PIDConL MsgAckn1/MsgAckn2 Zero: Feature Bit 22 Fix for PCS 7 APL

Problem Overview

When commissioning a PIDConL controller block from the Siemens PCS 7 Advanced Process Library (APL) V7.1 SP5, the message-acknowledgement status outputs MsgAckn1 and MsgAckn2 remain permanently 0, even though the corresponding alarms are visible in WinCC, can be acknowledged by the operator, and re-trigger correctly. The auxiliary error flags MsgErr1 and MsgErr2 likewise never leave 0. The HMI side shows correct alarm lifecycle behaviour, but the controller block itself never propagates the ACK_STATE from the internal ALARM_8P instances back to the application program.

This symptom is independent of how the controller is wired in the CFC chart: signal-conditioning inputs (PV_IN, SP_IN, SP_OP), the operator-permitted bits, and the output-side LMN path all behave normally. Only the two message-status words and the two message-error words are frozen at zero, which breaks any external logic that branches on whether an alarm has been acknowledged (for example, suppression of bumpless transfer during an active alarm window).

The symptom is well-documented in PCS 7 installations running APL 7.1 SP5 where the PIDConL is called exclusively from a time-driven organisation block such as OB35, and where OB1 is left empty (or contains only the default warm-restart OB100 logic). The alarm pipeline through WinCC works because the ALARM_8P block always reports its ACK_STATE to the OS via the configured message path. The controller-block outputs only reflect that state when an explicit update mechanism is enabled.

Affected Products and Versions

The behaviour is documented in the BRAUMAT / PCS 7 Library V7.1 description and the English-language companion document. The SIMATIC PCS 7 Process Control System APL V9.0 manual keeps the same MsgAckn1/MsgAckn2 output naming convention, confirming that the Feature-Bit interpretation has remained stable across major releases.

Root Cause

The PIDConL block encapsulates one CTRL_PID arithmetic core plus up to two ALARM_8P message blocks for the MsgLock1/MsgLock2 limit-message logic. Internally, the two MsgAckn outputs are wired to the ACK_STATE output of the embedded ALARM_8P instances, and MsgErr1/MsgErr2 are wired to the MSG_ERR output of the same instances.

Whether those internal ACK_STATE / MSG_ERR signals are actually copied out to the visible block outputs is gated by Feature.Bit22 of the PIDConL instance, where the Feature word is a 32-bit configuration input exposed on the block faceplate:

When Feature.Bit22 is 0 (the APL default), the MsgAckn1, MsgAckn2, MsgErr1, and MsgErr2 outputs are written only when an event in OB1 (the cyclic free-running OB) touches the block. Because modern PCS 7 installations run almost all of their logic inside OB35 (the 100 ms time-of-day interrupt) and leave OB1 essentially empty, the cyclic refresh of those four outputs never happens. The ALARM_8P instances still report their ACK_STATE to WinCC via the message path, but the value is not copied into the controller block's outputs.

This is why the symptom is invisible on the HMI but breaks any CFC/SFC logic that reads MsgAckn1 or MsgAckn2. It also explains the operator observation that "the ACK_STATE only updates after 10–15 seconds": that latency is exactly the period between two OB1 passes (or the next S7 communication cycle that incidentally reads the block) — not the OB35 period.

Solution — Enable Feature Bit 22

1. Open the CFC chart that contains the PIDConL instance in the PCS 7 Engineering Station.
2. Right-click the PIDConL block → Open Properties (or press Alt+Enter on the block faceplate).
3. Switch to the Inputs/Outputs tab and locate the Feature input (DWORD, 32 bits, default value = 0 in newly inserted instances).
4. Compute the new DWORD value: Feature = Feature OR (1 << 22). For a default value of 0 this gives 16#00400000. If other bits are already set (for example Bit0 = 1 to enable setpoint tracking, or Bit8 = 1 to enable bumpless transfer at start-up), keep them and add 16#00400000 to the existing value.
5. Click Apply, close the dialog, and recompile the chart (Chart > Compile > All).
6. Download the program changes to the AS in RUN mode (CFC supports online download of parameter changes without CPU stop).
7. Observe the MsgAckn1/MsgAckn2 outputs in a watched CFC instance table, or in the block-icon faceplate via WinCC, and confirm the value toggles to 1 after acknowledging the alarm on the OS.

The Feature input can also be set dynamically through CFC interconnections, although this is rarely done because Bit22 toggling changes the CPU load profile mid-cycle. For permanent behaviour, set it as a constant value on the block.

Alternative — Activate OB1 Refresh Path

