Smart camera results to an RT controller: how to split the work

A program that drives the inspection from your desktop runs fine until the day you point it at a headless real-time (RT) controller, and the build stops with an error naming a front-panel terminal the target has never heard of. The fix is architectural, not a setting: run the inspection on the smart camera itself and exchange a small result record with the RT side over the network. This piece gives you the decision, the payload sizing arithmetic with a worked example, the recipe-switching handshake, the start-up order and the checks to run before you order hardware. It is written for controls and vision engineers wiring smart cameras into PLCs and real-time controllers, and every number in it is derived from stated assumptions.

Can a desktop inspection interface run on a headless real-time controller?

No. A desktop inspection environment builds its control and display objects for PC front panels only, so the moment the same program targets a headless real-time controller the build rejects the terminal with a 'type not supported in current target' error.

The terminal class that drives a running inspection from a desktop front panel exists only in the desktop runtime. The real-time target has no implementation for it, so the compiler refuses the whole program rather than one node — which is why the error names a front-panel terminal and not a line of your logic. No target setting changes that.

So draw the boundary by capability. The desktop tool keeps two jobs: authoring and deploying inspections, and serving the operator screen on a PC. The controller keeps motion, discrete I/O and the verdict. Everything after the next section is the plumbing across that boundary.

Where should the inspection itself run?

Run the inspection on the smart camera that shoots the part, and give the controller only results. A camera that executes its inspection on-board needs no PC-side image path at all, and one verdict plus four measurements is a few dozen bytes per cycle.

A smart camera or vision sensor acquires, processes, decides and outputs on-board. That is the property that makes the split work: pixels stay inside the camera, and the network carries outcomes.

Choose the camera by optics, resolution and interface — processing power is not a line item, because the inspection runs where the sensor is. The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm lens on a GigE interface, and the MV-SC3050XC-16M-ATN-H puts a 5 MP colour sensor with a global shutter on Fast Ethernet. The compact LS-SMC-0063 integrates its own white light, so a small part is lit and inspected with no external light controller in the cell.

Options across that range:

If the cycle gets tight later, the term to attack is exposure plus tool time, not the link.

How do results travel from the smart camera to the real-time controller?

Publish one small record to a network variable — or a socket, or an OPC UA node — and let the controller read it each cycle. On a switched 100 Mbit/s link a 32-byte record with framing occupies the wire for about 10 µs, a rounding error against a 100 ms cycle.

Two records cover the handshake: results from camera to controller, and a recipe index from controller to camera. Everything else — images, logs, statistics — belongs on a separate, on-demand channel.

Three transports carry the record, in the order your tooling will usually allow:

1. A tagged network variable. Where the camera toolchain and the real-time runtime share a variable service, the inspection writes one tag and the controller reads the same tag each cycle — the lowest-friction option when both sides support it.
2. A plain TCP socket. The camera sends a short delimited string and the controller parses it, exactly as in parsing four vision results from one socket string.
3. OPC UA. The natural pick when the controller already reads the line that way, as in reading smart camera results over OPC UA into your control system.

All three move the same few dozen bytes, so the sizing in the next section applies to whichever you pick. Where the controller needs only a verdict and a recipe bit, discrete I/O removes the network entirely — GPIO and serial input control on a smart camera covers that handshake.

How much bandwidth does one result per cycle really need?

A handful of bytes. One result per 100 ms cycle is about 10 kbit/s against a 128-byte wire budget, roughly 0.01 percent of a 100 Mbit/s port, so bandwidth never decides this architecture; the camera's exposure-plus-processing time does.

Cost a realistic record; this layout is the running example for the rest of the piece:

• cycle counter, uint32, starts at 0 — 4 bytes
• verdict, one packed byte — 1 byte
• four measurements, float32 in millimetres — 16 bytes
• timestamp in milliseconds, uint64 — 8 bytes

That totals 29 bytes; pad to 32 for alignment. Add transport and variable framing and budget 128 bytes on the wire per update — a deliberately fat envelope, so the result understates nothing.

