Vision camera job switch online error: fix the state

You send a job-change command to a smart camera or vision sensor from a PLC, a robot or a host PC, and nothing happens. The sensor keeps running the old job, the operator interface may flag online communications with a yellow banner, and the same job file loads fine when you select it by hand. The file is not the problem. A vision sensor that is online refuses job loads by design. Below are the cause order, the handshake that fixes it, code you can adapt, and the checks that keep it fixed.

The symptom, decoded

Three clues point at the state machine rather than the file. First, the refusal appears only on the remote path: the same job loads when someone selects it in the local interface. Second, the sensor reports itself online, sometimes beside a banner questioning online communications. Third, the failure repeats at the same step every time, which a corrupt file almost never does.

Documented behavior backs this up. One vision-sensor error message states that a job cannot be saved while the sensor is online, and sends you offline to fix it. A second manual, for PLC-driven job changes, requires the vision system to be offline before the change is initiated. The gate is the industry default, not one maker's quirk.

If a robot program drives the change, socket handling on the robot side is a separate failure mode; Switch vision jobs mid program without losing the camera socket covers that. This piece is about the sensor-side state.

Why an online sensor refuses the load

Online means executing. The sensor acquires on trigger, runs its tool tree, and answers result telegrams on the industrial network. A job is the whole program: exposure and trigger settings, tools, and the communications mapping that turns results into bytes for the PLC. Loading one mid-cycle would swap all of that while inspections and handshakes are in flight, so the firmware gates job loads, job saves and configuration writes behind the offline state.

Offline is not a fault. It is the maintenance state: writes are accepted, inspection triggers are not, and no results flow. Plan for that silence instead of fighting it.

Some packages offer an allow-online-job-save style option. It is convenient at a bench and the wrong default in production, because a mid-cycle load stops results without warning. Keep the handshake.

The sequence that fixes it

1. Read the state. Poll the status word or online bit before commanding anything, and log the value. You want evidence of where the sequence failed, not just that it failed.
2. Command offline. Send the offline request over the protocol the sensor already speaks.
3. Wait for the offline confirmation. Wait until the status bit clears or the acknowledgement arrives, never for a fixed delay.
4. Send the job change. Use the job number or job name exactly as it is stored on the sensor.
5. Wait for the load acknowledgement. The sensor confirms the new job is resident and closed.
6. Command online and prove it. Return the sensor to online, confirm the online bit, then run one test trigger and check that a result arrives.

// Illustrative pseudocode; these names are ours, not any sensor API
bool state_ok = false
bool job_ok = false
int job_id = 4                 // the production job, as stored on the sensor
int timeout_ms = 3000          // per-step guard

write_command(CMD_OFFLINE)
state_ok = wait_status(STATUS_ONLINE, false, timeout_ms)
if not state_ok: fault("offline not confirmed")

write_command(CMD_LOAD_JOB, job_id)
job_ok = wait_event(EVT_JOB_LOADED, timeout_ms)
if not job_ok: fault("job load not acknowledged")

write_command(CMD_ONLINE)
if not wait_status(STATUS_ONLINE, true, timeout_ms): fault("online not confirmed")
// proof: one trigger after this line must return a result

The final status read proves the sequence; the test trigger proves the job.

Causes in order of probability

1. The sensor was still online when the request arrived. Test: the status word read in step 1 shows the online bit set. Fix: run the full handshake; a bare job change will keep bouncing.
2. The host fired every command back-to-back. The offline command and the job load land milliseconds apart and the second is refused. Test: timestamp every write and every state change in the log. Fix: event-driven waits, as in the pseudocode above.
3. A job is open in the editor. One field status word sets bit 1, Job is being edited, while an edit session is active, and remote loads are refused. Test: read the bit. Fix: close the editor and lock local access during production.
4. A discrete signal owns the state. The same status word sets bit 2, Offline is set by a discrete signal, when a hardware line forces the state, and protocol commands then change nothing. Test: toggle the line and watch the bit. Fix: drive that line from the PLC or remove it from the design.
5. The job is not resident on the sensor. A manual browse can load from a PC archive; a remote load needs the job on the sensor, under the number or name your telegram carries. Test: request the sensor's job list over the protocol. Fix: store every production job on the device, the way Smart camera program storage and offline editing explained describes.
6. Sensor firmware and interface software drifted apart. Job-control services and error text can shift across major versions. Test: compare the two version numbers. Fix: align them, then re-run the sequence once from the controller.

What each state accepts

Code your controller against the state machine, not against hope: offline is the only state in which both the load and its confirmation make sense.

A timing budget you can defend

Swap in the times from your own log; the arithmetic, not the values, is the point. If the sequence plus margin does not fit your cycle, the decision is to move job changes to a dedicated changeover step rather than to shave the guards.

When the usual answer is wrong

• Manual works, remote never does. The local interface runs offline, load and online as one hidden operation, and it browses jobs the sensor already stores. Your controller must do both explicitly.
• Offline confirmed, load still refused. The job is not on the sensor, the telegram's job number or name does not match, or an editor session holds bit 1. Request the job list and read the bits before touching the timing.
• Offline and online commands change nothing. A discrete input owns the state through bit 2, or the request is going through the wrong service. Drive job control through the protocol's job-change service, not file transfer and not interface automation.
• The new job loads and results stop. The communications mapping inside the new job differs from the old one. Check what maps where before the change, as Send vision results to a robot over EtherNet/IP byte mapping walks through.

On a fieldbus the selection often collapses to one register or one byte, and Job change a vision sensor over PROFIBUS: send exactly one byte shows that pattern, but the handshake rules above still apply around it.

Keep the sequence safe

Flush or save pending data before the sensor goes offline, in the order Save data before a scene switch: sequence it with an I/O handshake sets out. After a power cycle or a robot fault, re-run the handshake at cycle start; a sensor that restarts into a different job than the controller expects is the classic silent mismatch, and Vision job lost after a robot fault: re-handshake at cycle start covers the recovery. Make auto-loading the production job at startup your fallback, per Set your vision sensor to auto load its job on startup, and mind the load order notes in Camera configuration lost after job load: fix storage and load order.

Checklist before the next changeover

• All production jobs stored on the sensor, under the numbers or names the telegrams carry.
• Status word polled and logged at every step; any discrete offline line documented.
• Per-step timeouts and a fault path in the controller, not blind retries.
• Changeover sequenced at a part boundary; parts arriving mid-sequence fail closed.
• Firmware and interface software versions recorded and matched.
• One test trigger after every change proves the new job answers.

The hardware that runs it

Any smart camera whose jobs are commanded remotely needs this handshake, whatever name is on the label. The camera finder filters the range by interface, resolution and mount; the LS-SMC-0063, a 1.6 MP smart camera with a 16 mm lens, is one example of the class.

On the control side, a vision controller gives the handshake a permanent home beside the camera ports and light channels. The MV-VC3301H-128G66, an Intel Core i3 controller with 4 built-in light channels, is one such host.

Plan the next station end to end in the configurator, and if the sequence on your current cell still refuses, bring the protocol excerpt and the state log to our contact page. More field notes on camera and controller integration sit on the systems topic page.