MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.25k stars 19.23k forks source link

G29 Issue #5898

Closed aaronthomaswebster closed 7 years ago

aaronthomaswebster commented 7 years ago

I have built my own CoreXY printer and I am running into issues with G29. It does not seem to be working... My printer is trying to compensate but seems to be too close to the bed in the front right and too far away in the back left. I could post all my firmware settings but I was hoping to ask for some advice first.

I am running Marlin 1.1.0-RCBugFix - 6

aaronthomaswebster commented 7 years ago

Ok, You guys have been so helpful and I think I am going to try to redesign my printer a little bit. As you can see above in my configuration file my z probe is a pretty good distance from my hot end, I'm going to redesign the mount for my probe and see if I can get more consistent results.

benlye commented 7 years ago

@Bob-the-Kuhn I'm not massively surprised - you seem to be at the same point I got to with this - for all intents and purposes the software seems to be doing the right thing.

Nonetheless, this issue affects multiple people, so something is still up. If we can conclude that the software is working, I guess we then need to look at our hardware.

The only other question I had was whether somehow the printer isn't capable of calculating and applying the Z-offset compensation quickly enough in a printing situation, which is why our non-printing tests conclude that everything is fine, but prints don't come out as expected. I'm new to this, but from looking at the code it seems that all of this happens in the planner, and the z-offset compensation gets applied to the moves as each g-code line is processed. I can't see any reason why it would, but I wonder if (for example) print speed would have an effect? Is there anything else different in a printing situation?

@aaronthomaswebster I'm interested in how you get on. One of the things I'm looking at is my z-axis and replacing the motor couplers with ones with much less vertical give. I'm wondering if the springy-type couplers have too much play in them when the extruder is at the edge (where I see this problem) , therefore putting more weight on the coupler, compressing it, and reducing the Z height.

Thanks all for your continued effort.

Bob-the-Kuhn commented 7 years ago

@benlye - The print speed won't affect the compensation.

The planner creates a structure for each move command that includes the number of steps and direction for each axis. The stepper then executes that block. The compensated Z is computed as part of creating that structure.


@aaronthomaswebster - getting the probe closer to the nozzle just means you can probe more of the bed. It shouldn't affect the probe's accuracy.

You may want to consider switching to another type of probe. It appears that your inductive probe triggers at different heights around the edges vs. in the interior.

oderwat commented 7 years ago

Well I posted it here before and it helped some people in a community I frequently participate in:

; Heat up like for printing
M851 Z0 ; Z-Offset Reset
G28 ; Homing all axis (in the middle of the bed)
G1 X110 Y110 ; put nozzle! into the middle
; move nozzle down to hardly grip some paper
G92 Z0 ; mark this position as Z zero
G30 X110 Y110 ; let the sensor probe in the middle (where z for the nozzle actually is zero now)
; G30 Z Bed is the (negative) Z offset
M851 Z-1.23 ; 1.23 as example .. set the offset 
M500 ; store it to the eeprom

This procedure is able to compensate tilts between nozzle and probe (from bed or axis) which otherwise is ignored by the original procedure. This way you measure Z offset at the same spot where you let the nozzle touch the bed.

I suspect a lot of problems in Z-offset shifting between different positions of the bed. So you may want to try the above procedure at X20 Y20 and X200 Y200 and other parts of the bed. If you get different values for the z-offset it can't never work reliable!

oderwat commented 7 years ago

@Bob-the-Kuhn "getting the probe closer to the nozzle just means you can probe more of the bed. It shouldn't affect the probe's accuracy." ... not not fully true. It does effect the difference I describe in the post above. Just think of a 2mm height bump where the nozzle is while there is none where the sensor is. But it also changes how much tilting in the axis affect the z-offset stability. just think of a change in the tilt when the head moves. the farther the distance between sensor and nozzle tip, the more variance in the z-offset when the head tilts.

Bob-the-Kuhn commented 7 years ago

@oderwat - you got me to scratching my head.

Yes, the bed tilt definitely affects the relative heights but I don't think that makes a difference when doing bilinear auto leveling.

With bilinear leveling the software stores the probe's location along with the Z compensation for that point. When printing the planner uses that same compensation when the nozzle is at that point.

It does point out one thing I hadn't considered. You need to be fairly accurate in the X & Y offsets in the configuration file. If you have a 200mm bed that tilts 2mm, then a 5mm error in the X,Y offsets will give you a 0.05mm error in the compensated height.

