Enter robtarget targets on the teach pendant for a wrist camera

Typing target numbers straight into the pendant is the fastest way to stand a first camera station up: no offline project, no export, no round trip through a PC. This procedure covers both halves of that job for a wrist-mounted camera. First you enter the position and orientation values into a robtarget, then move to it with MoveL, and finally you put the camera to work — powered over its Ethernet cable and triggered by the robot program over a socket or a digital output. The pendant runs motion, the camera host runs the inspection, and the handshake between them is a few lines of program and three cables.

What you need

• A robot controller in manual mode, with the teach pendant and enabling device at hand.
• The target numbers: X, Y and Z in millimetres, the orientation, and the tool and workpiece frames they refer to.
• A host for the camera's own software — a PC beside the cell is the common case, and the camera finder filters bodies by interface and resolution if the camera itself is still to be chosen.
• An Ethernet path from the cabinet to the wrist, with power over Ethernet if the camera takes it.
• A high-flex cable for the moving section; the camera power and I/O cables page filters by length and connector.

What a robtarget stores

A robtarget is one stored position: the X, Y and Z of the tool center point in millimetres, an orientation written as a quaternion (four numbers), and configuration data naming which of the arm's possible joint solutions to use. All of it is measured in the tool and workpiece frames you assign to the target. Speed is not part of the target — speed data is a separate value that defines the velocity of the tool center point, the external axes and the tool reorientation.

Because the whole target lives in one data object, the pendant's data editor creates it or changes it directly; no offline software is needed to put a number in front of the arm. Configuration data can even be edited on its own: a home point stored as [-1,-1,2,0] runs the same position and orientation when changed to [-1,-1,-3,0], provided the new arm solution is physically reachable.

Enter the target on the pendant

1. Turn the mode key to manually reduced speed and keep the enabling device held; the arm only moves while you hold it.
2. Open the program-data view and create the robtarget — pPick, pPhoto, whatever name the program will call.
3. Select the tool and workpiece frames the numbers refer to. The same X, Y and Z mark different places under different frames.
4. Type X, Y and Z in millimetres.
5. Type the orientation's four quaternion values only if you have them from CAD or a calculation. Otherwise jog the wrist to the pose and update the target from the current position, so the orientation is recorded exactly as the arm stands.
6. Set the configuration data — copy it from a nearby target that already moves cleanly, or edit the four values directly as in the home-point example above.
7. Save. The data is live, and the program picks it up on the next execution.
8. Prove it with a MoveL: write the instruction, name the target, attach a slow speed data, and step it in manual mode.

Run the first MoveL safely

MoveL moves the tool center point in a straight line to the named target; the speed data decides how fast the point travels, how the external axes run and how the tool reorients. Two habits make the first approach uneventful, which is the goal. Insert an intermediate point above the station so the final leg drops vertically onto the camera pose. And treat the first cycle as a test, not a run.

If MoveL faults before the arm moves, suspect the configuration data rather than the coordinates, and jump back to the configuration step.

Trigger the camera from the program, not the pendant

The pendant's job ends at motion. The camera keeps its own host running its own software, and the robot program talks to that host — the pendant itself executes no camera code.

The common handshake is a TCP socket. The robot program opens a client connection to the camera host's IP and port, sends a short trigger string, and waits on the reply. The host captures, inspects and answers with coordinates as text, which the program converts into a target before moving on. Receiving vision data in the robot language over TCP sockets walks the receive side line by line, and third-party camera options on a robot controller covers what the controller can run itself if you would rather drop the separate PC. With the camera on the wrist, the pixel-to-robot conversion changes at every pose; chaining the eye-in-hand transforms from pixel to world coordinates works through that chain.

A discrete output is the second option: a 24 V digital output pulses an optocoupler input, the host triggers, and the robot waits on a second input for the done signal. Wires carry no coordinates, so pair the I/O with whatever link returns the data, or use it when the result goes to a PLC. Both directions of that wiring are in open-end trigger cable wiring for optocoupler trigger and strobe.

The sequence is the same either way: arrive at the photo position, trigger, wait for the reply with a timeout, convert, move.

