09. Capstone — Vision·Robot·Gripper Automation Cell

What you'll learn

• 1Handle vision=TCP Server·robot=Modbus Slave·gripper=Modbus Slave from one controller at once
• 2Encode vision float coords with split_word and send them as the robot's Cartesian LIN cycle (incl. negatives)
• 3Serialize the robot·gripper cycles safely with state polling (avoid latch)
• 4Orchestrate vision→pick(2-stage Z)→grip→place→release→home and measure cycle time

Introduction

The cell controller (cell_controller) is the conductor. It connects to vision as a TCP Client and commands the robot·gripper as a Modbus Master. Roles are decided by "who speaks first" — vision is a Server from the robot's view, but here the controller is the Client connecting to it.

Key concepts

1) One cycle's sequence

① send {TRIG} to vision → receive {X,Y,R}     (TCP/IP, lesson 3)
② robot LIN: (X,Y,approachZ) → (X,Y,pickZ)      (Modbus, lesson 6)
③ gripper close = pick part                     (Modbus, lesson 7)
④ robot LIN: pick up → place position           (Modbus, lesson 6)
⑤ gripper open = release part                   (Modbus, lesson 7)
⑥ robot GO HOME = return to origin              (Modbus, lesson 6)

2) The integration trap — state latch

Chaining the three devices, a prior motion's done signal lingers in the register (latch) and the poll passes before the next motion starts. Two defenses: ① the robot waits for IR524==2(Running) first, then IR524==1(Idle)+IR200==1(Success) — a 2-step poll; ② the gripper checks IR769==2 AND HR1606==0. Writing the next trigger immediately after HR200=0 reset locks the robot (it never sees the 0), so leave a poll cycle or two after the reset.

Core example

Functions are split into get_vision / robot_move / gripper_act / go_home so each step can be debugged independently.

def robot_move(m, x, y, z, a=0, b=0, c=0, cmd=1, mtype=1):
    axis = []
    for v in (x, y, z, a, b, c):
        low, high = split_word(round(v * 1000))   # ×1000 to int then 32-bit split (negatives too)
        axis += [low, high]
    m.write_holding(201, [cmd, mtype] + axis + [50, 100, 1, 0])
    m.write_holding(200, 1)
    while m.read_input(524,1)[0] != 2: time.sleep(POLL)        # ① wait for Running
    while not (m.read_input(524,1)[0]==1 and m.read_input(200,1)[0]==1):
        time.sleep(POLL)                                       # ② done
    m.write_holding(200, 0); time.sleep(POLL * 2)              # reset + recognition wait

Common mistakes

Q. From the second move, the robot shows "done" immediately (but doesn't move).

A. Looking only at IR524==1(Idle) passes because the prior command's Idle latches. Wait for IR524==2(Running) first, then IR524==1 & IR200==1 done (2-step poll).

Q. From the second move, the robot doesn't move at all and times out.

A. Writing HR200=1 right after HR200=0 reset means the robot never sees the 0, so ack doesn't clear and the command locks (manual 5.3.3.5 ⑤). Leave a poll cycle or two after the reset.

Q. A simulator won't start with Address already in use.

A. The three simulators share a port or a prior process holds it. Separate ports as 6000/1502/1503 and Ctrl+C old terminals before restarting.

Summary

• Automation cell = vision(TCP/IP)+robot(Modbus command cycle)+gripper(Modbus cycle)+home, orchestrated by one controller
• The controller is a TCP Client to vision and a Modbus Master to robot·gripper — decided by "who speaks first"
• Vision float coords → split_word(round(v*1000)) → Cartesian LIN; negatives round-trip via auto & 0xFFFF encoding
• The key to chaining is serializing with state polls: robot IR524 2→1 & IR200=1, gripper IR769=2 & HR1606=0 (avoid latch)

Exercises

1. Start the three simulators, complete one cycle, and confirm cycle time
2. Run the --trig TRIG2 negative-coord cycle and decode IR400~411 to confirm X=-45.10
3. Run --cycles 2 to process TRIG/TRIG2 in a row, reusing connections, and print average cycle time