Wrist camera remote snapshot trigger over TCP, no teach pendant

A wrist camera keeps one image ready at a time. Its snapshot endpoint — http://192.168.1.50:4242/current.jpg on this cell — serves whichever frame the last locate step stored, and fetching that URL never fires the sensor. To refresh the picture from your own client, a PLC, a dashboard or a bench PC, the remote trigger is not a vendor capture script and not the pendant: it is a stored, capture-only program that you start through the controller's client interface over TCP. Once its locate step finishes, the URL serves the new frame. This page walks through the program, the remote start, the fetch timing and the freshness checks, and shows where the pattern breaks. Everything here works with the pendant stowed.

What you need

• A taught wrist camera: its locate node already runs from the pendant, with calibration and part models saved.
• The controller's remote client interface: the TCP dashboard service that loads and starts stored programs, with its port in the robot's own manual.
• The snapshot endpoint: current.jpg on port 4242 of the controller address, as this camera system serves it.
• A client on the same subnet: a PLC socket block, a Python script or a bench PC that can open a TCP socket and issue an HTTP GET.

That is the whole toolchain: no SDK, no pendant app, no camera library. The hardware comes from the smart cameras and vision sensors category, and the camera finder filters sensors by resolution, interface and shutter. If you are unsure where the frames themselves live on the sensor, wrist camera image storage: where frames live and how to access them maps it out.

Store a capture-only program

On the pendant, create a new program and keep it to the capture step alone.

1. Insert the camera's locate node — the same "Cam Locate" step your production cycle uses — with its calibration and part models untouched.
2. Add nothing that moves or actuates: no motion nodes, no tool output, no set-I/O lines. If the node returns a pose, write it to a variable and let the program end there.
3. Save it under a fixed name; snapshot_capture works. That exact name goes into your client's load command, so never rename it afterwards.
4. Run it once from the pendant: confirm the arm stays still and the snapshot URL now serves a new frame.

More than one capture point means more than one such program, one per position — the same rule as teaching several snapshot positions across a large table, covered in multiple wrist camera snapshot positions to cover a large table.

Start the program from your client over TCP

1. Open a TCP socket to the controller's dashboard port and send the load command with the stored program's name. Read the reply line before anything else.
2. Send the play command and read its reply. The command words come with the controller's remote-interface documentation; they are short ASCII lines, the same messages dashboard tools and offline clients send.
3. Treat any reply that is not a success line as a fault: alarm the cell and do not fetch.
4. Wait for the program to finish. The same interface answers a program-state query, so poll until it reports idle, or apply the fixed delay from the timing section below.
5. Fetch the snapshot URL.

If the cell drives the controller through a robot driver layer, these dashboard commands are usually exposed as callable services there; use that path instead of raw sockets and keep the handshake identical.

The controller runs one program at a time, so sequence the trigger into idle windows: between cycles, on the PLC's handshake, never mid-motion. A play command aimed at a busy controller fails, and your client must treat that failure as a cycle fault, not something to retry blindly.

Beat the stale frame: time the fetch

Between the play command and the finished locate step, current.jpg still serves the previous cycle's image. A client that fetches the moment play is accepted reads an old frame that looks fresh — the classic failure of this pattern.

The readout term has a hard floor. The LS-SMC-0063 is a smart camera rated at 60 fps with a 16 mm lens. A 60 fps sensor therefore needs 1000/60 ≈ 17 ms per frame just to read out, before any exposure or matching time is added.

Swap the illustrative values for measured ones. Hash every fetched image for one shift, record the trigger-to-new-hash time, and set your delay to that number plus 50 ms of margin.

Prove the image is fresh

1. Fetch current.jpg and record its length and hash.
2. Trigger and fetch again after t_fetch: the hash must differ.
3. Put a marker in view or flip a reference part, then trigger: the new frame must show it, proving the endpoint serves the live scene rather than a cached copy.
4. Run a full shift with per-cycle hashing. Two identical hashes in a row means a stale frame slipped through — alarm on it instead of passing the part.
5. Stow or disconnect the pendant and run the whole sequence once more. The point of the pattern is that it works headless.

The GET itself is ordinary HTTP; grabbing images from an IP camera over an HTTP snapshot URL covers request headers and cache quirks. If stale results still reach the robot in production, the deeper fix is a fresh measurement per pick rather than a periodic image — vision result stale every cycle shows that handshake.

Common mistakes

• Polling the URL faster than you trigger the capture: half your frames are duplicates. Dedupe by hash.
• Sending play while the production program runs: the request fails, and retrying blindly turns a small fault into a stopped cell.
• Fetching on the play reply: this is the stale-frame race from the timing section, repeated every cycle.
• Renaming or re-teaching the capture program from a client: the load command breaks or the calibration drifts. Treat the stored program as read-only from the network.
• Writing commands without reading replies: the socket desyncs. One command, one reply line.
• Serving the snapshot outside the machine network: this endpoint answers without a login, so keep it on the cell network behind the controller, not on the office LAN.

When to trigger the camera directly instead

Program replay is the fallback for a camera with no command interface of its own. Plenty of smart cameras and vision sensors accept an ASCII trigger straight over TCP: send the command, read the result string, and skip the controller detour entirely. Triggering a smart camera over TCP with ASCII commands shows that exchange line by line, and sending commands to a smart camera over TCP in C# is the client-side code.

If the robot itself must call the shot mid-job, put the capture call inside the robot program instead of driving it remotely — triggering a USB camera capture from a robot controller over a socket covers that direction. And when locate passes in teach but fails at run time, the trigger is rarely the culprit; vision locate works in teach but fails at run time sorts out the stream-versus-snapshot causes.

If you are building the cell rather than wiring an existing one, pick a sensor whose locate step hands you a still image over the network, with the lens built in so the wrist stays short:

The controller side earns its slot when the cell grows past a single camera, bringing camera ports, built-in light channels and the headroom to run your dashboard client alongside production:

To show the same frame on a line display, show an IP camera HTTP snapshot on a remote dashboard reuses this exact endpoint.

Which route to take

• Camera with its own TCP command interface: send the ASCII trigger straight to the camera and read the result. Shortest path, no controller involvement.
• Camera without one: store the capture-only program and replay it over the dashboard port, exactly as this guide builds it.
• Robot must trigger mid-job: the capture call lives inside the robot program, not in your client.
• In every case, fetch only after the capture chain completes, and confirm each image by hash before the result drives anything.

Start from the camera finder to shortlist sensors, or the vision controllers page when the cell needs the ports. For a handshake checked against your own cycle time, the contact page reaches the applications team, and the systems topic page collects the surrounding integration patterns.