Testing a program on the physical line has three limitations: the line must already exist, an error can damage equipment or stop production, and rare situations are hard to provoke on purpose. A working model removes all three. This is what the term virtual commissioning covers: testing and programming the control system on a model, before the line is physically built.
What is tested
- Sequences: whether the steps run in the order the process requires, including the first cycle after a start and the last one before a stop.
- Interlocks: whether a shared zone is really blocked while another axis is inside it.
- Signal exchange: whether the PLC and the robot agree on who is waiting for whom, and what happens if an expected signal does not arrive.
- Timeouts and fault handling: how the program reacts to a missing part, a sensor that does not respond or a head lost from the gripper.
- Restart after a fault: whether a station can return to operation from the state it is actually in.
- Throughput: whether the program, and not just the mechanics, achieves the assumed takt.
Errors have consequences in the model
A model is useful only if errors have consequences in it. On the 24V LED lamp process, the transport raises a fault immediately when a separator releases two pallets on one lowering, when a pallet passes a lowered stop at a dock, or when a damper would push a pallet into the one ahead. Motion is checked for collisions on the moving geometry. A station’s fault stops only that station, as it would on a real line, while an emergency stop or an open door stops everything.
Timing matters as well. The software PLC scans inside each physics step, so PLC time equals simulation time and the line behaves the same regardless of screen refresh. A slow computer does not hide a problem between two frames, and the checks are also run at a deliberately low frame rate to confirm this.
How a change is tested
The program is a replaceable module, the same as on a physical controller. It sees the process only through its process image, with no access to the internals of the simulation, and a program error is reported with its file and line. After a change, resetting the model applies the new version and the line starts again from a defined state, with no need to rebuild the application.
Every change to the lamp line passes through a set of automatic runs: a production run, a run at a low frame rate and a run with a station reset. A change that breaks an earlier behavior shows up here, before anyone sees it on a screen.
Restart behavior
Restart logic is among the most expensive things to get wrong, and it is rarely tested as thoroughly as normal production. In the lamp process, the following convention applies. On a station reset, outputs that hold a part stay active: vacuum with a confirmed part, jaws closed on a part. An axis that cannot safely go straight home stays where it is, and the program takes it home in a safe order, such as up first and then sideways. The program then determines from its inputs where the station is, and continues. Each of these rules is executed and checked on the model.
Controllers and robots
The model reaches a controller through its process image, so the same model can work with an embedded software PLC or an external controller. We support all popular brands of controllers and robots. This allows us to propose the best possible solution for a given process, with no ties to a single manufacturer.
The lamp process itself runs on a software PLC inside the model, which is why we describe it that way. On a customer project this place is taken by the customer’s controller and code, and the test scope is agreed as a list of sequence and signal tests with a defined result.
Use after commissioning
The model remains useful once the line is running. A new product variant or a modified sequence can be tested on it first, without interrupting production. This is also a way to assess changes in advance, since modifying a machine’s program can have formal consequences under machinery regulations.
What a model does not show
A model removes logic errors: wrong sequences, timing, handshakes and collision zones. It does not show the mechanical reality on the floor, such as tolerances, vibration, sensor drift or how a particular material behaves. These are matters for fine adjustment on site, not for redesign, but they do exist.
A model also does not replace validation of safety functions. Those must be tested on the physical equipment, whatever the model has shown.
What this means for a project
The contractual commitment is concrete: programs tested on a model based on a real control system, against an agreed list of tests. For an integrator, this means that much of the work usually done during commissioning is carried out in the office. For the plant, it means that the first start of the line is not the first test of its logic.
The same model, with the same logic and the same faults, also serves another group of users: the people who will operate the line.