Resetting Minimum Weight Alarms in Siemens STEP 7 LAD

Problem Overview: Latching Minimum-Weight Alarms

A common bottleneck in weigh-and-dump packaging lines is a SCADA "minimum weight" alarm that refuses to clear after the operator has corrected the process. The classical symptom is straightforward: the comparator in the PLC confirms that the weight has risen back above the configured minimum, yet the alarm tile in the HMI stays red and the line will not advance to its validate-and-dump state. Operators then have to enter the SCADA, lower the threshold below the live weight, clear the alarm, manually add the missing mass with a shovel, and re-validate.

This article is a field guide for the maintenance engineer who has been asked to remove that workaround. It covers three LAD implementations in Siemens STEP 7 that allow the alarm to be acknowledged or to self-clear when weight recovers, without ever lowering the configured minimum weight. The first pattern is a one-network conditional auto-reset. The second is a latched alarm with operator acknowledgement. The third is a cycle-based re-arm. All three are written in ladder (KOP) so they drop into an existing project with no FBD/ST rework.

How the Existing Comparison Logic Works

The baseline code described in the field is one rung containing a real-less-or-equal compare and a coil that drives the alarm tag that the SCADA polls. A minimal reconstructed version looks like the following:

Network 1  "Min weight alarm source"
  |    DBW_SCADA_MinWeight (REAL)    DBW_BasculeWeight (REAL)
  |----[ ]----------------------------[CMP <=R]-------------------( "Alarm_WeightLow" )|

Parameter map for the baseline rung:

The compare result drives the alarm tag directly. The rung is unconditioned, so the output tracks the comparison in real time. As long as the load-cell weight is at or below the SCADA minimum, the tag is TRUE and the alarm is visible in the HMI. The moment the weight climbs above the minimum, the tag goes FALSE. On its own, this should clear the alarm — but in practice the alarm does not clear. The next section explains why.

Why the Alarm Will Not Clear

Three things in the typical stack can latch the alarm so the operator has to drop the SCADA minimum to clear it:

1. SCADA-level latching. In WinCC, TIA Portal HMI, and most SCADA packages, alarms are configured with a "come" class and a "go" class. If the alarm class is set to Come + Acknowledge with a status that only resets on operator action, the alarm stays in the active list until an operator presses the Acknowledge key, regardless of the PLC tag state. The PLC clearing the tag only de-energizes the input; the HMI alarm row keeps its red state.
2. Edge-triggered alarm generation in the HMI. Some HMI alarm wizards use the rising edge of the trigger tag. If the tag toggles rapidly near the threshold (load-cell noise, vibration during a partial fill, the comparator result flutters), the alarm is re-armed before it has a chance to clear. The operator sees a perpetual red tile.
3. PLC-side latch bit that is never reset. Less common, but the symptom matches a PLC code path that sets an Alarm_WeightLow_Latched BOOL on the falling edge of the compare and only resets it from a SCADA "Reset min-weight alarm" button that is never wired.

All three failure modes are solved with a single architectural choice: hand the alarm tag a clean, debounced, edge-evaluated, operator-acknowledgable source. The following sections show how to do that in LAD.

Edge Detection in STEP 7 Ladder Logic

Edge detection is the cornerstone of the fix. The technician's instinct to put a flank after the comparator is the right one, but the way you wire the flank depends on the platform. Siemens ships two families of rising-edge operators in LAD.

Classic STEP 7 (S7-300 / S7-400) FP Instruction

In STEP 7 classic, edge detection is implemented with a FP (Flank Positive) coil assigned to a BOOL, and a hidden bit (the edge memory bit) that you must allocate in a static DB, instance DB, or as a temp marker. The most robust pattern in classic STEP 7 is:

Network 1  "Edge detect: weight crossed ABOVE min"
  |    "Compare_OK_Real"              "EdgeM_OK_Real"  "EdgeM_OK_Real_Helper"
  |----[ ]----------------------------(FP)--------------------|
  |                                                              |
  |    "Compare_OK_Real"                                          |
  |----[P]---------------------------------------------------( "Edge_WeightAboveMin" )|

Two equivalent wirings are shown: an explicit FP coil with helper bit, and a [P] rising-edge contact that the LAD/FBD editor inserts in the comparison rung. The [P] contact form is shorter but uses an implicit edge memory bit that the compiler allocates for you. Both produce a one-scan TRUE pulse on the transition from below-min to above-min.

TIA Portal (S7-1200 / S7-1500) POS Contact and R_TRIG

In TIA Portal, the modern S7-1200/1500 CPUs give you three equivalent options:

• --|P|-- rising-edge contact (negated form --|N|--). Implicit, identical in behavior to classic [P].
• R_TRIG function block from the "Bit logic operations" palette. Has explicit CLK input and Q output; edge memory is held in the instance DB of the FB call.
• Negated form: F_TRIG for the falling edge (weight re-crosses below minimum — useful for re-arming).

