The Vision Decision Is Done, So Why Does the PLC Learn It Late?

INTERFACE

In this setup the longest segment delaying a decision is the 106.9 ms image transfer, not the 25 ms inference, and the key to putting a late result back in its place is the trigger ID.

Splitting vision-side latency from trigger input to result output into six segments, I calculated the worst-case wait of digital output and cyclic networking, and the share of results pushed past the next trigger.

About 12 min read

The inspection log says the decision finished in 25 ms, yet the machine side says the result arrived late. The vision engineer shows the inference time, and the controls engineer shows the time the result was received. The gap between those two numbers appears in no one’s log.

As that gap grows, a moment comes when a late result is read as the result of a different part. Without a number identifying the part, one delayed result knocks the verdicts of the following parts out of line one after another, and defective parts pass recorded as good.

So I split the path from trigger to result output into segments on the vision side, measure the worst case of each, and send results out tagged with a trigger ID and a timestamp. The example setup is a line that inspects 100 μm defects on a matte molded cover with a 4,096 × 3,000 px camera, and each part is assumed to receive a trigger every 150 ms. The cycle and logic with which the PLC reads results belong to the PLC design and need a separate review; here only the segments the vision system can answer for are calculated.

Latency is the sum of six segments

Vision-side latency does not end with one inference time; it builds up as the sum of six segments from trigger input to result output: trigger input (input filtering and delay), exposure, sensor readout and transfer, queueing (waiting while the previous image is processed), processing (preprocessing, inference, decision) and result output (digital output or a network message). The benchmark’s inference time is only part of the fifth segment.

Put in the numbers, and the order flips. One 4,096 × 3,000 px 8-bit image is 12.29 MB, and assuming an effective bandwidth¹ of about 115 MB/s on a 1GigE link, transfer alone takes 106.9 ms. With exposure at 0.2 ms and processing at a usual 25 ms, the longest segment is the transfer, more than four times the processing that contains the inference, and the three together, 132.1 ms, fit inside the 150 ms trigger interval. To my eye, this flipped order is where the whole latency story starts. The calculation for changing the interface itself is in the interface bandwidth article.

Only timestamps at the start and end of each segment let you say where the delay happened. Use the timestamp and frame ID carried by the camera’s exposure-end event as the reference point, and the boundary between exposure and transfer can be recorded on the camera’s clock. GenICam SFNC² defines items that carry a timestamp and frame ID in this event. Record processing time as p99 latency³, not as an average; how to split it by segment is in the p99 latency budget article.

The output path changes the shape of the worst wait

Whether a result goes out as a digital output signal or as an industrial Ethernet message changes the shape of the worst-case delay. A digital output⁴ travels down the wire the moment the vision device changes it, so vision-side latency closes at the instant the output is updated. A wire does not wait. An I/O connection on EtherNet/IP configured with a cyclic trigger, by contrast, sends data at a fixed interval called the RPI⁵.

At the top of the figure, A is a digital output whose signal rises the moment the result is ready, and B is a cyclic message that waits for the next packet slot. Even right after the result is ready, B has to wait for the next transmission, and in the worst case that wait approaches one full cycle. With the RPI set to 10 ms, 0 to 10 ms is added before the result goes out, depending on when processing finishes. 10 ms is the worst case. I would give this wait its own line in the budget sheet. When the PLC reads that data in its logic belongs to the PLC design and needs a separate review.

IEC 61131-3⁶ tends to come up in talk about PLC communication delay, but that standard covers PLC programming languages, and communication is covered by Part 5 of the same series. The vision side’s responsibility extends to recording, separately, the time a result was ready and the time it actually went onto the link. When results run close to the deadline, I would look first at splitting the output, with the decision bit on a digital output and detailed data on the network, before shortening the network cycle.

Every result carries a trigger ID

Every result message carries the trigger ID (or frame ID) and the exposure timestamp along with the verdict. These two are the first fields I settle in a result format. In a system whose processing time wobbles, the assumption that the next result to arrive belongs to the next part collapses with a single delay. With an ID, the receiver can attach a late result to exactly the right part, or clearly set apart a result that missed its deadline as ‘no verdict’.

