Resolving Custom Analog Alarm Trigger Failures on KTP600 Panels

Custom analog alarms on Siemens KTP600 DP color Basic Panels configured with WinCC Flexible 2008 frequently fail to fire even when the engineering project appears correct: the limit tag is wired, the trigger tag is monitored, the alarm class is assigned, and the trigger condition is enabled. The most common symptom is that the alarm does not fire when the operator enters a value above the limit, but does fire when the limit is later moved below the trigger value. This is not a software defect in the panel firmware and it is not a corrupted tag table. It is a deterministic consequence of the I/O field's operating mode combined with the way the analog alarm comparison pipeline is wired to the tag's stored value.

This reference explains the engineering root cause, the I/O field mode matrix, the project recovery procedure for stale runtime images, the OS update sequence for KTP600 Basic Panels, the verification steps that prove the fix, and the configuration practices that prevent the symptom from recurring on subsequent revisions.

Affected Components, Versions, and Hardware Specification

The symptom has been reproduced and verified on the following configuration:

The KTP600 DP color Basic Panel (Siemens article number 6AV6 647-0AE11-3AX0 for the color variant, 6AV6 647-0AD11-3AX0 for the monochrome variant) is part of the Basic Panels product line that was designed for compact operator control tasks and is supported by both WinCC Flexible 2008 and the TIA Portal from V13 onward. The panel integrates a 5.7-inch TFT display, a resistive analog touch surface, six freely configurable function keys, and a PROFIBUS DP slave interface on the DP variant. The runtime environment is delivered as part of the panel firmware image and is not separately upgradeable outside of the OS update procedure described in the WinCC Flexible help system.

KTP600 Basic Panel technical characteristics relevant to alarm configuration:

The full hardware and interface specification for the KTP600 DP color is documented in the SIMATIC HMI KTP600 Basic Panel Operating Instructions available on the Siemens Industry Online Support portal. The WinCC Flexible 2008 engineering environment is documented in the WinCC Flexible 2008 User's Manual.

Symptom Matrix and Reproducer Sequence

The failing scenario can be reproduced deterministically with the following sequence. The trigger tag and the limit tag are both internal HMI tags (data type INT, initial value 0). The custom alarm class "aa_error_1_by_user" is configured with the trigger tag as the trigger source and the limit tag as the high-limit threshold. The trigger I/O field is configured with mode "Input" and the limit value is used as the upper range limit of the I/O field.

1. Start runtime on the panel. Both internal tags initialize to 0.
2. Set the limit I/O field to 50. The limit tag receives 50.
3. Attempt to enter 60 in the trigger I/O field. The panel rejects the entry. The trigger tag remains at 0 (or the previous accepted value). The system message for "value out of range" is emitted.
4. Enter 45 in the trigger I/O field. The entry is accepted. The trigger tag holds 45.
5. Change the limit I/O field to 40. The limit tag now holds 40, which is below the trigger value of 45.
6. The custom alarm "aa_error_1_by_user" fires. The trigger value (45) has not changed; the threshold (40) has moved.
7. Set the limit I/O field back to a value above 45 (for example 50). The custom alarm is cleared.

The same project loaded in the WinCC Flexible simulator on the engineering PC, with the I/O field set to Input/Output mode, exhibits the expected behavior: the operator can type a value above the limit (if the range check is configured for the operator input), or the PLC writes a value above the limit, and the custom alarm fires immediately. The simulator result confirms that the project source is correct and that the difference is in the I/O field mode configuration.

Symptom-to-cause matrix:

Root Cause: I/O Field Mode vs. Tag Access Mode

The root cause is the combination of two configuration choices in the WinCC Flexible project. The first is that the I/O field that drives the trigger tag is configured in Input mode. The second is that the custom alarm is configured to monitor the trigger tag against the limit tag. These two choices interact in a way that is not visible from either property sheet alone.

In Input mode, the I/O field is a one-way street from the operator to the tag, gated by the configured range. The panel's runtime applies a value-range check to the operator's entry before it commits the value to the tag. Any value that falls outside the configured upper or lower limit is rejected, the operator is shown a system message, and the tag is either left at its previous value or forced to the nearest in-range boundary depending on the I/O field's "Behavior on invalid value" property. The trigger tag therefore never actually receives a value above the limit, and the analog alarm's high-limit condition "trigger > limit" is logically false at all times.

