Fixing TIA Portal V11 Alarm Indicator Counter on IM151-8

Problem Summary

An IM151-8 PN/DP CPU from the ET 200S family driving a SIMATIC KP400 Comfort panel produces an alarm indicator whose pending-alarm counter is wrong in three distinct ways. The HMI project was engineered in TIA Portal V11 SP2 Update 3 with WinCC V11 SP2. The PLC program source was migrated from STEP 7 V5.x to TIA Portal V11, and the same DB number (DB55) and the same area pointer (MD100 moved to DB55.DBD0) are still being used by the alarm indicator. Three counter symptoms are reproducible on the panel:

• One pending alarm in the errors group: counter reads 1 (correct).
• One pending alarm in the errors group plus one active system message outside the group: counter reads 2 (incorrect, the system message should not be counted).
• Two or more pending alarms in the errors group: counter stays at 1 (incorrect, the counter should increment).

The Alarm Class settings in the HMI correctly mark only the errors group as counted, so the miscount is not an alarm-class configuration issue. The fault lies in the runtime hand-off between the PLC data block and the HMI area pointer that drives the indicator.

Affected Hardware, Firmware and Software Versions

Observed Counter Behavior

The following matrix is taken directly from on-panel observations with the HMI tag PendingAlarms_errors bound to the alarm indicator.

State A passes, which is why the issue is not caught at single-alarm FAT. States C and D are the most dangerous operationally: the operator sees a single counter tick and assumes only one alarm is open, but multiple alarms are simultaneously pending.

Root Cause Analysis

The alarm indicator on a WinCC Comfort/Advanced runtime is driven by an area pointer defined in the HMI connection. The pointer has two logical halves:

1. A trigger area in the PLC whose bit state marks an alarm as pending (1 = pending, 0 = cleared). One bit per alarm, packed contiguously in a word or double-word array.
2. An acknowledgement area in the PLC whose rising edge (0 -> 1) tells the HMI that the operator has acknowledged the alarm at the panel.

The HMI reads these two areas by polling. It does not know or care how the PLC internally lays out the bits; it only respects the configured starting address and the length in words. The counter increment that the operator sees is just the popcount of the trigger area over the length the HMI was told to read.

What changed during migration:

• The STEP 7 V5.x source declared DB55.DBD0 as a BOOL storage location. In STEP 7 V5, a BOOL at the start of a data block occupies the LSB of the first byte, so the alarm trigger bit sat at DB55.DBX0.0 and the ACK bit sat at the offset the original programmer chose (in this project it was immediately adjacent).
• When the project was re-compiled in TIA Portal V11, the same DB55 slot was generated as a DInt because the symbolic source the user pasted into the DB initializer (a literal of type INT) was interpreted as DInt by the TIA DB wizard. A DInt occupies four bytes, not one, and the bit pattern of the variable no longer coincides with the LSB-of-byte-0 layout that the HMI area pointer still references.
• As a result, the HMI is reading from a byte that now contains the high byte of the DInt, not the original BOOL bit. The first alarm still works because bit 0 of the high byte happens to be the system bit that the user moves from MD100. The second alarm fails because the bit the HMI expected to find for alarm #2 is now located in a different byte. The system message is counted in state B because the HMI sweeps a full word, and one of the other bits in that swept word is the system message acknowledge flag that has been left in the same word due to the data type shift.

In TIA Portal V11, the DB initializer does not preserve BOOL semantics the way the older STEP 7 editor did. The fix is to declare the alarm storage area with an explicit width and bit offset, not to rely on the DB wizard to pick a type from a literal.

Solution Procedure

Follow this ordered procedure to restore the correct counter reading.

1. Capture the original STEP 7 layout. In the legacy STEP 7 V5.x project, open DB55 and write down the address, symbolic name and data type of every element that the alarm indicator touches. In this project, the trigger and ACK areas were both anchored on DB55.DBD0 with the type BOOL.
2. Open the TIA Portal project and isolate DB55. In the project tree, expand PLC > Program blocks > DB55. Switch the data block to Data view (not Declaration view). Confirm the actual generated data type at offset 0.0. If the column shows DInt, INT or WORD where BOOL is required, that is the defect.
3. Reset the DB to match the legacy layout. Edit DB55 in declaration view. Replace the auto-generated element with a STRUCT whose first member is a BOOL array of the required length (for example, ARRAY[0..31] OF BOOL). Assign the alarm group tags to specific bits inside the array, e.g.:

   TYPE "DB_AlarmLayout"
     STRUCT
       Trigger : ARRAY[0..31] OF BOOL;   // bit per pending alarm in "errors" group
       Ack     : ARRAY[0..31] OF BOOL;   // HMI -> PLC acknowledge, one bit per alarm
     END_STRUCT;
   END_TYPE