Calculate how often it collapses. Take away the 0.2 ms exposure and 106.9 ms transfer, and for a result to come out before the next trigger (150 ms), processing and output wait together must finish within 42.9 ms. If processing time has a p99 of 60 ms, the 1% that exceed 60 ms all arrive after the next trigger even with zero output wait. One part every 150 ms for 8 hours is 192,000 parts, and 1% of that is 1,920. That is no small number. For a receiver that matches by arrival order without IDs, each of those 1,920 can be the start of a matching that slips by one place.

The order the three numbers tell is clear. The longest line is the transfer, the output path adds up to 10 ms at worst, and the late 1% find their place only through IDs. When the camera, vision PC and PLC run on different clocks, timestamps cannot be compared, so PTP⁷, integrated into GigE Vision 2.0, aligns the clocks of the devices onto one time axis.

Even if the result for trigger 1001 misses its deadline and arrives after trigger 1002, with an ID it applies only to part 1001 and never mixes with the verdict for 1002. Without an ID, the receiver may read it as 1002’s, and from that moment matching slips by one place. How to handle results past the deadline is the machine side’s decision, but the IDs and times that make that decision possible have to come from the vision side. By my rule, a result message without an ID is not accepted in the spec.

Fixing latency without losing the 100 μm defect

Moved into spec-sheet lines, the latency measures read as below. Why cutting resolution comes last is in line ①.

Item	Value	Condition · basis	In plain words
① Minimum defect size	100 μm = 4.1 px (24.4 μm/px)	Cutting transfer to 26.7 ms with 2×2 binning leaves 2.05 px at 48.8 μm/px	Latency fixes that cut resolution come last
② Sensor · interface	4,096 × 3,000 px 8-bit (12.29 MB per image), 1GigE effective about 115 MB/s assumed	Transfer alone 106.9 ms per image, the largest of six segments	The longest line is transfer, not inference
② WD	Based on an object distance of about 202 mm, real WD fixed with the maker’s data	Fixed on the drawing so exposure conditions survive reinstallation	A changed distance changes exposure and resolution together
③ Timestamp reference	Exposure-end event timestamp + frame ID	GenICam SFNC 3.66, 15.5	The moment the shutter closes is the reference time
③ Result message fields	Verdict, trigger ID, exposure timestamp, processing-complete time	ID matching on the receiving side	Every result gets a name tag
③ Output path	Decision bit on digital output, detailed data on the network (RPI 10 ms assumed)	Worst network wait about one RPI	What is urgent goes down the wire
③ Monitoring	Per-segment p99, count of results arriving after the next trigger	With a 60 ms processing p99, at least 1,920 of 192,000 in 8 hours	Count late arrivals instead of averaging

Under these conditions the longest segment is the 106.9 ms transfer, against 25 ms of inference. The network’s cyclic wait stops at one RPI at most, while transfer repeats for every image, so the priority of fixes runs transfer, queueing, output path. Cutting transfer to 26.7 ms with 2×2 binning⁸ coarsens the resolution to 48.8 μm/px and drops the 100 μm defect to 2.05 pixels, so to keep the three-pixel rule it stays the last option. Resolution goes last.

Sometimes this method is the wrong pick. If only a single decision bit is needed and processing always finishes within one trigger interval, building with a hardware trigger and digital output alone, without ID matching, is simpler and easier to verify. When several cameras shoot at once, aligning their clocks with PTP and triggering them simultaneously over Ethernet with scheduled action commands cuts wiring compared with running a trigger cable to each camera. For offline inspection with plenty of processing margin, splitting segments drops in priority. If the part changes to glossy metal, exposure time and lighting change and so does the latency distribution, so the real distribution cannot be guaranteed before a sample test.

Stamping each segment and splitting the latency is the first exercise I would suggest to anyone taking on the job of attaching a vision system to equipment for the first time. From the side that runs the equipment, adding one ID field to the result message costs far less than tracing back verdicts that slipped by one place. This article explains technology and is not investment advice. See our Disclaimer.

Field Note

When word comes that verdicts in the machine record occasionally slip by one place, I would ask for the field list of the result message first. Without a trigger ID and exposure timestamp, the likely story is that one result delayed in the transfer queue got read as the next part’s verdict. With an ID, I count the results that arrived after the next trigger using the per-segment timestamps, and check whether that count matches the 1% calculated from the processing p99. On a line that went through reinstallation, I also confirm that the WD and exposure time still match the drawing.

