Vision detection score variable: log it in the robot program

Your production snapshot position sits where the calibration position does not, and when a locate starts failing, the usual fix — reopening the locate wizard — drags the robot back to the teach position you cannot spare. You do not need that trip. The camera add-on already hands the program a result array that carries the part count, the pose and the match score, so the score can be copied into your own variable and logged cycle after cycle, right where production happens. This guide gives you the array layout, the assignments that capture it, the threshold rule that turns logged scores into an alarm with worked arithmetic, and the hardware that keeps the history — all inside the program tree you already have.

Where is the detection score in the locate result?

The score sits in the last element of the array the Camera Locate node fills: on a 0-indexed array, f[0] is the number of parts found, f[1] through f[6] are the pose, and f[7] is the detection score. The add-on refreshes the whole array each time the program passes the Camera Locate node, and elements 1 to 6 hold the same pose as the object_location variable — p[x, y, z, x rotation, y rotation, z rotation] — expressed in the robot's base reference frame. Length and angle units are whatever your pendant already uses for pose variables, so nothing needs converting on the way in.

The array is overwritten at every locate, so copy the fields you need into your own variables before the program can reach another locate node. The pose values themselves are the end product of the camera calibration: object pose in camera frame at runtime after hand-eye calibration shows how that pose is produced, and using eye-to-hand calibration results to compute robot-base picks shows where the base-frame numbers go next.

How do you assign the score to a variable in the robot program?

Assign your own variables directly after the locate node — var_1 ≔ f captures the whole array, var_2 ≔ f[0] the part count and var_3 ≔ f[7] the score — and you do not initialize f yourself, because the locate fills it before the next line runs. The steps, in order:

1. Keep the Camera Locate node where it is; the locate itself does not change.
2. Add an assignment immediately below it: var_1 ≔ f, which takes all eight elements in one step.
3. Add the two reads you actually use: var_2 ≔ f[0] for the part count and var_3 ≔ f[7] for the score.
4. Keep var_2 and var_3 numeric. The score is a plain number, not a pose, so a pose variable is the wrong container.
5. Put the log line from the next section below the reads, in the same branch of the tree.
6. Check it once on a good part: run a single cycle and compare var_3 with the score the locate wizard reported for that part; the two numbers should agree.

The working order looks like this:

Robot Program
  MoveJ Waypoint_1
  Camera Locate
  var_1 ≔ f
  var_2 ≔ f[0]
  var_3 ≔ f[7]
  sync()

If a read of f raises a variable error, the read is sitting above the locate in the tree; move it below. The add-on's maker has not published a manual page for this array, so treat the eight-field layout as the add-on's convention and let the one-cycle check in step 6 confirm it on your cell — it takes under a minute.

What should you log after each locate?

Log three values after every locate — the count f[0], the pose f[1] through f[6] (or at least x and y) and the score f[7] — each line stamped with the time, because a production failure is diagnosed from the pose and the score together, not from the score alone. One cycle, one line:

14:32:07  count=1  x=412.3  y=188.0  score=0.94

Use whatever text output your controller offers — its message log or a file write — and keep the format fixed so the log stays machine-readable. The count answers "was anything found", which is the boolean check in the part detected flag variable article; the score answers the question the flag cannot: how well the part matched when it was found. Once the log exists, statistics fall out of it for free — the averaging measurement values per part guide turns repeated readings into per-part means. And if your vision runs on a separate device that sends results as text, parsing four vision results from one socket string shows how to split the message into the same fields. More program-side habits like this sit on the systems topic page.

Why is the production score lower than the calibration score?

The production score drops when the production snapshot position differs from the calibration position, because the part then sits elsewhere in the image — under different light, at a different angle — and fewer of the taught features line up. The model behind the score was taught at the calibration position: that light, that viewing angle, that part presentation. The score quantifies the gap, which is why a sinking score is useful even when every cycle still passes: it measures how far presentation has drifted. What the number means on a general matcher, and why the coarse search gates the result, is covered in the pattern match score threshold guide. Lighting is the most common mover of the number, and the ambient light variation guide for pick and place vision lists the shielding and exposure habits that hold it steady.

Two rules keep the comparison honest. First, compare only scores from the same taught model on the same camera: the scale is the add-on's own, not a standard unit, so 0.9 from one model says nothing about 0.9 from another. Second, judge every production reading against a baseline recorded once at teach time, at the calibration position — the next section turns that baseline into a limit.

How do you set a score threshold that catches bad locates?

Record the score on ten good parts at the calibration position, then set the acceptance limit about 10 to 15 percent below the lowest of those readings, and log every production score against that limit from the first cycle on. The margin has a basis: it must exceed the cycle-to-cycle scatter your own baseline shows, so treat 10 to 15 percent as the starting value and tighten it to roughly five times the observed spread once the ten readings are in hand.

Worked example — example readings from one cell, so your own ten parts set your own limits. Baseline scores: 0.97, 0.96, 0.95, 0.97, 0.96, 0.95, 0.96, 0.97, 0.95, 0.96. Lowest 0.95, spread 0.02.

The alarm limit sits 0.14 below the baseline — seven times the 0.02 spread — so it ignores noise and still catches real drift. A production morning then logs 0.94, 0.93, 0.91, 0.86, 0.79, and the last line decides:

The same log row carries the pose: x fell from 412.3 mm at baseline to 408.7 mm, so presentation moved 3.6 mm and the infeed guide is the first place to look. The decision for each case: score under 0.81 with count 1 → investigate lighting and presentation, not the program; score under 0.71 → stop the cell before matches become unreliable; count 0 at any score → missing-part handling, which the flag pattern already covers. Route that stop through the cell's existing stop chain — the safety circuit or supervisor logic your risk assessment defines — rather than a soft program flag alone.

When do you still need the calibration snapshot position?

Move the robot back to the calibration snapshot position only when the teach itself is in doubt — a bumped camera bracket, a replaced lens, a refocus or a lighting change — because the logged production scores, not a wizard re-test, are what tell you whether the locate degraded. The log gives you the trigger for each case. Pose shifted by the same few millimetres for every part → the camera or its bracket moved; re-mount and recover the calibration before touching the teach, which is the job of the vision calibration recovery guide. Score down across all parts with pose steady → lighting; fix the light first. Score and pose both fine but picks missing → the calibration itself drifted; that is the case that justifies the trip back. When the process genuinely needs several viewpoints — one snapshot position per tray layer, say — teach each one deliberately and keep a baseline per position, as the tray destacking snapshot position guide lays out. After any re-teach, record a fresh ten-part baseline so the alarm limit restarts from current numbers.

Which hardware runs the locate and keeps the logs?

A vision sensor or smart camera runs the locate on the device and hands count, pose and score to the robot over Ethernet, while a vision controller adds local storage that keeps the log for as long as the line runs. For a single-locate cobot cell, a 5 MP color vision sensor with a global shutter and an M12 mount does the locate on the device and talks to the robot controller over Fast Ethernet:

When the locate wants its own illumination switched with the cycle, a smart camera with an 8 mm lens adds an integrated multi-color light source on a GigE interface:

Where traceability rules demand that every score line survive restarts and audits, run the vision on a vision controller with 8 GB of memory and a 128 GB SSD plus 1 TB HDD and keep the log local to the line:

So: pick the vision sensor for one locate and one robot; the smart camera when the light must change with the cycle; the vision controller when the log is a requirement, not a habit. Browse the smart cameras and vision controllers categories, filter the camera finder by resolution and interface, or start at the camera configurator from your cycle rate and field of view. To talk a layout through first, the contact page reaches the applications team.