Run PLC logic against a 2D machine in the browser: belts, sensors, cylinders, tanks and pumps that feed your inputs — and fault switches to break on purpose.

A scan-cycle simulator proves your logic; it doesn't prove your logic matches a machine. You can force PartSensor true and watch the rung respond, but forcing is you playing the machine — and you are a merciful machine. You never hold the part on the sensor too long, never press stop mid-transfer, never jam the belt. Real machines are not merciful, which is why a class of bugs survives desk testing and waits for commissioning. PLC-Ladder's 2D machine visualization — in preview now — closes part of that gap: your program runs a simple animated machine, and the machine talks back.

What it is

Describe your machine and the request builds a 2D scene for it: belts, sensors, cylinders, tanks, pumps, buttons and lamps, wired to your program's I/O. After every scan the machine moves — a bottle advances along the belt, the fill valve opens, the level rises — and the machine's sensors feed your inputs. The loop is closed: your output starts the belt, the belt carries the part, the part reaches the photo-eye, the photo-eye drives your input, your logic responds. Nobody is forcing anything; the logic lives with the consequences of its own outputs, scan by scan.

The panel is part of the scene: press start, stop and reset like an operator, or hold two buttons for a two-hand start — which makes the anti-tie-down pattern testable the way it's actually defeated, by taping one button down and trying the other.

Why closed-loop testing finds different bugs

Forcing inputs tests your logic's responses. A closed loop tests its assumptions about time and sequence — where the expensive bugs live:

  • Dwell and travel time become real. A transfer that assumed the part clears the sensor before the next one arrives now meets a belt with actual spacing. If your edge detection was wrong, the counter miscounts in front of you (the level-versus-edge trap) instead of in front of the customer.
  • Sequence gaps show as stuck machinery. A state machine that strands a step doesn't just sit there as a frozen integer — a bottle sits under a nozzle that never closes, which is a bug you notice.
  • The scene flags oddities itself. It watches for things like a bottle that never leaves and asks whether that's expected — a second pair of eyes that has read neither your spec nor your excuses.

And because breaking things is the point, fault switches are built in: jam the belt, stick a sensor, block the nozzle. That turns the adversarial-testing checklist from a thought experiment into switches you flip. Does the jam alarm trip in time? Does a stuck sensor make your counter lie? What does the operator panel show while it happens?

What it is not (read this part)

The scene is a simplified model for checking logic, not the real machine. There is no 3D, no robots, no physics engine — a belt moves parts at a modeled rate; it does not compute friction. The feature is a preview: open and working, not yet validated by an outside engineer, and we'd rather tell you that than let you discover it. It doesn't replace vendor virtual-commissioning suites for machine-level engineering, and it changes nothing about the standing rule: a qualified engineer validates the logic for the actual equipment, and commissioning still owns physical reality — wiring, sensor calibration, mechanical truth. What the scene owns is the layer in between: whether your logic's assumptions about sequence and time survive contact with any machine at all.

Where it fits in the workflow

The 2D scene slots between simulation and your HMI work: draft the logic (from plain English, if you like), approve it, run it against the scene with the fault switches, and then expose it over OPC UA so your Ignition screens drive the same logic the machine is obeying — HMI, logic and machine behaviour all tested before a controller exists. The scene and OPC UA are both included with any credit pack; compiling and simulating stay free.

The two-minute test that shows you whether this matters for your work: build the bottle-filler — belt, photo-eye, fill valve, counter — let the scene run, and then hold a bottle on the sensor with a fault switch. If your count climbs while the bottle sits still, you've just met, safely, the bug that commissioning would have found expensively. Try it at plcladder.com.