How to average measurement values per part across repeated scene runs

The fix is to stop using the trend monitor's average and own the statistic yourself: declare Sum (real, initial 0.0) and Count (integer, initial 0) in job-scope persistent variables, add each pass reading into Sum and 1 into Count right after the measurement step, publish Mean = Sum / Count to the display or PLC register every pass, and clear both variables to zero in the first position of the start-marker scene. Cap Count at MaxSamples (set it to about five times the largest pass count a good part produces) so a missed end marker raises a bounded alarm instead of looping the measurement scene forever.

A long workpiece travels through the field of view, a marker starts the measuring and another marker ends it, and the measurement scene runs once per pass until the part is done. The trend monitor averages everything it has ever received, so the number on the screen mixes this part with the previous ten. This guide shows the method step by step, a worked example at 40 passes per part, and the two tests that prove the reset works.

What you need

• A camera platform whose flow supports arithmetic between scene executions: a calculation element, job-scope (persistent) variables and a conditional branch. Most smart cameras and vision controllers offer all three.
• Your existing two scenes: the start-marker search scene and the measurement scene, switched by the PLC or by internal logic.
• Three persistent variables, declared once. Illustrative names, to map onto whatever your platform calls them: Sum, a real number, initial value 0.0; Count, an integer, initial value 0; MaxSamples, an integer cap, set from the largest pass count a good part can produce.
• A place to publish the mean: an on-screen display element or a register the PLC reads.

Why the trend monitor average spans your parts

A trend monitor is a history tool. It appends every sample it receives and holds them until something clears the graph, so its average describes the whole production run. That is exactly what you want for a capability study and exactly what you do not want for a per-part display.

Clearing the trend at every scene switch fixes the number but discards the record, and on many platforms the clear is a display-layer action rather than something the flow can call at the right moment. Owning the statistic fixes both at once: the trend keeps recording for later, while the mean you display resets on an edge you control. It is the same principle as resetting camera settings programmatically before a capture: put the reset where your flow executes it, not where an operator has to remember it.

The accumulation method

The scenes can switch internally or be driven by the PLC. Where a start/stop handshake triggers each pass, the count is only as good as that handshake: one missed or doubled trigger shows up immediately as a Count that disagrees with the PLC's own count, a fault pattern the vision project start/stop handshake troubleshooting guide covers in detail. With that settled, the method is six steps.

1. Declare the variables in job or flow scope, not scene scope. Sum (real, 0.0), Count (integer, 0) and MaxSamples (integer, your cap). Job-scope variables survive the switch between scenes; scene-local variables are rebuilt empty at every start and silently drop the earlier passes.
2. Initialize once, in the start-marker scene. First position in the flow: Sum = 0.0 and Count = 0. This scene runs only when a part has just ended, so the reset fires exactly once per part.
3. Accumulate after every measurement. Directly after the measurement step: Sum = Sum + reading, Count = Count + 1. One addition per pass, no arrays, nothing stored per sample. The value you add must belong to this pass; a stale frame from the previous part corrupts the sum quietly, which the conveyor vision scene timing guide shows how to catch.
4. Compute and publish the mean on every pass. Mean = Sum / Count, written to the display element or the PLC register right after the accumulation. Guard the division: publish only when Count >= 1.
5. Cap the counter before the loop continues. A conditional branch ahead of the end-marker decision: if Count >= MaxSamples, stop accumulating, raise the alarm and force the flow back to the start-marker search.
6. Latch the final result at the end marker. Copy Mean and Count into the result registers the PLC reads, then return to the start-marker scene, which resets on its next entry.

The add-on-each-pass pattern is the same one behind how to accumulate a value on each loop iteration: one addition per cycle, one division for the display, no per-sample storage.

Worked example: one long part measured over 40 passes

Inputs, and where each comes from: 40 measurement passes on one part (a typical count for a long part measured once per scene pass); readings are gap widths in millimetres from the measurement tool; MaxSamples = 200, which is 5 x 40; Sum starts at 0.0 mm and Count at 0 at the start marker.

The rule in words: add every reading into Sum, add one into Count, and publish Sum / Count after each pass.

• Pass 1: the tool reads 1.220 mm. Sum = 0.0 + 1.220 = 1.220 mm, Count = 1, Mean = 1.220 / 1 = 1.220 mm.
• Pass 20: the first twenty readings total 24.320 mm. Mean = 24.320 / 20 = 1.216 mm.
• Pass 40: the last twenty readings total 24.280 mm, so Sum = 24.320 + 24.280 = 48.600 mm and Count = 40. Mean = 48.600 / 40 = 1.215 mm.

Result: the part's mean is 1.215 mm over 40 samples.

Decision: against an illustrative tolerance of 1.200 +/- 0.030 mm (accept 1.170 to 1.230 mm), 1.215 mm passes with 0.015 mm of margin to the upper limit. The cap leaves 200 - 40 = 160 passes of margin: if the end marker is missed, the flow alarms at Count = 200 and returns to the start search instead of looping, and because the reset lives in the start-marker scene, the next part begins from zero whatever happened before. Check the arithmetic the same way your verification will: 24.320 / 20 = 1.216, 24.320 + 24.280 = 48.600, 48.600 / 40 = 1.215, and Mean x Count reproduces the total, 1.215 x 40 = 48.600 mm.

Where the flow runs

The method is identical either way. When one camera carries the whole inspection, its scene logic runs the accumulation on the device itself:

For a single-camera cell driven from a controller, the MV-VC2140-128G40-1T holds the flow with 8 GB of memory and four built-in light channels:

When several cameras feed one flow, the MV-VC5525-256G70-NN combines PoE camera ports, 5+ LAN ports, 32 GB of memory and eight built-in light channels, so the accumulation and the light sequencing stay in one place:

Verify it worked

1. Known-value test. Run one part and export or note every pass reading. Sum them in a spreadsheet and divide by the count; the display must match to its last shown digit. For the worked example above, the display shows 1.215 mm and the check is 1.215 x 40 = 48.600 mm against the logged total.
2. Back-to-back reset test. Run two parts with different readings in a row. The first pass of part two must display part two's own first reading exactly, because Count restarted at 1. If it shows a blend of both parts, the initialization sits in the wrong scene or the variables live in a scope that is not shared between scenes.

Common mistakes, in the order they usually turn up:

• Initialization placed in the measurement scene: the total wipes after every pass and the display just echoes the newest reading.
• Variables declared inside the scene execution: Count never climbs past 1 and the mean equals the latest sample.
• Publishing before the first sample: the display divides by zero at the start of every part.
• No cap: a missed or unreadable end marker loops the measurement scene and the total grows without limit.
• Mean rounded into an integer variable: the decimals you are judging disappear before the display.

When to log every sample instead

The mean answers whether the part was consistent overall; it must not replace the per-pass tolerance check, which trips on any single bad reading even when the mean stays inside spec. Publish min and max next to the mean where the display allows it, and log the samples when the process needs capability data later. For aggregates queried after the fact, such as the average of one part out of a week of runs, a time-series store handles querying recent data across measurements without the flow carrying history at all.

Decide the recovery before it happens. If the device restarts mid-part, the variables die with it, so alarm the part and restart the accumulation on the next start marker; long-running state on cameras has its own failure patterns, covered in the smart camera fatal error and recovery guide.

Next step

If you are specifying hardware for a marker-switched measurement like this, start from the passes per part, the camera count and the PLC interface, then pick the platform. The configurator walks the camera, lens and lighting choices in order:

Or send the pass count and the interface to us through the contact page and we will propose a camera and controller pairing. More scene-logic faults are collected on the systems topic page.