DRO shows identical position at arc entry and exit — LinuxCNC believes the machine returned to the correct point. But probing a fixed reference shows X shifted +9.3mm and Y shifted -12.2mm. HLFB is configured at 20 counts and did NOT trigger. This means every commanded step was executed by the motor. The error is in the arc interpolation — the step path LinuxCNC generates to trace the circular arcs does not sum back to the correct physical position.
LinuxCNC version: Master (2.9), running on Raspberry Pi 5 (4GB), Debian Bookworm, Mesa 7i96s over ethernet (hm2_eth), SERVO_PERIOD = 1000000.
Linuxcnc doesn't generate a step signal. All planner calculations are based on position (float64 number) and velocity signals.These numbers (not steps or pulses) for each servo cycle are sent to the Mesa board, where "stepgens" converts them into pulses.
These are the connections in hal:
joint.N.pos-cmd -> hm2.N.stepgen.position-cmd;
Each cycle, Mesa sends back the counted number of generated pulses for reporting:
joint.N.pos-fb <- hm2.N.stepgen.position-fb;
The difference between the sent position and the feedback is tracked using the joint.N.f-error pin.The path planner (on the computer) and stepgen (inside the Mesa board) do not influence each other, but each performs its own role in the chain.
I hope you understand that, in this logic, the position can't simply shift in the planner. If there was an error, it would mean it was transmitting an incorrect coordinate to the mesa, and the same incorrect coordinate would be visible in your DRO (since it's also connected to the joint.N.pos-cmd == axis.N.pos-cmd signal). And the incorrect path would be drawn in the graphics window. The "live plot" draws either based on the pos-cmd or pos-fb numbers. there's a switch for this.
If "LinuxCNC believes the machine has returned to the correct point," then the planner has indeed returned to that point and is transmitting that exact position command to mesa.If the error occurred in stepgen inside mesa, then the position-fb counter would have returned an incorrect number of counts (as a float64 number, not pulses).
If your servos don't report their own following error, then there remains the possibility of an error between Mesa => Servo. Due to electrical interference/noise, not all pulses could have been received by your servo - it thinks it's following the path, but in fact, not all the pulses reached it.
This is confirmed by the fact that you saw a connection between the error and pulse timings.
I have been working with linuxcnc and fusion 360 for a long time as post programmer, so I can assure you - there is no connection between the post processor, pathplanner and your problem. Both work fine.
