A panel reads OPC tags only when its documentation lists OPC UA as a communication driver. Most operator panels list PLC protocols instead, so they need a PLC or gateway speaking one of those drivers, and the direct no-PLC path works only for raw I/O states through an Ethernet I/O block with a documented Modbus TCP register map.
You want a panel at each machine, the machine controllers are closed, and an OPC server already holds the data pulled off the remote I/O. The open question is whether the panels can read those tags directly or whether something must sit between them. The answer lives in one document: the panel's communication driver list. This article walks that check, compares the three paths that result from it, sizes the gateway load for 40 panels, and ends with the commissioning order and the ownership rules that keep the write path clean.
Can an HMI panel read OPC tags straight from an OPC server?
Only when the panel's own documentation lists OPC as a communication driver, and most operator panel families list PLC protocols there instead, which leaves the server's tags out of reach however the server is configured.
OPC is a client-server interface: the server publishes tags, and values move only when a client asks for them. SCADA packages and custom PC programs are OPC clients. A panel runtime is built around device drivers for PLCs and other controllers, and the vendor's driver list is the complete set of protocols its screens can speak. Substituting a different OPC server changes nothing, because the panel still needs a protocol from that own list.
The edition that shows up in panel driver lists is OPC UA, standardized as IEC 62541, the edition built to run on small devices. The older Windows-based edition, OPC DA, is effectively absent from panel runtimes.
How do you check whether a panel has an OPC UA client?
Open the panel manual's communication driver list and look for OPC UA; a minority of mid-range and premium panel lines document an OPC UA client, and if the entry is there the panel connects straight to any OPC UA server with no controller between them.
OPC UA turns the panel into a client over ordinary Ethernet. The panel browses the server's address space, reads and writes the nodes it finds, and the protocol carries the security settings. Manuals for the panel lines that ship a client describe the same setup flow: open the connections editor in the panel project, create a new connection, and select OPC UA as the communication driver, then enter the server's endpoint and security settings.
Check two things before planning screens around it. Confirm the entry exists for the exact model and firmware, because driver lists differ between models in one family. Then confirm the client's profile: panel OPC UA clients typically cover value reads and writes, with methods, events and historical access as the usual gaps. A monitoring screen that displays values and accepts setpoints fits a basic client.
The server side needs a node structure the client can browse; we walk one in Set up an OPC UA server in CODESYS for HMI clients.
What works when the panel has no OPC driver?
Put an intermediary between the data and the screens: a PLC or gateway owns the values and speaks a protocol from the panel's driver list, Modbus TCP being the most common, and the OPC server and the reporting application exchange values with that same owner.
The gateway holds the values and translates. The OPC server keeps its job of reading the remote I/O. The reporting application does the database work, looks up which part numbers the loaded recipe allows, and writes the derived strings and setpoint defaults into the gateway. Every panel then reads and writes through its own documented driver, and nothing on the screen depends on OPC.
Keep the two data types apart. Machine spare outputs carry discrete events: cycle active, fault, station busy. Recipe strings, part numbers and integer setpoints are data, and spare outputs cannot carry them; those values move through the gateway path or not at all.
Ownership is one writer per tag. If the operator enters a setpoint, the panel's write lands in a register the gateway owns and the reporting application reads it there.
Choosing that interface is its own decision; Choose a Modbus operator interface for a custom controller walks the matching logic.
When can a panel read machine data with no PLC at all?
Only for raw I/O states: if every value on the screen is a state of the remote I/O block, an Ethernet I/O interface with a published Modbus TCP register map can be addressed straight from the panel's Modbus TCP driver, with no controller in between.
Three documented pieces make the path real: the I/O maker's register map for the exact interface head, the panel's Modbus TCP driver, and a screen whose values are all registers in that map. The maker documents which heads speak Modbus TCP and which registers hold which inputs; verify the pairing before the design is wired around it. If the register map is not published, the path does not exist.
Status lamps, run and fault bits and cycle counters fit this path. Database-derived part numbers, recipes, operator-entered setpoints and production reporting do not; they need the gateway from the previous section.
One safety line belongs here: none of these paths belongs in a safety function. Panel drivers and Ethernet I/O ride networks without safety integrity, so interlocks stay wired to the machine's own safety hardware, and the screens watch from outside.
Worked example: what must the gateway carry for 40 panels?
A line of 40 panels, each showing 100 strings of up to 20 characters and 200 integer setpoints, asks the gateway for 300 values per panel: one shared set of 300 values serves all 40 screens, and 40 concurrent connections, not tag count, set the gateway size.
Scenario: 40 presses with closed controllers. Spare outputs on each drive inputs on Ethernet remote I/O. An OPC server reads the I/O. A reporting application looks up which parts each tool can run and writes the part numbers plus default setpoints into a gateway. Every screen shows the same plant-wide data.
Count what the gateway holds. If all screens show the same values, the set is held once:
- Strings: 100
- Integers: 200
- Total: 100 + 200 = 300 values
If instead every panel needed its own copy, the counts become 100 x 40 = 4,000 string values and 200 x 40 = 8,000 integer values, with 4,000 x 20 = 80,000 characters of string content. These are value counts, not a memory figure; storage overhead depends on the gateway's data model.
Now the wire, at a 1 s scan, a typical interval for monitored values; declare your own interval and redo the division. A 20-character ASCII string packs into 10 registers at two characters per register, so each panel's set is 100 x 10 + 200 = 1,200 registers. The Modbus application protocol returns at most 125 registers per read, so each panel needs 1,200 / 125 = 9.6, call it 10 read requests per scan. Across 40 panels that is 400 requests per second. Each request-and-reply moves roughly 300 bytes on the wire, 250 bytes of register payload plus TCP and Ethernet headers, so the scan moves 400 x 300 = 120,000 bytes per second, about 1 Mbit/s. A switched 100 Mbit/s network absorbs that with room to spare. The limits that actually decide are the gateway's documented connection count and its update behavior under load.
Keeping those updates fast with many panels on one controller is its own problem; Connecting many operator panels to one PLC without slow updates covers what slows a shared controller down.
Which path should your screens use?
Pick by data type: an OPC UA driver in the panel wins when the panel supports it, the PLC gateway wins for strings, setpoints and database values, and the direct I/O path wins only for pure status screens.
| Path | What the screen can show | Between server and screen | Strings, setpoints, database values | Wins when |
|---|---|---|---|---|
| Panel with an OPC UA driver | Any node the OPC UA server exposes | Nothing: the panel connects straight to the server | Yes, read and write | The driver list shows OPC UA and the server already holds the data |
| Gateway plus the panel's own driver | Values the gateway holds | A PLC or gateway speaking Modbus TCP or another listed protocol | Yes, with one writer per tag | The panel has no OPC driver, or the data needs database logic |
| Direct to Ethernet remote I/O | Raw states of the I/O block | Only the Ethernet I/O interface | No | The screen is status-only on a machine whose controller cannot be touched |
The OPC UA path wins on simplicity: one connection, no controller to size or program, and the server's tag model is what you program the screens against. The gateway path wins when a database participates or the panel has no OPC driver; it is the path that carries strings in both directions. The direct I/O path wins on cost for pure status screens, and it is the only one that runs with no controller at all.
Recommendation: Read the panel's driver list before anything else. If OPC UA appears as a communication driver for the exact model, connect the panels straight to the OPC UA server and skip the controller. If it does not, put a PLC or gateway in front, let the reporting application write the derived part numbers and setpoint defaults into it, and keep the direct I/O path for status-only screens on machines whose controllers you cannot touch.
A separate kind of screen sometimes gets requested alongside these: a board that shows counts, schedules and messages with no live machine values. That is a notice board, and an offline Android signage display from our panel-mount display range plays it from a card. It has no PLC or OPC driver and is not an operator interface for any path in this article.
How do you commission the chosen path in one afternoon?
Commission one connection at a time: prove one discrete state, one string and one integer end to end, in both directions, before importing the full tag list, because a green read inside the OPC server tests the server side only.
- Print the driver list for the exact panel model and mark the one protocol every screen will use. If the direct I/O path is in play, pull the register map for the exact interface head and check it against the panel driver's addressing.
- Wire one machine's spare outputs into the remote I/O and confirm the OPC server reads them.
- Build the gateway with three test values, one discrete, one string, one integer, and write a test string into it from the reporting application.
- Connect one panel. Display all three values. Enter a test setpoint and read it back at the reporting application.
- Import the full tag set and roll out panel by panel, watching connection status and comparing displayed values with the source values during the first shift.
The check that matters: a value written at one end arrives unchanged at the other, at every hop. An OPC read that succeeds at the server says nothing about the panel path, and a panel that renders a test value says nothing about the write path back. Test each direction on purpose.
Questions
Does classic OPC DA work from an operator panel?
Usually not. OPC DA rides on Windows COM and DCOM, so both ends historically ran on Windows; panel operating systems implement device drivers instead. OPC UA is the edition of IEC 62541 built for small devices, and it is the one panel manuals document as a selectable communication driver. For DA-era data sources, put an OPC UA server or a gateway between the source and the panel.
How do you resolve two writers on one tag?
Give every tag one writer. When the operator enters a setpoint on the panel, the panel's write lands in a register the gateway owns, and the reporting application reads that register and never writes it. Where both sides need the same value, create two tags, one per writer, and a rule that says which one the screen displays. Test each direction with a known value.
Does the OPC UA connection need security settings?
OPC UA carries its own security model in the protocol: the server chooses anonymous access, username and password, or certificate checks, and it signs and encrypts the traffic. Set the user model on the server first, then enter matching credentials in the panel's connection settings. An endpoint left on anonymous with no certificate check accepts any client that can reach the port.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.