Resolving WinCC Flexible 2007 HMI ACK Bit Anomaly on S7-300 PLCs

1. Problem Statement: Phantom HMIAck Bit Transitions in WinCC Flexible 2007

On SIMATIC S7-300 CPU 317-2 stations paired with SIMATIC WinCC Flexible 2007 panels, integrators routinely observe that the internal acknowledgment (HMIAck) bit of a discrete alarm unexpectedly transitions to "1" when a completely unrelated alarm trigger bit in the same trigger tag word is set. The most common symptom in the field is a 16-bit word (for example MW14 serving as deviceNr1AlarmHMIAckTag) in which the bit corresponding to alarm #1 goes high the instant alarm #2's trigger rises, even though alarm #1 has never gone active and was never acknowledged by the operator.

This behavior is not a PLC bug, not a wiring error, and not a CPU 317-2 defect. It is a deliberate design of the WinCC Flexible runtime data manager that exchanges the entire trigger/acknowledgment tag word atomically with the panel image at every HMI cycle. Because the alarm state image is rebuilt from the same word, transitions in the trigger area force a re-evaluation of every bit, and the running alarm class state machine writes back the current acknowledged condition for every alarm - including those that are inactive. Engineers who read HMIAck bits in the PLC for handshaking, statistics, or interlocking therefore see bits appear that the program never wrote.

The fix is to stop writing or reading the HMIAck bit and to use the dedicated "Acknowledgement PLC" tag configured per alarm class - a bit that the PLC owns, the panel reads, and the WinCC Flexible runtime never overwrites.

2. Affected Hardware and Software Versions

The 6ES7317-2AK14-0AB0 ships with 1 MB load memory, 256 KB work memory, 0.05 ms/KAW bit execution, and supports 32 digital I/O and 8 analog I/O in the central rack; none of these numbers matter for the ack-bit issue, but they confirm the platform is well within the population that was deployed through 2014 before being superseded by the S7-300 successor ET 200SP CPU and the WinCC Comfort/Advanced line under TIA Portal. Operators on S7-300 firmware V3.3 running WinCC Flexible 2008 SP5 report the same issue, so the symptom is platform-agnostic across the S7-300 family.

3. Anatomy of the WinCC Flexible Alarm Bit Architecture

3.1 Trigger Tag and Acknowledgment Tag Pairing

Every discrete alarm in WinCC Flexible is configured with two tag associations:

• Trigger tag (Ereignisbit / Triggerbit) - the bit the PLC sets to declare "this condition is active". WinCC Flexible reads the bit on every acquisition cycle and, on a 0 → 1 edge, generates the alarm.
• Acknowledgment tag (Quittierbit) - the bit the HMI writes back to indicate the alarm has been acknowledged. WinCC Flexible sets this bit to "1" on operator ACK and clears it when the trigger returns to "0".

Both tags are configured in the alarm editor under Properties → Trigger and Properties → Acknowledgement. The default behavior is that a single bit position in each tag is reserved per alarm. The bits are coupled positionally: bit 0 of the trigger word controls the ack bit at position 0 of the ack word.

3.2 The Internal State Machine That Touches Bits You Did Not Set

Inside the WinCC Flexible runtime, every discrete alarm has four state variables:

On every HMI acquisition cycle, the runtime executes the following logic for each bit position n in the trigger word:

1. Read T(n) from PLC image.
2. If T(n) = 0 and A(n) was previously 1 → alarm is "going", clear A(n), clear K(n), clear H(n) (write "0" to ack bit n).
3. If T(n) = 1 and A(n) was previously 0 → alarm is "coming", set A(n) = 1, K(n) = 0, write H(n) = 0 to ack tag.
4. If T(n) = 1 and A(n) = 1 and K(n) = 0 → alarm is "coming, not yet acknowledged"; H(n) remains "0".
5. If T(n) = 1 and A(n) = 1 and K(n) = 1 → alarm is "acknowledged"; H(n) = "1".
6. After processing all n, the runtime writes the entire ack tag word back to the PLC, including the H(n) values for alarms that are inactive (T = 0) but were once active in the past and are now in the K = 1 "was acknowledged, has since gone" state.

