Replace a failed PLC operator panel without a protocol mismatch

Which protocol decides the replacement panel?

The protocol configured on the controller's communication channel decides the panel, not the processor model: on an SLC 5/02 that channel runs DF1 point-to-point serial, commonly at 9600 baud, or DH-485 multidrop at up to 19.2 kbaud, and the replacement must support the one you find. One model of controller can serve either protocol from the same port, because the channel configuration, not the hardware, sets the mode. That is why the failed unit tells you less than the channel screen does: the dead panel may have been a text panel on DF1 or a network node on DH-485, and the replacement question is identical in both cases, namely which protocol is live on the wire. The number of panels that failed changes nothing here; one dead panel and three dead panels lead to the same first step, which is naming the protocol in service.

What is the difference between DF1 and DH-485?

DF1 is a point-to-point link where one controller port serves one panel and no network addressing is managed, while DH-485 is a token-passing network on RS-485 daisy-chain wiring that carries up to 32 devices with node addresses 0 to 31 and needs termination at both ends.

The data rates come from the two protocol documents: the DF1 protocol reference manual covers configuring the serial data rate, and the DH-485 communication interface documentation carries the network baud rate among its configured settings. The distance figures are general planning numbers with their basis in the interface standards: RS-232 was specified for short runs, and RS-485 design guides trade cable length against data rate, which is why the slower network reaches farther.

Can a DF1-only panel join a DH-485 network?

No. A panel whose documentation lists DF1 only has no DH-485 network driver and no node address setting in the 0 to 31 range, so it cannot join a DH-485 segment at any baud, and no wiring change adds the missing driver. The barrier is the driver, not the baud setting: DH-485 devices share one wire pair by passing a token, and a panel built without the network side has neither the token handling nor the address field its project software would need. Check the supported-protocol line in each candidate panel's documentation before you order. Screen style is a weak hint, so read the list rather than sorting by it: text-only panels commonly list DF1 alone, and many graphic panels list both DF1 and DH-485, but every model stands or falls on its own datasheet. If the channel turns out to run DH+ or RIO, neither protocol in this table applies and the panel must be documented for that network specifically.

How do you identify the protocol already on the machine?

Read it from the machine before you order: the controller's channel configuration names the mode and data rate, the wiring tells you RS-232 from RS-485, and a panel that shares one twisted pair with other devices is on a DH-485 network, not DF1.

1. Open the channel configuration in the controller's programming software. The mode field names DF1 or DH-485, and the data rate sits beside it.
2. Read the wiring when the software is not at hand. A single serial cable between the controller cabinet and the panel points to DF1; a twisted pair running cabinet to cabinet with termination at the two ends points to RS-485 and DH-485.
3. Count the devices on the link. One panel on a port is point-to-point; a controller and several panels sharing one pair are a multidrop network.
4. Open the old panel project files if they survived. The project names the driver the dead panel used.

In the DH-485 interface documentation the network baud rate is Parameter Number 1 in the settings list, so reading the settings from any live device on the segment gives you the rate in use. The full connection path from port to terminator is laid out in connecting an operator interface to a PLC over DH-485, and connecting a PC HMI to a PLC over serial or Ethernet covers the wider job of matching a link type to two devices.

What settings must the new panel match?

Match four values, and read each one from the channel configuration rather than guessing: the protocol, the data rate it shows, a node address no other device holds, and the port's parity and stop-bit settings.

• Protocol: the mode named in the channel configuration. This is the value that disqualifies a panel outright.
• Data rate: the value shown beside the mode. Set the panel to what you read; for scale, an RS-485 segment plans to roughly 1,200 m at low data rates but only about 12 m at the standard's 10 Mbps maximum, so a guessed high rate costs cable margin and compatibility together.
• Node address: a free address for a DH-485 panel. A duplicate disrupts the segment, and every device connected at the time counts toward the limit. Addressing several panels and PLCs on DH-485 shows how to lay the addresses out.
• Port parameters: parity and stop bits from the same channel screen.
• Termination: at both ends of an RS-485 pair, per the panel and controller documentation.

Scenario: two machines, two protocols, what do you order?

Take a plant with two machines: one saw whose controller feeds a dead text panel over one serial cable at DF1 and 9600 baud, and one packaging line whose controller shares a DH-485 network at 19.2 kbaud with three panels, 4 of the 32 slots used, longest run 100 m.

Machine A, DF1. The channel screen reads DF1 with the data rate at 9600 baud, and the serial cable measures about 8 m. Any panel documented for DF1 fits: set its port to the channel's rate, build the project for the controller family, and keep the run inside the 15 m RS-232 planning figure.

Machine B, DH-485. The controller and three panels share one terminated twisted pair; the channel reads DH-485 at 19.2 kbaud, addresses 1 through 4 are taken, and the longest run is 100 m. Order a DH-485 panel and give it address 10, which nothing holds. Check the numbers before ordering: 4 devices on the segment plus the new panel makes 5, and 32 - 5 = 27 device slots still free; the 100 m run sits under the roughly 1,200 m an RS-485 segment plans to at this data rate.

The decision. Machine A takes a DF1 panel set to 9600 baud. Machine B takes a DH-485 panel at 19.2 kbaud, address 10. For spares, one panel model documented for both protocols covers each machine, configured differently per channel.

Recommendation: read the protocol, data rate and node address off the controller channel before you order, then buy one panel model documented for DF1 and DH-485 alike and configure it per machine; a panel picked by screen style is the one that cannot join the network it meets.

What should you check before the machine runs again?

Before the machine runs again, confirm the new project shows live values, every pushbutton produces its documented controller response, and the panel's node does not disturb the rest of the network; do this with the machine in a controlled state so a wrong output cannot start motion.

Rebuild the panel project in the new panel's software. Screens, pushbuttons and value displays do not carry across models, so map each one to the controller data it touched. If the controller program changes screens by writing a register, map that register in the new project too; retriggering the screen-switch register covers the detail that trips most swaps, where the same value must arrive twice to take effect.

Back up the controller program before you touch channel settings. On a DH-485 segment a data-rate change lands on every node at once, so the old program and old settings are your way back.

Commission the panel in that controlled state: confirm live values on a status screen, press each operator command and watch the documented controller response, then cycle power to the panel once to confirm the project comes back; panels that lose their projects after a power cycle explains that failure mode. A panel that powers up with its screens intact but shows no live data is pointing at protocol, rate or address mismatch first, and page on why an HMI can show nothing while the PLC still runs walks through that separation.

What should you send with the panel order?

Send the vendor three things with the order: the channel settings you read off the controller (protocol, data rate, node address), the old panel project files if they exist, and the number of devices already on the segment so the vendor confirms a free address within 0 to 31. Those three items let the vendor confirm the model variant and the address before anything ships. Add the cable run length for a DH-485 order, because the segment total decides the margin, and note the cabinet's worst temperature, because panels carry an operating range and the enclosure adds to it; read the datasheet rating against the measured cabinet temperature.

If the machine's channel turns out to be DH+ or RIO, the order changes: choose among panels documented for that network and verify the interface in the model's documentation before purchase. If the controller itself is the next thing to fail, the second path is replacing processor and panel together on a current protocol, which restarts this selection with the new controller's channel as the deciding document.

One thing this order is not: a signage display. If the cell also needs a board that only presents information, such as a shift target or an andon-style count, that is a separate screen; our panel-mount displays play images and video offline from a memory card, and no signage panel is a substitute for the operator interface that exchanges data with the controller.

Questions