The first movement should answer one question
A project reaches the machine with many assumptions packed into its software: input polarity, valve direction, motor rotation, sensor position, timer settings, network identity, and mechanical clearance. Commissioning unpacks those assumptions under an agreed procedure. It is not a contest to make automatic mode run as early as possible.
This chapter describes how to organize the evidence and decisions. It is not authorization to energize equipment or enter a machine. Physical work, isolation, safeguarding, and permitted test conditions belong to the site's procedures and assigned competent people. The browser model lets you rehearse the reasoning without reproducing those physical controls.
Start with a commissioning question precise enough to answer: “Does the signal named ClampClosed change when the identified clamp reaches its closed position?” That is useful. “Does the clamp work?” hides several different questions.
Freeze a known starting package
Before the session, identify the software revision, hardware configuration, drive parameters, HMI version, recipes, drawings, and test procedure. Record what was loaded where. A source repository revision alone does not identify a machine if a drive parameter was changed from its keypad yesterday.
Create a baseline package that another engineer could restore, with access controls appropriate to the site. Include the toolchain and library versions needed to open it. Record unresolved deviations openly. If the panel drawing is being revised, identify the affected terminals and which approved marked-up drawing is in use.
The objective is not paperwork volume. It is the ability to answer “What exactly did we test?” after a later modification changes the result.
Walk from identity toward behavior
Use staged gates. Each gate reduces uncertainty before the next introduces more energy or complexity. The exact gates and approval roles depend on the machine and organization, but the ordering is useful:
- Review documents, versions, responsibilities, and test boundaries.
- Complete the required physical inspections and electrical checks under the relevant procedures.
- Confirm device identity, network configuration, and diagnostic status.
- Check input mapping and polarity against identified devices.
- Verify individual actuator behavior under approved controlled conditions.
- Exercise coordinated behavior with constrained conditions.
- Run agreed acceptance cases and record evidence.
Do not treat a successful later gate as proof that an earlier one was unnecessary. A machine may cycle while two sensor names are exchanged; the error appears only when recovery logic uses their intended meanings.
A usable I/O check sheet
Consider a model pneumatic clamp with open and closed feedback. The worksheet should distinguish what was physically observed from what the PLC displayed:
| Item | Identified device | Expected observation | Actual observation | Evidence |
|---|---|---|---|---|
| DI-07 | Clamp open sensor | Open position gives ClampOpen = TRUE | Record during check | Time and trace reference |
| DI-08 | Clamp closed sensor | Closed position gives ClampClosed = TRUE | Record during check | Time and trace reference |
| DO-03 | Clamp close request | Assigned valve channel responds | Record under approved test | Test step and witness |
| DI-07 + DI-08 | Combined plausibility | Both true is invalid for this mechanism | Inject in model first | Alarm identifier |
Never prefill “pass” because the animation looked correct offline. A model establishes expected behavior; it does not inspect a terminal.
Do not confuse a force with a measurement
A forced input can exercise downstream logic. It cannot prove a field sensor, cable, input channel, mapping, and polarity are correct. A forced output can bypass parts of normal logic, which changes what the test means and may create hazards on equipment. Any use must follow the site's explicit controls and authorization.
For the training model, keep an intervention register: signal, imposed value, reason, person, start time, removal time. Display a visible indication whenever an intervention is active. Before acceptance, verify the register is clear and rerun the affected cases with real model feedback.
The same principle applies to temporary code edits. A line that suppresses an alarm “just for today” is a behavior change. Record it, review it, remove or formally incorporate it, and test the final revision. Memory is a poor configuration management tool.
FAT and SAT need agreed boundaries
A factory acceptance test and a site acceptance test describe stages of project acceptance. Their exact content, witnesses, authority, and contractual effect come from the project agreement. Do not assume that a FAT automatically validates installed site interfaces, production materials, utility quality, or the completed safety system.
Write each acceptance case with preconditions, actions, expected results, actual results, evidence, and disposition. A failed case can lead to a correction and retest, or to a documented deviation accepted by the appropriate authority. The programmer should not silently redefine the expected result after seeing the machine.
Example: a transfer must complete within an agreed process time under a defined load. Record the load, measurement points, and timing method. Timing from HMI animation frames is not equivalent to timing a controller event trace. If the acceptance criterion is unclear, resolve it before arguing about a stopwatch.
Protect the recovery path
Normal production is only one part of acceptance. Test interruption with material present, restart after power loss under the agreed conditions, failed actuator feedback, unavailable downstream equipment, and operator cancellation. Evaluate the messages and recovery instructions as well as the outputs.
Ask an operator to follow the approved recovery explanation without coaching them through hidden programmer knowledge. If the display says “Step 40 error,” improve it. “Clamp did not reach closed position; inspect the identified clamp under the approved procedure” conveys a reason. Actual physical intervention instructions must match the machine's operating and isolation procedures.
Capture product disposition. After an interrupted dosing operation, the machine might be mechanically ready while the batch remains uncertain. Restarting production and releasing product are separate decisions owned by the appropriate functions.
Try it
A conveyor passes its automatic-cycle test. During a later check, you discover that the entry and exit sensor names are exchanged in the I/O mapping. A colleague suggests swapping the variable names and signing the original test sheet because “the machine already worked.”
Write the minimum defensible response. Identify which earlier evidence remains useful, which results are invalidated, and what must happen before handover.
Work through the answer
Record the mapping defect and correct it in the controlled source and documentation. Identify the new revision. The old observations still show what the old configuration did, but they no longer establish that the corrected program satisfies its requirements.
Rerun the individual input checks. Then review all logic that depends on those signals: transfer acceptance, arrival detection, jam detection, counts, recovery, and diagnostics. Retest the affected requirements and any broader regression cases selected by the impact review. Do not automatically discard unrelated network identity checks, but do not assume a single normal cycle covers recovery.
Handover should include the final tested package, completed results, approved deviations, backup and restore information, operator instructions, and identified support ownership. The signature records an authorized decision based on evidence. It is not a substitute for that evidence.
When an acceptance case fails, use the disciplined approach in debug with a hypothesis before changing a collection of settings at once.