Camera trigger at each waypoint: four-view inspection, one camera

Four stops around a part, one camera bolted to the arm, a result expected at every pose: the whole job is a move-stop-trigger-read block repeated at each waypoint. Programmed the wrong way - with the camera connection and its setup rebuilt at every stop - the same inspection crawls and fails intermittently. This guide gives you the program structure, the byte-level trigger handshake, and the cycle-time math that shows where the wasted seconds sit. It is written for anyone building the program directly on the teach pendant, with the camera mounted on the flange or forearm.

Initialize once, trigger and read at each waypoint

The pattern that fails is pasting the camera setup after every waypoint: open the connection, run the initialize call, take a snapshot, fetch a target. That sequence re-creates the connection and re-runs the camera's setup on every view, and it leaves you guessing whether the snapshot finished before the robot moved.

Split the program into three parts instead. In the initialization section that runs once before the loop, open the TCP socket to the camera and bring its inspection job ready. At each waypoint, move, stop, send the trigger, and block on the result string. After the loop, judge the four stored results and hand one verdict to the cell controller. Nothing about the camera gets rebuilt inside the loop.

The byte-level trigger

Most industrial code readers and many smart cameras expose a native TCP server for exactly this job: the controller sends the trigger, the camera acquires, evaluates and returns the result string on the same connection. Set the camera's connection mode to that server mode in its own settings first. In the common wiring it listens on port 3000, and the trigger is byte 15 (hex 0F) followed by byte 10, a line feed; some configurations expect a carriage return, byte 13, as well. Where the camera accepts ASCII text commands instead of raw bytes, the structure below stays the same and only the payload changes - triggering a smart camera over TCP with ASCII commands shows that variant.

# once, in the initialization section
conn := false                            # boolean, connection flag
conn := socket_open("10.10.10.10", 3000, "socket0")
                                         # 10.10.10.10 stands in for the camera's IP
                                         # 3000 = the native TCP port
                                         # "socket0" = socket name, string

# at each waypoint, robot stopped at the pose
socket_send_byte(15, "socket0")          # trigger: acquire and evaluate
socket_send_byte(10, "socket0")          # line feed ends the command
result := socket_read_string("socket0")  # string; returns at answer or timeout

The commissioning test that proves the block: park the robot at the first waypoint, fire one trigger, and read twice in a row. The first read returns the result string; the second must return nothing, because one trigger consumed one evaluation. If the first read returns nothing at all, the trigger never reached the job - the socket no-response checklist works through the send-loop causes in order.

Program it step by step

1. In the initialization section, declare a boolean conn, set it to false, and loop until the socket opens: conn := socket_open("10.10.10.10", 3000, "socket0"), with the camera's own address in place of the example IP. One open serves the whole program.
2. Bring the inspection job ready in the same section: load the job, set the camera to trigger mode, set a fixed exposure.
3. Move to the first waypoint. The move instruction completes only when the robot is at the pose.
4. Send the trigger: socket_send_byte(15, "socket0"), then socket_send_byte(10, "socket0").
5. Read the answer: result := socket_read_string("socket0"). The call returns when the string arrives or the timeout expires.
6. Store the string in this view's slot - four variables, one per waypoint - and treat an empty string as a fail verdict, not a program stop.
7. Repeat steps 3 to 6 at the remaining three waypoints, then judge the four results and report a single pass or fail.

Trigger only when the robot has stopped

The move instruction is your in-position signal: hang the trigger immediately after it, and the shutter fires with the robot settled. If the arm is long or the camera heavy, insert a short settle pause between move and trigger and keep it identical at all four stops, so the four images share one geometry.

Check the camera's trigger configuration before the first run: a camera left in its free-run default ignores byte triggers and keeps delivering frames nobody asked for - the per-camera trigger configuration guide lists the settings involved. Then let the blocking read do the timing. It returns only when the evaluation is finished, so the robot never moves while the camera works, and reading too early - the stale-result-per-cycle failure - cannot happen.

Worked example: cycle time for four views with a 0.2 s wait

• Views per part: four - the inspection task.
• Fixed wait per view: 0.2 s - the value the example program waits after each trigger when the pendant cannot block on the read.
• Frame rate: 60 fps - the printed rate of the LS-SMC-0063, the smart camera with its 16 mm lens built in.
• Run length: 1,000 parts - the example lot; scale the result to yours.

Fixed-wait program: t_wait = 4 × 0.2 s = 0.8 s of standing still per part. Over the example run, 1,000 × 0.8 s = 800 s ≈ 13.3 min spent waiting and doing nothing else.

Blocking read: t_frame = 1 / 60 s ≈ 16.7 ms, so four acquisitions take 4 × 16.7 ms = 66.8 ms ≈ 0.07 s per part, plus the job's own processing time, which you measure once at commissioning.

The vision segment is therefore about 0.07 s plus processing with the blocking read against 0.8 s with the fixed wait - more than ten times as much. Block on the read and drop the fixed wait entirely. Keep a wait only where the pendant cannot read synchronously, and size it to the measured answer time instead of a round 0.2 s.

Choosing the camera that rides the arm

Three properties decide it: processing on board, so no PC rides along - that is what a smart camera or vision sensor is for - a compact mount, where the M12-lens models dominate, and an Ethernet interface the pendant's socket layer can reach. Color sensing earns its place when a view judges appearance; mono is enough for geometry and codes. If a view only has to read a code at its angle, fixed code readers with the same native trigger replace the smart camera outright.

The MV-SCB007EC-12S-WBN pairs a 1.6 MP color sensor with a 12 mm lens on an M12 mount over Fast Ethernet. That is the entry point for a small part seen from four stops.

Stepping up, the MV-SC5060XM-08M-WBN moves to GigE with a 6 MP mono sensor and an 8 mm lens, still M12.

Two larger vision sensors cover the same four-stop pattern when the checks want more pixels or built-in lighting:

Keeping the four views consistent

Focus lives at one working distance. These cameras carry fixed, often manually focused lenses, so focus once and hold that distance at all four waypoints - a closer fourth stop blurs exactly the view you trusted. Arm vibration punishes a marginal focus as well, which is the trade-off the autofocus versus fixed-focus guide for moving robots works through.

Set exposure manually so the four images compare on one scale. A camera riding the arm sees the cell lights from four directions, and automatic exposure quietly rescales each view - the ambient light variation guide shows how far that moves a threshold.

Route the cable along the arm's dress pack with a service loop at the base, and strain-relieve it at the connector; a straight run off the camera back flexes every cycle and fails at the plug first. For building and teaching the four poses before installation, the slide tables and camera brackets hold the camera rigid while you teach.

When a view returns a position rather than a pass or fail, convert millimetres to metres and degrees to radians before composing the offset with a taught reference pose - applying camera offsets with unit conversion works the arithmetic, and sending camera offsets to the robot over a TCP socket covers the message format on the robot side.

Checks before the first part

• Socket opens once and the connection flag reads true - a mid-program reconnect is the usual source of dead reads.
• Camera set to trigger mode, not free run - byte 15 does nothing in free run.
• Read-twice test passes at waypoint one - one trigger consumes one evaluation.
• An empty result is stored as a fail and logged, not left to stop the program.
• All four poses sit at the working distance the focus was set at.
• Exposure fixed, lights on, ambient changes shadowed or shielded.
• Trigger-to-string time recorded - it sets the read timeout and closes out the fixed wait.

To pick the camera and the rest of the chain, the camera finder filters by mount, interface and resolution, and the system configurator assembles the set-up from the camera up. The neighbouring systems guides cover the socket, the trigger and the result handling from the robot's side.