Why double touch probing is not a good thing.
It's widely believed we can get better __probing__ results when using a double touch when probing.
Let's compare to double touch __homing__.
Or better let's begin with single touch __homing__.
We home to find out out position, so our position is unknown.
To find the endstop we have to move into the direction of the endstop.
The maximum way we have to move is a bit longer than the axis length.
When we arrive at the endstop - when it triggers, the stepper pulses are stopped immediately.
It's a sudden stop. No smooth deacceleration is possible.
Depending on the speed and the moving mass we lose steps here.
Only if we approached slow enough (below jerk speed?) we will not lose steps.
Moving a complete axis length, that slow, takes for ever.
To speed up homing, we now make the first approach faster, get a guess about our position,
back up a bit and make a second slower approach to get a exact result without losing steps.
What we do in double touch probing is the same. But the difference here is:
a. we already know where we are
b. if the first approach is to fast we will lose steps here to.
But this time there is no second approach to set the position to 0. We are measuring only.
The lost steps are permanent until we home the next time.
So if you experienced permanently rising values in M48 you now know why. (Too fast, suddenly stopped, first approach)
What can we do to improve probing?
We can use the information about our current position.
We can make a really fast, but deaccelerated, move to a place we know it is a bit before the trigger point.
And then move the rest of the way really slow.
Unify run_z_probe
Add double touch for DELTAs.
Introduce Z_PROBE_SPEED_FAST and Z_PROBE_SPEED_SLOW
defaulting to homing_feedrate_mm_m[Z_AXIS] and homing_feedrate_mm_m[Z_AXIS]/2
This is an update of MarlinDev PR #196.
G20/21: support for switching input units between millimeters and
inches.
M149: support for changing input temperature units.
In support of these changes, code_value() and code_value_short() are
replaced with an array of functions which handle converting to the
proper types and/or units.
Follow-up the PR #3082
Follow-up the commit 143ad74: unnoticed updates
Fix for commit b0f5ba0: Z offset: -front [of the nozzle] +behind -> Y offset: -front [of the nozzle] +behind
Standardize the writing method: Z-probe, z-probe -> Z Probe
Adjust spacing
Aim: Test probes in update_endstops only when activated
Changes:
Configurations
Add define for FIX_MOUNTED_PROBE to handle the situation where formerly ENDSTOPS_ONLY_FOR_HOMING had to be set, or lowering the nozzle below Z_PROBE_OFFSET_FROM_EXTRUDER could give an "endstop hit" message.
Add define for Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN to indicate a common situation, that we have a probe but it is connected to an endstop pin
Add some comments
Shift some entries to have related things together.
Conditionals.h
We have a probe (HAS_Z_MIN_PROBE) if one of the pins is defined AND one of the probes is defined.
SanityCheck.h
Add some tests if the probe is connected and if we have defined a probe.
stepper.cpp
Changes to test the probe only when it is deployed (z_probe_is_active).
Test update_endstops() when the probe is deployed.
MarlinMain.cpp
a. set and reset z_probe_is_active in deploy_z_probe(), stow_z_probe() and dock_sled()
b. set and reset z_probe_is_active in the case a z-servo is moved to a defined position. The only remaining unhandled servo move is in M280 where we do not end in a defined position. If you want to handle a probe use M401/402
c. skip deploying/stowing when already deployed/stowed in the dedicated deploy/stow functions.
d. Handle the new FIX_MOUNTED_PROBE in parallel to a servo driven probe/endstop.
To do: In another PR. handle all probes in deploy/stow_z_probe.
Sort out SERVO_LEVELING vs. HAS_SERVO_ENDSTOPS.
If Marlin is blocking the serial input or command queue for any length
of time (for example more than 2 seconds), it needs to send a message
to serial out to inform the host that it is busy. Marlin should only
send these messages out when busy, and preferably not when trying to
print formatted output.
rebased
corrected spelling
changed to #elif for error
Still with MIN_Z_HEIGHT_FOR_HOMING but con be done with (folder wide) search-replace when we have a better name.
Renamed `WARN_REDUCED_ACCURACY` to `DISABLE_REDUCED_ACCURACY_WARNING`
Changed the condition for blinking from
```
#if ENABLED(WARN_REDUCED_ACCURACY)
```
to
```
#if DISABLED(DISABLE_REDUCED_ACCURACY_WARNING)
```
Replaced displaying "---" instead of the value of a coordinate when
unhomed or with reduced precision
with blinking the coordinate-prefix-character ('X','Y','Z').
For "unhomed" a '?' is shown every second second - until that axis is
homed. The value displayed is, as before the "---" where displayed, the
relative to the reset position coordinate value.
When the axis stepper was disabled, now we can display a hint on that,
by showing a blinking ' ' instead of the axis letter, when
WARN_REDUCED_ACCURACY is defined.
I suppose the code itself is here the better documentation.
A '+/-' character is in non of our charsets so i decided for a '?' for
now to reduce the work.
There is no additional space on the displays one could use to display
the information, so replacing something is the only option. As the axis
letters are totally redundant with their positions on the display they
contain the least information.
So my decision was to overwrite them.
