PLC flag triggers an HMI event once: check the reset path

Why one flag gives one event and a button gives every event

Event managers trigger in two ways. A change trigger fires when the tag moves, so 0 to 1 arms it and only a return to 0 rearms it. A level trigger fires while its condition is true. If the project uses a change trigger and the PLC sets the flag once and leaves it set, the tag never moves again and the manager has nothing to react to. The reset rung that should have cleared the flag never ran, or nothing in the project clears it.

The button tells you the trigger type by accident. Its press action writes 1 and its release writes 0, so every press hands the manager a fresh transition. That makes it a useful clue about the trigger type and a poor test of the PLC path, because the button object writes the tag through its own action. How long a panel holds its own bit under a finger is its own timing question; how many PLC scans an HMI momentary button bit stays on covers it.

What each symptom points to

Watch the flag in the PLC monitor and match what you saw to one of these.

• Flag goes to 1 and stays at 1. A change trigger with nothing new to see; the reset rung never ran. Find the logic meant to clear the flag and watch it online.
• Flag is 1 for one scan, then 0. The pulse fell between two panel reads. Hold a request until the panel acknowledges; the handshake below ends it.
• Flag cycles 0-1-0 cleanly and the second event still misses. Address mapping or the event's condition. Compare the address the event watches with the one you monitored.
• The button repeats the event, the PLC flag does not. Two different trigger paths. Compare the button's action with the event's condition and action.

Check the flag through one full cycle

Put the PLC online and watch the exact address the event is bound to. Trigger the sequence once and write down three values: the flag before the trigger, while the event should be active, and after the event should have completed. Open the event in the manager and read its trigger type, change or level. Check the action list there too and confirm nothing in it depends on the button object.

If the monitor shows the flag stayed at 1, stop there: the scan time is irrelevant and the repair is the missing reset rung. If the flag never made the transition at the address the event watches, compare the two addresses before anything else; HMI pings the PLC but reads fail: check the protocol driver sorts a dead link from a wrong tag. A clean 0-1-0 with a silent panel is the pulse width case, and the next two sections handle it.

Why the 100 ms scan is the wrong suspect

A coil that is on for one scan of a 100 ms cycle is visible on the wire for about 100 ms. The panel reads tags on its own clock, the read cycle set in the project's connection settings, and the two clocks run independently. A read catches the pulse only when a read lands inside that window, so the catch rate is pulse width measured against read cycle.

Shortening the scan moves the wrong number. A one-scan pulse shrinks with the scan, so a faster scan makes the panel's job harder. The worked example below puts numbers on both directions. The panel's read cycle is a setting on the panel side of the link; no PLC scan value sets it. Narrow pulses are the root cause, and the handshake removes the width question entirely. The same mechanism sits behind why an R_TRIG pulse never shows on the HMI screen.

The handshake: one request, one event

Two bits in the PLC do the whole job: a request bit the PLC writes and the panel reads, and an acknowledge bit the panel writes and the PLC reads. Name them whatever your project calls its handshake tags.

1. Ready state: request = 0, acknowledge = 0.
2. The PLC sets request to 1 and holds it there across scans.
3. The panel reads request = 1 on its next cycle and fires the event, on that level or on the change to it.
4. The event's last action writes acknowledge = 1 back to the PLC.
5. A PLC rung sees acknowledge = 1 and clears request and acknowledge in the same scan.
6. The pair is back at ready, and a change trigger is re-armed the plain way: the tag really did return to 0.

A request can never be missed, because it stays high until the panel's own acknowledge says it was read. One request can never fire twice, because request returns to 0 before the next one arrives. If the event repeats while request stays 1, the acknowledge rung is late: watch the acknowledge bit to confirm the panel's write reached the PLC, then check that the clear rung addresses both bits. The write-back wiring, including which side clears which bit, is laid out in signal an HMI alarm acknowledgment back to the PLC.

Recommendation: hold the request bit until the panel writes its acknowledge bit, and clear both bits from one PLC rung in a single scan. A change trigger and a level trigger both work on the request, because it returns to 0 before the next request arrives. Leave the scan time at the value the process logic was tuned to; change it only after the flag is shown to make the transition the event needs, and put it back after the test.

Worked example: a one-scan pulse against a 1 s read cycle

A packaging line counts finished batches. Its PLC runs a 100 ms scan, and one coil pulses for a single scan to make the panel log a batch event. The project sets the panel's tag read cycle to 1 s.

Pulse width: one scan, so about 100 ms. With pulse starts landing at random phases of the read cycle, a read catches the pulse 100 ms / 1000 ms = 10% of the time. Roughly one batch event in ten is logged; nine are lost with nothing on screen.

The line's engineer shortens the scan to 10 ms to help. Pulse width becomes 10 ms and the catch rate 10 / 1000 = 1%, one event in a hundred. The change moved the wrong way.

With the handshake: the PLC sets request and holds it. Worst case, the panel reads it up to 1 s later, fires the event, and the acknowledge write lands at the next slot up to 1 s after that; the PLC clears both bits within one 100 ms scan. Worst case from request to ready: 1 s + 1 s + 0.1 s = 2.1 s. Every request fires exactly once, and a faster read cycle only shortens that 2.1 s.

Test it before the line runs

Start from ready, request = 0 and acknowledge = 0, and let the PLC run two full request cycles. Watch all three signals: request, acknowledge, and the event's result on the panel. Pass means one request produced one event, the pair returned to ready, and the second request fired with nobody touching a button.

If the line has to run before the repair, a button on the panel can serve as a temporary operating method, and it is an operator override on a machine: use it only where the sequence stays safe with the event fired by hand, and log it as temporary. The handshake is the permanent repair, and the button path comes out of the project once it is in.

Questions