Network 1  "R_TRIG: weight just crossed above min"
  |
  |    "Compare_WeightAboveMin"                                 "R_TRIG_DB".Q
  |----[ ]------------+--------+--- ??? ---+---( )---|
  |                          |              |
  |                          |    R_TRIG    |
  |                          +---[CLK]-(Q)--+
  |
  Network 2  "Result"
  |
  |    "R_TRIG_DB".Q
  |----[ ]----------------------------------------( "Edge_WeightAboveMin" )|

Drop the R_TRIG instance DB into a project-global data block (or a multi-instance inside a wrapper FB) so the helper bit is preserved across scans. If the instance is a local temp, the edge memory is undefined between cycles and the contact chatters.

Platform Comparison

Pattern A: Conditional Auto-Reset

The minimum change required to remove the operator's "lower threshold to clear" workaround is to invert the alarm polarity: drive the alarm tag from the rising edge of "weight > minimum" instead of from the falling edge of "weight <= minimum". As soon as the load-cell weight climbs above the configured minimum, the SCADA threshold is satisfied, and the alarm can be set or cleared by the PLC automatically. The operator never has to touch the SCADA minimum.

Network 1  "Compare: bascule above configured minimum"
  |    DBW_SCADA_MinWeight            DBW_BasculeWeight
  |----[CMP >=R]------------------------------------------------( "Compare_AboveMin" )|

Network 2  "Pulse on the rising edge of above-min"
  |    "Compare_AboveMin"               "EdgeM_AboveMin"
  |----[ ]-----------------------------(FP)-------------------|
  |
  |    "Compare_AboveMin"               "Edge_WeightRecovered"
  |----[P]-------------------------------------------( )---|

Network 3  "Latched alarm clears when weight is back above min"
  |    "Compare_AboveMin"    "Alarm_WeightLow_Latched"  "Alarm_WeightLow"
  |----[ ]-------------------(R)--------------------------( )---|

Operation: Network 1 runs every cycle. Network 2 fires a one-scan pulse the cycle the weight crosses above the SCADA minimum. Network 3 uses that pulse (or, more simply, the steady-state compare result) to reset the latched alarm bit. The operator presses the SCADA Acknowledge button once the alarm tag is FALSE; the HMI alarm row transitions to acknowledged and out of the active list.

This pattern is the right call when the alarm class in the HMI is configured as non-latching with a "go" qualifier — the PLC clearing the tag is enough to clear the tile. If your HMI still keeps the alarm red, you also need to expose a HMI-side acknowledge step (covered in Pattern B).

Pattern B: Operator Acknowledge Latch

When the SCADA alarm is configured to require explicit acknowledgement, the PLC must hand the operator a clean acknowledge path that is only enabled when the process condition is no longer true. The pattern is an SR flip-flop with three inputs: set, reset (automatic on recovery), and acknowledge (manual from the HMI).

Network 1  "Compare: weight below min triggers set"
  |    DBW_BasculeWeight            DBW_SCADA_MinWeight
  |----[CMP <=R]------------------------------------------------( "Comp_BelowMin" )|

Network 2  "Pulse on the falling edge of compare (just went low)"
  |    "Comp_BelowMin"                "EdgeM_BelowMin"
  |----[ ]---------------------------(FP)-------------------|
  |                                                              |
  |    "Comp_BelowMin"                "Edge_WeightDropped"
  |----[N]-------------------------------------------( )---|

Network 3  "SR latch: set on drop, reset on (ack AND above min)"
  |
  |            +------(S)------+
  |            |               |
  |    "Edge_WeightDropped"     |
  |----[ ]----+               |
  |                            |        "Alarm_Ack_HMI"    "Compare_AboveMin"   "Alarm_WeightLow"
  |                            +---( )--+----[ ]-----------[ ]-------------------(R)---( )---|
  |                                              |                                       |
  |                                              +----[ "Alarm_WeightLow" ]---(R)----+  |
  |                                                                                  |  |
  |                                                                                  +--+

The above is a textual representation; the canonical LAD block is the SR element from the bit-logic palette:

  SET:    "Edge_WeightDropped"            ( --| |-- S )
  RESET1: "Alarm_Ack_HMI" AND "Compare_AboveMin"   ( --| |-- R )
  Q:      "Alarm_WeightLow"               ( Q output of SR )

Behavior:

• When the weight drops to or below the SCADA minimum, Network 2's falling-edge pulse sets the latch. The alarm tag goes TRUE, the HMI alarm row goes red.
• When the operator refills the bascule and the weight climbs back above the minimum, Compare_AboveMin goes TRUE. The acknowledge bit Alarm_Ack_HMI from the HMI is now a valid reset because the AND condition Ack AND AboveMin is true. The latch resets, the tag goes FALSE, the HMI alarm leaves the active list.
• Until weight is back above the minimum, the AND gate is open-circuit. Even if the operator mashes the Acknowledge button on the HMI, the latch cannot clear — the alarm stays latched and the line cannot advance to validate-and-dump. This is the safety property that justifies removing the "lower the SCADA minimum" workaround.

Wire Alarm_Ack_HMI to a momentary HMI button, an HMI tag with a "Set bit" event on press, or a tag pulsed by a WinCC Acknowledge event on the alarm class. Do not wire it to a sticky HMI tag — a sticky tag is a re-arm bug waiting to happen.

