Resolving Program_Alarm Flashing on a Steady SIG Input in TIA Portal

The Siemens Program_Alarm (also catalogued as Generate program alarm with associated values) is an extended instruction available in STEP 7 V15.1 and later for S7-1200 and S7-1500 CPUs. The block monitors a Boolean input SIG and raises a program alarm on every detected edge of that signal. When the alarm appears to flash even though the SIG bit remains logically true, the cause is almost always one of the following: a duplicate instance, a momentarily glitching SIG (electrical noise, scan-time aliasing, or an inverted source toggling faster than the PLC scan), or two blocks fighting to acknowledge/modify the same alarm. This article walks through the failure modes, the diagnostic procedure that isolates them, and the corrective patterns that prevent recurrence on production lines that read alarm-ready signals from vision systems, barcode readers, or other digital peripherals.

1. Program_Alarm Instruction Overview

The Program_Alarm instruction sits in the Extended instructions > Alarms folder of the TIA Portal program editor. It is the successor of the legacy S7-300/400 SFB33 / SFB34 / SFB35 / SFB36 alarm blocks, and was re-introduced for S7-1500 to support the diagnostic buffer integration required by PROFINET, WinCC, and the HMI alarm subsystem.

Each call instance is associated with a single alarm in the HMI/SCADA. The instruction writes an alarm record to the CPU diagnostic buffer and broadcasts a program-alarm message via the S7 communication channel to subscribed WinCC Runtime, Comfort Panel, or third-party OPC UA server. The HMI subsequently toggles between incoming and outgoing entries in the alarm view whenever the block reports a SIG transition.

2. How a "Steady" Signal Can Still Toggle

A trace that displays the SIG bit as constantly high is not, by itself, proof that the input to the Program_Alarm block is constant. Several mechanisms can mask the transition while the bit is being read inside the call site:

2.1 Inverted Source

The original incident was triggered by a camera Ready signal that the engineer used inverted as the SIG. If the camera reports ready with a 0 (low) on its output and the line inverts it to 1 for "camera NOT ready", then any 5–10 ms chatter on the original line (from a PLC-side input filter mismatch, a 24 V supply sag, or a photo-eye ringing) will translate to a high-frequency inverted square wave. The trace window of 1 s/div often hides pulses shorter than 5 ms.

2.2 Input Filter / Debounce Mismatch

S7-1500 digital input modules (e.g. 6ES7521-1BL00-0AB0) default to an input filter of 3.2 ms when wired to a 24 V source. If the source has a faster transition, the filter hides it. The inverted signal inside the PLC, however, can still see the 0→1 of the filtered result and the 1→0 of the next filter window, creating one rising edge and one falling edge every filter period.

2.3 Multiple-Call Aliasing

Placing Program_Alarm in more than one network and driving both networks from the same SIG tag is a common copy/paste error. The HMI view then alternates between the two instances. Engineers see "the alarm" flicker between two messages or two colours. The original author resolved the issue by removing a second instance that was also trying to update the alarm — see Section 5.

2.4 OB1 vs. Cyclic OB1x vs. Watchdog

If the block is called in OB35 (cyclic interrupt, 100 ms default) but the SIG tag is updated in OB1 at 2 ms, every 100 ms cycle the block samples the most recent SIG value. If the upstream logic writes SIG 0, then 1, then 0 within the same 100 ms window, the call sees only the last write and may incorrectly report an edge that did not exist in OB1. Configure consistent OB priorities and pair SIG writes with the calling OB.

3. Symptom Matrix

4. Prerequisites for Diagnosis

1. STEP 7 V16 or later with the S7-1500 CPU's Program_Alarm extended instruction installed. Compatibility matrix: Siemens ID 109747174.
2. Online connection to the PLC (TCP/IP, PROFIBUS, or PROFINET) with read/write rights.
3. Trace functionality licensed on the CPU (S7-1500 firmware V2.0+; trace was introduced in V2.0 and the configurable trigger conditions were extended in V2.6). Firmware is downloadable from Siemens Industry Online Support.
4. Project source (.ap16 or later) that contains all blocks, not a compiled library copy.
5. Access to the physical signal at the digital input module's screw terminal or spring terminal to scope the source.

