Situation
A beverage bottling site added a new palletising robot beside an existing line PLC. The robot OEM supplied a standard interface, but production stops during layer changes and film breaks exposed ambiguous fault recovery: operators reset the robot locally while the line believed product was still in transit.
Problems encountered
- Handshake signals used different pulse widths than the line conveyor interlocks expected.
- Robot program changes were not version-controlled alongside PLC revisions.
- Light curtain muting during pallet changeover was manual and error-prone.
- No single HMI screen showed combined line and robot state for shift leaders.
Engineering response
TECHNLOGIX PTY LTD defined a finite-state model covering run, pause, fault, and teach-request modes with explicit entry and exit conditions on both controllers. We documented signal timing in a shared interface specification signed by the robot vendor and site maintenance. SCADA received aggregated state and last fault code for downtime classification.
FAT on the vendor floor replayed jam and empty-pallet scenarios. On site, we ran layered recovery drills with operators before peak season.
Outcomes
Recovery after minor faults moved from ad hoc radio coordination to a defined sequence on one HMI. Dual resets that left the line starved were reported less often in the first quarter after go-live.
Lessons for similar sites
Robot projects are integration projects: budget time for state diagrams, not only mechanical reach studies. Lock PLC and robot program versions before SAT sign-off.