Step 6 is the source of the surprise. A bit that the PLC left at "0" is overwritten by "1" because the alarm's internal state K is still "1". WinCC Flexible does not differentiate "this alarm went away while acknowledged" from "this alarm is currently active and acknowledged" when it projects the ack word back to the controller - it writes the current H value for every bit regardless of T.

3.3 What the Engineer Sees in the PLC

In the original report, the user configures:

• MW12 → deviceNr1AlarmTriggerTag (bits M11.0 through M11.3 for four alarms)
• MW14 → deviceNr1AlarmHMIAckTag (bits M13.0 through M13.3)

Sequence reproduced from the field report:

1. Operator boots the panel. All trigger bits are 0, all HMIAck bits are 0. The runtime initializes the internal state K(0..3) = 0.
2. PLC sets M11.0 = 1 (alarm 1 active). WinCC Flex transitions: A(0) = 1, K(0) = 0, H(0) = 0. The bit M13.0 stays at "0" in the PLC.
3. Operator presses ACK on alarm 1 in the alarm view. WinCC Flex sets K(0) = 1 and writes H(0) = 1, so M13.0 = 1.
4. Trigger M11.0 goes back to 0 (alarm 1 gone). WinCC Flex clears A(0) = 0, K(0) = 1 (preserved for the "goes" event so the operator still sees the historical line), H(0) = 0. The bit M13.0 is written to "0".
5. PLC later sets M11.1 = 1 (alarm 2 active). The runtime re-evaluates the entire word. It discovers that the internal K(0) = 0 (the alarm is no longer in the "was-acknowledged, has-since-gone" cache because the previous "goes" event cleared it), so it considers alarm 1 to be a fresh, never-acknowledged inactive alarm. It then writes H(0) = 1 because K(0) = 0 and the runtime is mirroring the "acknowledged" default. The PLC therefore sees M13.0 = 1 even though no operator has touched alarm 1.

This is what the user observed: "WinCC Flex automatically sets HMIAck bits for alarms which are not active (trig bit 0) or active and was acknowledged (and Ack bit reseted to 0 later, so such alarms get double acknowledge)". The phrase "double acknowledge" is the integrator's interpretation of the redundant 0 → 1 transition on a bit that the PLC had previously written to 0.

4. Root Cause Analysis

4.1 Shared Image Word Semantics

The HMI ↔ PLC communication in WinCC Flexible 2007 uses a memory image that is refreshed as a whole word (or doubleword, depending on tag type). Discrete alarm bits are not exchanged individually; they are exchanged as packed arrays. The runtime has no concept of "I should not touch this bit because the PLC wrote it". It treats the ack tag as its own scratch memory and projects the current internal acknowledged state of every alarm onto that scratch.

4.2 Ack-Bit Re-Initialization at Panel Restart

On cold start of the panel, the internal K state is initialized to 0 for every alarm. This means that at the very first cycle after a panel restart, all HMIAck bits are written to "0". If the PLC was using those bits to drive downstream logic, the logic will see them fall to 0 momentarily, then settle to 1 the next time a trigger bit is processed for an alarm that was already acknowledged before the restart. The standard mitigation is to set every HMIAck bit to 1 in OB100 / OB101 / startup logic so the panel sees a coherent initial state. This is exactly the "little dirty trick" the experienced integrator suggested in the discussion.

4.3 Why Modifying HMIAck Bits in the PLC Makes It Worse

If the PLC writes HMIAck bits during runtime, the panel's next acquisition cycle will overwrite them, which means the PLC's writes are silently lost. This generates race conditions and is the most common cause of "phantom" acknowledgments. Siemens technical support explicitly states that HMIAck bits must not be modified by the PLC program. The PLC-owned handshake is the Acknowledgement PLC tag, not the HMIAck tag.

