Vision inspection deployment workflow: keep it editable or freeze it

An inspection built in a configurable vision environment reaches a fork at commissioning. You can drive it from your own application through the engine's API, or export it as generated code. The two paths look equivalent on a bench and diverge on the line, the first time a threshold, ROI or tolerance needs tuning. This guide gives the decision rule, works the numbers that decide where the inspection physically runs, and lists the checks to make before you commit either way.

The decision rule: will the inspection change after deployment?

Answer one question: after sign-off, will anyone tune the inspection? During ramp-up the answer is almost always yes, so keep the inspection in its runtime engine and let your application drive that engine through its API. Export code only when the inspection is genuinely final and everyone accepts a regeneration cycle for every future change.

The reason is mechanical, not stylistic. Generated code implements the inspection as it existed at the moment of export; the link back to the editable file is cut. Editing a threshold in the original inspection does nothing to the compiled application running on the controller. The API link keeps the editable file as the live artifact, and your application becomes a client of it.

That choice is separate from the tools inside the inspection. For that axis, see AI vs rule-based smart camera inspection: how to choose.

How the two architectures work

The runtime engine link

The inspection lives as a file that the engine loads. Your application asks the engine to open that inspection, arm the trigger, run each cycle and hand back named results: coordinates, scores, a verdict. The engine executes the same tools you tuned in the editor, on the machine that runs production. Your application never opens the camera and never reimplements a tool; it owns the operator screen, the PLC handshake and the logging around the engine.

The code export

The environment translates the inspection into source that you build into an application. The build may still call a licensed image-processing library, but the editable inspection disappears: thresholds, ROIs and tool settings become values in source. From the first build onwards the code is the product, and every inspection change is a code change.

What a change costs under each architecture

Take a concrete case. A new lot of parts reflects differently and one segmentation threshold must move from 90 to 110 grey levels — a ten-minute edit in the editor. Under the engine link, you open the inspection, change the threshold, save, and the application loads the file again before the next shift: no build, no redeploy. Under export, the same edit touches source. You regenerate the inspection code, rebuild the application, redeploy it to the controller and repeat whatever validation you ran at sign-off. Each change repeats that cycle, and the deployed build drifts further from the editable master you tuned against golden parts.

Worked example: what fits down the wire from a 5 MP sensor

The architecture choice also has a physical half: where the inspection runs decides what the network must carry. Full frames are heavy; results are not.

The inputs, and where each comes from:

• Resolution: 5,000,000 pixels at 8 bits per pixel, mono — the common 5 MP 8-bit case, which sets the frame size used below.
• Link rates: 100 Mbit/s for Fast Ethernet, 1,000 Mbit/s for GigE — the Ethernet standards behind those two interface names.
• Planning overhead: about 90% of the nominal rate treated as usable — the usual allowance for protocol headers, inter-frame gaps and scheduling.

The rule, in words: bytes per frame equals pixels times bytes per pixel, and the frames per second a link can carry equals its usable bytes per second divided by bytes per frame.

The arithmetic:

• One frame: 5,000,000 px × 1 B = 5.0 MB.
• Fast Ethernet: 100 Mbit/s ÷ 8 = 12.5 MB/s; at 90% usable that is 11.25 MB/s, and 11.25 ÷ 5.0 ≈ 2 fps of full frames.
• Results instead: a verdict with X-Y coordinates and a score fits in about 100 B. At 100 parts/s that is 100 × 100 B = 10 kB/s, which is 0.09% of the 11.25 MB/s usable rate.
• The same frames over GigE: 1,000 Mbit/s ÷ 8 = 125 MB/s; at 90% that is 112.5 MB/s, and 112.5 ÷ 5.0 ≈ 22 fps.

The result: a Fast Ethernet link carries results, not images, from a 5 MP sensor — full-frame streaming tops out near 2 fps. Over GigE the same frames move at roughly 22 fps, which covers the pace of a single-camera inspection loop.

