Pick-to-Light Systems: Commissioning and Acceptance Checklist #
Pick-to-light systems are a common sight in goods-to-person workstations, where operators assemble orders from totes, cartons, or put walls while light modules direct each pick, confirmation, and exception. These systems appear simple in principle, but their reliability depends far more on disciplined commissioning than on the quality of the hardware alone. Commissioning is not a one-time event held on the morning of go-live; it is a structured process of verifying every device, every logical association, and every zone behavior under controlled conditions. This article provides a practical commissioning and acceptance checklist for warehouse operators, maintenance engineers, and controls teams. It describes component interactions, common symptoms, evidence collection, and the decision boundaries that distinguish a ready station from one that is likely to fail under peak pressure. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority. The guidance here is intended to inform, not to replace, those authorities.
Scope of Commissioning and Acceptance #
Commissioning confirms that the system behaves as designed. Acceptance confirms that operations can take responsibility for it with confidence. The two are connected but distinct. A commissioning program should end with a clear statement of what was tested, what passed, what did not pass, and what remains open. Acceptance is the formal handover of that outcome to the operational team, including training records, configuration backups, and a list of known limitations.
The scope of pick-to-light commissioning extends beyond the light modules themselves. It covers the physical mounting, cable routing, controller logic, zone-to-order mapping, human-machine interface behavior, network traffic, and the interaction between the picking station and the wider warehouse execution system. It also covers operator workflow, because a station that technically passes every test but forces awkward reaches or confusing confirmation sequences will generate errors in production. The checklist must therefore treat hardware, software, and work design as one integrated system.
Every commissioning activity should produce evidence. Evidence can be a signed test sheet, a screen capture of a controller log, a photograph of an as-built wiring label, or a timestamped data export from the warehouse system. Memory is not evidence. A station that passed a test six weeks ago and has since been modified by three different technicians has no verified state until it is retested. This discipline is the core of acceptance.
Pre-Commissioning Prerequisites #
Before any functional test begins, the physical and electrical state of the workstation must be verified. Walk the station with the as-built drawings and confirm that every device is mechanically secure. Check that light modules, displays, and push buttons are mounted at heights that suit the range of operators expected to use the station. A module that is technically functional but positioned out of comfortable reach will be bypassed by operators, and that is a failure of commissioning even if the electrical test passes.
Electrical and network readiness follows. Confirm that all power supplies are correctly sized, fused, and labeled. Check that no cables are routed near moving parts, heat sources, or sharp edges without adequate protection. Loop through each connector and confirm that latches are engaged and strain relief is present. Loose connectors are the most common cause of intermittent “ghost” faults in pick-to-light systems, and they are difficult to diagnose after go-live.
Network topology must be documented and verified. Each controller, switch, and module should have a recorded IP address or node identifier that matches the configuration file. If the system uses a separate control network, confirm that it is isolated from general office traffic. Also confirm that all firmware versions and configuration files have been captured as a baseline. Without a baseline, it is impossible to tell whether a later change is intentional or accidental.
Finally, perform a pre-start hazard assessment in accordance with site procedures. Every person involved in commissioning should know the lockout and tagout points, the emergency stop locations, and the process for re-energizing the station. No commissioning test is worth an injury, and no written checklist overrides a site-specific safety rule.
Hardware Verification and Device Mapping #
Hardware verification begins with a physical audit. Walk the entire station and record the serial number, address setting, and label of every light module, display, button, sensor, and annunciator. Compare these records against the design drawing. Addresses that are set incorrectly on a device are a classic source of cross-talk between zones, where one pick location lights up when a different location was intended. The physical audit is the only reliable way to catch such problems before logical testing.
Device mapping links each physical device to a logical point name in the controller or warehouse control system. This mapping must be verified both from the controller to the device and from the device back to the controller. A device can be correctly recognized by the controller yet still be mapped to the wrong slot or zone in the database. The mapping test is simple but often skipped: trigger a single device directly and see which logical point reports the signal. Repeat for every device, then repeat again after any firmware update or configuration change.
Pay close attention to indicators with multiple colors, intensities, or flashing states. Confirm that the controller can command each distinct visual state and that the operator can distinguish them under normal warehouse lighting. If two states look similar, change the configuration or adjust the lighting, not the operator’s expectations. Also confirm that audible signals are distinguishable from adjacent stations. A buzzer that is too quiet or too loud creates errors that are hard to trace.
Logical Configuration and Zone Assignment #
In goods-to-person workflows, pick-to-light zones typically correspond to a slot, a tote position, or a carton location in a put wall. Each zone has a unique logical identifier, and that identifier must be tied to a specific order location or SKU location in the warehouse execution system. During commissioning, verify that every physical location has exactly one zone assignment and that no zone is duplicated across two physical locations. Duplicate zones cause the order to light in two places at once, which confuses operators and creates mis-picks.
Check the association between the zone and the order. An order line presented to the station should light only the zone that contains the requested SKU. Confirm that this association is driven by the warehouse system’s current data, not by a static display value that was copied into the module years ago. If the system shows a SKU description or order number on the module display, verify that the text is legible, fits the display width, and is updated in real time.
Also test the behavior of empty slots. In many workstations, a slot that is momentarily empty should be suppressed from lighting until it is filled, while a slot that is inactive should not participate in any order. This distinction matters for replenishment workflows. If the logic cannot distinguish between “empty and ready for replenishment” and “disabled because out of service,” then the station will produce ambiguous cues that operators cannot resolve safely.
Functional Test Sequence #
Functional testing should proceed in controlled stages, from the smallest unit to the full integrated flow. Do not jump to a live order wave before each individual behavior has been observed.
Stage 0: Single-Device Test #
Use the controller’s diagnostic mode or a handheld trigger to activate each device individually. Confirm the light color, flashing behavior, display text, and buzzer response. Record any device that fails to respond or responds incorrectly. Keep the test evidence per device, not per row or per zone.
Stage 1: Zone-Level Test #
Submit a single order line that corresponds to a specific zone. Confirm that the correct module lights, that the confirmation button responds, and that the light clears after confirmation. Repeat for every zone in the station. This stage catches wiring errors that Stage 0 may miss, such as two devices sharing a controller output.
Stage 2: Order-Level Test #
Submit an order with multiple lines spread across several zones. Confirm that all zones light simultaneously and that each confirmation clears only the relevant zone. Check that the order is not considered complete until all associated zones have been confirmed.
Stage 3: Mixed-Operator Test #
Run two or more operators at the same station or on adjacent stations simultaneously. Confirm that orders do not cross over, that the operator identity capture is correct, and that response times remain acceptable. Interference between zones and operators often appears only under simultaneous activity.
Stage 4: Exception Path Test #
Trigger each exception condition deliberately: a short pick, a missed pick, an out-of-stock location, a damaged label, and a cancel request. Confirm that the exception is shown on the display in a clear and distinct format, that the required operator action is obvious, and that the warehouse system receives a correct exception record. The exception path is where most production errors originate, and it deserves the same testing depth as the happy path.
Stage 5: Replenishment Test #
Issue replenishment tasks to the station and confirm that the correct zone lights, that the confirmation clears the light, and that the inventory record updates. Also confirm that a replenishment task and a picking task are never presented for the same zone at the same time unless the logic explicitly permits it.
Stage 6: Stress Test #
Run a sustained period of continuous order processing at or above the expected peak rate. Monitor the controller logs for missed messages, timeouts, or retries. Let the station run long enough to expose thermal issues, network congestion, and memory leaks. A station that passes a two-minute demo but fails after one hour under load is not ready for acceptance.
Diagnostic Table: Common Symptoms and Evidence #
The following table lists symptoms that commonly appear during commissioning and early production. For each symptom, the table shows the likely area to inspect, the evidence to collect, and a common misinterpretation to avoid.
| Symptom | Likely Area | Evidence to Collect | Common Misinterpretation |
|---|---|---|---|
| Zone does not light when order is presented | Wire continuity, module address, zone mapping | Stage 0 manual test result, controller log for the order, mapping table export | “The module is broken” — often caused by an incorrect address or a zone that was never mapped |
| Two zones light for a single order line | Physical wiring daisy-chain, duplicated zone ID, controller output mapping | Device audit list, zone configuration export, wiring diagram annotation | “The camera caught it” — usually a duplicate logical address, not a sensor issue |
| Light remains on after confirmation | Controller logic, confirmation button wiring, order completion rule | Timestamped controller log, button input capture, order status in WES | “The operator did not press hard enough” — verify the button signal first |
| Buzzer sounds but no light appears | Separate buzzer circuit, module output channel, controller output configuration | Output voltage measurement, manual trigger test result for buzzer and light independently | “The module is dead” — buzzer and light are often driven by separate outputs |
| Intermittent no-response during a shift | Loose connector, damaged cable, network frame loss | Connector inspection photos, cable continuity test, switch error counters | “It must be a software bug” — mechanical connections fail more often than logic |
| Display shows wrong order number | Order ID mapping, display buffer, WES data transmission | Screen capture of display, WES order log, controller receive log | “The operator selected the wrong wave” — compare the transmitted value with the displayed value |
| Slow response at peak volume | Network congestion, PLC scan time, WES queue backlog | Round-trip latency measurement, switch utilization, WES queue depth log | “The hardware is too slow” — often a queue or protocol inefficiency |
Order-Flow Stability and Workload Balancing #
After functional tests pass, the station should be observed under realistic order flow. The goal is not just to verify that the equipment works, but that the workflow remains stable. Uneven workload distribution is a common hidden defect. If fast-moving SKUs are concentrated in a single zone or a single side of the station, that zone will constantly light while others remain dark, causing one-sided operator motion and localized bottlenecks. Commissioning should include a review of the slot allocation logic and, if necessary, a reallocation of SKUs to balance pick activity across all zones.
Observe the operator’s motion from the moment an order arrives to the moment it is confirmed. Look for unnecessary reach, bending, stretching, or rotation. Also observe how the operator confirms a pick: is the confirmation button within comfortable reach of the picking hand? Is the confirmation button confused with the exception button? These ergonomic details affect throughput more than most technical parameters.
Workload balancing also applies to wave release timing. A station that receives too many orders at once creates a queue of lit zones that are waiting for confirmation, and the operator’s attention becomes scattered. A station that receives too few orders creates idle time and starves the downstream takeaway conveyor. During commissioning, test different wave release intervals and observe the effect on order completion time and operator error rate. Record the recommended release settings in the acceptance document.
Error Handling, Replenishment, and Thresholds #
Every pick-to-light system needs defined thresholds and escalation rules. Define what happens when an operator reports a repeated failure in the same zone. Define what happens when a confirmation is not received within a certain time. Define what happens when the station detects a mismatch between the expected SKU and the operator’s scan. These thresholds should be tested during commissioning, not improvised after go-live.
Replenishment deserves particular attention. In a goods-to-person workstation, the operator is often the same person who replenishes the station, or a separate replenisher is responsible for keeping zones full
Related Pearl Gateway Guides #
Site-Specific Review Worksheet #
This educational worksheet supports a structured review of pick-to-light systems: commissioning and acceptance checklist. Begin by identifying the equipment boundary, control ownership, operating modes, material characteristics, upstream dependencies and downstream consequences. Record what the system is expected to do, what was actually observed and which evidence is time-aligned. Avoid changing several variables at once, because simultaneous changes make cause and effect difficult to establish.
Evidence to collect #
- Operating mode, active mission or route, and the exact sequence state.
- Alarm history, device state changes and controller timestamps.
- Physical observations such as alignment, contamination, wear, obstruction and load condition.
- Recent maintenance, software changes, parameter changes and recurring work orders.
- Upstream and downstream readiness, including blocked, starved and unavailable conditions.
Decision boundaries #
Use approved site procedures and competent engineering judgment before intervention. General information in the Order Fulfillment & Workstation Design library cannot determine whether a specific machine is safe to enter, restart or modify. Preserve original settings, document authorized adjustments and establish a rollback point before controlled testing. When evidence conflicts, stop and resolve the timestamp, naming or measurement discrepancy before drawing a conclusion.
Closeout record #
A useful closeout record states the symptom, confirmed cause, evidence, corrective action, validation method, residual risk and follow-up owner. It should also identify whether the event exposed a design weakness, maintenance gap, training issue, spare-parts issue or monitoring blind spot. This turns a single recovery into reusable reliability knowledge without treating one observation as universal.