5. The Correct Architecture: PLC Acknowledgement Tag

WinCC Flexible 2007 supports a second acknowledgment path called "Acknowledgement PLC" (German: Quittierung SPS). The path is configured per discrete alarm in the alarm editor:

1. In the project tree, select Alarms → Discrete Alarms.
2. Open the alarm whose behavior is wrong, switch to Properties.
3. On the Acknowledgement tab, change the "Acknowledgement tag" setting to a tag that the PLC will write to acknowledge the alarm. The default is the HMI-owned tag (the one that is being clobbered). Switch it to "PLC-owned" or to a tag that the PLC controls.
4. Compile and download.

The PLC-owned acknowledgment tag is a single bit per alarm that the panel reads. When the PLC writes "1" to the bit, WinCC Flexible treats the alarm as acknowledged (provided the alarm is configured with the Acknowledgement by PLC property in the alarm class). The PLC never has to read this bit back - the bit is one-way from PLC to panel.

6. Step-by-Step Configuration Procedure

6.1 Prerequisites

• WinCC Flexible 2007 SP5 with HF7 (or WinCC Flexible 2008 SP5) installed on the engineering station.
• STEP 7 V5.5 SP4 (or STEP 7 V5.4 SP5) for the S7-300 project. TIA Portal V13 SP1 is acceptable only if the HMI project is being migrated.
• Active connection between the engineering station and the panel (Ethernet or USB-PPI for OP/TP 177, Ethernet for MP 277/377).
• Live S7-300 program accessible for online testing (MPI cable, PROFIBUS, or Ethernet CP).

6.2 Reconfigure the Alarm to Use PLC Acknowledgment

1. Open the WinCC Flexible project.
2. Navigate to Alarms → Discrete Alarms.
3. Select alarm 1 (deviceNr1Alarm1) and open Properties.
4. On the Trigger tab, confirm the trigger tag is deviceNr1AlarmTriggerTag and the bit is 0.
5. On the Acknowledgement tab, remove the existing Acknowledgement tag (the one named deviceNr1AlarmHMIAckTag). If the dialog forces a tag selection, set it to an internal dummy tag the PLC will never use.
6. Check the "Acknowledgement by PLC" option and bind it to a new tag, e.g. deviceNr1AlarmPLCAckTag at bit position 0. Repeat for alarms 2 through 4 (bit positions 1 through 3).
7. Repeat for the HMI-owned tag deviceNr1AlarmHMIAckTag: keep it in the project if the PLC code reads it for visualization, but document that its content is owned by the HMI and must not be relied on for control logic.

6.3 Update the S7-300 Program

Sample STL / LAD code in OB1 to acknowledge alarm 1 from the PLC (for example, when an external reset button is pressed):

// STL example, OB1, network 10
      U     "HMI_ExtAck_Button"     // operator pushbutton input
      FP    "HMI_ExtAck_Flag"        // one-shot edge memory
      SPBN  NOA1
      S     "deviceNr1Alarm1PLCAck"  // bit in PLCAckTag, position 0
      S     "deviceNr1Alarm2PLCAck"  // bulk-ack if desired
      S     "deviceNr1Alarm3PLCAck"
      S     "deviceNr1Alarm4PLCAck"
NOA1: NOP   0

// Clear the bit after one HMI cycle so the next press can re-acknowledge
      UN    "deviceNr1Alarm1Trig"    // bit in trigger tag, position 0
      R     "deviceNr1Alarm1PLCAck"  // release ack when trigger falls

If the project uses a structured FB for alarm handling, the PLCAck bit can be set with a positive edge and cleared when the trigger falls. The bit does not need to be read back; the panel consumes it on its next acquisition cycle.

6.4 Compile, Download, Test

