Vision camera to PLC serial link: why ARD reads no data

Two cameras pass results to each other over Ethernet all day, the inspection fires on every part, the result string builds correctly — and the PLC serial port sits enabled over an empty buffer. If you are wiring a smart camera's RS-232 output to a PLC serial port for the first time, that combination almost always comes down to four faults: the camera's serial write never fired, the cable lacks the transmit-receive crossover, the port settings disagree, or the read asks for more characters than the message holds. Work them in that order, and a terminal program plus one character-count instruction close the link the same afternoon.

Why does an exact-count read stay enabled but never complete?

An exact-count read completes only when the receive buffer already holds exactly the number of characters you asked for, so request 16, receive 12, and the instruction sits there enabled forever with its done bit off.

The read arms on the false-to-true transition of its rung and then waits. Two characters of a requested 16 produce no done bit, no fault and no message — just an enabled instruction doing its job. That silence is why an 'enabled but receiving nothing' symptom is almost never a defect in the read instruction itself: debug the bytes, not the rung. Bytes fail to arrive in four places — the send trigger, the cable crossover, the port settings and the count — and the sections below work through them in that order.

The mnemonics come from the ASCII instruction set of the PLC family in the original case: ARD for the exact-count read, ARL for the read-to-terminator, ACB for the buffer character count. Every PLC brand ships the same three ideas under other names, so map them once and the rest of this guide applies as written.

Is the camera actually sending anything?

Usually nothing: a serial-write step inside a camera job does not run just because the inspection ran — it needs its own trigger, and with no trigger assigned the camera never puts a single byte on the wire.

A case with exactly this shape had the inspection running on a manual trigger, the serial write configured in the job, port settings matched — and not one byte on the wire. The fix was to assign a trigger to the WriteSerial step itself, through a job-state condition (CellState). The setting hides because it sits on the write step rather than on the job's global soft trigger, so the inspection can pass parts all day while the serial output never executes.

Whatever the camera software, look for the same thing: a trigger or execution condition attached to the serial output element. Two arrangements work:

1. One pulse, two actions. The same camera input that fires the inspection also fires the serial write, so a result is always in the telegram when the write runs.
2. Send on done. An inspection-done output fires the write, so nothing is sent for a part the tools rejected.

For the first arrangement you wire a PLC output or photoeye into a camera input; the open-end trigger cable wiring for optocoupler trigger and strobe guide covers that input side. Then respect the ordering rule that bites everyone: put characters in the buffer before you arm the read — pulse the write first, then enable the read in the same or the following scan.

How do I test the camera's serial output without the PLC?

Take the PLC out of the circuit: connect the camera's serial leads to a laptop running a terminal program at the agreed baud rate, fire the inspection, and either characters appear or they do not.

Set the terminal program to the settings you intend to run — 9600, 8, none, 1 to start — and fire one part:

• Characters appear. The camera job, its send trigger and its port settings are all proven. The fault is downstream: cable or PLC side.
• Nothing appears. Stay on the camera. Confirm the write step executed (most jobs expose a step status flag), that its trigger is assigned, and that the port selected in the software is the physical port you wired.

Then reverse the test: connect the PC to the PLC's serial port instead. If the PLC echoes characters back and accepts what you type, its port and settings are proven too, and whatever remains is the cable between the two devices. This is the same drill used when wiring a barcode scanner to an HMI serial port, and it settles more serial disputes than any amount of guesswork.

Does the cable cross transmit and receive?

Almost always yes, because both ends of the link present as DTE: the camera's transmit lead must land on the PLC's receive lead and vice versa, with signal ground common — the crossover a null modem cable gives you.

RS-232 is a point-to-point link between two DTE devices, and each end transmits on one pin and listens on another. Wire transmit to transmit and the two streams pass each other in the cable unheard, which looks identical to a dead link. The crossover is exactly what a null modem arrangement defines: TX to RX, RX to TX, signal ground to signal ground. Buy a crossed cable or cross the leads on your own breakout — either works, and which numbered pin carries serial on your camera is stated in its I/O manual. Look it up once, label the leads, and every future camera of that family wires the same way.

Length has a number too. The RS-232 standard's capacitive limit works out to about 15 m at 20 kbit/s; at 9600 baud that 15 m is a routine panel-to-panel run, and beyond it you are spending noise margin you may not have.

A smart camera's power and I/O leave the housing through keyed circular connectors, and the breakout cable converts those pins into bare leads for a terminal block. For the SC6000 series that breakout is a 17-pin M12 to open leads, 7 m, static duty.

Cameras that break out through an M8 connector take the 8-core equivalent: male M8 to eight open leads, 7 m, drag-chain rated for a moving cable track.

Do the port settings need to match on both ends?

Yes, all five of them: baud rate, data bits, parity, stop bits and flow control must match at both ends, and the usual working default is 9600 baud, 8 data bits, no parity, 1 stop bit, handshaking off.

Copy the five values from the camera software's serial settings page to the PLC serial channel's configuration screen, and set the channel to user ASCII mode so the port serves your program rather than the programming network. A mismatch in any value produces one of two symptoms: silence, or characters in the buffer that read as garbage. The garbage case is actually good news — the link works and only the framing is wrong — and the garbage characters on a PLC serial link article walks that diagnosis end to end.

