Robot socket send string not received: fix the handshake

A robot sends the login string, socket_send_string returns True, and the same command typed into the camera's telnet portal works fine — yet the command is not received on the vision side. That combination almost always means the bytes left the robot but never formed a complete, terminated line in the order the camera's ASCII command server expects. This page is for integrators wiring a robot controller to a vision sensor over raw TCP. You will find why True proves less than it looks, which terminator byte (LF is 10, CR is 13) releases the camera's input buffer, how to copy the login prompt order from a terminal session, and how to prove the fix on the wire before the next production run.

Why does socket_send_string return True when the camera receives nothing?

socket_send_string returns True when the robot's TCP stack accepts the bytes. The URScript manual states the function expects no response, so the return value says nothing about whether the camera's command server parsed, accepted or even received a complete line.

You know the network path works, because you read the camera's login banner over the same socket. The failure sits one layer up. The camera's command server waits for a complete line before it acts, and an unterminated string is not a command — it is a partial line in a buffer.

The URScript manual defines the call as socket_send_string(str, socket_name='socket_0') and states that it expects no response. A clean True is the normal result of every send, delivered or discarded. The camera's reply string, not the return value, is your delivery confirmation.

Why does the same command work over telnet and fail from the robot?

Telnet appends an end-of-line terminator every time you press Enter. socket_send_string transmits exactly the characters in the string and nothing more. So the portal test sends a complete line while the robot leaves an unterminated "admin" sitting in the camera's input buffer.

The terminal supplied the one byte your program omits, so nothing in the portal test could catch the difference. The server holds partial input indefinitely because it cannot know that "admin" is a whole user name. The login never advances and no command executes.

The receive direction still works, because the server pushes its banner and prompts the moment you connect. Server-to-robot and robot-to-server traffic fail independently. That asymmetry is the signature of a handshake problem rather than a network problem.

What terminator does the camera's ASCII server expect?

Send the terminator the camera's communications settings define: industrial ASCII command servers end a command with LF (ASCII 10), CR+LF (ASCII 13 + 10) or NUL (ASCII 0), and a common factory default on native-mode servers is CR+LF or NUL.

Set the terminator on the camera side first, because that is the setting you control outright. Where the sensor's communication settings offer a choice, pick LF and end every robot string with the escape: socket_send_string("admin\n"). Sending the terminator as its own call, socket_send_string("\n"), puts identical bytes on the wire — TCP is a byte stream, and the server never sees where one send stopped and the next began.

Where the camera ships locked to CR+LF, the program must emit both bytes, and the listener test in the next section confirms within one cycle whether it does. One missing byte is the whole difference between a completed login and a silent buffer.

How do you copy the login sequence into the robot program?

Step through one telnet session with a notepad and write down every prompt and reply in order — banner, user prompt, user name, password prompt, password, ready marker. Then reproduce that exact order in the program with a terminated send and a read between each step.

The reads between sends are not decoration. A prompt-driven server can ignore input typed ahead of its prompt, and each read tells the program when a stage actually completed. Give every read a 1.0 second timeout so a silent camera stops the sequence cleanly instead of desynchronising the login.

# Function names are URScript; IP, port, prompts and command text are illustrative examples.
socket_open("192.168.1.50", 5000)      # camera IP and ASCII command port from its settings
socket_read()                          # banner, then the user prompt
socket_send_string("admin\n")          # user name, terminated
socket_read()                          # password prompt
socket_send_string("admin\n")          # password, terminated
socket_read()                          # ready marker
socket_send_string("TRIG 1\n")         # inspection command, terminated
reply = socket_read(timeout=1.0)       # result string, capped at 1 s
socket_close()

Your real values come from the camera's communication settings page and from the telnet transcript you wrote down. Send the trigger command only after the ready marker arrives — a command fired into a half-finished login is the second most common cause of a True with no effect. On a healthy plant LAN the whole login finishes well under 500 ms, so the reads cost you almost nothing.

How do you prove what the robot puts on the wire?

Point the robot program at a terminal test server on your PC — a netcat-style listener bound to the same port. It prints every byte the robot sends, so one cycle shows whether a terminator follows the user name or the login stops mid-way.

Run the listener, run the program, and read the transcript. "admin" with nothing after it means the terminator never left the robot. "admin" followed by CR and LF, or by LF alone, means the login reached the camera and the fault moves to the camera-side checks below.

The same listener doubles as a stand-in camera: type the replies the camera would send while you tune the robot side, and the robot program cannot tell the difference. A packet capture gives the same evidence, but the listener needs no switch port and answers in one cycle.

What if the string arrives and the inspection still does not run?

When the listener proves a complete, terminated command and the camera still does not inspect, the fault is camera-side: the wrong job is loaded, the trigger source points at hardware input instead of the TCP command, or the result string is not routed back to the socket.

Test it in one move: run the identical command from the telnet portal with the production job loaded. If the portal triggers the inspection, the camera is configured and your robot string differs in bytes, so go back to the listener. If the portal also fails, fix the camera configuration before touching the robot program again.

The reply path has its own failure modes — framing, parsing, stale results — covered in smart camera OCR string output over TCP and in parsing four vision results from one socket string. For the trigger sequence itself, the ASCII command trigger guide walks the full send-and-read cycle.

When is the socket connection itself the fault?

Almost never once the banner arrived, but three conditions still mimic a dead send: a second client occupying a single-connection server, a socket left closed by a fault or program restart, and a subnet error that blocks only the robot's direction of the conversation.

If the robot never receives the banner either, the fault is connection-level: IP and subnet first, then the port number, then the single-client limit. The no-response fix for the robot socket send loop covers that path, and re-handshaking at cycle start restores the session after a robot fault drops it mid-production.

Which vision hardware takes ASCII commands over TCP?

The same handshake works with any vision sensor or smart camera that exposes an ASCII command server over TCP; the smart camera and vision sensor lines in our catalog do, and PC-based vision software behaves identically when it runs on a vision controller on the robot's subnet.

For a mounted sensor on a standard Ethernet line, the MV-SC3050XC-16M-ATN-H is a 5 MP colour vision sensor with a global shutter and a 1/1.45" sensor.

When the inspection logic needs a PC-class job rather than an on-sensor program, the robot sends the same ASCII handshake to a vision controller; the MV-VC2140-128G40-1T runs an Intel N-series processor with 8 GB of memory, 3-4 LAN ports and 4 built-in channels of light output.

Browse both lines in the smart cameras and vision sensors category and the vision controllers category, or filter interface and resolution directly in the camera finder.

How do you keep the handshake solid after the next change?

Freeze the working sequence into one logged template — open, read prompt, terminated send, read, trigger, read result, close on exit. Every future camera swap or firmware update then becomes a compare-against-transcript exercise instead of a new debugging session.

• One terminator convention for the whole program, copied from the camera's settings page, so the bug cannot sneak back in.
• A 1.0 second timeout on every read, so a silent camera stops the cycle instead of hanging the robot.
• Logging of every send and read to pendant variables or the screen, so a desynchronised login is visible in one cycle.
• The socket closed on program exit and a fresh handshake at cycle start, so a fault never leaves a half-logged-in session behind.
• The telnet transcript stored next to the program, so the next engineer diffs prompt order instead of rediscovering it.

More send and receive patterns, robot side and PC side, live on the systems topic page. If you are choosing the camera side of the link, the vision system configurator pairs the sensor with lens and lighting for the field you inspect — and when a handshake still refuses to close, send the transcript to the applications team through the contact page.