Configuring RS-232 Communication on a Motoman NX100

A Cognex camera connected to a Motoman NX100 can use the controller’s RS-232C serial port, but the communication path depends on the NX100 software options and Inform III functions installed. For direct vision communication, check the Visual DCI option and the LOADV/SAVEV instructions; for serial character input/output, use the Serial Input-/Output-Function instructions in the Inform list.

Does the camera use the NX100 serial-I/O path or Visual DCI?

Trace the request from the camera to the controller before selecting instructions. In a direct serial link, the camera transmits through the RS-232C cable to the NX100 COM1 port, and the job reads characters from the serial input buffer. For the NX100’s vision-system path, Visual DCI must be enabled; the controller communicates with the camera using LOADV and SAVEV. These paths are not interchangeable instruction sets.

ABB instructions such as opening COM1 or sending and receiving socket data are not a reliable guide to Motoman syntax. For character-based serial I/O, use the NX100 Inform III OPEN, INPUTB#, OUTPUT, and CLOSE instructions. If the application requires the vision-data path, confirm Visual DCI availability and use LOADV/SAVEV rather than translating socket calls literally.

Required operation	NX100 path to check	Decision
Read or write serial characters	Serial Input-/Output-Function in the Inform list	Use OPEN, INPUTB#, OUTPUT, and CLOSE.
Communicate with a vision system through the NX100 vision function	Visual DCI software option	Check that the option is enabled; use LOADV/SAVEV.

Before building the job, confirm which path the project uses and that its option is present. The next check is the physical serial connection.

Is the RS-232C link wired for the NX100 port?

Use the NX100 9-pin RS-232C port and a standard null-modem (cross-link) cable for an external system. RS-232 uses fixed-voltage signals and is more susceptible to noise and distance problems than differential signaling such as RS-485. With appropriate cabling, keep the cable at or below 15 m; use converters for longer distances.

Link item	NX100 value or requirement	Commissioning check
Controller connector	9-pin RS-232C	Identify the port and confirm the cable reaches that port.
Cable type	Null modem, cross link	Verify it is not a straight-through cable.
Supported maximum speed	19200 baud	Do not exceed the port maximum.
Recommended speed	9600 baud	Begin commissioning at 9600 baud.
Cable length	Up to 15 m with appropriate cabling	Use converters for longer runs.

After confirming connector, cable type, and length, check the camera’s serial settings against the NX100 job. A correct protocol setting cannot compensate for a wrong cable or a noisy, overlength run.

How do you open and close COM1 in Inform III?

Find the serial input/output instructions in the Inform list under OTHER. OPEN establishes the serial channel and returns a communication handle in a B- or I-variable. Use that same handle for subsequent serial instructions and CLOSE the channel after the exchange.

OPEN I000 "COM1:9600N81"
CLOSE I000

The documented OPEN format is COM<port no.>:<speed><parity><data length><stop><flow control>. COM port number 1 is listed. The parameters describe baud rate, parity, data bits, stop bits, and flow control; the listed flow-control choices are FX for XON/XOFF, FC for CTS/RTS, and FN for no flow control. The example string uses 9600 baud, no parity, 8 data bits, and 1 stop bit.

There is an important implementation caveat: the documented current version of the Serial Input-/Output-Function always uses 9600 baud, 8 data bits, 1 stop bit, no parity, and no flow control, regardless of parameters specified in OPEN. Therefore, do not infer that changing the string changes the active serial format. If the camera is configured differently, determine whether the controller’s installed function supports that format before debugging application data.

OPEN must execute before serial input/output. CLOSE releases the handle after transmission finishes. Confirm that the job reaches OPEN without an instruction or option error, and that it reaches CLOSE only after the exchange has completed.

How do you receive characters from the camera?

INPUTB# waits until a character is available in the input buffer, then stores its ASCII value in a B-variable. CHR$ converts that value to a character, and CAT$ appends the character to a string. This is a character-by-character receive path: the job must account for message length or a defined terminator so it knows when to stop collecting data.

