SCADA connection to a PLC when an HMI panel holds the port

Can a SCADA PC and an HMI panel share one PLC serial port?

No. An RS-232 port is a point-to-point link between exactly two devices. The panel already holds the master seat on yours: it polls, the CPU port answers as an SNP/SNPX slave, and no second master gets onto that cable.

RS-232 defines one transmitter and one receiver per line, which is why the port was never built for a third device. The standard's practical reach is about 15 m at 9600 baud, so the cable is short and dedicated by design. Your SCADA computer would be a second master: it wants to poll the PLC exactly the way the panel does. A slave port answers the conversation it is given; it has no schedule for taking turns between two masters, and the serial protocols involved define none. Y-cables and port splitters multiply wiring, not conversations. They leave two transmitters driving into hardware built for one.

Multidrop serial wiring changes the picture only for slaves. RS-485 lets one master poll several devices on one cable pair over runs up to about 1200 m, which is the case in wiring one HMI panel to three PLCs on an RS422 multidrop. Your PC is a second master, so the same arithmetic applies in the other direction.

The port count is simple: two devices fit, three do not. When a PLC simply runs out of ports, the fix is the same either way: a second interface, added beside the first.

Can the SCADA software pull its data from the HMI panel instead?

No. A SCADA package reads PLCs through driver objects, and its object documentation lists drivers for PLC protocols. An operator panel keeps its tag list inside its own project and offers no data feed to a second client.

An operator panel is an endpoint. Its project holds addresses and data types for the values it shows, and the panel uses them for its own polls; nothing in that design hands a copy to another program. Copying the panel project's tag list onto paper is still worth doing: it tells you exactly which PLC values matter, which becomes your point list. The values themselves have to come from the PLC.

The Ethernet shortcut fails for the same reason. An Ethernet card sold to link a panel to an H2/H4-ECOM module in a PLC rack has that link as its documented purpose. It is not a server that publishes panel data to the SCADA PC, and a panel connection appears nowhere in the SCADA package's driver list. Changing the panel applications moves nothing on the PC side. The missing piece is a PC-to-PLC path, so the engineering change belongs at the PLC.

What adds a second communication path to the PLC?

One added interface per PLC: built-in Ethernet on the CPU where it exists (the IC693CPU374 is a documented example in the Series 90-30 family), an Ethernet Interface module, or a serial slave module such as a CMM set for RTU slave.

Leave the CPU's own serial port alone in every case: it answers as an SNP/SNPX slave, and that conversation is your panel's. Choose Ethernet where you can, because one network card on the PC serves every PLC on 100 m segments per switch hop, while serial needs one PC-side port per PLC. Over Ethernet the family carries its own SRTP protocol and, on interfaces that provide it, Modbus/TCP. Match the module to whichever your driver wants. Before ordering anything, open the SCADA package's driver list and confirm the protocol appears in it: the module, the protocol and the driver have to line up, and the driver list is where that check costs nothing.

What does the SCADA software connect through?

The PC side always runs through software: a driver object or an IO server inside the SCADA package, or an OPC server the package reads, configured as one instance per PLC.

A workstation-to-PLC link never exists as bare wire. The SCADA package builds its process from objects, and the PLC connection is one of them: you pick the driver for the protocol, give it the path (a serial port or a network address), and bind values to it. Where the package works through OPC, the OPC server takes the PLC side and the package takes the values. Confirm the server supports the exact interface and protocol you installed, and confirm your package version talks to that server. Both checks are one call to the vendor's support desk, and both are cheaper than a module no driver can address. The basics of the PC side, serial or Ethernet, are in connecting a PC HMI to a PLC over a serial protocol or Ethernet.

What do you need before you start?

Three inventories: the rack (installed modules, the port serving each panel, free slots), the panel-to-PLC map, and the point list of PLC values the SCADA screens need, with addresses and data types.

Write each one down before hardware shopping:

