When an HMI panel keeps its touch response but PLC values stop updating two or three times a day, the serial exchange has stalled and only a panel power cycle restarts it. Record the failure signature, confirm the timeout and poll time saved on the panel match the project, and test the panel on its own supply before swapping hardware.
Two or three times a day the panel on your line keeps its touch response while every PLC value on screen goes stale, the TX2 and RX2 lights sit dark on both serial ports, and only a panel power cycle brings the numbers back. That pattern is a stalled serial exchange, the panel side holds the stalled state, and the repair is configuration work, not a new panel. Work through it in this order: record the failure signature, set the panel's timeout and poll time to the tight pair below, read both values back from the running panel, match the two ends of the port field by field, and give the panel its own supply if a dropout still comes. Each step below says what to record and what result decides the next one.
Why does the touch screen still work when PLC data freezes?
A touch panel that accepts input while its PLC values sit frozen has a working display and a stalled serial exchange, and dark TX2 and RX2 lights at both ends show that neither side sent anything during the fault.
On this kind of link the panel is the polling master. It sends each request, the PLC answers it, and the poll time setting paces the exchange. When the panel's driver stops exchanging, the PLC has nothing to answer, so both ports go quiet and restarting the PLC restores nothing. Restarting the panel restarts the driver, which is why the lights come straight back. The temperatures, counts and alarm bits on screen all stop at the same moment, and the rate, two or three drops a day, is steady enough to test a fix against. Read it as one fault with one owner: the exchange stopped, and the panel holds the stalled state until its power is cycled.
What should you record before power-cycling the panel?
Capture four facts during the fault: the time it started, which values stopped updating, the light state of TX2 and RX2 on the panel port and on the PLC port, and whether the PLC still runs its outputs.
Those four facts separate the faults that look alike. A live screen with stale values and dark lights at both ends is a stopped exchange. A dark screen, or a panel that ignores touch, is a panel power or hardware fault on a different track. A PLC with its run light on and its outputs held kept working through the event. Write the times down too: two or three dropouts a day is a rate you can compare against after the fix, and times that line up with one machine starting can point at electrical noise from that machine. Record first, restart second; the restart is the recovery step, and the repair comes from the checks below.
What do the timeout and poll time settings control?
Timeout is the wait the panel driver allows for a PLC response before it retries, poll time is the pause the panel inserts between polls once a reply has arrived, and the pair that ends this pattern is 25 ms of timeout with 5 ms of poll time.
Both fields sit in the panel project's communication setup for the port in use, port 2 on the serial cable here. The panel's driver help documents each one: timeout as the response wait, poll time as the injected pause between polls. The numbers are tight for a serial link. At 9600 baud with one start bit, eight data bits and one stop bit, one character occupies 10 / 9600 = 1.04 ms on the wire, so a timeout in that range is a short, deliberate wait. Short waits only work when they are the values actually running, which is the next check.
Are the settings on the panel the ones you downloaded?
The configuration list can read the timeout and poll time as saved while the panel runs something else, because the panel runs whatever project was last downloaded and applied, so read the values back from the panel before you change anything or credit the change.
This is the trap in this exact pattern: the starting list already showed that same tight pair, and setting those two fields again was what ended the dropouts. A list in a project file or a commissioning note drifts away from the panel the moment an older project file is downloaded over the current one. Close that gap in order:
- Open the panel project and write down the communication setup for port 2 as saved: station number, baud rate, parity, handshaking, timeout, poll time.
- Set the timeout and poll time fields to the values above, and download the project the way your site normally applies one.
- Reopen or read back the running configuration on the panel and confirm both fields show the new values.
- Watch the port lights for the next hour; steady TX2 and RX2 activity at both ends says the exchange is running.
If the read-back already showed the same pair and the dropouts still come at the old rate, go to the supply test below.
Which settings must match at both ends of port 2?
Compare every field at both ends, station number, baud rate, parity, stop bits, handshaking and protocol; the working pair here ran station 1 at 9600 baud, no parity, 1 stop bit, no RTS or CTS handshaking, with the panel polling the PLC's K sequence protocol on port 2.
| Setting | Panel side, port 2 | PLC side, port 2 |
|---|---|---|
| Station number | 1 | 1 |
| Baud rate | 9600 baud | 9600 baud |
| Parity | none | none |
| Handshaking | RTS control: no, require CTS: no | RTS on 0 ms, RTS off 0 ms |
| Protocol | the driver for the PLC family | K sequence |
| Timing | timeout 25 ms, poll time 5 ms | timeout X1 |
Match the PLC side's stop bit 1 in the panel driver, and keep the panel's RS485 select set to no for the cable this link uses. Check each row on its own; agreeing on baud rate while parity differs still blocks the link. X1 is the port's timeout entry as that PLC family prints it, and the scale behind it lives in the PLC's manual, so read it there before changing it. Reseat the serial connector at both ends while you are in the cabinet, and look the cable over for damage and for runs beside AC wiring. A link that never comes up at all is the flat mismatch covered in an HMI panel not talking to the PLC: serial settings mismatch; a link that runs for hours and then drops is the pattern this article treats.
Could the shared supply be dropping the link?
Seven reed switch inputs and one photo eye shared this panel's 60 W, 24 V supply, which leaves capacity to spare, so the supply suspects are brief dips and switching noise, and a meter holding a steady reading will hide both.
The check that settles it is a controlled split. Power the panel from its own low-voltage feed, or from a spare DIN-rail supply in the cabinet, with nothing else on it, then run at the old failure rate for a day. Two or three dropouts a day is enough rate that a clean day decides the question: if the separate feed ends them, the shared supply or its wiring is the cause, and the fix is a dedicated feed for the panel or a supply with more filtering. Change one thing at a time; moving the panel, the cable and the settings in one afternoon leaves you unable to say which change worked. Keep the serial cable away from AC runs while you are in there, and note the traffic times of anything else using the PLC, a computer link through a communications module for instance, to see whether the dropouts line up with it.
A shared low-voltage feed is a known way to take a panel down, and the coil-load version is covered in why a shared DC supply with solenoid coils freezes an HMI. Where the noise rides in on the building's AC side, the hunting method is the one used to find the noise when an HMI locks up on AC power but runs on 24 VDC.
Worked example: how much of a 60 W supply does the panel get?
A 60 W supply at 24 V delivers 2.5 A in total, and the seven reed inputs and one photo eye in this setup draw well under 0.1 A together, so the arithmetic points away from capacity and toward dips and noise as the supply-side suspects.
Carry the numbers:
- Supply: 60 W / 24 V = 2.5 A available.
- Reed inputs: at a common 8 mA per point for a 24 V DC discrete input, 7 x 8 mA = 56 mA.
- Photoelectric sensor: about 30 mA, the middle of the 25 to 50 mA range a typical three-wire sensor lists.
- Sensor load together: 56 mA + 30 mA = 86 mA, about 0.09 A or 2.1 W.
- Left for the panel: 2.5 A - 0.09 A = 2.41 A, about 58 W.
Double the sensor figures and the panel still has over 2.2 A, so this supply is nowhere near its 60 W limit on paper. The failure the isolation test looks for is different: some load switching in the plant drags the shared rail down for a few milliseconds, the panel's supply sags mid-exchange, and the driver stalls with both ports dark. A hand-held meter taking a few readings a second shows a healthy steady voltage through the whole event. That is why the verdict comes from the separate-supply test above, or from a meter that records the minimum voltage it saw.
How do you confirm the fix held?
Leave the downloaded values alone, watch the TX2 and RX2 lights cycle steadily during polling, and hold the link for a full day at the old rate of two or three dropouts; a clean day at that rate says the timing pair was the fault.
To keep an eye on the link afterwards, put a heartbeat counter on the screen: a PLC register that steps once a second, shown in a corner of the panel, turns the next stall into something an operator notices in seconds. The setup is in verify HMI communications with a PLC heartbeat counter. Write the timing values and the date they were applied into the project notes, so the next download does not restart the search from the beginning.
Recommendation: Set the timeout and poll time pair above on a 9600 baud serial link showing this pattern, download the project, read both values back from the running panel, and hold the link for a full day at the old failure rate. If a dropout still comes, power the panel from its own feed before you swap panels or touch the PLC port settings, and change one thing at a time until the day is clean.
Questions
How fast is a 9600 baud serial port in characters per second?
With one start bit, eight data bits and one stop bit, 9600 baud carries 960 bytes per second, about 1.04 ms per character. A timeout of that length therefore spans roughly 24 characters of reply plus turnaround. On a link with longer frames, or a PLC that needs several milliseconds of scan time before it answers, a longer timeout is the correct setting and that tight pair would declare misses on healthy replies.
Does swapping in a spare panel settle the diagnosis?
Only partly. In this pattern a spare panel reproduced the same two or three dropouts a day, which moves the search toward settings and the shared supply and away from one defective unit. Each swap costs downtime and leaves both panels on the same feed, so run the read-back of the timeout and poll time and the separate-supply test first.
Do those timeout and poll time values apply to a network driver too?
Treat them as serial-port numbers. Network drivers on the same panels carry their own timeout fields with different scales, and a value that suits a 9600 baud cable says nothing about what a network driver expects. Set network timing from that driver's own documentation, then read the values back from the running panel the same way.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.