1. Clear the destination string and initialize the character count.
2. Open COM1 and use INPUTB# with the returned handle to read a character into a B-variable.
3. Convert the ASCII value with CHR$ and append it to the destination string with CAT$.
4. Repeat until the expected length or message-ending condition is reached, then close the handle.

SET S012 ""
OPEN I000 "COM1:9600N81"
INPUTB# I000 B011
CHR$ S011 B011
CAT$ S012 S012 S011
CLOSE I000

The lines above show the receive operations; a complete job must place them in a loop and provide an exit condition appropriate to the camera’s message format. The example receive job initializes a counter and collects a bounded number of characters. Avoid treating INPUTB# as a nonblocking poll: it waits for input. If the job appears stuck there, check the camera transmit event, wiring, serial format, and whether the camera actually sends data.

For verification, send a known short text from a test host and confirm that the received string contains the same characters in the same order. Then repeat with the camera’s actual output format.

How do you transmit data without truncating the output buffer?

OUTPUT sends one character identified by a B-variable to the output buffer. The NX100 example increments a byte value and transmits values through 254. Because closing the communication channel stops processing the sending buffer, the example adds a timer before CLOSE.

SET B010 0
OPEN I000 "COM1:9600N81"
*LABEL OUTPUT#
I000 B010
INC B010
JUMP *LABEL IF B010<=254
TIMER T=0.30
CLOSE I000

Use OUTPUT for each character required by the message, and keep the channel open until queued data has had time to transmit. The documented example uses TIMER T=0.30; that delay belongs to the example’s buffer-drain sequence, not a general guarantee for every camera message length or communication condition. Validate the transmitted message at the receiving device rather than assuming that executing OUTPUT proves delivery.

At the receiving end, check that the full message arrives before the NX100 closes the channel. If it is cut short, inspect the close sequence and buffer-drain delay before changing the camera protocol.

How should you handle delimited position data?

The supplied position example receives characters with INPUTB#, accumulates them into strings, converts fields with VAL, and writes values into components of a position variable using SETE. Its test job identifies P008 as an XYZ-type position, uses a comma as the field separator, and uses carriage return (ASCII 13) as the transmission terminator. The macro job accepts three arguments: the position index, the separator character code, and the terminator character code.

Map the camera’s output format before using this approach. Confirm field order, delimiter, terminator, numeric representation, and expected decimal scaling. The sample contains logic that converts received strings to numeric values and scales them before writing position components; do not reuse that scaling without matching it to the camera’s units and output format. The listing is incomplete, so treat it as a parsing pattern rather than a complete ready-to-run job.

Test with a known position message and compare every parsed component with the transmitted values. Check that a carriage return ends the message and that the comma separates the intended fields before allowing the position to drive robot motion.

How do you prove the complete camera-to-NX100 path?

Work from physical link to application data. A useful fault split is whether the failure occurs before serial data reaches the controller, while the job is waiting for input, during parsing, or after a send is queued.

Observed symptom	Likely layer to check	First diagnostic
No characters received	Physical link or receive trigger	Check null-modem wiring, camera transmission, selected COM1 path, and baud/framing match.
Job waits at INPUTB#	No character in input buffer	Confirm the camera is transmitting and the serial path is open.
Characters arrive but string is wrong	Message boundary or parsing	Check expected length, separator, terminator, and field order.
Transmit message is incomplete	Output buffer closed too early	Keep the channel open through the send and check the delay before CLOSE.
Vision instruction path unavailable	Software option or path selection	Check Visual DCI and use LOADV/SAVEV for that path.

1. Verify the 9-pin connection, null-modem cable, and cable length.
2. Confirm the selected path: serial character I/O or Visual DCI.
3. For serial I/O, open COM1 using the installed function’s supported format; begin at 9600 baud, 8 data bits, 1 stop bit, no parity, and no flow control.
4. Send a known test message, receive it with INPUTB#, and compare the reconstructed string character by character.
5. Test the camera’s real message, validate delimiters and numeric scaling if parsing positions, and verify the complete exchange before enabling the production job.

Frequently asked questions about NX100 RS-232