A 10 to 15 second delay between an HMI panel and devices such as a bill acceptor or a thermal printer is almost never the serial wire: a 20-byte transaction occupies a 9600 baud link for about 21 ms. Split the interval into trigger-to-request, request-to-response and response-to-display, time each segment, and fix the one that holds most of the seconds.
A 10 to 15 second delay between an HMI panel and the devices behind it, a bill acceptor and a thermal printer in the typical case, is almost never the serial wire. At a common 9600 baud setting, a 20-byte request and its reply occupy the link for about 21 ms, counting 10 bits per byte. The seconds live in wait logic, in a stale handshake bit, or in one device queued behind another. Before you touch scan settings or shorten a timeout, split the interval into three measured segments, time each one on a single transaction, and let the biggest segment name the fix. This article gives the three segments, the symptoms each delay pattern points to, a worked example on a 14-second delay, and the fix that follows from each reading.
What a 10 to 15 second delay points to
Two installations can report the same seconds and need opposite fixes. Match what you see against this list; the timing method in the next two sections tells the causes apart.
- The delay is nearly the same length every time, on both devices. Shared wait logic: a timer or a handshake wait in the sequence both transactions pass through.
- Nothing leaves the panel for several seconds after the trigger. A permissive upstream of the request, or the transaction held behind another.
- The request goes out promptly and the reply comes back late. The device or its interface. One device only points at that device; both point at a shared controller or a shared link.
- The reply lands promptly and the screen updates late. The panel-to-PLC data update path, its poll interval or its driver scan.
- The delay appears only when one device ran just before the other. A queue: one transaction at a time through shared logic or a shared interface.
Map each device to its path before anything else
Trace the bill acceptor's connection to its endpoint, into the panel, into the PLC, or through a separate interface, and record which. Trace the printer separately. Installations of this kind commonly mix the paths, and each arrangement puts different drivers, message handling and control logic in the delay's path.
For each path, write down three things:
- Who initiates the transaction: the panel, the PLC or the device.
- Which event on the wire marks the request, and which LED, bit or status word marks completion.
- What the device does on completion: pay, print, or both.
Use the panel and PLC project configuration, the device labels and the wiring drawings. The check: you can draw each request-and-reply path and name the interface at every hop. If a path's endpoint is unknown, stop before changing communication settings, because the settings you would edit belong to a link you have not identified yet.
Time the three segments
Time one transaction, trigger to visible result, in three parts:
- Trigger to request. From the operator action or the PLC bit that starts the sequence to the first activity on the wire: a transmit LED on the interface or the transmit flag the panel's diagnostic screens show.
- Request to response. From that first activity to the device's completion indication, its LED or its status bit changing state in PLC online monitoring.
- Response to display. From the completion indication to the value changing on the screen.
Watch the bits in PLC online monitoring and the device LEDs together, and put an interface monitor on the link where the wiring drawing says the device hangs off a serial port. Keep the event definitions identical for both devices, and make each timed run one transaction, start to finish.
Each result leads somewhere specific. When the third segment owns the interval, take the checks from an HMI screen slow to update over serial with no errors. When the device path runs over Modbus TCP, time request-to-response the same way and apply Modbus TCP data slow to update on an HMI panel. When no single segment dominates and the whole path feels slow, a slow HMI panel: touch, entry and screen update delays covers the panel-side causes.
Example: a 14-second delay split into three timed segments
Inputs.
- The installation: a pay-at-the-door terminal, an HMI panel with a bill acceptor and a thermal printer, both devices reported at 10 to 15 s from request to visible result. That reported range is the case this article works.
- Stopwatch total: 14 s from trigger to screen update.
- One timed run, readings taken against PLC online monitoring and the device LEDs: 0.3 s from trigger to first activity on the acceptor line, 12.4 s from that activity to the acceptor's completion bit changing, 0.5 s from the bit change to the paid value on screen. The three readings are one illustrative run; your readings will differ.
- Wire reference: a 9600 baud setting and a 20-byte transaction.
Rule. The three segments add up to the observed total, so a run that misses the total means an event definition slipped. The segment holding more than half the total owns the fix. Request-to-response also has a floor that no setting change beats: the time the bytes need on the wire.
Arithmetic.
- 0.3 s + 12.4 s + 0.5 s = 13.2 s, inside the reported 10 to 15 s band, so the three segments account for the delay.
- 12.4 s ÷ 13.2 s = 0.94, so request-to-response holds 94% of the interval.
- Wire floor: 20 bytes × 10 bits per byte = 200 bits; 200 bits ÷ 9600 bits/s = 0.021 s, about 21 ms. The measured wait is 12,400 ms ÷ 21 ms ≈ 590 times the wire time.
Result. The acceptor's request-to-response segment owns the delay.
Decision. Work the acceptor's path: interface configuration, handshake order, queue, in that order of likelihood. A shorter panel timeout or a faster screen refresh leaves all 12.4 s in place. Had the run shown the screen segment near 12 s with the other two under a second each, the same more-than-half rule points at the panel-to-PLC update path, and the acceptor's serial settings would be the wrong work. At 9600 baud or faster, no serial setting buys seconds: the wire stays busy for tens of milliseconds.
Rule out wait logic and a stale handshake bit
In delays of this size, the sequence logic is the usual owner. Open the rung or panel action that starts the transaction and the condition that releases the next step, and look for three things.
A timer in the wait path. An ON-delay timer instruction turns its output on only after its rung has stayed true for the preset time, so a wait built on one adds its whole preset to every transaction. Compare the preset with the measured interval; an exact match names the owner. Change the preset only after confirming what the timer governs, because some waits exist to let a device finish internally.
A handshake pair in the wrong order. The request bit must be set and the previous transaction's done bit must be reset in the order the sequence documentation shows. A done bit left over from the last transaction can hold the next step or release it early, and both faults show up as fixed, odd intervals. Watch the request and done bits across one transaction in online monitoring and check the order against the sequence documentation.
A queue between the two devices. Printer work held behind bill validation, or the reverse, makes each device inherit the other's time. The symptom is the last line of the first list: the delay appears only when one device ran just before the other. The timed segments show how much of the interval the queue held, and reordering the queue is the fix.
A shorter timeout makes the panel report failure sooner. It does not make the device answer sooner, and a valid reply that lands after the shortened timeout gets treated as a failure, which trades the delay for failed transactions and cut-off prints.
Isolate one path before you change a setting
With the baseline recorded, run one controlled transaction on one endpoint with the other path idle, and time request-to-response. Then run the other path alone. Three outcomes:
- Both paths slow at the same stage: the shared logic or the shared interface owns the delay, so work there.
- One path slow, the other fast: the slow device, its interface and its configuration own the delay.
- The device answers within its documented time and the screen still lags: the panel-to-PLC update path owns the delay, and the article on slow serial updates linked above is the next read.
One safety point belongs here. Before you fire test transactions at a bill acceptor, isolate it from anything that counts money or dispenses product, because a test note on a live machine is a real payment. Use the device's own test or service mode where its documentation provides one.
Fix the segment that owns the interval and verify
Apply the fix where the timed run put the seconds.
- Trigger to request owns it: find the permissive or the queue that held the request, and release or reorder it.
- Request to response owns it: work the device path, interface configuration first, then the handshake order, then the device's own settings per its documentation.
- Response to display owns it: work the panel-to-PLC update path, poll interval and driver, with the linked article.
Record the original values and save the project before any edit, and make permanent edits only after a controlled test passes. To verify, run the full trigger-to-result sequence on both paths and check four things: the request goes out once, the completion indication changes once, the screen shows the result, and the stage times match the timed-run baseline. Set the target before you call the job done: the device documentation gives its transaction or print cycle time, and the target is request time plus device cycle plus display poll, with no retries in the log.
Recommendation: Time the three segments on one transaction before you change any serial setting, scan setting or timeout. If request-to-response holds more than half the measured interval, work the device path in this order: interface configuration, handshake order, queue. If response-to-display holds it, work the panel-to-PLC update path. If trigger-to-request holds it, find the permissive that gates the request. Change a timeout only when the timed run shows the timeout itself is the interval you measured.
Questions
Is the PLC scan time worth checking first?
No. A small PLC clears its logic in a few milliseconds, commonly 1 to 10 ms per scan, while the delay here is 10 to 15 s. Ten thousand milliseconds divided by five is two thousand, so the delay runs about two thousand scans deep. Scan settings cannot hold these seconds, and editing them first spends a shutdown window on the one setting the timed run never blames. Check the scan only if the segments point at the logic itself and online monitoring shows the rung waiting scan after scan for a bit that never arrives.
Why does the delay look longer at the screen than in the logs?
The panel shows the new value only at its next screen update, so a fixed wait reads longer by up to one full update interval. Time the segments against the logic bits and the wire activity, the way the article does, and the logs give the fixed number while the screen gives the worst case. That gap is why the same installation can report 10 seconds to one observer and 15 to another.
What should be ready if the delay survives every check in the article?
Four things: the wiring drawing with the interface named at every hop, the three timed segments from one run, the sequence documentation showing the handshake bit order, and the project and device documentation for the installed models. With those four, the remaining question is usually inside one device, and the device manufacturer's documentation is the source for its status codes, its service mode and its measured transaction time. Without the timed segments, the next person starts where you started, by guessing which link to blame.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.