1. Compile the WinCC Flexible project. Verify no warnings of the form "ack tag not connected" or "trigger tag size mismatch".
2. Download the runtime to the panel.
3. In STEP 7, download the S7-300 program (or do a delta download if only DB/MB changed).
4. Online: force deviceNr1Alarm1Trig (M11.0) to "1". The alarm should appear in the alarm view as unacknowledged. The HMIAck bit M13.0 should remain 0.
5. Set deviceNr1Alarm1PLCAck to "1" from the PLC. The alarm view should mark the alarm as acknowledged. The HMIAck bit M13.0 should now go to 1.
6. Reset M11.0. The alarm disappears. M13.0 should go to 0.
7. Force M11.1. The HMIAck bit M13.0 should remain at 0. The bit M13.1 (ack for alarm 2) should be controlled only by alarm 2's state, not by alarm 1's state.

7. Verification Procedure

To certify that the installation is correct, perform the following acceptance test and record the results in the FAT/SAT report.

7.1 Static Verification

7.2 Dynamic Verification

7.3 Online Monitoring Tips

• Open a watch table in STEP 7 containing MW12, MW14, and the PLCAck word. Force a slow acquisition cycle (1 s) on the panel to make transitions visible.
• Use the WinCC Flexible online diagnostics (Tools → Tasktray icon → Diagnostic) to see the alarm event log. Confirm that every "comes" event has a matching "goes" event and a matching "ack" event if the alarm class requires acknowledgment.
• Capture the HMI tag image over PROFIBUS with a bus analyzer if discrepancies persist. The CP 343-1 / CP 343-1 Lean can be put into diagnostic mode in STEP 7 to log every read/write of the ack tag.

8. Edge Cases and Field-Proven Caveats

8.1 Multiple Alarms in One Tag Word

The original failure mode is most visible when several alarms share a single trigger word. If possible, use one trigger bit per alarm in a separate word (or even a separate tag) so that the panel image rebuild does not drag in unrelated bits. This is not a fix - the same bit-packing happens internally - but it isolates the visual confusion for the operator who sees the alarm view.

8.2 Mixed Acknowledgment Classes

WinCC Flexible allows per-alarm configuration of "must be acknowledged" and "no acknowledgment required". Alarms of the "no acknowledgment" class do not generate a HMIAck bit at all; their H(n) is permanently 0. If the project mixes the two classes within the same trigger word, only the "must be acknowledged" bits are written back. This can also look like a phantom write to the engineer reading the tag.

8.3 Operator Action Log

The "Acknowledgement PLC" path does not record an entry in the operator action log. The log only sees operator-driven acknowledgments. If traceability of PLC-driven acknowledgments is required (for FDA 21 CFR Part 11 or similar), the PLC must generate its own audit record by setting the PLCAck bit through a dedicated FB that also writes a timestamp to a log DB.

8.4 Restart of the CPU While the Panel is Running

If the S7-300 CPU goes to STOP and back to RUN, the panel's internal alarm state is not cleared. The panel will re-acquire the trigger word and re-evaluate every alarm. PLC-owned PLCAck bits are not affected because they live in the PLC, but the panel will re-write the HMIAck word. The PLC program must tolerate the resulting transitions on the HMIAck tag for one or two HMI cycles.

8.5 HMI Tag Length Mismatch

A common commissioning error is to declare the trigger tag as a word in the PLC but as a byte in the panel, or vice versa. The runtime then mismaps the bit positions and triggers a totally unrelated alarm. Always declare the same length (Word = 16 bits) and the same start address on both sides. In WinCC Flexible, the tag's Length field in Properties → General must be set to "Word".

8.6 S7-300 Work Memory Limit

The CPU 317-2 has 256 KB of work memory. A large alarm configuration with hundreds of discrete alarms and PLC acknowledgment bits can consume noticeable DB space. With the S7-300, every bit used for handshake still costs 1 bit in the bit memory area or in a DB, plus the panel-side symbolic tag. Plan at least 16 bits of bit memory per device with four alarms. If the device count exceeds 256, switch to DB-based tags to keep M area free for other uses.

9. Migration Considerations: WinCC Flexible to TIA Portal WinCC Comfort/Advanced

