PLC Handshakes

Every exchange between a PLC and OV Spark Pro follows a handshake: the PLC raises a request, the camera acknowledges, and the PLC lowers the request once it has seen the acknowledgement. There are four: trigger, reading results, recipe switch, and commands.

This page is for the controls engineer writing the PLC logic. It works the same over EtherNet/IP and PROFINET.

In short

• Always wait for the camera's ready bit before raising a request, and hold the request until you see the ack
• Read results on Results Valid plus a changed Inspection ID, never on a toggle alone
• Acknowledge every result, or nothing new is presented

Signal names here, byte offsets from the generated files

This page names signals rather than addresses, on purpose. The byte and bit layout is generated per firmware, so take it from the EDS or GSDML for your camera's firmware, or from the reference sections on the camera's Industrial Ethernet page. Hand-typed offsets are how an install ends up reading the wrong bit after an update.

Trigger

1. Check Online = 1, Trigger Ready = 1 and Trigger Ack = 0. Write Part ID, and User Data if you use it, then raise Trigger and hold it
2. The camera accepts on the rising edge: Trigger Ready drops to 0, Trigger Ack rises to 1, and Part ID and User Data are latched. If it rejects the trigger, Trigger Error rises and Error ID says why
3. When you see Trigger Ack = 1, lower Trigger
4. The camera lowers Trigger Ack. Exposure Complete sets when the exposure ends, and Trigger Ready returns to 1 when the next acquisition can start

Watch out for

• Holding Trigger high does not re-trigger. The camera acts on the rising edge only
• Trigger Error reports the last trigger from any source, not just yours. Read Error ID for the reason rather than assuming you triggered too fast
• Trigger Ready = 1 while Busy = 1 is normal when the image buffer is in use. The camera can accept the next trigger before the current inspection finishes. Do not latch that as a fault

Reading results

One handshake covers both modes. With Buffer Results Enable = 0, results are live and each one overwrites the last. With Buffer Results Enable = 1, up to 10 are queued.

1. Wait for Results Valid = 1
2. Read every result field in one scan, together with Inspection ID
3. Raise Inspection Results Ack and hold it. The camera dequeues, and Results Valid and the pass and fail bits drop to 0
4. When you see Results Valid = 0, lower the Ack. If more results are queued, the next is presented on that falling edge

Treat Results Valid going 0 to 1 with a changed Inspection ID as a new result.

Watch out for

• Inspection Completed toggles; it is not a level. In buffered mode it marks a completion rather than a presentation, so it can flip while the result fields stay the same. Never read results on the toggle alone
• Live mode can hide an inspection. Two completions inside one packet interval can look like one flip. Buffered mode is immune
• Changing Buffer Results Enable discards the queue and the presented result, on either edge
• A gap in Inspection IDs means an accepted trigger produced no result: aborted, dropped, or suppressed
• While the Ack is high, nothing new is presented, however many inspections complete

The overall verdict is in Inspection Pass and Inspection Fail. Both at 0 means no result. Per-tool detail comes from the slots you assign on Step 5: Outputs.

Recipe switch

1. Check Recipe Switch Ack = 0, write Recipe ID, then raise Recipe Switching Request
2. If accepted: Recipe Switch Ack rises, Trigger Ready drops, and Online drops with Offline Reason = 3, recipe loading. If rejected: Recipe Switch Error rises, with an unknown-recipe or busy error
3. When loading completes: Current Recipe ID, Recipe Version and Tool Count update, Recipe Load Complete rises, and Online returns to 1
4. Lower Recipe Switching Request. The camera clears the Ack and Recipe Load Complete

Watch out for

• Keep Recipe ID constant from the rising edge of the request until the Ack
• In-flight parts finish under the old recipe. They carry the old recipe in Recipe ID During Judgment, so use that, not Current Recipe ID, to interpret a result
• Queued results survive the switch and keep the recipe that judged them
• If loading fails, the previous recipe stays loaded
• The Recipe ID is the PLC recipe ID set on Step 5: Outputs. Duplicating or importing a recipe gives it a new one

Commands

1. Check Command Ready = 1, write Command ID and Command Arg 0 to 3, then raise Execute Command and hold it
2. The camera latches the ID and arguments: Command Ready drops, Command Executing rises
3. When it finishes, one update carries all of Command Response 0 to 3, Command Result Code, Command Executing = 0, Command Complete = 1 and, on failure, Command Failed = 1. These are never split across scans
4. Read the response and lower Execute Command. The camera clears Command Complete and returns Command Ready to 1

The command list and result codes are in the Command reference and Codes sections of the camera's Industrial Ethernet page.

A robust PLC sequence

For a typical line, the logic that survives production looks like this:

1. On part present, wait for Trigger Ready, then trigger
2. Wait for Results Valid with a new Inspection ID
3. Read the verdict, any slots you need, and Recipe ID During Judgment
4. Acknowledge
5. Act on the verdict, matched to the part by Part ID or Inspection ID

Match results to parts by ID, not by timing

Assuming the next result belongs to the next part works until the first dropped trigger. Write a Part ID with each trigger and check it comes back with the result, and a single missed part cannot shift every verdict after it.

Back to the getting-started pathConnect to your PLC

Step 12 of 13. Map outputs to EtherNet/IP or PROFINET.