Change a vision job from a PLC or use one generic job with user data

Your PLC knows which product is next on the line. Your smart camera or code reader then has to know what to check on it, and there are two ways to tell it: load a different job file, or keep one job and send the product's settings as data each cycle. The job-per-product reflex works for a handful of SKUs and collapses at a few hundred. This guide gives you the decision rule, both EtherNet/IP job-change mechanisms, the user-data pattern with a worked byte mapping and handshake, and the point at which separate job files are still the right answer.

The decision: job files below about a dozen variants, user data above

Commit to this rule:

• Under roughly a dozen products sharing one optical setup: a job file per product, changed by the PLC. Twelve files are quick to keep aligned, and a load happens between product runs, where the stall costs little.
• A dozen or more products, or a SKU list that keeps growing on the same optics: one generic job plus user data. The PLC writes a product code and a tool-enable mask into the output assembly every cycle; a new product becomes a new row in a recipe table, not a new camera file.
• Different lens, field of view or lighting per product family: neither method alone. Group products by optical setup, keep one job per family, and drive per-product tools inside each job with user data.

The dozen-file crossover is maintenance arithmetic, not a camera limit. The worked numbers two sections down show why the cost multiplies with every file you keep.

How a PLC changes a vision job over EtherNet/IP

Most networked vision systems support job change two ways, and both of them load a file:

1. Explicit messaging. The PLC sends a one-shot service request that runs the camera's load-job command with a file name or number. You configure it as a message instruction aimed at the camera's IP address, with the service and parameters listed in the vendor's EtherNet/IP integration note. The same path can send any supported command, but every change is a full request-response transaction, not a tag write.
2. The implicit I/O connection. The output assembly the PLC already writes on every connection update reserves a job or execution number field, usually with a change bit beside it. You move the number into the field, pulse the bit, and the camera loads that job and reports progress in the input assembly.

For a handful of products the implicit path is the clean one: the PLC logic is an integer write and a pulse, and job status is readable in the input assembly. Job change over PROFIBUS works the same way — job change over PROFIBUS with exactly one byte shows the minimal version. For where implicit and explicit messaging each belong in general, see vision sensor results to an HMI over EtherNet/IP.

Both mechanisms stop acquisition while the file loads. That single fact drives the arithmetic in the next section.

Why job change scales badly: the maintenance arithmetic

Every job file is a full copy of the inspection: tools, tolerances, exposure, lighting settings. A change that should apply to all products has to be repeated in every file by hand, and a missed file keeps inspecting its product against stale settings until a bad part surfaces downstream.

Worked example, with illustrative inputs you can replace with your own: 200 products, one lighting correction, 3 minutes to open, adjust, save and deploy one job.

• Edits required: 200 jobs × 1 correction = 200 edits.
• Time: 200 × 3 min = 600 min = 10 h of engineering time per lighting change.
• Residual risk: one forgotten job means one product family inspecting against the old setting, indefinitely, until scrap or a customer finds it.

At 12 products the same change costs 12 × 3 min = 36 min, an hour of annoyance. At 200 it is a working day, every time a light drifts, a tool improves or a tolerance tightens. That multiplication, not any hardware limit, is what sets the dozen-file crossover.

Cycle time adds a second cost. Acquisition stops during every load, so a mixed line that changes product every part pays a load stall on every part, and any part under the camera mid-change is not inspected at all. A file scheme also has to survive restarts: set the camera to auto-load its job on startup so a power cycle never leaves the wrong file active.

The user-data pattern: one job, per-product settings from the PLC

Keep one job that contains every tool the product family needs, all disabled by default, and let the PLC decide which ones run on each part. Most smart cameras and code readers with an EtherNet/IP stack reserve part of the output assembly as user data: bytes your job can read at run time, beyond the trigger and acquisition bits. Three moves implement the pattern:

1. The job defines which incoming bytes hold the product code and the tool-enable mask.
2. The PLC writes code and mask before each trigger, from its own recipe table — filled by operator entry at the HMI or by a barcode read upstream.
3. The job enables the masked tools, inspects, and returns results with a done bit in the input assembly.

