Smart camera to PLC over TCP: trigger and pass/fail

A smart camera already runs the inspection on the device; what remains is plumbing: the PLC must start each cycle and receive a pass/fail verdict. One TCP connection does both jobs. The camera listens on a fixed port, the PLC connects as the client, sends a short trigger string, and reads back a fixed-length ASCII result — no gateway PC, no fieldbus profile, no middleware. This guide is for controls and vision engineers wiring that first link on a real line. You get the roles, the string format, a latency budget with the arithmetic shown, and the live checks that prove the link before the line runs.

Make the camera listen and the PLC connect

Give the smart camera the server role and the PLC the client role. The camera keeps one fixed IP address and one listening port, so the PLC program holds exactly three constants: IP address, port, timeout. Reverse the roles and the camera has to find the PLC again after every link loss, and a listener hidden inside the inspection tool is harder to supervise from the ladder logic. A camera-side socket server is built for this pattern: listen once, accept one client, answer one telegram per cycle.

The same pattern runs our barcode-reader links: barcode reader as TCP server: wire your PLC as the client shows the wiring from the reader side, and TCP client or listener: match your network barcode reader to your host explains when a moving listener earns its keep. For a single camera-to-PLC link, it usually does not.

Write the trigger and result strings before you open the IDE

Decide the bytes on paper first; every timeout and every ladder branch hangs off them. Keep both strings fixed length, so the PLC reads one block per cycle and never scans for a terminator.

The trigger is 4 bytes: the ASCII characters TRG followed by a line feed. The camera starts exactly one inspection on receipt.

The result is 16 bytes, defined position by position:

The trailing CR and LF exist for people: a terminal tool on the bench shows clean lines. The counter exists for the PLC: it must increment by exactly 1 per inspection, so a repeated or skipped value is a protocol fault rather than a silent pass. Eight digits wrap at 99,999,999 cycles; at 2 parts per second that is 99,999,999 ÷ 2 = 49,999,999.5 s, about 579 days between wraps — longer than most lines run between code changes.

Reserve one defect code for the busy case. This example uses 999: a trigger that arrives while the previous inspection is still running gets F, 999 back, and the ladder counts it as a pacing fault, not as a product reject.

Fix the addresses, the port and the connection policy

Put the camera and the PLC on their own subnet and pin the addresses. Example values: camera 192.168.10.20, PLC 192.168.10.10, subnet mask 255.255.255.0. Keep the link off the office network; a dedicated port pair or a VLAN keeps broadcast noise out and makes any firewall rule one line long. Where a plant network sits in between, vision controller to PLC: TCP ports and firewall rules covers the port planning.

Choose the camera's listening port above 1024, clear of everything else on the machine network; 50000 works in this example. Write it into the PLC program's constant list, not into a comment.

Keep the connection open across cycles. TCP is full duplex, so trigger and verdict share one socket. Connect-per-cycle is simpler to recover but adds the three-packet handshake to every part — well under a millisecond on an isolated switched network, plus one more place for a reset to land. With a persistent socket, the PLC reconnects only after a fault.

What you need on the bench

• A smart camera whose software includes a TCP server or raw-socket tool, with the inspection running on the device.
• A PLC with TCP client instructions: open, send, receive, close. Every mid-range controller family provides them.
• A bench PC with a terminal TCP tool, so you can play either side alone.
• A small switch and two Ethernet cables.

For a color verdict on moving parts, the MV-SC3050XC-16M-ATN-H pairs a 5 MP color global-shutter sensor with a Fast Ethernet interface and an M12 mount.

Three catalog smart cameras that fit the server pattern at different resolutions:

The LS-SMC-0063 runs 1.6 MP on-device inspection at 60 fps over GigE. The MV-SC5060XM-08M-WBN steps up to 6 MP mono on a 1/2.4" sensor with an 8 mm lens; it is a rolling-shutter camera, so either keep part motion modest or freeze it with a short exposure and a strobed light.

Wire it up, in order

