The driver on a replacement operator panel must match the protocol configured on the PLC channel it connects to. DH-485, DH+ and DF1 are separate protocols and a PLC-5 can run any of them depending on the channel setup. Read the channel configuration and buy against it: DF1 point-to-point takes a PLC-5 DF1 driver, DH-485 needs a documented DH-485 driver, and DH+ has no direct serial driver, so plan a gateway route or a documented DH+ interface.
A replacement operator panel for a legacy line fails at cutover for one reason more than any other: the driver was matched to the processor family, and the channel was running a different protocol. DH-485, DH+ and DF1 are three separate protocols, all common on that generation of equipment, and a PLC-5 can be configured for any of them depending on the channel and how the machine was engineered. Read the protocol on the channel the panel talks to, then order against it. This page gives the check sequence, a decision for each protocol, and the bandwidth arithmetic that shows why a matched DF1 point-to-point link is not the bottleneck.
The channel configuration decides the order
The driver on the new panel must equal the protocol set on the channel it connects to. Different channels on the same processor can carry different protocols, so the family name on the cabinet door settles nothing. Open the processor in your PLC programming software, open the channel the panel is wired to, and read the protocol, the station or node address, the baud and the error-check value exactly as shown. Those are the numbers you buy against.
The usual signature of a driver mismatch is a panel that reports connected while every read comes back empty. HMI pings the PLC but reads fail walks that check before you blame the cable.
The three protocols and how to tell them apart
DH-485 is a multidrop network built on the RS-485 electrical standard, the differential shared-bus standard, running at 19.2 kbit/s with up to 32 nodes. It grew up around the SLC family and reaches a PLC-5 through gateways.
DH+ is a token-passing network with its own physical layer: transformer-coupled taps on a trunk, 57.6 kbit/s, up to 64 nodes. It is neither RS-232 nor RS-485, and that is the whole problem, because a serial port on a panel cannot join it directly.
DF1 is a serial protocol running point-to-point over RS-232, a two-device short-haul standard with about 15 m as the classic planning distance. DF1 also has a half-duplex multidrop form, but the documented case for replacement panels is the plain one: one panel to one processor.
Three field checks, in order:
- Open the channel configuration. Its protocol value is the decision.
- Count the devices on the trunk. More than 32 points to DH+, since DH-485 stops at 32.
- Look at the port and the cable. A short RS-232 run to the processor points to DF1; transformer-coupled taps point to DH+.
What each configuration allows
| Channel shows | What it runs | The replacement panel needs | Decision |
|---|---|---|---|
| DF1 | RS-232 serial, one panel to one PLC | A driver documented as DF1 for PLC-5, matched to baud, station address and error check | Order it, prove it on the bench, cut over in a window |
| DH-485 | RS-485 network at 19.2 kbit/s, up to 32 nodes | A current DH-485 driver and a node address | Order only with that driver in the current data sheet, otherwise plan a gateway or bridge |
| DH+ | Token-passing network at 57.6 kbit/s, up to 64 nodes | A direct serial driver, which typical replacement panels do not have | Do not order the DF1 panel for this link; plan a gateway route or a documented DH+ interface |
Example: one panel and one PLC-5 over DF1 at 19200 bit/s
Inputs, and where each comes from: the channel configuration reads DF1 full duplex, 19200 bit/s, 8 data bits, no parity, 1 stop bit, station address 0. That is an example readout; the real values come off your own configuration screen, and yours govern. The main screen of the panel project shows 40 integer values, an example screen size, so count yours. The framing rule is general asynchronous serial practice: 8 data bits, no parity, one start bit and one stop bit make 10 bits per byte.
Rule in words: divide the bit rate by 10 to get bytes per second, then divide the data block size by that rate.
Arithmetic:
- 19200 bit/s ÷ 10 bit/byte = 1920 bytes/s
- 40 registers × 2 bytes per 16-bit register = 80 bytes per data block
- 80 bytes ÷ 1920 bytes/s = 0.042 s, about 42 ms per full-screen read before envelope overhead
Result: even if envelopes and retries triple the airtime to about 126 ms, the link pulls the whole screen roughly 8 times a second. A 1 s update target on the panel leaves the wire idle most of the time.
Decision: at screen-sized transfers the bandwidth is not the constraint, the driver match is. Order the panel whose current documentation lists a PLC-5 DF1 driver for point-to-point use, set the driver to the channel values, and prove it on the bench before cutover.
If the channel shows DH+
Stop the order and choose a route, because the DF1 driver cannot join the trunk: DF1 speaks to a serial port, and DH+ is a token-passing network with its own physical layer.
Route 1 is a gateway module. A DH+ to DH-485 gateway such as the 1785-KA5 bridges the two networks, and the PLC-5 communications manual, publication 1785-6.8.9, documents gateway mode: in gateway mode DH+ devices must initiate messages and DH-485 devices cannot. A polled operator panel on the DH-485 side cannot poll through the module, so the design flips: the processor pushes the data with message instructions and the panel displays what arrives. That brings the timing traps covered in dropped PLC-triggered messages on a serial HMI panel.
Route 2 is a protocol bridge documented for your exact pair of protocols. Bridges carry limits, and the limits that surface when an HMI bridges Modbus RTU and DF1 show the pattern to test before trusting one.
Route 3 is an operator interface documented for DH+ itself, which usually means keeping the existing terminal in service or using a PC interface with DH+ hardware.
Decision: pick one route before the purchase order, and take any DH+ claim from a supplier in writing.
If the channel shows DH-485
Then the panel needs a DH-485 driver, and a DF1 driver is no substitute. Confirm the driver exists in the panel's current data sheet, because driver lists change between software releases. Wiring and addressing have their own rules: connecting an operator interface to a PLC over DH-485 covers the link, and DH-485 node addressing for several panels and PLCs covers the addresses once more than one device shares the network.
Decision: order against a documented DH-485 driver and the node address you recorded; if no current panel offers the driver, the gateway and bridge routes above apply.
What to record and what to ask for
Record from the machine:
- the processor catalog number and the channel number
- the channel values: protocol, station or node address, baud, error check (CRC or BCC)
- the cable path from panel to processor, including every device in between
- a device count on the network trunk
Ask the supplier before the order:
- the exact driver name documented for a PLC-5 over DF1, and the software release that carries it
- whether the driver is point-to-point only or supports multidrop
- the documented cable and electrical interface for that driver on that processor port
- that the baud range covers the channel setting, for example 19200 bit/s
- written confirmation of any DH+ capability
Test writes under control
Bench-test the replacement before the change window: load the project, power the panel from its documented supply, and prove reads against known register values first. Enable operator writes only after reads are stable, only on tags the control narrative marks safe, and only with the machine in a state where a wrong value moves nothing. Keep the old panel wired and its project available as the rollback until operations signs off. A connected indicator is not proof that the mapped tags and write paths are right.
Recommendation
Recommendation: read the channel configuration before you price anything. If it shows DF1 point-to-point, order the panel that documents a PLC-5 DF1 driver, set the driver to the channel's baud, station address and error check, and prove reads and any writes on the bench in a planned window. If it shows DH-485, order only against a current DH-485 driver and a recorded node address. If it shows DH+, hold the order and plan a gateway route with processor-initiated messages, a documented bridge, or a DH+ interface, because the DF1 driver cannot join that network. Once the protocol is settled, the swap procedure itself is in replacing a failed PLC operator panel without a protocol mismatch.
Questions
Can two replacement panels share one DF1 channel?
The documented case is one panel to one PLC-5 over full-duplex DF1. DF1 also defines a half-duplex multidrop form that several devices can share, but support varies between panels and processors and it changes the polling design. A second panel on the same channel is a new design, not an extra cable: confirm half-duplex DF1 in both current manuals and get the topology confirmed in writing with the order.
Once the protocol matches, do the other channel settings matter?
Yes, every one of them. Both ends must run the same baud, data bits, parity, stop bits and error check or the link passes nothing. The channel configuration prints the processor side, and the panel driver setup takes the same values on its side. A baud or framing mismatch shows up as continuous checksum and framing errors, which is a different diagnosis from a wrong protocol selection.
Why do DF1 and DH+ get mixed up so often?
Because they share the same application layer, the message set that moves data between processor and interface. DH+ carries that message set over its token-passing network, while DF1 carries it over a plain RS-232 serial port. Everything above the physical layer looks familiar on paper, which is why a DF1 selection feels like it should work on a DH+ trunk. A DF1 driver talks to a serial port, and the trunk is not one.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.