Start an inspection automatically from a custom program

You built the inspection in a configurable vision engine, it passes parts on the bench, and now the line wants it unattended. Your PLC, robot program or cell code has to start the inspection, trigger each part, collect the pass or fail result and stop the engine cleanly at the end of a shift - no operator, no start button. Every mainstream configurable engine ships an automation interface for exactly this, together with a startup option that drops the software straight into inspection mode at launch. This guide gives the decision between the three control routes, the connect, load, trigger and read sequence with starting timeout values, the startup settings for unattended cells, a worked example that sizes a controller's LAN ports for a four-camera cell, and the checks that keep the handshake alive through a full shift.

Choose the route: automation API, discrete I/O or run-on-launch

Three routes drive an inspection from outside the engine, and most cells combine two of them.

The decision falls out of who asks for the result. If your program is a PLC and one pass bit per part is enough, wire it and skip the code. If your program needs the numbers - measurements, per-check states, recipe switches at changeover - use the API, locally if it runs on the same controller as the engine, over the cell network if the engine lives on a vision controller elsewhere in the cell. Then add run-on-launch underneath either route, because the boot sequence is not your program's job. Where the inspection can decide on the camera itself, a smart camera exposes the same run, trigger and result control with no pixel traffic at all.

The rest of the systems topic page collects the timing and handshake guides that this article builds on.

What you need before you write code

• The engine with its automation examples. Engines that expose an API install example projects alongside the software, normally in a folder named for the interface, in COM/ActiveX, .NET or C/C++ form. Open the example closest to your language first; it already answers the connect, load and read questions.
• A host sized on ports, not enthusiasm. Count camera links, one link to your network, one to the PLC, and spare I/O or PoE where the wiring needs it.
• The recipe at its final path, with the result outputs named exactly as your code will read them.
• A wire plan if a PLC is in the loop: trigger, busy, result-ready, pass, fail and a spare acknowledge conductor.

Budget a two-camera cell like this. Two camera ports, one link to the cell network, one to the PLC, with light channels to match the illumination you already chose.

The MV-VC3301H-128G66 pairs an Intel Core i3 with 8 GB RAM and a 128 GB SSD, and lists 5+ LAN ports, 4 built-in light channels and no PoE camera ports; the VM6200Pro license is included.

The other placement decision is where the inspection itself runs. On the controller, pixels stream and the port arithmetic in the worked example below applies. On the camera, the engine lives on the camera and only results leave it:

The LS-SMC-0063 inspects on the camera at 1.6 MP and 60 fps with a 16 mm lens over GigE. The MV-SC5060XM-08M-WBN does the same job on the device at 6 MP with an 8 mm focal length in an M12 mount. Whichever placement you pick, the code in the rest of this guide drives the inspection the same way.

Prepare the inspection for remote control

1. Save the recipe at its final path and note the exact name. The API loads that string, character for character; a rename on the bench breaks the cell later.
2. Name the outputs your program needs - overall pass, per-check states, measurements - so they come back under fixed names in a fixed order.
3. Decide who fires each shot. A self-triggered engine inspects continuously; a per-part cell fires one shot per part. Set the camera's acquisition mode to match, because a free-run default silently swallows external triggers - the setup is covered in hardware trigger configuration per camera, and the continuous case in continuous acquisition mode for live loops.
4. Switch on the engine's remote or automation access in its options, so the engine listens for your program while it runs.
5. If the line runs more than one product, plan recipe changes through the same interface. The switching pattern built around operator buttons in local vision recipe switching transfers directly - your program presses the button.

Turn on start-when-launched for unattended cells

Configurable engines carry a startup setting that skips the editor entirely. The dialog names differ; the sequence does not:

1. Open the engine's options dialog and find the startup group.
2. Enable the option that runs the inspection when the software launches.
3. Select the recipe the engine should load straight into inspection mode.
4. Restart the engine and confirm it comes up running, with the chosen recipe active.

Then prove it survives a power cycle, because the cell will see one. Switch the host off at the mains, wait ten seconds, switch on, and confirm the engine is already inspecting before anyone touches a keyboard. On a Windows host, give your own launcher the same treatment - a startup task or a service - so the engine and your code come back together; the way these fail quietly is exactly the subject of a service that will not start automatically on Windows.

Run, monitor and stop the inspection from your code

The API sequence is identical across engines; only the method names differ. Connect, load, run, trigger, read, stop:

1. Create the engine object and connect by IP address - or locally, if your code runs on the same controller. Set a 3 s connect timeout so an absent host fails fast instead of hanging the line.
2. Load the recipe by its saved path and check the return value. A name that almost matches is the most common first-run failure.
3. Put the engine into inspection mode. With run-on-launch already set, the inspection is running and your code attaches to it instead of starting it.
4. Trigger one part, through the API call or the input wire, and wait for the state to change from running to result-ready. Poll the state every 20 ms: faster burns processor time for nothing, slower adds its own delay to every part.
5. Read the results in that same poll - overall pass first, then the named outputs - and copy them out before the next trigger, because the next trigger overwrites them.
6. Treat any exception as a stop and reconnect. Wrap connect, load and start in one routine, retry with a 3 s then 10 s back-off, and reload the recipe on each retry; a mid-shift engine restart then heals itself.

The same pattern as illustrative pseudocode:

// Illustrative names - your engine's automation examples carry the real ones
string recipePath    = "C:/recipes/bracket_check.recipe";
int    resultTimeout = 1500;               // 3 x the measured 500 ms cycle
bool   passed        = false;

