Unhoming does not unhome all joints.

 

I just noticed that my version of qtplasmac does not cleanly unhome joints and leaves joints for the second Y axis homed if you unhome the Y axisAxis gets it right so it must be a UI issue.

Does this translate to an actual use issue ? I'm curious how linuxcnc handles it.
Also is your config a xyyz or a xyzy config?

It was in a XYYZ sim (default qtplasmac I think).
I noticed it while I was writing a component (and playing with the logic component) for somebody to get a pin that showed when all joints were homed and I could not work out why my code was failing...

Yes I have become aware that XYYZ vrs XYZY configs are not handled perfectly.
Dealing with joints in trivial machine is certainly been painful - programming wise

By the way, GSTAT can send a signal for homed/not all homed with a list of joints.
It would be pretty easy to make a python component to set pins appropriately - not real time of course, but that's probably not a problem.

I think the issue is really the unhoming.
I've never really understood as a user that started about when the joint axes got to V 2.8 when it was master why some of these features exist.
You walk up to a machine turn it on and home it at the beginning of the day.
I have no idea why users want kinstype=both so they can see joints before they home the machine. I just want to use the machine and I need to home it first.

When I first started removing kinstype=both was mandatory to support joint axes. That made sense to me.

I have no comprehension why one would want to unhome a machine.
Rehome yes, its useful. Sometimes My Z axis may loose steps when a sensor does not fire so rehoming the Z is handy.

If unhoming was not supported the problem would go away. If you must support unhoming, surely its not too much to ask to check if there are multiple joints and unhome them all.

Its really not acceptable that a GUI does not respect documented and expected behaviour.
I find it disappointing that after about 5-7 years, we still have not fully embraced the joint axes paradigm.

Anyway, thats the end of my red wine induced rant!
 

The fact that you just discovered that it didn't work as you thought, might help you understand why these things slip by.
Linuxcnc is complicated and you can skin a cat a million ways.
If someone doesn't exercise and notice the problem - I'll never know about it.
We fix the problems when we find and understand them.

And then there are corner cases. As soon as I make the action button unhome both joints, someone with a robot will ask why both joints unhome when he just wants one joint to unhome

anyways I will soon push a (hopeful) fix for this - thank you for the report.

Chris, you'll be pleased to know you are not alone. I caught a similar issue in a QTPYVCP confg today I was testing for someone.

Thanks for taking the issue on board.

And yes I fully understand that these things sneak through. The good thing is usually when I find a bug, people want to fix it!