Why an R_TRIG pulse never shows on the HMI screen

Why does the HMI miss a pulse the PLC really produced?

The R_TRIG output is TRUE for exactly one program scan, about 20 ms at a default cycle time, while the HMI reads that tag on a 100 to 1000 ms refresh cycle, so the screen is not looking during the pulse.

IEC 61131-3 defines the block: R_TRIG watches CLK, and after CLK steps from FALSE to TRUE it holds Q high for one evaluation of the block, then drops Q until the next rising edge. One evaluation is one pass through the task. The TRUE state exists for that pass and is gone.

The screen reads the tag on its own schedule. Vendor support pages show HMI tag refresh commonly left at 1 s and pushed to 100 to 200 ms when it matters, and one visualization environment ships a 200 ms default between controller and screen. The reads land between pulses. Edge detection and display both do their jobs; their clocks never meet. To see where each evaluation runs, trace PLC execution order across task layers.

What symptoms tell you the pulse is one scan wide?

Three signs identify it: downstream logic that consumes the pulse works, the lamp or bit on screen never changes, and forcing the input TRUE lights the lamp, which clears the wiring and the address.

• A counter wired to the same R_TRIG output climbs on every event while the on-screen lamp never lights. The edge fires; only the display path loses it.
• Forcing the lamp's tag TRUE lights it within one refresh. The address, the wiring and the display path are good, so the fault is timing. How forcing works in the PLC cycle covers what a force touches and what it leaves alone.
• The lamp flickers on for a random few events. A read landed inside a TRUE scan. That is the sampling race, not an intermittent sensor.
• Nothing moves anywhere and the counter stays flat while the input provably toggles. The block is called conditionally and misses scans, or the signal never reaches it. Move the call into a task that runs every scan.

Which refresh rate is the screen actually running?

Most tag refresh cycles run 1 s by default and reach 100 to 200 ms when you shorten them, and one visualization system defaults to 200 ms between controller and screen, so measure where yours sits before blaming the logic.

In most HMI projects the update cycle lives on the tag group or the connection, one number in milliseconds per group. Open the tag settings and read it. Two field facts go with it: the default is often 1 s, and the number of variables linked to the screen drives the controller scan as well, with 4 ms scans reported on a light project. More watched tags slow both sides.

A faster cycle shrinks the gap and never closes it: even at 100 ms, four of five pulses land between reads. Shorten the refresh to make state changes feel live; fix the pulse itself with the two methods below.

How do you stretch the pulse with a TOF?

Feed the R_TRIG output into a TOF with PT := T#3s and put the TOF output on screen; the off-delay holds Q TRUE for 3 s after the edge, which spans 15 reads at 200 ms, so the screen cannot miss it.

rTrigInstance(CLK := InputSignal);
tofInstance(IN := rTrigInstance.Q, PT := T#3s);
VisiblePulse := tofInstance.Q;

TOF is the IEC 61131-3 off-delay: Q follows IN, and when IN falls, Q stays TRUE for the preset time PT. Given a TRUE that lasts one scan, the block hands the display a TRUE that lasts seconds. A new edge inside the delay keeps Q high and restarts the timing, so a burst of pulses shows as one solid lamp. Size PT for the viewer: it must sit well above the refresh interval, and ten refresh intervals is a safe floor.

How do you latch the pulse with a SET coil?

Latch the edge into its own BOOL with a SET coil, or the equivalent IF block in structured text, and reset it from an acknowledgment button; the bit then stays TRUE until someone clears it, so no refresh rate matters.

rTrigInstance(CLK := InputSignal);
IF rTrigInstance.Q THEN
    EventLatched := TRUE;
END_IF;
IF Acknowledge THEN
    EventLatched := FALSE;
END_IF;

In ladder the same thing is a SET coil driven by the pulse and a RESET coil driven by the acknowledgment. The latch beats the timer when events arrive faster than the display time: the TOF merges a burst into a solid lamp, while the latch plus a count tells you how many events happened. When you need the tally, a CTU counter on the raw pulse counts what the screen never samples; PLC up down counter scan timing and direction logic covers how to wire it.

How do the numbers come out in a worked example?

A case sealer rejects 40 cartons a minute, one R_TRIG pulse per reject, scan 20 ms, screen refresh 200 ms: 60 / 40 = 1.5 s between pulses, and 20 / 200 = 0.10, a 10% chance any pulse is ever read.

Take a bad run at full rate:

• Pulse spacing: 60 s / 40 cartons = 1.5 s per reject.
• Probability one pulse is read: 20 ms / 200 ms = 0.10, so 10%.
• Seen in one minute: 40 x 0.10 = 4 rejects on screen, 36 missed.

Now add the TOF with PT := T#3s. Each edge holds Q TRUE for 3 s, which spans 3 / 0.2 = 15 reads, so every reject lights the lamp. Because a new edge arrives every 1.5 s, each one restarts the delay and the lamp holds solid for the whole run: the operator sees that rejects are happening, without counting blinks.

If the operator must count events by eye, drop to PT := T#1s. The lamp is TRUE for 1 s and dark for the remaining 1.5 - 1.0 = 0.5 s between cartons, one blink per reject. Latch with the SET coil and put the CTU count beside it, and the screen reads 40 after the minute whether anyone watched.

Should the stretched signal drive machine logic too?

No: keep sequencing, counters and interlocks on the raw one-scan output and give the display its own stretched or latched tag, because a 3 s TRUE held into a counter or a step chain changes what the machine sees.

Feed that same burst through the TOF into a counter and the counter sees one rising edge for the entire run, because the stretched output never falls between cartons. It undercounts, silently. This is the one place to be strict: the display tag is for eyes. Anything that stops the machine or guards an operator runs on the one-scan logic or the hardwired path, and the stretched tag stays out of it.

When should the event go on a floor notice screen instead?

Put it there when operators away from the machine need the count more than the single event: latch or count in the controller, then carry the number to a notice screen that runs its own playlist.

The HMI answers the machine question. When the tally matters across the aisle or across the plant, count in the controller and publish the number where the floor already reads shift messages, on a shop-floor notice screen. The count reaches the screen as displaying a live dashboard on a signage screen describes. The one-scan pulse stays in the controller either way.

Recommendation: Give the display its own tag and leave the machine on the raw one-scan output. Use a TOF with PT := T#3s when someone must see every event as it happens, and the SET coil latch with a counter when events arrive faster than the display time or the tally matters. Set the tag refresh to 200 ms or faster while you are in the settings, and keep both the stretched and the latched tag out of sequencing and safety logic.

Questions