If Bit22 must remain 0 to preserve CPU headroom (typical for very large PCS 7 plants with hundreds of PIDConL instances and a tight OB35 cycle), the alternative is to ensure the PIDConL instance is called from OB1. The library implements a low-cost refresh of the four status words on the OB1 pass, which does not have the full per-cycle cost of the Bit22 path.

1. In the S7 program editor, open the OB1 source.
2. Insert a CFC-in-OB call: from the menu Insert > Block Call > From CFC Chart, browse to the chart containing the PIDConL instance, and insert a call to that chart family.
3. Compile and download. Note that this path introduces the MsgAckn* latency observed in the field (10–15 seconds in typical configurations), because OB1 free-running cycle time is not deterministic and is often dominated by the OB35 interrupt.
4. Use this option only when read-consumers of MsgAckn* can tolerate that latency (for example, slow trend annotations or operator-information blocks).

Trade-off summary:

Verification Procedure

After enabling Feature.Bit22, verify the fix end-to-end:

1. In the CFC online view, force the controlled variable PV just outside the configured MsgLock1 high limit and confirm the alarm appears in the WinCC alarm line.
2. Acknowledge the alarm from the WinCC alarm view (click the green checkmark on the unacknowledged alarm row).
3. Watch the MsgAckn1 output in the CFC instance table — it must transition to W#16#0001 within one OB35 cycle (≤ 100 ms).
4. Bring the process back into the limit band so the alarm clears itself; verify MsgAckn1 returns to W#16#0000 on the next alarm clear edge.
5. Repeat for MsgAckn2 by forcing a violation of the second limit (MsgLock2).
6. To validate MsgErr1/MsgErr2, temporarily delete the WinCC message configuration for one of the two ALARM_8P instances (in the OS project editor, mark the message as not generated). The corresponding MsgErr1 or MsgErr2 must then transition to 1, confirming the error-flag plumbing. Restore the message configuration before sign-off.
7. Run an S7-CPU utilization trace for at least 10 minutes and confirm the OB35 cycle time increase is consistent with one extra ALARM_8P.ACK_STATE/MSG_ERR read per PIDConL per cycle. On a CPU 410-5H with 100 controllers and 100 ms OB35, expect a 1–3 ms increase.

Related I/O and Configuration

The SIMATIC PCS 7 Process Control System APL PIDConL I/O manual lists every input and output that interacts with the message-status path. The relevant subset is:

The general ALARM_8P messaging-error semantics are documented in the SIMATIC Process Function Library V3.0 manual, which states that MSG_ERR rises when the message path (configured in the OS project editor) is incomplete, when the AS-OS connection is interrupted, or when the message number has not been generated during compilation.

Performance and Cycle-Time Considerations

Each PIDConL call with Feature.Bit22 set performs two additional accesses to the embedded ALARM_8P blocks (one for ACK_STATE, one for MSG_ERR), plus the implicit internal copy to the MsgAckn1/MsgAckn2/MsgErr1/MsgErr2 outputs. On a CPU 416-3 PN/DP with 100 controllers and OB35 at 100 ms, measured delta is in the 1–3 ms range per OB35 pass; on a CPU 410-5H the absolute impact is similar but represents a smaller percentage of the available cycle budget.

If you are running the AS close to the configured communication load (CPU utilisation > 70 %), audit the change first with the S7 CPU load monitor (PLC > Diagnostics > CPU Load) or PCS 7 Maintenance Station. For plants in the 90 %+ band, prefer the OB1-refresh alternative and accept the higher MsgAckn* latency for non-safety consumers.

Common Pitfalls

• Setting Bit22 only on one of several controllers. Each PIDConL instance carries its own Feature word — there is no global override. Review every controller in the plant that consumes MsgAckn*.
• Forgetting to recompile the OS after a chart change. Although the MsgAckn* values are read internally, an OS recompile is required if you also added or renamed ALARM_8P messages. Without it, MsgErr* may legitimately rise.
• Confusing MsgLock with MsgAckn. MsgLock is an input that suppresses incoming messages; it does not clear MsgAckn*. To reset an acknowledgement state programmatically, drop the relevant limit through MsgLock = 1 and back to 0, then re-trigger the alarm.
• Reading MsgAckn1 bitwise in CFC. The output is a WORD that mirrors ALARM_8P.ACK_STATE. Use the low byte (bits 0–7) as the eight discrete acknowledgement flags of the message instance; do not interpret the high byte.
• Assuming OB100 warm-restart is sufficient. The OB100 path initialises the controller and the message blocks but does not refresh MsgAckn* when Bit22 is 0. Cyclic OB35 / OB1 execution is required.

Quick Reference — DWORD Value for Bit22

Use the CFC online Watch view to read the live Feature DWORD before changing it, so you OR the new bit into the existing mask rather than overwriting the configuration.