Using the procedure you detailed, the bed has to be very flat or else you'll get different z-offsets. Doesn't matter if the bed is tilted, just that it's flat.

It appears to me that, with bilinear leveling, the main error contributors are:

oderwat commented 7 years ago

I am talking about the z-offset measurement, not about probing points. People had the problem that their G28 fits at X110 Y110 but not at other points e.g. after G29. I can only repeat: Think of a bed with a "bend" at the place where the nozzle is, but distant to the probe location. Your initial probe-z-offset measurement will be off from the real value. This is true for bends and tilts of bed or axis. To compensate for that I came up with the z-offset measuring procedure I described above. Until you understand what this is about, there is an important piece missing in my opinion. As mentioned before, I had multiple people which complained about not working G29 ... and after "begging" them to use above procedure for z-offset measuring, the problem vanished.

Besides that, measuring the z-offset at different points is very interesting. As I said: It needs to be constant everywhere and "logically" it should be in the range of the probe accuracy. But in reallity it may not be constant! Take the normal prusa setup with two horizontal rods holding the printer head carriage. If one of the rods is "farther back" on the right side, the whole head will tilt backwards with increasing x position. This will introduce a change in the distance between the nozzle and the probe position (the z-offset), as with the tilting head, the probe may be higher in relation to the bed than the nozzle at that point. So you may probe there and even compensate for the XY offset, but you can't compensate for the sudden Z offset.

People get confused about "z-offset" and probing points. Z-offset is the distance from the nozzle tip to the probe trigger location, which has to be constant over the whole bed. If it is not, you can't reliably probe at another location. Technically it degrades the probe accuracy and may be related to the XY position and "could" be another factor which needs compensation. Afaik this is even implemented in some firmware which uses the IR difference sensor.

oderwat commented 7 years ago

With bilinear leveling the software stores the probe's location along with the Z compensation for that point. When printing the planner uses that same compensation when the nozzle is at that point.

This is the problem :) if the nozzle and the probe at this position have a new error introduced which makes the stored z-offset (which was measured at just one point in the middle of the bed) not reflecting the real distance between nose and sensor trigger point at this place.

One easy to see and understand way to describe a similar effect: Think of having the probe cable being too stiff and "bending" the probe different at different bed positions. It would be immediately clear, that this destroys everything. Having a (variable) tilt in the head will do the same.

thinkyhead commented 7 years ago

There's another "hidden" way to find out exactly how much compensation is being applied at the current XY position. This should probably be added to M114, but for now…

If you have DEBUG_LEVELING_FEATURE enabled (and use M111 S8 to enable it) then you can use G29 Q to get a report that includes how much Z adjustment is being applied at the current point. The line looks like this:

echo: ABL Adjustment Z-0.04

...or for planar leveling...

echo: ABL Adjustment X0.01 Y0.03 Z-0.01
Bob-the-Kuhn commented 7 years ago

@oderwat - I'm aware that there can be a significant difference in the bed height between the probe's position and the nozzle's position. I just don't think it matters when the nozzle is within the probed area and bilinear leveling is used.

Having a consistent Z_offset across the bed is very important if you're using 3 point or linear bed leveling. These methods assume the bed is a tilted plane. You can't have a consistent Z_offset if the bed has peaks and valleys.

oderwat commented 7 years ago

@Bob-the-Kuhn well you still don't get it, but I tried. Hint: "Z-Offset = Distance from nozzle tip to probe trigger (needs to be constant to create a valid measurement)" "Z-Compensation = Value of the ABL correction (is changing and calculated from probed points)".

Bob-the-Kuhn commented 7 years ago

A mighty fine discussion of apples vs. oranges.

I agree with the above statements.

My comments were aimed at when having a constant Z offset mattered and when it didn't (assuming that the probe wasn't the source of the inconsistencies).

BillStruve commented 7 years ago

Seems to me that G29 should have 3 offsets, z, x, and y between the nozzle and the probe. As I understand, the z correction is applied to the nozzle position (x,y) but it is calculated from data when the probe is at position (x+dx,y+dy). In my printer it doesn't matter since both dx=0 and dy=0, but commonly both will not be zero.

ghost commented 7 years ago

