Switchkins with External Offsets Causes Discontinuity

[sbmarcom]

I have a scara machine controlled by linuxcnc, used for plasma cutting. I use external offsets for THC, probing, and setting the height during a cut. This has worked well until I started using switchkins for rapid moves, now I have a failure with the Z axis.

Here is the issue, based on my understanding from reading the code, I could be missing something:

When running in one kinematics mode, there is the "axis" height, which the TP sees, then the external offset, which to my understanding is only seen by the motmod. Normally, in the do_forward_kins function, the forward and inverse kinematics are run on the total position, then the offsets are applied after, the TP sees the position after offsets are applied.

However, when the kinematics are switched, in handle_kinematicsSwitch, the tpSetPos function is run to sync up the TP with the state of the machine. However, this does not also clear the external offsets, so immediately after this is done, the motion planner will try to apply the offsets to the new position which already includes these offsets. I have a hack in my code to clear the offset immediately after the switch, but there is still a brief moment where the machine will either dive or raise up unexpectedly.

Here are the steps I follow to reproduce the issue:

1. Apply an external offset on the Z axis in one kins mode
2. Switch the kinematics, and look at the plot of axis.z, along with the z eoffset and joint position, you will see the jump

This is what I expected to happen:

I would expect the offsets to either be cleared to reflect the fact that the offsets are accounted for in the TP, or not have the synchronization happen.

This is what happened instead:

The offsets are added into the TP, but not cleared in motmod, so there is a double count of the external offsets.

Information about my hardware and software:

• I am using this Linux distribution and version (often, shown by lsb_release -a):
  Debian 11 Bullseye
• I am using this kernel version (shown by uname -a):
  6.1.35-rt11-v8+ SMP PREEMPT_RT
• I am running ...
  • A binary I built myself
• I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git):
  2.9.0~pre0
• I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc):
  Custom - N/A
• I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card):
  Rpi compute, N/A

[Sigma1912]

I have a hack in my code to clear the offset immediately after the switch, but there is still a brief moment where the machine will either dive or raise up unexpectedly.

Could you share what you have come up with so far?

[sbmarcom]

In my component which manages the z-height with offsets, I had written the following code:

    if (*hdata->machine.interp_synced){
        *hdata->axis_[Z].offset_req = 0;
        *hdata->axis_[Z].offset_current = 0;
        *hdata->axis_[Z].offset_counts = 0;
        *hdata->machine.interp_synced = 0;
    }

the machine.interp_synced pin was set high right after I switched kins, and was set using the M64 command in Gcode.

However, this is not really relevant, because it is kind of a hack.

In the following plot, you can see the error more clearly, the purple line marks where the kins were switched. You can see that the current offset is added to the axis position, then my code tries to cancel out the offset, but it becomes a mess.

The other issue is that when this happens, the trajectory planner is trying to move the axis back down to the command position, so it moves down regardless of the offset. As you can see in the plot, this motion is not exactly what I want.

[sbmarcom]

Here is my proposal for how to fix this more permanently, however, I have only ever worked on this one linuxcnc machine so I am not sure if this will cause issues for other machines.

in control.c, in handle_kinematicsSwitch(), run 'axis_apply_ext_offsets_to_carte_pos(-1, pcmd_p);before callingtpSetPos(&emcmotInternal->coord_tp, &emcmotStatus->carte_pos_cmd);`

Here is what I think this would fix:

• It would prevent the offset from being applied on top of the axis position which already accounts for the offset.
• The trajectory planner commanded position would start in a state without motion, to prevent following errors and unexpected movement.

If this sounds like a good solution, I will make a PR for these changes.

[Sigma1912]

The original author of the switchable kinematics feature has retired from the project. Given the lack of personnel you will not likely get a review based on a rough outline of a fix. The best way forward would be for you to implement the fix you are thinking and once tested create a pull request.
Thanks.