Omron sells vision as part of the same machine rather than a separate one. The FH vision system sits on the same EtherCAT network as your servos and is configured in the same Sysmac Studio project. The PLC triggers an inspection the way it powers an axis, the results land in ordinary variables, and the measured X/Y/angle feeds straight into motion commands. From camera to claw, it is all one project.
Parts arrive on the belt slightly off-centre, as they do on any real line. 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 in the same EtherCAT frame as the servo setpoints, so you write no socket code, no parser and no register map.
Timing decides whether the pick lands. Trigger while the part is inside the field of view, and remember that the belt keeps moving during the inspection: the FH returns in tens of milliseconds, so 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, and the same latch-and-offset pattern sits underneath 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 sends a scene-switch command before it triggers, so a product changeover is only a different scene number, set 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, commands and measurement results such as the offsets; larger data (strings, images) moves acyclically. The FH shares the diagnostics, the cable and the project file with your drives.
📐 Calibration makes pixels into millimetres. The camera measures in pixels; the robot moves in mm. A calibration (dot grid or touch-and-teach) sets up the transform between the two. It goes out of date without any warning when someone bumps the camera, changes the lens or raises the conveyor, so re-calibrate after 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) does more than any algorithm setting, so buy the light before you tune the threshold.
After a weekend maintenance shutdown, the cell picks every part 4 mm off-centre, consistently and in the same direction. Inspections still judge OK. What's the most likely cause?