Follow the transform path before editing any coordinates: Inventor exports the cutting curve, the plug-in assigns object, reference, and tool context, RoboDK places that data in the station hierarchy, Move Geometry locates the curve relative to the gripper, and the remote TCP defines the fixed hot wire. If any hop uses the wrong frame, the curve appears displaced, rotates around an unexpected origin, or moves again when a reference is updated.
Where does the cutting-path transform stop?
A remote-TCP application reverses the familiar relationship between tool and work. The robot carries the workpiece in the gripper while the process point—the hot wire—remains fixed. The imported curve therefore belongs with the robot-carried workpiece geometry, not with the stationary wire.
| Transform hop | Required meaning | Failure symptom |
|---|---|---|
| Inventor curve | Curve coordinates relative to a known CAD origin | Path imports at an apparently random position |
| Export reference | Defines the coordinate context used to export the curve | Repeated manual rotation and translation are required |
| Robot tool geometry | Gripper, workpiece, and curve move together | Curve remains behind or follows the wrong station item |
Move Geometry |
Fixed transform from the gripper/tool frame to the curve | Path is offset or rotated relative to the held workpiece |
| Remote TCP | Fixed hot-wire pose used as the process point | Robot motion is calculated about the wrong point |
| Program base | Controller-side frame context represented by #BASE
|
Simulation and controller motion disagree |
Start with layer one: the CAD origins, axes, attachment hierarchy, and rigid transforms. Program-generation details cannot correct a curve attached to the wrong item or geometry expressed in the wrong coordinate system.
Which setup approach should be used?
| Approach | Curve attachment | Placement method | Result |
|---|---|---|---|
| Drag the imported path and edit TCP values | May remain ambiguous | Mixes station placement, geometry placement, and process-frame changes | Difficult to reproduce; edits can appear to drift |
| Use the curve as robot-carried tool geometry | Curve belongs to the gripper/workpiece assembly | Enter the curve-to-tool transform in Move Geometry
|
Curve maintains a rigid relationship to the held workpiece |
| Use the hot wire as the remote TCP | Wire remains fixed | Define its pose separately from gripper geometry | Robot carries the workpiece along the cutting curve |
Use the second and third approaches together. Attach the curve to the robot-carried gripper or workpiece assembly, place it with a single explicit Move Geometry transform, and define the stationary hot wire as the remote TCP. Set the curve coordinate system so its Z axis represents the cutting axis.
The gripper TCP and the hot-wire TCP serve different purposes. The gripper frame locates the carried geometry relative to the robot flange. The remote TCP locates the stationary process point. Making them numerically identical collapses two distinct physical relationships and does not align the curve.
Why do coordinate edits appear to drift?
A coordinate value has meaning only with its parent frame. Editing a reference pose changes the reference and every child beneath it. Editing Move Geometry changes the model or curve inside its owning tool without moving the owning frame. Editing the TCP changes the point used for motion calculation. These operations are not interchangeable.
An entry of +1000 followed by -1000 is reversible only when both values are applied to the same transform, about the same axes, with no intervening hierarchy or orientation change. If the first edit moves a parent reference and the second edits child geometry, the transforms multiply rather than cancel. Rotation also changes the direction represented by a later X translation.
Graphics that correct themselves after restarting indicate that the displayed station state and the recalculated transform chain were temporarily out of agreement. Treat restarting as a display-state recovery step, not as the alignment method. After reopening, record the item hierarchy and every relevant pose before making another change.
How should the remote-TCP station be configured?
- Establish the CAD origin. In Inventor, identify the origin and axes used by the exported curve. The export reference must have a known relationship to the gripper or held workpiece. If that relationship is unknown, measure it in CAD before importing.
- Orient the curve coordinate system. Define the coordinate system as though its Z axis were the cutting axis. Correct the orientation at the CAD/export stage when practical so the imported data arrives in a predictable frame.
- Build the robot-carried assembly. Attach the gripper geometry to the robot tool/flange relationship, then place the workpiece and cutting curve in that carried assembly. Moving the robot must move all three together.
-
Enter the curve transform once. Use
Move Geometryto enter the known curve-to-tool transformation. This is the fixed geometric relationship between the exported curve and the carried assembly. - Define the stationary process frame. Configure the hot wire as the remote TCP at its physical location and orientation. Do not use this TCP to compensate for an incorrect curve-to-gripper transform.
- Generate a short test path. Use a small portion of the curve and inspect the simulated workpiece motion before generating the full program.
If the Inventor plug-in offers both reference and tool selections, assign them by physical role: the reference establishes the exported curve’s coordinate context, while the tool selection identifies the robot-carried assembly associated with that curve. The precise selectable item types depend on the plug-in interface; confirm whether it accepts a sketch directly or requires an exported feature by inspecting the plug-in’s available geometry selection.
How can each transform be diagnosed independently?
| Check | Action | Passing result |
|---|---|---|
| Hierarchy | Jog or reposition the robot in simulation | Gripper, workpiece, and curve move as one rigid assembly |
| Curve geometry | Temporarily inspect the assembly with the robot stationary | Curve lies on the intended workpiece cut line |
| Cutting-axis orientation | Display the curve coordinate axes | Z points along the cutting axis |
| Remote TCP | Inspect the fixed hot-wire frame while moving the robot | The wire frame remains stationary |
| Frame isolation | Change one transform, then restore that same transform | The geometry returns to its recorded pose |
If the curve is wrong relative to the workpiece, correct Move Geometry. If the complete carried assembly is wrong relative to the robot, correct the gripper/flange relationship. If the workpiece follows the curve correctly but misses the stationary wire, correct the remote TCP. This isolation prevents one frame from being used to mask an error in another.
How is the generated program verified?
The appearance of #BASE identifies a controller-side base-frame context; it does not by itself prove that the remote TCP was physically taught or that every simulated transform matches the controller. Compare the station’s base, tool, and remote-TCP assignments with the corresponding controller configuration before running motion.
- Save and reopen the station so RoboDK recalculates and redraws the transform chain.
- Confirm that the curve remains aligned with the workpiece after reopening.
- Move the robot through several simulated poses and confirm that the carried assembly remains rigid while the hot-wire TCP remains fixed.
- Inspect the generated program for the intended base and tool context, including the use of
#BASE. - Compare the remote-TCP pose in RoboDK with the pose taught at the controller.
- Run the short test segment under the site’s commissioning controls and verify that the workpiece curve passes through the fixed wire with the intended Z-axis cutting orientation.
FAQ
What happens if I use the gripper TCP as the hot-wire TCP?
The process point moves with the robot instead of representing the fixed wire, or the station combines two different physical relationships. Keep the gripper/flange geometry transform separate from the remote TCP.
What happens if I move the reference and then enter the opposite value?
The move cancels only when both edits affect the same transform in the same coordinate basis. A parent-frame change, child-geometry edit, or intervening rotation causes the transforms to compound.
What happens if the path is still displaced after reopening RoboDK?
The saved transform chain remains wrong rather than merely being drawn incorrectly. Verify the attachment hierarchy, correct the curve pose with Move Geometry, confirm Z is the cutting axis, and finish by running the short simulated test segment.