Joint following Error with rotational axis

Hi
If I stop any Gcode program using the cycle stop button while any of the rotational axis (B and C) are not at 0 or home position, then I get a joint following error on joint 0 and joint 2 (X and Z). If the head is situated at the zero or home location then there is no problem.

 

This indicates that your forward and inverse kinematics do not match one another for B and C angles unequal to zero.

We did check for that first off but we will look again.

We installed our config with our kinematics on 2.8.4 using Axis as gui and no problem. Then we did the same with Gmoccapy as gui and again no problem.
The next step was to install on 2.9.2 with Axis as gui and no problem. When we installed the same with Gmoccapy as gui the error presented itself again. I also installed on master 2.10 and the problem exists there as well.

This would suggest that the problem lies somewhere with Gmoccapy and the way it handles multi axis setups.

The following test were done:

1) 2.8.4 with Axis giu - no problem

2) 2.8.4 with Gmoccapy - problem

3) 2.9.2 with Axis - no problem

4) 2.9.2 with Gmoccapy - joint following error on 0 and 2

5) 2.9.2 with GTDragon - joint following error on 0 and 2

6) 2.10 with Gmoccapy - joint following error on 0 and 2

It would seem that both the programs do not handle tool length offset correctly especially if a rotation axis is involved. It seems that the tool length setting jumps to zero if the stop button is pressed while the b axis is not on zero. The C axis and A axis has not been tested yet.

It would seem that the problem occurs when the gui executes a G49 in the background. This does not happen with Axis but it does with Gmoccapy and QTDragon.

G49 should not be used with a multi axis machine at all and there should be an option either on the gui or in the setup to allow the user to make the choice if they want to use it or not.

Gmoccapy use automatic G43 command.
You can try delete it:
github.com/LinuxCNC/linuxcnc/blob/54bca1...ccapy.py#L3536-L3540

or you can try delete other parts with G43.

From further testing we discovered that it was not the G43 that was causing issues but the G49 that was issued on_abort.

You mean the custom 'on_abort' routine?
I cannot reproduce this in gmoccapy simulation configs, neither estop nor program stop changes 'motion.tooloffset.z' value.

Correct, and you cannot simulate the problem either. It only shows up on the running software.

Can you tell us more about this problem? I am interesting.