DH-485 network node addressing for several panels and PLCs

What one DH-485 trunk allows

DH-485 is a token-passing protocol on an RS-485 differential pair: a device transmits only while it holds the token, and the token travels from node to node. The protocol's design documentation and the DH-485 connection guides that panel makers publish set the numbers that decide this job.

• 32 nodes on one segment, panels and controllers counted together. Three controllers and two panels use 5 of the 32.
• Node addresses 0 to 31, one per device, no repeats, with 31 as the maximum node address.
• Trunk length up to 2500 ft, the published limit for one DH-485 segment, measured end to end.
• Token Hold Factor 1, the default in the panel connection guides. It sets how much a node may transmit each time the token reaches it; a factor of 1 keeps each turn short, so the wait stays short for every other node.

One setting binds the whole trunk together: every device runs the same network baud rate, entered in its DH-485 communication settings. When one device answers and another does not, compare that setting first.

The cousin of this job, one panel wiring out to several controllers over an RS-422 multidrop and polling them in turn, is covered in wiring one HMI panel to three PLCs on an RS422 multidrop. DH-485 adds the token and the node numbers, and the numbers are what let two panels share three controllers.

What you need

• Controllers that speak DH-485. The SLC 5/03 processors do. Whether a given model has a native DH-485 port or joins the trunk through an RS-232 to RS-485 converter such as the AIC+ is written in that controller's communication manual; check it before ordering cable.
• Panels whose DH-485 driver lists more than one controller and takes a node address per controller. A port marked serial is an electrical spec, so the driver list in the panel's manual is the fact to confirm before anything is bought.
• Shielded twisted pair for the trunk, run device to device in one line.
• Termination for two ends. Enable the termination jumper or resistor on the first and last device on the wire and leave the middle devices off.
• A written address list: every device, its node address, its baud setting. It hangs in the panel enclosure and it is the document the next technician works from.

Bring the network up one device at a time

1. Make the address list. Controllers take the low numbers, 0, 1 and 2; panels take numbers well above, 10 and 11; the gaps absorb machines added later. No number from 0 to 31 is used twice.
2. Set each controller's DH-485 settings: its node address from the list, the one network baud rate for the whole trunk, and Token Hold Factor 1 unless that controller's manual says otherwise. These settings sit in the communication channel configuration in the controller's programming software.
3. Wire the trunk through all devices in one line, then enable termination on the two end devices only.
4. Power the first controller alone and read it from the programming software at its node address. With nothing else up, an answer proves the address, the baud rate and the wiring of one device.
5. Add the first panel. In its project, select the DH-485 driver, set the same network baud rate, and enter controller 0's node address. Then read a register you control: write 1234 into an unused integer register on the controller and confirm 1234 arrives on the panel.
6. Add each remaining controller one at a time. Each one becomes its own controller entry in the panel project, named and pointed at its node address, and passes the same known-value read before the next joins.
7. Add the second panel and repeat the reads. If both panels carry similar screens, build them once and reuse them; reusable HMI screens for multiple devices covers that pattern.
8. Test writes last, only where the application needs them and with the machine in a safe commissioning state, so a write aimed at the wrong node cannot move a running output.

Bring-up means many power cycles. If a panel comes back without its project after one, fix that before continuing; HMI panel loses its project after a power cycle is the page for it.

Worked example: three controllers and two panels

A packaging line runs three SLC 5/03 processors and two operator panels on one trunk.

• Addresses: controllers 0, 1 and 2; panels 10 and 11. Devices on the trunk: 3 + 2 = 5 of the 32 allowed, so 32 - 5 = 27 addresses stay free for machines added later.
• Cable: four runs of 85 ft between the five devices, 4 x 85 ft = 340 ft of trunk, inside the 2500 ft segment limit.
• Termination: the device at each physical end of the trunk carries the jumper; the three middle devices have it off.
• Panel projects: each panel lists three controllers by node address, so the build has 2 x 3 = 6 read paths to prove: panel A to controllers 0, 1 and 2, then panel B to the same three.
• Settings: Token Hold Factor 1 and one network baud rate on all five nodes.

The proof read: 1234 written into an integer register on controller 1 comes back as 1234 on both panels, and only on the screens pointed at controller 1. That one check exercises the driver, the node addresses and the trunk at the same time.

How to check it worked

• Both panels show live values from all three controllers, six read paths updating together.
• Change a value on controller 2 and watch the screens bound to controller 2 move while the screens bound to controller 1 hold still. That separates an addressing mistake from a wiring fault.
• One controller unreachable while the rest answer: compare its node address against the list, then its termination position, then its entry in the panel project.
• Devices dropping off at random moments: two of them share a node address. Walk every device against the printed list; the token rotation has no way to tell two devices on one number apart.
• Nothing answers at all: compare the network baud rate screen to screen first, then check the trunk end to end.

A line-status board over the line is a different screen doing a different job: it plays its own content from its own storage and is not a node on the token network, so it adds nothing to the panels' wait. The shop-floor displays section is where to start for that screen.

Serial-to-Ethernet adapters

An adapter that moves serial bytes onto Ethernet is not a DH-485 node: it cannot hold the token, so it cannot select a controller, so the panel behind it sees one cable and no path to controller 0 or controller 1. The Ethernet route exists, but only with a gateway that speaks DH-485 on the trunk side and a protocol the panel's driver supports on the plant network side, with each controller addressed through that gateway in the panel project. All three of those pieces have to appear in the hardware's own documentation before you order anything. Where every panel and controller already speaks DH-485, the trunk is the cheaper build: cable, converters where a model needs one, and node addresses.

The decision

Recommendation: Put every panel and controller on one DH-485 trunk, provided each panel's DH-485 driver can address controllers by node number. Assign the controllers 0, 1 and 2 and the panels 10 and 11, leave the gaps for growth, run Token Hold Factor 1 and one network baud rate on every device, terminate the two end devices only, and bring nodes online one at a time with a known-value read before each next join. Take the gateway route only when a panel cannot speak DH-485 or a controller sits beyond the cable run, and split the plant into routed groups of up to 32 nodes only when one segment is actually full.

Questions