Change XY_PROBE_SPEED format to (x*60)

[qwewer0]

Description

Changing XY_PROBE_SPEED value format to match the other mm/m feedrate formats in the configurations.

Benefits

Feedrate format uniformity.

Related Issues

None

[thinkyhead]

The "natural" unit for feedrates is the mm/m value used with the F parameter, so mm/m feedrates that are now expressed in whole mm/m values don't need to be re-expressed in mm/s. The reason for using x*60 inside of the manual feedrates array was only to make it easier to see the relative proportional speeds between the elements of the array, not because mm/s is in any way a better or more comprehensible unit for feedrates.

[qwewer0]

My idea was to use the same format for XY_PROBE_SPEED as for HOMING_FEEDRATE_XY, HOMING_FEEDRATE_Z, MANUAL_FEEDRATE.

If we’re already here, may I ask why DEFAULT_MAX_FEEDRATE is in mm/s?

[AnHardt]

For historical and (backward) compatibility reasons we have to use mm/minute for the F-parameter. (maybe inch/minute in inch-mode). For the average feedrates used in early CNC-machines that made perfect sense.
With the faster speeds our 3D-Printers are running at, at least some of us, have a better feeling/intuition for speeds in mm/second.
For Marlin internal calculations we one day decided to use mm/seconds. At least for a while we targeted to write down our configuration parameters in mm/second, but have not been strict with that (like always).
On the other hand the "x*60"-notation for values in mm/minute is very attractive because the users with a good 'feeling' for mm/s can easily throw in their numbers and those with a better 'intuition' for mm/minute can easily omit the "*60" . The same would be true for "x/60.0". So in the config-files this is not critical.

Adjusting by g-code is much less satisfying - we can't calculate but only read numbers.

On the long term a calculating parser could be useful.
On the short term we could make a mode-setting for the speeds/feedrates used in g-code:

• TRADITIONAL - mixed - like it is today
• MM_PER_MINUTE - all speeds in mm/minute for all g-codes and F
• MM_PER_SECOND - all speeds in mm/second for all g-codes except F
• STRICT_MM_PER_SECOND - all speeds in mm/second including F

Internal representation should stay in mm/s.
Don't know what to do with M503. It, at least, needs a hint about the mode.

[AnHardt]

For the derived units, like accelerations, mm/minute becomes really ugly. I would not like to see mm/minute²

[qwewer0]

Yeah, a uniformity of mm/m, mm/m² or mm/s, mm/s² would be nice, but I know it isn't an easy/quick task to change it all.

IMO, the ideal option would be at first

MM_PER_SECOND - all speeds in mm/second for all g-codes except F

then in the distant future to have it as

STRICT_MM_PER_SECOND - all speeds in mm/second including F

with a legacy option in the configurations to have the F parameter in mm/m.

[AnHardt]

mm/m

mm/m is millimetre/meter = 1000. Always!
Maybe mm/min is acceptable.

[qwewer0]

mm/m is millimetre/meter = 1000. Always!

I think mm/m is short for mm/min in the configurations.

[AnHardt]

Then take it as an error-report.