Quote
Roxy
The Fade_Correction factor is done in the G0 & G1 handler for efficiency. The printer only changes layers occasionally. So it saves a lot of CPU cycles by only doing it there instead of on every move. But there are a few other places where it has to be done also. I must have missed one in the LCD movements.
If you do a G29 P 0 T M A and just use PronterFace to move the nozzle around on the bed, is everything OK? I'm hoping the answer is "Yes!" because it won't be difficult to find the LCD problem.
Sorry but i can't say yes
Pronterface uses the following code to change the position
SENT: G91 SENT: G1 Z1.0 F200 SENT: G90
It seems that the G91 disables the leveling
A normal absolute G0 works fine in pronterface
And i found one line in the code that makes it unable to upload on a genuine Arduino, i already patched it:
--- a/Marlin/Bed_Leveling.h
+++ b/Marlin/Bed_Leveling.h
@@ -169,7 +169,7 @@ enum MBLStatus { MBL_STATUS_NONE = 0, MBL_STATUS_HAS_MESH_BIT = 0, MBL_STATUS_AC
#if ENABLED(DEBUG_LEVELING_FEATURE)
if (DEBUGGING(MESH_ADJUST)) {
- SERIAL_ECHO("??? Yikes!!! NAN in get_z_correction( ");
+ SERIAL_ECHO("??? Yikes!! NAN in get_z_correction( ");
SERIAL_ECHO(x0);
SERIAL_ECHO(", ");
SERIAL_ECHO(y0);
@@ -185,4 +185,4 @@ enum MBLStatus { MBL_STATUS_NONE = 0, MBL_STATUS_HAS_MESH_BIT = 0, MBL_STATUS_AC
#endif // UNIFIED_BED_LEVELING_FEATURE
#endif
due to the three "!" in the code they need to be sent to the controller. If the arduino ide send them it will break the communication with the updater.