#440 "homed" icons in Axis (and other GUIs)

[Sebastian Kuzminsky]

Homing icons in Axis (and in the other GUIs):

• In joint mode, show which joints are homed (obviously).
• In World mode, do what exactly? Trivkins could show which axes (aka joints) are homed, but non-trivkins should maybe just show one icon meaning "the machine is entirely homed"?

[pkm]

Indeed, a fully parallel robot can be either homed or not. But a general LinuxCNC machine can have trivial axes like continuos rotary axis, which can be homed independently.

I suggest that the correspondence between joint/axes is established, which directly solves homing icons problem.
Technically it can be similar to HOMING_SEQUENCE attribute, e.g. each group of joints/axes has its number.

A few examples of actual kinematics:

a) all independent 0->X, 1->Y, 2->Z (trivial kins);
b) all dependent (0 1 2 3 4 5) -> (X Y Z A B C) - (Stewart platform);
c) all dependent, overactuated (0 1 2 3 4 5) -> (X Y Z);
d) mixed dependent (0 1 2) -> (X Y Z) + independent 3 ->B, 4->C (tripod + 2 rotary axes);
e) mixed (0 1) -> X, 2->Y, 3->Z (gantry);
f) two groups of dependent (0 1 2) -> (X Y Z), (3 4 5) -> (A B C);
etc.

E.g., for case d) joints 012 and axes XYZ belong to group 0, 3 and B to group 1, 4 and C to group 2.

For dependent axes homed icons should appear only when all correspondent (grouped) joints are homed.

This should also help with syncronized homing, which is really nesessary.

[pkm]

Actually, HOME_SEQUENCE itself is enough, provided that all groups should be homed simultaneously/synchronously.

[Sebastian Kuzminsky]

Your suggestion to add information to the ini file describing the joints-to-axes mapping would let us display per-axis "homed" icons, once all the joints in that axis' group are homed. This would continue the behavior of current (2.7 and older) versions of LinuxCNC, which show per-axis "homed" icons for all machines.

I'm questioning whether that's the behavior that we want. I don't think per-axis "homed" icons are useful. I suggest that we think of homing as purely a joint-mode thing.

I think the machine should start up in joint mode, with all joints unhomed (on an Identity kinematics machine the joints could be labeled with axis names, like they are now). The user initiates homing, and as each joint completes homing it gets annotated with a "homed" icon. When all joints are homed the machine automatically switches to World mode and the DRO switches from showing joints to showing axes. I'd prefer this mode switch to happen in Task or Motion, not in the GUI, so there's less room for variation in this behavior.

If the machine becomes unhomed (for example by having a VOLATILE_HOME joint and entering E-stop), the machine should leave World mode, go to Joint mode, and clearly display which joints are homed and which are not. It's then up to the operator to home the unhomed joints, resulting again in a fully homed machine, which will again switch it to World mode.

[pkm]

I agree with your point. No joints should remain unhomed in world mode. Then the automatic switching makes perfect sense: all homed -> go to world mode, unhomed -> go to joint mode.
But will it be possible to switch to joint mode and move a joint after homing? This better be hidden from end user, though.

[Sebastian Kuzminsky]

But will it be possible to switch to joint mode and move a joint after homing?

I see no reason to forbid this.

[Jeff Epler]

I think that the existence of joints mode needs to remain "mostly hidden" by people with "trivial enough" machines. This clearly includes traditional mills and lathes and I hope that it could cover gantries but that's of reduced importance—gantry operators will have to have to know about joint mode to resolve certain startup problems on their machines.

Basically, anywhere gentrivkins can be used I hope to have AXIS show individual home symbols in cartesian mode.

On the other hand, maybe for any system where "home all" is enabled by having a homing sequence, the individual homing indicators are of lesser importance anyway.