Auto-start your vision system at robot controller boot

At 02:00 the plant drops power; at 05:00 it comes back. The robot controller boots, auto-loads its program and asks the vision system for the first inspection result. Nothing answers, because the vision software only ever started when someone logged in and launched it by hand. The cell faults before an operator has reached the door.

This guide is for integrators and cell owners who want that sequence to run itself: the robot program at power-up, the vision hardware and application on their own schedule, and a handshake that bridges the two boot clocks. You will leave with a startup order, a ready signal, and a boot-time budget with real numbers behind it.

The decision: three pieces, not one setting

No single checkbox makes a vision system auto start on robot boot. The robot controller, the vision hardware and the vision application each wake on their own clock, and the cell only behaves when all three come up in a defined order. Build the startup as three pieces:

1. The robot runs at power-up. Enable the controller's automatic-run settings and select the program that must load.
2. The vision side launches itself. On a vision controller that means BIOS, logon and an application launcher; in a smart camera the job reloads from the device itself.
3. The robot waits for vision before its first acquisition. The vision clock usually runs tens of seconds behind the robot clock, and a ready signal covers the gap.

Skip the third piece and you have automated a fault: the program starts, asks for a result and faults before anyone reaches the cell. The steps below set each piece, then measure the gap so the handshake stands on a number.

Everything here covers the boot path. Calling inspections from your own code once the cycle is running is a different flow — Start an inspection automatically from a custom program is that subject.

What you need

• A robot controller with automatic-run settings — vendors call them autoload, auto start or auto initialize — and permission to change them.
• A vision host: a vision controller or a smart camera that stores its job on the device.
• The vision application's saved configuration set, stored where the launcher finds it at startup.
• Switch access and fixed IP addresses for the cameras.
• A handshake path to the robot or PLC: a spare I/O line or the Ethernet link you already have.

Step 1: make the robot run its program at power-up

Controllers ship with automatic run disabled, which is correct during commissioning. For a production cell, enable the automatic-run group and select the program to load. With those settings on, the controller runs the loaded program as soon as it powers up, provided the required start input is asserted. In most cells the PLC asserts that input once the safety circuit reports healthy, so power-up, guard check and program start stay in that order.

If your controller boots to the wrong program or sits on a program-selection screen at power-up, the knowledgebase page on fixing program search at robot controller boot walks the controller side of that fault. When the start command comes from the PLC over a fieldbus instead, auto-starting the robot through the PLC handshake shows the signal sequence from the PLC's side.

Step 2: bring the vision hardware up on its own

The smart camera path

A vision sensor keeps its job and camera settings inside the device, so the boot chain is one link shorter: power returns, the sensor boots, the job reloads, the sensor waits for a trigger. Verify the auto-load setting and that the stored job is the current one — Set your vision sensor to auto load its job on startup covers that setting and its traps. Feed the camera from a circuit that comes up with the cell, not from a desk socket someone switches off at night.

For single-camera inspections, a sensor in this class runs the whole inspection on the device:

The vision controller path

A PC-based host has three stages, each with a setting people miss:

1. Power-on. In BIOS setup at power-on self-test, set the power-management option that brings the board up when mains returns to power on. Left on stay-off, the cell waits for a human with a keyboard.
2. Logon. Configure automatic logon with a restricted account; the session exists so the vision software has somewhere to run.
3. Launch. Start the vision application from the OS task scheduler with an at-logon trigger, or run it as a service if the SDK supports headless operation.

A headless host needs LAN ports for the camera fleet, storage for logs and images, and a processor class that keeps boot short:

The bigger hard disk in one exists for image logging; the other comes with the vision software license included. Configure the same three stages on either.

Step 3: launch the vision application in the right order

The launcher starts the program; the program then brings the cameras up in an order that survives a cold start. Open each camera by a stable identifier, apply the saved configuration set, and set exposure before starting the stream — Set manual exposure before streaming: initialization order shows what a stream started too early locks in.

