Camera socket login fails: send user and password in order

You open the socket, the camera accepts the connection, and the login still fails: the reply is 'User: Password: Invalid Password', all on one line. That single line tells you most of what you need. The camera ran a login, it consumed both of your sends as the username line and the password line, and the second one was empty or wrong. This guide is for anyone driving a camera's ASCII command port from a robot or PLC. The same exchange covers smart cameras and fixed code readers alike. You get the correct send order, the terminator rule, and the tests that separate a framing fault from a credentials fault.

The exchange the login server expects

An ASCII login on a command port follows the same five steps on almost every device that uses one.

1. Connect. The server prints its login prompt — 'User:' or 'Login:' — ending in a colon and a space, not a line break.
2. You send the username as one line: text plus the terminator the device documents.
3. The server checks the username and prints 'Password:' the same way.
4. You send the password as the second line.
5. The server prints the verdict: a success banner or a failure line such as 'Invalid Password'.

Three rules follow. One send carries one line and one terminator. You read the reply before the next send. The prompts themselves are not lines — they carry no line break — so a read instruction that waits for a line break will not return them on their own.

Why the verdict arrives as one line

The prompts sit in the TCP buffer without a newline. The first line break the server sends comes at the end of the verdict. A line read therefore returns everything since the connection opened in one string: 'User: ' + 'Password: ' + 'Invalid Password' + CRLF. By the time your read returns anything, the password prompt has already been and gone.

The practical consequence: with a line-only read, you cannot synchronize the password send on seeing 'Password:'. Use a byte-level read with a short timeout if your controller has one. If it does not, send on a fixed settle time and let the verdict line tell you the outcome — the verdict is a real line, and every line-based read will return it.

The four causes, most likely first

Work down this table. Each test takes minutes and changes one thing at a time.

Cause 1 matches the observed signature exactly. Both prompts plus the failure in a single line means both sends were consumed as credentials, and the second one was empty.

Worked example: logging in to a camera at 192.168.1.124, port 30008

Inputs, as wired in the cell:

• Address 192.168.1.124, port 30008 — TCP, ASCII command service.
• Username 'admin', sent as send 1.
• Send 2: an empty string.
• Terminator after each send: bytes 13 then 10 (CR, LF).
• Waits: 1.0 s after the connection opens, then 10 ms between steps, with one line read after each send.

The rule for a line-framed server:

The arithmetic:

• Send 1 = 'admin' (5 characters) + CR + LF = 5 + 2 = 7 bytes → line 1 = 'admin'.
• Send 2 = '' (0 characters) + CR + LF = 0 + 2 = 2 bytes → line 2 = ''.
• The server matched line 1 to the account, printed 'Password: ', then read line 2 as the password. An empty password fails, so it printed 'Invalid Password'.
• Your first line read returned the first complete line of the session — 'User: ' + 'Password: ' + 'Invalid Password' + CRLF — which is why the whole exchange arrived at once.

Result: the framing worked. Both lines were delivered, line 1 was accepted, and line 2 carried nothing to validate.

Decision: put the account's real password into send 2 and read the verdict line after it. If the verdict is still 'Invalid' with the correct password, walk down the cause table — terminator first, then timing, then account rights. If the account legitimately has no password and the service still demands one, that is a device configuration task, not a robot program task.

The fix, step by step

1. Open the connection to the camera's command port and give the service about 1 s to settle before the first send.
2. Send the username plus the terminator the device's socket documentation names — CR, LF, or CR then LF. Pick it from the manual, not from habit.
3. Read with a timeout. An empty or partial return is normal here: the password prompt carries no line break.
4. Send the password plus the same terminator. Exact case, no trailing spaces, no quotes around it.
5. Read the verdict line. It ends in a line break, so a line read returns it: a success banner means the socket is yours; 'Invalid' means audit the two sends before touching the timing.
6. Log every send and every read with raw bytes and timestamps. The log turns a two-hour mystery into a two-minute read.
7. Keep one send helper that appends the terminator and one read helper with the timeout — never inline the bytes at each call site.

If the device does not appear to hear the first send at all, that is a different fault; the fix is in the socket handshake guide.

Prove the device side from a PC first

Before editing the program, reproduce the login by hand from a PC terminal utility: open the same IP and port, type the username, press Enter, type the password, press Enter, and watch the verdict. If the manual login succeeds, the device, the account and the terminator are all correct, and the fault is in the program's framing or timing. If it fails there too, no socket code will fix it — the account needs correcting on the device.

That five-minute test halves the fault domain. The same discipline carries you past login into commands: triggering a smart camera over TCP with ASCII commands uses the identical send-read pattern.

When the usual advice is wrong

• The port never prompts and answers commands straight away: it has no login on that service, and credentials become two malformed command lines. Delete the login and send your first real command.
• The reply prints as symbols: the port speaks a binary or packed protocol, not ASCII lines. A login exchange does not apply; follow the device's protocol route instead.
• The verdict never arrives and the socket stalls: check the service's idle timeout — some servers drop a session that logs in but then sends nothing.

Keep it from failing on the next camera

A short list before you commission the next camera:

• Read the device's socket protocol page before writing code: port, login yes or no, prompt text, terminator.
• Keep the credentials in one configuration place that the login routine reads, so a password change touches one file.
• Test every new model from a terminal client before wiring the program.
• Halt the job on a failed verdict instead of retrying in a loop.
• Command-code conventions for multi-job devices are in the RS232 recipe selection guide.

More socket-level fixes, from buffering to recipes, sit on the systems topic page.

Wire it into the cell

Once the login passes, the same socket carries triggers and results. If you are choosing hardware for this kind of link, network-connected readers and cameras are the starting point, and the camera finder filters them by interface and resolution:

When the client should be a cell-mounted controller rather than the robot itself, a vision controller runs the socket client and the inspection job together:

From there the same connection reports positions and grades — reading X, Y, angle and score over a robot socket shows the result format end to end.

If you want a second pair of eyes on the exchange, send us the camera model and the exact reply line through the contact page and we will walk the sequence with you.