RS232 serial control of a vision controller: get the first reply

You wired the cable to the pinout, the port settings look right, and the controller still sits silent while you type commands at it. That is the classic first contact with a legacy vision controller's RS232 command port. The cause list is short: two items cover most cases, a terminal emulator sending the wrong line ending, and a controller that is not in the mode which accepts remote serial commands. This guide commits you to a settings set, gives the ten-second loopback test that clears or convicts the cable, provides a first-reply program with the timing arithmetic behind its timeout, and marks the point at which Ethernet is the better link. It applies to any controller that exposes an RS232 command port, whatever the badge on the front says.

Why does a vision controller ignore RS232 commands that the terminal sends?

Two causes cover most silent controllers: the terminal emulator sends a line feed after every carriage return, so the command arrives as CR+LF instead of the CR, 0x0D, the protocol expects, or the controller is still in run or monitor mode instead of the mode that accepts remote serial commands.

Check the mode first because it costs nothing. Many controllers of this generation keep a small switch on the back that selects between the local run panel and the remote communication port. Others keep the same choice as a setting stored inside the running project. With the switch on run, the serial receiver is logically disconnected and no byte you send gets parsed.

Then look at what the terminal actually puts on the wire. A command line on these ports ends with a single carriage return, 0x0D. A terminal transmitting CR+LF appends a line feed, and parsers read that as a second, empty command line: sometimes the real command still executes, sometimes the pair is rejected outright. Set the terminal to CR only before changing anything else.

And discount the screen as evidence. With local echo on, the emulator prints your own keystrokes, so a busy display proves nothing about the controller.

Which serial port settings does the link need?

Copy the port table from the controller's communication chapter exactly. Where that page is missing, start at 19200 baud, 8 data bits, no parity, one stop bit and no flow control, the combination most controllers of this generation accept, and change one parameter at a time.

The values must match on both ends byte for byte, and they have to be the controller's values, not the ones a terminal program opens with by habit. Most of this generation leaves the factory at 9600 baud, 8N1, which is safe but slow. The 19200 rate is what a small program on a homemade lead typically holds clean, and it is where this guide starts.

Two traps hide around the table. If the port is configured in two places, the driver's default in the operating system and the opening call in your program, an omitted parameter in the program can fall back to the driver's value, so keep the two identical. And unless the controller's command chapter lists hardware handshaking, flow control stays off everywhere.

How do you prove the cable and pins are right before blaming the software?

Short pins 2 and 3 of a DE-9 plug, fit it at the controller end of your cable, and type a character: whatever comes back proves the PC port, the cable and its TX/RX crossing are good, which takes the wiring off the suspect list in one test.

A DE-9 connector on a PC port is DTE: pin 2 is RXD, pin 3 is TXD, pin 5 is signal ground. A controller's serial port is usually DTE as well, so the cable crosses the data pair, pin 2 to pin 3 at the far end, pin 3 to pin 2, pin 5 straight through. Take the crossing from the controller's pinout page rather than from habit, because a minority wire the port as DCE and reverse it.

To build the lead, start from a moulded connector with bare leads: the LS-CBL-0224 is a DB9 female-to-open cable, 7 m long, so you solder straight to the printed pinout, keep the run short and land the shield at one end only. Ready-made serial and I/O leads sit in the cables range, and the wiring discipline is identical to wiring a barcode scanner's RS232 ASCII string to a PLC port: transmit to receive, grounds tied, shield single-ended.

Then run the ten-second test:

1. Short pins 2 and 3 inside a spare DE-9 plug, which becomes your loopback plug.
2. Fit the plug at the far end of the cable, with the cable attached to the PC.
3. Open the port with the settings from the table above and type one character.
4. Read what returns.

A returning character proves both conductors run end to end and the PC side transmits; the remaining suspects are the mode, the settings and the controller. Nothing returning means fix the cable first, because no protocol change will help. Keep the homemade run at about 15 m or less at this baud rate; the standard's load-capacitance budget sets that ceiling.

Why does a terminal emulator mangle the command line?

Terminal emulators exist for typing at modems, not for feeding protocols: their transmit setting usually appends a line feed, 0x0A, after your carriage return, and that extra byte makes the controller read a command it does not recognise, if it answers at all.

Emulator defaults serve a human at a keyboard: a transmit line ending of CR+LF, a display that hides control bytes, and a local echo that looks exactly like a device reply. Every one of those defaults lies to a protocol session, and the last one is the dangerous lie, because it convinces you the controller answered when only your own keystrokes came back.

Four settings make an emulator usable for one-off tests: transmit line ending CR only, local echo off so everything on screen arrived from the wire, hex display for the control bytes, and the port values from the table above. Even then, keep the emulator as a watching tool and let a program do the talking, because a program sends exactly the bytes you specify and logs the reply. The same silent-serial pattern bites barcode scanners triggered over serial: the reader scans locally but the host hears nothing until framing and termination match.

How do you send the first command from your own code?

Open the port with the settings table above, write the command as bytes with a CR appended, wait longer than the reply takes, and read what lands: at 19200 baud a 20-byte reply needs 10.4 ms, so a 500 ms timeout gives a 48-fold margin.