I know that the issue that I have with Bilinear ABL is, it was air printing in the position of X120 - X185 (worse when closer to the edge (X185)) and was scraping tape from X0 - ~X70.

I seriously thought my probe was inconsistant. I ran repeatability test at every point that it would probe in the 3x3 grid (9 points). I gathered data from the repeatability test ever 5 different times and plotted them in Excel. I was looking for an issue. I found that my probe was within .003mm throughout all of that.

My glass and bed is fairly flat and can get it to print ok without any software bed leveling.

MBL has worked better than without it. I never thought to check the Z offset at each point. Mainly thinking that my probe isn't moving.

I have more testing to do.. Thanks guys!

Bob-the-Kuhn commented 7 years ago

@BillStruve - during G29 the head is moved to (X, Y) which means the probe is at (x+dx,y+dy). G29 then saves (x+dx,y+dy) and the probe results. During moves the planner applies the probe results when the nozzle is at (x+dx,y+dy).

Bob-the-Kuhn commented 7 years ago

@BillStruve - can you point me to the info on your print head system?

I've heard of systems where the nozzle is the sensor but I haven't found any.

How repeatable is your system (M48 type results)?

Bob-the-Kuhn commented 7 years ago

What inductive sensors are you guys using?

I'd like to play with a couple and see how they perform.

benlye commented 7 years ago

I use this one: https://www.aliexpress.com/item/M18-8mm-sensing-DC-5V-NPN-NO-LJ18A3-8-Z-BX-5V-cylinder-inductive-proximity-sensor/32719316657.html

It seems to work very well, with good repeatability and accuracy across the bed. For example:

M48 P10 X105 Y93
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.062250 Min: -0.065 Max: -0.060 Range: 0.005
Standard Deviation: 0.001750

The worst range I've seen across a 10-probe sample is 0.015, with SD of 0.004899.

oderwat commented 7 years ago

@Bob-the-Kuhn please get your terminology right "Z-Offset" is what is stored with M851. This needs to be constant on the physical side for any type of ABL to work. What I am talking about us not comparing apples with oranges and can't be ignored. It simply is the explanation for problems real people have with their real systems.

@benlye try the following to see if your system reports constant z-offsets:

Get the four extrem points for you abl measuring from the configuration. For example X20 Y20, X200 Y20, X200 Y200, X20 Y200. You can also just choose 4 points in the corners of your bed.

Then do the full procedure below for each of those points and for X and Y at half your bed size (aka middle of your bed), for example at X110 Y110. Using your values for the 5 different positions instead of 110 in the example below.

; do this once
M851 Z0 ; Z-Offset Reset
G28 ; Homing all axis (in the middle of the bed)

; do this for every point
G1 X110 Y110 ; put nozzle to the measure point
; move nozzle down to hardly grip some paper
G92 Z0 ; mark this position as Z zero
G30 X110 Y110 ; let the sensor probe in the middle (where z for the nozzle actually is zero now)
; note Bed Z value for X110 Y110

This will measure at which height relative to the nozzle the probe does trigger at your chosen points. The value should be as accurate as your M48 Sensor results and constant over all points. If there are bigger differences at different bed positions your z-offset is not constant and ABL can't not work probably. If that is the case you need to find the problem with your hardware first.

ghost commented 7 years ago

Shouldn't that be G28 Z, if you want to home in the middle of the bed?

oderwat commented 7 years ago

@Tannoo not with a probe setup, they usually (always?) probe at the center of the bed. It also doesn't matter here. It is only needed to initialise the positioning. The important factor is that you G1 and G30 to the same point. This is the only way you can check if your z-offset (aka M851 aka distance between nozzle and probe trigger point) is constant over your whole bed. This is the basis for everything else and as important as the probe repeatability error.

I made a small correction to the procedure because you only need to reset the z-offset and initialise the coordinates once.

ghost commented 7 years ago

Ok, but a G28 with or without probe will put my nozzle at 0,0,0. Center of the bed is roughly 80,80. So, G0 X100 Y100 to put it near the center then home Z wit G28 Z. Then continue as you stated.

I'm just getting it clear on what you want done for when I get to do it later this morning.

ghost commented 7 years ago

Well, with the probe, the nozzle doesn't get that close to the bed. Nevermind about the swap.

I haven't used the probe for quite some time.. You'll have to forgive me.

ghost commented 7 years ago