Wire the arm: one Ethernet cable, plus an optional trigger line

Power over Ethernet collapses the wrist problem to a single cable — data and the camera's supply ride the same cord. Confirm first that the camera takes PoE at all, and which class: does my camera support PoE shows the check to run before you buy or wire. IEEE 802.3af delivers 15.4 W at the switch port and guarantees about 12.95 W at the camera end after line loss, so match the camera's stated draw against both the port class and the switch's total PoE budget. Ethernet's 100 m span limit is nowhere in sight on an arm: the dress pack plus the fixed run stay far inside it.

Flexing kills ordinary patch cords, so the moving section wants high-flex, drag-chain rated cable with locked connectors. The LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks, built for drag chains. The LS-CBL-0117 is a 15 m RJ45 camera data cable with locking stud connectors, sized for the fixed pedestal-to-cabinet section. For the discrete trigger pair, the LS-CBL-0300 is a 7 m M8 8-pin, male-to-open 8-core power and I/O cable rated for drag-chain use. A 24 V unit from the power supplies page runs anything non-PoE you hang beside the camera, such as a small trigger light.

These three cover the moving run, the fixed run and the trigger pair:

Worked example: standoff and lens for a wrist camera over a 300 mm tote

The Z value you type into the photo target decides the optics as much as the lens does, because standoff sets the field of view. Set the case: camera on the wrist looking straight down into a tote with a 300 mm × 225 mm opening (4:3, to match the sensor), at a 400 mm standoff from lens front to tote rim — the standoff is the assumed working height, chosen for wrist clearance. The sensor side is fixed by the camera data: a 1/1.8-inch format sensor has a 7.2 mm active width. Ten percent margin around the opening sets the field of view target at 330 mm.

The rule, in words: magnification is sensor width divided by field of view, and focal length follows from the working distance and that magnification.

Arithmetic, in order:

• m = 7.2 mm / 330 mm = 0.0218
• f = 400 mm × 0.0218 / (1 + 0.0218) = 8.7 mm / 1.0218 ≈ 8.5 mm

An 8 mm C-mount lens covers about 360 mm at 400 mm standoff (400 × 7.2 / 8), comfortably past the 330 mm target. A 12 mm lens covers only 240 mm at 400 mm; it meets the 330 mm need exactly at 550 mm (330 × 12 / 7.2 = 550 mm), so it becomes the better match if the wrist can sit higher. A 25 mm lens sees about 115 mm at 400 mm — a detail station, not a tote view. Decision: at 400 mm, order the 8 mm; if the arm can hold 550 mm of clearance, raise the photo target's Z and take the 12 mm.

Run your own standoff and scene width through the calculator:

Type the winner into the photo robtarget — Z at 400 mm above the tote top in the workpiece frame — and let the camera, not the keyboard, produce the pick target afterwards.

Checks before the first full cycle

• Move to every typed target once in manual mode at reduced speed before the first automatic cycle.
• Calibrate the workpiece frame to the physical fixture first; perfect numbers in an uncalibrated frame still land in the wrong place.
• Send one trigger and read one reply string with the program in step mode before any motion depends on the handshake.
• Plan the network once, controller side and camera host side, the way camera setup on a robot controller: ports, IPs and I/O lays it out.
• If picks must repeat tighter than a millimetre, measure the chain before trusting it: hand-eye calibration accuracy verification: test before you trust it gives the test.
• Anchor the dress pack at both ends, and re-check the connector locks after a day of cycling.

When typed targets are the wrong tool

A typed robtarget is the right tool for anything fixed: the photo position, a home, a drop-off. It cannot aim at a part that arrives somewhere new each cycle — that is the camera's job at runtime. The working pattern: move to the typed photo target, trigger the host, and build the final pick target in the program from the coordinates that come back. How a 2D vision-guided pick-and-place cycle works shows that loop end to end, and the applications guides collect more set-ups like this one.

Next step: choose the camera and the cable set together, because the interface decides both. The configurator can start at the camera step or at the extras step for cables and triggers, and the contact page is where an unusual run length or a non-PoE camera gets checked against a specific cable before you order.