Projects that started on WinCC Flexible 2007 are routinely migrated to TIA Portal V13 SP1 / V14 / V15 / V16 / V17 / V18 over the panel's lifecycle. The migration tool is WinCC Migration Tool (formerly ProSave migration), shipped with the TIA Portal. The migration preserves the alarm structure, but the bit semantics change subtly:

• In TIA Portal, the "HMI acknowledgment tag" is renamed "HMI acknowledgment variable" but behaves identically - it is still owned by the panel and must not be written by the PLC.
• The "PLC acknowledgment tag" is renamed "PLC acknowledgment variable" and remains a one-way bit from PLC to panel.
• The bit position alignment is no longer automatic. In TIA Portal, the alarm editor binds each alarm to a specific bit of the trigger and ack variables, and the project must declare the same bit on both sides explicitly. Migrated projects often have the bits misaligned by one position; verify each alarm's bit after migration.
• WinCC Comfort/Advanced adds the option to acknowledge an entire alarm class by setting a single class-level PLC variable. This is convenient for large plants but requires the alarms to share a class.

10. Related Approaches on Other Vendor Platforms

Engineers who also maintain equipment on other HMIs will recognize the same handshake problem across vendors. The general pattern is universal: the panel owns an acknowledgment feedback bit, and the PLC must not write it. The recommended workaround in every case is a one-way PLC-to-panel bit reserved for "PLC wants to acknowledge". Schneider Electric's EcoStruxure Operator Terminal Expert and Vijeo Designer follow the same pattern; the official Schneider FAQ FA282548 documents the ScriptFunction call AcknowledgeAlarms that achieves the equivalent of the WinCC Flexible "Acknowledgement PLC" mechanism. Ignition by Inductive Automation implements the same handshake via the system.alarm.acknowledge Python/Jython function and a dedicated PLC-side boolean tag. Unitronics UniLogic exposes the same concept as the AckTag in the alarm configuration. In every case, the rule is the same: do not read the panel-owned ack bit for control logic; do not write it from the PLC; use a PLC-owned one-way bit for the handshake direction you need.

11. Diagnostic Matrix: Symptom → Cause → Fix

12. Long-Term Best Practices

1. One device per trigger word. Avoid mixing unrelated alarms in a single word; the diagnostic value of separation outweighs the few bytes of M memory saved.
2. Reserve one PLC-owned ack word per device. Name it consistently (...PLCAckTag) and document it in the HMI tag table.
3. Use symbolic tags, not absolute addresses. In the S7-300 program, use a global symbol table entry like deviceNr1Alarm1PLCAck rather than M 13.0. M-area bits are easy to overwrite by mistake in another FB.
4. Document the bit ownership in the project documentation. Add a comment in the alarm editor: "HMIAck bit M13.0 is HMI-owned; PLC must not write. Use PLCAck bit DBxx.DBX0.0 to acknowledge."
5. Test the cold start, warm restart, and CPU STOP/RUN paths separately. The three paths exercise different code paths in the runtime and can each reveal a forgotten edge case.
6. Plan migration to TIA Portal at the next major shutdown. WinCC Flexible 2007 / 2008 is no longer actively maintained. Siemens' product lifecycle (PCL) classifies WinCC Flexible 2007 as out of general availability; spare-part and update support ended several years ago. The migration to WinCC Comfort/Advanced under TIA Portal V18 is straightforward for projects of this size.

13. Summary

The phantom HMIAck transitions in WinCC Flexible 2007 on S7-300 CPU 317-2 are an architectural consequence of packed-bit image exchange and a runtime that owns the ack tag. The fix is not to fight the runtime by writing the HMIAck bits from the PLC, but to switch to the dedicated PLC-acknowledgement tag. With that one reconfiguration, the spurious transitions stop, the operator-acknowledged feedback is no longer corrupted, and the PLC gains a clean one-way handshake for its own acknowledgment decisions. The same pattern - HMI-owned feedback bit, PLC-owned control bit - is the universal solution across vendors and survives migration to TIA Portal WinCC Comfort/Advanced without modification.