Send vision results to a PLC with a fixed-position RS232 telegram

A smart camera finishes an inspection in tens of milliseconds, and then the result has to cross to the PLC that runs the machine. The tempting format is a readable string such as 123.24,10.30, and the PLC starts hunting for the comma. Sooner or later a value gains a digit, arrives negative, or shows a decimal comma instead of a point, and the cut positions shift silently. This guide takes the other road: pack every value as a zero-padded integer with a fixed scale factor, at a fixed position inside a fixed-length telegram. You will design an 11-character frame, wire the DB9 link, set both serial ports to the same parameters, and read the fields on the PLC without any separator logic.

Fixed positions beat separators

A separated string makes the PLC parse: find the comma, split the pieces, convert each one. Every exception breaks that logic. A minus sign appears, a value grows a digit, or a locale prints 123,24 instead of 123.24, and the byte positions move under the shift operations. A fixed-position telegram removes the search entirely, because the position is the address: byte 1 is always the result code, bytes 2 to 6 are always the first value, and those offsets hold whether the value is 123.24 or 10.30. The frame also has a fixed length, so the receive side asks for exactly that many characters and never scans for a terminator.

That parsing pain is not unique to cameras: separator-framed scanner strings fail on serial HMI links in the same way, which is why framing serial data without headers deserves its own guide. Keep the two directions apart, too. The telegram here flows camera to PLC; when the PLC also commands the camera — load a job, move a window — that direction is the RS232 recipe-selection pattern, one unique command code per recipe.

Design the telegram: fields, widths and scale factors

Decide three things per value, once, in writing.

• Scale factor. Multiply by 10 for one decimal, by 100 for two. A ×100 scale keeps 0.01 resolution and turns every value into an integer, so the decimal separator never travels on the wire and no locale can corrupt it.
• Width. Pick the digit count from the range: five digits hold 0 to 99999, which is 0 to 999.99 at ×100. Zero-pad every value — 01030, never 1030 — so the width is truly fixed.
• Sign. Reserve one fixed sign byte, + or -, in front of any field that can go negative. The magnitude keeps its five digits.

Put a result code in byte 1 so the PLC can triage a failed inspection before converting any numbers. The layout used throughout this guide, with positions counted from 1:

Write the scale factors into the telegram definition both teams read: the camera side formats by them, the PLC side divides by them. When a field must cover a wider range later, change width and scale together on both sides in the same revision — a width change without a scale change corrupts every value by a factor of ten.

Step by step: from measurement to bytes

1. List what the PLC actually needs. A result code plus the measured values is usually enough; a failed part often needs no angles at all, just the code.
2. Fix the scale factor and width per value from its range, and reserve a sign byte where a negative is possible.
3. In the vision tool, format each numeric result with a fixed-point numeric format of two decimals (123.24), then strip the decimal point — or format straight to a zero-padded integer string if the tool offers that directly.
4. Concatenate the fields in the agreed order: result code, field A, field B. No commas, no spaces, no unit letters.
5. Send the whole string in one serial write at 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
6. Cross-wire the cable: camera transmit to PLC receive, grounds joined, shield drained at one end (next section).
7. On the PLC, receive exactly 11 characters per frame, cut at the fixed offsets, convert each field to an integer and divide by the scale factor.
8. Prove the edges before the machine runs: zero (00000), maximum (99999), a negative through the sign byte, and a failed inspection that changes only the result code.

Worked example: two angles in 11 characters

The inspection from the layout above measures two angles, resolution 0.01 degrees, range up to 999.99 degrees, part passed.

• Angle A = 123.24° → 123.24 × 100 = 12324 → five digits already → 12324
• Angle B = 10.3° → 10.3 × 100 = 1030 → zero-pad to five → 01030
• Result code = 0 (pass)

Telegram: 01232401030 — 11 bytes, always 11 bytes.

On the PLC, bytes 2–6 convert to the integer 12324, and 12324 ÷ 100.0 = 123.24°. Bytes 7–11 give 1030, and 1030 ÷ 100.0 = 10.30°. Byte 1 says pass. No search ran anywhere in that chain.

Timing at 9600 baud: one byte costs 10 bits (1 start + 8 data + 1 stop), so the frame is 11 × 10 = 110 bits and 110 ÷ 9600 = 11.5 ms on the wire. The same frame at 115200 baud takes 110 ÷ 115200 ≈ 0.95 ms. At 9600 the line clears about 87 such frames per second (960 bytes/s ÷ 11), comfortably more than one result per inspection cycle.

Wire the link: DB9 pins, crossover and length

Three conductors carry the result. On the common DB9 DTE pinout, pin 2 is receive, pin 3 is transmit and pin 5 is signal ground. Cross them over — a null-modem connection: camera pin 3 to PLC pin 2, camera pin 2 to PLC pin 3, and pin 5 to pin 5. Wire both directions even when results flow one way; a crossover cable already covers any later command traffic. Set both ports identically and leave the handshake lines alone:

The usual design guideline for RS232 is about 15 m at these baud rates; stay inside it or drop the baud rate, and drain the cable shield to chassis at one end only. For the wiring itself, a frame-grabber I/O cable with a DB9 female on one end and open leads on the other, such as the LS-CBL-0224, gives 7 m of flying leads that land directly on the PLC's terminal blocks.

Fire the camera from a discrete output, not from the serial line: the result path stays clean and the trigger keeps its own timing. Where the camera's power and trigger ride an M8 8-pin connector, an open-ended power-and-I/O cable such as the LS-CBL-0300 carries that line, 7 m and drag-chain rated. Trigger races between a PLC output and the camera's capture window have their own causes and fixes in vision format selection and PLC trigger timing.

Read it on the PLC

PLC serial ports rarely ship a ready-made block for plain ASCII strings, so you write the receive routine once — and fixed length is what keeps it small. Request exactly 11 characters per frame. Validate before converting: byte 1 must be 0 or 1, and bytes 2–11 must all be digits. On any bad frame, discard it, flush the buffer, wait for an idle gap of about three character times (roughly 3 ms at 9600 baud) and count the failure; three bad frames in a row means a cable or a formatting fault, so raise an alarm. The idle gap exists because a fixed-position link sends one frame per inspection and then rests.

When the PLC receives nothing at all, work the physical layer first: swapped pins 2 and 3, a missing ground, mismatched serial parameters — the same three causes behind a silent serial trigger, with a test for each.

When RS232 is the wrong tool

Keep the serial link for a handful of values and one result per cycle. Move to Ethernet when any of these is true: more than about 20 bytes per frame, command traffic in both directions, cycle times under 10 ms, or distance beyond the 15 m guideline. The fixed-width discipline carries over unchanged to a TCP payload; on the PLC side, a worked T_SEND and T_RCV telegram exchange shows the receive-commit pattern that pairs with it. If the camera tool speaks Modbus or OPC natively and the PLC already reads those, the same rule holds: fix the widths, fix the scale factors, put the status first. Most current smart cameras are Ethernet-first anyway — the smart cameras category filters by interface, and the camera finder narrows by resolution and shutter. Serial links are one corner of the wider vision systems guides.

Go-live checks

Tick through before the line runs:

• Both ports at 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
• One written telegram definition: field order, widths, scale factors, sign bytes, revision date.
• Edge frames tested end to end: zero, maximum, negative, fail code.
• Bad-frame counter visible where technicians actually look.
• Shield drained at one end, run inside the 15 m guideline.
• The plan for the day a field widens: both sides change in the same revision.

If the link is still on the drawing board, pick the serial and trigger cabling on the camera data and I/O cables page, and reach the applications team through the contact page when the port pairing is unclear.