Timeout Time is how long an HMI panel waits for one PLC response before it gives up on that request; Poll Time is the wait between requests. Raise Timeout Time when replies are slow on every refresh, and raise Poll Time when several clients overload the link.
Two settings on the panel manager tab decide whether a polling link runs clean: Timeout Time and Poll Time. Timeout Time is how long the panel waits for one response before it gives up on that request and moves on to the next data-block request. Poll Time is the wait between requests, there so the PLC is not overloaded with them. They fail in different ways and they cure different faults, so the job is knowing which knob your timeout message is pointing at. This article defines each setting, shows the arithmetic that separates the two cases, and works one typical serial link end to end: a 100-register poll at 19,200 baud that finishes 21 ms too late for its configured timeout window, and passes once the block is halved.
Timeout Time: the wait for one reply
Timeout Time runs against a single data-block request. A response that arrives inside the window is written to the tags and the timer is forgotten. If nothing arrives in time, the panel marks that request failed, raises its timeout message, and continues with the next data-block request, so polling carries on.
The number that matters is your slowest exchange, not your average one. A block whose reply needs 121 ms misses a window set to 100 ms on every poll, while a 69 ms block on the same link and the same settings passes every time. That is why one screen can time out constantly while the rest of the project looks healthy. The same arithmetic sits behind an erratic Modbus RTU response delay between an HMI and its PLC, where replies drift in and out of the window as the PLC's scan load changes.
Poll Time: the gap between requests
Poll Time is the idle gap the panel leaves after one data-block request and before it sends the next. Its job is to keep the PLC from being overloaded with requests. A shorter gap sends requests faster and consumes more of the link; a longer gap cools the link and slows every screen item fed by that poll.
Two sums describe the cost. Refresh pace is 1 divided by the sum of the poll gap and the exchange time: behind the example's 121 ms exchange, a poll gap equal to the timeout gives about 4.5 updates per second. Link load is the exchange time over that same cycle: 111 ms of line time in every 221 ms cycle means the port sits busy about half the time. A second panel, a programming client, or requests passed through another panel all share whatever capacity is left.
Which symptom points to which setting
| What you see | What it points to | What to change first |
|---|---|---|
| Timeout message on every refresh of one screen, link quiet otherwise | Replies to that block are slower than the Timeout Time value | Timeout Time, to about twice the computed exchange |
| Message appears only while a second panel, a programming client, or pass-through traffic shares the port | Request load on the PLC or the shared line | Poll Time, raised on each client that polls |
| Message appears instantly, every cycle, and no data ever returns | Wiring, station address, or port settings | Nothing in the timers; repair the path |
When nothing comes back at all, timers are the wrong tool: the fixed serial port settings checklist clears wiring, station address and port setup first. To tell a link that answers slowly from one that has gone down, use the frozen HMI panel or dropped link checks. In a pass-through chain the two readings can both be true, because each panel reports the state of its own link; watch the client that originates the requests.
Worked example: a 100-register poll at 19,200 baud against the configured timeout
A common case: a panel polls a PLC over an RS-232 line running Modbus RTU, and the timeout message fires on one screen.
Inputs, each with where it comes from:
- Line speed 19,200 baud, counted as 19,200 bit/s on a serial port, with 8 data bits, no parity, 1 stop bit. These are the port settings as entered on the panel and the PLC; read yours off the driver screen.
- Frames for one read of 100 holding registers over Modbus RTU: 8 bytes out (slave address, function code, start register, register count, CRC) and 205 bytes back (address, function, byte count, 200 data bytes, CRC). The frame sizes are fixed by the protocol layout.
- 10 bits per byte: start bit, 8 data bits, stop bit, no parity.
- PLC handling budgeted at one scan, 10 ms. Small PLCs complete a full scan of their logic in single-digit milliseconds, so 10 ms is a safe worst case.
- Current settings, read off the panel manager tab: Timeout Time 100 ms, Poll Time 100 ms.
The rule in words: an exchange cannot finish sooner than the line time of both frames plus the PLC's handling, so Timeout Time has to cover that total.
Arithmetic:
- 8 + 205 = 213 bytes on the line.
- 213 bytes × 10 bits per byte = 2,130 bits.
- 2,130 bits ÷ 19,200 bit/s = 0.111 s, so 111 ms of line time.
- 111 ms + 10 ms of scan = 121 ms before the last byte reaches the panel.
- 121 ms against the configured window: the panel gives up 21 ms before the reply finishes. Every poll of this block needs the same 111 ms of line time, so the message repeats on every refresh.
Confirm the diagnosis by halving the block to 50 registers: the response drops to 105 bytes, so 8 + 105 = 113 bytes on the line, 1,130 bits, 1,130 ÷ 19,200 bit/s = 58.9 ms, plus 10 ms of scan = 69 ms. Inside the configured window, on the same link with the same two settings. The fault followed the block size, and the block size is yours to choose.
Decision: set Timeout Time to about twice the slowest exchange, 121 × 2 = 242 ms, entered as the nearest value the panel's setting list allows above that, 250 ms here. Leave Poll Time at its recorded value for the first trial and touch it separately if shared load is part of the fault.
Change one setting per trial
- Record both current values and the conditions when the message appears: which screen, what time in the shift, which other client is open.
- Repair any confirmed path fault before touching a timer. Wiring and station numbers do not respond to arithmetic.
- Change Timeout Time or Poll Time, never both at once. Hold the other value where it was.
- Run the operation that produced the message long enough to see several refreshes of the slowest screen.
- If data gets slower and the message stays, put the recorded value back and try the other setting next.
Recommendation: raise Timeout Time when the message fires on every refresh of one screen while the link is otherwise quiet, and size it at about twice the slowest exchange, computed as line time plus one PLC scan. Raise Poll Time when the message appears only while other panels or a programming client share the PLC or the port, and raise it on every client that polls, one at a time. Change one number per trial, watch the same operation afterwards, and record the final values in the maintenance file.
One warning belongs here: a Timeout Time raised far enough hides missing replies behind old values on the screen. Treat stale process values as no data, especially where an operator acts on them.
What the settings change on the floor
Timeout Time costs nothing while replies arrive inside the window; it extends only the wait on late or missing ones. Poll Time bills every cycle, so it sets the pace of the screen: push the gap to 500 ms behind the example's 121 ms exchange and updates fall to about 1.6 per second, the difference between a value that tracks the machine and one that lags a button press. Where delays stretch into seconds across several devices, the HMI panel to device delay trace walks the route end to end. And where the panel should stay a machine interface, give shift and notice content a screen of its own: our factory-floor display range is built for that job.
Questions
What units are Timeout Time and Poll Time entered in?
The setting screen on the panel prints the unit next to each field, and it differs between products: milliseconds on some panels, seconds on others. Convert your computed exchange time into the field's unit before entering it, so a 121 ms budget becomes 0.121 where the field counts seconds. If the screen shows no unit, enter a trial value, switch to the slowest screen once, and compare the behavior against your arithmetic; being off by a factor of 1,000 is unmistakable on the first try.
Does raising Timeout Time slow the screen down?
No. The timer runs only against a reply that is late or missing, so a well-sized Timeout Time adds nothing to exchanges that finish inside the window. Poll Time is what paces updates: its gap is added to every cycle, successful or failed. That is why the two are tuned in opposite situations. A larger Timeout Time buys patience for slow replies at no refresh cost; a larger Poll Time buys a quieter PLC and pays for it in slower updates on every screen.
One panel passes requests through for another client. Which status do you trust?
Each panel reports the state of its own link, so a clean port on the panel in the middle and a timeout on the client that originated the request can both be true at once. Run the comparison that isolates the load: note whether the fault appears with the programming or second client closed, then again with it connected. If the timeout shows up only while that client is on the line, two pollers are sharing one port, and Poll Time on each is the setting to raise.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.