During long lasting moves of a delta machine neither the temperatures are maintained nor buttons checked nor ... .
The fix is to call 'manage_heater()' and 'idle()' every now and then in the loop where the move is segmented.
The code is abot the same as in G2_G3 wher we had the same problem with too large circles lasting too long.
Fixing #7510
Travis is having problems at: https://github.com/MarlinFirmware/Marlin/pull/8560
So... doing a direct commit to get things correct. Bugfix_v1.1.x does not have this bug. Nothing needs to be done to that branch.
This will solve 2 issues on tool change.
1) when no home is done ("no_move" is set) tool change should never move X & Y because... I don't know where I am...only Z should be adjusted to avoid bed collision if other nozzle is lower than current.
Since no move no bed level matrix should be applied
2) When SWITCHING_NOZZLE is enabled and system is homed there are two movements to go to destination, but first can move Z to older position and then crash on the bed
include LPC1768 syntax for M42
couple more pin_t changes
consistency
change M42 to R, P format
Revert "change M42 to R, P format"
This reverts commit 01f12f579ec9ccc1bb9126e68d2c86449e9b7edf.
If using babystep to adjust the Z probe offset, the axis will move and the mesh will be updated at the same time, causing a doubling of the Z offset over the rest of the print.
To correct for this, the current Z position would need to be modified in the opposite direction, canceling out the additional Z offset added to the mesh. This would be confusing to users, and moreover it would not be accurate without also taking the current Z fade level and current Z height into account.
It might make sense to change the mesh in the case where no babystepping is taking place, but this could be considered an undesirable side-effect of changing the `zprobe_zoffset`.
One way to remedy this would be to return to storing the mesh with `zprobe_zoffset` included, then subtracting `zprobe_zoffset` from the returned Z value. Thus, a babystep moving the Z axis up 1mm would subtract 1 from `zprobe_zoffset` while adding 1 to all mesh Z values.
Without including the `zprobe_zoffset` in the `z_values` there is no safe way to alter the mesh in conjunction with babystepping, although it's fine without it.
