task: unhome VOLATILE_HOME joints on any motion-disable edge

[grandixximo]

Summary

• Fixes With VOLATILE_HOME = 1, triggering an end-stop disables the machine but keeps the axis homed #3954. With VOLATILE_HOME=1, tripping a limit switch (or amp-fault, ferror, misc-error, spindle-fault) disables the drives but leaves all joints flagged as homed. Only ESTOP and F2/machine-off paths cleared the homed flag.
• Adds a 1->0 edge detector on emcStatus->motion.traj.enabled in the task main loop. On the edge it calls emcJointUnhome(-2), which unhomes only joints marked VOLATILE_HOME. Estop and machine-off continue to do their own unhome and remain idempotent.

Why this scope

• VOLATILE_HOME is opt-in. A user setting it has declared the joint cannot hold position when its drive is off, so the discriminating event is "drive disabled", not "task state went OFF".
• Three reports over five years (With VOLATILE_HOME = 1, triggering an end-stop disables the machine but keeps the axis homed #3954, joint.N.amp-fault-in does not unhome joints set to VOLATILE_HOME = 1 #3668, plus a 2021 forum thread linked in With VOLATILE_HOME = 1, triggering an end-stop disables the machine but keeps the axis homed #3954) all hit the same gap. Per-cause patches would miss the next path; an edge detector covers limit, amp-fault, ferror, misc-error, spindle-fault and any future cause uniformly.
• Default is VOLATILE_HOME=0, so configs with absolute feedback are untouched.
• Soft limits do not disable motion, so they do not trigger an unhome. This matches the contract: home is only lost when the drive is actually cut.

Test plan

• Sim config, VOLATILE_HOME=1: home X, jog Y into a hard limit switch. X loses homed status.
• Sim config, VOLATILE_HOME=1: home X, ESTOP. X loses homed status (existing path, regression check).
• Sim config, VOLATILE_HOME=1: home X, F2 off. X loses homed status (regression check).
• Sim config, VOLATILE_HOME=1: home X, hit a soft limit. X stays homed (drive not cut).
• Sim config, VOLATILE_HOME=0: home X, trigger a fault. X stays homed (no regression).
• Hardware (stepper + limit switch): reproduce the exact With VOLATILE_HOME = 1, triggering an end-stop disables the machine but keeps the axis homed #3954 scenario.

[BsAtHome]

There may be some tab/space indent mismatch.

So, if a joint fault does not trigger machine off or estop, then this is not triggered? How is the specific joint unhomed in that case?

[grandixximo]

There may be some tab/space indent mismatch.

So, if a joint fault does not trigger machine off or estop, then this is not triggered? How is the specific joint unhomed in that case?

The only only fault that does not machine off (that I could find) is soft limit, and if machine did not go off, joint should still be in good position, homing should still be valid.
amp-limit already turns off the machine, so no need to loose homing independently.

[BsAtHome]

But that means you must have any joint's fault signal(s) wired up so that the machine goes either off or in estop. Otherwise, your joint may lose tracking and linuxCNC is not aware of that.

[grandixximo]

But that means you must have any joint's fault signal(s) wired up so that the machine goes either off or in estop. Otherwise, your joint may lose tracking and linuxCNC is not aware of that.

Which joint fault does not turn off the machine? limit switches machine off, amp-fault machine off.

[BsAtHome]

That which comes from external (like a signal from the drive controller hardware).

[grandixximo]

That which comes from external (like a signal from the drive controller hardware).

I cannot find a fault path that disables a single joint while leaving the machine on. joint.N.amp-fault-in, hard limit, ferror, misc error, spindle fault, all route through emcmotInternal->enabling = 0, which disables whole motion (traj.enabled 1=>0). edge detector catches that uniformly, so every fault visible to the core unhomes volatile joints.

I cannot find a "one joint faulty, machine stays running" mode, if it exist I can hook signals to unhome only the effected joint that's faulty and volatile.

[BsAtHome]

If there is no path for a single joint failure while the machine stays on, then that is just the way it is and this solution will be adequate to fix the current problem.

If anybody wants to use such a single-joint-failure-mode feature (probably only for very special robotics), then they can send a patch ;-)