When the operator lowers the limit below the current trigger value, the alarm does fire - but the trigger condition is now being satisfied because the threshold moved, not because the trigger value moved. As soon as the threshold is moved back above the trigger value, the alarm is cleared. This is the expected behavior of a high-limit analog alarm, but it is the wrong alarm to diagnose a user input error, because the user input is being prevented by the I/O field before the alarm subsystem ever sees the offending value.

If the alarm class is changed to the built-in "System" class, the system messages for the I/O field's out-of-range entry are still emitted. Those messages are routed through a different code path that is independent of the trigger tag's stored value. The system message handler maintains its own internal event log and is triggered by runtime events, not by tag-value comparisons. That is why the System class appears to "work" while the custom class does not.

The architectural constraint that produces this behavior is the I/O field's "Mode" property in the WinCC Flexible configuration. Three modes are available for an I/O field bound to a tag:

A common misconception is that the I/O field mode is equivalent to the tag's access mode. They are not. The tag's access mode (internal, external with absolute address, external with symbolic address) determines where the value physically resides - in the panel's local memory, in the connected PLC's process image, or in a referenced data block. The I/O field mode determines which party is allowed to write the value and which party is allowed to read it on the HMI. For a custom alarm triggered on the trigger tag, the I/O field mode is the property that controls whether the value entering the tag can ever exceed the configured limit.

Architectural Constraint: Input Validation and Alarm Trigger Pipeline

To understand the interaction precisely, the input validation and alarm trigger pipeline for a tag with an I/O field and a custom analog alarm proceeds in the following order:

1. Operator enters a value on the I/O field and presses Enter (or the I/O field loses focus).
2. The runtime converts the entered text to the tag's data type (for example INT or REAL).
3. The runtime checks the converted value against the I/O field's configured Limits property (low limit, high limit). This check is performed only when the I/O field is in Input or Input/Output mode.
4. If the value is out of range, the runtime rejects the entry, emits a system message, and either discards the entry or clamps the value to the nearest in-range boundary depending on the "Behavior on invalid value" property.
5. If the value is in range, the runtime writes the value to the tag. The write propagates to the tag's storage location (internal memory for internal tags, the PLC process image for external tags).
6. The alarm subsystem reads the tag's new value and evaluates all configured analog alarm conditions that reference the tag.
7. If the condition becomes true, the alarm is raised, assigned to its configured alarm class, and queued for display in the alarm view and for logging in the alarm log.

The critical observation is that the alarm subsystem reads the tag's value, not the operator's entered value. The operator's entered value is intercepted at step 3 and either passed through or rejected. The tag's value at step 6 is the value that was successfully written at step 5. If the I/O field rejects every out-of-range operator entry at step 4, the tag never holds an out-of-range value, and the alarm at step 7 is never raised.

This is by design. The I/O field's range check is a defensive measure to prevent the operator from accidentally entering a value that the process cannot tolerate. The analog alarm is a separate defensive measure to detect when the process value (regardless of source) exceeds the safe range. The two mechanisms are not redundant - they are complementary. The I/O field range check protects the operator from the tag; the analog alarm protects the process from the tag.

When the safety logic is designed to alert on a too-high operator input, the design must account for the fact that the I/O field range check will silently clamp the input. The two valid design patterns are:

1. Disable the I/O field range check for the trigger tag and rely solely on the analog alarm. Set the I/O field's Limits property to a range that is wider than the safe range, and configure the analog alarm to fire when the tag value exceeds the safe limit. The operator can type any value in the wider range, and the alarm fires for any value above the safe limit.
2. Move the limit check to the PLC. The PLC reads the trigger tag from the operator, validates it against the process-safe range, and writes the validated value (or an out-of-range flag) to a separate tag. The I/O field bound to the operator's raw input can be in Input/Output mode, and the analog alarm is configured on the PLC-validated tag. The I/O field's own range check can be left at the PLC's process-safe range, or it can be widened to permit the PLC to detect the violation.

Pattern 1 is the simpler configuration and is appropriate for a single-panel system with no PLC. Pattern 2 is the more robust configuration for a system with a PLC and is appropriate when the safety logic needs to be in the PLC for audit or SIL reasons. Both patterns produce a deterministic alarm behavior on the panel; the failure mode of the original configuration (Input mode + custom alarm on the clamped tag) is a configuration error, not a runtime error.

Solution: Reconfigure the I/O Field Mode

The primary fix is to change the I/O field from Input mode to Input/Output mode. This allows the PLC (or a WinCC Flexible script bound to a tag or to a schedule) to write a value above the limit, which is what the custom alarm is designed to detect. The operator's input is still subject to the range check, so the panel will continue to reject out-of-range operator entries - but the alarm will now fire on the PLC-driven value, which is the intent of the safety logic.