Z_SAFE_HOMING needs to be enabled to home Z in the center by default.

benlye commented 7 years ago

Well, what do you know, my Y_PROBE_OFFSET_FROM_EXTRUDER was out by 2mm!

I just reset and recalibrated by bed settings as accurately as I think I can. I'll repeat some tests later today, including checking the Z-offset in each corner as well as the centre.

BillStruve commented 7 years ago

@Bob-the-Kuhn I'm confused, how can "G29 then saves (x+dx,y+dy) and the probe results" if it does not know dx and dy. The Mini Metal Maker z-min (which I use for z-probe) is not in the print head, it is 3 microswitches under the bed. Z0 is set to 0.35 in the post G29 gcode, so the nozzle is at the surface of the bed instead of the microswitch trip point. M48 results: Mean: -0.327813 Min: -0.330 Max: -0.325 Range: 0.005 Standard Deviation: 0.001348 Raw data for G29 and M48:

>>> g28
SENDING:G28
echo:busy: processing
echo:busy: processing
echo:busy: processing
>>> g29 v4
SENDING:G29 V4
G29 Auto Bed Leveling
echo:busy: processing
Bed X: 20.000 Y: 5.000 Z: 0.009
echo:busy: processing
Bed X: 40.000 Y: 5.000 Z: 0.011
echo:busy: processing
Bed X: 60.000 Y: 5.000 Z: 0.044
echo:busy: processing
Bed X: 60.000 Y: 25.000 Z: 0.063
echo:busy: processing
Bed X: 40.000 Y: 25.000 Z: -0.004
echo:busy: processing
Bed X: 20.000 Y: 25.000 Z: 0.022
echo:busy: processing
Bed X: 20.000 Y: 45.000 Z: -0.025
echo:busy: processing
Bed X: 40.000 Y: 45.000 Z: 0.064
echo:busy: processing
Bed X: 60.000 Y: 45.000 Z: 0.067
Eqn coefficients: a: 0.00140104 b: 0.00035417 d: -0.03697918
Mean of sampled points: 0.02791666
Bed Height Topography:
   +--- BACK --+
   |           |
 L |    (+)    | R
 E |           | I
 F | (-) N (+) | G
 T |           | H
   |    (-)    | T
   |           |
   O-- FRONT --+
 (0,0)
 -0.05292 +0.03646 +0.03896
 -0.00542 -0.03229 +0.03521
 -0.01917 -0.01729 +0.01646
Corrected Bed Height vs. Bed Topology:
 +0.00031 +0.06167 +0.03615
 +0.05490 +0.00000 +0.03948
 +0.04823 +0.02208 +0.02781
Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001401
-0.000000 +1.000000 +0.000354
-0.001401 -0.000354 +0.999999
echo:enqueueing "G1 Z0.35 F600"
echo:enqueueing "G92 Z0"

