Incorrect Z position after Auto Bed Leveling (HOME is fine) #4612
Comments
|
I've just re-uploaded correct Configuration.txt in previous post. |
|
I think there's an issue with gri(d) bed leveling? Try without "#define AUTO_BED_LEVELING_GRID". Comment it out to use the 3 point leveling and also try G29 with and without v4 ("G29 v4"). I've had luck with that, but I'm still trying to track down the issue. |
Roxy-3D
changed the title
|
@bgort I know but I didn't see any solution to this. |
|
@tnw513 As far as I know, there isn't one yet. Was just letting you know in case you hadn't seen the others. |
|
@bgort Actually I had not seen one of the two :) |
|
running into a similar issue. using UBL, after doing calibration. once I start a print it starts over 1mm above bed, i end up compensating in my slicer |
|
I see something similar on my delta. |
Hmmmmm... We may need to add more debugging code to find where the problem is. I'm not seeing that issue. But I haven't been printing much the last week. I've been re-writing the mesh_buffer_line() routine to be faster. The good news (on the UBL) side is if we have to add debug code to figure this out, it shouldn't take too long to find the problem. Can you get a set of steps that reliably duplicates the problem? |
|
not sure.. ive tried too much stuff and now am confused more then ever. im trying G29 Z to get an offset only way i seem to be able to get the nozzle to the right height is using babystepping during the first layer. I need to start from scratch |
|
I had to create a new mesh a bunch of times while writing the software. Here is a shortcut: Put the nozzle in the center of the bed and let it grab 10 points. That is enough you should be able to start printing a Mesh Validation pattern. Verify you can get those 10 points dialed in and accurate. You can keep adding to the Mesh a whole bunch of different ways. |
|
For others with the issue, is it exactly 1 and 2 mm as you say? Or approximate? I'm definitely getting variation: 1.37, 1.35, 1.36. Usually clustered, making me think its based on the bed leveling plane, but can change significantly over time. This is definitely not an issue in rc4 with my configuration. I'm going to pull a fresh copy of rc7 (is this any different than rcbugfix?) And make as few changes as necessary to see if that even works with auto bed leveling. |
|
I just started over. reflashed, M502, M500 when i did a test print of a file.. the nozzle was aprox 2mm over the surface |
|
I'm not at home at the moment so I can't pasted any output. Then went I print a file from an SD card it would end up ~2mm off the bed. |
RC is just there as a historical point in time. It is when RCBugFix started getting fixes applied to it (for the current RC-#). You really want to be using RCBugFix. |
OK! That helps! Remember G29 Z is pretty much untested. If it can print... Can you do a G26 C P O2 and dial in 10 or 15 points? Does it start to print almost normal? And a G29 W will tell you all of the current important numbers that control the system. |
|
@adamfilip I just had an idea. The big difference between what you and I have is this: I have my Z_PROBE_OFFSET_FROM_EXTRUDER set perfectly so I don't have a Z_OFFSET. Can you try to move towards what I have? I'm going to do the exact opposite. I'm going to deliberately move my Z_PROBE_OFFSET_FROM_EXTRUDER out of calibration and try to do what you are doing (correcting with Z_OFFSET). |
|
Dear contributors to this thread. UBL-branch Please let's return here to RCBugFix, Grid levelling, different |
|
With ABL (no UBL :-) ) and RCBugFix. Seems that my probe is working fine: |
|
@tnw513 |
|
mmm... and what can I do to test? I've done a test with DEBUG_LEVELING_FEATURE defined. EDIT: new log. RCBugFix as of today: and and after G29 head is at exactly 0.5mm over the bed. |
|
In MarlinMain.cpp please add: @@ -2259,11 +2259,14 @@ static void clean_up_after_endstop_or_probe_move() {
DEBUG_POS(">>> set_bed_level_equation_lsq", current_position);
}
#endif
vector_3 planeNormal = vector_3(-plane_equation_coefficients[0], -plane_equation_coefficients[1], 1);
+ planeNormal.debug("plane_Normal");
+ planner.bed_level_matrix.debug("identity?");
planner.bed_level_matrix = matrix_3x3::create_look_at(planeNormal);
+ planner.bed_level_matrix.debug("directly after create_look_at");
vector_3 corrected_position = planner.adjusted_position();
current_position[X_AXIS] = corrected_position.x;
current_position[Y_AXIS] = corrected_position.y;
current_position[Z_AXIS] = corrected_position.z;And repeat the test you made the log with - but with |
|
Example output: If is not symetrc we have numerical problems in the calculation of the matrix from the normal. That would be not very nice but a thing we probably have to live with. != something is altering the matrix. Hard to find. |
When I started over my Z Probe offset from extruder is set to the correct amount of -17mm and my Z offset was Zero. but then i needed to add Z offset .9mm so Im adding the .9mm to my -17 to get -16.1 for my Z_PROBE_OFFSET_FROM_EXTRUDER |
I understand who has what... But I agree. @adamfilip let's start a separate thread for UBL Z_OFFSET issues. Otherwise, we are going to confuse everybody. Here is one more thing you are doing differently than me. You are actually measuring things, and trying to plug in numbers. In theory, that should work just fine. But the way I operate is I've always looked at what the error was, and corrected most of it, but always made sure I would not drive the nozzle into the glass. So, it takes me 3 or 4 tries to get the nozzle's Z_OFFSET_FROM_EXTRUDER exactly correct. But it is perfect after those 3 or 4 iterations. The reason I'm mentioning it is this: With the Z-Fade-Height active, it is possible there is a disconnect and either too much or too little Z-Height compensation is being done. And that compensation is going to change based on how much you are tying to correct. Please try 3 or 4 (or 7) iterations to get Z_OFFSET_FROM_EXTRUDER set perfectly. And try to do it on a place on the bed where you know things are relatively flat. And don't forget to do a M502 and M500 each cycle (I always forget to do that!!!) Mean while... I'm going to start setting up to go the opposite route and see what I find. |
|
New log: Matrix seems non altered. |
|
@tnw513
The position after G29 (grid/3point) is mostly determined by your settings for Z_PROBE_DEPLOY_HEIGHT, Z_PROBE_TRAVEL_HEIGHT, Z_HOMING_HEIGHT. To make a valid statement about the levelling, measure after G1 Z0 and also tell the related x/y coordinates. |
|
@Blue-Marlin Sure. In addition I've disabled min software endstop and I can go down until -0.5mm (nozzle is touching standard paper 0.1mm) on z axis. I've the following value defined: Even with Z_HOMING_HEIGHT undefined Z will go up before home (probably in order to deploy z probe). |
This is a little bit fuzzy for me to talk about. I don't remember all of the details. But I looked at this 3 or 4 months ago. I believe the non-symmetry is coming from the fact we don't have an .inverse() method to modify a matrix. Instead, in set_bed_level_equation_lsq() we use .create_look_at() to give us the correction matrix. The problem is, it does not assume the ability to create an inverse matrix to do its math. I think I remember it approximates the solution. The y_row is not even scaled an appropriate amount to compensate for the scaling of the x_row (and the non-scaling of the z_row). As a first level correction, it might make sense to calculate the y_row to get the y entry, but then use the x and z rows to fill in values to force the symmetry. And some extra reading I did at that time to understand things: stackoverflow.com/questions/349050/calculating-a-lookat-matrix Note all the comments about 'inverse' and 'inversion' of a matrix. If I remember right, I finished with the opinion that create_look_at() is not exactly correct. But it is a reasonable approximation. matrix_3x3 matrix_3x3::create_look_at(vector_3 target) {
vector_3 z_row = target.get_normal();
vector_3 x_row = vector_3(1, 0, -target.x / target.z).get_normal();
vector_3 y_row = vector_3::cross(z_row, x_row).get_normal();
matrix_3x3 rot = matrix_3x3::create_from_rows(x_row, y_row, z_row);
return rot;
} |
|
@ProffesorD Your bed seems to be too warped to produce a good flat matrix. Try using |
|
You are correct... I figured it out (had to dig out a straight edge). Even bilinear has a tough time. New bed ordered. Thanks again |
|
I am now advising people to z-offset like this: M851 Z0 ; reset a previous offset This way you probe in the same point where the nozzle is. That helped some guys to get a better Z-offset when their bed is tilt. But if the angle between nozzle and sensor trigger moves with the X axis there is nothing you can really do besides of stopping to use "auto-level" and simply level manually but still using z-probing for easier overall setup. |
|
Good tip, G92 would definately save some trial and error with m851. Also, I found that I had to set the Z offset AFTER bed leveling procedure. Not every time, but definately on the first setup I found the G29 would mess up my offset. |
|
Hello, G29 probes like it should, but offset is wrong afterwards, even at 0,0 (midpoint in round bed) and even if the nozzle was perfectly leveled on this point before. Have put log of G29 into gnuplot to see if probe measurements are way off, but Have tried to put EEPROM on, off, deleted, reloaded multiple times. Rotated the bed. G29 gives also deviations across multiple measurements, but not always on all points, of up to 0.3. |
|
@GesaP what kind of leveling are you using and are those values in the plotting mm, like +/- 2mm? That would be a lot. I would suggest you level the bed first manually and try again. You may also try to switch the leveling method. I wonder if there is a bug with leveling in a way that the G28 probing Z0 gets overridden by G29. Probably the whole G29 calculation should be normalised by the difference at the point where Z0 was taken. Or... G29 should "fail" if it is off by some amount. |
|
Hi oderwat, thanks for your reply. Yes, the results in the plot are mm. Do you mean by "manually" to tilt the bed until it is somewhat accurate/turn the leveling screws or to do G30 and then M851 on every point? And yes, my fixed delta height configured in the firmware gets overridden, but isn't that normal with the results of G29 stored in EEPROM? But my knowledge of how the printer stores the leveling results is limited (and they can't be accessed via M501). Just downloading the latest bugfix, can I just copy+paste all the files and migrate my config.h and config-adv.h changes? Maybe this will change things, though in the description it only says it fixed MBL. |
|
Used the latest bugfix now, still same behaviour. |
|
This is still an issue - i have had this for nearly a week, now with no reliable results. prusa I3, rumba. |
|
I have the same issue with marlin 1.1.8 |
|
I have the similar issue where it performs the auto bed levelling and if you get a piece of paper and check height it is fine but when you attempt to print it is approx 2-3mm off the bed, however this no longer is the issue when you turn off stealthchop and run the steppers noisy. works fine at that point. Just putting my problem out there, heck I even downloaded the latest version, changed my drivers over, recompiled and init the eprom and still exactly the same issue with bltouch 3.1 so I am at a loss but printing with noisy stepper motors. |
|
Hi all. I see this old thread is closed but people are still seeing the issue. I have the same with my Ender 3 and Marlin 2.0.5.3 Anyone found a solution already? |
|
Yeah I found the Z-Offset issue is related to some sort of driver problems namely with stealth chop but not limited to that alone. I originally had 2130 steppers and used the stepper drivers for those and in stealth chop it had the issue, I tried, with square wave, I tried with current settings (which made it better but still random issues), I tried with 0.9 deg steppers and 1.8 deg steppers and it was more obvious on 0.9 deg steppers, none the less anything I tried was still inaccurate with stealth chop mode on. (Finally found that S-Curve = off and Junction Deviation = off as well as Stealth Chop = off was the only way to get good performance and accurate prints and z-offset issues went away) When I changed the stepper drivers to 5160's the problem went away, at this point I also noticed an issue that I had with the Hemera E3D direct drive unit went away, the Hemera use to click randomly at higher speeds making me think my maximum feed rate was lower than it is now, my printing of Nylon can be done at 120mm/s where as before the maximum was 80mm/s and printing of PLA can be done at 150mm/s where before maximum was 100mm/s so mathematically I gained 50% more performance with the new drivers that use a different driver set in the firmware. Anyone who wants to challenge my finding can simply get those drivers and compare the two based on what I have placed above for information because I cant go back now as it put me out of action for 4 weeks chopping and changing. The issue with S-Curve and Junction Deviation is a separate issue to the Z-Offset but two issues made it all that harder to work out. Summary: 2130 Driver issue when using stealth chop and attempting maximum speeds increases problems and using stealth chop is impossible, this does not happen with 5160 drivers. Junction Deviation and S-Curve are separate issues to the inaccuracies of z-offset as those settings will mainly cause zitting issues and blobs on corners where speed changes on bends and hard corners effect the print quality and reverting back to original acceleration setting and classic jerk solve that issue and are not driver related. |
|
Please test the |
|
Same here. Tested latest bugfix-2.0.x branch, with TMC2209 (UART Mode) and BLTouch (Triangelab Clone, May 2020) the Z-Offset is completely wrong after a G29. Tested the current scenarios, all failing at the end due to a wrong z-offset when print starts:
Various combinations of S-Curve and LinAdvance doesn't seem to afflict the problem, at least in my case. While using Unified Bed Leveling I managed to "guess" by trial-and-error a usable value for Probe Z-Offset so that the first layer wasn't either printing in mid-air or scraping the bed. But of course, the value is completely wrong to what can be found with the proper calibration. While using Biniliear Bed Leveling instead, the only thing that made a difference was the "fade at height" option: if it was enabled, the print started far away from the bed; when disabled, the nozzle scratched the bed during the first layer. Manually adjusting the Z-Offset via baby-stepping would lead to a successful print, but that should not be the case scenario when using a probe and a bed levelling system. |
|
For what it is worth, I went back to 1.1.9 with this build below and don’t have the issue anymore on my Ender 3. |
|
@NeoMod — It would be better to post a new issue. General issues like "leveling is weird" can be due to any number of bugs, not necessarily the same bug that was involved in this August 2016 issue. |
|
Had the same issue today with Marlin 2.06 on a Anet A8 after messing about with the capacitive sensor position. |
|
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. |
|
I had the same issue as OP. My old Start G-Code I had: My new Start Gcode is: Theory behind this: For those interested, a Start Gcode without RESTORE_LEVELING_AFTER_G28: |
|
In my case it was fixed by tilting the bed a bit. I ran G29 V4 and one point was failing, causing the bed leveling to fail, which left my nozzle at the wrong height. It actually tried to go to "minus-two-ish", which is the distance it should go to (I think it tries to go to Z_PROBE_LOW_POINT, which is why it displays that value). However, when bed leveling fails, the Z value stays at the "minus-two-ish" value, and doesn't reset, causing the confusion in my case. TL;DR: |
|
My friend... You are a saviour... |
|
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. |
and others
As title when i issue G28 all is ok. Test with paper passed (some friction).
after send G29 the nozzle is higher than it should be. The same paper pass freely between the nozzle and the bed.
I don't know if there is a problem with my config file but seems ok.
Step to reproduce:
-Home (from display or G28)
//////////////////////////////////////optional
-Move Z to 0
-Move X and Y to center with a paper between nozzle and bed (position is ok)
/////////////////////////////////////
-Auto bed leveling (from display or G29)
-Move Z to 0
-Move X and Y with a paper between nozzle and bed (position is too high)
Latest RCBugFix: @405afec
Printer: Prusa i3 Hephestos
Configuration.txt
PS: same behavior with RC7. OK with RC6.
PPS: EEPROM activated (restored, reloaded ecc). I've tried to increment the distance between the probe and the nozzle (both in configuration file and EEPROM) and when with G28 the nozzle scratch the paper (obviously), with G29 the paper pass without friction.
The text was updated successfully, but these errors were encountered: