Rotary axes homing

I think I can configure it myself, but I decided to start this topic because, firstly, maybe someone has a ready-made solution, and secondly, it may be useful to someone else.

Well, I bought a Chinese rotary axis. It is of good quality and works properly, but the designer did not provide homing limit switches.
I decided to add them in such a way as to interfere with the original structure as little as possible.
I came up with an idea that if you cleverly place miniature inductive sensors, they can work with small pieces of metal attached to moving elements, while the sensors themselves will be attached to a stationary base.
I fiddled with it a bit and it worked.
The video shows a complete makeshift, the elements are attached with double-sided tape, and the Chinese TL-W3MC1 sensors work with plates from a canned food can. Of course, ultimately it needs to be done better.

As you can see, the B axis (tilt) is referenced first, then it is set at the appropriate angle relative to the sensors (in this case +90 deg from machine zero), and only then the A axis (rotary table) is referenced. No special combinations are needed here, just set the HOME, HOME_OFFSET and HOME_SEQUENCE parameters correctly in the ini file.

As I wrote above and as you can see in the video, it works properly, but there is a problem that needs to be solved.
Well, everything is fine when we base all axes at once.
If we try to reference only the A axis, it will probably fail, because the sensor and the mating metal will be in such positions that they will never come close to each other. Therefore, when homing only the A axis, should be first check whether the B axis is referenced and is in the appropriate position, and then decide whether to perform homing or display an appropriate message instead.
It seems to me that LinuxCNC has the appropriate pins and HAL components to do this, but I haven't thought about the details yet, because I only started this project today and, objectively speaking, I've already done a lot.

If someone would like to help me, that would be nice.

The task turned out to be a bit more difficult than I had anticipated.
Although HAL provides the pins and flags necessary for the required configuration, they cannot be easily utilized—for instance, simply by adding entries to an .ini or .hal file.
The developers of LinuxCNC recommend writing and compiling a custom "homecomp" component; however, I concluded that it would be simpler and more effective to modify the `src/emc/motion/homing.c` file.
Firstly, this modification is straightforward and requires only a basic understanding of C programming.
Secondly, the newly created pins are inactive by default; if a user chooses not to employ them, the system continues to function exactly as it did before the changes.
Thirdly, this is a versatile solution that could prove useful for other configurations as well.

Here is how it works:
 
 
The first image illustrates a scenario that, in principle, should not occur: the homing process for the Y-axis (joint 1) is blocked prior to the initial homing sequence. While this shouldn't happen, it was necessary to test it. As shown, all axes complete their homing process—with the exception of the blocked axis, which remains in its pre-homing state, as intended.
The second image shows the state after unblocking the Y-axis homing, performing a full homing sequence, executing some movements, re-blocking the Y-axis, and then running the homing sequence again. As can be seen, all axes complete their homing and zeroing—except for the blocked axis, which retains its existing homing status and position.
Now, it is possible to configure everything within a .hal file using standard LinuxCNC components. For example, to prevent an axis from being re-homed, you simply need the following line in your HAL file: As for the modified `homing.c` itself, it works as intended: it blocks the homing of a specific axis and displays a message informing the operator that the outcome of the homing process may differ from what they expected.
I suspect some of the changes might be redundant, which could result in the same message being displayed multiple times. I haven't been able to verify this, but it poses no real risk—it’s merely a minor nuisance. The message itself could also be refined to look better, though that would be a purely cosmetic change.

A brief summary of the changes:
I have added new boolean pins, `joint.N.homing-inhibit`, one for each axis.
By default, these are set to `FALSE`, so if they are left unused, LinuxCNC will behave exactly as it did before.
Setting a pin to `TRUE` will exclude that axis from the homing procedure—leaving it in its current state—and trigger a warning message for the operator. No other actions are taken.
 

I tested it on an real machine.
Unfortunately, it didn't work as intended.
That is to say, everything was fine when homing a single axis, but when homing all of them at once, things got really strange...
This sort of thing often happens when you're working with someone else's code. While it’s fairly easy to understand what a given function does, it’s much harder to figure out the order in which those functions are called.
Essentially, the state of the `joint.N.homing-inhibit` pins was being read at the wrong time—or, more specifically, it wasn't being updated.
Running a program with outdated data never ends well...

I took a bit of a shortcut, but I concluded that the `joint.N.homing-inhibit` pins should be ignored when homing all axes simultaneously. This is because the entries in the `.ini` file already define the correct sequence, ensuring that each axis is positioned in a way that allows the next one to be homed.
Everything is working as expected now.
The files in my previous attachment were for LinuxCNC 2.10-pre2, but since that version doesn't support EtherCAT, I’ve prepared a patch for LinuxCNC 2.10-pre1—the version I’ll continue to use.
In principle, the only differences should be in the line numbers (the `homing.c` files differ in length between the two versions). With a little tinkering, it should be possible to apply these changes to even older versions (though you might need to adjust variable types in the declarations).

I’ve also written a HAL file containing the necessary logic. It uses the `near` component to compare the position of the B-axis against a target value within a specified tolerance, and the `and2` component to verify whether the B-axis has been homed—ensuring that the reported position is reliable.
This can also be implemented without modifying LinuxCNC sources; however, instead of `joint.N.homing_inhibit`, you would need to use `motion.homing-inhibit`, which prevents homing for all axes. While not exactly the ideal solution, it is certainly much better than nothing.