4. Recompile the S7 program. In the project tree, right-click the Program blocks folder and select Compile > Software (rebuild all blocks). Verify that the Compilation messages tab contains no implicit type-conversion warnings on DB55.
5. Verify the HMI area pointer. In the HMI project, open Connections > <HMI connection> > Area pointer. Confirm the pointer for the alarm indicator still references DB 55, word 0 (trigger) and the same or a parallel word for acknowledgement. If the original project used a length of 1 word and the alarm group has grown, extend the length accordingly.
6. Regenerate the HMI image. Right-click the KP400 device and select Compile > Software (rebuild all). Then choose Download to device > Software (all) to flash the panel. TIA Portal V11 SP2 Update 3 requires the panel to be in Transfer mode for this step.
7. Repower the ET 200S station. Power-cycle the IM151-8 so the freshly compiled DB55 is loaded into load memory and copied to work memory. A run/stop -> run transition is not enough on IM151-8 if Delete in RUN was not previously enabled on the DB.

Verification

Verification must be done on the panel, not in the PLCSIM, because the area pointer hand-off is only exercised on a real WinCC runtime.

1. Force a single alarm in the errors group from the watch table. Confirm the counter reads 1.
2. Force a second alarm in the same group. Confirm the counter reads 2.
3. Force a third alarm. Confirm the counter reads 3.
4. Trigger a system message from any other alarm group. Confirm the counter does not change.
5. Acknowledge the alarms from the panel. Confirm the counter falls back to 0, and the alarm log records the acknowledgement.
6. Repeat the test with a power cycle. The count must survive a station restart in RUN.

If states C and D still show "stuck at 1", repeat steps 3 and 5: the STRUCT members in DB55 must be in declaration view order, not alphabetical, because the PLC reserves storage in declaration order.

Migration Best Practices from STEP 7 to TIA Portal

Data type ambiguities are the most common silent failures when migrating STEP 7 V5.x projects to TIA Portal V11. The following rules prevent the alarm indicator defect (and several similar ones) from reappearing.

• Never let the TIA DB wizard infer a data type from a literal. STEP 7 V5.x accepted DB55.DBD0 as a 32-bit container that you could then address bit-wise. TIA Portal V11 will pick a numeric type for the same symbol. Declare the type explicitly in the Data type column before any code references the symbol.
• Use STRUCTs for HMI area pointers. Group the trigger, ACK and any additional alarm control bits inside a single STRUCT, and bind the HMI area pointer to the STRUCT base address. This locks the bit layout to the declaration order and survives subsequent edits.
• Recreate, do not migrate, the HMI tags. When STEP 7 V5.x HMI tags are imported into WinCC V11, the absolute PLC addresses are sometimes re-interpreted. After migration, expand HMI tags > <connection> > Show all tags and confirm the area pointer is still pointing to the original DB, word, and length.
• Pin the engineering versions. Mixing STEP 7 V5.5 + TIA Portal V11 SP2 Update 3 is supported as a stop-gap (the on-site fix used this) but causes the HMI and PLC to diverge over time. Plan a follow-up migration to TIA Portal V13 or later, where the DB wizard is more deterministic and the BOOL preservation has been hardened.
• Lock the panel image version. WinCC V11 SP2, WinCC V11 SP2 Update 4 and WinCC V11 SP2 Update 5 all have different alarm indicator behaviors. Pin the panel image version in Devices & Networks > KP400 > Properties > Image to avoid silent behavior change when the engineering PC is updated.

Alarm Indicator Configuration Reference

Use the table below as a checklist whenever the counter is in doubt. Each row is a configuration field in TIA Portal V11 SP2 Update 3, the value the field must have, and the failure mode if it is wrong.

Data Type Layout Reference

Why the data type shift is so destructive: the HMI area pointer is byte- and bit-precise. A change of one bit in the assumed layout cascades into all three failure states.

The "stuck at 1" behavior in state C is explained by the fact that the HMI still reads DBW0 as a 16-bit value but only the LSB now contains a controllable bit. The HMI counts LSB set = 1, LSB clear = 0, and never observes the higher bits moving because the program moves MD100 into DB55.DBD0 with a single MOV instruction, not a bit-by-bit OR.

Troubleshooting Matrix

Field-Proven Cautions

• Do not trust a single-alarm FAT. The defect is invisible with one alarm and only appears at two or more pending alarms, or with one alarm plus an unrelated system message. FAT scripts must include the multi-alarm case.
• PLCSIM masks the defect. The PLCSIM internal bit model and the WinCC runtime simulator do not exercise the same area pointer hand-off as a real ET 200S / KP400 pair. Always run final validation on the real hardware.
• DB wizard changes break more than alarms. The same data-type inference defect can corrupt recipe data, axis position latches and PROFINET diagnostics. After every migration, scan all DBs for implicit numeric promotion.
• Step 7 V5.x as a stop-gap is fragile. The on-site workaround in this case (CPU in STEP 7, HMI in TIA) worked for a single shipment but is not maintainable. The PLC will eventually need to be re-engineered in TIA Portal once the HMI is also migrated to a current Comfort version.
• Back up the working DB55 layout. Before any TIA Portal upgrade, export the DB to a SIMATIC source file (".scl" or ".awl") and store it in version control. Re-importing a backup is faster than re-deriving the layout after a wizard change.