5. Step-by-Step Diagnostic Procedure

1. Project-wide search for the alarm ID. In TIA Portal press Ctrl+Shift+F, type the EV_ID value (e.g. W#16#0001), and check Search in: All objects. Any second occurrence is the duplicate instance to remove.
2. Enable a PLC trace on the SIG tag. Use Traces > New trace, set sample period to 1 ms, trigger on a 1→0 transition of SIG, and record 2000 samples. If a transition shorter than 5 ms appears, the source is glitching.
3. Scope the physical input. Connect an oscilloscope to the camera's Ready terminal and verify the actual waveform. Pay particular attention to the rise/fall time, ringing, and any common-mode noise from the 24 V supply.
4. Check the digital input filter. In Device configuration > DI module > Inputs > Channel template, set the input filter to 0.5 ms and re-test. If flashing stops, the source is noisy; the filter needs to be widened or the source debounced.
5. Inspect cyclic OB priority. Open the program blocks tree, expand System blocks > Program blocks, and check whether Program_Alarm is called in OB1, OB35, OB82, or a custom OB. Move the call to OB1 if it is in a cyclic interrupt, or vice versa, and observe.
6. Look for any code that reinitialises the instance DB. A line such as "Program_Alarm_DB".SIG := FALSE; "Program_Alarm_DB".SIG := TRUE; (or any structured reinit using the := assignment on internal tags) forces a synthetic edge on every PLC restart or HMI recipe change. Replace with edge detection (R_TRIG / F_TRIG).
7. Validate via offline simulation. Use PLCSIM (S7-1500 firmware ≥ 2.0) or PLCSIM Advanced to drive the SIG tag with a forced constant 1 and confirm whether the HMI alarm view still flashes. If the simulation is clean, the issue is in the physical wiring or external device.

6. Solutions by Root Cause

6.1 Remove the Duplicate Instance

The original post was resolved exactly this way: a second instance of the same alarm was modifying the alarm record. Once the redundant block is deleted (or its ID/EV_ID made unique), the flashing stops. Validate uniqueness of the pair (ID, EV_ID) across the entire program and the assigned HMI alarms; the values must be unique per PLC.

6.2 Debounce the Inverted Source

For an inverted camera-ready signal that is known to chatter, add a TON/TOF debounce or use the standard Edge detection pattern:

// Debounced edge detector for the camera-ready signal
// Input:  "cameraReadyRaw" (BOOL, 24 V input from the camera)
// Output: "cameraReadyFilt" (BOOL, debounced 50 ms)

IF "cameraReadyRaw" THEN
    IF "debounceTimer".ET < T#50ms THEN
        "debounceTimer"(IN := TRUE, PT := T#50ms);
    END_IF;
    IF NOT "cameraReadyFilt" AND "debounceTimer".Q THEN
        "cameraReadyFilt" := TRUE;            // rising edge qualified
    END_IF;
ELSE
    "debounceTimer"(IN := FALSE, PT := T#50ms);
    "cameraReadyFilt" := FALSE;               // fast clear on release
END_IF;

// Drive the alarm with the falling edge of the filtered, INVERTED signal
// (camera ready low = alarm condition high)
"cameraNotReady" := NOT "cameraReadyFilt";

IF "cameraNotReady" THEN
    "Program_Alarm_DB"(SIG := TRUE,
                       ID  := W#16#0001,
                       EV_ID := DW#16#0000_0001);
ELSE
    "Program_Alarm_DB"(SIG := FALSE,
                       ID  := W#16#0001,
                       EV_ID := DW#16#0000_0001);
END_IF;

This pattern guarantees that a true chatter is absorbed by the 50 ms filter and the alarm is called only with the final, debounced value.

6.3 Match the Input Filter

If the source device is rated for 5 ms minimum pulse width, set the S7-1500 DI module's input filter to 5.0 ms or higher. The available values are typically 0.05 ms, 0.1 ms, 0.5 ms, 1.0 ms, 3.2 ms, 10 ms, 20 ms. On the ET 200SP, the values are exposed in Properties > Input 0..7 > Input filter.

6.4 Use Associated Values for Multi-Source Alarms

If two sources legitimately need to update the same alarm, do not use two Program_Alarm instances with the same EV_ID. Instead, route both sources through a single instance and pass the source identifier as SD_1. The HMI alarm text can then show the source name in the runtime. This avoids the duplicate-instance race that produces flashing.

6.5 Replace Program_Alarm with a S7-1500 SysLog or "WRMSG" Pattern

For modern projects on firmware V2.5+, consider WRMSG (Write user alarm to diagnostic buffer) plus a HMI alarm class. The WRMSG instruction is non-edge-sensitive, latches the alarm until explicitly cleared, and never produces the 0→1 / 1→0 toggling that causes flashing. See Siemens TIA Portal V20 Program_Alarm reference for the deprecation roadmap.

7. Verification Procedure

1. After applying the fix, force the SIG tag TRUE and observe the HMI alarm view for 5 minutes; no flashing should occur.
2. Force SIG FALSE and then TRUE manually (or via PLCSIM) to confirm a single incoming/alarm event and a single outgoing event are logged in the WinCC alarm log.
3. Check the CPU diagnostic buffer via Online & diagnostics > Diagnostics buffer. Exactly one "Program alarm <EV_ID> incoming" and one "… outgoing" entry should appear per true edge.
4. Repeat the test with a 10 ms signal pulse train at the DI terminal. The alarm should appear once, not ten times.
5. Use the Project-wide cross-reference on the alarm ID to confirm only one Program_Alarm call remains in the program.
6. Save the project, compile, and download. Re-test after a power-cycle.

8. HMI / SCADA Interaction Details

On a Comfort Panel (TP1500, TP700, KTP1200) or WinCC Runtime Advanced, the alarm view consumes the ALARM_S records broadcast by the CPU. Each incoming transition at the SIG input creates an incoming record; each opposite transition creates an outgoing record. The visual flash is generated by the HMI when the incoming and outgoing states are interleaved rapidly. Configuring the alarm class with the flash background property in HMI alarms > Properties > Appearance can either hide the flash (set Flash background = No) or make it more visible. Use this for presentation tuning only — the flash is a symptom, not a configuration defect.

For WinCC Professional / Unified, the alarm subscription is OPC UA. The flashing is similarly driven by status changes, but the source is the ConditionState field. If you see flashing in WinCC RT Professional but not in the CPU diagnostic buffer, the issue is in the HMI tag subscription polling rate, not in the CPU program.

9. Firmware and Version Notes

10. Related Patterns and Anti-Patterns

• Anti-pattern: Calling Program_Alarm in two networks with the same EV_ID and different SIG sources. Causes the flashing observed in the source case.
• Anti-pattern: Using a NOT coil before the call site. SIG must be a clean Boolean; use a separate tag := NOT source line above the call.
• Anti-pattern: Driving SIG from a global HMI tag without an edge gate. The HMI operator can flip the tag from the screen, producing one extra transition per click.
• Best practice: Drive SIG with a deterministic PLC tag, debounced, edge-qualified, and routed through a single call site.
• Best practice: Reserve a contiguous EV_ID range per area (e.g. W#16#0001–W#16#0FFF for alarms, W#16#1000–W#16#1FFF for warnings) and document the assignment in a project-wide table.
• Best practice: For S7-1500 firmware ≥ V2.5, prefer WRMSG with severity classes for any alarm that must be latched, paged out, or re-acknowledged by the operator.

11. Troubleshooting Matrix

12. Summary

The Program_Alarm flashing with a steady SIG is almost never caused by a bug in the CPU firmware; it is caused by logic that the CPU is faithfully reporting. A duplicate Program_Alarm instance, an inverted source that is ringing below the trace's resolution, or a SIG write that bypasses edge detection are the three most common culprits. The original case was the first: a second block was modifying the same alarm ID. Removing that block restored the expected single-event behaviour. Apply the diagnostic steps in Section 5 in order, validate with the verification steps in Section 7, and refer to the Siemens TIA V20 documentation linked throughout for firmware-specific behaviour.

FAQ