Pattern C: Cycle-Based Re-Arm

On a weigh-and-dump line, the alarm should re-arm cleanly at the start of every cycle (typically when the operator hits the cycle-start or "discharge complete" button). Pattern C adds a "Cycle Start" reset input to the SR latch, alongside the acknowledge. This is the right pattern when the alarm is meant to be checked at every cycle, not on a free-running basis.

  SET:    "Edge_WeightDropped"                              ( S )
  RESET1: "Cycle_Start_Pulse"                              ( R1 )
  RESET2: "Alarm_Ack_HMI" AND "Compare_AboveMin"            ( R2 )
  Q:      "Alarm_WeightLow"                                  ( Q )

Behavior:

1. At cycle start (operator presses start, or a discharge-complete flag from the previous cycle pulses high), the latch is hard-reset regardless of weight state. The alarm tile goes from red to cleared.
2. During the fill phase, if the weight drops to or below minimum (e.g. product stuck to the chute walls, or the load cell briefly reads a low value because of vibration), the falling-edge detector sets the latch. Alarm goes red.
3. The line cannot continue until either (a) the operator manually acknowledges AND weight is back above minimum, or (b) the next cycle start resets the latch for a clean re-check.

This is the most defensive pattern and the one I would default to on a regulated batch line, where a missed minimum cannot be allowed to propagate even one cycle.

HMI / SCADA Alarm Acknowledgement

The PLC side is only half of the fix. The HMI alarm class has to honor the same acknowledge contract. In WinCC Comfort/Advanced and the TIA Portal HMI alarm editor, the relevant properties live on the alarm class itself and on the alarm tag.

If the HMI is a third-party SCADA (Ignition, iFIX, Citect, FactoryTalk View), the same contract applies: the acknowledge event should pulse Alarm_Ack_HMI in the PLC for one scan, never hold it as a sticky TRUE, and the alarm class should be configured to clear on the falling edge of the trigger tag once acknowledged.

Best Practices for Process-Weight Alarms

• Never tie the validate-and-dump permissive to the latched alarm tag. The permissive that advances the line must read the unlatched compare result (weight >= min). The alarm is for the operator's awareness; the permissive is the process safety boundary.
• Hysteresis on the compare. Load cells near the threshold can dither. Add a hysteresis of 0.5–1.0 % of the SCADA minimum to the compare — for example, raise the alarm on weight <= (min - 0.5 %) and clear it on weight >= (min + 0.5 %). One-shot latches plus hysteresis is the cleanest way to keep the alarm tile from flickering on every cycle.
• Debounce the edge detector. If the load cell is particularly noisy, gate the falling-edge detector with a TON (on-delay) of 200–500 ms. The set only fires if the compare stays TRUE for the delay. This eliminates spurious alarms from a single noise spike on the load cell during the fill.
• Comment the alarm origin. Always keep a single, well-named rung that is the alarm's source of truth (e.g. Alarm_WeightLow in a section labelled "Weight validation alarms"). All other code in the project must read that one tag. Do not let individual function blocks compute their own alarm versions of the same condition.
• Persist the edge memory in a non-volatile tag for restart. On S7-1500 with R_TRIG, the instance DB can be set as retentive. On S7-300/400, the FP helper bit must be in a retentive M or DB so the alarm state survives a power cycle.
• Do not silence the alarm to fix the symptom. It is tempting to add a one-shot reset on every cycle start. That converts a real product-quality interlock into a soft warning that never trips. If the alarm is firing too often, the answer is to fix the chute, not the code.

Verification and Commissioning Steps

After implementing any of the three patterns, walk through this checklist on the running line before going back to production.

1. Simulate the compare in the PLC table. Force DBW_BasculeWeight to a value below the SCADA minimum, then to a value above. Watch Compare_AboveMin toggle. The alarm tag should set on the below value, clear on the above value, and never chatter between the two.
2. Watch the edge detector. Monitor Edge_WeightDropped and Edge_WeightRecovered in the watch table. Each transition should produce a single-scan TRUE pulse, not a stuck value.
3. Test the acknowledge path with weight still low. Force the weight below the minimum, set the alarm bit, and press the HMI Acknowledge button. The alarm tag should remain TRUE; the AND gate is doing its job.
4. Test the acknowledge path with weight back above min. Force the weight above the minimum, press Acknowledge. The alarm tag should clear, the HMI tile should leave the active list, and the validate-and-dump permissive should be open.
5. Test the cycle-start re-arm (Pattern C). Trigger Cycle_Start_Pulse from the watch table with the weight at any value. The alarm latch should reset.
6. Check the operator workflow end-to-end. Trigger a real low-weight event (close the chute mid-fill). The alarm tile should go red, the operator refills the bascule, the weight climbs above the SCADA minimum, the operator presses Acknowledge, and the line advances to validate-and-dump. No SCADA minimum adjustment should be necessary at any step.
7. Power-cycle test. Power off the PLC with the alarm active; restore power. The alarm should re-appear in the same state on restart (if the edge memory is retentive) or be re-detected within one scan of the load cell updating.

Troubleshooting Matrix

Frequently Asked Questions