Unify run_z_probe

[AnHardt]

Unify run_z_probe
Implicates double touch for DELTAs when probing.
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
#4261

[thinkyhead]

Looks like now this should be…

line_to_axis_pos(axis, endstop_adj[axis], get_homing_bump_feedrate(axis));

[thinkyhead]

I rebased this on the latest code, then decided to make another tweak. Namely, it seems best not to include homing_feedrate_mm_m[Z_AXIS] as a default configuration option value, but to use a "factor" instead, which is multiplied by the homing feedrate.

// Proportion of homing speed for the first approach when probing
#define Z_PROBE_FACTOR_FAST 1
// Proportion of homing speed for the second approach when probing
#define Z_PROBE_FACTOR_SLOW 0.5

[AnHardt]

Changing to factor here would (for me) be repeating the same error.
With absolute speeds we have the full flexibility to use a factor, in the config., or not.
I admit using a variable here is a somewhat unusual construct. Do you have a better idea to get homing_feedrate_mm_m[Z_AXIS] into the config. (array defined)

Why homing_feedrate_mm_m at all? To give a speed that should work for most systems. But in principe they should be independent. At least that was my takeaway from #3975.

[thinkyhead]

I understand the point. But we cannot have (any more) configuration options that use named variables from the source code. So it has to be an absolute value or a factor related to some other reference speed.

Too bad the feedrates aren't all specified in one place.
Meanwhile, we could split them up a bit, like so…

#define HOMING_FEEDRATE_XY 50*60
#define HOMING_FEEDRATE_Z  4*60
#define HOMING_FEEDRATE {HOMING_FEEDRATE_XY, HOMING_FEEDRATE_XY, HOMING_FEEDRATE_Z, 0}  // set the homing speeds (mm/min)

. . .

#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z
#define Z_PROBE_SPEED_SLOW HOMING_FEEDRATE_Z / 2

[AnHardt]

Looks good to me. But i already hear Roxy moaning about to big changes in the configs.

The structure and order of the configs needs some more discussion, i think.
At the moment, for me, Configuration.h looks like after an earthquake.
With too much white space. Too long. Not in the order i would configure it for a new machine. ...
This should have a # in issues.

[thinkyhead]

Configuration.h looks like after an earthquake

Too many options? All out of order? Organization would be good!

[thinkyhead]

Ready to merge #4356