When a machine-tending cell crashes — a gripper in a closing chuck, a cycle started on an empty spindle — the post-mortem almost never finds a broken component. It finds an assumption: one machine acting on what it believed the other was doing instead of what the other confirmed. The robot and the CNC are two computers that can't see each other; everything they know travels over a handful of discrete I/O lines. Getting that handshake right is the actual engineering in a tending cell. When I automated order flow into a robot cell, the software above the cell was the easy half — the I/O contract below it is what this post is about.
The minimal signal set
Names vary by integrator; the roles don't. A workable load/unload cell needs roughly this contract:
- CNC → robot: ready for service (program at the load position, spindle stopped), door open confirmed (from a sensor, not from "I sent the open command"), chuck open confirmed / chuck closed confirmed (pressure switch or position sensor), in alarm.
- Robot → CNC: request service, robot clear of machine (the one that prevents the expensive noise — the door and cycle are interlocked on it), part loaded, cycle start permitted.
- Both directions, hardwired outside the logic: the e-stop chain and safety interlocks. Safety lives in the safety circuit — light curtains, door switches, safety relays — never in program logic. The handshake below is for sequence, on top of a cell that's already safe.
The sequence, step by step
- 1CNC finishes the part, retracts to the load position, stops the spindle, raises ready for service.
- 2Robot sees it, raises request service; CNC opens the door and raises door open confirmed — from the sensor.
- 3Robot enters, grips the finished part, waits for chuck open confirmed, extracts, and retreats fully before doing anything else.
- 4Robot loads the blank, holds it in place, signals part loaded; CNC closes the chuck.
- 5Only on chuck closed confirmed does the gripper release and the robot withdraw.
- 6Robot clears the envelope, raises robot clear — and only then may the door close and cycle start fire.
- 7Any alarm, either side, at any step: freeze, signal, wait for a human. Automatic recovery mid-handshake is how one crash becomes two.
The rule under every step
Confirm, never assume. Every transition waits on a sensed state from the other machine — never on a timer, never on "I sent the command, so it happened." A chuck that lost air pressure looks identical to a closed chuck if all you checked was that you asked it to close. Timeouts exist to raise an alarm when confirmation doesn't arrive — never to proceed without it.
Details that separate smooth cells from haunted ones
- Use level signals for states, pulses only for events. "Door is open" should stay true as long as it's true, so either side can re-read reality after a fault instead of reconstructing it from missed edges.
- Write the contract down as a table — signal, meaning, who sets it, who clears it, timeout, alarm behavior — before wiring anything. Half the integration pain is two people holding different mental contracts.
- On the FANUC side, budget real time for mapping — robot I/O to the CNC's PMC addresses is bookkeeping, but wrong bookkeeping fails at 2 a.m., not at commissioning.
- Commission in single-step. Walk the whole handshake once with the robot at 10% and a hand on the deadman, watching each signal on the pendant and the PMC diagnostic screen. Ten minutes of this beats a week of mystery faults.
- Design the empty-hands recovery first. The hardest question in any cell is "where does the robot go from here?" A home-safely routine from any position, holding nothing, is the foundation every fault path lands on.
A good handshake is boring on purpose. Every exciting story about a robot cell is a story about a skipped confirmation.
Once the cell runs, the interesting layer sits above it: feeding the cell from your ERP, reading cycle data off the control, and knowing your true cell OEE. Planning a first cell, or unhaunting an existing one? Get in touch.
