Run the camera inspection once at program start and save the pose

In a vision-guided cell the camera has one of two jobs: find every part as it arrives, or report one position that stays valid for the whole run. When the part sits in a fixed nest, that second job needs a single inspection at start-up — yet most programs keep triggering the camera every cycle, paying inspection time on each part and adding a fresh failure point per pick. This guide moves the inspect command into the program's once-only Before Start section, saves the returned pose in a variable, and wires the cycle loop to read the saved value. You will also get the tests that prove the camera fired exactly once.

Inspect once when the position is a property of the cell

If the nest, the camera bracket and the tool stay put for the whole run, the part's position is a property of the cell, not of each part. Inspecting every cycle re-measures something that has not changed. The decision rule is short: a fixed nest means one inspection per program run, stored once and read forever after; loose or moving parts mean an inspection per pick, and a saved pose is the wrong tool.

The once-per-run cost is small. Give the inspect command a 2 s timeout and up to three attempts, and the worst case at start-up is 6 s of waiting. That budget only has to beat the per-cycle inspection you are removing, which the next section puts in numbers.

What one skipped inspection saves

Timestamp the camera trigger and the reply once in your own cell to get the real inspect-and-reply time; 400 ms per cycle is a realistic working figure for this example. At 1,200 parts per shift, the removed inspection turns into pure cycle time:

The 6 s start-up budget pays for itself after 15 cycles (6 s ÷ 0.4 s = 15). Everything after that is margin. You have also removed one communication round-trip per cycle — one fewer place for a timeout to stall the cell mid-shift.

What you need

• Program access on the pendant, so you can enable the once-only start section on the program's top node. It executes before the main loop, ahead of the cycle code.
• A camera or vision controller whose inspect command the robot can reach: a digital output pulse or a request string over TCP. Both hand-off routes are covered in starting an inspection automatically from a custom program and the smart camera to robot TCP data exchange.
• A program variable for the pose, with an initial value you choose deliberately.
• The part loaded in its nest before you press start.

Step 1: fire the inspect command in the Before Start section

1. Load the part, then open the program tree and enable the Before Start section on the program's top node. On a script-generated program this block sits ahead of the main routine, which is the point: the controller runs it once, before the first cycle.
2. Move your existing inspect call into that section unchanged — the same output pulse or request string the loop used.
3. Add a timeout and retries around it. Expect the reply within 2 s and retry up to twice, so a missing part faults the start clearly instead of hanging the program.
4. Leave the main loop untouched. The next steps swap what the loop reads.

Step 2: store the pose in a variable with a sane initial value

1. Create the variable and give it the taught pose as its initial value, written as six values: x, y, z and the three rotations. The pose-read call on this controller family is get_actual_tcp_pose(), which returns the pose as p[x, y, z, rx, ry, rz] — translations in metres, rotations in radians, in base coordinates by default.
2. Fill the variable from the camera reply: parse the numbers out of the message and write them in. A malformed reply is a fault, never zeros.
3. Teach it from the robot instead when the nest position is known on the tool side: jog to the taught point, stand still, call get_actual_tcp_pose() and assign the result to the variable. If the point already exists as a taught waypoint, assign the waypoint itself to the variable — same pose, fewer moving parts.
4. Name the variable for what it holds. fixture_pose_start says more than var1 when a fault appears mid-shift.

A sketch of the structure; fixture_pose_start and the motion call stand for your own names:

# Before Start — runs once per program run
# trigger the inspect, wait up to 2 s, retry twice, then:
fixture_pose_start = get_actual_tcp_pose()   # p[x, y, z, rx, ry, rz]

# Main loop — every cycle
move_to(fixture_pose_start)                  # your controller's motion call

Step 3: make the cycle loop read the saved variable

1. Replace the per-cycle inspect call with a read of the variable. The move that used to wait for the camera now starts from the saved pose immediately.
2. If your communications layout forces the trigger to stay in the loop, gate it with a counter: run the inspect only while the counter is zero and increment it inside the same branch, so the command fires exactly once per run.
3. Log the pose you wrote at start-up. The detection score logging pattern works for any value, poses included, and gives you something to compare across restarts.

How to verify the inspection ran once

1. Counter test: run 20 cycles and watch the trigger. The output pulse, or the camera's own inspect counter, moves once — not twenty times.
2. Restart test: stop the program mid-run and start it again. The Before Start section runs once more, the variable resets to its initial value, then takes the fresh reply.
3. Power-up test: after a cold start, before the first run, the variable holds the taught initial value. If yesterday's numbers are still there, you wrote to storage the controller keeps across power-off, and the startup inspection is being skipped — the dangerous case.
4. Fault test: raise a robot fault, clear it, restart. The comms-side habit in vision job lost after a robot fault restores the connection; the Before Start section restores the pose.

Five mistakes that put the camera back in the loop

• The inspect call stayed in the loop. The most common one: the startup inspection runs, then the loop triggers the camera again anyway.
• The guard counter resets every cycle. If a loop pass zeroes the counter, the trigger fires again. Increment it inside the guarded branch, nowhere else.
• The variable has no initial value. The first read, before any successful reply, hands the robot an undefined pose.
• The pose was saved while the robot was still moving. Read it only when the robot stands still at the taught point, or you store a moving target.
• The frame does not match. The camera reports in its calibrated frame; the robot moves in base coordinates. Convert before you store — the eye-to-hand calibration transform is where that maths lives.

When a saved pose is the wrong pattern

• Parts arrive loose or shift part to part: inspect per pick instead. When every cycle needs a fresh measurement covers that side.
• A pallet or destacker exposes layers: teach one snapshot position per layer, as in tray destacking robot vision.
• Two different parts share one program: separate snapshot positions per part, as in teaching two parts in one vision program.
• A fixed nest that drifts — tool wear, temperature, changing ambient light — needs a re-inspection per shift or per batch. The ambient light variation guide shows how to hold the optical side steady while the geometry stays fixed.

Hardware that runs this pattern

Any camera the robot can trigger fits; the real choice is where the inspection runs. A smart camera carries the inspection on the device and hands coordinates straight to the robot program. The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm focal-length lens in an M12 mount over a GigE interface.

A vision controller takes the heavier side of the split: several cameras, lighting control and result logging in one box on the robot's network. The MV-VC5525-256G70-NN combines PoE camera ports, eight built-in light channels and 32 GB of memory, with five or more LAN ports for camera and robot traffic.

The MV-VC2140-128G40-1T is the compact pick for a single-camera cell: 8 GB of memory, a 128 GB SSD plus a 1 TB HDD, four built-in light channels and three to four LAN ports.

Filter either side by ports, resolution and mount in the smart camera finder. More cell-integration patterns sit on the vision systems topic page. Tell us the part, the cycle target and whether the nest truly stays fixed, and we will spec the capture side — or start at the camera step in the configurator:

If you would rather talk it through first, the contact page reaches the applications team.