Set up a PC as an HMI beside an operator panel with OPC

What an OPC server does

The OPC server is a translator. On one side it speaks the PLC's protocol; on the other it offers a common OPC interface, so client software reads and writes the PLC without carrying a driver for every device. It draws no screens and shows nothing to a person: installed alone, it displays nothing useful. Before you buy anything, name the client that will sit on the other side of it, an HMI or SCADA package or your own code with an OPC client.

The panel needs none of this. It already talks to the PLC directly. If you later want the panel itself to read a second data source, that is a different topology: one panel family's documentation states a maximum of eight OPC servers per client, and whether an HMI panel can read OPC tags without a PLC covers that case. For simple logging, a spreadsheet front end through DDE is the lightest path; reading and writing PLC tags from Excel through DDE shows that setup.

What you need

• A network path to the PLC: an Ethernet communication module the OPC server's driver supports, or the PLC's serial port when the PC sits beside it. Confirm in the vendor's current documentation that the driver lists your PLC and the connection type.
• The OPC server with that driver.
• A client for the PC: an HMI or SCADA package, or the spreadsheet route for plain data logging.
• A PC left at the machine, connected to the same switch as the PLC, with its own screen, keyboard and mouse. That workstation is part of the control setup, not a sign. If the line also needs a board showing counts and machine states to people walking past, that is a separate display job: see shop-floor and andon-style boards.
• The panel project's address list: every PLC address the screens read or write.
• An approved remote route: a VPN into the site, set up with whoever owns the firewall.

Set up the PC beside the panel

1. List the panel's addresses. Open the panel project and write down every PLC address its screens read or write. The PC software works from that same list, so start with one data register the panel already displays.
2. Give the PLC a network address. Fit the Ethernet module and give it a static address on the site subnet, for example 192.168.1.50 with the PC at 192.168.1.20 and a mask of 255.255.255.0. Connect both to the same switch and ping the module from the PC; a reply comes back within a few milliseconds.
3. Install the OPC server on the PC. Create the channel and the device for your PLC model in the server's configuration and enter the module's address from step 2.
4. Read one tag. In the client, add that data register from the panel's list and compare the value on screen with the value on the panel. If the ping works but the read fails, the fault is in the device settings or the driver selection, not the network.
5. Build the remote commands on their own addresses, behind a local/remote selector, with the heartbeat watchdog sized in the example below.
6. Connect from off site to the PC, over the VPN, and read the same register from your remote session. The PLC's address never leaves the site.

Keep the panel and the PC from writing over each other

The panel and the PC are two clients of the same PLC memory, and nothing arbitrates between them except your ladder logic. When both write one address, the last write in the scan that processes it wins, so a remote operator can switch off what the local operator just set. Give every remote command its own address and never reuse the panel's command bits.

Add a local/remote selector in the ladder so only one source can act on an output at a time. Make the remote commands momentary: the client writes the command true for one poll cycle and false at the next, and PLC logic clears the bit if the heartbeat stops. A remote start that survives a lost connection is a hazard, and this heartbeat is what removes it. The pulse-then-release pattern is the same one a wired momentary pushbutton uses, and a write-up of momentary pushbutton to latched output logic shows that contrast. The scan-side arithmetic of how long a momentary bit is visible is in how many PLC scans an HMI momentary button stays on.

Worked example: 3000 ms heartbeat watchdog for a 1000 ms poll

Inputs. Poll interval 1000 ms, the setting you enter in the client's scan group for the heartbeat and command tags. Missed polls allowed: 2, a design choice, so a single lost VPN packet trips nothing. PLC scan time 10 ms, typical for a small PLC, which scans in the low tens of milliseconds; read the real value from your PLC's scan-time diagnostic and substitute it.

Rule in words. The client toggles a heartbeat bit every poll. PLC logic trips a watchdog when no toggle arrives within the timeout, clears the remote command, and refuses remote commands until the heartbeat returns. The timeout must exceed one poll more than the number of polls you are willing to lose.

Arithmetic. Timeout = (2 missed polls allowed + 1) × 1000 ms = 3000 ms. Worst case after the link dies: if the last toggle arrived just before the drop, detection comes 3000 ms later; if the drop lands just before a due toggle, it comes 2000 ms later. Add one scan for the clear: 3000 ms + 10 ms = 3010 ms at worst. The command itself is written true at one poll and false at the next, 1000 ms apart, and the PLC samples it every 10 ms, so an arriving command is always seen; a command left true because the link died before the false write is cleared at the watchdog trip.

Result. With a 1000 ms poll and a 3000 ms watchdog, a dead link can hold a remote command for at most about 3 s, after which the PLC has cleared it and locked remote commands out until the heartbeat returns.

Decision. At a 1000 ms poll, set the watchdog to 3000 ms. The rule is 3 × your poll interval: at a 500 ms poll, 3 × 500 ms = 1500 ms, and the held-command window drops to about 1.5 s. If the process cannot tolerate that window, shorten the poll until it fits.

Why the PLC address stays off the public internet

The common PLC protocols were written for a cable between two boxes and carry no meaningful authentication, so a PLC address that answers from the internet is memory anyone can read and write. A port forward straight to the PLC is a temporary restore measure at best. The permanent setup keeps the PLC address private and brings the PC's screen to you instead: one VPN session, and the client behaves as if you stood at the machine.

Published guidance on managing remote access for industrial control systems calls for the same shape: remote sessions enter through a managed gateway with multi-factor authentication, endpoints are controlled, and access is logged. If a forward to the machine already exists, confirm hop by hop what it exposes with the step-by-step test of a failing HMI remote access port forward and remove the rule once the VPN works. If you do not administer the site firewall, hand this part to whoever does.

How to check it worked

• Panel normal. With the client connected and polling, the panel behaves exactly as before.
• Values match. Every tag on the panel's list reads the same on the PC as on the panel screen.
• Writes tested on harmless bits. Write one data bit from the PC and watch it change on the panel; write one from the panel and watch it change on the PC. Stay on plain data bits before anything the machine acts on, following the order in testing operator panel writes before motion.
• Dead-link test. Drop the VPN on purpose while a remote command is on. The line settles in its safe state, no remote command stays latched, and remote commands stay refused until the heartbeat returns.
• Outside test. From a laptop outside the VPN, the PLC's address gives no reply.

Recommendation: Put the HMI software on a PC left at the machine, connect to that PC over a VPN, and never forward a port to the PLC. Give remote commands their own addresses behind a local/remote selector, make them momentary, and set the heartbeat watchdog at 3 × the poll interval, 3000 ms at a 1000 ms poll. A laptop is fine for commissioning, but the computer that stays on site is the one your remote session reaches.

Questions