I don't use cia402 homing so someone else has to come with advice on that.
If you just want something that works you can use standard linuxcnc homing.
linuxcnc.org/docs/html/config/ini-homing.html

You can always revisit cia402 homing later on.
 

Hello,

I have now checked my entire configuration again.
I have also tried different homing methods.
Unfortunately, the error persists.
After homing is complete, the axes jump back and the servo shows Er87.1.
The axis is then referenced.
The error occurs on all axes.

Does anyone have any advice?

I installed a 1A FF miniature fuse for the Mesa.

I am unable to reproduce the error on the sim because I needed to trigger the probe while it was going to home or the starting location to start probing. This would cause a G38.2 error then the lockout would start. I ran a debug and returned a [Error] from a specific routine. I should have grabbed a screenshot.. I noticed a difference in the sim subroutines folder vs the subroutines folder I got from the github. I replaced all the files and lockout is no longer accruing

What Mesa fuse? There are PTCs to protect the 5V encoder wiring, if these trip, you have a wiring error.

All correct, see attached screenshots

Thanks for the clarification spumco. I had thought for sure Fusion 360 had said something as to not working 
on windows 10 machines as of 1-1-2026, but since it is still for the moment working on my Win10 stuff.
I must have been mistaken. I will have to look back to see how to do Win11 LTSC. And yes for me
I am still stuck having to use windows for certain things at work. UGH

I moved them

sim
axis
axis_mm_scurve

instead of the main folder.

andypugh just sent me the Tormach 9 axis code, I will be looking at that closely...

After further investigating, it seems when queue buster, M66 E0 L0  or G38.n is used, makes the preview disappear and sub call level is 1
Most of my routines are used for years, and when there were problems with LOG, and DO / WHILE loop and others, queue buster always helped.

I modified a probing routine for diameter inside, just moving with G1. #<queue_bust> can be set to 0 or 1 , to see the problem

the file example.ngc is used to call example_sub.ngc


 

 

I haven't wired them up yet, but the fuse issue also happened when the power amplifiers were connected.

The lower LED is slightly dim. I adjusted the voltage; it was 4.6V, now it's 5.1V. When I move the axis, the fuse trips immediately, but the wire only deforms slightly more. Is 1A too low, or is the Mesa fuse defective?

If I remember correctly, I've checked this back then and the the column R showed 0.0000 for G54 and other offsets. Clearing and saving the offsets did not help. Only G10 L2 P1 R0 resolved the issue. But since then, everything works fine. I will let you know, in case it happens again.

Here is a version, which creates a surfacemap.yml so the parameters persist throughout sessions. The variables like probe fast feed rate are still independent from the standard PB probing parameters. Maybe this can be aligned in a future version of this interface.