Detect snap movement frame by frame: tracking a fast shape change

A bimetal thermal protector does its job once, quickly: heated past its trip point, the disk flips within milliseconds and breaks the circuit. If you test such disks in an oven, the vision task is not to freeze that flip but to catch it and pin a temperature to it: filter each image, find every disk, and flag the frame in which a disk's tracked position jumps. This application note sizes such a system end to end — frame rate, pixels per disk, lens and stand-off, lighting through oven glass, the snap threshold and the temperature time-stamp — and ends with cameras that fit. The numbers come from one worked example: a 32 × 32 array of 1,024 disks ramped from 25 to 200 °C over one hour.

What frame rate do you need to catch a snap?

Five frames per second is enough, and two still works: the disk stays flipped once it snaps, so the frame rate only sets how finely you can time-stamp the event, and at 5 fps on this ramp that timing error is about 0.01 °C. The snap is latching, not transient — you bracket it between two frames, you never freeze it, so a high-speed camera buys you nothing here.

What the frame rate actually buys is temperature resolution. The ramp runs 175 °C in 3,600 s, or 0.049 °C/s. One frame interval of uncertainty costs ramp rate divided by frame rate:

At 5 fps the bracket is 0.049 / 5 = 0.0097 °C, call it 0.01 °C. At 2 fps it is 0.024 °C, and even 1 fps gives 0.049 °C — all far inside a 0.3 °C measurement budget, so 5 fps is comfort, not necessity. Exposure can be generous because the parts hold still: 10 ms is typical, and the exposure-plus-readout ceiling sits far above 5 fps on any current GigE camera — the mechanics of that ceiling are covered in maximum frame rate on a hardware trigger and in why a GigE camera drops frames at long exposure.

Bandwidth is a non-issue at this rate: 1,600 × 1,200 pixels at 1 byte and 5 fps is 9.6 MB/s, about 77 Mbit/s, a small share of a GigE link, so one camera, one cable, one PC.

How many pixels does each disk need?

Give each disk at least 25 pixels across its diameter — the worked example delivers 27 — so a sub-pixel centroid cleanly separates a 0.05-pixel creep step from a 4-pixel snap jump. Assume disks about 10 mm across on a 14 mm pitch: a 32 × 32 grid then spans 448 mm square. A 1,600 × 1,200 sensor must cover that square with its short side, so 1,200 pixels span 448 mm and one pixel equals 448 / 1,200 = 0.373 mm on the part. A 10 mm disk images at 10 / 0.373 = 27 pixels across.

The 4:3 sensor then wastes a third of its width (the horizontal field becomes 1,600 × 0.373 = 597 mm) — that is the price of a square array on a rectangular chip, and it is worth paying for a round part count. With a clean, high-contrast blob, sub-pixel centroid fitting repeats to roughly a tenth of a pixel, so a 1-pixel decision threshold has a ten-to-one noise margin.

What lens and stand-off cover the array without edge distortion?

A 35 mm C-mount lens about 2.9 m above the array does it: the corner disk then sits about 6° off axis and its perspective foreshortening stays near 0.6 percent, invisible to a blob threshold. Distortion matters here because a foreshortened disk looks like a moved disk, and moved disks are exactly what you are measuring.

With a sensor 5.5 mm on its short side (a 4.6 µm pixel pitch on 1,200 rows):

The magnification is m = 5.5 / 448 = 0.0123. Rearranged for a 35 mm lens, the working distance is WD = f × (1 + m) / m = 35 × 1.0123 / 0.0123 = 2,885 mm, about 2.9 m. The corner disk sits at half-diagonal √(224² + 224²) = 317 mm off axis, an angle of atan(317 / 2,885) = 6.3°, and cos(6.3°) = 0.994, so the corner shrinks 0.6 percent. Pull the camera in to 0.6 m and the same corner sits 28° off axis, cos = 0.884, an 11.6 percent shrink — enough to corrupt any per-disk threshold. The long stand-off, not an exotic lens, is the fix, and standard C-mount optics keep the cost down.

Depth of field is not a constraint at this magnification: at f/5.6 with a one-pixel circle of confusion (0.373 mm on the part), the estimate 2 × N × c × (1 + m) / m² works out near 30 m, so focus once and lock the barrel.

Run your own array numbers through the calculator:

How do you detect the snap between two frames?

Filter the image, locate each disk as a blob at its known grid node, and flag the snap when the centroid moves more than about 4 percent of the disk diameter between consecutive frames while the blob area changes more than 10 percent. Two gates, not one, because the flip is mostly out of plane and the projected silhouette often changes more reliably than the centroid.

The pipeline runs in three passes per frame. First a smoothing filter removes sensor noise and softens reflections off the safety glass and the base-metal strip. Second, grid gating: disks sit on a known 14 mm pitch, so accept a blob only inside a ±10 pixel window (±3.7 mm) around its expected node; windows are 20 px wide against a 37 px pitch, so they never overlap, and off-pitch reflections are simply dropped. Third, per-disk tracking: keep a ring buffer of centroid and area, one entry per frame, for all 1,024 disks.

Thresholds come from a logged ramp, not from guesswork. In the example, creep moves a centroid by about 0.05 px per frame (0.2 percent of the 27 px diameter); a snap moves it 1.5 mm, or 1.5 / 0.373 = 4 px, about 15 percent of the diameter, and shifts area 10 to 20 percent. The committed rule: movement above 1 px (4 percent of diameter) together with an area change above 10 percent between consecutive frames is a snap. That is 20 times the creep noise and a quarter of the snap jump, expressed against disk diameter so it ports between lenses. The same blob machinery that counts and sorts parts by shape is covered in blob analysis for glass detection, and the sub-pixel details are in half-pixel offset in blob centroid — fix your coordinate origin convention once, before you log anything.