Field Checkpoints

Moved into spec-sheet check items, the field note’s sequence reads as below.

• Are the WD and exposure conditions (exposure time, light level) fixed on the drawing so they survive reinstallation? (a changed distance changes exposure and resolution together)
• Is a start and end timestamp recorded for each of the six segments? (to say where the delay happened)
• Does the result message carry a trigger ID (frame ID) and exposure timestamp? (to put late results back in place)
• For network output, is the RPI known and one full cycle of worst-case wait in the budget? (up to 10 ms with a 10 ms RPI)
• Are judgments made on p99 and the count of results arriving after the next trigger, not on averages? (1% or more with a 60 ms processing p99)
• Has the boundary been agreed in writing that the PLC’s read cycle and logic delay are a separate review? (the scope of vision-side responsibility)

Frequently Asked Questions

Is latency no concern with digital output?

The output itself adds almost no wait, but the five segments before it stay as they are. In this setup the 106.9 ms transfer remains, and when processing time wobbles, results slip past the next trigger just the same. That is why even with digital output there needs to be a way to pair the decision bit with a network message that carries the ID.

Does cutting the RPI to 1 ms solve it?

The output wait shrinks to 1 ms at most, but network load and device workload grow. In this setup the RPI’s share is at most 10 ms, far smaller than the 106.9 ms transfer, so shortening the cycle has a limited effect. The range of RPI settings varies by device and PLC and needs a separate review.

What if the camera clock and the vision PC clock differ?

Align the two clocks with PTP, or at least keep the camera timestamp of the exposure-end event and the PC receive time in the same record and track their offset separately. With mismatched clocks, the length of the transfer segment cannot be measured.

Glossary

• [1] Bandwidth MB/s
  The amount of data a link can carry in one second. Dividing the size of one image by it gives the transfer time. ↩
• [2] GenICam SFNC Standard Features Naming Convention
  A convention that unifies the names and behavior of machine vision camera features. Items such as the exposure-end event and timestamp can be found under the same names regardless of maker. ↩
• [3] p99 latency 99th percentile
  The value at the 99th percent mark when latencies are lined up from shortest to longest. It exposes the tail that runs late one time in 100. ↩
• [4] Digital output DO
  An electrical output that sends a signal in two states, on and off. It changes the moment the result is set, with almost no wait. ↩
• [5] RPI Requested Packet Interval
  The interval at which data is exchanged on a cyclic EtherNet/IP connection. Like a bus schedule, a ready result still waits for the next departure. ↩
• [6] IEC 61131 PLC standard series
  A series of international standards for PLCs. Part 3 covers programming languages and Part 5 covers communications. ↩
• [7] PTP IEEE 1588
  A protocol that precisely aligns the clocks of networked devices. Timestamps from different devices can be compared on one time axis only when the clocks agree. ↩
• [8] Binning binning
  Reading several neighboring pixels as one. 2×2 binning cuts the data to a quarter but doubles the length each pixel covers. ↩

References

• ODVA, Quick Start for Vendors Handbook: A Guide for EtherNet/IP Developers (PUB213R0): RPI definition (glossary), Cyclic and Change of State triggers
• EMVA, GenICam SFNC v2.7: Timestamp (3.66), Exposure End Event (15.5, with timestamp and frame ID items)
• LUCID, Multi Camera Synchronization using PTP and Scheduled Action Commands: PTP (IEEE 1588) integrated into GigE Vision 2.0, simultaneous triggering over Ethernet
• IEC 61131 (Wikipedia): Part 3 Programming languages, Part 5 Communications
• Formulas: transfer time = image size ÷ effective bandwidth, processing and output budget = trigger interval − exposure − transfer, late results ≥ parts × (1 − 0.99). Assumptions: 4,096 × 3,000 px 8-bit, 1GigE effective 115 MB/s, exposure 0.2 ms, processing typically 25 ms with a p99 of 60 ms, trigger interval 150 ms, RPI 10 ms

Related reading — Why an Average Latency Inside the Deadline Is Not Safe · Camera Interface Bandwidth Determines Resolution · Edge AI Inference Latency Is Set by the Camera Interface Before the NPU