Yes: one HMI project reads multiple PLCs by holding one device per PLC and selecting that device on every tag. The node list shows which controllers answer discovery, and a tag import writes into one device at a time. Build the four devices first, import each database into its own device, and pass one read-only counter test per PLC before the screens go live.
Yes, one panel can read all four. The pattern holds across HMI packages that support several controllers: the project carries one device per PLC, and every tag names its controller by selecting that device. Four PLCs means four devices. A controller that shows up in the node list is discovered. No tag reads it until a device exists and a tag selects it. This page walks the whole job: what to gather, the devices, the tags, the imports, the serial variant, and the check that clears the screens for the line. If you are still choosing between polling every PLC from the panel and linking them through one controller, settle that first in one HMI reading two PLCs: poll both or link them.
Can one HMI panel read four PLCs through one project?
Yes. A project that reads four PLCs holds four devices, one per controller. Each tag names its PLC by selecting the device in the tag editor, so the panel reads exactly the controller that owns each address. Nothing in a four-controller job forces you to link the PLCs together first.
The device is the connection object in the HMI software: it carries the protocol, the network address and the label. The tag is the reader: it carries two settings, the device it reads and the address inside that device. Both settings right, and the number on the screen is the number in that PLC.
This page covers one panel polling several controllers. When a second panel joins the job, the load math changes; read connecting many operator panels to one PLC without slow updates and two HMI panels polling many PLCs: use a master PLC before you grow the project.
What do you need before you open the tag editor?
You need the four controllers online with fixed addresses, the panel driver that matches them, and a memory list per PLC naming the registers each screen will show. The tag work goes quickly once those three are on paper. Gather them before the first device is built.
- The network plan: on Ethernet, one IP address per PLC, recorded. A private run like 192.168.1.11 through 192.168.1.14 for four controllers keeps the devices straight at a glance.
- The driver: the HMI software offers one driver per PLC family and protocol. Four identical PLCs use the same driver four times. A mixed line needs the driver that matches each controller.
- The memory list: for each PLC, the addresses the screens will read or write, with their register types and engineering units.
- On serial, the station numbers: one unique number per PLC, written down before the wiring starts.
What does the node list actually tell you?
It tells you which PLCs answer discovery on the network, and nothing more. A controller sitting in the node list is found. No tag in the project reads it until you create a device and point a tag at it. Treat the list as step one of two.
| What you see | What it means | Next move |
|---|---|---|
| A PLC appears in the node list | The panel hears it on the network | Create its device in the panel manager |
| A PLC is missing from the list | Discovery cannot reach it | Fix the IP settings, the cable or the controller port before touching tags |
| The PLC appears but a value is wrong or blank | The network path works; the tag's device or address is off | Check the tag's two fields before touching the network |
A green communication indicator makes the same statement as the node list: the path to that controller is up. The tag still decides what gets read. A wrong value on a healthy link sends you to the tag editor, not to the switch.
How do you add one device per PLC?
Open the panel manager in the HMI software, add one device for each controller, and label every device with its machine name. Four PLCs become four named entries before a single tag exists. Numbered, the job is short:
- Open your project in the HMI programming software and open the panel manager, the window that lists the controllers the panel talks to.
- Add a device. Four PLCs on the job means four devices in this list.
- Name each device for its machine: Filler, Capper, Labeler, Packer. The name travels into the tag pick lists, so a clear label now saves clicks on every tag you build.
- Set the connection on each device: the IP address on Ethernet, or the station number and serial settings on a multidrop line.
- Save and read each device's status. All four healthy before the first tag is the cheapest place to catch a mistyped address.
Keep one device per PLC even when all four sit on the same switch. A tag names its controller through the device. Two PLCs behind one device leave the tag with no way to pick between them.
How do you point each tag at the right PLC?
Pick the device in the selector at the top of the tag window first, then enter the address under that device's rules. The device picks the controller, the address picks the register inside it, and a correct tag needs both fields right. The order matters, because the valid address list follows the selected device.
The two fields are independent, and that independence sets your troubleshooting order. Editing the address keeps the tag on its current device, so a copied tag still reads the old PLC until you change the device too. Selecting the right device while an address copied from another controller is still in place reads the wrong register over a healthy link. When a value looks wrong, read the device field and the address field separately.
Name tags for the machine and the signal: Filler_Count, Capper_Speed. With four controllers feeding one project, the prefix is what stops a later screen edit from putting the labeler's speed where the packer's belongs.
How do you import each PLC's tag database?
One import fills one device. The import writes the incoming tag list into the device you have selected, so four PLCs means four imports, and you verify the destination before each one. Newer releases put the destination choice in the import dialog itself. Older releases import into the currently selected device, so select the device first.
Where the dialog offers no destination choice, the discipline is: select the Filler device, import the filler's database, open two or three imported tags and read their device field, then move to the capper. A database that lands in the wrong device reads valid addresses on the wrong controller. That is the quietest fault on an operator screen.
Hand-typed tags close the gap when an import covers only part of a line. Type them against the right device and keep the machine prefix. The hand-built rows then read the same way as the imported rows.
What changes on an RS-485 multidrop network?
The one-device-per-PLC rule stands; the addressing changes. On a shared serial line every PLC needs its own unique station number, and each device in the panel carries that station number with matching baud, data bits and protocol settings. Four controllers take station numbers 1 through 4, written into the PLC ports and the panel devices alike. Every node runs the same line settings, commonly 9600 baud, 8 data bits, 1 stop bit unless your PLC documentation says otherwise.
Confirm two things before you trust the wire: the panel's driver for your PLC family supports addressing several stations on one line, and every node runs identical serial settings. The cable plan, termination and port wiring are their own job, covered in wiring one HMI panel to three PLCs on an RS422 multidrop. Where the network assigns node numbers to panels and PLCs together, the scheme in DH-485 network node addressing for several panels and PLCs shows the pattern.
A serial line adds a failure mode an Ethernet switch hides: one node with the wrong baud or a duplicate station number can stall traffic for the whole line. Set and record the station numbers first, then bring the nodes up one at a time.
Example: four PLCs, four devices and eight tags
Take four machines: a filler at 192.168.1.11, a capper at 192.168.1.12, a labeler at 192.168.1.13 and a packer at 192.168.1.14. The project holds four devices, eight tags and a four-counter check before any operator screen goes live. Every number below comes from that one layout.
| Device label | Controller | Network address | Tags it owns |
|---|---|---|---|
| Filler | PLC 1 | 192.168.1.11 | Filler_Speed, Filler_Count |
| Capper | PLC 2 | 192.168.1.12 | Capper_Speed, Capper_Count |
| Labeler | PLC 3 | 192.168.1.13 | Labeler_Speed, Labeler_Count |
| Packer | PLC 4 | 192.168.1.14 | Packer_Speed, Packer_Count |
The arithmetic of the build: two tags per controller across four controllers is 4 x 2 = 8 tags. Each tag carries two deciding fields, device and address, so the full audit is 8 x 2 = 16 fields to read back. The import runs four times, one database per device. Budget about 5 minutes per import plus a 10-minute field audit, and the whole four-PLC build fits inside an hour. Set a target of a 1 second or faster refresh on the counter screens, a common operator expectation, and check it on the busiest screen. The live check touches one counter per controller: Filler_Count shows 1,204 parts on the panel and 1,204 parts in the PLC programming software at the same moment, so that device passes. The same comparison closes the other three.
How do you prove every tag before the line runs?
Test one known, read-only address on each of the four PLCs. Compare the panel's number against the same address in the PLC programming software. Release the screens once all four match: four passing comparisons settle the four device paths. The full audit follows the same pattern.
- Pick a counter on PLC 1 that increments while the machine runs.
- Put the tag on a test screen or the tag monitor and note the number.
- Read the same address in the PLC programming software. The two numbers must match; let one part cycle and watch both step up together.
- Repeat on PLCs 2, 3 and 4, changing only the device. The address rules stay the same on each.
- Walk the whole tag list and read the device field on every tag, all 16 checks from the example above. Then the screens go back to the line.
Keep every test tag read-only. A tag that writes moves an output on whichever device it points at, and a tag pointed at the wrong device writes to the wrong machine.
Recommendation: build the four devices and pass the four counter tests before any operator screen goes live, importing each PLC's database into its own device and reading the device field on a few imported tags after each pass. If your import dialog shows no destination choice, select the device before importing and hand-type the remaining tags with the machine-name prefix.
Questions
Do I need a separate device for a PLC I only read from?
Yes. Every tag needs a device, and a read-only tag is bound the same way as one that writes: select the device, then the address inside it. A controller you only monitor still gets its own device, because status tags read through the same device field as control tags. Leaving it out of the device list is what sends you back to the tag editor halfway through the build.
Can two devices use the same register number?
Yes. Each device owns its own address space, so register 2010 on the filler device and register 2010 on the capper device are two different tags reading two different controllers. Name each tag for its machine and its signal, like Filler_Count and Capper_Count, and the shared number stops being a trap for the next engineer.
How many PLCs can one panel handle?
The specification sheet for your panel prints the device limit; treat that number as the ceiling. In practice you meet a refresh limit first: every added device carries its own tags and the panel polls all of them, so the busiest screen sets the pace. Four controllers on Ethernet is a light load; a long serial multidrop is where refresh slows first.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.