Commissioning and acceptance checklists are not a list of boxes to tick; they are structured diagnostic instruments that translate engineering intent into measurable evidence. For warehouse operators, a checklist is often the difference between a controlled handover and a season of unpredictable faults. This article examines how to design and apply such checklists so that they capture useful condition evidence, expose interaction failures early, and reduce the chance of repeat faults after handover. It is written for maintenance technicians, responsible engineers, and controls teams who need to know what to look for, how to interpret it, and when a decision clearly belongs to a site procedure or to OEM documentation.
What Commissioning and Acceptance Mean in Practice #
Commissioning and acceptance are frequently treated as a single event, but they serve different purposes. Commissioning is the process of energising, configuring, and exercising equipment to confirm that it functions as designed. Acceptance is the formal verification that the equipment meets the agreed performance criteria and is ready to be handed over to operations. In a warehouse context, a conveyor system or automated storage and retrieval machine may be commissioned by one team and accepted by another, often with separate contractual obligations and risk tolerances.
The diagnostic checklist therefore has a dual role. During commissioning, it guides the technician through a sequence of increasingly revealing checks. During acceptance, it becomes the evidence package that supports the decision to release equipment for production. The same physical observations can appear in both phases, but the decision boundary is different: a commissioning fault is a development issue, while an acceptance fault is a handover blocker. Understanding that distinction prevents technicians from over-engineering or under-reporting problems.
This article assumes that site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over any generic suggestion. The purpose of the checklist is to supplement, not replace, those authorities.
Preparing the Checklist: Inspection Design Essentials #
An effective checklist is designed before it is used. The first design decision is the inspection hierarchy: what assemblies, sub-assemblies, and individual components will be examined. Warehouse automation usually involves material flow, motion control, safety systems, and data communication. A useful checklist groups checks according to these operating functions, not according to vendor drawing numbers, because technicians tend to think in terms of flow and behaviour rather than part lists.
For each functional group, the designer should define the observable symptom, the evidence to collect, and the acceptance criterion. For example, a live-roller conveyor has an observable symptom of “drive chain tension”; the evidence might be a deflection measurement; the acceptance criterion might be a specified range in the OEM manual. This simple mapping turns a vague visual inspection into a diagnostic test.
Consider the inspection scale. Not every component requires the same depth of examination. A fast-moving sortation arm has a higher failure criticality than a static guard panel. Weight the checklist so that high-criticality items receive more detailed evidence collection, but keep low-criticality checks in the list to avoid blind spots. Avoid the temptation to inflate the checklist with items that cannot generate a decision. Every check must have a pass or fail outcome, or at least an observation that can feed into a later decision.
Static Checks Before Power Application #
The first live checks are performed in a de-energised state. The objective is to confirm physical integrity, clearances, and the presence of everything the equipment needs to operate safely. None of these checks can be accelerated away by software configuration or craft skill.
Check these areas methodically:
- Structural alignment: frame straightness, anchor bolt torque, levelling pads, and expansion joints.
- Motion geometry: drive alignment, chain or belt tracking, sprocket/ pulley seating, and travel limits.
- Sensor positions: photoelectric, inductance, and ultrasonic sensors correctly located, fixed, and aimed.
- Physical clearances: pallet and product envelope versus guard and conveyor profiles.
- End stops and buffers: present, correctly sized, and not deformed.
- Cable and hose routing: no pinch points, adequate bend radii, and separation from heat sources.
- Part presence: all fasteners, clips, and shield plates fitted to the OEM bill of materials.
Static checks also capture baseline condition evidence. Measure and record drive temperatures, oil levels, and tension values. Photograph any abnormal observation before correction so that later comparison is possible. This baseline becomes important when a fault appears weeks after handover: the technician can compare the current state with the original evidence rather than guessing whether the issue existed during commissioning.
Never proceed to live testing if a static check reveals a condition that could cause injury, equipment damage, or an uncontrolled failure. Mark the item as failed in the evidence log and escalate through the site process. A checklist is not a permission slip; it is a diagnostic record.
Live Checks: Power, Logic, and Guarded Motion #
Live checks begin with power application in a controlled sequence. First, confirm incoming power supply quality, voltage phase balance, and earth continuity. Then energise the control system and observe the operator interface for alarms or unexpected conditions. At this stage, the check is about the state of the system when it wakes up: which zones report ready, which devices report faults, and which communications are established.
After the control system is stable, perform guarded motion tests at minimal speed. For a pallet shuttle or transfer car, this means moving a light load, usually a dummy pallet or a test box, through the travel path under manual or semi-automatic control. The technician observes start, stop, ramp, and overflow behaviour, recording distances of over-travel. Table of observations below provides an example of how to record motion evidence.
Safety-system checks are performed in this phase and must not be bypassed. Each guard interlock, emergency stop, light curtain, and safety PLC input should be tested with the machine in a safe and known configuration. The correct diagnostic behaviour is to record the result as evidence, not to alter the safety circuit to achieve an easier test. If a safety device cannot be tested without bypassing it, do not run the test; escalate.
Run the no-load sequence for a complete production cycle as defined by the conveyor or machine logic. Capture the full cycle time, zone occupation duration, and any missed transitions. A commissioning checklist should include a log of every alarm that fires during this run, however minor. Temporary faults that clear themselves are valuable diagnostic evidence, not noise to be ignored.
Loaded Functional Testing and Acceptance Evidence #
Once the equipment passes no-load running, apply realistic load conditions. The purpose of loaded testing is to reveal interaction failures: load cells that read incorrectly under weight, motors that overheat only when acceleration torque is high, sensors that lose detection due to load vibration, and conveyor drive soft starts that slip with a full pallet.
Build the loaded test from partial to full rated load. For a stretch wrapper, test with a stable medium-weight load before the maximum load envelope. For a conveyor system, test single-zone and multi-zone conveyance at rated speed, with deceleration and back-pressure. Record motor current readings at each stage, because current rise under load is one of the most objective indicators of mechanical friction or brake drag.
Repeatability is the key acceptance criterion for most warehouse automation. Run the same loaded cycle several times and record the variation in the measured end positions and cycle times. A system that completes three identical cycles with slightly different stopping positions may fail an acceptance requirement even if every cycle technically within tolerance on its own. The variance is the diagnostic clue, usually pointing to inconsistent friction, worn mechanical play, or a position feedback issue.
Practical Diagnostic Table: Example Evidence and Interpretations #
The following table gives example observations a technician might encounter during commissioning or acceptance testing. It is not a substitute for site documentation; it illustrates how to structure evidence and interpret symptoms.
| Observable symptom | Typical component interactions | Evidence to record | Plausible interpretation | Decision boundary |
|---|---|---|---|---|
| Over-travel beyond stop positions | Drive brake, proximity sensor, limit switch, PLC deceleration ramp | Distance of over-run, sensor switching gaps, motor current ripple | Brake wear, sensor misposition, or deceleration ramp too aggressive | If load hits buffer, stop test; escalate. Do not adjust sensor to hide defect. |
| Uncommanded stop during a move | Zone sensor, drive enable, safety relay, line communication | Time of stop, alarm code, sensor state, zone occupancy map | Communication drop, sensor flicker, or safety input toggled briefly | Requires repeat test after fault log review; if repeatable, escalate to controls. |
| Abnormal high-pitch or rubbing sound | Bearing housing, drive coupling, chain guides, side guards | Sound localisation, temperature of associated bearing, vibration amplitude | Misalignment, shroud contact, or bearing pre-load | No loaded cycle until source found and rectified. |
| Pallet misalignment at transfer | Conveyor side rails, transfer car, position sensors, load centering | Misalignment direction and distance, load edge profile, rail gap | Worn rail guide, differing conveyor speeds, or sensor trigger timing | Transfer misfits are handling hazards; stop and investigate mechanically. |
| Vibration at rated speed | Motor, gearbox, shaft, bearing housing, frame mount | Vibration frequency (Hz), RMS velocity, temperature, load state | Unbalance, resonance, or soft foot in mount | If vibration exceeds OEM guide, run at reduced speed only for diagnosis. |
Use the table as a template during checklist design: identify the likely symptoms for your specific equipment and fill in the component interactions, expected evidence, and decision boundaries. The act of writing these columns often reveals missing checks.
Common Interpretation Errors in Diagnostic Evidence #
Interpretation errors are the most costly part of commissioning and acceptance. A wrong interpretation sends the technician down a rework path, wastes spares, and sometimes generates a repeat fault that appears again after handover. Recognise these common patterns.
The first error is assigning a single cause to a complex interaction. A conveyor mis-stop may be caused by a slightly slow sensor, a brief PLC I/O glitch, and a marginally sticky brake all occurring together. The evidence on the screen shows the glitch, so the technician replaces the PLC module. The fault returns weeks later because the brake was never re-conditioned. The diagnostic approach should record all unusual conditions during a sequence, not just the first alarm.
The second error is over-weighting the latest event. When a machine has been in continuous test and then exhibits a fault, technicians naturally focus on the most recent change or component. A better discipline is to ask what was different in this test run versus the previous successful run, and to review the fault log for a progressive change in current or speed before the stop.
The third error is replacing a good component too early. Many premature spare part changes occur because the evidence collected was insufficient. For instance, a dark sensor lens can cause missed detection, but the technician records only “sensor fault” and installs a new sensor, leaving the lens contamination issue unresolved. Condition evidence, such as the actual light margin reading, prevents this waste.
Finally, avoid the software-first bias. In modern warehouse systems, controls faults are frequently observed symptoms with mechanical triggers. When a motor drive fails to respond to a command, confirm the axis can rotate freely by hand (de-energised), check the mechanical brake releases, and measure torque before questioning the software logic.
Failure Coding, Spares, and Repeat-Fault Reduction #
Commissioning and acceptance are the first time a machine generates fault data, and that data has long-term value. Consistent failure coding, based on the site asset hierarchy, allows the maintenance team to identify which components, interactions, and environmental conditions produce the most faults. Without disciplined coding, the fault log becomes a sequence of unrelated incidents.
When the checklist records a fault, assign it a structured code: equipment identifier, component, failure mode, and apparent cause. For example, “CONV-Z12 / DriveMotor / Overcurrent / BrakeDragging” is far more useful than “conveyor fault”. The coding should be designed before commissioning begins, so that the commissioning team uses the same codes the warehouse maintenance team will use later.
Spares planning benefits directly from this evidence. If commissioning tests show that a particular photo-eye consistently works at only 20% of its light-margin range, then the component is marginal and a spare should be available on-site. If three different index drives all exhibit high current at the same load point, the cause is likely a design issue, not a component failure, and ordering spare drives will not solve it.
Repeat-fault reduction is achieved by closing the loop between commissioning evidence and later maintenance history. The technician who accepts the equipment should document the top two or three risk areas observed during testing. When those areas fail in operation, the maintenance team knows to look at the original evidence baseline first, rather than starting the diagnosis from zero.
Decision Boundaries and Handover #
A checklist loses value when the technician treats every observation as equally actionable. Define decision boundaries in advance. A deviation that is cosmetic and within tolerance should be logged but not necessarily corrected during commissioning. A deviation that affects safe motion, load stability, or repeatability should stop further testing until resolved.
Handover is a formal decision, not a moment. The acceptance sign-off should name the specific evidence available, the residual known deviations, and the recommendations for the first operational inspection period. Any unresolved deviation should be recorded in the handover notes, with a description of the condition, the potential effect, and the proposed follow-up action. The independent stance here is important: the checklist is evidence, and the site engineer or responsible manager makes the final call on release.
Do not use acceptance as an opportunity to persuade operations to accept a faulty machine. The acceptance checklist exists to protect both the maintenance team and the operations team from an unworkable handover. If a required test cannot be completed because the equipment is not stable, record that fact clearly and hand the decision to the engineering authority. Every bypass of the expected process creates a latent fault that will appear later as a repeat issue.
Where the equipment involves complex control interactions, the acceptance process should include a grace period or a phased handover. This is not a failure of the commissioning checklist; it is a realistic recognition that certain faults only appear after sustained production loading. Document the grace-period observation criteria in the acceptance evidence so the operations team knows what to report.
Key Takeaways #
- Design the checklist around function and observable behaviour, not just component presence; weigh checks by failure criticality and evidence value.
- Collect baseline condition records during static inspection, including temperatures, tensions, and photographs, to support later fault analysis.
- Test safety devices in a known safe configuration without bypassing them; if a test cannot be performed safely, stop and escalate.
- Record every alarm and deviation during live testing, including those that clear themselves; they are diagnostic evidence for interaction faults.
- Use structured failure codes from day one so commissioning data feeds directly into maintenance history and repeat-fault reduction.
- Interpret symptoms by looking at component interactions and progressive trends, rather than assuming the latest event or the newest component is the root cause.
- Define clear decision boundaries between acceptable deviation, correctable fault, and stop-test condition before the checklist is executed.
- Handover is a decision based on evidence; list residual risks and recommended first-period inspections rather than claiming perfect condition.
