Why a UR wrist camera preview freezes during program run

You have a UR robot with a wrist camera, and the pendant is showing you less than it used to. Program stopped: the Installation tab streams the camera, more or less real time. Program running with camLocate or Visual Offset nodes: the preview updates only when one of those nodes grabs a frame, so you see the code plate and little else. That is the designed behavior of the camera driver, not a fault, and no pendant setting reverses it. This guide covers why the controller works this way, how to place a checkpoint node so the preview shows the exact moment you care about, how to tell that apart from a failing wrist cable, and how to size an independent camera that streams through the whole cycle.

Why does the wrist camera preview freeze during the program run?

Because the pendant preview is fed by the camera driver, and while a program with camera nodes runs, the driver produces a frame only when a camLocate or Visual Offset node takes its snapshot — every refresh you see is one of those grabs.

The script layer behind those nodes is snapshot-based. The controller's script directory shows the pattern: the picture is taken first, through camera.takeSnapshot(), and the image analysis runs on that picture afterwards. There is no continuous stream running underneath for the pendant to tap, so between grabs the display holds the last frame — which is why the code plate stays on screen long after the robot has moved on. One Visual Offset node per cycle therefore gives you exactly one preview frame per cycle, at the instant that node fired. The behavior is the same on the UR5 and the UR5e. The same snapshot-versus-stream split explains a cousin symptom: vision locate that works in teach but fails at run time.

Why is the Installation tab live until the program starts?

With no camera node executing, nothing in the program owns the camera, so the Installation tab polls it continuously and the preview runs near real time — that is the state you set the cell up in.

Ownership is the difference. A stopped program releases the camera, and the tab pulls frames as fast as it can. A running program that contains camera nodes takes exclusive use of them: the nodes' grabs become the only source of frames, and the tab can only display what arrives. A program with no camera node at all can leave the live view available even while it runs — the freeze arrives with the first camera node in the program tree. So the fastest way back to a live image is to stop the program; the tab picks the camera up again on its own.

Does the Save Image node refresh the preview?

No — the Save Image node writes the current picture to a file; it neither starts a stream nor forces a new grab, so the preview stays frozen between camera-node executions.

What the node does give you is an archive. Read it as photograph what the camera last captured, not as open the live view. In a checkpoint set-up it earns its place: put one beside each camera node and every part leaves a picture on the controller, taken at the exact moment you chose. Pull the files off after the run and evaluate them at leisure on any PC.

How do you see the camera at a chosen point in the run?

Put a camera node at that point: each execution of a camLocate or Visual Offset node grabs exactly one frame and the pendant shows that frame, so the node doubles as your shutter button.

1. Drive the robot to the waypoint where you want to look — the pose where the code plate fills the view.
2. Insert a Visual Offset node there. It needs the code plate in view and nothing taught about the part.
3. Run the program. The preview refreshes at that waypoint on every cycle.
4. Duplicate the node at other waypoints to inspect other moments; each copy costs one snapshot plus its analysis time in the cycle.

Planning more than one viewpoint? Multiple wrist camera snapshot positions to cover a large table works through the geometry of covering more area with a single camera. And if the checkpoint frames look coarser than you expected, troubleshooting wrist camera resolution on UR robots covers what governs image detail on these cameras.

Can you use the camera without teaching objects to camLocate?

Yes — a Visual Offset node needs only its code plate in the field of view; it measures where the plate sits and shifts your waypoints to match, so nothing about the part itself has to be taught.

Your instinct is right that camLocate's object teaching is a detour when you only want to correct position drift. Three routes avoid it:

• Visual offsets only. The plate does the locating. Applying camera XY offsets in a robot program with unit conversion shows how the measured offset reaches the motion.
• Marker locating in your own code. ArUco marker pick and place, from marker pose to grasp is the full pattern with a marker you print yourself.
• Teach something that is not the part. Locating an empty tray slot by teaching the cavity as a part turns the fixture into the model and leaves the product out of it.

Before you commit to any route, the feasibility checklist for vision-locating a part tells you whether the part will hold up under locate at all.

When is a frozen preview a real failure?

When the preview stays dead even though a camera node just executed, or when the Installation tab shows nothing with no program running — that is a camera, cable or connector problem, and the wrist connector is the first suspect.

The wrist camera feeds through the tool connector, and its cable flexes with every wrist rotation, so that connection is the part that wears. The signature of a worn path is motion dependence: blank frames, torn frames, or a preview that drops out at particular wrist angles and returns at others. The design behavior described above is not motion dependent — it refreshes exactly when nodes fire, every time. Test with the program stopped: open the Installation tab, jog the wrist slowly through its range, and watch the view. Reseat the tool connector first; if dropouts track wrist angle, replace the cable with a high-flex type from the camera cables range. If you watch a camera in your own software instead of the pendant, a freeze there has a different cause tree — start with channel checks for a preview that freezes after the first frame.

