If the IDEX mode was previously set (via GCode or the LCD Panel) to a duplication mode... It was lost after a G28 due to this redundant setting of 'extruder_duplication_enabled'.
It is very important to the various use cases of IDEX machines that extruder_duplication_enabled is preserved across a G28. The reason is this allows a person to use the LCD Panel to put the machine into a duplication mode, and then send a 'normal' part file to the printer and get two parts out of the process.
Allow LCD Menu to adjust Junction Deviation lower than .01. Some machines currently have a JUNCTION_DEVIATION_MM value as low as .005 mm. In the case of non-Linear-Advance machines... The upper limit is raised to .5 mm.
Probably more thought needs to be given to the Linear Advance case. It maybe it doesn't need a special case and should just use the same bounds as the non-Linear Advance case.
The extra clutter was making the Junction Deviation patch script calculate the wrong value.
(The script wasn't smart enough to see the extra lines were commented out and used the wrong values in the calculation.)
All fixed now with a JUNCTION_DEVIATION_MM calculated at .017
Re-apply the formula .4 * V^2 / Default_Acceleration to work correctly in Raptor configuration.h file.
(The problem is there are multiple XJerk and YJerk values declared based on the step sticks used on the printer.)
This change should provide correct values for all setups.
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.)
Some of the Rotations did not do the right thing with setting and clearing pixels.
I think it is correct now. But if not... It is much closer to being correct.
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?
The registers within the Max7219 can get corrupted a number of ways. This allows the Max7219 to be reset and fully initialized.
And... it also allows the user to see the initialization pattern.
There is significant downside to breaking up the long line segments on UBL Cartesian machines. It adds a lot of extra computation but worse... It cuts out all of UBL's off mesh Z-Height correction checks. There have been a large number of people complaining about the nozzle going to infinity or crashing into the bed lately. They are being caused by
```
void unified_bed_leveling::line_to_destination_cartesian()
```
not watching over the segments being queued up for movement.
* Work around for serial buffer over run
PronterFace sends a lot of M105 commands. During long operations such
as UBL's G29 P1, G29 P2, G29 P4 and G26 this can over run the serial
buffer. This results (very often) in a M1 (actually a M1M105) ending
up in the command queue.
Until we figure out a better way to resolve this issue, this will keep
the UBL commands from experiencing bogus commands at thier completion.
A number of regressions were patched also. The UBL G29 P2 and P4 Press and Hold had stopped working. It is very possible this is broken in the bugfix_v1.1.x branch also.
The main purpose of the Pull Request is to get the 3-Point mesh tilting to use the LSF algorithm just like the grid based mesh tilt. This simplifies the logic and reduces the code size some what. But the real reason to do it is the 3-Point case can be solved exactly. And by feeding these numbers into the LSF algorithm it provides a way to check all that code for 'correctness'.
G26 uses logic that looks like:
```
ex = _GET_MESH_X(i + 1) - (SIZE_OF_INTERSECTION_CIRCLES - (SIZE_OF_CROSSHAIRS));
```
The Bi-Linear macros need parenthesis to work correctly.
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.
These changes may need to be warmed over. I tried to fix things with
the least amount of disruption. I just wanted to get the bugfix_v2.0.0
branch working for people again.
This is a non-intuitive change. @oldmcg says in this post https://github.com/MarlinFirmware/Marlin/issues/7572#issuecomment-340641207 that using DELTA_PRINTABLE_RADIUS is better than DELTA_PROBABLE_RADIUS for setting the probe limits. This is because the automatic probe code checks all locations for being reachable by the probe prior to doing the probe.
Roxy-3DandGitHub
