Closed brookstalley closed 5 years ago
brookstalley
commented
6 years ago A little more investigation shows that there is a large effective slope in the mesh between X=170 and X=192, running from Y=147 to Y=242.
(169,147) and (170,146) are both normal height; moving either 1 right or back causes a 5mm jump.
Moving from (170,147) to (192, 147) produces a linear change in Z of about 30mm.
Bergerac56
commented
6 years ago What is your configuration? 8bits or 32 bits?
brookstalley
commented
6 years ago 8 bits, Rambo 1.3L in a Makergear M2. Running 1.1.8.
Roxy-3D
commented
6 years ago Your mesh values should all be close to 0.00 Ideally, some will be + and some will be -. Having mesh values in the 9.0 mm range is totally untested. You need to adjust your Z_PROBE_OFFSET_FROM_EXTRUDER number so it is accurate and returns a value very close to 0.00 mm at the point it probes.
brookstalley
commented
6 years ago I’m probably missing something with config interactions. My Z_PROBE_OFFSET_FROM_EXTRUDER is -0.52, which is accurate as measured. UBL does work flawlessly except that back right corner.
Turning UBL off, my correct M206 value is M206 Z9.9 ... should I be leaving that in place with UBL enabled, or setting it to 0 but adding 9.9 to Z_PROBE_OFFSET_FROM_EXTRUDER, or is there a better way to zero out the Z offset?
Thanks for the speedy reply and assistance!
brookstalley
commented
6 years ago Believe it's sorted out; thanks for the lead on expected values being much smaller. Here's what I did:
New mesh looks like:
READ: (0,6) (6,6)
READ: (57,242) (192,242)
READ: -0.077 -0.061 -0.043 -0.039 -0.018 -0.019 -0.024
READ: -0.025 0.001 -0.007 0.018 0.048 0.017 0.006
READ: 0.035 0.028 0.016 0.054 0.043 0.068 0.034
READ: 0.033 0.014 0.054 0.065 0.044 0.073 0.053
READ: 0.064 0.012 0.023 0.017 0.049 0.022 0.020
READ: 0.015 0.020 -0.015 -0.013 -0.017 -0.009 -0.033
READ: [-0.052] -0.065 -0.071 -0.073 -0.094 -0.064 -0.096
READ: (57,12) (192,12)
READ: (0,0) (6,0)...and no more huge jumps.
Roxy-3D
commented
6 years ago Yeah... But you should be able to generate that mesh with just a G29 P1.
Koshu
commented
6 years ago @brookstalley Are you by any change homing to z-max? Had a similar problem. Didn't want to fine tune my z-max that precise (after all I have a probe, which should take care of this kind of stuff). So the mean value of my mesh was at ~2mm. The problem here is the fading, because it also "fades" the mean value. My parts were always 2mm to high, which got me confused for quite some time. Disabling the fading altogether did the trick. @Roxy-3D Maybe it would be a nice addition to ignore the mean value for the fading, because it doesn't distort the printed part? This shouldn't be an issue if you use the probe for homing but for other setups it is, since you will never get the mean value correct 100%.
brookstalley
commented
6 years ago @Koshu yep, homing to z-max; that's where the endstop is on my printer. I did learn to turn fading off for just that reason, though now that I have the mesh offsets at 0 +- 0.1mm, I'll try turning it back on.
It does feel like there'e an improvement here where the UBL probing logic could center the mesh on its mean value, and apply any extra offset to M206, or at least give a message like "Recommend moving large offset out of mesh using G29 P6 C9.8 + M206 Z9.8". Maybe? Not sure if there are cases where that's a bad idea.
Roxy-3D
commented
6 years ago @Koshu
Maybe it would be a nice addition to ignore the mean value for the fading, because it doesn't distort the printed part? This shouldn't be an issue if you use the probe for homing but for other setups it is, since you will never get the mean value correct 100%.
Please explain your idea in different words. The fade logic does not currently use the mean mesh value. But I suspect if I can understand your thinking... We can make that better.
With that said, one of the things I'm going to add is a #define to turn on rigorous debug logic on the Z-Height correction logic (as well as the fade correction). That might be helpful to nip these kind of problems in the bud.
Koshu
commented
6 years ago @Roxy-3D Right now it seems to work like this (Please correct me if I'm wrong): The fading fades out whatever is set in the map. If you use Z-Max for homing you map might look like this (a little exaggerated):
5,1 5,0 5,1
5,0 5,0 5,0
4,9 5,0 4,9In this example the mean value is about 5 mm because the print height in Z wasn't set 100% correctly in the firmware (or maybe changed because you tightened the screws on the bed a little bit more). Now, lets say the fading height is set to 10 mm. In this case at 10 mm the printer will be at a Z-position of 15 mm (distance to the bed) because the fading corrected everything in the map. This will result in printed object that is 5 mm to large. That's what happened in my case, I think. However, the actual distortion that the fading should correct is only in the range of ~0.1 mm, because the mean value of the map (even if it is way off) only changes "where in the printer" the part will be printed but doesn't change the dimensions of the part. So, in this case the printed part is actually more accurate if you turn fading off (but slightly distorted).
A solution might be if the fading ignores the mean value of the map. In this case at the time the fading height is reached it will only fade out the distortion of the bed in the range of ~0.1 mm. The 5 mm mean value on the other hand will never be faded out and kept as an offset throughout to hole print.
brookstalley
commented
6 years ago What @Koshu said -- same here.
I believe the issue could also be addressed by moving either the mean or the minimum value from the mesh Z heights to M206 coordinate space correction. In Koshu's example, that mesh should be functionally the same as setting M206 4.9 and then doing G29 P6 C-4.9, to get the mesh
0.2 0.1 0.2
0.1 0.1 0.1
0.0 0.1 0.0...and then fading should work as expected. I think.
Koshu
commented
6 years ago That would probably work as well. However, an automated way would be nice.
Roxy-3D
commented
6 years ago A solution might be if the fading ignores the mean value of the map.
I think what you really are saying is to have the fading factor in the mean of the mesh map and include that in the calculations. Right now, the mean of the mesh map is not considered. I can look into doing that.
But really.... The 'right' answer is to have your machine calibrated properly.
Koshu
commented
6 years ago I think what you really are saying is to have the fading factor in the mean of the mesh map and include that in the calculations. Right now, the mean of the mesh map is not considered. I can look into doing that.
I didn't quite understand that. Can you explain it to me?
But really.... The 'right' answer is to have your machine calibrated properly.
Why? I have a sensor for that part, so the marlin already knows everything it needs to know. Whats the benefit of manually transferring the mean value of the map to the home-offsets?
brookstalley
commented
6 years ago Agreed to correct calibration.
Koshu and I may have different but related issues/suggestions. I think what we're seeing is unnecessary complexity in the calibration and settings for printers with z-max endstops. By definition, my printer knows when it is at Z = 200mm, but absent tuning of M206, the nozzle height at z = 0mm is somewhere between 5mm and 10mm depending on what bed I'm using.
After thinking about it, I believe the best way to simplify this is to have G29 P1 disregard the current M206 setting, do its testing, and then transfer the minimum gap value from the mesh into M206 and subtract that from the mesh. That way even if the mesh is turned off, the M206 setting won't cause the head to crash on G1 Z0, no matter where it is in the bed. And fades would also work as expected.
Now that I understand what's going on, it's easy enough to do this myself manually. But it was a whole bunch of hours of figuring this out, so it would be nice to spare future folks.
If that sounds like a reasonable approach, I'll submit a PR for review.
thinkyhead
commented
6 years ago M206 shouldn't (assuming all is well) have any effect on internal operations, because internal movement is done in native machine space. The M206 offset is just subtracted from your inputs on G-move commands, and added to coordinates when printing them out.
Roxy-3D
commented
6 years ago If that sounds like a reasonable approach, I'll submit a PR for review.
Yes... Please submit a Pull Request with your suggestion. And it would be best (for now) if we make the new code sensitive to being on a Delta printer. ie. #if ENABLED(DELTA)
brookstalley
commented
6 years ago Thanks, @Roxy-3D . Will do in the next day or so. But... you blew my mind with that last comment. This isn't a Delta; it's a Cartesian.
@thinkyhead I think you've summarized my proposal better than I did: when G29 P1 finds large, constant Z offsets, move them out of G29 (machine space) and into M206 (user space). It allows UBL to calibrate both mesh and M206, with a "whole bed" constant offset in M206 and only the XY variability in G29.
That's my hope, anyway.
Roxy-3D
commented
6 years ago Oooops! You said your machine homes Z to max. And almost always that is a Delta. Please ignore the comment about making the code conditionally compiled in with #if ENABLED(DELTA).
thinkyhead
commented
6 years ago a "whole bed" constant offset in M206 and only the XY variability in G29.
So, kind of like what we used to have: leveling.z_offset.
Ultimately, what you're looking for is a nice automated way to get your probe offset right so all future leveling applies the proper correction. It's actually impossible to obtain a meaningful "whole bed" offset without having a reasonable probe Z offset in the first place.
I propose that the LCD include an option to obtain an accurate probe Z offset through a simple procedure: First it places the probe in the center of the bed and takes a few measurements to get a weighted average. The probe is then raised to a point where it is no longer triggered (plus a mm or two). Then the procedure prompts you to move the nozzle down to where it just touches the bed. At that point we know what the correct Z probe offset should be, and can be assured of a very accurate measurement for future bed leveling procedures. The new probe-nozzle offset is then applied to the zprobe_zoffset, as with M851 Z.
So let's follow an example:
zprobe_zoffset is set as 10 - (-0.2), or 10.2.M500 because now we have an accurate zprobe_zoffset.Roxy-3D
commented
6 years ago I think this would be very useful. And it would help us support people bringing up new machines or new bed leveling systems. The ability to just say "Do a Z_PROBE_OFFSET_FROM_EXTRUDER using the LCD Panel." will simplify the support issues greatly.
I am very supportive of this happening!!!
brookstalley
commented
6 years ago I think we're talking about a few related but different scenarios which would benefit from similar work. I know I've been remiss putting my PR together, but I'm still here and will get it soonish.
Issue 1: UBL does not like large Z values in mesh Solution 1: At completion of UBL, move average mesh height into M206 and remove from mesh (this is the PR I need to put together)
The original notes in this issue were things I ran into because my printer homes to Z_MAX and bed leveling (correctly) does not use the M206 Z offset. Given the fixed Z height in configuration.h, my printer knows that Z=200 is home. Therefore, the bed touches the nozzle right around Z=-9mm (depending on bed material).
UBL correctly builds a mesh with Z values of -9mm, but actually using that mesh causes all sorts of problems. It is necessary to get the average of the mesh with G29 P5, set that value to M206, and subtract it from the mesh with G29 P6.
Issue 2: Fade cutoff doesn't account for mesh adjustment (what @Koshu saw) Solution 2: Add mean mesh height (likely negative) to target end of fade
If I understood the issue correctly, Koshu had a mesh with a mean value of -2mm, and enabling fade caused 10cm parts to be printed 12cm tall because the fade spanned Z=0 (adjusted for mesh) to Z=10 (not adjusted for mesh).
Issue 3: It should be possible to automatically calculate probe height from bed Solution 3: What @thinkyhead said
Koshu
commented
6 years ago To Issue 2: The main Problem isn't that the fade height is wrong (also that probably happens, too), it's that the mean mesh height gets "faded" as well. Dynamically setting the fade height (like proposed as solution) won't fix this, it will only change the position at which it happens. However, the fix for Issue 1 probably fixes Issue 2 as well, I think. So, for Issue 2 no extra steps are necessary if my assumptions are correct.
thinkyhead
commented
6 years ago enabling fade caused 10cm parts to be printed 12cm tall because the fade spanned Z=0 (adjusted for mesh) to Z=10 (not adjusted for mesh).
Yes indeed! A mesh with a mean value of -2mm will cause the nozzle to lower by 2mm at Z0, and at Z10 there where the mesh offset stops, Z will be at 10mm, and your object will now be 12mm tall.
So yes, it's a Bad Idea™ to have a mesh with such a large negative deviation from 0. The firmware tacitly assumes that your mesh will tend to center on 0 and that there won't be much more than +-0.1mm in deviation from there. Maybe we should be more strict about that!
thinkyhead
commented
6 years ago A technical solution to a deviated mesh like that is perhaps possible. If the desired effect is to have the fade occur over 10mm guaranteed, and not over 12mm, then we could subtract the lowest value in the mesh from the current Z before using it as the fade input.
But note, it's also a tacit assumption of the fade behavior that your bed isn't very tilted, but mostly very flat. If you have a tilted bed the Z fade correction would get even weirder. The lowest mesh value might be -10mm and your highest +10mm. And what would we do then? We would have to apply both a planar matrix and a mesh to get anything sane.
So you can't have tilt. And we really should enforce a minimum deviation from center to prevent that scenario.
If we were to adjust the whole mesh upward to make the smallest value zero, then tweak the zprobe_zoffset to match, this would get saved with the mesh on M500, and presumably the next probe would come out better. But for the current print we would then need to introduce a global offset (i.e., The minimum Z value I mentioned retaining earlier.)
This brings us back around to the way leveling used to be, where the leveling system didn't subtract z_probe_zoffset from the mesh, and we would instead "do it live," subtracting it inside of apply_leveling. The upshot of this extra bit was that if we altered zprobe_zoffset it had an immediate effect.
We seem to keep coming back around to how valuable that extra offset would be. It would provide a more consistent and persistent corrective for a large minimum Z value where the mesh itself is pretty flat.
There seem to be some good reasons to bring it back into play, not least of which is that it resolves a lot of my previous concerns surrounding both G33 and BABYSTEP_ZPROBE_OFFSET.
boelle
commented
5 years ago @brookstalley still having issues in latest bugfix 2.0?
boelle
commented
5 years ago @thinkyhead i think we can close this one
boelle
commented
5 years ago @thinkyhead Another one that needs to be closed. Sorry, I got bored.
github-actions[bot]
commented
4 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.
Bug Report
Description: After probing complete mesh, moves from some nodes to very close Z's result in huge Z axis jump
Expected behaviour: Z moves by 0.005mm
Actual behaviour: Z moves by ~5mm
Here is my G29 T0 after moving to 175,140,5 (G1 X175 Y145 Z5):
...and then issuing a G1 X175 Y150 Z5 results in:
...but the Z axis has actually moved closer to the nozzle by about 5mm rather than the 0.005 that seems to be indicated.
I have tried M111 S247 and the UBL leveling and G28 commands print debugging info, but this move does not.
configs.zip