Hypothetical tooling and harness handover

Task and implementation

Task and explicit assumptions

A laboratory is assumed to replace a gripper and its moving harness on an existing robot. The exercise identifies the flange and adapter drawing, attached mass information, object contact conditions, utility connections and the complete cable route. It preserves the old tool and wiring version before making any decision. The receiver is asked to confirm pin definitions and permitted connections from the actual documents rather than from plug shape or wire colour. This is a planning exercise and does not imply this site supplied a tool.

Two routes and their tradeoffs

Route A retains the verified tool arrangement and uses a documented harness replacement, reducing interface changes but preserving the original task limits. Route B introduces a different tool or adapter and harness as a combined integration, allowing a new contact arrangement while adding mechanical, utility and control checks. The second route is not established by two plugs mating. Conversely, the first route does not prove that an object outside the original contact conditions can be handled.

A task-specific execution method

Create separate mechanical, power, air and signal maps, using applicable drawings rather than wire colour. Mark the full moving route and strain relief. Identify tool-close acknowledgement, retained-object feedback and the final placed-object result separately. Check static connection and permitted motion as different activities under the equipment procedure. Preserve the adapter, finger, cable and software versions with the object sample. If a pin, permitted utility or failure behaviour is unknown, stop the affected check instead of experimenting with live connections.

Worked hypothetical result and decision

Assume a 1.2 kg tool, a 0.3 kg adapter and a 2 kg object solely for this exercise. Their attached mass totals 3.5 kg, rather than the object alone. That sum does not establish suitability: the robot maker applicable load and centre-of-gravity conditions must still be checked. Now suppose the close status is successful but the object slips before placement. Command handling passed one layer, while retention and task outcome did not. Review contact and feedback rather than recording the whole cycle as successful.

Problem branches and stopping conditions

If any pin or failure behaviour remains unknown, it blocks the affected functional check. If the connection is confirmed, static continuity, permitted motion and object retention are recorded separately. The handover includes drawing versions, label photographs, unsuccessful picks, release observations and the party responsible for final acceptance. A tool-close status alone is not proof of a retained object, while a retained object alone does not establish production reliability or risk control. The receiver must be able to return each observation to the tested physical configuration.

What the receiving team can conclude

The handover should allow another engineer to distinguish what fits, what connects, what the controller supports and what object behaviour was observed. Include the original pin map, tool configuration, unsuccessful picks and the approved task boundary. A static electrical result cannot substitute for the moving route, and a moving route cannot substitute for object retention. The exercise ends with a supported choice or a named unresolved interface, not a claim that the site supplied equipment or completed a customer installation.

If the new tool changes contact or utility requirements, retain that difference as an integration condition. The receiving party should not inherit an unexplained assumption from the old assembly. Keep the object, tool and route together when deciding what further check is needed.

Before you begin

1. Tool adapter and object conditions
2. Approved utility and pin drawings
3. Full route and task observations

Review criteria and sources

Review criteria

1. Unknown pins block affected checks
2. Retention and command are separate
3. Task failures remain in handover

Primary-source reading

Harmonic Drive Engineering Data
https://www.harmonicdrive.net/_hd/content/documents1/FBB_DifferentialGear.pdf

UR-Series Service Manual
https://www.universal-robots.com/manuals/EN/PDF/Shared/service-manual_ur-series/Service_Manual_UR-Series_en.pdf

Universal Robots: Maximum Payload (model-specific conditions)
https://www.universal-robots.com/manuals/EN/HTML/SW10_15/Content/prod-usr-man/complianceUR30/H_g5_sections/mechanical_interface_g5/maximum_payload_UR30_en.htm