Python Interface motion_mode fails to change with VOLATILE_HOME = 1

[jethornton]

If a joint has VOLATILE_HOME = 1 and all joints are homed the motion_mode is TRAJ_MODE_TELEOP as expected. Turn the power off and the joint(s) with VOLATILE_HOME = 1 are unhomed. The motion_mode does not change to TRAJ_MODE_FREE as expected when the joints are unhomed. If you only have one joint with VOLATILE_HOME = 1 the motion_mode does not change when you home that joint. If you have more than one joint with VOLATILE_HOME = 1 when you home the first joint then the motion_mode changes to TRAJ_MODE_FREE.

[rmu75]

I assume you observed that on current master branch. Is this a new problem?

[Sigma1912]

testing on current master shows that it is not just the python status but also the 'motion.teleop-mode' halpin that is not updating properly:

[Sigma1912]

Unhoming of joints set to volatile is handled here:

linuxcnc/src/emc/motion/homing.c

Line 283 in 69d26ee

static void set_all_unhomed(int unhome_method, motion_state_t motstate)

It seems that outside of homing.c we have no way of knowing if there are any joints set to volatile, we don't even know if 'set_all_unhomed(-2, motstate) did unhome any joints at all unless we explicitly check if all joints are homed after calling it.

Since this call may or may not leave joints unhomed we cannot switch to mode_free before calling it and there seem to be no provisions to do so after.

[andypugh]

VOLATILE_HOME is intended to unhome joints if encoder tracking is lost. I am not sure that amp-fault necessarily implies tracking lost.
The docs say that it is activated if machine power is off or e-stop is on.
The motion manpage doesn't say what amp-fault does.

[Sigma1912]

@andypugh
Note that amp-fault is not relevant in this issue. This one is about motion_state not reflecting joints unhomed by the volatile behavior.

The discussion about amp-fault behavior it should be moved to #3668