No file ever loads. Settings take effect at the next trigger, so new values arrive within one or two connection updates; adding a product is a recipe row, and a lighting edit happens once, in one job.

How many products does one code field cover? The field width alone sets it:

A 16-bit field costs the same engineering as an 8-bit one, so size for the SKU list you expect over the system's life, not the one on the floor today.

The hardware needs one thing: tools that switch at run time from written data, plus spare bytes in the assembly. Most on-device inspection systems qualify. A 6 MP GigE smart camera such as the MV-SC5060XM-08M-WBN runs the whole inspection on the device while the PLC only feeds it code and mask. Installations that stay on Fast Ethernet can use a 5 MP color vision sensor such as the MV-SC3050XC-16M-ATN-H the same way.

A worked mapping: product code and tool mask in four bytes

Assembly layouts differ by vendor, so take the offsets from the camera's own assembly map. The fields to reserve look like this example layout:

The input assembly returns the applied code plus a done bit, which gives you an echo check for free.

Three handshake rules keep the cycle predictable:

• Write user data between parts, never while a trigger is in progress.
• One apply pulse per part; code and mask hold until the next write.
• Compare the echoed code against the written code before the part is released.

The write discipline is the same one that keeps barcode data flowing from PLC to HMI without drops: one handshake per part, no free-running writes. For how result bytes map into the return assembly, the byte-mapping walkthrough uses the same field-by-field method.

Code readers: a generic decode job usually removes job change entirely

A fixed code reader with a generic decode job reads every symbology you enable inside that one job — a change of code type is a setting, not a different file. What changes per product is the expected content. Keep the expected string per product code in the PLC recipe table and compare it against the read result; that is the pass/fail match-verification pattern. Job change re-enters only when acquisition itself differs — another focus distance or light arrangement per product family — and then you are back to one job per optical family, not per product.

Decode throughput, not a job list, sets a reader's capacity: the LS-CRD-0028, for instance, is a 5 MP fixed code reader rated at 30 fps and 60 codes/s with an 8 mm lens. A compact Fast Ethernet reader covers the same generic-decode role in a smaller footprint:

When separate job files are still the right answer

Three cases argue for files:

1. Different optics per family. A different focal length, working distance, field of view or lighting arrangement cannot be parameterized away inside one job. Keep one file per optical family and user data inside it — two to five files even on a line with thousands of codes.
2. A small, stable product range. Below roughly a dozen variants the edit arithmetic stays trivial, and a job per product is the scheme the next engineer understands at a glance.
3. A version boundary per product. When each product's inspection must exist as a fixed, separately versioned artifact — some customer audits ask for exactly that — per-product files give you a cleaner boundary than shared user data.

When you do change jobs, prefer the implicit job-number field over explicit file-load messages: an integer write and a change bit per switch, progress visible in the input assembly, and no string handling anywhere in the PLC.

Checks before you commit

• Count SKUs per optical setup, not total SKUs. The count that drives the decision is how many products share one lens, distance and light.
• Read the assembly map. Confirm spare output bytes, which fields the job can read at run time, and what the input assembly echoes.
• Prove tool switching first. Enable and disable two tools from written data in a test job before building the full generic job.
• Add the interlocks. No writes mid-acquisition, echo check before release, fault on mismatch.
• Test the failure paths. Force a wrong code, a wrong mask and a write during a trigger; expect a held part and a logged fault, never a crash or a silently passed part.
• If you keep files, version them. Auto-load the default job at power-up and keep a written map of which code loads which file.

Where to go next

Pick hardware to match the decision. Smart cameras host the generic-job pattern for presence, measurement and assembly checks; fixed code readers usually need nothing more than their standard decode job plus a match check in the PLC. The camera finder filters both by interface and resolution, and the configurator walks the rest of the chain: lens, light and trigger hardware. The systems topic page collects the related guides, from assembly mapping to handshake design, starting at LumaSpec Learn.