The sensor answers on the bus, the GSD file is installed, and you can take it offline and online and send data — yet every job change ends in the job failed bit. The fault is almost never the bus; it is the width of the write. The job number travels to the sensor as exactly one byte, so anything wider puts half your value in the job byte and the other half on the neighbouring handshake byte. Below are the byte layout, the handshake sequence, a worked example of the classic word-write failure, and the two-job test that proves the fix before the line runs again.
What a job change actually sends
A sensor set up from its GSD file exchanges cyclic data with the PLC on every bus cycle: output data flows from the PLC to the sensor, input data flows back. The GSD defines how many bytes sit in each direction; the sensor's fieldbus manual maps them in its Job control section — which output byte carries the job number, which bit triggers the change, and which input bits report the sensor's answer, typically busy, done and job failed.
The payload is one byte because the telegram selects rather than uploads. The jobs themselves — inspection recipes, code definitions — are stored in the sensor. A job selector only has to carry a number, and 0 to 255 fits in one byte, so that byte is the entire message you have to get right.
One sensor serving several products at changeover is the classic use — for smart cameras as for fixed code readers switching code definitions between trays.
The rule: write exactly one byte
Write the job number with a byte-sized move into the byte the Job control section maps for jobs. Nothing else belongs in that byte, and the handshake bits live in their own byte, written separately. A byte runs 0-255, so any job number on the sensor's list fits.
A wider write fails whichever byte order your CPU uses. On CPUs that place the high byte of a word at the lower address, a 16-bit move of job 3 writes 0x0003 as bytes 0x00 then 0x03: the job byte receives 0x00 and the sensor never sees job 3 at all. On CPUs that store the low byte first, the job byte gets the right 0x03 — and the second byte lands on the handshake byte on every scan, wiping the trigger bit you set, so the request never completes.
Then there is the bit that costs the most debugging time: the job failed bit latches. It changes only when the PLC initiates a job change, and it stays set until one succeeds. One bad write keeps it high through every scan that follows — even after you correct the program — until the next good change clears it.
Worked example: writing job 3 from a CPU that stores the high byte first
Inputs: the sensor's stored job list includes job 3, the recipe for the second product (a typical case; the arithmetic is identical for any stored number). The GSD module selected in the engineering tool contributes two output bytes starting at %QB256 — the address is illustrative, the layout as the Job control section prints it: first byte job number, second byte handshake. The current program moves 16 bits, not 8, into the word at %QB256.
Rule: the job-number byte must receive 0x03 and nothing else; the handshake byte must receive only the trigger bit.
The value 3 as a 16-bit word is 0x0003, and the CPU splits it across two bytes:
The high byte sits at the lower address, so %QB256 receives 0x00 and %QB257 receives 0x03. The sensor's job byte reads 0, its handshake byte picks up two stray bits, and it answers with the job failed bit. The change to job 3 never arrives — and per the rule above, the failed bit now stays set until a good change runs.
Decision: delete the word move. Write one byte, 0x03, to the job-number byte, and set the trigger with a separate byte write to the handshake byte. The threshold is structural, not numeric: any write wider than one byte into a one-byte field fails, at every job number and on both byte orders. On a low-byte-first CPU the same word move fails the other way round — the job byte gets its 0x03 while the handshake byte is forced to 0x00 every scan, cutting the trigger you just set.
The handshake sequence, step by step
- Note the job numbers on the sensor's stored job list, with the product each belongs to. The telegram selects from this list; it cannot create jobs.
- Install the GSD file in the engineering tool's device catalog, drag the sensor into the network view, and select the data module whose input and output byte counts match the Job control section.
- Copy the byte map into a comment beside the PLC addresses: job-number byte, handshake byte, and the bit positions in the input data.
- Write the job number with a byte-typed move into its byte. Leave the handshake byte at zero.
- Set the trigger bit with one byte write in which only that bit is high.
- Watch the input data: the sensor takes the job, reports busy, then sets done or job failed.
- Clear the trigger. The sensor drops the done bit and the change is complete.
- Repeat once with a different job number. Two clean changes prove the write rather than luck.
Verify the change without stopping the line
Put the output bytes in a watch table first: the job byte should hold your number, and nothing should touch the handshake byte except the step that sets the trigger. Then run the two-job test at the line — job A for ten parts, job B for ten parts, failed bit watched the whole time. Ten clean changes in each direction is a handshake you can release.
Confirm the switch from the sensor side too. Where the sensor offers a menu or web page, it shows the active job, so you can see the change happen rather than infer it. To decode the input byte by hand, read it as hex and apply the bit positions from the Job control map.
Keep the bus LED honest: a steady green with jobs still failing means the link is healthy and the fault lives in your telegram. A green LED that flickers points at parameterization or configuration trouble at the bus level — settle that first, because no telegram is delivered reliably over an unstable link.
Common mistakes that set the job failed bit
- A word or dword move into the byte field — the classic, and the exact failure of the worked example.
- A second block writing the same output address. The last writer in the scan wins, so the job byte changes value between your write and the bus cycle. Dedicate the sensor's output bytes to one block and audit every write to that address range.
- A trigger pulse shorter than the sensor's scan. The request is lost without any error; hold the trigger until the answer arrives.
- A job number that is not on the sensor's stored list. The telegram arrives cleanly and the failed bit answers — the sensor is behaving correctly, so correct the number, not the bus.
- Waiting for the failed bit to clear by itself. It latches until a PLC-initiated change succeeds.
If jobs drop after a robot or cell fault rather than after a program edit, the handshake has lost its state. Rebuild it at cycle start as described in vision job lost after a robot fault: re-handshake at cycle start.
When a cyclic byte is the wrong tool
| Job selection method | What the PLC sends | Choose it when |
|---|---|---|
| Cyclic fieldbus byte (this guide) | One job byte plus a handshake bit, every bus cycle | Changeovers run at machine speed and jobs switch several times a shift |
| Discrete trigger inputs | One digital input per job | Two or three jobs and spare digital I/O is free |
| Serial command | A short command string over the serial link | The sensor is already wired for serial results |
| Auto-load at startup | Nothing after boot | One job per machine, chosen when the sensor powers up |
For the last row, set it once and skip the handshake entirely: set your vision sensor to auto load its job on startup.
The result side has its own handshake and its own pitfalls. Send decisions and coordinates, not images — see sending pass-fail results to a PLC, sending vision coordinates through a register handshake and a fixed-position RS-232 telegram. When the reader also drives the robot's program choice, routing a barcode reader result to robot job selection picks up where the job change stops.
Before you order: match the sensor to the bus
The cyclic byte exchange only exists where the sensor publishes a device description file for your bus. The smart cameras and fixed code readers in this shop list Fast Ethernet, GigE, USB and Serial interfaces, so a PROFIBUS network needs either the sensor family's fieldbus variant or a gateway that translates. Decide that before you design the telegram, because the byte map lives in the fieldbus manual that ships with the variant you buy.
When you specify, confirm two things: the family publishes a GSD file for your network, and its fieldbus manual carries the Job control chapter with the byte map and handshake. Both are one-page checks that decide whether the rest of this guide fits your hardware as written. The shop finder filters sensors by interface, resolution and shutter, and the configurator below starts at the trigger step.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
If the job change is one half of a bigger integration, the handshake articles above carry the other half — and if you want a byte map checked against a specific sensor before committing the PLC program, contact us with the manual's Job control page.
Questions
Why does the job failed bit stay set after I correct the program?
The bit latches. It changes only when the PLC initiates a job change, and it clears only when one succeeds. After you fix the write width, force one good change — write a valid job number, pulse the trigger, watch the done bit — and the failed bit drops. From then on it is a genuine error signal again: on means the most recent PLC-initiated change failed.
My PLC language only offers word-sized moves to the process image, what now?
Move the job number into a memory byte with the right operand size, then copy that single byte to the output byte. The value never has to change — 3 is 3 in a byte and in a word; the operand width is what corrupts the telegram. Some toolchains also let you declare a byte-typed variable mapped onto the output address, which works for the same reason: the sensor only ever receives the one byte.
Does the same job change work over PROFINET?
Yes. The cyclic data exchange and the handshake pattern are identical: one output byte for the job number, one handshake bit, done and failed bits in the input data. What changes is the description file — PROFINET devices use the GSDML format instead of a GSD — and how you install it in the engineering tool. The byte map itself comes from the same Job control chapter of the fieldbus manual.
Which job numbers are valid on the fieldbus byte?
The byte carries 0-255, but only numbers on the sensor's stored job list select anything. A number that is not on the list is not a telegram error: the sensor receives it cleanly and answers with the job failed bit, which is correct behaviour. Number the jobs in the sensor first, then use exactly those numbers in the PLC program.
How do I prove the fix without running production?
Drive the handshake from the force or watch table while the machine is in a safe stopped state: write the job byte, set the trigger bit, read the input data as hex. A done bit answers a valid change, a job failed bit answers an invalid one, and nothing at all means the trigger never arrived. Two forced changes to two different numbers is enough evidence to release the program to the line.