KTP600 Alarm Logging Resolving Historical Data Limitation

1. Problem Definition

A SIMATIC KTP600 Basic mono PN (1st generation) connected to a S7-314C-2 PN/DP does not show a Historical Data node under the project tree in WinCC Flexible 2008 SP5 or TIA Portal V13/V14/V15/V16. Engineers configuring alarm logging typically navigate to Historical Data > Alarm logs to define a log target, but the node is missing because the runtime firmware of the 1st generation Basic Panel firmware family does not implement the log subsystem. The result is that an Alarm View cannot be switched into Log mode, and there is no on-panel storage of past alarm events beyond the volatile alarm buffer.

The following signals confirm the limitation:

• The Historical Data editor is grayed out or absent in the project tree.
• An Alarm View on a screen only offers Alarm buffer and Pending alarms modes; the Alarm log selection is unavailable.
• Tag logging configuration succeeds in the engineering tool but produces no runtime dataset on the panel.

The remedy is either to (a) re-engineer the alarm visualization to use the 256-entry circular alarm buffer, or (b) replace the panel with a 2nd generation Basic Panel (KTP700 Basic mono PN or larger), which exposes the full Logs subsystem in WinCC Comfort / TIA Portal.

2. Root Cause: Panel Generation and Capability Boundary

Siemens Basic Panels are partitioned by hardware generation. The 1st generation Basic Panels (article numbers in the 6AV6 647-0xxxx-3AX0 series) ship the WinCC Flexible runtime; the 2nd generation Basic Panels (6AV2 123-2xx03-0AX0 series) ship the WinCC Comfort / TIA Portal runtime. The runtime difference is not cosmetic:

3. KTP600 Alarm Buffer Architecture

The alarm buffer on a 1st generation KTP600 is implemented as a fixed-size, volatile, first-in / first-out (FIFO) ring of 256 alarm records. The buffer lives in panel RAM; it is wiped on power-down and on a cold restart of the runtime. The buffer is the only historical view of alarm state available on this panel class.

Each discrete alarm event generates up to three records in the buffer:

1. Came — the moment the alarm condition became active.
2. Acknowledged — the moment the operator pressed the ACK key (only emitted if the alarm class requires acknowledgement).
3. Cleared — the moment the alarm condition returned to a safe state.

An operator opening the Alarm View therefore sees a sequence such as 2014-03-12 08:14:22.117 / MotorOverload / came / PLC tag Bit 3.4, followed minutes later by 2014-03-12 08:17:05.402 / MotorOverload / acknowledged, then 2014-03-12 08:19:11.880 / MotorOverload / cleared. A single physical fault can therefore consume three slots of the 256-entry buffer.

Figure 1 — State machine showing the three buffer records generated per discrete alarm event on a 1st generation Basic Panel.

If the system has 100 discrete alarms, an aggressive fault burst will fill the 256-entry ring in roughly one hundred alarm cycles. Once full, the oldest record is overwritten without warning. Operators must therefore be educated that the panel is not a long-term historian for alarms; it is a short-term visibility window. Persistent recording must be implemented at the controller level, on an SD card in the S7-300 CPU, or on a SCADA node upstream.

4. Configuring the Alarm View in WinCC Flexible 2008 SP5

Because the KTP600 has no Historical Data editor, alarm configuration is performed entirely from the Alarm editor in WinCC Flexible. The procedure below yields a functional alarm buffer view on the KTP600 Basic mono PN paired with an S7-314C-2 PN/DP.

4.1 Prerequisites

• WinCC Flexible 2008 SP5 (or later SP) installed on the engineering station.
• A converted or freshly created KTP600 Basic mono PN project (target device 6AV6 647-0AA11-3AX0).
• The S7-314C-2 PN/DP CPU is reachable on PROFINET and is selected as the only connection partner.
• HMI tags are defined and mapped to PLC tags carrying alarm state.

4.2 Step-by-Step

