Omron's pitch is that vision isn't a separate machine — the FH vision system sits on the same EtherCAT network as your servos, configured in the same Sysmac Studio project. The PLC triggers an inspection like it powers an axis; results land in ordinary variables; and the measured X/Y/angle flows straight into motion commands. Camera to claw, one project.
Parts arrive on the belt slightly off-centre — that's reality. Press TRIGGER as a part enters the camera's field: the FH measures the offset, returns OK/NG plus X-offset and angle into the PLC's variables, and the pick head moves to the corrected position instead of the nominal one. NG parts are let through to the reject chute. Watch the result variables flash as each judgement lands.
trig(Execute := doInspect, // rising edge! SceneNo := 3); // 'cap offset' scene IF trig.Done THEN IF VisResult.Judge = OK THEN // pick at corrected position mv(Position := rNominalX + VisResult.OffsetX); END_IF; END_IF;
Results arrive as cyclic process data on the same EtherCAT frame as the servo setpoints — no sockets, no parsing, no register maps.
Timing is the whole game: trigger while the part is inside the field of view, and remember the belt keeps moving during the inspection — the FH returns in tens of milliseconds, and the pick coordinate must account for the travel since the photo. Real cells latch an encoder position at the exact trigger instant for that correction; that latch-and-offset pattern is the heart of every vision-guided conveyor application.
🗂️ Scenes are recipes. The FH organises inspections into numbered scenes (scene 3 = cap offset, scene 7 = label check). The PLC selects the scene at trigger time — so a product changeover is just a different number in the same FB call, driven by your recipe system.
⚡ It's an EtherCAT slave like any other. The FH appears in the Sysmac Studio network view next to your drives: cyclic PDOs carry trigger bits and core results; larger data (measured coordinates, strings, images) moves acyclically. Same diagnostics, same cable, same project file.
📐 Calibration makes pixels into millimetres. The camera measures in pixels; the robot moves in mm. A calibration (dot grid or touch-and-teach) establishes the transform — and it silently expires when someone bumps the camera, changes the lens, or raises the conveyor. Re-calibrate on any mechanical change, and verify with a known part.
💡 Lighting is 80 % of vision. The most common 'PLC bug' in a vision cell is the afternoon sun. Stable, controlled lighting (and a hood) beats every algorithm setting — buy the light before tuning the threshold.
After a weekend maintenance shutdown, the cell picks every part 4 mm off-centre — consistently, in the same direction. Inspections still judge OK. What's the most likely cause?