One update is 128 × 8 = 1,024 bits. At 100 Mbit/s it occupies the wire for 1,024 ÷ 100,000,000 s ≈ 10 µs. Ten parts per second move 10 × 1,024 = 10,240 bit/s ≈ 10 kbit/s, which is 10 ÷ 100,000 ≈ 0.01 percent of the port. Scale it freely: a hundred results per second is 0.1 Mbit/s, an eight-camera cell about 0.8 Mbit/s — still under one percent of one Fast Ethernet port. The number that decides the cycle is exposure plus processing, and the frame-rate gap between acquisition and processing article shows how to measure it.

How does the controller choose which inspection the camera runs?

Write a recipe index to a variable the camera's inspection reads each cycle. The inspection software's own inspection-selection step, documented as 'Select Inspection', switches sequences between parts, so a 2-byte unsigned integer from the controller is the whole handshake.

The camera applies a new index at the start of the next cycle, never mid-inspection, so recipe changes land between parts by construction. Three rules keep the handshake predictable:

• Range-check the index on the camera: an out-of-range value holds the last recipe and sets a fault bit in the result record.
• Version the record: append new fields and reserve a few bytes, so a controller update never reinterprets old bytes.
• Treat the index like a setpoint: write it once per change, and let the cycle counter tell you which recipe produced which verdict.

Where there is no network at all, serial does the same job with one command code per recipe — see RS232 recipe selection with unique command codes. Compact vision sensors run the same handshake over their inputs:

What happens at start-up and when the link drops?

Deploy the camera side first, then let the controller wait for fresh data before it acts. Gate the first machine cycle on a ready flag, and treat three consecutive cycles without a fresh result — 300 ms at a 100 ms cycle — as a link fault, not a failed part.

Order the start-up so the camera is inspecting before the machine moves: publish the variables, deploy the inspection to the camera and set it to start on power-up, then start the controller and hold the first cycle until the ready flag and a first result arrive. The classic failure is the reverse order — parts run while the camera is still loading — and the ready-gate fix for a smart camera's missed first images is the pattern that prevents it.

For the running link, decide what absence means before it happens. Watch the cycle counter: if it stalls for three consecutive cycles, declare a link fault, stop feeding parts and retry. Recovery after hours or days of running is its own discipline; network failure recovery after a smart camera fatal error covers the watchdog-and-restart pattern.

When is a vision controller the better place for the split?

When the inspection grows past one camera, move aggregation to a vision controller. Four cameras at ten results per second each total about 41 kbit/s, and a controller with multiple LAN ports and built-in light channels absorbs cameras and strobes without a separate switch.

One camera keeps its own results, but a cell of four or six grows a coordination problem: merged verdicts, part tracking across cameras, strobe timing, the PLC conversation. That middle layer is what a vision controller is built for — camera ports on one side, discrete I/O and built-in light channels on the other, one CPU running the logic. The MV-VC3301H-128G66, for example, brings 5+ LAN ports, four built-in light channels and a Core i3 with 8 GB of memory.

Two controllers cover the range from compact cell to multi-camera line:

Bandwidth still does not bite: 4 cameras × 10 results/s × 1,024 bits ≈ 41,000 bit/s. And when the final go/no-go is assembled in the PLC rather than the controller, merging verdicts is a bitwise OR — step by step in combining camera inspection results with a bitwise OR in RSLogix 5000.

What do you check before you commit to the split?

Confirm three numbers before you order: measured processing time per inspection, machine cycle time and worst-case result size. If processing plus the 10 µs network term fits the cycle with 20 percent to spare, the split works; if not, cut tool cycles or upgrade the camera.

The checklist is short because the architecture is:

• Measured processing time. Run the production tool chain at production resolution and record the worst case across a hundred parts, not the best case from the bench.
• Cycle budget. Cycle time minus exposure, processing and the 10 µs link term must leave at least 20 percent of the cycle. Miss it and you cut tool cost or exposure, never the link.
• Loss behaviour. Pull the link with the line running and confirm it stops within three cycles and restarts clean — not that it scraps three parts.
• Recipe switch. Write an out-of-range index and confirm the camera holds the last recipe and raises the fault bit.
• Cold start. Power the whole cell from cold and confirm the camera inspects before the controller opens the gate.

When the numbers fit, the hardware choice is mechanical: pick the camera for optics and interface in the smart cameras category, check candidates in the camera finder, and choose the aggregation point among vision controllers. If one decisive number is missing from your plan, ask the applications team through the contact page before you order. The systems topic page collects the integration guides this piece links.