1. Open the project in WinCC Flexible 2008 SP5 and confirm the panel type under Project > Device Properties.
2. Open Project > Communication > Connections and verify the single PROFINET connection to the S7-314C-2 PN/DP. The HMI is the only client; the CPU's integrated PROFINET interface is the server.
3. Open Alarms > Discrete Alarms and add one row per alarm bit. For each row, set Trigger tag (e.g., DB100.DBX0.0 for MotorOverload), Alarm class (Errors, Warnings, etc.), Alarm text, and Group.
4. Open Alarms > Analog Alarms and add limit-based alarms if required.
5. Open the desired screen, insert an Alarm View from the toolbox, and configure the view properties as follows:

   Property	Setting for alarm-buffer view
   Mode	Alarm buffer
   Display	Pending and acknowledged (or Active)
   Columns	Date / Time, Alarm text, Status (Came / Acknowledged / Cleared)
   Sort	Date / Time descending
   Single acknowledgment	Enabled for Errors class only

6. Compile the project (Project > Compiler > All). The transfer will report No errors; the warning Alarm log not configured will be present and is expected.
7. Download to the KTP600 via PROFINET or Ethernet and observe the alarm buffer updating in real time.

5. Configuring Alarm Logging on a 2nd Generation Basic Panel

When the application genuinely requires a persistent alarm log — for example, to satisfy a 21 CFR Part 11-style audit trail or a process historian — the panel must be a 2nd generation Basic Panel or larger. The 2nd generation runtime implements the Logs subsystem described in the TIA Portal alarm logging documentation:

Basics of alarm logging (RT Unified) - WinCC Unified, TIA Portal V20

On WinCC Comfort / TIA Portal V16 and later, the project tree exposes Historical Data > Alarm logs as a first-class editor. The runtime then writes a CSV-formatted alarm log into the panel's flash memory, which survives power-down and can be exported via the panel's Service > Backup / Restore page or pulled via the panel's web server (where licensed).

5.1 Procedure in TIA Portal

1. Add a KTP700 Basic mono PN (6AV2 123-2GB03-0AX0) or larger to the project.
2. Drag the discrete alarm definitions from the imported WinCC Flexible project; TIA Portal retains alarm classes, trigger tags, and group memberships.
3. Open Historical Data > Alarm logs, add a new log named e.g. ProcessAlarms, set Storage location to File system (CSV), and choose Ring buffer or Sequential as the log strategy.
4. Under Alarms > Properties > Logging, assign each alarm to the ProcessAlarms log.
5. On the runtime Alarm View, switch Mode from Alarm buffer to Alarm log; the operator can now scroll back beyond the 256-entry buffer.
6. Enable Service > Logs > Export to allow CSV retrieval.

6. Hardware Migration Paths

If the application cannot live with the volatile 256-entry buffer, three realistic migration paths exist:

Figure 2 — Three migration paths from the 1st generation KTP600 buffer-only architecture.

1. 2nd generation Basic Panel swap. Replace the KTP600 with a KTP700 Basic mono PN or KTP1200 Basic. The KTP700 mono (PN article 6AV2 123-2GB03-0AX0) is the smallest 2nd generation panel and supports full alarm logging. The cutout grows from 197 × 122 mm to 197 × 141 mm; check door swing and bezel clearance. The existing PROFINET connection from the S7-314C-2 PN/DP is reused unchanged.
2. Controller-side logging on the S7-300. Add a SIMATIC MMC (e.g., 6ES7 953-8LF30-0AA0, 8 MB) or a standard SD card in the S7-300 CPU slot, then write a DataLog block to /LOG from STEP 7. This captures alarms at the source even if the panel is replaced with another 1st generation panel or removed entirely. S7-300 supports the standard SFCs DPRD_DAT, DPWR_DAT for any external archive.
3. WinCC Unified SCADA add-on. Keep the KTP600 in place but add a WinCC Unified station on the same PROFINET network and forward alarms via Alarms-to-Connect for long-term SQLite storage. This is appropriate when an existing SCADA node is already present.

7. Controller-Side Alarm Capture (STEP 7 SCL Snippet)

When a persistent log is required but the panel cannot be swapped, capture the alarm edges in the S7-314C-2 PN/DP itself. The following SCL snippet writes one line per Came event into a global DB that can be flushed to the S7-300's MMC by the operating system when using DataLog, or polled by the HMI.

