Vision recipe changeover with parameter files

Production lines that run several similar products rarely differ enough to need separate vision programs, but they always differ enough to need separate settings. Re-editing and redeploying inspection code at every changeover turns a five-minute product switch into an afternoon of risk and paperwork. The fix is structural: store each product's regions of interest, tool parameters, acceptance limits, camera settings and reference images in its own recipe file, and make the running program a reader of files rather than a container of typed-in constants. This guide walks through what goes into the file, how to lay recipes out on a controller, the changeover sequence that survives an audit, verification, and the storage sizing.

What goes into a recipe file for one product?

A recipe file carries every setting that differs between products: the regions of interest, the parameters behind each tool, the acceptance limits, the camera exposure and gain, the light channel settings, and the reference images the tools match against.

A good test for any value you are unsure about: if setting the station up for this part from scratch would change it, the value belongs in the recipe. The OPC UA for Machine Vision companion specification, part 1 (spec number OPC 40100), describes the idea the same way: a recipe as the stored properties, procedures and parameters that describe the vision task.

One schema serves every product, and the loader never special-cases an ID. The key names below are illustrative — they follow no vendor schema; the values are worked numbers for a 10 mm bored part. What matters is the discipline: nothing product-specific stays in the compiled code.

{
  "recipe_id": "BRK-4721",
  "schema_version": 3,
  "camera": { "exposure_us": 2400, "gain_db": 6.0 },
  "light": { "ring_channel_percent": 65 },
  "alignment": { "min_score": 0.85, "expected_angle_deg": 0.0 },
  "checks": [
    { "name": "bore_diameter", "roi": [612, 480, 200, 200], "limit_mm": [9.95, 10.05] }
  ],
  "reference_images": ["golden_part.bmp", "alignment_master.bmp"]
}

Every value the inspection loop reads — the 2400 µs exposure, the 0.85 match floor, the 9.95 to 10.05 mm diameter window — comes from this file, so a new bore diameter is a new number in a new file, released and reviewed like any drawing change. The changeover sequence below is the test that proves a file actually drives the tools.

How do you switch products without touching the vision code?

You load the file the plant already owns for that product: the PLC sends a recipe ID, the vision program resolves it to a parameter file on disk, applies it to the running tools, and answers with the active recipe ID before the first part moves.

The program itself is one interpreter. It knows the schema, accepts any file that validates against it, and pushes the values into parameterised tools at load time. Because no product name, no limit and no ROI is compiled in, adding a product becomes adding a folder and one manifest row — the build and release process never enters a changeover.

Split the two roles at the file level. Operators select and load from a validated list; engineers create and edit. The operator-button switching pattern shows the selection side done properly, with the station confirming the active recipe before the cycle starts. For the trigger itself, send one unique code per product over the link the line already has; the RS232 recipe-selection handshake works the same way over serial as over TCP.

The same pattern runs without a PC on smart cameras: the camera holds its parameter sets on board and switches between them from its own inputs, which covers single-station checks such as presence, code reading and simple dimension work.

Which settings change per product and which stay shared?

Everything the part's geometry or surface drives belongs to the product: ROIs, match scores, tolerances, exposure and light levels — while everything the station's hardware fixes, from camera to calibration to I/O timing, is loaded once at boot and shared.

Calibration stays global because it describes the station, not the part. If a new product needs different optics or a different working distance, that is a mechanical change with a recalibration, not a recipe entry. Exposure and white balance, by contrast, can be pushed to the camera live at load time — the runtime camera parameter control approach applies unchanged here.

The reference coordinate system that anchors your relative ROIs is what makes per-product offsets transfer cleanly between products. For match scores, work in a 0.7 to 0.9 band: below 0.7 a match stops telling parts apart, above 0.9 it starts rejecting acceptable surface variation. If a freshly taught master produces hits that flip 180 degrees, the tolerance and score fixes are the first place to look.

How should recipe folders be organised on the controller?

One folder per product revision, named with the part number your ERP already uses, plus a manifest that records each file's checksum and schema version, keeps every changeover auditable and makes rollback a folder copy.

C:\Vision\recipes\
  manifest.csv                     recipe_id, revision, checksum, schema_version
  BRK-4721_rev4\recipe.json
  BRK-4721_rev4\golden_part.bmp
  BRK-4721_rev4\alignment_master.bmp
  GSK-0812_rev1\recipe.json

The exact path matters less than the shape. Put a checksum for every file into the manifest and make the loader verify it before applying anything — the checksum catches the classic copying mistake, recipe content from one product under another product's folder name, before it reaches the tools.