>>> m48 p20 x 40 y25 v4
SENDING:M48 P20 X 40 Y25 V4
M48 Z-Probe Repeatability Test
Positioning the probe...
echo:busy: processing
Bed X: 40.000 Y: 25.000 Z: -0.323
echo:busy: processing
1 of 20: z: -0.326 mean: -0.3256 sigma: 0.000000 min: -0.326 max: -0.326 range: 0.000
2 of 20: z: -0.326 mean: -0.3256 sigma: 0.000000 min: -0.326 max: -0.326 range: 0.000
echo:busy: processing
3 of 20: z: -0.327 mean: -0.3263 sigma: 0.000884 min: -0.327 max: -0.326 range: 0.002
echo:busy: processing
4 of 20: z: -0.327 mean: -0.3266 sigma: 0.000937 min: -0.327 max: -0.326 range: 0.002
echo:busy: processing
5 of 20: z: -0.326 mean: -0.3265 sigma: 0.000848 min: -0.327 max: -0.326 range: 0.002
6 of 20: z: -0.327 mean: -0.3267 sigma: 0.000859 min: -0.327 max: -0.326 range: 0.002
echo:busy: processing
7 of 20: z: -0.329 mean: -0.3270 sigma: 0.001079 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
8 of 20: z: -0.328 mean: -0.3271 sigma: 0.001080 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
9 of 20: z: -0.327 mean: -0.3272 sigma: 0.001025 min: -0.329 max: -0.326 range: 0.003
10 of 20: z: -0.327 mean: -0.3271 sigma: 0.000976 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
11 of 20: z: -0.328 mean: -0.3272 sigma: 0.000974 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
12 of 20: z: -0.329 mean: -0.3274 sigma: 0.001107 min: -0.329 max: -0.326 range: 0.004
echo:busy: processing
13 of 20: z: -0.330 mean: -0.3276 sigma: 0.001270 min: -0.330 max: -0.326 range: 0.004
14 of 20: z: -0.329 mean: -0.3277 sigma: 0.001260 min: -0.330 max: -0.326 range: 0.004
echo:busy: processing
15 of 20: z: -0.328 mean: -0.3277 sigma: 0.001222 min: -0.330 max: -0.326 range: 0.004
echo:busy: processing
16 of 20: z: -0.325 mean: -0.3275 sigma: 0.001353 min: -0.330 max: -0.325 range: 0.005
echo:busy: processing
17 of 20: z: -0.328 mean: -0.3276 sigma: 0.001319 min: -0.330 max: -0.325 range: 0.005
18 of 20: z: -0.329 mean: -0.3276 sigma: 0.001310 min: -0.330 max: -0.325 range: 0.005
echo:busy: processing
19 of 20: z: -0.329 mean: -0.3277 sigma: 0.001333 min: -0.330 max: -0.325 range: 0.005
echo:busy: processing
20 of 20: z: -0.329 mean: -0.3278 sigma: 0.001348 min: -0.330 max: -0.325 range: 0.005
Finished!
Mean: -0.327813 Min: -0.330 Max: -0.325 Range: 0.005
Standard Deviation: 0.001348
Bob-the-Kuhn commented 7 years ago

@BillStruve - thanks for the info.

On (x+dx,y+dy) - I thought you meant dx was the X offset of the probe and dy was the Y offset of the probe.

Bob-the-Kuhn commented 7 years ago

@oderwat - attached is the logic sequence I went through to arrive at my "constant M851 Z offset is not needed when using bilinear leveling" conclusion.

Please review. Z offsets.xlsx

BillStruve commented 7 years ago

@Bob-the-Kuhn Sorry about that, I did a (too) quick look at Configuration.h and did not find Y_PROBE_OFFSET_FROM_EXTRUDER, X_PROBE_OFFSET_FROM_EXTRUDER, so I thought that they were not specified. Boy, my memory is going since I had set both of these to zero a couple of months ago!

benlye commented 7 years ago

I need to do a few more prints, but the few tests I've done since fixing my probe X and Y offset values and re-calibrating the bed settings have had much more consistent first layers.

Before now, if I printed a skirt it would almost never come off in one piece because it would be nonexistent in one corner. For the last few prints it is paper-thin (my initial layer is 0.12) and consistent all the way around, and comes off in one piece.

:-)

EDIT: Just to be clear, by 're-calibrating the bed settings' I mean that I adjusted some settings relating to bed / positioning in configuration.h, namely the travel after homing settings, as I found that the center coordinates were slightly off the actual bed center. I did not adjust the levelling screws.

aaronthomaswebster commented 7 years ago

I have an ignorant question.... is G29 all i need to do to enable auto bed leveling or is there something to do after G29 to apply the leveling?

Bob-the-Kuhn commented 7 years ago

G29 automatically enables auto leveling.

You can use M420 to enable/disable auto bed leveling once G29 has been run.

jamhot1 commented 6 years ago

hey guys, I've decided to double my 3d printer into a PCB milling machine and have run into a few issues trying to issue specific commands appended to the G29 procedure. I need to probe as many as 15 points in specific area's on the PCB so that I can use them to mill out my designs. It also saves me trying to probe the entire bed and reduces time. I just can't seem to get it to play ball. If I send G29 X8 Y8 L25 R65 F110 B160, It will only probe out the 1st 2 rows of 8 before resetting itself. I have AUTO_BED_LEVELING_LINEAR set which I believe allows me to modify the G29 parameters in this way. I thought it might be a memory issue because the latest release uses 97% of flash memory but I revert to previous that used 92% and i still get the same issue. It this a related issue? i am running on an Anet A8 machine.

thinkyhead commented 6 years ago

@jamhot1 — Are you using 32x microstepping? What kind of Z feedrate are you using between probes? Try reducing your feedrates to see if it prevents the reset.

github-actions[bot] commented 2 years ago

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.