Re-homing fails in axis sim

[BsAtHome]

Running 2.10-pre directly from git master on Trixie.

A repeatable way to fail homing was discovered resulting in the message: Cannot home while shared home switch is closed j=2.

Scenario to repeat:

1. Start axis sim and set Estop=off, Machine=on
2. Home all axes (press "Home All" button) and wait for all axes to be homed
3. Unhome all axis (menu "Machine/Unhoming/Unhome All Axes")
4. Again try to home all axes (press "Home All" button)
5. --> error pops up

Other scenario to repeat:

1. Start axis sim and set Estop=off, Machine=on
2. Manually home X (menu "Machine/Homing/Home Axis X")
3. Manually home Z (menu "Machine/Homing/Home Axis Z")
4. --> error pops up

Manual order homing Y, Z, X in second scenario does work, but you still cannot unhome and repeat the homing as in the first scenario.

[Sigma1912]

That is because we have 'HOME_IS_SHARED = 1' for joints 0 and 2 in the ini file.
To rehome you need to move the X axis in the negative direction so the simulated shared home switch signal goes False . Not sure if this ever worked otherwise but this could probably be fixed by setting 'HOME_OFFSET = 1'
https://github.com/LinuxCNC/linuxcnc/blob/master/configs/sim/axis/axis.ini#L172

[andypugh]

Yes, this is a long-standing irritation with the Axis sim. I have often found it when trying to debug other things, but have always been more interested in the other thing....

[hansu]

The same for the gmoccapy sim configs. At least when you abort homing and try to re-home.

[BsAtHome]

Setting HOME_OFFSET of JOINT_0 to 1.0 does indeed solve the immediate problem. But you can still trigger the problem.

So, why is there a shared homing signal? Is this necessary for the sim? I can see an application in real machines, but in a sim?

[Sigma1912]

I don't think it is necessary. It may just be like that because somebody found a way to simulate it many years ago.
https://github.com/LinuxCNC/linuxcnc/blob/master/lib/hallib/simulated_home.hal

[andypugh]

I imagine it is to demonstrate the concept.
However, with a real machine you would be able to see which axis was on the home switch / end stop. With the sim it's a bit mysterious.

[hdiethelm]

Looking at the simulated_home.hal, it seams like someone long time ago did that on purpose. Not using a shared home switch is even simpler. The work around is easy. Just open halshow and jog until the home switch opens. In axis_mm, moving X negative or G53 G0 X-1 Y0 Z0 does the trick.

[hdiethelm]

That is because we have 'HOME_IS_SHARED = 1' for joints 0 and 2 in the ini file. To rehome you need to move the X axis in the negative direction so the simulated shared home switch signal goes False . Not sure if this ever worked otherwise but this could probably be fixed by setting 'HOME_OFFSET = 1' https://github.com/LinuxCNC/linuxcnc/blob/master/configs/sim/axis/axis.ini#L172

That only works if you don't move after the first homing and before second homing.

Changing that would be some quick search&replace work and a lot of testing afterwards for all the examples. There are a lot of them using this:

grep -r simulated_home.hal configs/ | wc -l
69

[BsAtHome]

Yes, the workaround is relatively straight forward. But the real issue I have is the feedback. The error message is cryptic and the recovery procedure hidden.

The procedure of re-homing (unhome, then home) should be a simple procedure. Any errors should give you at least a clear pointer to solve it.

The error message talks about "j=2" denoting the joint (who else knows that other than insiders?). The user interface is talking about axes. This example is trivial kinematics, so that has an easy mapping. There are at least two problems. Firstly, the user interface only allows you to home an axis whereas the system (internally) does not handle/home the axis but a joint. And secondly, more complex kinematics will be even more confusing. There needs to be a better way to streamline this.

[hdiethelm]

If you use shared home switches, then you will have this issue and due to the concept of splitting axis and joints which is needed for non trivial kinematics and even gantry machines, there is no way of generally telling which joint is the issue.

Options:

• Don't use shared home switches on in examples
• Fix the error message for XYZ and XYYZ (gantry) machines
  • Something like j=0,2 (Corresponding axis X and Z), manually move away from both limit switches
  • That could be a bit cumbersome duet to I think you can randomly assign joints to axis

I think most people having shared home switches in their machine know how to recover because they see what their machine is doing. However, people using the examples for testing will run into issues.

[Sigma1912]

I'd suggest to change the existing example configs to non-shared home switches and create a separate example config to show how to use shared home switches.

I could prepare a PR for this.

[Sigma1912]

See:
#3869

Please understand that I cannot possibly test all sim configs but I have tested homing and rehoming in all modified sim configs in the folders 'axis' and 'gmoccapy' except those in 'axis/qtvcp' and 'gmoccapy_qt_messages.ini' (due to issues with PyQt5 dependencies on my test PC)

[andypugh]

I support removing home-is-shared from the sim configs. It adds an unnecessary frustration for new users. And not-so-new too.