Vision sensor no process sequence defined error: reset and retrain

Trigger fires, the aiming lamps come on, the image stays dark, and the decode counter never moves — while the device reports a "no process sequence defined" error and asks you to set the unit to default settings. That is one fault, not two. The aiming lamps are wired to the trigger in firmware, but the strobed reading light is a step inside the stored inspection sequence. With no valid sequence stored, nothing commands the light, so every part reads as a miss. This guide shows you how to confirm which of the four usual causes you have, run the reset the manufacturer documents, rebuild the sequence in the right order with the illumination step timed to your line speed, and prove the fix before the next production run.

What the no process sequence defined message tells you

A vision sensor or industrial fixed code reader decides nothing by itself. On each trigger it executes a stored sequence: a step that fires the illumination, an acquisition step with a defined exposure, the read or inspection tools, and an output step that sends the result. The message is literal — the device booted and found no complete sequence to execute.

The split behaviour you observe is the signature. Targeting lamps come on with the trigger because alignment is a firmware-level aid, independent of any job. Reading illumination is different: it lives inside the sequence as a defined step with a duration and a timing relationship to the exposure. No sequence, no illumination step, no light — and a dark image means the read tool never had a chance.

Treat the message and the dead light as one fault, and fix the storage, not the lamp.

Likely causes, in order of probability

Work down the list; each test takes minutes.

1. The job was never saved. A fresh device mounted before anyone built a job, a configuration pushed over from another unit with an empty job, or an interrupted save. Test: open the device in the manufacturer's configuration utility and look at the application list — an empty list, or a job whose sequence holds no steps, confirms it.
2. Corrupt job storage. A power dip during a save or a firmware write can half-write the job area. Test: the job appears in the list but fails to load, or loads without its tools. The storage-and-load-order failure mode is a close cousin — see camera configuration lost after job load: fix storage and load order.
3. A sequence with no illumination step. The application exists, but the sequence holds acquisition and tools only, and some firmware flags any incomplete sequence with this same message. Test: open the sequence editor and count the steps — you need illumination, exposure, tools and output.
4. The wrong application for the device. A job exported from another family, or a fieldbus master that switches to a job number the device does not store. Test: check the job's target model against the device and check what writes to it at boot. If a PLC changes jobs over fieldbus, a single wrong byte selects an empty slot — see job change over PROFIBUS: send exactly one byte.

The fix: the reset the manufacturer documents

Once storage is confirmed empty or corrupt, the repair is the documented one, in this order.

1. Export backups of every job worth keeping from any device that still has them, and record the device's network settings.
2. Run the reset to defaults from the manufacturer's configuration utility. Devices the network tool can no longer find have a documented rescue procedure in the manual for exactly this situation.
3. Let it finish, then power-cycle. The reset erases all inspections and tools and returns settings such as the IP address to defaults. That is the documented cost of the repair, not a malfunction.
4. Reconnect at the default address, load or rebuild the job, and save it to device storage, not just the working session.

Stay on the vendor's own path: an undocumented recovery image or a settings file from an unknown source trades one fault for two.

Rebuild the sequence: illumination first, output last

Rebuild in the order the device executes, because each step depends on the one before it.

1. Illumination. Define the strobed light to fire on trigger, with a duration timed to the line speed — the worked example below gives the arithmetic. Drive the light from the reader's illumination output, or from a light controller with a strobe feature.
2. Exposure. Set a fixed exposure that brackets the strobe, and turn every auto exposure and auto gain off; auto modes re-tune image by image and drift with ambient light, which is its own slow failure — see camera image brightness drifts over time: turn every auto mode off.
3. Tools. Add the read tool, draw the region of interest where the code actually lands, and limit the symbology list to the codes you print.
4. Output. Send the result where the line consumes it: digital outputs for a reject gate, or a serial or Ethernet message for the PLC. If the PLC reads an ASCII string, the framing matters — ASCII barcode data framing in the PLC receive buffer: nulls and races covers the buffer traps.
5. Save to the device, power-cycle, confirm the job reloads. A job that lives only in the working session dies with the next power cut, which is how most of these faults start.

A controller dedicated to the lights keeps the strobe pulse clean and repeatable; the LS-CTL-0070 is a 4-channel, 200 W digital controller with a strobe feature and RS232.