To reconfigure the I/O field in WinCC Flexible 2008:

1. Open the project in WinCC Flexible 2008.
2. In the project tree, expand "Screens" and double-click the screen that contains the "trigger" I/O field. The screen editor opens.
3. Click once on the "trigger" I/O field to select it. The Properties dialog opens in the inspector on the right side of the screen editor.
4. In the Properties > General section, locate the "Mode" property. The current value will be "Input".
5. Click the Mode property and select "Input/Output" from the drop-down list.
6. In the Properties > Limits section, verify the configured upper and lower limits. These are the limits that the panel runtime applies to operator input only. If the PLC is expected to write values that are intentionally above the operator-acceptable range, set the I/O field's upper limit to a value at or above the highest expected PLC write, so that the operator can still type a value in the PLC's expected range if the operator is permitted to do so.
7. Save the screen. From the File menu, select "Save" or press Ctrl+S.
8. From the Project menu, select "Rebuild All". Wait for the compile to complete without errors.
9. Transfer the project to the panel as described in the Project Recovery Procedure below.

After the I/O field mode is changed, the trigger tag will accept writes from the PLC, and the analog alarm configured on the trigger tag will fire as soon as the PLC writes a value above the limit. The operator's input is still range-checked, but the panel no longer prevents the alarm from being raised on a PLC-driven value.

Project Recovery: Rebuild, Reset, OS Update, Transfer

If the project on the engineering PC has been edited in ways that produced inconsistent state - for example, tags were renamed, alarm classes were duplicated, library references were broken, or the project was migrated from an earlier WinCC Flexible version - WinCC Flexible may compile the project but leave stale references in the generated runtime image. In that case, the panel will exhibit the symptom regardless of the I/O field mode change, because the runtime image is not consistent with the project source.

The recovery procedure for a stale WinCC Flexible project on a Basic Panel is a four-step sequence: Rebuild, Reset, OS Update, Transfer. Each step addresses a specific failure mode. The sequence is the most reliable way to bring a Basic Panel to a known-good state and is the procedure recommended in the WinCC Flexible 2008 User's Manual for commissioning and recommissioning.

Step 1: Rebuild All. From the Project menu in WinCC Flexible 2008, select "Rebuild All". This regenerates the entire runtime image, including all screens, tags, alarms, area pointers, scripts, and recipes. The incremental compile that runs on every save is fast but can leave stale object code for objects that were renamed or deleted. The full rebuild takes longer (typically 5-30 seconds for a KTP-class project) and guarantees that the runtime image is consistent with the project source.

Step 2: Reset to factory settings. In the project tree, right-click the panel (under "Devices" or under the project root) and select "Reset to factory settings". This erases the application memory and the runtime image on the panel. The operating system, the panel's serial number, the PROFIBUS address, and the calibration data are preserved. The panel reboots and shows the standard "WinCC Flexible" or "TIA Portal" startup screen. The reset is required because the panel's existing runtime image may contain references to the old tag names, old alarm class names, or old screen numbers, and the new runtime image would conflict with those references if it were transferred on top of the old image.

Step 3: OS Update. In the project tree, right-click the panel and select "OS Update". WinCC Flexible prompts for the OS image file. The OS image for the KTP600 is part of the WinCC Flexible 2008 installation under "WinCC Flexible\Images" (the path varies by installation; the default in Windows XP SP3 is C:\Program Files\Siemens\Automation\WinCC Flexible\Images). The image file is named after the panel's order number - for the KTP600 DP color, the file is KTP600.dp_color.img or similar. Select the matching image and wait for the update to complete. The panel reboots automatically when the update is complete. The OS update is required when the panel's operating system version does not match the runtime version expected by the project, or when the panel is being commissioned for the first time.

Step 4: Transfer. In the project tree, right-click the panel and select "Transfer" > "to target device". The compiled runtime image is downloaded to the panel via the configured PG/PC interface (PROFIBUS DP for the KTP600 DP, MPI for the KTP600 PN, or Ethernet for the KTP600 Basic PN variants). The panel restarts and runs the new project. If the panel's transfer mode is not enabled, the panel's Control Panel must be opened on the panel itself, the "Transfer" settings must be configured to allow remote transfer, and the transfer must be initiated from the engineering PC within the transfer timeout window.

