[JakeInTX]

Hi all,

I'm working with a UFACTORY xArm 6 through RoboDK.

Joint movements work perfectly in both modes, whether the robot is driven live by RoboDK or running a program sent to it independently. The problem only shows up with linear moves:

- Driven live by RoboDK: linear moves are correct, path and end effector orientation match simulation.
- Sent to the robot with "Send Program to Robot" and run independently: linear moves either miss the correct position, or reach it with the wrong orientation, and the path doesn't match what RoboDK shows.

I can't rely on joint moves alone for this project, so I need linear moves to behave the same sent as they do live.

What I've already checked:
- Base frame in RoboDK matches the xArm's reference frame (no unexpected offset).
- Tool frame (TCP) values in RoboDK match the TCP configuration in UFACTORY Studio exactly (same X, Y, Z, and Euler angles).
- Confirmed the Euler angle convention in RoboDK matches how the xArm defines roll, pitch, and yaw (fixed-angle XYZ).
- Tested a single-axis jog to isolate the issue; the discrepancy still shows up on sent linear moves even though live-connected linear moves are fine.

Since joint moves are consistent in both modes and only linear moves diverge, and only when sent rather than live, I suspect this is something in how the post-processor or program generation handles Cartesian/linear motion for the xArm 6 controller specifically. Has anyone else run into this, or know what changes between live-driven and sent-and-run execution for linear moves on the xArm?

Thanks,
Jake

[Raphael]

This is a known issue with the xArm driver that has been fixed and will be included in a later version. In the meantime, please find the newest version of the driver here.

[Raphael]

Sorry, it seems like I misunderstood your question. Here is the updated post-processor.