// FB_CaptureAlarm (cyclic, OB1)
// Input : bAlarmIn BOOL, szAlarmText STRING[32], dtStamp DATE_AND_TIME
// Output: writes a record into a ring buffer DB

FUNCTION_BLOCK FB_CaptureAlarm
VAR
    iWriteIdx  : INT;          // 0..255 ring index
    bFull      : BOOL;         // set when ring has wrapped
END_VAR
VAR_TEMP
    pEntry     : POINTER TO tAlarmRec;
    iCur       : INT;
END_VAR
TYPE tAlarmRec : STRUCT
    dtWhen     : DATE_AND_TIME;
    szText     : STRING[32];
    eState     : BYTE;         // 1=came, 2=ack, 3=cleared
END_STRUCT END_TYPE

IF bAlarmIn AND NOT bPrevIn THEN       // rising edge of fault bit
    iCur := iWriteIdx MOD 256;
    pEntry := ADR(dbAlarmRing.alarm[iCur]);
    pEntry^.dtWhen := DT_TO_DATE_AND_TIME(IN := dtStamp);
    pEntry^.szText := szAlarmText;
    pEntry^.eState := 16#01;
    iWriteIdx := iWriteIdx + 1;
    IF iWriteIdx >= 256 THEN bFull := TRUE; END_IF;
END_IF;
bPrevIn := bAlarmIn;

The DB can be exported via the S7-300 file system or read by the KTP600 as a recipe-style data block and displayed in a Recipe View. Note that KTP600 Basic mono also lacks recipe support on some firmware revisions, so confirm the runtime version in Project > Device Properties > Runtime before relying on this path.

8. Communication and Timing Constraints

The S7-314C-2 PN/DP CPU supports up to 8 PROFINET IO connections and up to 16 S7 connections in total, of which the HMI typically consumes one. Alarm updates are exchanged using the standard S7 protocol on top of ISO-on-TCP (port 102) or (optionally) RFC 1006 over TCP. The following timings apply for a 314C-2 PN/DP at a 0.1 ms PROFINET cycle:

9. Verification and Commissioning Checklist

Use the following checks to confirm the alarm subsystem behaves as expected after configuration:

1. Force a known alarm bit true in STEP 7 (e.g., set DB100.DBX0.0 := TRUE in the VAT table). Confirm the alarm appears in the Alarm View with the correct timestamp and class colour within one second.
2. Press the ACK softkey on the panel; confirm the row changes from Came to Acknowledged and that the ACK bit is written back to the configured PLC tag (typically DB100.DBX16.0 on a 314C).
3. Force the alarm bit false and verify the Cleared record enters the buffer.
4. Trip 100 distinct alarms within one minute and verify the ring wraps at entry 256 without crashing the runtime. On the KTP600 firmware < V12, a runaway alarm storm can corrupt the buffer pointer; if this occurs, upgrade to the latest Service Pack.
5. Cycle power to the panel and confirm that, on reboot, the buffer is empty — this is the expected behaviour for a 1st generation panel.
6. If using a 2nd generation panel, copy the \Storage Card SD\Logs\alarms.csv file to a USB stick via the panel's Service menu and confirm rows are present after power-down.
7. Compare the panel's log timestamp with the CPU's STATUS_WORD of SFC 1 (READ_CLK); the two should agree to within one second. Drift indicates the panel RTC battery (CR2032, replaceable) is depleted.

10. Troubleshooting Matrix

11. Safety, Compliance, and Operational Notes

• Alarm logging on a 1st generation Basic Panel is not a substitute for a safety-rated recording system. The 314C-2 PN/DP's integrated PROFIsafe or external F-CPU remains the legally binding record for safety incidents.
• When a persistent alarm audit trail is required by a regulated standard (e.g., 21 CFR Part 11, ISO 13485, IEC 61511), the operator must rely on the controller-side log or an upstream SCADA historian — not the volatile panel buffer.
• Replacing a 1st generation KTP600 with a 2nd generation Basic Panel does not change the S7-300 program; the migration is purely HMI-side.
• Always cross-reference the firmware version of the S7-314C-2 PN/DP against the compatibility list for the 2nd generation panel in the TIA Portal release notes before reloading a converted project.