On many IDEX machines the allowed travel of the X1 carraige and X2 carraige does not perfectly overlap.
This helps the issue. But more work needs to be done at the higher level. (For example the X1_MAX_POS should probably be factored into G26's mesh validation pattern.)
- Clean up the API to use a `static` class instance to adhere to Marlin convention
- Add `const` position data access for read/write
- Add Storage capacity to the interface
agData in Table 71 is extremely oversampled (see Issue #11220). I have removed the data points that perform *worse* than linearly interpolating the remaining points, and fixed up two points that were simply rounded incorrectly.
Co-Authored-By: Aaron Griffith <aargri@gmail.com>
* Fix BLTouch homing
Deploy at start, dont call generic stow function at finish or raise goes too high before setting 0
* Update tool_change.cpp
* Update motion.cpp
* Update motion.cpp
* Update motion.cpp
* Update motion.cpp
* Change brackets to be more in align of Marlin coding standards
Indeed the HAL does not need to be mucked around with to expose ATmega2560 pins not available as numbers on the MEGA board, I'll need to update the wiki with that tidbit and a reference to the pin-mapping comment in `fastio_1280.h`.
The current Marlin implementation relies on a timer interrupt to start the ADC conversion and read it. However in some circumstances the interrupt can be delayed resulting in insufficient time being available for the ADC conversion. This results in a bad reading and false temperature fluctuations. These changes make sure that the conversion is complete (by checking the ADC hardware via the HAL) before reading a value.
See: https://github.com/MarlinFirmware/Marlin/issues/11323
It takes too long to display the mesh data for large mesh's at startup. We should consider ways to speed this up.
Perhaps it makes sense to display an entire row of the mesh instead of just one mesh point?