engine.Connect("192.168.10.20", 3000);   // ms; fails fast if the host is down
engine.LoadRecipe(recipePath);
engine.StartInspection();                // redundant when run-on-launch is set

for each part:
    engine.Trigger();
    wait for engine.State == "ResultReady" within resultTimeout;
    passed = engine.GetResult("OverallPass");  // the name set during preparation
    route the part by passed;

engine.StopInspection();
engine.Disconnect();

The test that proves the result: close the editor, fire 100 parts, and log each trigger timestamp against each result timestamp. One hundred results, none later than the timeout, means the interface and the budget both hold. Results that drift past the budget point at the engine rather than the wire - acquisition faster than processing is the sequence for that diagnosis. These starting values are tuned once from that log, not guessed twice.

Worked example: four 6 MP cameras streaming into one controller at 15 fps

The inputs, with their sources:

• Pixels: 6 MP per image - the class of the MV-SC5060XM-08M-WBN, a 6 MP mono GigE camera with an 8 mm lens in an M12 mount.
• 1 byte per pixel - the 8-bit mono format, the streaming baseline for this kind of cell.
• 15 frames per second per camera - the conveyor demand this case is sized to.
• 1,000 Mbit/s raw per GigE port = 125 MB/s, about 950 Mbit/s ≈ 118 MB/s usable - the GigE link rate; the usable figure is the normal streaming budget after protocol overhead.

The rule in words: pixels times bytes per pixel times frames per second gives the megabytes per second per camera; divide the total stream by the usable link rate and round up for the port count.

The arithmetic:

per camera:   6,000,000 px × 1 B × 15 fps = 90 MB/s
one port:     950 Mbit/s ÷ 8              ≈ 118 MB/s usable
headroom:     118 − 90 = 28 MB/s          ≈ 24% spare
ceiling:      118 ÷ 6 MB                  ≈ 19.7 fps → just under 20 fps for one 6 MP 8-bit camera
four cameras: 4 × 90 MB/s = 360 MB/s      → ceil(360 ÷ 118) = 4 ports
two per port: 180 MB/s on a 118 MB/s port → over the link limit

The result: one 6 MP 8-bit camera fits one GigE port up to just under 20 fps, and at 15 fps the port runs at 76% with a quarter of the link in reserve for overhead spikes. Four streaming cameras therefore need four ports, one camera each, plus a fifth link for your program and the PLC.

The decision: budget one GigE port per streaming 6 MP camera at 8 bit up to about 19 fps; above that rate, or once the ports run out, move the inspection onto the camera so only results cross the network. The port count above is a printed line, not a corner case:

The MV-VC5525-256G70-NN pairs a 12th-gen Intel Core i5 with 32 GB RAM and a 256 GB SSD, and lists 5+ LAN ports, PoE camera ports and 8 built-in light channels.

One camera per port leaves the fifth link free for your code, and PoE on the camera ports removes the power supplies along the way.

When a PLC runs the line: the discrete I/O handshake

Wires sometimes beat code. The PLC already sequences the cell and wants one bit per part, and the standard signal set fits on six conductors: trigger in, busy out, result-ready out, pass out, fail out, and a common ground. Three timing rules hold across engines:

• Trigger pulse 10-20 ms. The pulse must outlast the PLC input filter, which is typically a few milliseconds; 10 ms is a safe floor, 20 ms on a slow input.
• Latch before the next part. Wire result-ready into the PLC and read pass/fail in the same scan, or hold the outputs until an acknowledge input - an unread result is an overwritten result.
• Treat busy as ignore, not error. A trigger that lands during exposure is dropped by most engines rather than queued.

The restart and ordering failures around this handshake are already worked through in the vision start/stop handshake guide and the picking restart case; both apply unchanged when your program, not an operator, arms the engine.

Common mistakes, and the fix for each

• The code hangs on connect. Remote access is off, the IP sits on another subnet, or a firewall blocks the port. Prove the engine runs by opening it on the host first, then connect locally from that host, then from your program across the network - the failing step names the broken layer.
• The recipe loads but nothing inspects. The engine is still in configuration mode, or the name differs by one character from the saved file. Load, start, trigger: all three, in that order.
• Results arrive late or skip parts. Your code reads after the next trigger has overwritten the buffer. Copy the results out in the poll that saw result-ready, before triggering again.
• It works until the engine restarts mid-shift. Nothing re-connects. Call the connect, load and start routine from the exception handler with the 3 s then 10 s back-off.
• The cell comes up in the editor after a reboot. Run-on-launch is unset, set for the wrong recipe, or your launcher never ran. Re-test with a power cycle, not a window close.

Checklist before you go live

• Recipe at its final path, loadable by name from a fresh connect - the API loads strings, not intentions.
• Run-on-launch proven with a real power cycle - a window close skips the login and service start that a reboot exercises.
• 100-part trigger/result log inside the timeout - proves the budget with the editor closed, the way the cell runs.
• 20 ms poll and a 3x-cycle result timeout configured - the starting values from the code section, tuned once from the log.
• PLC latch proven on back-to-back parts - two triggers 200 ms apart must yield two latched results, not one.
• Maintenance path to the editor - an engineering-login shortcut, so run-on-launch never has to be switched off on the line.

Size the parts before the code: the smart camera finder filters by resolution, shutter, mount and interface, and the build configurator walks the chain from camera to controller. Orders include free expert support, so for the questions the catalog pages do not answer - engine versions, interface options, integration - ask through the contact page.