Bug in G12.1

I'm setting up an real milling machine with xyzab_tdr_kins kinematics.
To avoid unnecessary questions, I emphatically declare that everything is correct in my configuration, I made all changes on purpose, it was supposed to be like that, it works well and has no connection with the described below error.

Since this is a real machine, it has real parameters in the ini file. Unfortunately, the Z-axis travel is only 110 mm, but as it turned out, this was a bigger problem than I expected....
After basing it looks like this:
 
Then I issued some commands, which you can see in the MDI window.
 
So far everything works as it should, but after executing G12.1 miracles happen:
 
If you look closely at the pictures above, you can find the reason.

The explanation of this phenomenon is extremely simple.
Well, after a 90-degree rotation, G12.1 actually swaps the axes.
This is probably mathematically correct and works correctly in the simulator and on a real machine in JOG mode.
But when I try to use the g-code in MDI or in a program, this converted Z(abs) value is compared to the Z axis soft limits specified in the ini file, which makes absolutely no sense.
As you can see in the pictures, even an attempt to rotate by a very small value (here 1 degree) causes an error, although it is very far from the soft limits of the Z axis. Basically, it's even worse, because G0A1 here is a movement around the Z axis, the spindle is supposed to stay in place, and the error appears...

I only have reference sensors in the machine, I haven't planned any hardware limits and I don't want to install them because there are Ethercat drives that turn off when overloaded and report an error.
I also don't like the abandonment of soft limits, because they effectively prevent movement outside the working area.
Besides, the error is in G12.1 and it is this that needs to be fixed, not around the problem.

G12.1 should, in addition to what it does, disable soft limits (and G13.1 enable them again).

This is a limitation of the current implementation. See the millturn sim config on how to switch the limits using the 'ini' halpins when switching the kinematics. Note that this workaround is crude and will basically only allow to expand the limits to avoid false soft limit errors.

There is currently major work underway to give linuxcnc proper multi axis capabilities, including proper limits handling. The G12.1/ G13.1 codes are part of this work and many further changes are currently in testing and will hopefully be merged step by step into master over the coming months.

github.com/LinuxCNC/linuxcnc/pull/4374

Aciera wrote:

many further changes are currently in testing and will hopefully be merged step by step into master over the coming months.
 

I'm afraid this won't be a solution for me, just replacing one problem with another.
forum.linuxcnc.org/ethercat/59324-lcec-c...c-2-10-and-debian-13
The changes in the master branch have gone way too far. You should wait until version 2.10 is finished before rewriting the basic code. Now it's the case that code written a month ago will not work with LinuxCNC compiled today. If it continues like this, no one will control it...
For now, I would like to stay with the version compiled on September 26, i.e. with working Ethercat.

I know how to deal with changing limits and I wrote the appropriate m-codes yesterday and changed existing M428 and M429. It can also be solved differently.
It's workable for now.

2.10 is not released and is a branch in development, I intend to merge as much as I can before the release, it's a bugger that we are working on similar issues from different angles, but I'm glad you got it working...

We have signatures now? Oh good, if i knew what to put there!