The four steps can be executed individually in the WinCC Flexible 2008 menu, or the Rebuild All and Transfer can be combined into a single operation from the Project menu. The Reset to factory settings and the OS Update must be executed individually.

OS Update Procedure for KTP600 Basic Panels

The OS update is a separate procedure from the runtime transfer. The OS update replaces the panel's operating system image (the firmware), while the runtime transfer replaces the application memory (the project). The two are stored in different partitions of the panel's flash memory and are upgraded independently.

The OS update is required in the following situations:

• The panel is being commissioned for the first time (factory state, OS image may be missing or may be an older version).
• The project was migrated from a previous WinCC Flexible version and requires a newer runtime that is not present on the panel.
• The panel's operating system has been corrupted (typically indicated by the panel showing a boot loop or a "WinCC Flexible" screen that does not proceed to runtime).
• The panel's operating system version does not match the version expected by the project (WinCC Flexible checks the version on transfer and refuses to transfer if the versions are incompatible).

The OS update is not required for routine project changes. If the project has been modified but the panel's OS version is already compatible with the new project, the runtime transfer alone is sufficient. Forcing an OS update on every transfer is not harmful but adds several minutes to the commissioning cycle and can be skipped when the OS version is already known to be correct.

Procedure:

1. Connect the engineering PC to the panel via the configured PG/PC interface. For the KTP600 DP, this is PROFIBUS DP at the panel's configured address. The default PROFIBUS address for a new KTP600 is 1; the default for a KTP600 in a configured project is the address set in the project under "Device" > "Properties" > "PROFIBUS".
2. Set the PG/PC interface on the engineering PC. In the Windows Control Panel, open "Set PG/PC Interface" and select the appropriate interface - either "PC Adapter (PROFIBUS)" for a USB-to-PROFIBUS adapter, "CP5611 (PROFIBUS)" for the Siemens CP5611 PCI card, or the equivalent for the available PROFIBUS hardware.
3. In WinCC Flexible 2008, open the project. In the project tree, right-click the panel and select "OS Update".
4. The "OS Update" dialog opens. Select the correct OS image file from the WinCC Flexible installation directory. The image file for the KTP600 DP color is typically named KTP600_color_Vx.x.x.img or similar (the version number is part of the filename).
5. Click "Update OS". The transfer begins. The panel displays a progress bar and the engineering PC displays the transfer log in WinCC Flexible.
6. Wait for the transfer to complete. Do not power-cycle the panel during the transfer. Interrupting an OS update can leave the panel in an unrecoverable state that requires a factory service procedure.
7. The panel reboots automatically when the update is complete. The boot screen shows the new OS version. The panel is now in the factory state with the new OS and no application memory.
8. Proceed to the runtime transfer (Step 4 of the Project Recovery procedure above).

The OS update log is written to the WinCC Flexible transfer log (typically C:\Program Files\Siemens\Automation\WinCC Flexible\Log) and can be reviewed for transfer errors. The most common OS update failure is a PROFIBUS connection error, which is typically caused by incorrect baud rate, incorrect PROFIBUS address, or missing PROFIBUS termination. The second most common failure is an incorrect OS image file, which is caused by selecting the image for a different panel variant (KTP600 DP monochrome vs. KTP600 DP color, or KTP600 DP vs. KTP600 Basic PN). The OS image must match the panel's order number exactly.

Verification Procedure and Acceptance Tests

After the I/O field has been reconfigured and the project has been rebuilt and transferred, the following verification sequence should be executed on the panel. Each step has a specific pass criterion. If any step fails, the procedure must be repeated from the I/O field mode change.

Step 3 is the key acceptance test for the I/O field mode change. If the custom alarm fires in step 3, the mode change has been applied correctly and the PLC-driven write path is working. Step 6 confirms that the operator's input is still range-checked. Step 7 confirms that the alarm is reacting to the PLC write and not to the operator input. If the alarm fires in step 6 (operator input above the limit is accepted and the alarm fires), the I/O field's Limits property has not been configured, and the fix is to add the limit to the I/O field's Limits property while keeping the mode in Input/Output.

Alarm Class and Analog Alarm Configuration Reference

In WinCC Flexible 2008, alarm classes are configured in the project tree under "Alarm Logging" > "Alarm Classes". Each alarm class defines a name, a default acknowledgment model, a color scheme for the alarm state, and an optional logging destination. The custom alarm class "aa_error_1_by_user" is created in this dialog and is assigned to individual alarm events in the screens or in the tag-based analog alarms.