Keep paths inside recipe.json relative to the recipe folder. Absolute paths baked in at teaching time break at the first redeployment; the model file path fixes describe the same failure for trained AI models, which belong in the recipe folder too.

Keep the last two or three revisions per product on the controller. Rolling back a bad limit change is then a folder copy, not a support call.

What does a safe changeover sequence look like, step by step?

The sequence that survives an audit is: receive the ID, validate the file, apply camera and light settings, load tools and limits, then prove it with a known-good and a known-bad part before the PLC releases product.

1. Receive the ID. The PLC or operator panel sends the recipe code; the vision system echoes it back before anything else happens.
2. Resolve, never default. Look the ID up in the manifest. An unknown ID raises a fault; it never falls back to whichever recipe loaded last.
3. Validate the file. Schema version matches the loader, every required key is present, and each checksum equals the manifest value.
4. Apply camera and light settings. Push exposure and gain to the camera, set the light channels, and let the output settle before the first capture.
5. Load tools and limits. Build the ROIs from the alignment reference, then load tool parameters, acceptance windows and reference images.
6. Read back and compare. Echo the applied exposure, gain and score floors; any value that differs from the file is a fault.
7. Prove it with parts. The golden part must pass and the known-bad part must fail; both captures are saved with the changeover record.
8. Signal ready. Report the active recipe ID to the PLC and log who changed what, when, and from which revision to which.

How much controller storage do a few hundred recipes need?

Plan on roughly 20 MB per recipe for a 5 MP station that keeps four reference masters, so 150 products fit in about 2.9 GB — around two percent of the 128 GB SSD in an entry vision controller.

Worked example, assuming a 5 MP mono station with 2592 × 1944 pixel, 8-bit masters:

• one master: 2592 × 1944 × 1 B = 5,038,848 B ≈ 4.8 MB
• four masters per recipe (golden part, alignment master, two defect samples): 4 × 4.8 MB ≈ 19.2 MB, plus a few kB of parameters
• 150 products: 150 × 19.2 MB = 2,880 MB ≈ 2.9 GB

Uncompressed 8-bit is the ceiling: lossless compression and cropped masters pull the number down, and 16-bit masters double it. Any of the shop's vision controllers holds a library of this size comfortably — storage never becomes the deciding factor, verification discipline does. For the hardware, the MV-VC2140-128G40-1T pairs 8 GB of RAM with a 128 GB SSD and a 1 TB HDD for the image archive.

Higher-mix lines change the port count, not the storage maths. The MV-VC3301H-128G66 exposes 5+ LAN ports and includes a VM6200Pro license, while the MV-SVC2506-16G60-128G separates 4 camera GigE ports from 1 configuration port and 1 communication port for lines that keep engineering traffic off the camera network.

How do you prove a recipe loaded correctly before running parts?

Two captures decide it: the golden part for this recipe must pass, a known-bad part must fail, and the values the tools report after loading must equal the file's numbers to the last decimal.

Order the proof as three checks. First the loader's read-back: compare the applied exposure, gain, light percent and score floors with the file, field by field; a mismatch is a fault, not a warning to click away. Second the checksum, already verified at load. Third the physical golden-part run, which catches what software cannot — a stale master image, a drifted fixture, a light that settled differently.

Tag every result record and archived image with the recipe ID and revision. When a customer question arrives months later, the record proves which limits judged the part; pushing NG images to the HMI or a server only pays off if the images carry that tag. Close the changeover with a first-article sign-off from a second person, both verification captures attached.

When is a recipe file the wrong answer?

Recipes swap parameter values, not logic: if a new product needs a different tool chain, a new lighting geometry or different optics, it is an engineering release, and forcing it into a recipe file is how stations drift into unmaintained exceptions.

Watch for these cases:

• A new inspection principle — a texture check where none existed, a second camera — is a code release with its own schema version, not a parameter edit. Forcing it into the file grows product-specific branches in the loader, and you are back to compiled constants with extra steps.
• Different optics are a mechanical change. If the part needs another lens or working distance, the station changes and recalibrates; recipes assume the station's geometry is fixed.
• Mixed-model flow with a readable ID on each part needs no changeover at all: read the part ID and select the recipe per part.
• Where the robot, feeder and vision each hold their own product data, give one owner the master ID and let it distribute the rest — the ownership faults that surface at changeover come from exactly this split.

A library built this way turns a product switch into a file operation and a five-minute verification. If you are sizing a controller for your own recipe library, start from the storage example above, count the camera ports your plan needs, and let the system configurator match cameras, lenses and lights to it. More inspection write-ups sit under the applications topic, and if your changeover resists the pattern, tell us about the line and we will work through it with you.