Two camera locate nodes in one program: rename waypoint names

You added a second camera locate node to pick a second part, and the relative moves that ran perfectly for part 1 now head somewhere else for part 2. Nothing is wrong with the camera, the light or the part teaching. Both locate nodes are writing through waypoint names that match, and the node taught or run last overwrites the stored positions the other node's moves were built on. This guide walks the fault end to end: confirm the name collision, rename every waypoint per node, re-teach, and prove the fix with a slow dry run. It closes with the decision for each layout — two nodes, one snapshot with multiple detections, or a fixed overhead camera.

Why did the second camera locate change my programmed moves?

Because the two locate nodes share waypoint names: a name is the key the pendant stores a taught position under, so the second node's teach overwrote the values the first node's relative moves were built on. A locate cycle holds two kinds of stored data. The fixed waypoints you teach — snapshot position, approach, pick, retreat — keep their positions under their names, and the node writes its locate result at run time into a waypoint variable, which then moves the robot to whatever position that variable holds.

Both kinds are keyed by name, and one key holds one value. Copy the first node to build the second — the usual route — and the copy keeps the names, so the second teach replaces the first node's stored positions key by key. At run time, two nodes writing one result variable means the last write wins. Either window corrupts a pick, and the program listing shows nothing about which one fired.

Take example values from a two-part cell. Node A's camera locates part 1 at X = 310.2 mm in the snapshot frame, and you teach the pick as that position plus +12.0 mm in X: the pendant stores 310.2 + 12.0 = 322.2 mm under the name "pick". Later you teach node B, whose camera finds part 2 at X = 148.6 mm; through the same name it writes 148.6 + 12.0 = 160.6 mm over the 322.2 mm. At run time node A's pick reads 160.6 mm — a miss of 322.2 - 160.6 = 161.6 mm, exactly the distance between the two parts along X (310.2 - 148.6 = 161.6 mm). The code looks untouched; the storage behind the name is not.

How do you confirm shared names are the cause?

List the waypoint names inside each camera locate node and compare the two lists: a single duplicate name is enough to corrupt a pick, and the target you are checking for is zero matches across the whole program. That check takes half a minute on the pendant and settles the question in most cells. Work through the others only if the lists come back clean.

1. The name check. Open both nodes and write their waypoint names side by side. Any match, on any role, is the fault; there is no harmless duplicate.
2. The symptom signature. Teaching worked and part 1 picked fine; the moves changed only after the second node was taught. That points at stored positions, not at optics or lighting. If instead the locate cannot find the part at run time while teaching looked good, the fault is image-side — read about stream versus snapshot failures at run time.
3. The isolation run. Save a copy, delete node B, run one cycle. Node A picks part 1 correctly again, so the collision is confirmed; restore the copy and apply the fix below.
4. After the fix. Picks that travel the right distance in the wrong direction have a different cause — the reference frame of the variable waypoint — covered in fixing a variable waypoint reference frame.

Which waypoints need unique names?

Every waypoint attached to a locate node needs a name that appears nowhere else in the program: snapshot position, approach, pick and retreat each take a per-node prefix, and the node's locate-result variable gets one too. The table is the whole rule.

Prefix by part or node, suffix by role. Names that say what they are survive a program re-order; numbered names such as waypoint_07 do not, and they are what a copy-paste duplicates first.

How do you rename and re-teach without breaking the first pick?

Rename first, re-teach second: renaming every waypoint in the second node before touching any position keeps each taught value bound to its own key, and the re-teach then stores the second part's positions cleanly under those keys. Renaming alone is not enough — the taught positions follow the old names until you re-teach.

1. Save a copy of the program under a new version name so you can roll back.
2. In node B, rename each waypoint — snap_part2, approach_part2, pick_part2, retreat_part2 — and the locate-result variable.
3. Move the robot to node B's snapshot position before teaching. A locate's stored offsets are valid from the pose it was taught at, which is why the robot must return to the snapshot position first.
4. Re-teach node B's waypoints from that position, one by one.
5. Open node A and confirm its taught positions still read the values you set; rename nothing there.
6. Dry run one full cycle per part at reduced speed before you release the program.

Should two parts mean two camera locate nodes?

Use two nodes when the parts sit at different places and need their own snapshot; use one node with multiple detections when both parts appear in the same image, because one snapshot then does both picks with no names to collide. The parts' layout decides, not the camera.

Two nodes is the layout for two snapshot positions, and teaching two parts in one program with separate snapshot positions covers how to place those snapshots. When both parts share the image, multiple object detection in one snapshot picks a full tray per cycle and carries a single name set. A table too large for one view needs several snapshots from the wrist camera — multiple wrist camera snapshot positions — and the same rule holds there: one prefix per snapshot position. For a family of geometrically similar parts, parametric teach reduces the work to one taught model plus per-part parameters, and locating a part reliably often wants more locates in the sequence than one — five locate nodes instead of one explains that layering.

• Two parts, two fixture locations: two nodes, per-node prefixes.
• Two parts in one image: one node, multiple detections.
• One part family with size changes: one node, parametric teach.
• Wide table: several snapshot positions, one prefix each.

When is a fixed overhead camera the better answer?

When both parts always land on a fixture or a known region of the table: a fixed smart camera above the cell takes one snapshot of both parts, and the robot spends no travel time moving between wrist snapshots. The cycle gets shorter, and with one node there is only one writer per name.

Smart cameras run the locate on the device and hand coordinates to the robot, and the same one-name-per-result rule applies to the result variables in that program. The LS-SMC-0017 is an 8.8 MP smart camera with a global-shutter sensor and a C mount, so the lens can be matched to the field of view instead of being fixed by the body. Mount it on one of the camera stands: the LS-MNT-0040 holds a camera at 700 mm of height on a 400 x 450 mm base.

A station that outgrows its integrated lighting can add a vision controller beside it: the MV-VC3301H-128G66 switches its 4 built-in light channels and gives the cell one box to run the wider program.

Keep the wrist camera when parts arrive anywhere in a wide bin or the table has no single view. If you build the wrist station yourself, a compact body keeps the mass off the gripper: the LS-SMC-0063 pairs a 1.6 MP sensor with its own 16 mm lens and a polarized white light, so the wrist carries one camera and one cable. Whatever sits on the gripper, which tool-frame offsets work with a gripper-mounted camera tells you which offsets hold up.

How do you keep the next program collision-free?

One rule and one check: every waypoint name starts with its node's prefix, and you search the program for duplicate names before the first teach — zero matches means no collision can start. Everything else is habit.

• Copy a locate node, rename its waypoints immediately, then teach — never teach into a fresh copy.
• Keep a template program with a named, prefixed waypoint set per node.
• Give the locate-result variable the same prefix as its node.
• Re-run the duplicate scan after any paste, including pastes inside one node.

The program tree on the pendant is where these names live and where duplication bites; configuring named waypoint nodes walks that tree node by node. More fixes at this level sit under the systems topic.

Next step: run the rename-and-re-teach sequence above on the running program, then pick the layout that removes the collision for good — two nodes, one snapshot with multiple detections, or a fixed overhead station. Size that station in the system configurator, compare locate cameras in the camera finder, or contact the applications team with your cell layout.