The whole chain — camera, light, reject gate — must respect one timing order: machine vision trigger timing: sequence camera, light and reject gate walks through it. If your light has no input the reader can drive, camera LED flash control with no API: add an external strobe shows the hardware route, and trigger a vision light on for two seconds at the inspection moment covers the steady-light case.

Worked example: strobe duration for a part at 200 mm/s

The illumination step exists to freeze motion. With the light off, the exposure has to run long enough to blur the part past readability; with a short strobe, the light-on time sets the blur and the exposure just has to wrap the pulse. Here is the arithmetic for a typical small-parts conveyor — substitute your own speed and pixel size.

Inputs and where each comes from:

• Part speed: 200 mm/s — assumed, typical for a small-parts conveyor; measure yours with a stopwatch over a known distance.
• Pixel size: 3 µm — assumed, typical for a 5 MP imager on a 1/1.7-inch-class sensor; take the real value from your sensor data.
• Blur budget: 1 pixel — the working limit for a reliable decode of a 1D or 2D code.

Rule in words: the part must travel less than one pixel while the light is on.

Arithmetic: t_strobe(max) = 1 × 0.003 mm ÷ 200 mm/s = 0.000015 s = 15 µs.

Decision: keep the strobe at or below 15 µs at this speed. Set it to 10 µs for margin and the blur is 200 mm/s × 10 µs = 0.002 mm, which is 0.002 ÷ 0.003 = 0.67 pixels — inside the budget with room. The limit scales directly with speed: at 400 mm/s the same budget halves to 7.5 µs, which is why fast lines need shorter strobes or larger pixels.

For contrast, assume factory lighting alone needs about 5 ms of exposure for a readable image. The same part then blurs 200 mm/s × 5 ms = 1 mm, which is 1 ÷ 0.003 = about 333 pixels. That image cannot decode, and that is why the sequence needs an illumination step at all.

The cadence check closes the loop. With 100 mm part pitch, parts arrive every 0.5 s — 2 reads/s — so a compact reader rated for 60 codes/s carries this line with room to spare. The LS-CRD-0028 reads 60 codes/s at 30 fps, pairing a 2560 x 2048, 5 MP sensor with an 8 mm lens and a global shutter.

When the reset does not stick

If the error returns a shift or a day later, stop resetting — the reset repaired the symptom, and something is erasing the job again. The usual suspects:

• Power. A dip during a save or a firmware write half-writes the job area. Put the device on a conditioned supply and log power events.
• A controller writing at boot. A fieldbus master that sends a job-change command at startup can select an empty slot on every power-up. Check which controller writes to the device and what it sends.
• Failing storage. Corrupt jobs across repeated resets point at the storage area itself, and that is a repair case, not another reset.

Also check the job-switch state itself: some devices refuse a job change requested while online and report a state error instead — vision camera job switch online error: fix the state walks that path.

Checks before you call it fixed

Run the list once after the rebuild, before production.

• Pull a trigger with the live image open: aiming lamps on, strobe firing, image bright and sharp. A dark image with the light confirmed firing is a different fault — gain, exposure or lens — not this one.
• Power-cycle and confirm the job reloads from storage, with the sequence showing illumination, exposure, tools and output.
• Read ten parts in motion and confirm the decode rate matches the arrival rate; misses that track speed point back at the strobe budget.
• Confirm the result reaches the PLC in the form it expects — send a vision match result to a PLC output shows the wiring and handshake.
• Zero the shift statistics so the first counts are real — reset pass/fail counters per batch in a vision inspection script.

Keep an exported copy of the rebuilt job with the panel documentation. The next time a power event or a firmware update wipes a device, recovery is an import and a trigger test instead of an hour of rebuilding.

Hardware for the rebuild

The same rebuild covers a code reader or a smart camera; only the tools inside the sequence differ. Compact code readers mount at the line and decode on board, and smart cameras carry the same sequence structure for inspection work — both run the inspection on the device, with no PC in the chain. Where the reading light should come from the camera itself, a model with integrated illumination removes the strobe wiring entirely.

Hardware that fits this rebuild:

After you rebuild either device, run the same save-and-power-cycle check, then keep the exported job with the panel documentation.

More reader-side fixes are collected on the code reading topic page. The light controller finder and camera finder filter by strobe feature, mount and interface, and the configurator steps through camera, light and controller as one chain. If reads still fail after a clean rebuild, send the trigger and wiring sketch through the contact page and we will check the timing with you.