How do you get a live view through the whole cycle?

Mount a second, independent camera that streams continuously — a small GigE smart camera on a bracket, watching the fixture — because the pendant cannot be forced to stream while camera nodes run.

The companion camera runs on its own link to your PC or HMI, so its frame rate has nothing to do with the program state. Your viewer pulls frames whenever it wants: grabbing images from an IP camera over an HTTP snapshot URL is one way in, and running the fetch off the main thread keeps that viewer responsive while it does. The camera finder filters by interface and resolution, and the fixed-mount pick from our smart cameras is this one:

The LS-SMC-0063 is a 1.6 MP smart camera with a 16 mm lens and white polarized light, running at 60 fps over GigE.

Three sensors worth comparing for the job:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Take a mono 1.6 MP sensor for watching plates and poses; take the color 5 MP sensor when parts must be told apart by appearance. The wrist camera itself can also step outside the pendant: integrators have driven it from Python through the controller's real-time data exchange (RTDE) interface, with no pendant in the loop at all. When your code owns the grabs, it decides when frames are taken and where they go, and the preview question never arises.

Mount the companion fixed, outside the arm's reach, on one of the camera brackets from the accessories range. Where its cable has to move with the arm, drag-chain rating is the spec that matters:

The LS-CBL-0199 is a 3 m GigE camera cable, high-flex, with screw locks, rated for drag-chain use.

What lens and working distance does a watch-the-fixture camera need?

Cover a 300 mm wide fixture from about 575 mm away with a 12 mm lens on a 1/2-inch-class sensor — the arithmetic below shows the sum, and the calculator repeats it with your own numbers.

Assume the region you want to watch is 300 × 225 mm (the fixture plate with margin) and take a 1/2-inch-class sensor at 6.4 × 4.8 mm with 1440 × 1080 pixels, so each pixel is 6.4 mm ÷ 1440 = 4.4 µm.

1. Magnification: m = 6.4 mm ÷ 300 mm = 0.0213.
2. Lens from a first guess of 500 mm working distance: f = 500 mm × 0.0213 ÷ 1.0213 = 10.4 mm, so the nearest stock lens is 12 mm.
3. Working distance that lens needs: WD = 12 mm × 1.0213 ÷ 0.0213 = 575 mm.
4. Short-side coverage: 4.8 mm ÷ 0.0213 = 225 mm, matching the target region.
5. Pixel footprint: 300 mm ÷ 1440 px = 0.21 mm per pixel, so a 2 mm feature spans about 9.6 px — plainly visible.
6. Motion: at 60 fps a frame arrives every 16.7 ms; an arm moving 250 mm/s crosses 250 × 0.0167 ≈ 4.2 mm between frames. To hold blur at or under 0.5 mm, keep exposure at or under 0.5 ÷ 250 = 2 ms.
7. Focus margin: depth of field ≈ 2 × N × c × (1 + m) ÷ m². At f/4 with c = 8.8 µm (two pixels), that is 2 × 4 × 0.0088 × 1.0213 ÷ 0.000454 ≈ 160 mm, an estimate that doubles to about 320 mm at f/8 — fixture height swings of ±50 mm stay sharp at f/4.

Run your own region and sensor through the same sum:

What should you check before changing anything?

Work the five checks in order: live view with the program stopped, one checkpoint node in a minimal program, a Save Image beside it, the wrist connector and cable, and only then new hardware.

• Installation tab, program stopped. A live view confirms camera and wrist connection are healthy. A dead view here means the connection comes first, and nothing else in this guide applies yet.
• One Visual Offset node in a minimal program. The preview refreshes once per pass at that node: the design rule, and your checkpoint pattern, confirmed in a single run.
• Save Image beside the checkpoint. One file per part lands on the controller, so the run can be evaluated offline afterwards.
• Wrist connector and cable. Reseat the tool connector, jog the wrist slowly, and watch for motion-dependent dropouts; replace the cable with a high-flex type if they appear.
• Companion camera mounting and cabling. Fixed mount outside the envelope, a service loop in the cable, drag-chain rating where it moves — brackets and cables sit in the accessories finder.

When the checks point to new hardware, start in the configurator:

If a camera node fires and the preview still does not move, tell us through the contact page which of the five checks failed — that narrows it to the camera or its cable in one message. More pendant and wrist-camera patterns are collected under the robotics vision topic.