Support for manually deployed fixed probes

[brandstaetter]

Resolves issue #11858

[AnHardt]

Nice implementation.
Bad naming. Bad systematic.
A FIX_MOUNTED_PROBE has its name because it is fix mounted. Anything what could be removed or attached can't be fix.
For me the correct alternative would be a new probe type - MANUALY_DEPLOYED_PROBE.
Also thinkable is a complete change in the systematik to deploy and stow actions.
A probe type could than be described by a sequence of actions.
Actions could be for example:
sequence_start, sequence_end, do_loop, loop-while, deploy-path_1, deploy-path_2, deploy-path_3, stow-path_1, stow-path_2, stow-path_3, deploy-servo, stow-servo, deploy-solenoid, stow-solenoid, pause_for _user_action, trigger-test, trigger_test_p_target, trigger_test_n_target, probe_reset, ...
Maybe combined with adjectives, describing properties needed outside of deploy/stow, like:
triggered_when_stowed, iriggered_when_error, trigger_is_pulse, ...

A probe type can then be described by its adjectives and its deploy and stow sequences.
A MANUALY_DEPLOYED_PROBE would have a deploy_path_1 and pause_for_user_action.

[brandstaetter]

@AnHardt sounds good, but this would cause a refactoring/rewrite of a lot of logic. As the MANUALY_DEPLOYED_PROBE behaves a lot like the FIX_MOUNTED_PROBE this was the obvious shortcut. Can you open an issue for the rewrite of the probe logic with your ideas, I guess this should be planned properly and will take some time.

[AnHardt]

MANUALY_DEPLOYED_PROBE is just as similar to FIX_MOUNTED_PROBE as any other probe. FIX_MOUNTED_PROBE does nothing but switching ON. All other probes just add actions.
Implementation your way was just the convenient way.

[brandstaetter]

@AnHardt yes, that was what I was trying to say. I am sorry, English is not my native language. Also, I am a bit rusty in C++ so I appreciate any feedback to improve.

Will you create the issue to coordinate refactoring?

[thinkyhead]

It’s also a fine idea to make it a general option, simply allowing (for whatever reason) a message and wait-for-click to be inserted ahead of deploying and stowing the probe, even if it might be servo or something else. The Allen key probe would possibly benefit from this, for example. In that case we simply remove the condition around the config option:

- #if ENABLED(FIX_MOUNTED_PROBE)
-    //#define MANUAL_DEPLOY_STOW
- #endif
+ //#define PAUSE_BEFORE_DEPLOY_STOW

[AnHardt]

@brandstaetter

English is not my native language

Mine is German to.

Will you create the issue to coordinate refactoring?

Restructuring probe code again is not that high in my priority list. I dropped probes a lot with the introduction of BL-Touch. (political reasons - patents, pulse not a good concept - better use two pins for triggered and error, announcing Marlin compatibility - but in reality, only for high steprates in Z (at that time))
Restructuring anything was dropped in general until the 1.x.x branches go static. Time to reschedule.

But the doctors and me are afraid to do long term projects. They say reading github/MarlinFirmware does 'interesting' things with my EKG. I'd be much to involved. I should stop it - I can't - They call it addiction.

Currently i'm in rehab (for my heart), far away from home, with just a laptop, a MEGA, a DUE and a logic analyser. I'm missing testing on my printers, the big screens and the fast machines. Probably i can return to home somewhen in autumn. Then the time for the larger projects will comme. (Or better not? ???)

However. Thanks for the PAUSE_BEFORE_DEPLOY_STOW. That was missed since a looooooooong time.