• Rack inventory. For every PLC: the CPU type, every communication module in the rack, which port the panel cable lands on, and which slots are empty.
• Panel-to-PLC map. Three panels and three PLCs usually means one panel per PLC, but confirm it; a shared PLC changes how many paths the PC needs.
• Point list. The values the PC screens, alarms and calculations need, each with its PLC address, data type, and whether the PC may write it. The panel project's tag list is a good source.
• Software side. The SCADA package's driver list and version number, so the protocol you pick is one the package can address.
• Physical side. A switch port for Ethernet, or a serial cable cut to the run length and a PC-side port per serial path.

If a floor-facing status board is also on your list, that is a different device from this PC link; the factory status display or operator HMI comparison sorts out which job a signage display does.

How do you install and configure the second path?

Work one PLC at a time and keep every panel link in service throughout. Add the PC path beside it: fit the hardware, configure both ends, and bind a first test value before you build the full point list.

1. Keep the panel link untouched. Note which port its cable uses and do not move it; every step below adds, none replaces.
2. Fit the interface. Internal Ethernet needs nothing in the rack; an Ethernet Interface module or a serial slave module (CMM as RTU slave, or an RTU900/RTU940) goes in per its manual, with power off at the rack.
3. Configure the PLC side. Set the protocol and node address on the new interface, serial baud where it applies (9600 baud is a common starting point for a Modbus RTU link), and record the register map the PC will read.
4. Configure the PC side. Add one driver or IO server instance per PLC, pointed at the address you recorded, and leave the panel's connection settings alone.
5. Bind a first test value. Pick two or three PLC values you can watch change at the controller, bind them on a test screen, and get them reading correctly before the full build.
6. Repeat per PLC. Expect differences between racks; a setting that worked on the first CPU is a guess on the second until you check it.

Keep the link read-only unless control writes are explicitly required and a reviewed change covers them: a SCADA write into a running machine is a design change, not a screen edit.

Example: three panels and one SCADA PC, which ports does the job need?

Three panels, three applications, three Series 90-30 PLCs, one PC. The port count decides the hardware:

• Occupied: 3 CPU serial ports, one per PLC, each answering its panel as an SNP/SNPX slave. Free serial ports: 0.
• Needed: 3 PC paths, one per PLC: 3 PLCs x 1 path = 3.
• Ethernet case: each CPU has internal Ethernet (the IC693CPU374 class). Modules to buy: 3 CPUs x 0 = 0. PC links: 3, over one switch on 100 m segments. Driver instances: 3.
• Serial case: each CPU lacks Ethernet. Modules: 3 PLCs x 1 (a CMM as RTU slave, or an RTU900/RTU940) = 3. PC serial ports: 3, one per module, each cable held under the roughly 15 m RS-232 reach at 9600 baud.
• Mixed case: one CPU without Ethernet: 1 module, 1 PC serial port, 2 network links.

Each Ethernet Interface carries up to 16 channels, numbered 1 to 16, so one SCADA path per rack uses 1 and leaves 15 for growth. The decision falls out of the count: 0 modules where Ethernet is built in, 1 module per serial-only PLC, and the panel links stay exactly as they were in all three cases.

How do you check the new path works without disturbing the panels?

Confirm each new link with the panel still running: bind one known value, force a change at the controller, watch it arrive at the PC, and run both paths together through a full 8-hour shift.

• Panel keeps polling. Its link is untouched hardware on an untouched port, so silence after the change means the new work displaced something: recheck the port and module assignments first. A serial link that goes quiet with its light out matches an HMI to PLC serial timeout with a dead com light.
• Value changes end to end. Force a known value at the controller and watch it arrive at the PC; a correct read of a moving value beats a static one.
• Values arrive but read wrong. That is an address or data type mismatch, not a connection fault; the BCD analog register that shows nonsense numbers is the classic case.
• PC cannot connect at all. Check in order: physical link, node address, driver configuration. Leave every panel application alone until those three are confirmed.
• Both paths run together. Leave panel and PC talking through a full shift; a link that works alone and drops under both loads points at configuration, not wiring.

Recommendation: Put the SCADA PC on Ethernet wherever the CPU already has it built in, add one serial slave module per PLC where it does not, and leave every panel link exactly as installed; confirm your SCADA package's driver list covers the chosen protocol before ordering hardware, and run the link read-only until a reviewed change calls for writes.

Questions