The decision, with its threshold: multiply inspection rate by frame size and hold it under 90% of the link's nominal rate. Below that line, full frames can reach a runtime engine on a controller and the inspection stays editable there. Above it, run the tools on the device and ship results — which is precisely what a Fast Ethernet vision sensor does. The MV-SC3050XC-16M-ATN-H is that class of device: a 5 MP colour sensor that inspects on board and reports over Fast Ethernet.

What the engine link makes routine

Because the inspection file stays live, jobs that otherwise become rebuilds stay small:

• Your interface, a headless engine. The operator screen, alarms and logging are your code; the engine stays invisible. Live tuning follows the same split — runtime camera parameter control: exposure and white balance live shows parameters changing without stopping the pipeline.
• Recipe switching. A product change is a different inspection file. One proven pattern hands the recipe from the PLC as a serial command code, as in RS232 vision recipe selection: one command code per recipe.
• Results into the plant. The engine publishes named results your control system reads directly; read smart camera results over OPC UA into your control system maps engine items to PLC tags.
• Second-tool access. To inspect camera parameters while the engine owns the device, expose the tree over the network instead of opening the camera twice: access a camera parameter tree over TCP from a second app.
• Rate matching. When acquisition outruns processing, the fix is scheduling between engine and application, not new tools; acquisition faster than processing: fix the frame rate gap walks that diagnosis.

When exported code is the right answer

Export in three cases: the inspection is validated and stable; the target hardware cannot host the engine, such as a compact embedded board; or you are handing the line to a software team that will own the code permanently. In all three, export once, after golden-part validation, and archive the editable master beside the build. Then treat the export as production code rather than a formality: generated source deserves the same review as hand-written code, and the review-and-verify checklist for AI-generated embedded code transfers directly to vision exports.

What export never buys is freedom from change. If the process later shifts — new supplier, new surface finish, new tolerance — the regeneration cycle from the previous section is the price, every time.

Choosing the hardware that hosts each path

The two families divide cleanly, and the catalog reflects it.

On-device inspection lives in smart cameras and vision sensors. The tools run on the camera's processor and the plant network carries results, so deployment reduces to copying the tuned inspection file to the device. Check the device's tool library before you commit: the on-board tools are fixed at purchase. Where a vision sensor runs out of resolution or tool depth, a smart camera keeps the same architecture on stronger hardware — the camera finder filters by resolution, interface and shutter. The MV-SC5060XM-08M-WBN, a 6 MP mono GigE model in the SC5000X series, is that step up with the inspection still on board.

Engine on a controller fits multi-camera cells, heavy tool chains and shared illumination, and the vision controllers category lists them by LAN ports, PoE and memory. The controller's job is ports and headroom: the MV-VC3301H-128G66 hosts the engine with 5+ LAN ports, 4 built-in light channels, 8 GB memory and an Intel Core i3, with the vision software licence included, and its lighting channels drive the lights directly from the panel.

Cells that need PoE cameras or more channels step up: the MV-VC5525-256G70-NN adds PoE camera ports and 8 built-in light channels with 32 GB memory, while the compact MV-VC2140-128G40-1T covers 3-4 LAN ports on an Intel N-series processor.

Checks before you commit

• Four API verbs. Confirm the engine API covers open, run, results and inspection reload — the whole link is those four calls plus your interface code.
• Licence shape. Confirm which licence the engine needs at runtime and whether the controller bundles it.
• Link budget. Multiply inspection rate by frame size; hold it under 90% of nominal link rate, per the worked example.
• Results contract. Agree the protocol, the item names and the timestamp handling with the controls team before wiring.
• Master custody. Version-control the inspection file and record which file revision produced each exported build.

The decision, per case

• Tuning expected after sign-off, the common case: runtime engine link, with your application as its client.
• Inspection frozen, embedded target, or permanent code handover: export once, review the code, archive the master.
• Part rate times frame size above 90% of the link: on-device inspection in a smart camera or vision sensor, results over the network.
• Several cameras, heavy tool chain, built-in light control: engine on a vision controller.

For the surrounding integration patterns, the systems topic page gathers them. And if the decision is genuinely 50/50, talk it through with us: bring the part rate and the frame size, and the arithmetic above usually settles it.