Fix dropped PLC-triggered messages on a serial HMI panel

Why the panel misses the message number

A serial message display reads its message register on its own schedule over the link, and acting on what it reads takes far longer than one PLC scan. A ladder that writes the number in one scan and zero in the next gives the number a lifetime of about 5 ms. The panel can miss it completely and receive only the zero, which blanks the display. The panel maker's support confirmed a delay is required between the two writes.

The sample programs escape this because an operator's switch release supplies the zero. A hand holds a button for hundreds of milliseconds, and that accidental pause covers the panel's response window. The moment the PLC takes over the zero write, the sequence loses that margin. This class of panel publishes no ready-for-data or data-accepted handshake, so the two timers do that job.

Symptoms and what each points to

Work down this list in order; the first match is usually the answer.

• Sample programs display every message; PLC-triggered messages come up blank or get skipped. The panel, cable and pointer setup are fine; the PLC write sequence is the fault.
• The message number never appears and the display just stays blank. Zero reached the panel before it had read the number.
• A 100 ms hold after the number works sometimes. The interval sits partly inside the panel's response window; intermittent success means the wait is too short, not nearly right.
• Blanks continue with the interval on both steps. Another rung is writing the register through the interlock, or the values written are not the ones you expect. Log the register for an hour and match each write to its rung.
• Nothing ever displays, including the sample programs. Stop timing work and check the link itself: wiring, serial settings and the register address. A wrong address usually raises its own error, and fixing HMI invalid address errors when tagging PLC memory walks through that.

None of those? If the screen plays its own content with no PLC writing to it, its delays come from somewhere else; diagnosing a factory screen update delay covers that case.

Read the write order first

Watch the message register while one alarm fires and record two things: the values that land in it, and how many scans each value lives. In the failing pattern the register shows the message number for one scan, about 5 ms, and zero on the next. That confirms a sequencing fault, and ladder logic alone will fix it.

Do not start by swapping the panel or touching pointer settings while the sample programs still display correctly; the failure follows only the PLC-written sequence. While you are in the ladder, count every rung that can write the register, including any rung that writes zero. If two rungs can fire in the same window, no timer on one of them will fix it.

The fix: a not-ready flag and two timers

1. Add one internal not-ready bit to the PLC.
2. On the message trigger, set not-ready and write the message number to the panel register in the same rung.
3. Start a 250 ms on-delay timer from the moment the number is written.
4. When that timer is done, write zero to the register.
5. Start a second timer with the same interval.
6. When the second timer is done, clear not-ready.
7. Put a normally closed not-ready contact in every other rung that can write the register, including the rungs that write zero.

The flag has to stay set through the second wait. Clearing it right after the zero write puts the panel back in the race just as the next message becomes possible. The shape is the same as a delayed write commit timer for HMI switch presses: the panel receives a finished value on a timer instead of a value that changes in the middle of a read.

Example: three alarms from one line stop

Say a packaging line stop raises three messages in priority order: guard door open, motor overload, air pressure low. The queue shows them one at a time through the timed sequence.

Each message holds the sequence for the number interval plus the flag interval, plus a few scans to step through the rungs. At a 5 ms scan, three or four scans add about 20 ms. Call it about 0.5 s per message, so three queued messages take about 1.5 s from trigger to the last one cleared.

The wire time shows what the hold is really covering. At 9600 baud with 8 data bits, no parity and one stop bit, each character takes 10 bits, so the link carries 9600 ÷ 10 = 960 characters per second, about 1.04 ms per character. A 12-character register write, an illustrative length for a short command, takes 12 × 1.04 ms, about 12.5 ms on the wire. Transmission is a small fraction of the hold, so most of the interval covers the panel's own processing, the one number no manual for this class of panel prints.

Cutting both timers to 100 ms would bring three messages down to about 0.6 s, but in the tested sequence messages dropped intermittently at 100 ms, so the 0.9 s you save buys intermittent blanks. If operators need the top alarm inside 1 s, raise only the highest-priority message and fold the other conditions into its text. Three alarms that display every time beat five that sometimes do.

One boundary stays fixed while you tune any of this: the message panel reports the door and the E-stop, it is not part of either safety function, and those keep their hardwired channels under IEC 60204-1.

Keep one writer behind the flag

The timers protect the display only while no request can enter with not-ready set. Review every rung that writes the panel register and fit the interlock contact to each one. If several machine conditions can trigger messages in the same window, queue the later requests and release them one at a time as the flag clears. The queue also fixes a second failure: two requests 100 ms apart would otherwise collide inside one timed sequence even with each sequence internally correct.

Leave no maintenance or bypass rung that skips the interlock. One write through the flag undoes the whole arrangement.

Verify with back-to-back messages

Test at least three distinct message numbers, never a single lucky write. Watch the register and the flag through each cycle and check four things: the number stays present through the first timer; zero appears only after that timer is done; the flag stays set through the second timer; and the next request is held off until the flag clears. Then fire the messages back to back with no gap, the way a real line stop does.

Give each message its own number and wording so operators can tell them apart at a glance; operator text in HMI alarms covers writing those event messages.

Recommendation: Gate every PLC write to the panel register behind a not-ready flag, hold the message number on the first timer, write zero, and hold the flag through a second timer at the same interval before clearing it. Budget about 0.5 s per message and queue bursts so nothing writes through the interlock. Keep 100 ms out of production programs; it dropped messages intermittently in the tested sequence. Shorten a timer only after the panel maker supplies a documented response time or handshake, and retest with back-to-back messages before release.

Questions