Trigger a vision inspection over RS-232 from a PLC

Your PLC owns the line, the fixtures and the parts; the vision PC owns the camera, the light and the verdict. The cheapest way to join them is three wires. The PLC sends a short ASCII command over RS-232, the PC waits on the port, runs the inspection, and answers with one result line the PLC can parse. Done right, the link costs a few milliseconds per cycle and never jams. Done wrong, it reads half commands, fires on stale triggers, or stops the station the day the PC hiccups. This guide is for controls and vision engineers bringing up that first serial trigger link. It gives the wiring, the port settings, the message frame, the wait loop on the vision side, the timing arithmetic at 9600 baud, and the timeout rules that turn a lost reply into a rejected part instead of a stopped line.

One command in, one line out

The decision, before any code: one ASCII command in, one ASCII line out, framed by a line feed, at 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. The PLC writes its command, starts a timeout, and waits for either the reply or the timeout. The vision PC never polls a file or a screen; it sits in a read that returns on the line feed, runs the inspection, writes the reply, and loops back to the read. Three conductors carry the whole contract: transmit, receive and signal ground.

A discrete trigger wire is faster, but it carries one bit. Serial carries the verdict and the numbers back on the same three wires, which is why it stays the retrofit staple when the PLC has a spare communication port and no spare I/O slots.

What you need

• A PLC serial port your program may use for ASCII frames. Programming ports stay reserved for the programming software; the PLC manual names which port accepts application frames.
• A vision PC with a built-in serial port. A USB-to-serial adapter works; a built-in port removes one driver variable from the bench.
• A shielded serial cable with transmit and receive crossed, and a way to land bare wires on the PLC terminal strip.
• Vision software that supports a read returning on a termination character. If yours only reads fixed byte counts, enable the termination setting anyway; it is the piece that makes frames whole.
• The settings below, agreed by both teams before anyone writes code.

The two timeouts are starting values, not physics. The PLC timeout must exceed the longest inspection you will ever run on the link, and the vision read timeout only sets how often an idle PC loops.

Wire the cable and set both ends

1. Pick the application port on the PLC, not the programming port. The programming software keeps its port busy, and a link that worked at the desk fights you at the cabinet.
2. Cross the pair: the PLC transmit lands on the PC receive and the other way round, and the two signal grounds join. Take pin numbers from the port drawings in the two manuals; D-sub 9 assignments are not universal between devices.
3. Keep the run shielded and clear of motor and mains cabling. The original RS-232 specification was written around 15 m at 20 kbit/s, and 9600 baud sits well inside that envelope, but every metre through a tray of drive cables is noise you paid for.
4. Set both ends to 9600, 8, none, 1, no flow control. A rate or parity mismatch shows up as repeating garbage characters, never as silence.
5. Test the cable before any application code: fit a loopback at the PC end, receive tied to transmit, and confirm your read loop sees its own bytes; then move the loopback to the PLC end.
6. Watch raw bytes on the PC with a plain read that prints everything. You want TRIG and one line feed, exactly once per part.

For the PC end of a link you land on terminals, a DB9F-to-open lead keeps the connector moulded and the wires screwable:

The 7 m lead reaches most cabinet-to-bench runs, and swapping a crossed pair later is a two-minute job on a terminal strip.

Agree the message frame before anyone writes code

Command side: a short uppercase ASCII code plus the line feed, TRIG and LF for the default inspection. If the line runs several products, give each recipe its own code instead of sending parameters in the frame; one command code per recipe is exactly what the RS-232 vision recipe selection guide uses to keep switching simple. Reply side: a fixed field order, comma separated, verdict first — PASS,12.5 or FAIL,13.1, then LF. ASCII only in both directions: no binary, no checksums on the first pass. A damaged frame announces itself as a parse failure or a timeout, and the timeout rules below already know what to do with that.

The line feed is the frame boundary, not the byte count. A read waiting for a fixed number of bytes returns whatever has arrived when the count or a timeout expires, so it cuts frames in half or glues two together; a read that breaks on the LF returns complete frames every time. That is the same framing discipline barcode integrations live by — prefix and suffix framing for scanner input walks it from the scanner side. Parse the reply by splitting on the commas and comparing the verdict field, the way PLC ladder logic compares barcode strings does.

The wait loop on the vision side

One loop owns the port from power-up to shutdown. Configure the read once, with the termination character enabled and a 5000 ms read timeout, and let it block. A termination read returns within a byte time of the feed arriving; polling the buffer with a sleep between checks adds latency and lets frames queue behind each other. After each handled command, flush the input buffer so an echo or a late duplicate cannot fire the next part.

port       = the PC serial port          # the one the PLC lands on
settings   = 9600 baud, 8-N-1, no flow   # both ends
timeout_ms = 5000                        # read timeout; the idle loop period
loop forever:
    frame = read until LF               # string; blocks up to timeout_ms
    flush the input buffer              # drop echoes and late bytes
    if frame is empty:
        log the idle link once, continue
    if frame matches a known command:
        verdict, value = run the inspection
        write verdict + "," + value + LF
    else:
        write ERR,0 + LF                # answer every frame; silence means a dead link

Prove the loop before the PLC ever connects: fire 100 frames from a loopback plug and count 100 complete replies with an empty buffer after each one. An unknown code earns an error line, not silence. If your inspection also starts from camera software triggers, the same discipline of a ready check, a deadline and a defined fail state is what the camera trigger ready timeout diagnosis applies on the camera side.

Worked example: timing a 9600 baud trigger and reply against a 1 s cycle

The inputs, with their sources:

• Link settings: 9600 baud, 8 data bits, no parity, 1 stop bit — the defaults in the table above.
• Command frame: TRIG plus LF = 5 bytes — the command frame agreed earlier in this guide.
• Reply frame: PASS,12.5 plus LF = 10 bytes — the reply format agreed earlier.
• Inspection time: 150 ms — an illustrative stand-in; put a millisecond timer around your own run, because this number moves the total.
• Cycle budget: 1000 ms — a station inspecting one part per second.

The rule, in words: with 8-N-1, every byte travels as 1 start bit, 8 data bits and 1 stop bit, which is 10 bit times per byte at any rate.

The arithmetic: per byte, 10 / 9600 = 1.042 ms. Command leg: 5 bytes × 1.042 ms = 5.2 ms. Reply leg: 10 bytes × 1.042 ms = 10.4 ms. Both wire legs: 5.2 + 10.4 = 15.6 ms. Full cycle: 15.6 + 150 = 165.6 ms of the 1000 ms budget, so the wire carries 15.6 / 1000 = 1.6 % of the cycle.

The decision: hold the wire legs under 5 % of the cycle and the link will never be the bottleneck. At 1.6 %, 9600 baud stands, and the 150 ms inspection sets the pace. The link stops being free when replies grow. A 100-byte results line costs 100 × 1.042 = 104 ms, which is 10.4 % of this budget and over the line; the fix is rate, not code. At 19.2 kbaud the same line costs 100 × 0.521 = 52 ms, right on the 5 % threshold, and at 115.2 kbaud it is 100 × 0.0868 = 8.7 ms, under 1 %. Change both ends together: a rate raised on one side alone reads as garbage on the other.

Timeouts and the busy rule

PLC side: start the 2000 ms timeout the moment the command leaves, and do not release the part until the reply or the timeout lands. Reply parsed, dispose the part by its verdict. Timeout, the link failed rather than the part: route it to the reject or re-check chute and count link faults separately from part faults. A triggered part with no disposition is how one dead PC stops a line.

Vision side: answer every frame you receive, even a failed inspection, so a PLC timeout means exactly one thing — nothing arrived. Silence is reserved for a dead link. Keep one command in flight: the PLC sends the next TRIG only after the reply or the timeout, which makes the exchange self-clearing and needs no handshake wires.

When something breaks, separate the two failure shapes. A timeout with nothing received points at wiring, a dead port or the programming-port mistake. A parse failure with bytes received points at settings or framing; repeating garbage characters mean a baud or parity mismatch, and the fix in garbage characters from a scanner over the PLC serial link applies unchanged. A silent reader on a live port is the other classic, and the silent serial trigger diagnosis walks it frame by frame.

When serial is the wrong answer

The on-device option removes the PC and the protocol together. A smart camera runs the inspection where the pixels land: the PLC fires a trigger input and reads the verdict over the camera's own interface, with no frame format to defend. The smart cameras range is built around that idea, inspection on the device with no PC. For stations that want PC-class processing without a PC in the loop, an X86-platform camera keeps it on the device:

The LS-SMC-0017 pairs an 8.8 MP sensor and a C-mount with its X86 platform, so heavy in-camera processing and a simple handshake to the PLC stay in one housing. Control vision routines from GPIO or serial input shows the camera-side handshake, and camera trigger lines as digital outputs helps when the cabinet is short of spare wires.

Keep the strobe on the vision side

The PLC triggers the inspection; it should not fire the flash. A serial command is a 10 ms-class event, far too slow to place a flash inside an exposure. Let the camera strobe output fire the light so the timing chain stays entirely on the vision side, and use a serial link to the light controllers only to set intensity, strobe width and channel on a part change. Camera strobe output timing works through the flash-to-exposure alignment. The controllers below put an RS-232 port on the light line:

The LS-CTL-0487 drives 2 channels at up to 240 W over its RS-232 port; the LS-CTL-0070 covers 4 channels at 200 W for multi-light stations. Either takes its settings over the serial port, so the vision side owns the light without another PLC card.

Bring-up checks and the classic failures

1. Fire TRIG from the PLC 100 times. The PC log shows 100 complete frames, and the input buffer is empty after each one.
2. Pull the PLC transmit wire. The PC sees an idle link and keeps looping; the PLC sees its 2000 ms timeout and routes the part. Both sides land in defined fail states, never in a hang.
3. Send an unknown code. The PC answers with the error line, so bad commands count separately from lost frames.
4. Time 100 full cycles with a millisecond timer. The mean minus your measured inspection time should sit near the 15.6 ms the arithmetic predicts for a 15-byte exchange.
5. Run an hour with motors starting and ambient lights switching. Zero glued frames, zero unexplained timeouts, one reply per command.

Then the failures, in the order you meet them: the programming port instead of the application port; rate or parity mismatched on one end; transmit and receive not crossed; fixed byte-count reads instead of termination reads; an input buffer never flushed; no PLC timeout; hardware flow control left on with no handshake wires attached. Each produces a signature — the desk link that dies in the cabinet, garbage, silence, half frames, stale triggers, a held part, a port that never sends — and the sections above give the test for each.

Where the link fits in the system

Once the serial contract holds, the rest is standard hardware thinking. The cables range covers the camera, trigger and I/O runs around the link, and the configurator walks the trigger chain end to end at the trigger step. More triggering and serial guides sit on the systems topic page, with everything indexed in the guides hub. If a link still drops frames after the checks above, the contact page reaches the applications team; send both settings tables and a log of the raw bytes, and the fault usually falls out of the first screen.