PLC-LadderTest an Ignition HMI without a PLC: point the gateway's OPC UA client at simulated logic, bind real tags, and verify screens before the hardware ever arrives.
You can test an Ignition HMI without a PLC — fully: live tags, buttons that force inputs, status lamps that respond, alarm conditions that actually trip — by pointing Ignition's OPC UA client at simulated logic instead of hardware. Every SCADA developer knows the standoff this solves: the screens are due, the controller is on a ship or still being panel-built, and "we'll test at commissioning" means debugging two systems at once in front of the customer. This post covers the three ways to get live tags without a controller, when each fits, and the full workflow for the one that tests the most.
The Three Ways to Fake a PLC (Honestly Compared)
1. Ignition's own simulator devices and memory tags. Built into the gateway: simulator device profiles generate changing values, and memory tags accept writes. Perfect for screen cosmetics — layouts, bindings, templates render with moving data. The limit: there's no logic behind the tags. Press your Start button and the Run lamp won't respond, because nothing connects them. You're testing paint, not plumbing.
2. A vendor soft-PLC (PLCSIM, CODESYS Control, etc.). Real logic, real OPC UA in some cases — and real friction: licenses or time-limited runtimes, heavyweight installs, and you must write the PLC program first in the vendor IDE. Right answer when the final PLC program already exists and you want maximum fidelity to the target platform.
3. Browser-simulated logic exposed over OPC UA. The middle path this post walks: build the control logic (or a faithful sketch of it) in a browser simulator, click Expose to SCADA, and the running simulation becomes an OPC UA server — opc.tcp endpoint, encrypted sessions, browsable typed nodes. Ignition connects to it exactly as it would to a controller. Now the Start button forces a real input, a real seal-in latches, a real TON delays, and the Run lamp follows the logic, not a script. You're testing plumbing.
The honest scope note up front: option 3 tests HMI-to-logic behaviour — bindings, interlock responses, alarm flows, operator sequences. It does not test device-level details (vendor driver quirks, I/O timing, network hardware). Those still belong to commissioning; the goal is arriving there with only those left.
The Workflow, End to End
Step 1 — Build or sketch the logic. Recreate the machine's core behaviour in the simulator: the start/stop interlocks, the permissives, the timers, the alarm conditions. You don't need all 400 rungs — you need every rung the screens touch. (If the logic is still being designed, this doubles as design review; even generated-from-English logic works, since it's compiler-checked.)
Step 2 — Expose it. One click, set the session username/password, note the endpoint (opc.tcp://opc.plcladder.com:4840). Your variables appear as typed nodes under Inputs, Outputs, Timers, Status — inputs writable (a write is a force), outputs read-only, timer and counter presets writable for tuning.
Step 3 — Connect Ignition. Gateway → Config → OPC Connections → new OPC UA connection → endpoint, Basic256Sha256 / Sign & Encrypt, credentials, trust the certificate. The complete click-by-click (plus verifying with UaExpert first, which you should) is in Connect OPC UA to UaExpert and Ignition.
Step 4 — Bind the real screens. Drag the OPC nodes into Ignition tags and bind your actual Perspective/Vision views — the production screens, not test copies. This is the point of the exercise: the deliverable gets tested, not a stand-in.
Step 5 — Run operator scenarios, not demos. Walk the screens the way an operator (and then a hostile operator) would: start the sequence from the HMI and watch the staged outputs; hit stop mid-cycle; drop a permissive during a run and check the screens say why the machine stopped; acknowledge an alarm whose cause persists (it must not clear — set-dominant latching); write to an output tag and confirm it's refused. Every one of these found at a desk is a finding that didn't happen during commissioning week.
Step 6 — Iterate freely. Edit the logic in the simulator and node IDs stay stable, so Ignition tags keep working — change a timer preset from the HMI, restructure a rung in the editor, retest in seconds. This loop (screen tweak → logic tweak → retest) running at desk speed is what hardware-dependent testing never gives you.
What Teams Actually Get Out of This
Parallel development is the headline — the SCADA developer and the PLC programmer stop blocking each other — but the quieter wins add up: operator training on live-behaving screens before the machine exists; FAT-style demos for customers weeks early; screen-design reviews where "what happens if the feed jams" gets shown, not whiteboarded; and interlock misunderstandings surfacing as HMI bugs instead of commissioning incidents. When the real controller arrives, you repoint the OPC connection (or rebind tags to the vendor driver), and the screens have already survived hundreds of operator scenarios.
The free plan runs one exposed session at a time, which is enough to try the whole loop tonight: sketch the seal-in, expose it, bind two components in Ignition, and press your own Start button against logic that actually decides. Fifteen minutes, no hardware, and the standoff is over.