Read camera strings over RS-232 in RAPID

A vision camera can hand a robot its result as one text line over RS-232: part ID, X, Y and an angle. The robot program cannot move on that text — motion needs numbers in RAPID variables. This guide takes you from a bare serial port to a working routine: match the port settings on both ends, wire the crossover, read one terminated line with ReadStr, and split it into numbers with StrPart and StrToVal. A worked example then checks the wire time for a 22-character line at 9600 baud against a 2-second pick cycle.

What you need

• A camera with a serial (RS-232) output and its manual's serial page: baud rate, data bits, parity, stop bits and the line terminator setting
• A robot controller whose serial channel can be addressed from RAPID, plus access to its configuration editor
• A serial cable that ends in bare leads, so you can cross the camera's transmit wire to the controller's receive wire on a terminal block; camera-end cabling lives in the cables category
• A way to print strings on the teach pendant for the checks below

Check one thing before you wire anything. Current smart cameras — the smart cameras range included — stream over Ethernet or USB rather than serial; serial result lines are the territory of code readers and older cameras. If your camera has an Ethernet port, use the socket route instead: it is faster and better supported, as receiving vision data in RAPID over TCP sockets shows.

Step 1: match the port settings on both ends

1. Read the camera's serial settings: baud rate, data bits, parity, stop bits. The classic starting point is 9600 baud, 8 data bits, no parity, 1 stop bit.
2. In the controller's configuration editor, open the serial port device and set the same four values. Set flow control to none unless the camera's manual documents handshake lines — a port left waiting for a handshake signal reads nothing at all.
3. Note the exact name the configuration gives the serial channel. The quoted device string in your RAPID Open call must match it character for character.

RS-232 has no error checking at the link level. A baud or parity mismatch raises no alarm; it silently delivers wrong characters, which looks like a parsing bug. Set both ends identical before you debug anything else. Each byte also fixes the link's speed ceiling: start bit, data bits, optional parity bit, stop bit — 10 bits per byte at 8N1, 11 with parity. The worked example below builds on that arithmetic.

Step 2: wire the crossover

The camera's transmit wire goes to the controller's receive wire, its receive to the controller's transmit, and signal ground to signal ground. If the read returns nothing, swap the two signal wires: a straight-through cable fitted where a crossover belongs is the most common wiring fault in this job, and trying the swap costs nothing. Keep the run inside the guideline of about 15 m for RS-232 at modest baud rates; past that, wrong characters start appearing at random. The PLC side of the same wiring is shown in wiring an RS-232 ASCII device to a PLC serial port.

Step 3: set the terminator, then read one line

Give the camera an explicit line terminator — carriage return, or carriage return plus line feed — in its serial output settings. Vision tools often ship with the terminator disabled, and a read against a line with no end character waits forever. With a terminator set, the RAPID function ReadStr returns exactly one line per call and waits for that end character. Open, Close, ReadStr and the string functions are documented in the RAPID technical reference manual; the device string, the variable names and the line format in this module are the example's own.

MODULE SerialCameraRead
    VAR serialdev serCam;       ! serial channel handle
    VAR string sLine := "";     ! one line from the camera

    PROC ReadOneLine()
        Open "COM:", serCam;      ! quoted name must match the configured channel
        sLine := ReadStr(serCam); ! returns once the line end arrives
        TPWrite sLine;            ! print the raw line before parsing anything
        Close serCam;
    ENDPROC
ENDMODULE

Open the channel once at program start and Close it in the stop routine; that avoids a failed Open when an aborted cycle leaves the channel held. Opening per cycle also works, at a small time cost.

Step 4: split the line into numbers

Take a concrete format: the camera sends

P07,412.5,238.0,15.2