import serial
import time

port = serial.Serial(
    port='COM3',                    # your adapter's port name
    baudrate=19200,                 # both ends, per the table above
    bytesize=serial.EIGHTBITS,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    timeout=0.5,                    # seconds
)

port.reset_input_buffer()
port.write(b'T1\r')                 # example command word; use your protocol's own
port.close()

Every library name above is pyserial's published API; the T1 command word and COM3 are placeholders for your protocol's own values.

The test that proves each stage: with the loopback plug still fitted, read the bytes after the write and they come back as the command plus CR, three bytes, which clears your code, the driver and the cable in one run. Move the plug to the controller's lead and the reply becomes the echo or acknowledgement the command chapter defines. An empty result sends you back to the mode and wiring checks in the sections above.

One read trap: a line-read call that waits for a line feed never sees one on a CR-terminated reply, so it burns its full timeout and returns empty. Read a fixed byte count or the bytes already waiting in the input buffer, as the snippet's buffer check implies.

If the port arrives through a USB adapter, expect 1-10 ms of extra latency, invisible to command traffic and disqualifying for hard trigger timing. When a runtime names the adapter differently than the desktop does, mapping a USB serial port to a COM port inside a PLC runtime covers the fix.

The port is open and nothing answers — what is left to check?

Work the remaining causes in order of probability: the mode switch or remote setting first, then settings saved but not transferred to the running program, then handshake lines asserted by the PC, then a baud mismatch between driver default and program, and only then the transceiver itself.

1. Mode switch or remote setting. Move the controller to its remote or communication state per the command chapter and power-cycle; if the panel still shows run mode, the receiver is logically dead and nothing downstream matters.
2. Settings saved but not transferred. On many controllers the communication values live inside the inspection project, and saving on the PC is not the same as writing them to controller memory. Reboot the controller and confirm the values survived.
3. Handshake lines. Set flow control to none at both ends; a program that raises DTR and RTS on open can hold a controller that treats them as enable inputs.
4. Baud mismatch, including defaults. Step both ends through 9600, 19200 and 38400 together; those three cover the rates this generation ships with.
5. TX and RX crossed backwards. A cable that passes the loopback can still be reversed for the controller; swapping pins 2 and 3 at one end is a two-minute test on a homemade lead.
6. Port hardware. When every check above passes and an oscilloscope or a second PC shows clean bytes arriving, the serial board is the suspect and the maker's service channel takes over.

The root cause is not unique to serial hardware. A GigE camera that ignores its external trigger almost always has the acquisition mode left in continuous, which is the same device-not-accepting state on a newer interface. Prevention is short: land the final settings in the project before the panel closes, label the lead with its pinout, and keep the loopback plug in the toolbox.

When is Ethernet the better link than RS232?

A serial line at 19200 baud carries only 1,920 bytes per second, enough for a trigger word and hopeless for results, program lists or anything image-sized. Keep it for a legacy controller that already owns its cell. Move to Ethernet when the PC must switch programs automatically, read results per cycle, or serve several devices at once.

Ethernet changes the economics: one link handles commands, results and program management, and a controller with several LAN ports serves several cameras without new wiring. The command pattern survives intact, because triggering a smart camera over TCP with ASCII commands is the serial session moved to a socket, and starting an inspection automatically from a custom program shows the hand-off from your own code. Where a PLC only needs go or no-go, controlling smart camera routines from GPIO or serial input stays the leanest option.

The parts differ by case. For a PC that runs vision over Ethernet, the MV-VC2140-128G40-1T vision controller brings 3-4 LAN ports, 2 USB 3 ports and four built-in light channels on an Intel N97 with 8 GB of memory, a 128 GB SSD and a 1 TB hard drive. For a station that drops the PC entirely, the LS-SMC-0063 smart camera inspects 1.6 MP at 60 fps through a built-in 16 mm lens and white light, and takes its trigger over the GigE port. The wider vision controllers and smart cameras ranges cover other resolutions and port counts.

For the run across the cell, choose a locking RJ45 cable: the 15 m LS-CBL-0117 uses locking studs, so vibration cannot walk a plain latch tab out of its jack.

The decision, case by case:

• Legacy controller, working process, PC only selects programs: stay on RS232, fix the line ending and the mode, run 19200 baud, and stop there.
• New station, or program changes every batch: vision controller on Ethernet, commands as TCP/ASCII, one LAN port per camera plus a spare.
• No PC wanted in the cell: smart camera with on-board inspection, triggered by the PLC over the network or an input line.

Checks before ordering:

• Count LAN ports as one per camera plus one spare for engineering access.
• Match built-in light channels to the number of lights the cell will switch.
• If the cameras should take power over the data cable, pick a controller model from the vision controllers range that lists PoE camera ports.
• Confirm each camera's mount and connector before ordering lenses.

The configurator steps through controller, cameras, lights and cabling in order, and the systems topic page collects the rest of the trigger and integration fixes. If the controller still says nothing after the checks above, tell us what the wire shows — the reply bytes, or their absence, usually name the fault.