Connect one operator panel to two PLCs over DF1 and Ethernet

What you need

• Two device definitions in the panel project. This job names them DEV1 for the first controller and DEV2 for the second, and the screens and diagnostics use those names from here on.
• A serial cable for DEV1. DF1 is an asynchronous, byte-oriented protocol carried over RS-232, and the panel's serial port reaches the first controller's unused 9-pin RS-232 port with it. Build the cable to the pin lists both manuals print; some pairs want a straight cable, some a null-modem crossover.
• The first controller's serial channel settings. Copy the communication rate, framing and any station or node values from the controller's own configuration into DEV1. If that port has never been used, its channel may already run a compatible DF1 setup or may need configuring first, and the panel's link status settles which case you are in within seconds.
• The second controller's Ethernet card and its target address. The card's own configuration prints what DEV2 must target: an IP address on some cards, a node or hardware address on others. Enter what the card shows.
• A trusted reading for every value. The data table access module already shows machine position, and the small display at the work area already shows the second controller's faults. Those screens are the reference the new panel has to match.

Set up the two device definitions

Each device definition binds one driver to one physical port and carries its own target address and tag list, so the panel talks to the two controllers independently and a fault on one path never blocks the other.

1. Create DEV1 with the DF1 driver bound to the panel's serial port, and cable it to the first controller's 9-pin RS-232 port.
2. Match every serial setting in DEV1 to the controller's channel configuration: same communication rate, same framing, and the station or node values the DF1 driver asks for. Read the values from the controller program; do not guess one.
3. Create DEV2 with the second controller's driver bound to the panel's Ethernet port, and enter the Ethernet card's target address.
4. Enter tags device by device. Machine position comes from the first controller as N7:1. Fault bits come from the second controller's data files, at the addresses its program already uses.

A project that loads cleanly has satisfied the editor, nothing more. The wire gets its test on the machine, one path at a time, in the steps below.

The same structure scales to more controllers: each one stays its own device with its own tags, as laid out in pointing one HMI panel at multiple PLCs with per-device tags.

Set N7:1 as a signed 16-bit integer

N7:1 addresses element 1 of integer data file 7 in the first controller: the N stands for an integer file, 7 is the file number and 1 is the element. Its data type is a signed 16-bit integer, stored as a two's-complement signed word spanning -32,768 to 32,767.

The wrong type reads the same bits as a different number. Unsigned 16-bit turns a negative position into a large positive one, and BCD applies an entirely different digit encoding, which is why a mismatched register throws numbers that make no sense on screen. That failure pattern, and how to trace it, is covered in why an HMI panel shows nonsense numbers from a PLC BCD analog register.

Use the full address with file and element, exactly as the controller program prints it, and select signed 16-bit. When a link is online and a value still reads wrong, check the address and its data type first, then the scaling on the screen object. A right data type still shows counts if the program stores counts, so take the units and any scaling from the program and verify them against a trusted screen.

Never rewrite a controller value to make a misconfigured object look right.

Bring one path online at a time

5. Load the project to the panel and power both controllers. Watch DEV1's communication status on its own. An offline serial device points to the port, the cable, the settings match or the device selection; leave addresses and data types alone until the link is up.
6. With DEV1 online, put N7:1 on a test screen and compare it against the data table access module's position reading while you watch both. A match keeps the signed 16-bit setting; a mismatch sends you back to the address, the type and the scaling, in that order.
7. If DEV1 stays offline and the diagnostics report framing or NAK activity, the two ends disagree on the serial settings; fixing DF1 NAK errors and PLC comm timeouts walks that fault to ground. Before you pull the permanent cable, check the planned run against the serial distance limits set out in how far an HMI can be from the PLC on DF1 RS-232.
8. Move to DEV2. Check the Ethernet card is installed and the cable seated, then read one fault bit you already know from the small display at the work area and check the two screens agree. Judge each device on its own status; one path being up says nothing about the other.

Keep these first checks to reads. Writing to a controller address is a later, deliberate step, and the discipline for it, testing writes before motion, is set out in operator panel PLC link setup: test writes before motion.

How to check it worked

• DEV1 and DEV2 each report their own online status, and both are up.
• N7:1 on the new panel matches the data table access module's position reading, value for value, including a negative reading if the machine produces one.
• A known fault bit shows the same state on the new panel and the small display at the work area, exercised under an approved, safe machine condition.
• Every fault label is rewritten in plain words the operators use; readable labels are the point of the swap.
• The old display stays mounted and powered until the new panel has matched it, so the machine is never without a fault display during the changeover.

Recommendation: Build the panel project as two device definitions, DEV1 on DF1 over the serial port to the first controller and DEV2 on Ethernet to the second, and commission DEV1 to a matched N7:1 reading before you touch DEV2. Enter every address from the controllers' own programs, with position at N7:1 as a signed 16-bit integer, and keep the first checks to reads only. Leave the old display mounted until the new panel matches it value for value, and size the fault labels by the worked example below before you draw the screens.

Example: sizing fault text on the 6-inch panel at the work area

Inputs. The panel being replaced sits 10 ft from the operator work area; that is the distance this job starts from. The new 6-inch panel mounts at the work area, and the example assumes the operator reads it from about 3 ft; measure your own stand-off and move the numbers with it. The planning figures come from the FHWA legibility rule: 30 ft of viewing distance per inch of capital letter height, and 20 ft per inch where the text must read at a glance, with line spacing at 1.7 x the capital height.

Rule. Minimum capital height in inches equals viewing distance in feet divided by the planning figure in feet per inch.

Arithmetic. At the old spot, 10 ft: 10 ft ÷ 30 ft/in = 0.33 in capitals on the standard figure, and 10 ft ÷ 20 ft/in = 0.5 in for reading at a glance. At the work area, 3 ft: 3 ft ÷ 30 ft/in = 0.10 in on the standard figure, and 3 ft ÷ 20 ft/in = 0.15 in at a glance. Line spacing at the work area: 1.7 x 0.15 in = 0.26 in between lines.

Result. Fault capitals of 0.15 in meet the glance figure at a 3 ft stand-off; 0.2 in adds margin for an operator standing a step further back.

Decision. Hold every fault label and the position digits on the 6-inch panel at 0.2 in capital height or larger, with 0.26 in line spacing. If the panel ever moves back to the old 10 ft spot, the minimum rises to 0.33 in, and to 0.5 in for reading at a glance. A 6-inch panel carries that, so set the text style once and check the longest label fits before you commit the layout.

Questions