How to test a PLC program before commissioning

Why test before site

Commissioning is the most expensive time in a machine's life: the machine, the fitters, the electrician and often the customer are all waiting. A logic error found there costs hours; the same error found at a desk costs minutes. Offline testing doesn't replace commissioning, but it moves most of the debugging to a cheaper place.

The tools

Most PLC platforms have a simulator in the engineering software:

Some smaller PLCs have no simulator. Then the same test list runs on a bench PLC with switches and lamps, or on the machine with the outputs disabled.

Start from the sequence description

The test list comes from the sequence description and the I/O list, not from the program. For every step, write down what starts it, the outputs it switches, what ends it, how long it may take and the alarm if it doesn't finish. A test written from the program only proves that the program does what it does.

What to test

• Power-up and the first scan: outputs off, retained values sensible.
• Homing or the reference run, from every position the machine can stop in.
• The automatic cycle, step by step and then at full speed.
• Manual mode: each move on its own, with the interlocks that should block it.
• Changing mode in the middle of a cycle.
• Stop, emergency stop and reset, and a restart after each.
• Every alarm: make the fault happen, then check the message, the reaction and the reset.
• Counters, recipes and parameters at their limits.

Simulate the machine, not just the inputs

Forcing inputs by hand works for a few steps, not for a whole cycle. A better way is a small simulation routine that plays the machine: when the extend output turns on, the extended sensor turns on a moment later; when the clamp closes, the clamp sensor follows. One flag switches the routine off, and it never runs on the real machine.

To test faults, make the simulated machine misbehave: delay a sensor past its timeout, drop a signal mid-cycle, or never send it at all.

Test the HMI with the PLC

Run the HMI in its simulator against the simulated PLC where the tools allow it; otherwise check every HMI tag address against the tag list. Walk through every screen: buttons write the right bits, values show the right units and decimals, and every alarm text matches the fault behind it.

Record it

Keep an offline test report: each test, the expected result, the actual result, the date and the program version. It becomes the checklist for the factory acceptance test (FAT) and for commissioning, and it shows the customer what was tested before the machine arrived.

What offline testing can't prove

• Wiring, sensor positions and the real I/O.
• Mechanical timing: how long a cylinder really takes, with real air pressure and load.
• Drive and servo parameters, and the tuning.
• Network timing with every device connected.
• Safety functions. Safety circuits and safety PLC logic must be validated on the real machine, against the risk assessment and the applicable standard.

On site

Start with a point-to-point I/O check: every input and output, by tag, against the drawings. Then run the machine dry, without parts, and then with parts. Because the logic was tested beforehand, site time goes on the real I/O and fine-tuning.

My PLC programs come with an offline test report for this reason. If your devices talk Modbus, the Modbus RTU frames guide covers the frames and the usual faults.