Edge inference camera integration for factory automation

The AI model runs on the camera, the image never leaves the device, and the inspection still has to kick a part off the conveyor at the right moment. That gap — a result inside an edge inference camera, an action on the line — is an integration problem, and it has a short answer: treat the camera as an autonomous vision sensor and publish its result through the lowest tier your line already supports. This guide is for controls and manufacturing engineers wiring an on-camera AI inspection into a PLC, a serial host or a plant network. You will choose the hand-off tier, size the sensor, and budget trigger-to-result time with the arithmetic shown.

The decision: pick the lowest tier your line already supports

An edge inference camera carries the model, runs it on every trigger and publishes a result. Nothing in the wiring depends on what the model detects; it depends on what the downstream system can consume. Three tiers cover essentially every line:

Pick the lowest tier that satisfies the data requirement, not the newest one. A reject arm needs a contact, a quality database needs the class, an MES needs a queryable record — those are different jobs. Most stations end up running two tiers at once: I/O for the reject, REST for the record.

Where the model lives and how updates roll out across camera and host is a separate problem — plan edge vision inference deployment across camera and host covers that side. If the PLC half of the link is new territory, getting started with machine vision for PLC programmers walks the basics first.

What the camera publishes

The payload is small and predictable whatever the application: a class or detection result, its probability, and the time inference took. Some applications add the trigger counter or a reference to the stored image. That size is what picks your tier. A pass/fail flag is one bit, a class with probability is a short text line, a traceable record is a few hundred bytes. The three tiers carry the same information in three different envelopes, so the choice is about the consumer, never about the model.

Tier 1: digital I/O for pass, fail and reject

Digital I/O never fails to integrate. An optocoupled trigger input starts the exposure and two or three outputs report state. Wire the minimum set: trigger in, busy out, result out. Hold the result pulse for at least twice the PLC scan time so no scan misses it — at a 10 ms scan, set 25-50 ms.

Two settings do the engineering. First, a watchdog in the PLC: a timer at about twice the worst-case result time, reset on every result pulse, so a hung camera produces NOK instead of silence. Second, a trigger interlock: no retrigger while busy, or you will inspect parts under the light pulse from the previous cycle.

Strobe the light on the same trigger as the camera. Light controllers exist for exactly this hand-off, and strobing keeps the flash the same part after part: the LS-CTL-0070 is a 4-channel, 200 W digital control box with RS-232 and strobe output on board.

Cabling and handshake details — which wire carries what, and why the first frame after a trigger can come out dark — are covered in do I need a camera GPIO cable for image acquisition and first camera frame dark: exposure settling or light timing.

Tier 2: serial result strings

Serial sits between a contact and a network: the camera formats a result line and pushes it after every inspection, and any host that reads characters can take it. The only arithmetic is framing. At 9,600 baud with 8 data bits, no parity and one stop bit, every character costs 10 bits on the wire.

A frame such as P,0.97\n — result flag, probability, terminator — is 7 characters: 7 × 10 = 70 bits, and 70 / 9,600 = 7.3 ms. At 115,200 baud the same line takes 70 / 115,200 = 0.6 ms. Either way the link adds single milliseconds to the budget.

Keep frames fixed width with a fixed terminator so the host parses in one instruction. The host-side pattern — comparing strings and counting reads in ladder logic — is worked through in PLC ladder logic to compare barcode strings and count three reads.

Tier 3: REST and JSON over the plant network

The REST tier makes the camera a network resource: a host sends an HTTP GET and the camera answers with the last result as JSON. Authentication is standard HTTP Basic, so set a strong credential before the camera joins the plant network, and no vendor SDK is needed on the client side. An illustrative payload:

{
  "state": "OK",
  "class": "scratch",
  "probability": 0.97,
  "inferencetime_ms": 45
}

Your camera's REST reference gives the real resource paths and field names; the shape is always result, probability, timing. On a switched plant LAN a GET typically round-trips in 5-20 ms, so the poll interval dominates latency: poll at half the takt or faster to catch every result, and expect between zero and one full poll period of extra delay, half that on average. For the PC side of such a link, smart camera LabVIEW integration: use inspection results as data shows the consume-results-as-data pattern, and the same shape works from Python or C#.

A five-minute pull test

Prove the path from a laptop before you write any PLC code:

curl -s --user user:password http://192.168.1.50/results/last

The address and resource path here are placeholders for what your camera's manual prints. Then the same query in Python, with every value declared:

import base64, http.client, json

host = "192.168.1.50"    # str: camera address on the plant LAN
path = "/results/last"   # str: results resource from the camera's REST reference
user = "inspection"      # str: account created in the camera's user management
secret = "change-before-commissioning"  # str: its password

token = base64.b64encode(f"{user}:{secret}".encode()).decode()
conn = http.client.HTTPConnection(host, timeout=2)
conn.request("GET", path, headers={"Authorization": "Basic " + token})
record = json.loads(conn.getresponse().read())
conn.close()
print(record["class"], record["probability"])

