Set your vision sensor to auto load its job on startup

A vision sensor that only runs after someone loads its program from a laptop is not deployed — it is being remote-controlled. The complaint always sounds the same: the inspection works while the PC software is connected, power cycles between shifts, and the next morning the sensor sits idle until the job is pushed again. The fix is two device settings, not code. Store the job in the sensor's own memory as a named slot, then mark that slot as the job that loads on startup. This guide walks through the deployment, the power-cycle test that proves it worked, and the mistakes that keep sensors tethered to a PC.

Loaded is not stored: where the job actually lives

Running a job from the PC exercises the sensor's working memory. The job belongs to that editing session and to the connection; remove power and working memory clears, so the sensor boots with nothing to run. Deployment — your vendor's word may be deploy, send, download or write to device — copies the finished job into the sensor's non-volatile memory as a named job slot. A slot survives every power cycle. The second half is selection: the sensor's job list carries a setting for which slot loads at boot. Skip the deployment and there is nothing to load; skip the selection and the sensor loads nothing. Both actions take seconds, and neither involves writing code.

For how that on-device storage behaves across edits and offline work, smart camera program storage and offline editing explained goes deeper.

What you need

• The sensor on your network, reachable from the PC that runs the vendor software
• The current version of the inspection job, already tested on live images
• Known-good and known-bad parts for the final check
• A fixed IP address to assign, or access to the DHCP server to reserve one
• Trigger wiring planned end to end: which photoelectric sensor or PLC output fires the camera, and which result output the machine reads

Budget 15 minutes for a first deployment and the same again for the power-cycle test.

Deploy the job and select the startup job

1. Connect and open the job. Put the sensor on the same network segment as your PC, open it in the vendor software and load the working version of the inspection job. Note the sensor's IP address now; step 7 makes it permanent.
2. Finish tuning first. Run the job on live images and confirm a known-good part passes and a known-bad part fails, with the result output behaving as the machine expects. Focus, exposure and thresholds must be final before the next step, because deployment snapshots the job exactly as it stands.
3. Write the job to the sensor. Run the deploy or write-to-device action. The software stores the job in the sensor's internal memory as a named slot. Note the slot name; you need it in step 5.
4. Confirm the slot exists on the device. Open the sensor's job list and check that the new slot appears with today's changes. If the list still shows only old jobs, the write failed quietly — repeat step 3 and watch for the success message.
5. Set the startup job. In the same job list, mark the new slot as the job that loads on startup. Exactly one slot carries the mark. A sensor pointed at an empty or obsolete slot boots idle, which is precisely the behavior you are fixing.
6. Save the device settings. On many sensors the startup selection, network address and I/O configuration persist only after a separate save or user-set action. If your device works that way, follow the pattern set out in save camera parameters as a user set that loads on startup and save camera settings across power cycles with a user set.
7. Fix the address. Assign a static IP address or reserve the sensor's address on the DHCP server. PLC code and result readers connect to an address, and a sensor that appears at a new address after every boot reads as offline even though its job ran perfectly.
8. Disconnect and power-cycle. Close the software, drop the PC from the sensor's network and cut power to the sensor. What happens next is the test.

Prove it runs headless

A deployment is proven with the PC out of the loop, not with the software merely minimised.

• Cold-start the sensor with the PC software closed. The ready output should come up on its own, with no connection requested.
• Present a part. The result output must fire on the trigger alone — no editor open, no SDK running.
• Read the key settings back after boot. Exposure, gain and frame rate should match what you deployed; the readback habit is set out in camera startup frame rate: verify saved settings and readback.
• Watch the first seconds of production. If good parts reject while the image settles, gate the line on the sensor's ready output — smart camera misses first images after load: fix the ready gate explains the gate.

If all four pass, the sensor no longer needs a PC to do its job. Export the job file to a shared drive the same day; when a sensor fails in a year, a saved job file turns recovery into a load-and-deploy instead of a rebuild.

Six mistakes that keep a sensor PC-dependent

1. Saving in the editor only. The session lives on the PC's disk and in working memory. Until the write-to-device action runs, the sensor has nothing.
2. Deploying before the last tuning pass. Exposure and focus changes made after the deployment never reach the device. Treat deployment as the final step of every job change, not a setup step.
3. Assuming the startup mark follows the redeploy. On some devices, overwriting a slot leaves the startup selection pointing where it was. Re-check the selection after each deployment.
4. Pushing the job from the SDK at boot. It works until the PC that pushes it is down, rebooting or hung, and then the line waits on a laptop. Deployment removes that dependency; let the SDK handle results and job switching instead.
5. Trusting DHCP alone. A new lease after a power cycle changes the sensor's address and breaks the PLC connection. Static or reserved, always.
6. Updating firmware without an export. On some models a firmware update clears user jobs. Export the job file first, redeploy after the update and repeat the cold-start test.

Give the SDK the right job

Once the job is deployed, the sensor runs standalone and the integration question changes shape. The PLC reads results, not programs: digital outputs for pass and fail, or the sensor's documented field and command interface for richer data. For changeovers, switch between deployed slots from the PLC through the inputs or commands the manual documents — the jobs already sit on the sensor, so a switch is instant. If the consumer of those results is a custom program, the patterns in start an inspection automatically from a custom program apply unchanged. What you should not build is a PC whose only task is loading the job at boot: that re-creates the failure this guide fixes, with more moving parts.

What the reload ritual costs: a worked example

The manual reload feels free because it is only a few minutes. Summed over a line's life it is not. Take example inputs — 5 minutes per reload, one power-down per production day, 250 production days a year, one sensor:

Substitute your own minutes and days. The deploy-once pattern drives the recurring part to zero, because the sensor loads its own slot at boot in seconds; what remains is genuine hardware failure, and the pre-deployed spare above turns that into a swap. At 83 hours a year across a small cell, deployment stops being a nicety and becomes maintenance policy.

Hardware that runs inspection on board

The pattern only applies to hardware that executes the inspection itself, which is exactly what the smart cameras and vision sensors category is for: inspection on the device, no PC. Filter the camera finder by interface, resolution and lens mount when you need a specific fit. Each of the following runs its program on board:

Fixed-lens models suit compact single-part stations; when the part needs a chosen lens or more pixels, step up to the M12-mount and higher-resolution models in the finder. Where one sensor is not enough — several cameras, PLC handshaking, light control — the same idea moves up a level to a vision controller. The application lives on the controller, so set the project it opens at boot in that software's startup settings and the whole cell returns on its own after a power cut. The MV-VC2140-128G40-1T fits a compact cell: an Intel N-series processor, 8 GB of memory and 4 built-in light channels for the illumination side.

Checklist: before you leave the sensor alone

• Job slot on the device — the write-to-device action succeeded and the slot appears in the sensor's own job list; the editor's save is not proof.
• Startup selection — the slot is marked as the startup job, re-checked after the final redeploy.
• Settings persisted — device settings saved or user set written; exposure and frame rate read back correctly after a cold boot.
• Address stable — static or DHCP-reserved address; PLC result connection tested with the PC absent.
• I/O exercised — trigger in, result out, with no software running anywhere.
• Recovery ready — exported job file on a shared drive and, for critical lines, a spare sensor deployed and shelved.

Deploy once, mark the slot, cut the PC loose — that is the whole change. If you are still selecting hardware, the configurator walks camera, lens and lighting choices in order, free expert support comes with every order, and contact us reaches the applications team when a job refuses to stick.