Auto exposure adds a trap of its own: at boot it re-learns from whatever sits in front of the lens, so the first parts of a shift can measure differently from the rest. In a cell that runs unattended, fix the exposure, or give the auto-exposure a fixed brightness target and a measurement region that cannot walk off the part.

Arm trigger-driven acquisition last, so the first exposure happens when a part is actually in place, not while the cell is still waking up.

Step 4: gate the first acquisition on a ready signal

The auto-loaded robot program must not ask for a result until the vision side reports live. The pattern: the vision application raises a digital ready output or network flag only after every camera is open, the job is loaded and a test frame has been processed. The robot waits for that input at program start, with a timeout larger than the worst boot you measured — 90 s covers the budget below with margin — and faults with a message that names the vision side if the wait expires.

Keep the signal honest afterwards. A ready line latched at boot hides a camera that dies mid-shift; a cyclic heartbeat that toggles every few hundred milliseconds lets the robot tell running from wired-but-dead. Robot vision camera disconnect detection without stopping the program builds that watchdog. The boot-time fault this prevents is well known: the job is still loading when the first trigger lands — Smart camera misses first images after load: fix the ready gate is that exact failure.

So handshake twice: ready once at boot, then trigger and result-valid every part.

Budget the boot before you trust it

The handshake makes boot work; the budget says how long the robot will wait. Write the stages down and add them:

The stage values are illustrative; measure yours from logs. One robot-side delay has a documented floor, though: a switch port that still runs classic spanning tree stays out of forwarding for two 15 s forward-delay phases before camera frames pass — the IEEE 802.1D defaults, 15 s + 15 s = 30 s of silence between camera and host.

Worked example from the table: with the spanning-tree delay, vision ready moves to 40 s + 30 s = 70 s while the robot's first grab sits at 30 s + 2 s = 32 s. The robot spends 70 s − 32 s = 38 s in retries against a vision side that cannot answer yet. Mark the camera ports as edge ports and RSTP forwards them immediately, which removes the 30 s and leaves the 8 s of ordinary boot difference for the ready gate to absorb.

That is the decision in numbers: edge ports on camera ports, fixed IPs, and a robot that waits for ready instead of trusting any boot order.

Verify with a real power cut

1. Save every setting to its non-volatile home — job on the device, configuration set on the host — then break power at the breaker mid-cycle, not with a soft shutdown.
2. Restore power and let everything come up untouched.
3. Pull the ready timestamp from the vision log and the first-grab timestamp from the controller log; the gap is your real margin.
4. Confirm the first inspection returns a valid result — not a timeout, not a default-threshold no-read.
5. Repeat twice; the worst of the three runs sets the robot's wait timeout.

Mistakes that break the first images

• Live settings never saved. The job loads at startup and overwrites values you only tuned in the live tree — Camera configuration lost after job load: fix storage and load order is the fix.
• DHCP slower than the camera. The camera asks for an address before the DHCP service is up, and discovery fails. Fixed IPs remove the race; the rest of the boot-order checklist lives in GigE camera not discovered on startup: fix the boot order.
• Auto exposure re-learning at boot. The first parts drift until it settles. Fix the exposure for unattended running.
• Deadlock by design. Vision waits for a trigger while the robot waits for a result, and nothing ever moves. Handshake one way at boot, the other way in the cycle.
• USB cameras on one hub. Enumeration order and bandwidth shift after a power event; the feed count that survives is in How many USB cameras one controller can feed before drops.

When auto start is not the answer

Teaching and maintenance should still start under a hand on the controls; autostart belongs to the production program, not to a technician re-teaching a pick. And when a cell grows past one or two cameras, size the host before automating its boot — a unit with PoE camera ports and more memory takes cameras and headroom in one box:

Set the three pieces in order, measure the boot once, and let the handshake carry the difference. To pick host, sensor and lights as one chain, start at the system configurator; more startup-order fixes sit in the systems topic, and if you want a second pair of eyes on your sequence, contact the applications team.