When an HMI communication timeout coincides with outputs frozen for up to 5 seconds, the PLC suspended its scan and stopped answering the screen in the same instant, so the PLC's power and CPU lead the suspect list. Secure the process, capture the supply with a power line monitor, read the CPU diagnostics at each alarm minute, and work the communications path only once the supply has held steady.
A touchscreen that reports a communication timeout while the physical outputs sit frozen at their last state is showing one event, not two. The PLC suspended its scan: it stopped writing outputs and stopped replying to the screen in the same instant, so valves and dosers held wherever they were for up to 5 seconds while the process kept running. That combination puts the PLC's supply and CPU at the top of the suspect list and leaves the screen at the bottom. The order of work below secures the process first, then separates a power stop from a link fault with evidence: a power line monitor on the PLC feed and the CPU diagnostics at each alarm minute, followed by the repair the capture names.
Why do outputs hold their last state while the HMI shows a communication timeout?
Because the PLC stopped executing its scan and stopped answering the screen in the same instant, every output latched where it was for up to 5 seconds, and the frozen outputs, not the alarm, name the PLC as the side that stopped.
A PLC spends its cycle reading inputs, executing logic, writing outputs and answering the screen. Suspend that cycle and the output modules hold the last states they were given, the screen keeps polling into silence, and the timeout alarm appears. Panels word the alarm their own way; one common family prints the code PLC-001. The alarm and the frozen outputs share a cause, and the screen's own health is not in question: it kept asking on schedule, which is all a healthy panel does. Reset or replace the screen last, after the PLC side is cleared.
What do you do the moment the alarm hits and the process keeps running?
Apply the site's controlled-stop procedure and check every tank level and batch against its target before releasing production, because an output window frozen for up to 5 seconds can keep a fill valve open long enough to overfill a tank.
The timeout clearing and the screen repainting say the link is back; they say nothing about what the outputs did during the gap. Weigh or quarantine the affected tanks and batches under the site procedure, then log the alarm time to the minute while operators remember it: which outputs held, how long the screen showed the alarm, whether the PLC power indicator blinked. That record costs a notebook line and is what you line up against the monitor capture later.
Is the fault in the PLC's power or in the communications link?
The frozen outputs settle it: a communications fault cannot latch a physical output, so a timeout with outputs held for up to 5 seconds puts the PLC supply and CPU first and the link second, while a timeout with every other value still updating stays a link problem.
Read the event, then pick the branch:
- Timeout alarm and outputs frozen together: the PLC suspended. Work the supply capture and CPU diagnostics first.
- Timeout alarm with the PLC indicators normal and other stations reading fresh values: the link. Work the communications checks.
- PLC power indicator out, or a restart in the CPU log at the alarm minute: a supply interruption, and the capture below applies.
- Alarm at the same time each shift, or whenever one large machine starts: a load event on a shared circuit; write those start times next to the monitor record.
- Screen blank or frozen at the same minute as the PLC: two devices down together point to a supply upstream of both.
Pull the CPU diagnostics with the programming tool and the PLC's own documentation, and record any power-down restart, CPU fault or mode change with its timestamp. Where the timeouts come and go on no schedule at all, why an HMI shows an intermittent PLC communication timeout covers the running-PLC branch in detail.
How do you capture a brownout on the PLC supply?
Fit a power line monitor on the PLC's own feed, as close to its power terminals as you can reach, and leave it through at least 7 days of production, because a dip can arrive and clear inside one half cycle of mains, 8 ms at 60 Hz.
A handheld meter read after the event samples steady voltage, and the dip is gone by then. A line monitor records the trough voltage and its duration as it happens, which is the record this diagnosis turns on. Before you judge the capture, read the PLC's documentation for its supply tolerance: a trough above the documented minimum clears the power side, and a trough below it names the repair. Inspect the supply terminals while the panel is locked out, and write down the start times of any large machines sharing the circuit.
Keep a screen on a feed separate from the PLC so one dip cannot silence both devices. Where a screen mounts in the same cabinet, a 24 V DC DIN-rail supply feeds it from a low-voltage circuit. Two neighboring faults are worth a read: why a shared DC supply with solenoid coils freezes an HMI covers noise from shared low-voltage loads, and the power-first check for a blank, frozen HMI applies the same order to a screen that dies outright.
Scenario: what does a captured dip look like in numbers?
Suppose a 240 V feed at the PLC dips to 168 V for 0.2 s, and the CPU fault log records a power-down restart at the same minute as the screen's timeout alarm; that combination names the supply as the cause of this installation's stops.
Carry the two numbers through:
- 168 ÷ 240 V = 0.70, so the trough sat at 70 percent of nominal.
- 0.2 s × 60 cycles per second = 12 cycles of mains spent below the level the PLC's documentation allows.
A trough at 70 percent of nominal lasting 12 cycles is a brownout, and PLCs, like every semiconductor device, are sensitive to low voltage. With the CPU restart tied to the same minute, the power side is the cause to work here: move the PLC to a feed without the large motor starts, or add conditioning sized to the captured trough and duration, then leave the monitor in place to verify the troughs are gone.
The opposite result decides the other branch. A week on the same 240 V feed records a worst trough of 236 V: 236 ÷ 240 = 0.983, within 2 percent of nominal, and the CPU log stays clean. The supply held, so the timeout belongs to the link, and you work the next section one change at a time.
Recommendation: Leave the screen and its project untouched until one event is captured in full: a line-monitor record on the PLC feed spanning at least 7 days of production, plus the CPU status at every alarm minute. A trough below the PLC's documented supply minimum sends the repair to the power side; a steady supply with a clean CPU log sends it to the link, one change at a time.
What do you check on the link when the PLC never stopped?
Change one thing at a time and only once the monitor shows a steady supply: first the driver and protocol family in the HMI project against the PLC port's documented protocol, then the baud and port settings, then addressing, then the tag list.
Clear the documented causes in this order, and note each change with its date:
- Driver and protocol family: the project must speak the protocol the PLC port's documentation names. One panel family's stubborn timeout cleared only after the project's protocol selection was corrected to match the PLC.
- Baud and port settings: some PLC ports run at a fixed rate, 9600 baud on some models, so an HMI project set faster never receives a valid reply.
- Addressing: a wrong address or subnet on an Ethernet link produces this alarm; put the panel and controller on one documented subnet and check the path with a ping first.
- Tag list: values the project requests that the PLC does not hold fail the request and surface as timeouts.
- Load: the vendor guidance for a no-reply alarm says to check the load on the PLC and the network, because a crowded link delays replies past the timeout interval.
- Firmware: outdated panel or PLC firmware is a documented source of conflicts; update it after the capture, never during it.
For a serial link with the transmit indicator dead, HMI to PLC serial timeout with a dead com light walks the port side, and fix an HMI PLC timeout and invalid checksum error covers the corrupted-reply variant.
What fix keeps the tanks and batches in spec next time?
Repair the side the capture names, then make the process protect itself: give the PLC a feed that rides through the captured dip, or correct the link settings, and design the outputs so a lost or stale output update leaves the fill valve closed and the dosing at zero.
Power-side repair means a feed of its own, or conditioning sized to the captured trough and duration. Link-side repair means the corrected setting from the list above, changed and dated. Then add the protection the process was missing: define what the outputs must do when the PLC stops controlling, and build it in the control program so a lost or stale output update de-energizes the fill valve and zeroes the dosing. Validate that behavior in planned downtime by forcing the condition, and record the result. A communication alarm raised by an HMI is not a safety function, so a screen warning is not that protection. Keep the timeout interval exactly as the project has it configured; it decides when the alarm speaks and nothing else.
How do you verify the fix before the next batch runs?
Verify three things before releasing production: the monitor records no trough below the PLC's documented supply minimum across a full production week, the CPU log shows no stop, and the safe-state test run in planned downtime still closes the valve when you cut the link on purpose.
Keep the monitor installed for one further week of production: zero timeout alarms with a clean CPU log closes the job. A recurrence means the capture repeats with the newest change documented, one change per event, so the next capture names the remaining cause. If the CPU keeps faulting with the supply steady and the link cleared, escalate to the PLC vendor's support with the monitor record and the CPU log in hand; those two files turn a long support call into a short one.
Questions
Can a loose terminal on the PLC feed produce this same fault?
Yes. An intermittent connection on the PLC's supply produces the same signature: the CPU loses power for a few cycles, the outputs latch, and the screen raises its timeout. With the panel locked out and de-energized, check every terminal from the breaker to the PLC's power terminals and re-terminate anything loose or discolored. Leave the line monitor installed; its record then shows whether the troughs stopped after the rework.
Why did the touchscreen keep running while the PLC was down?
The screen and the PLC normally sit on separate feeds, so a dip on the PLC feed leaves the screen powered and polling. The panel received no reply inside its timeout interval and raised the alarm, which is why a healthy-looking screen goes with a stopped PLC. A screen reset therefore treats a symptom and leaves the PLC stop untouched.
Should I raise the timeout interval in the HMI project to stop the alarm?
No. The interval only decides when the alarm appears; it has no effect on how long the outputs hold, because the hold ends when the PLC resumes its scan. Raising it hides a 5 second stop behind a longer silence and slows the warning that sends operators to check the process. Keep the configured value and spend the effort on the capture.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.