For analog alarms, the trigger source is a tag and the condition is a limit comparison. The available condition types are:

The reference configuration for the "dosing amount exceeds limit" scenario is:

The "Limit tag" can be a tag (so the limit is dynamic and operator-adjustable) or a constant (so the limit is static and engineering-defined). For dynamic limits, the limit tag must be defined in the project's tag table and assigned in the alarm's properties dialog under "Trigger" > "Limit". The limit tag and the trigger tag should use the same data type to avoid implicit conversions in the comparison. A common error is to define the trigger tag as INT and the limit tag as REAL; the comparison works but the precision is lost on the INT side, and the limit may effectively be one unit lower than the configured value due to truncation.

The alarm text supports two placeholder fields ({0} and {1}) that are filled with the trigger value and the limit value at the time the alarm is raised. The placeholder fields are configured in the alarm's properties under "Alarm text". The placeholders are not localizable separately from the alarm text and are not affected by the language switch on the panel.

Field-Commissioning Best Practices

Several configuration practices, when applied consistently, prevent the custom analog alarm trigger failure and related symptoms on Basic Panels.

1. Match the I/O field mode to the intended write source. Use Input mode when only the operator should write the value and the alarm should only fire on the operator's input. Use Input/Output mode when a PLC or script may also need to write the value, and when a custom alarm needs to react to those writes. Use Output mode when the value is calculated by the panel and displayed for diagnostic purposes only.
2. Use the I/O field's Limits property for operator range checking, and use a separate high-limit alarm for process safety. The I/O field's limits and the alarm's limits are independent properties. The I/O field limits prevent the operator from typing out-of-range values; the alarm limits detect process values that exceed the safe range, regardless of the source. Configuring both provides defense in depth.
3. Rebuild the project before every transfer. WinCC Flexible 2008 is an incremental compiler. The incremental compile that runs on every save is fast but can leave stale object code for objects that were renamed, deleted, or had their references changed. A "Rebuild All" ensures that no stale object code is left in the runtime image. The cost of a full rebuild is small for KTP-class projects (typically 5-30 seconds) and is negligible compared to the cost of diagnosing a stale-image symptom on the shop floor.
4. Reset to factory settings, OS update, and then transfer. This three-step sequence is the most reliable commissioning procedure for a Basic Panel. Skipping the reset or the OS update can leave the panel running an old operating system with a new runtime image, or a new runtime image with old configuration data, which can produce subtle behavior differences that are difficult to diagnose remotely.
5. Keep the engineering PC's time and the panel's time synchronized. The alarm log timestamps are based on the panel's internal clock. A mismatched clock can make an alarm appear to fire before it should or after it has cleared, which complicates root-cause analysis. The panel's time can be set in the panel's Control Panel under "Date/Time", or can be synchronized from the PLC via an area pointer if the panel's time synchronization is enabled in the project.
6. For internal tags, use the I/O field's Output mode for display-only values. This prevents the operator from accidentally editing a value that is supposed to be calculated by a script or a PLC write. The Output mode blocks operator input at the runtime, regardless of the I/O field's operator control enable setting.
7. For PLC-driven trigger values, use the I/O field's Input/Output mode and disable the operator's input by setting the "Operator control enable" property to "no". The field will display the PLC-driven value and the operator will not be able to edit it. The PLC write path is preserved, and the analog alarm fires on the PLC write.
8. Test with the simulator before the panel. The WinCC Flexible simulator on the engineering PC executes the same runtime code as the panel, with the only difference being the display device and the touch input. Reproducing the symptom in the simulator first confirms whether the issue is in the project source or in the panel's runtime image. If the symptom reproduces in the simulator, the project source has a configuration error. If the symptom does not reproduce in the simulator but does reproduce on the panel, the panel's runtime image is stale and the recovery procedure is required.
9. Document the I/O field mode and the alarm class in the project's documentation. The I/O field mode and the alarm class are not visible on the panel's runtime display. A change to either property can have non-obvious effects on the alarm behavior. Documenting the choices in the project's functional specification makes the rationale visible to the next engineer who works on the project.
10. Avoid using the same tag for operator input and PLC alarm source unless the design explicitly requires it. If the operator's raw input and the PLC's validated output are both needed, use two separate tags: one for the operator's input (in Input mode) and one for the PLC's validated output (in Output mode or bound to a separate I/O field). The analog alarm is configured on the PLC's validated output tag. This pattern prevents the I/O field range check from interfering with the alarm subsystem.

Frequently Asked Questions