How do you light the disks through oven glass?

Light from all four sides through the glass walls with constant-current or high-frequency sources, never down through the roof: the roof plates pass too little light, and one-directional light casts shadows that move like snaps. That roof failure is the documented dead end of this application — a backlight behind the press plates never delivered enough photons, while side entry through glass lit every disk from all directions and killed the shadows.

Lamp drive matters as much as geometry. Mains-frequency ripple at 100 Hz has a 10 ms period: a 10 ms exposure integrates exactly one cycle and comes out even, but 120 Hz ripple leaves 0.2 of a cycle exposed and the mean intensity wanders frame to frame — which reads as area change and false snaps. Kill it at the source: LEDs on a constant-current controller, or lamps driven in the tens of kilohertz. Any exposure is then clean. A red bandpass filter over the lens with red LEDs raises contrast when enough red light reaches the parts; measure that before committing, because the filter that helps contrast can starve exposure. The lighting step of the system configurator sizes drive current and strobe timing for exactly this class of problem.

Enclose the camera in a light-tight box on its stand: plant light leaking in changes slower than your frame rate but faster than your ramp, and it pollutes the area gate. The general discipline of lighting before exposure before software is laid out in stable 2D vision inspection systems.

How do you time-stamp the snap against oven temperature?

Sample every temperature sensor with every frame and attach the nearest sensor's reading to the first frame that shows the snap: timing then costs about 0.01 °C and the sensors own the rest of the 0.3 °C budget. Six Pt100 zones across the oven give each disk a nearest sensor; spatial gradient, not camera timing, is where the accuracy lives.

Do the sensor arithmetic before trusting the budget: a Class A Pt100 tolerance is ±(0.15 + 0.002 × |t|) °C, which is ±0.55 °C at 200 °C — wider than the 0.3 °C target on its own. The gap closes with in-situ calibration of each sensor against a reference, and that calibration is what actually buys the accuracy, not the camera. To keep the frame-to-temperature pairing honest, read camera frame rate measurement from timestamped frames and log both streams continuously.

Write one CSV row per snap — grid index, snap temperature, frame timestamp — and import it into whatever QA tool you run. Track the batch mean and sigma of snap temperature over time: a drifting mean is the earliest warning of stamping or welding tool wear on the line.

Which camera should you pick today?

A 2.5 MP global-shutter GigE camera with a C-mount is the like-for-like choice; go to 12 or 20 MP when the array grows or the disk detail you need is finer than the snap geometry. The example above uses the 1,600 × 1,200 format; at a similar pixel pitch, 12 MP covers about 2.2× the array width at the same 27 pixels per disk, since the pixel area grows 4.8-fold.

The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter, a 1/1.7" sensor and a C-mount.

Three current area scan cameras span the range:

All 3 share: Binning Supports 1 × 1, 2 × 2, 4 × 4; Lens mount C-mount; Certification CE, RoHS, KC; Mono/color Color. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-CH120-11UC takes that to 12 MP over USB3 with a global shutter and a 1.1" sensor. The MV-CS200-10GC gives 20 MP over GigE with a 1" sensor and a C-mount; its rolling shutter tolerates this duty because the array holds still between events, though global shutter keeps the transition frame cleaner. Processing load is light: 1,024 blob fits per frame × 5 fps is about 5,100 fits per second, ordinary work for a desktop CPU that is also writing the log — the framing for that judgement is in smart camera image processing time. On the plant floor, industrial mini PCs survive the heat and vibration that a desk tower will not. Browse the full area scan cameras range or filter by sensor format and shutter in the camera finder.

What makes a snap detection false-trigger or miss?

Three causes account for nearly all bad snaps: lamp ripple beating the exposure into intensity wander, glass and strip reflections passing as blobs, and the re-close on cooling re-tripping a heating threshold. Each has a number attached. Intensity wander: log 200 frames at a steady temperature and demand frame-to-frame mean spread under 1 percent — more than that means the light drive, not the algorithm, is wrong. Reflections: the ±10 px grid window rejects them by construction. Re-close: tag every event with its ramp branch, heating or cooling, so a hysteresis re-close is recorded as its own measurement rather than a second snap.

Dropped frames barely matter at 5 fps — one lost frame widens the bracket by 0.2 s, or 0.01 °C — but timestamp logging makes gaps visible, so log them anyway. One mechanical trap remains: mount the camera to the frame, not the oven shell. A 200 °C oven grows thermally, the 2.9 m stand-off multiplies that growth, and a grid that walks between cycles defeats the gating. Re-find the grid origin at the start of every cycle and the mount only needs to be stiff, not thermally stable.

What should you check before you order?

Run one full ramp with real disks and log everything: the creep noise floor, the snap jump and the frame-to-frame intensity spread fix every threshold and confirm the parts list in a single hour. Order against measurements, not estimates.

• Logged creep centroid deltas at or under 0.1 px per frame — this sets the movement threshold at 1 px with margin.
• At least 25 pixels across the smallest disk, checked in the corners, not the centre.
• Bracket error = ramp rate ÷ frame rate at or under 0.05 °C; at 0.049 °C/s and 5 fps you get 0.01 °C.
• Frame-to-frame intensity spread under 1 percent over 200 frames, or fix the light drive first.
• Every temperature sensor calibrated in situ against a reference near 200 °C.
• The over-temperature cutout proven to work with the PC switched off.

If your array, disk size or ramp differs from the example, put your own numbers through the configurator or ask the applications team — the thresholds move with the pixels-per-disk ratio, and that ratio is the first thing to recompute.