Vision locate with changing part sizes: teach one model per batch

A wrist camera earns its keep with a parametric model: teach a rectangle with its height, width and length in mm, and the camera locate node finds that part from then on. The trouble starts with the second batch. The dimensions changed, the MES has the new numbers, and you want to push them into the locate node over TCP at program start. You cannot. The taught dimensions are constants inside the node, and no message rewrites them at run time. Here is the pattern that works instead: teach one locate node per size, let the external computer send a batch ID that selects the node at cycle start, and know the point at which this stops scaling and recipe-driven vision takes over locating.

Why the locate node will not take new dimensions

The parametric model is built from the height, width and length values entered at the pendant, in mm, and those values are stored with the taught model. They are not exposed as variables a TCP client can write. The vendor's documented answer to this exact request is short: it is not supported, and each different object needs its own locate node.

That leaves the three options in the usual plan ranked like this:

1. Rewrite the whole program with the new dimensions. The dimensions are not addressable, so this means rewriting and re-uploading program code. Skip it; the warning below says why.
2. Rewrite only the locate step. Same obstacle, plus a partial write into a program that still has to validate. Skip it too.
3. Teach one locate node per size, then switch by selection. Nothing is rewritten at run time. This is the working pattern.

If you have taught shape models but never built a parametric one, the parametric teach workflow for geometric parts walks through building exactly that model.

What you need

• One taught locate node per size, named for the size (for example L60xW45xH18 for a 60 × 45 × 18 mm part), each taught at the height the gripper actually picks.
• A PC or MES process that knows the current batch and listens on a fixed TCP port both sides agree on, for example 3000.
• The pendant program restructured so the locate step is selected rather than edited; on a UR10e, that is an If / else-if chain in the program tree.
• A controlled stop for an unknown batch ID, wired to a fault output the PLC can see.
• About ten sample parts of every size for verification.

Teach one model per size, then switch by batch ID

1. Inventory the sizes. List the sizes that actually run and give each one a node. Before teaching several models, run through the vision locate feasibility checklist; finding a contrast problem before three nodes are taught costs less rework than finding it after. Teach each node at pick height so the scale is right — teaching pattern matching at final part height explains why the teach height sets the scale.
2. Open the socket at cycle start. The pendant program connects to the PC's IP and agreed port as a client, with a receive timeout (if the pendant has no timeout parameter, count loop cycles and fault out): a dead server then faults the program with a clear message instead of hanging the robot. After any fault, the handshake runs again at the next cycle start, following the re-handshake after a robot fault pattern.
3. Fix the message format. One ASCII line from the PC: BATCH,<id> followed by a newline, with <id> a small integer, for example BATCH,3. A comma-delimited, newline-terminated line parses in one step; avoid free-form text.
4. Map the ID to a node. An If / else-if chain on the parsed integer: 1 arms the L60xW45xH18 node, 2 arms L80xW60xH24, 3 arms L40xW30xH12 (example sizes, all mm). The chain is plain pendant logic; the taught nodes themselves never change.
5. Acknowledge and guard. The program sends OK,<id> back so the MES knows which model armed. An ID with no matching node sets the fault output, sends ERR,<id> and stops the program. Never fall back to the first node.
6. Run the cycle. Locate, pick, place, repeat until the locate reports no part found. The loop-until-empty batch pick gives the end-of-batch condition.
7. Handle the batch change. The PC sends the next BATCH,<id> line and the program returns to step 3. Nodes, socket and calibration stay untouched. Switching the active model without dropping the connection is the same problem solved for external cameras in switching vision jobs mid-program without losing the camera socket.
8. Verify. Run ten picks per size with the sizes shuffled, plus one deliberate unknown ID to prove the stop works. Record the cycle time per size; if one size is slow, the cause is usually that node's exposure or model, not the socket code.

What the pattern saves: a changeover example

The inputs below are example numbers — substitute your own schedule; the arithmetic is the point.

• 4 batches per day, one size per batch.
• Hand-teaching a new batch at the pendant: 12 minutes, including the 10-pick verification.
• 240 production days per year, 3 sizes in the mix.

Teaching every batch by hand: 4 × 12 = 48 minutes per day, and 48 × 240 = 11,520 minutes per year. Divided by 60, that is 192 hours — 24 eight-hour shifts of a technician at the pendant, every year.

With one node per size: the 3 sizes are taught once, 3 × 12 = 36 minutes in total. Every batch start after that costs one socket round trip, well under a second. The 192 hours per year collapses into those 36 one-time minutes, and mis-teaching disappears because nothing is taught twice.

Why not overwrite the program or the node's values

Options 1 and 2 fail for the same reason: the locate values are not data your TCP client can reach, so changing them means changing program code. A program modified by an external computer is a new program. It needs its own validation before the cell should ever run it, and a partially written upload is a stopped cell — or a cell that starts with half of two programs.

The decision: option 3. Selections are data. Code stays frozen.

When pendant locating stops scaling

Watch the count of sizes. At two to six sizes, the node-per-size pattern is the simple answer. When the mix reaches dozens of sizes, or a new size arrives every few batches straight from CAD, each new model becomes another teach session with a person at the pendant. That is the point where dimensions should live as data and vision should run where parameters change per part:

The middle tier is where smart cameras live: the locate runs on the camera itself and jobs switch on command — the one-byte job-change pattern in job-changing a vision sensor over PROFIBUS. The bottom tier is vision controllers: the vision application runs next to the robot, sizes are recipe rows, and the robot consumes camera offsets sent over a TCP socket.

On the middle tier, the MV-SC3050XC-16M-ATN-H runs the locate on the device at 5 MP over Fast Ethernet, and the MV-SC5060XM-08M-WBN adds a 6 MP mono sensor with an 8 mm M12 lens on GigE.

On the bottom tier, the MV-VC2140-128G40-1T runs the vision application on an N97 processor with 8 GB of RAM, a 128 GB SSD and a 1 TB HDD, with 4 built-in light channels to drive the lighting side.

Common mistakes

• Fallback to node 1 on an unknown ID. The wrong model still finds a part; the offsets are what come out wrong. Make it a fault, as in step 5.
• Teaching at fixture height. Every millimetre between teach plane and part top skews the scale. Teach at pick height.
• A socket wait with no timeout. A dead PC then hangs the cell instead of faulting it. Set the timeout in step 2.
• Reconnecting every cycle. Open once and re-handshake at cycle start; per-cycle reconnects are where half-open sockets come from.
• Sending dimensions instead of the ID. The node cannot take them, and the workaround ends up being the program rewrite ruled out above. Send the ID.
• Skipping the acknowledgement. Without OK,<id>, the MES believes a model armed while the program sat stopped.

The decision, per case

• Two to six sizes that rotate as batches: teach one node per size and switch by batch ID. One teach per size, ever. Run this pattern this week.
• One or two sizes a millimetre or two apart: a single node may hold. Prove it with ten picks at each extreme; if it holds, keep one node, otherwise teach the second anyway.
• Dozens of sizes, or a new size from CAD every few batches: recipe-driven vision. Start with a smart camera and a job per size; move to a vision controller when you need light control, several cameras, or offsets computed next to the robot.

Size the camera side for your largest and smallest parts in the configurator:

If the batch mix is not clear-cut, send the size list through the quote form and we will size both tiers with you; the camera finder filters by resolution and interface if you want to browse first. More socket, locate and job-switch patterns are collected on the robotics topic page.