Baud is simply an agreement: 9600 is the common default, 19200 and 38400 sit in the middle, 115200 is the fast end, and any value works as long as both ends use it. Pick one, write it on the electrical drawing, and leave parity at none and handshaking off unless both manuals demand otherwise.

How many characters does one result message take?

Count the telegram, because that count is your read length: a result like 125.43,88.10,1 plus carriage return and line feed is 16 characters, and an exact-count read set to anything else never completes.

Worked out character by character:

• 125.43 is 6 characters; the first comma makes 7.
• 88.10 brings the total to 12; the second comma to 13.
• The status digit 1 makes 14; CR and LF close the telegram at 16 characters.

Timing comes from the same arithmetic. With 8N1 framing every character occupies 10 bit times — 1 start, 8 data, 1 stop:

At 9600 baud that is 9600 ÷ 10 = 960 characters per second, so the 16-character telegram takes 16 ÷ 960 = 16.7 ms to arrive. Set the exact-count read to 16 and it completes within a scan or two of the last character landing in the buffer. Set it to 20 and the same telegram strands 4 characters short of completion forever — and if the camera ends the message with CR only, the true count is 15, which is exactly why the buffer check in the next section takes the number from the wire instead of from your notebook.

How do I check the receive buffer before reading from it?

Arm a character-count instruction — the ACB type on processors that carry one — and watch its live count: zero means the camera or cable is still wrong, a partial count means your read length is wrong, and a full count means the read logic is.

The count instruction reads the port's control structure without disturbing the buffer, and the number it shows routes the fault at a glance:

• Count 0 while the camera should be sending. The send never fired (trigger section above) or the cable lacks the crossover.
• Count parked below your read length. The telegram is shorter than the count requested: a count of 15 against a read of 16 is the CR-only telegram from the last section, caught red-handed.
• Count reaching the read length but no completion. The read is not re-arming. These instructions fire on a false-to-true transition of the rung, so a rung held true reads once and then sits; momentary the rung or re-arm it each cycle.
• Count climbing past one telegram. The read never drains the buffer, so part two's telegram is being read as the tail of part one's. Drain after every read, and clear the buffer whenever a cycle aborts.

One guard belongs on every read: a timeout, so a dead link fails a part instead of hanging the machine. The abort pattern for a serial read that receives nothing shows the timeout-and-abort structure.

Should the read stop at a terminator instead of a fixed count?

Yes for variable-length results: a read-to-terminator instruction — the ARL type — returns everything up to the first line feed or up to its maximum count, so an 8-character result and a 16-character result both complete the same rung.

The trade is one discipline for another: instead of an exact count, both ends must agree on a terminator character, and the classic mismatch is a camera that ends results with carriage return (CR) while the read watches for line feed (LF). State the terminator deliberately — LF, CR, or CR followed by LF — and put it in the camera's telegram as its own character.

When you control both ends, the deterministic pair is a fixed-width telegram plus an exact-count read: no terminator to disagree about, and the count proves the telegram at the same time. The fixed-position RS232 telegram for sending vision results to a PLC shows how to lay one out, and if the same serial link must later switch the camera between products, reserve one unique command code per recipe so the PLC can send recipe numbers down the same pair of wires.

What is the whole checklist, and when is Ethernet the better link?

Work the link in a fixed order — trigger, terminal test, cable, port settings, buffer count, read type — and reach for Ethernet whenever results per second or cable distance outrun what RS-232 at 9600 baud delivers.

Camera side

1. Assign a trigger to the serial-write step — a job-state condition or a camera input — because an untriggered write never executes.
2. Fire one inspection and confirm the write step ran, not just the inspection tools.
3. Send once to a PC terminal: characters visible means the camera side is closed.

Cable

4. Cross TX and RX and tie the signal grounds; between two DTE ends that is a null modem arrangement.
5. Keep the run inside about 15 m at these speeds; use shielded cable and ground the shield at one end.

PLC side

6. Match baud rate, data bits, parity, stop bits and channel mode, with handshaking off.
7. Count one real telegram and set the exact-count read to it, or switch to a terminator read.
8. Watch the buffer count live: 0, partial and full each point at a different section above.
9. Add a read timeout and drain the buffer each cycle, so one bad part cannot poison the next.

Serial earns its keep at one result per part: 960 characters per second at 9600 baud moves a 16-character telegram about 60 times per second, and 115200 baud multiplies that by 12. When you need more results per second, a longer reach or several consumers at once, move the data to Ethernet — either the PLC's own Ethernet port or a serial-to-Ethernet interface module in front of it. Where the program can open raw TCP sockets, results arrive as a plain stream you parse yourself, the pattern shown in receiving camera data over TCP sockets in CoDeSys; where it is register-based, the register handshake for sending vision coordinates to a PLC is the established pattern.

If you are selecting hardware for the link rather than repairing one, the smart cameras finder filters by interface and resolution, the cables page holds the breakout leads, and the configurator started at the extras step assembles camera, cable and accessories in one pass. More serial and PLC integration patterns sit on the systems topic page, and if you send us the camera model and the PLC port details, we will help you spec the cable and the settings — the contact page reaches the applications team.