PLC Program Testing: Prove Behavior, Not Just Rung Appearance

Start with a requirement stated in observable language. “The rung should seal in” describes an implementation. “After a valid start pulse, the motor command remains true until Stop, overload or emergency stop becomes active” describes behavior. The second statement can test a seal-in branch, a SET/RESET implementation or a Structured Text state variable without confusing one drawing style with the real acceptance criterion.

Define the initial state. The machine mode, permissives, timer values, counter values, physical position and fault latches all matter. If the test relies on a prior case having left the conveyor running, then it is a sequence of dependent steps and should be written as one scenario. Independent requirements should start clean. Fresh state prevents a passing first case from donating a latched bit to a broken second case.

Apply inputs with durations that the scan can observe. A pushbutton pulse shorter than the task interval may be missed on a real controller unless hardware or input buffering captures it. In simulation, a pulse should span enough scan steps to establish an on edge and a later off edge. A wait should describe why it exists: allow a timer to complete, let physics settle, or confirm that an output remains stable.

Assert what matters to the requirement. An output bit may be enough for simple combinational logic. A sequencer may require phase, actuator command and process-state evidence. Avoid asserting every internal tag simply because it is visible; that overfits tests to one implementation and makes safe refactoring expensive. Assert internal state only when the state is part of the design contract or needed to prove a hazardous transition cannot occur.

Combinational logic may settle in one scan, while internal variables written late in the program are not consumed until a later scan depending on the execution model. A test that waits an arbitrary second will eventually see the right final value and hide an unintended delay. Express both the required deadline and the scan resolution: for example, output must drop no later than the next completed scan after Stop is observed.

Timers need temporal boundaries. Advance the simulated clock in known increments and assert before the preset, at the first eligible completion and after reset. Test what happens when the input drops just before completion, when the preset changes while active if supported, and when the preset is shorter than one scan. The goal is not to memorize one simulator implementation but to develop cases you can adapt to the target PLC.

Pulses need an on edge and an off edge separated by executable scans. Back-to-back software writes in the same observation cycle can collapse into a level that the program never reads. The simulator test runner explicitly schedules the falling edge and allows a low scan before another pulse, which is useful for counters and edge detectors. Real I/O may need input filters or high-speed hardware when pulse width approaches task timing.

Rung order deserves targeted tests where one internal value is written and read in the same scan. Reverse order can create a one-cycle delay even though each rung looks correct in isolation. Write a case that asserts the intermediate scan, not only the state a second later. Then document whether the delay is intended, harmless or a requirement violation.

Independent requirements should produce independent outcomes. A program may pass Stop priority and fail overload recovery. Showing both results gives the learner a bounded repair task and tells an engineer which regression areas remain stable. The overall completion status should pass only when every required case passes, but the diagnostic view can still celebrate the requirements that are already correct.

Hidden checks can reduce answer-copying in an assessment, but they should not become arbitrary surprises. The public brief must state the behavioral requirement even if the exact input combination remains hidden. When a hidden check fails, reveal enough category guidance to support learning without exposing the entire answer. In engineering use, secrecy is usually less important than traceability; name the requirement directly.

Avoid source-shape grading unless structure is part of the requirement. Searching for a specific rung pattern rejects alternative correct implementations and can accept cosmetically similar but unsafe code. Execute the program across the full behavioral matrix. Structural rules still have a place for forbidden instructions, mandated safety architecture or maintainability conventions, but label them as separate static checks.

A failed assertion is not a controller fault. The program can remain syntactically valid and useful for iterative diagnosis. The simulator returns ordinary practice to a live scan after a grading mismatch, allowing the learner to inspect state and adjust the program. Production test tooling should make the same distinction between test failure, compile error, runtime fault and infrastructure failure.

Browser simulation is excellent for rapid logic feedback, training, regression cases and fault reasoning. It can run cases that would be slow or hazardous on equipment. Its physics model is deliberately bounded, its scan environment is not a real CPU under load, and its I/O values do not pass through actual modules, wiring or networks. Use it to improve the program and test design before scarce plant time.

Target-controller simulation or emulation adds the vendor compiler, libraries, memory behavior, task configuration and supported instructions. It can reveal differences in implicit conversions, timer resolution, retentive state and execution order. Networked or virtual-controller setups may also test HMI and supervisory interfaces. Confirm the exact limitations in the current vendor documentation.

Hardware-in-the-loop and point-to-point I/O testing prove the electrical and communication path. Operate field devices, compare terminal signal, module indication, raw tag and engineered value, and remove forces after each recorded check. A simulated limit switch does not prove polarity, addressing, noise immunity or mechanical actuation.

Commissioning proves the integrated system under an approved plan. Safeguards, risk assessment, reduced-energy tests, operators and emergency response matter. Repeat the highest-risk functional cases and all recovery paths. A browser pass is preparation and learning evidence; it is not a safety certification, FAT signature or authorization to energize machinery.