M303 D will now toggle activation of PID_DEBUG output. This allows the debug capability to be built into the firmware, but turned on and off as needed.
The code is slightly more optimized than it used to be and this has caused the setup and hold times on the Formbot T-Rex 2+ machines to be insufficient. This change gives sufficient margin and the LCD Display is clean again.
Something has shifted. The previous timing delays on the Max7219 debug displays is too tight without this correction.
I suspect something has been optimized and roughly 50ns of needed setup and hold time has disappeared.
This corrects the issue and the display results are clean again.
Some of the items in the Tool Offset Adjustment menu (in particular, the Z Offset!!!) were only adjustable with .1mm accuracy.
This is not enough. So the edit menu is switched to float52 to fix the issue.
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'.
Roxy-3DandScott Lahteine
