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.
- Fix G26 Circle Drawing.
- Add default extrusion settings so machine can print lines on print bed
- Yet to be done: Get LCD Menu's to use these settings.
* Merging early because of build failures. See #8105
* Make LPC1768 pinmapping not specific to Re-ARM
* Add HAL_PIN_TYPE and LPC1768 pin features
* M43 Updates
* Move pin map into pinsDebug_LPC1768.h
* Incorporate comments and M226
* Fix persistent store compilation issues
* Update pin features
* Update MKS SBASE pins
* Use native LPC1768 pin numbers in M42, M43, and M226
* Get UBL Mesh Generation, Mesh Save & Mesh Load working with 32-Bit platforms
* clean up read_data() and write_data() for non-LPC1768 HAL's
* Get read_data() and write_data() return codes consistent
All HAL's read_data() and write_data() return false if they succeed.
* Get read_data() and write_data() return codes to be consistent
Make read_data() and write_data() return true if an error happens.
* Say UBL is now checked out on machine types in default Configuration.h file.
* fixed some include paths
* LPC1768: Fix Serial API
Add missing serial methods used if TX_BUFFER_SIZE is set
Change return value of HalSerial:read to match Arduino API
* LPC1768: add filters to ADC
This is to try and compensate for hardware issue and oversensitivity to noise
* LPC1768: remove the polling section of delayMicroseconds
* LPC1768: lock usb mass storage device while device accesses it.
Currently only applicable to persistent store,
The device always has priority and will unmount the sd card from the host, Windows then tries to automount again so it can look like the explorer window freezes. Linux Mint, by default, just closes the Nemo window.
* Add timeout to make sure if Serial never connects that Marlin still boots
* Remove unneeded ifdef CPU_32_BIT
In general the need for ifdef CPU_32_BIT blocks means that something is missing from the HAL API or a Platform, in this case HAL_TICKS_PER_US was missing from the AVR Platform
* LPC1768: relocate RE-ARM debug_extra_script.py
Scott Lahteine