1. Pin the addresses. Set the camera to 192.168.10.20 and the PLC to 192.168.10.10 with mask 255.255.255.0, then ping each from the other side.
2. Build the inspection job on the camera. Make verdict and cycle counter available as job outputs, and set the job to produce one result per inspection.
3. Start the camera's TCP server on port 50000, set for one client at a time and one reply per received telegram, and map the 4-byte trigger to the job trigger input.
4. Map the reply to the 16-byte format from the table above: verdict in byte 1, counter incremented once per cycle, defect code 999 reserved for busy.
5. Test the camera alone from the bench PC. Connect to 192.168.10.20:50000, send TRG plus a line feed, and confirm exactly 16 bytes return with the counter reading 00000001. Trigger with no part in view and note the fail code; that becomes your no-part verdict.
6. Add the TCP client in the PLC. Connect to 192.168.10.20:50000 with a 2 s connect timeout, send the trigger once per cycle, then receive exactly 16 bytes with the receive timeout from the next section.
7. Branch in the ladder: P sets the pass bit; F with code 999 counts a pacing fault; F with any other code rejects with that code; a counter that is not the previous value plus 1 sets a protocol-fault bit and fails the part. Storing ASCII barcode strings in PLC memory: bytes, words and clears shows how to hold and clear the receive buffer without leftovers, and PLC ladder logic to compare barcode strings and count three reads shows the string-compare pattern.
8. For the socket calls themselves, a PLC socket-messaging walkthrough for camera trigger and result shows the open-send-receive-close sequence instruction by instruction, and a PLC-to-smart-camera TCP setup walkthrough demonstrates both ends configured end to end.

Set the receive timeout from a latency budget

The receive timeout must clear the worst honest reply, not the average one. Budget four terms and multiply by four:

Worst case: 16.7 + 2 + 40 + 1 = 59.7 ms, call it 60 ms. Four times that is 240 ms, so set the receive timeout to 250 ms and keep the connect timeout separately at 2 s. At a 500 ms cycle the link consumes at most 60 ÷ 500 = 12% of the cycle. Log trigger-to-reply for a thousand cycles on day one; if the worst case sits below half the timeout, 250 ms stays.

Error handling that survives a shift

Treat a timeout as a fail. The part leaves as a reject and the event lands in a link-fault counter, separate from the defect counter, so an operator sees link faults and defects apart at a glance. The rule is short: no telegram, no pass.

Check the counter. Each reply must be the previous counter plus 1; a repeat, a gap or a jump back to 1 mid-shift sets the protocol-fault bit and fails the part.

Reconnect on a backoff: close the socket, wait 1 s, then 2 s, then 5 s, and stay at 5 s until the link returns. If the reconnect hangs on a refusal, the camera control port connection refused checklist separates listener-side from firewall-side causes quickly. Physical link loss on a switched machine network shows up in milliseconds at the Ethernet layer, so the realistic faults recover without touching TCP keepalive.

Pace the triggers above the worst reply time. A trigger that arrives while the camera is busy loses a cycle: the camera answers F, 999, and the PLC counts it. If that counter climbs at line rate, the line is outrunning the inspection; the fix is pacing or a faster job, not a longer timeout.

When plain TCP is not the right tool

Sub-millisecond reject timing. Drive the camera from a discrete hardware trigger and bring the verdict back on a discrete output, with the socket kept for diagnostics. An I/O handshake updates in single-digit milliseconds — PLC scan, camera input and output delays included — which beats the tens-of-milliseconds socket budget when the reject solenoid must fire inside a fixed window.

More than one camera. Let a vision controller own the camera links and hand the PLC one verdict. The MV-VC2140-128G40-1T has 3-4 LAN ports and 4 built-in light channels, so a single box holds several camera links and the lighting drive:

Longer strings. OCR text and barcodes do not fit 16 bytes; smart camera OCR string output over TCP: how to send it covers variable-length text with terminators.

Pictures in the HMI. A TCP telegram carries verdicts, not frames; smart camera image in a PLC HMI: what actually displays live explains what a PLC screen can and cannot show.

No Ethernet client in the PLC. A controller without socket instructions can still read a fixed-position telegram on a serial port; send vision results to a PLC with a fixed-position RS232 telegram is the same framing idea on older wires.

Checks before you go live

• Addresses pinned and DHCP off on both ends; a lease that expires mid-shift moves the listener.
• Ping both ways, then connect from the bench PC as a client before the PLC ever connects.
• A thousand-cycle timing log at full line rate, with the worst trigger-to-reply below half the 250 ms timeout.
• A forced-fail part through each defect code, with every ladder branch observed, including code 999 and the protocol-fault bit.
• The link-loss drill at full rate: pull the cable mid-run and confirm rejects counted, backoff reconnect, and a counter that continues with no repeat.
• A power-cycle of camera and PLC, with both ends reconnecting on their own.

More integration notes at this level sit on the vision systems topic page.

Pick the camera, then keep the protocol boring

The camera choice is optical first: field of view and resolution decide the model, and the socket link rides on whatever you pick. The smart camera finder filters by resolution, interface and shutter; the system configurator assembles camera, lens, light and controller as one checked set; and the quote page turns a parts list into a formal quote. Start with the field of view, write the two strings on paper, and the TCP link will be the least dramatic part of your line.