Closed houseofbugs closed 4 years ago
this seems to be a dubilate of #15450
@houseofbugs is the issue the same?
1.1.9 are not longer worked on actively by the maintainers (me not one of them) 2.0.1 is a frozen copy of bugfix 2.0.x so always best to use 2.0.x
Scott and I have been discussing this a lengths. It's still present on bugfix as of the time I made the post. Its not a huge discrepancy when you have a machine that is well dialed in physically and a probe that gets good accuracy.
The issue was alerted to me by a guy with a BL Touch that had poor accuracy so the skewed number was more noticeable.
I don't see it presenting itself too much on my machines but they are very well dialed in but it's definitely present on them. We're talking like 0.001mm of "drift" on them which is why it went unnoticed for a long time.
Things Scott and I discussed offline:
I believe the issue is somewhat related to the placement of set_bed_leveling_enabled(leveling_was_active); after all homing movement is complete. You're applying the leveling offset, and it sees where its supposed to be, but there is no command actually moving it to 5.0mm in this case.
Perhaps a flag is needed on set_bed_leveling_enabled to move to the expected readout position.
Another solution would be to move the Z post position command to after the apply leveling in the base routine instead of buried where it is now.
Keep in mind this is from a 20 minute glance and I havnt had time to sit down and test things in any in depth fashion.
In our testing with two CR-10S machines we see correct behavior.
The original post mentions that the Z position changes when you enable and disable leveling. This is completely normal. You want Z to change based on the mesh beneath it when enabling or disabling leveling. As noted it goes back to 5 when leveling is turned off, so the reciprocal correction is working.
Here's the boilerplate procedure that we need someone who can reproduce the issue to run for us:
bugfix-2.0.x
to test with the latest code.DEBUG_LEVELING_FEATURE
and M114_DETAIL
and re-flash the firmware.M111 S247
to enable maximum logging.G28
to do your standard homing procedure.G29
to probe the bed. This will also enable bed leveling.M500
.If the problem can be reproduced simply with G28
(as with RESTORE_LEVELING_AFTER_G28
) then just do some G28
and G1
moves so we can see some G28
output. If the problem appears at this point, great! We have some useful info, so:
If you need to do other things to get the symptom to appear, please take notes and report the exact steps needed to get the Z error.
Thanks!
I've been fiddling with this also since the live stream. I've so far been unable to produce the effect with ubl. It's something I'll be tinkering with and post if I come up with anything helpful.
I'm gratified to confirm, anyway, that the correction applied when turning leveling on and off is consistent. It is, after all, just adding or subtracting the same interpolated Z offset of the bed at that XY position, and that is not a number that will change as you turn leveling on and off.
As far as re-enabling leveling within G28
, the thing I would be most concerned with is that the current_position
is fully up to date and the planner is synced with the current XYZ before re-enabling leveling.
It also came up that now that we have the extra space and speed on 32-bit, there is no reason not to enable ABL_BILINEAR_SUBDIVISION
on those boards to get a somewhat better set of interpolated Z values.
I'm going to get more scientific with the testing. I have to print a dial indicator mount to test and see actual z height after the probe offset is set. The validation of something with the Z height "drifting" was that after back to back prints or steps performed the nozzle usually ends up closer and closer to the bed with each repetition. Resetting the machine or rebooting it fixes this. I wish I had more pinpointing as to what is doing this and will work to getting more data and videos showing the issue.
I strapped a Mitutoyo dial indicator on to a machine here with the latest 2.0.x bugfix flashed. Config is below that was used. I can 1000% for sure say this is NOT a hardware issue but a firmware bug.
I will test with the options you mentioned above and report back later today. I am dedicating many hours today to testing this bug.
Video of Testing: https://www.youtube.com/watch?v=fztDI3ns03M
Firmware Used: https://content.timothyhoogland.com/files/ShareXUpload/EZ300_1300CST_012520_2.0.xbugfix.zip
Machine Info: MKS Gen L EZABL V3 Kit TMC2208 on XY, A4988 on ZE Artillery AL-4 (modded) w/ Dual Z + Linked Rods + Dual Motors
In our testing with two CR-10S machines we see correct behavior.
The original post mentions that the Z position changes when you enable and disable leveling. This is completely normal. You want Z to change based on the mesh beneath it when enabling or disabling leveling. As noted it goes back to 5 when leveling is turned off, so the reciprocal correction is working.
Except in the video I posted above you can clearly see after homing the nozzle is the same distance off the plate and its showing 5.16mm when its actually 5mm. I am not seeing it "compound" the Z distance. It appears to always be off the same amount. If I put the nozzle at 0 when it shows 5.16 my nozzle is grinding into my bed.
Here's the boilerplate procedure that we need someone who can reproduce the issue to run for us:
- Download Marlin
bugfix-2.0.x
to test with the latest code.- Enable
DEBUG_LEVELING_FEATURE
andM114_DETAIL
and re-flash the firmware.- Connect to your printer from host software such as Cura, Printrun or Repetier Host.
- Issue the command
M111 S247
to enable maximum logging.- Perform a
G28
to do your standard homing procedure.- Do a
G29
to probe the bed. This will also enable bed leveling.- Save the mesh to EEPROM with the LCD or
M500
.If the problem can be reproduced simply with
G28
(as withRESTORE_LEVELING_AFTER_G28
) then just do someG28
andG1
moves so we can see someG28
output. If the problem appears at this point, great! We have some useful info, so:
- Paste the host log into a TXT file and drop this file into your next reply.
If you need to do other things to get the symptom to appear, please take notes and report the exact steps needed to get the Z error.
Thanks!
This is what I am testing now. Will post an output when I complete testing.
I did as asked. Here is what is odd. When using G1 Z0 it looks to be the correct height. But moving down the LCD displayed value (which was 5.14mm) from octoprint or the LCD puts the nozzle 0.14mm too low.
Log file: https://pastebin.com/aVWup3Uq
These look to be relevant to the issue being discussed here:
https://github.com/MarlinFirmware/Marlin/pull/15203 https://github.com/MarlinFirmware/Marlin/issues/15835
Thanks for the extra data and log. I'll review it and see what portion of the code is implicated. Hopefully it will be a straightforward issue!
At a glance, in bedleveling.cpp lines 91 and 99, functions appear to be reversed. It means one direction applies backwards and the other won't apply. Haven't had a chance to dig deeper as I've had a backed up drain in my basement to deal with today....
That code is correct. The leveling correction is being applied to the current position when turning it off, and the leveling correction is being removed from the current position when turning it on. So, if the nozzle is logically at 5.0mm but the bed is actually 5.14mm below the nozzle:
Good luck with the drain!
I hope it is now clear why the Z value flips between 5.0 and 5.14 when turning leveling on and off. As long as the bilinear offset at the current XY (194, 160) is in fact calculated to be -0.14 then this behavior is what you'd want.
One thing that can affect the result is Z fade, but I see in the logs that it is set to zero. Good idea, since that eliminates Z fade as being the cause of the drift.
Hmm… This looks suspicious. Let's look closer at this…
ABL Adjustment Z-0.122
current_position= X300.00 Y295.00 Z5.00 : Leveling ON
current_position= X300.00 Y295.00 Z4.88 : ...Now OFF
current_position= X300.00 Y295.00 Z4.88 : sync_plan_position
current_position= X0.00 Y0.00 Z4.88 : sync_plan_position
>>> do_blocking_move_to X-450.00 Y-450.00 Z4.88
It's at the start of G28
so it probably gets canceled out, but I need to make sure it's not backward.
Ya got me all paranoid about backwardness now!
your not alone in being paranoid it might be backwards that was the first idea that popped in my head also. the original report noted the issue compounded each time adding up over time but i have not seen this behavior at all. in my testing it seems to be working properly it just looks odd when the mesh data is applied. i still kinda think the real issue was hardware defect with the probe being very inaccurate that was the source of the issue i could be wrong.
Ok, nevermind. It's ok. I'm now looking at Z_AFTER_PROBING
which I didn't have enabled in my testing.
i have Z_AFTER_PROBING 5 enabled in my fork and for my testing did not see a problem. i think we might be chasing our tails on this one. being 100% sure is a good thing.
If I put the nozzle at 0 when it shows 5.16 my nozzle is grinding into my bed.
Bilinear interpolation is imperfect, and the probe offset also does matter. So there should be a bit of a slop margin considered. The firmware is convinced that the bed is 0.14mm below true zero where the nozzle is located. It is almost certain that this is wrong by some amount.
To help understand the way the mesh interacts with the Z position, can you repeat your test using a tighter grid, such as a 7x7 with ABL_BILINEAR_SUBDIVISION
enabled and set to 2…?
If I put the nozzle at 0 when it shows 5.16 my nozzle is grinding into my bed.
Bilinear interpolation is imperfect, and the probe offset also does matter. So there should be a bit of a slop margin considered. The firmware is convinced that the bed is 0.14mm below true zero where the nozzle is located. It is almost certain that this is wrong by some amount.
To help understand the way the mesh interacts with the Z position, can you repeat your test using a tighter grid, such as a 7x7 with
ABL_BILINEAR_SUBDIVISION
enabled and set to 2…?
I did that later today with a 7x7 and ABL_BILINEAR_SUBDIVISION
set to 3. No change.
your not alone in being paranoid it might be backwards that was the first idea that popped in my head also. the original report noted the issue compounded each time adding up over time but i have not seen this behavior at all. in my testing it seems to be working properly it just looks odd when the mesh data is applied. i still kinda think the real issue was hardware defect with the probe being very inaccurate that was the source of the issue i could be wrong.
I think the "compounding" is due to a machine issue, not firmware, I cannot replicate that. We can exclude that from the issue. That "issue" was what others said to me but I cannot replicate that. My experience is that it's always slightly off. The other issue is still present where the Z offset appears to be "drifting".
I'm at the point in your video where you move Z down with the LCD and it allows Z = -0.04 (which is 0.16 minus 0.20). So I think it is being constrained in motion but Z is perhaps not being corrected in that case. If that were happening, it would be possible to keep moving down to below the bed, and the Z error would compound … -0.04, -0.08, -0.12, -0.16…
So please check and see if moving Z from the LCD with leveling on leads to anything like this.
Of course, with leveling on, Z=0 should (ideally) be just touching the bed at every point, but again this depends on a good mesh.
The Z motion is constrained by the soft endstops, so depending on the Z min endstop there might be freedom to move Z below zero. But, there is no missing error correction. The constraint is done before the move is applied.
I don't have the min endstops set in my firmware for the Z Min direction
Took a shot in the dark after InsanityAutomation mentioned these lines. If I comment out lines 91 and 99 from bedlevel.cpp the ABL behaves as expected.
Z shows the correct value and when bed leveling is on (M420 S1) the Z is being adjusted when I am moving around from the LCD and USB GCode commands.
FYI in you can monitor the creep doing nothing but G1Z5\n M420S0\nM420S1 a dozen times, then G1Z5 and look at the difference.
FYI in you can monitor the creep doing nothing but G1Z5\n M420S0\nM420S1 a dozen times, then G1Z5 and look at the difference.
Is that with the lines commented out above or with them at the defaults?
Intact at defaults
Hi i think i have the same issue i am not an expert but i have inconsistent z-offsets i mean i have an EZABL woriking great the standar deviation is in the range of 0.001 - 0.003 so its working well (in fact i have tried 3 diferent sensors all in the same range of standar deviation and the problem stills
i explain myself , I start a one layer gcode to calibrate and babystep my z offset, i tuned in and get a precious first layer, the print finish and save the z-offset and the try to print te exact same code and now prints to far from the bed (get separate lines) SOOO i need to recalibrate my z-offset and again i get a good first layer, and try for the third time the exact same gcode and now the nozzle is too close to the bed and need to recalibrate again and so on so every print i need to recalibarte my z Offset i tried many solutions from here but with no luck
i am using SKR Mini E3 1.2 with my own compilation of marlin bugfix 2.0.x y did the verbose logging and let my TXT file here also let my Configuration files
i really hope you can help us with this or give some ideas i will be happy to try
Configuration Files.zip Log Z Offst drifting.txt
Thanks
Took a shot in the dark after InsanityAutomation mentioned these lines.
Well, that simply removes any correction when enabling/disabling leveling. It will only hide the problem, it doesn't necessarily mean this is the location, cause, or even evidence of the problem. And alas, those corrections are needed and can't just be removed.
Z shows the correct value and…
Just to be clear and reiterate:
5.00
to 5.16
.If the mesh said "the bed has no dip at this point," then Z would remain 5.00 and moving the nozzle down to the bed would be just dandy. But the mesh data says that the bed dips there.
If this is not the case then the mesh data is wrong. Better mesh data should help.
A good trick for double-checking your probe offset is to move to the particular spot where the machine homes to establish zero and check the mesh offset at that point using G29 Q
(requires DEBUG_LEVELING_FEATURE
… but not M111 ...
). It should be close to zero if the mesh data and bilinear interpolation are matching up well with the real bed, especially if it homes to the center.
I keep forgetting to ask, but it will help if you also paste the mesh output from M420 V
along with future comments about unusual mesh offsets. And also use G29 Q
liberally to see how much correction is varying over the bed. It's a good feature (though not as good as an OctoPrint plugin) for getting a picture of what bilinear interpolation thinks of your mesh data.
And of course, look at that 3x3 mesh and compare it to a 9x9 or 11x11 mesh of the same bed under the same conditions. A 3x3 mesh is too coarse to get reasonable readings of the bed height at all points. There could be a general dip from right-to-left, but at that particular spot on the bed it is relatively flat. A finer mesh is not just good for your particular heated bed, but also good … For Science!
There's an M420 C
command that will center the mesh around the mean average value (so the highest bump and lowest dip have the same magnitude). M420 C<offset>
also works. But don't use this for testing mesh results. It will throw off your data. However, it can be useful for some stuff.
In particular M420 C
is recommended for use along with correcting the probe Z offset. While babystepping does correct print height and can apply to the Z probe offset, it also makes the mesh data stale, so after babystepping to get a "perfect" probe offset you can just do M420 C
and M500
before the next G28
and your mesh data will be caught up. Or, just do a whole new G29
as usual…
In particular
M420 C
is recommended for use along with correcting the probe Z offset. While babystepping does correct print height and can apply to the Z probe offset, it also makes the mesh data stale, so after babystepping to get a "perfect" probe offset you can just doM420 C
andM500
before the nextG28
and your mesh data will be caught up. Or, just do a whole newG29
as usual…
Hi and thanks for your response but as i said i am a simple user can you ellaborate more in the 420 C command, about what to de next the M500 i mean i can do the M420 C then M500 where i put it or i have to do it before every print there is a way to put it in my start gcode
I have configured my starting Gcode to make an ABL (g29) routine before each print so this is way i dont understand if this command M420 C need to do it before each print hope you or someone can help me cause this bug is very annoying becaus even calibrating te z Offset i can not get repeteable good first layers (as i said calibrate and the next need to recalibrate)
Thanks and i will post the G29 Q as soon i get it from my machine thanks
I'm addressing @houseofbugs with the comments above.
sorry i misunderstand, but the question it still open i continue with te problem my z offset changes every print and ia have seen in 3d printing facebook groups some people have the same problem can you help us with that if there is something i can help (logs o replicateing the problem i am glad ti help
thanks in advance
Remember that when you have BABYSTEP_ZPROBE_OFFSET
enabled, babystepping changes your Z probe offset. As a result you must do a new G29
afterward to update the mesh for the changed height. If you skip the G29
the nozzle will be at the wrong height.
There's a catch-22 with babystepping such that we cannot adjust the mesh at the same time as adjusting the nozzle's position over the bed. In the near future we'll be exploring live mesh editing options to get a babystepping-like effect, and for 32-bit we can afford to do some other things that we held off on with AVR.
@houseofbugs has the problem by miracle been fixed when using 2.0.x bugfix ?
Here's some data from my repeated G29 tests. No G28 in-between. No restore-leveling option enabled, And no Z fade. Just a bunch of probing, print out some data, and G29
again… Perhaps this has enough information to reveal some correlations.
First trial with 6x6 meshes. Not much data collected…
Next trial. Much quicker 3x3 meshes. These show a less pronounced shift, but it is there.
--> STEPS PER MM: M92 X80.00 Y80.00 Z400.00 E95.00 (Each Z step is 0.0025mm)
--> ~~`RESTORE_LEVELING_AFTER_G28`~~ is DISABLED
--> Z Fade OFF
--> Probe Offset Z-0.16
is this fixed?
I think I am experiencing this issue on my printer. It will be tomorrow evening before I can complete any further testing and provide logs but it appears in both 2.0.bugfix from 7/20/19 and in 2.0.4.4. I upgraded because of issues with bed leveling. I also have to disable stealthchop to get accurate probing, is that a known issue? Should I compile a new build with current bugfix for testing or stay on 2.0.4.4?
@houseofbugs has the problem by miracle been fixed when using 2.0.x bugfix ?
Haven't had a chance to test yet.
I am having a similar issue when using M851 (probe offset) and bed leveling (bilinear or UBL both are affected) and RESTORE_LEVELING_AFTER_G28
The z-offset was random, after every so minor change of the z-offset.
After three days of pulling my hair out, the workaround was to explicitly enable bed leveling after G28
using M420 S
. This behaves as expected, even with RESTORE_LEVELING_AFTER_G28
still enabled
@houseofbugs still an issue?
Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Bug Description
Z Height is incorrectly set and shown on the LCD display.
Steps to Reproduce
RESTORE_LEVELING_AFTER_G28 Steps:
Enabling Bed Leveling from LCD Steps
Expected behavior: Z height should be the actual height set to the Z height after homing.
Actual behavior: It appears to be skewing the Z height after mesh generation based on whatever deviation your probe has. If you have a less accurate probe the difference in the Z height will be more incorrect vs a probe that is very accurate. Restarting the printer after every print "fixes" the issue but only for that 1 print.
I suspect that however the mesh is being applied after generation with these features is not using the value from G28 (or G28 Z) which is skewing the Z height. If you disable the RESTORE_LEVELING_AFTER_G28 and only use G28, G29 when starting a print the issue does not present itself.
This bug is present in Marlin 1.1.9 and 2.0.bugfix as of posting this