The test that proves it: run the query with a known good part in front of the lens, then with a known defect. The class field must flip and match what the camera's own preview shows. That single check confirms address, authentication, resource path and result source together — and if the laptop works while the host does not, the fault is in the network, not the camera.

Size the sensor before you wire anything

No tier rescues an undersampled image, so run the pixel arithmetic first. Take an 80 mm wide part with 20% margin: the field of view is 96 mm. The smallest defect that must be found is 0.3 mm across, and four pixels per feature is the working minimum for a classifier. The pixel size then has to be 0.3 / 4 = 0.075 mm, and the FOV needs 96 / 0.075 = 1,280 pixels across.

Typical 5 MP arrays run about 2,592 × 1,944, so the long side gives 2,592 / 1,280 ≈ 2× margin, and the 1,944 px short side covers a 96 × 0.75 = 72 mm tall FOV where only 960 px are needed. Choose mono over color unless color is itself the feature: mono sensors put every pixel into one channel.

Both cameras below clear that arithmetic with margin: a 5 MP color vision sensor with a global shutter on Fast Ethernet, and a 6 MP mono smart camera with an 8 mm lens on GigE.

For a stopped part either shutter type works; for parts moving past the lens, keep the global-shutter model or cut the exposure per the blur rule below. If the inspection needs custom runtime code instead of a fixed application, pick an X86 platform: the LS-SMC-0017 carries an 8.8 MP global-shutter sensor behind a C-mount.

The trigger-to-result timing budget

One formula decides whether a tier fits the line:

Worked example at 60 parts per minute: 60,000 ms / 60 = 1,000 ms of takt per part.

• t_trigger 1 ms plus t_exposure 2 ms, a strobe flash
• t_inference 45 ms — the term you measure on your own parts; it dominates every other
• t_link: an I/O pulse about 1 ms, a 7-character serial frame 7.3 ms, REST between 0 and 220 ms at a 200 ms poll
• t_host: one PLC scan, 10 ms

Totals: I/O ≈ 1 + 2 + 45 + 1 + 10 = 59 ms, serial ≈ 65 ms, REST ≈ 58-278 ms. Against the 1,000 ms takt that is 5.9%, 6.5% and up to 27.8%. Every tier fits at 1,000 ms. The line where comfort ends is nearer 300 ms: below it, take polling REST off the reject path and keep I/O or pushed serial there. And even when REST carries the records, the reject stays on a contact — a deterministic input beats a JSON field at reject time.

Blur lives in the same budget. At a 200 mm/s line speed, a 2 ms exposure smears 200 × 0.002 = 0.4 mm, which is 0.4 / 0.075 ≈ 5 pixels at the sizing above — so stop the part or cut the exposure. Exposure time vs shutter speed for moving-part inspection has the method, and if acquisition then outruns processing, acquisition faster than processing: fix the frame rate gap is the follow-up.

When one camera is not the whole answer

Stations grow: a second camera for the back face, a third for the label, and the PLC link turns into a cabinet full of cables. A vision controller consolidates acquisition, lighting outputs and the plant link in one fanless box, and the category includes models with PoE camera ports, so one cable per camera carries power and image data. The MV-VC2140-128G40-1T carries 3-4 LAN ports, 2 USB 3 ports, 4 built-in light channels and 8 GB of memory on an Intel N-series processor.

At that point the PLC integration itself — handshake, result registers, alarm handling — becomes its own small project, and machine vision PLC integration on the production line walks it station by station.

Checks before you commit

• Prove the data path from a laptop. One curl query confirms address, authentication and result format before any PLC code exists.
• Measure inference on your parts, not the demo set. Log 50 cycles and put the worst time in the budget, not the average.
• Turn every auto mode off. Auto exposure and auto gain re-adapt between parts and drift the image; camera image brightness drifts over time: turn every auto mode off explains why and what to set instead.
• Set the PLC watchdog at twice the measured worst case and route its trip to NOK plus your normal stop logic, so a camera fault is a rejected part, never a silent pass.
• Pin firmware and model versions, and keep the previous model on hand for rollback; swapping a neural network model on edge vision hardware covers the procedure.
• Match every result to a part with the trigger counter or timestamp, so a network delay cannot shift a result onto the wrong part; asynchronous vision result frame matching with timestamps is the pattern.

When the usual answer is wrong

An inference camera classifies; it does not measure. Dimensional checks at 0.01 mm need a calibrated, PC-based setup — see machine vision deep learning setup: choosing CPU or GPU for the host side. Below a 100 ms takt, on-camera inference rarely fits; run classical tools over I/O or move the model to a host, and object detection without a GPU: CPU inference for inspection shows the CPU route. If every image must be archived per part, REST image pulls add real bandwidth — plan storage the way barcode inspection image archiving to cloud storage lays it out.

That is also the honest boundary in the other direction. When the task is pass/fail classification at a takt of a second or more, the edge inference camera is the right shape: no PC, no frame grabber, three wires or one GET per part. Pick the smart cameras that cover the field of view you computed, start the configurator at the controller step for the multi-camera version, or bring your takt time and part drawings to the contact page and we will size the station with you.