— part ID, X in mm, Y in mm, angle in degrees, comma-separated, fixed width, one decimal. Characters 1-3 are the ID, characters 5-9 are X, characters 11-15 are Y and characters 17-20 are the angle. RAPID's StrPart takes a string, a 1-based start index and a length; StrToVal converts a numeric string into the num you hand it and returns FALSE when the text is not a number.

    VAR string sField := "";
    VAR num nX := 0;       ! mm
    VAR num nY := 0;       ! mm
    VAR num nAng := 0;     ! degrees
    VAR bool bOK := FALSE;

    PROC ParsePose()
        bOK := TRUE;
        sField := StrPart(sLine, 5, 5);   ! characters 5-9:   "412.5"
        bOK := StrToVal(sField, nX) AND bOK;
        sField := StrPart(sLine, 11, 5);  ! characters 11-15: "238.0"
        bOK := StrToVal(sField, nY) AND bOK;
        sField := StrPart(sLine, 17, 4);  ! characters 17-20: "15.2"
        bOK := StrToVal(sField, nAng) AND bOK;
        IF NOT bOK THEN
            TPWrite sLine;   ! a conversion failed: inspect the raw line
        ENDIF
    ENDPROC

Every field's conversion feeds the one bOK flag, and the routine refuses good coordinates unless all three converted. That check is what stops a corrupted line from becoming a move to 0,0. Prove the conversion on the pendant with TPWrite "X = "\Num:=nX, which prints 412.5. If the camera's format is variable-width instead, find each comma's character position first and slice between commas — the same field-splitting pattern over a socket is worked through in parsing several vision values from one string on the robot.

Worked example: 22 characters at 9600 baud inside a 2-second cycle

The case: a 9600 baud, 8N1 link — the step 1 defaults — carrying one result line per pick, for a robot that picks every 2 seconds. The line is the format from step 4: P07,412.5,238.0,15.2 is 20 characters, plus carriage return and line feed, so 22 bytes travel the wire.

The rule: a serial byte costs a start bit, the data bits and the stop bit, plus parity when set. Characters per second equal the baud rate divided by bits per byte, and line time is bytes per line divided by characters per second.

The arithmetic:

• 8N1 carries 10 bits per byte: 9600 baud / 10 = 960 bytes per second.
• One line: 22 bytes / 960 bytes per second = 0.0229 s, about 23 ms of wire time.
• With parity (8E1, 11 bits per byte): 9600 / 11 = 873 bytes per second, and the same line takes 22 / 873 = 25 ms.
• Cycle budget: a 2 s cycle holds 960 × 2 = 1920 characters, so the example's 22 bytes use 23 / 2000 = 1.2% of it.

Decision: keep the characters per cycle under about 1000 — half the 1920-character ceiling, left as margin — and the serial link never gates the cycle; what you wait for is the camera's exposure and processing, not the wire. When a format grows toward 1000 characters per cycle at 9600 baud, raise the rate or move the read. At 115200 baud, 115200 / 10 = 11520 bytes per second, so the same 22-byte line costs 22 / 11520 ≈ 2 ms; a background task removes the wire time from the motion budget entirely.

Verify it worked

Run five cycles in a row before you call it done. A first cycle that parses and later ones that stall point to a stale line sitting in the receive buffer — clear the buffer between cycles so a late line from the previous part is not read as this one.

Common mistakes

• Terminator left off at the camera: the read waits forever and the cycle looks dead. Set CR or CR/LF explicitly.
• Flow control left on at the controller: the port waits for a handshake signal the camera never sends. Set none.
• Parsing without gating on the conversion result: one corrupted line becomes a move to a false position.
• One read per cycle with no buffer clear: a line that arrives late is parsed as the next part's result.
• Reading inside the motion path with no plan for silence: the robot stands still for as long as the camera stays quiet.

Next steps

Two decisions settle the job. One short result line per cycle fits RS-232 comfortably: 23 ms of wire time leaves 98.8% of a 2-second cycle for everything else, so match the settings, set the terminator, parse behind a checked StrToVal, and you are done. Long or frequent data moves the answer to Ethernet. And when the consumer is a PLC rather than the robot, sending a vision match result to a PLC output and triggering an inspection over RS-232 from a PLC cover the other end of the same wire.

For the camera side, start at the camera finder; more integration guides sit on the systems topic page. Free expert support comes with every order — contact us with the camera's serial format and your controller, and we will check the settings with you.