A DH-485 communication timeout means the HMI sent its request and no device replied inside the panel's configured wait period. On a link that died during a machine shutdown, check the processor's operating state and fault status first, then the cable, then the node addresses and the 19200 baud setting, changing one thing at a time.
A DH-485 communication timeout means the panel sent its request and no device answered inside the panel's configured wait period. The message names the reply that never came; the history tells you where to look. This link ran until a maintenance shutdown, so the cause is almost certainly something that shutdown touched: a processor sitting stopped or faulted after its power cycled, a connector left unseated, a node address that changed with a swapped processor, or a programming laptop still attached to the network. Work them in that order, one change at a time, and wait out the panel's reply period after each change before judging the result. This page gives the order, the numbers that govern a DH-485 link, and the arithmetic that rules a slow network out.
What the timeout tells you
The panel transmits a request addressed to one node on the link and starts its wait clock. A reply inside the period updates the display. No reply inside the period raises the timeout, tagged with the name of the PLC connection in the project, something like plc01. That tag is an address label for the connection, not a diagnosis.
The useful split is between a missing reply and a rejected reply. A device that received the request but could not act on it answers with an error response, and panels show that as a different code; on DF1 serial links the same family of failures appears as NAK errors, and fixing DF1 NAK errors and comm timeouts on serial HMI links covers that branch. The same split runs through Modbus RTU no-reply and address errors: no reply and a bad reply lead to different work.
Symptoms and what each points to
- Timeout on every poll, starting right after the restart. The link broke between the last good run and the restart. The suspect list is the shutdown's own work list: processor stopped or faulted, connector not reseated, address changed, laptop attached.
- One panel times out while other devices still exchange data. The processor and trunk are alive. Work the failing panel's cable, port, project and address.
- The timeout comes and goes. A marginal connector, noise picked up along a disturbed cable route, or a wait period too tight at busy moments. The article on intermittent HMI communication timeouts separates those.
- An error code instead of a timeout. A reply came back and was rejected; follow the NAK path above.
- Every device on the link is silent. The processor is stopped or faulted, or the trunk itself is broken at a junction the repair disturbed.
Start with what the shutdown touched
A shutdown is evidence. Write down what the repair changed before running any test: which cabinets were opened, which connectors were pulled, whether the processor was swapped or re-configured, whether a laptop was attached, whether a trunk junction or an end-of-line resistor moved. Two items account for most restart timeouts. First, the processor: a machine shutdown cycles its power, and a processor whose communication configuration did not survive the power-off comes back on defaults and answers nothing while looking fully powered. Second, the panel project: a power cycle can leave a panel with a lost or half-loaded project, which the article on an HMI panel that loses its project after a power cycle covers.
Read the indicators before changing a setting: panel power and backlight, the processor's mode indicator in its normal run state, and any fault code it displays. Follow your site's lockout procedure before opening the cabinet or handling connectors.
The deciding question before you change anything
Can any other node on the network still exchange data with the processor? If a second panel or a programming station polls successfully, the processor and trunk are healthy and the fault sits on the failing panel's side. If nothing talks to the processor, the work belongs on the processor and the trunk. That one observation halves the job, and you can answer it before the first setting is touched.
The numbers that govern a DH-485 link
DH-485 is a token-passing link on RS-485 hardware, and its governing numbers are fixed:
- Data rate: 19200 baud. The specification offers one speed. If your panel driver asks for a baud figure it must read 19200; if it has no speed field, there is nothing to set.
- 32 devices, node addresses 0 through 31, each unique. Two devices sharing an address disrupt each other's traffic, and the link behaves as if it were dead. The layout rules for handing out addresses on a shared link are in DH-485 node addressing for several panels and PLCs.
- Total span: 4000 ft (1219 m), the maximum the specification allows. A trunk extended during a repair past that span runs marginal; a rebuilt shorter run is safe on this count.
- Termination: 120 Ω across the pair at each physical end. Standard RS-485 practice, matching the roughly 100 to 120 Ω characteristic impedance of the twisted pair used on these links. An end resistor left off after a junction moved shows up mostly as intermittent errors.
- Extra initiators. A computer running programming software is an initiator on the data link, so a laptop left connected since the repair adds its turns to every pass of the token. Disconnect it and retry.
Worked example: a 69 ms exchange against a 5 s wait
Scenario: a panel at node 4 polls a processor at node 1 over DH-485, and the panel project sets a reply wait of 5 s. During a repair the processor was replaced, and the new one went in at node 3. Power returns, the panel addresses node 1, and no device on the link holds that address. After 5 s the timeout appears.
The arithmetic rules speed out. At 19200 baud with 10 bits per character (start, 8 data, stop), the link carries 19200 ÷ 10 = 1920 characters per second. A read request of 36 characters takes 36 ÷ 1920 = 0.019 s, about 19 ms. The 96-character reply takes 96 ÷ 1920 = 50 ms. One exchange consumes about 69 ms of bus time, roughly 1.4 percent of the 5000 ms wait. Nothing about traffic turns 69 ms into 5000 ms; when the wait expires, the reply never existed.
Set the processor back to node 1, or re-target the panel project to node 3, and polls resume on the next request. With the driver at 19200 and the path verified, a standing timeout leaves two candidates: an addressed node that is not there, or a broken path. The indicator check in the section above tells you which.
Work the link in this order
- Processor state. Mode indicator in its normal run state, no active fault. Recover a faulted processor by the machine's established procedure, then re-poll.
- Power at both ends. Panel powered with its display lit, processor powered, and any interposing supply between cabinet power and either device showing its output present.
- Connectors. Reseat the link connector at the panel and at the processor, and confirm each plug lands on the DH-485 port, not a neighboring serial port. Look for bent contacts and for damage along the route the repair disturbed.
- Cable test. Substitute a known-good link cable or test continuity on the existing one. A visual inspection will not find an open conductor.
- Settings. Panel target address against the processor's actual address, each unique on the link; driver baud at 19200; reply wait read from the project, not assumed.
- Extra initiators. Remove the programming laptop from the network and retry.
- Termination. Confirm the end-of-line resistor sits across the pair at each physical end, especially where a junction was moved during the repair.
After each step, wait out the panel's reply period and watch for values that move. One change per attempt keeps the result honest, and a written note of each change keeps a second fault from hiding the first.
Recommendation: on a DH-485 link that died across a machine shutdown, read the processor's operating state and fault indicators before touching hardware, reseat and test the cable second, and compare the node address and driver baud third, changing exactly one thing between attempts and waiting out the panel's reply period each time. When another device still exchanges data with the processor, leave the processor alone and confine the work to the failing panel's cable, port and project.
Return it to service
Verify with moving data. Watch displayed values change against the machine, let the panel run through a normal production cycle and about an hour of running, and check the panel's diagnostics for clean exchanges with no new timeouts. Confirm what the machine did while the link was down: outputs that held their last state through the outage each need a check before restart, and fixing an HMI communication timeout when outputs hold state walks that verification. If the timeout reappears intermittently a day later, the link is still faulty; inspect connectors and termination while the fault is present.
A separate board for line status
The timeout lives on the controls link, and a line-status board needs no PLC link at all. We build shop-floor signage boards that play recorded content offline, with no PLC connection to time out, which suits shift notes, schedules and andon-style status pages alongside the HMI.
Questions
Is there a faster baud setting for DH-485?
No. DH-485 runs at a fixed 19200 baud; the specification offers one speed and no alternatives. The wrong speed shows up in the panel driver: some DH-485 drivers ask for a baud figure, and any value besides 19200 leaves the panel deaf to the network. If the driver has no speed field, there is nothing to set, and the timeout lies elsewhere.
How many devices can share one DH-485 network?
Up to 32 devices, at node addresses 0 through 31, with the whole run held inside the 4000 ft (1219 m) span the specification allows. Every address must be unique: a panel and a processor sharing one address disrupt each other's traffic and stop the exchange. Count the devices and their addresses on the drawing before you add another panel.
Every check passes and the panel still times out. What next?
Split the link. Connect a programming terminal or laptop to the network and address the processor from it. If that exchange succeeds, the processor and trunk are healthy and the fault is on the panel side: its cable, its port or its project. If nothing talks to the processor either, the work belongs on the processor and the trunk ends, starting with its mode and fault indicators.
Can a tight reply wait cause false timeouts?
Yes, during heavy traffic. If the timeout appears only while several programming devices are active on the network, the wait period in the panel project is the place to look. The worked example shows a normal exchange needs about 69 ms of bus time, so a 5 s wait carries a wide margin. Lengthen the wait only after the state, cable and address checks have passed.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.