Can anyone else confirm these Z behaviors with 3.0RC1
-
-
The reported height for the Z axis adjusts itself based on heightmap and babysteps.
I.E. If I home Z, 0.00 is displayed and when I move Z +1.00, the display changes to 1.00 (so far so good). If I move XY to a point where the heightmap says 0.099 correction, the Z display changes to 1.099. If I baby step Z +0.050, the display reads 1.149. I don't believe that either of those behaviors are correct. With the heightmap disabled, Z isn't changed on XY movement but baby stepping still affects it. TBH I don't remember if baby stepping always did that but I know that the heightmap correction was never included. -
The Z motors aren't actually moving when a heightmap correction is called for. They do for baby steps. I confirmed this with feeler gauges. At the initial spot where the display read Z 1.00, my 1mm feeler gauge fit between the bed and nozzle snugly. When I moved to the second point, the 1mm feeler gauge would no longer fit at all. So I homed there, set Z to 1.00 and measured with the 1mm feeler gauge and got the snug fit again. Moving back to the original spot and I had to use the 1mm gauge plus a 0.10 gauge to get the same snug fit. I disabled the heightmap I got exactly the same behavior except the displayed height didn't change.
I saw someone mention on another thread that they might have the same non-compensation problem on 2.x but I'm not sure if they're related.
-
-
I was just figuring out how to post this same exact observation. Changing back to beta12 fixes what I see as an issue with probing. Baby stepping wasn’t working like it should either. It’s as if the height map after probing is completely ignored. I’ve had to baby step up to .45mm farther to keep the nozzle from dragging, with RC1. Going back to beta 12 restores proper functionality.
-
If it helps, I am using 2.04 (2019-11-01b1) and the Z displayed in PanelDue and Web UI while printing is in 0.2mm layer height increments, even though baby steps and mesh compensation are enabled.
Keeping reported Z height consistent with the slicer's Z heights is intuitive IMO.
-
OK, I've solved the issue with the Z motors not actually following the heightmap... I had M566 "Jerk" set to 125 which was too low for the motors to respond. The result is that the displayed value gets the correction but the motors don't. When Jerk is set to a more reasonable value (600 in my case), the motors follow the heightmap and the display remains constant. I'm not sure when I set the Jerk that low but it's working now... Except during homing moves:
It seems that the heightmap correction isn't applied when homing so if you home Y and Z, move Z 1.00, then move Y to a spot where a 0.100 correction is needed, Z moves with the heightmap and and the display stays constant. If you then move (G1) Y back to 0.00, the reverse correction is applied and everything's fine. If you home Y instead of moving back to Y 0.00, the correction is NOT applied so both the actual and displayed height is Z 1.100. This is cumulative! If I move Y back to the spot with the 0.100 correction, the correction is applied but if you home again, it isn't so the displayed and actual height is Z 1.200.
-
Well, I can't reproduce the issue with the heightmap not being applied relative to jerk (with me being the jerk
).Still have the issues with the heightmap not being applied on homing and with baby steps being applied to the Z position display.
