mesh results inconsistent with leveling
-
@jltx It might also help if you post the output from your bed.g when performing bed levelling.
-
-
this is not the exact one run before the above HeightMap but the results are typical.
-
@martin7404 no, see output I added. large variation at the pivot points.
-
@gloomyandy here is the HeightMap.csv
RepRapFirmware height map file v2 generated at 2021-12-19 03:27, min error -0.056, max error 0.175, mean 0.051, deviation 0.081
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
X,Y,25.00,275.00,25.00,275.00,-1.00,125.00,125.00,3,3
0.161, 0.072, 0.014
0.114, -0.010, -0.050
0.175, 0.036, -0.056 -
@jltx Hold on, I'm investigating something...
-
@jltx What point are you using to set set your z=0 in the height map (it looks like it is the centre of the bed from your height map)?
Looking at the bed.g output it looks like a plane passing through your 3 selected probe points does not also pass through your z=0 point. Because of this even when your bed is level there will be an offset and so all of the motors will be driven a small amount up/down to try and correct this offset. You can see this in the bed.g motor correction output with all being moved a similar amount in the same direction. Because of this I'd expect that same offset (about 0.02) to be shown at the the same points in your height map. I've had similar issues.
There are a couple of possible fixes you could try:
- When running bed.g perform an additional G30 at one of the selected probe points (probably first is best) to set a z=0 point that coincides with the plane you using to perform the bed levelling.
- Probe more than the minimum of three points and include the point you home to as one of the extra points. I use this method and actually probe the four corners of the bed (well just in from them) and the centre point (that I use for homing). In this case the plane will be over constrained and RRF will use a best fit mechanism to define it.
Method 1 should remove the offset from the bed.g output, but because your z home point will still not be on that plane you will continue to see an offset in your height map, that is basically the difference between your z=0 height and the plane through your pivot points.
Method 2 is not mentioned in the Duet guides but is what I've been using for some time. Personally I think it gives better results as it takes into account more of the bed and not just the pivot points. In this case your bed.g output and your height map will probably continue to show and offset (but probably a smaller one than you are seeing now). Again this offset will be the difference between the Z=0 height and the best fit plane applied to your bed.g points.
Oh and in both cases make sure that you re-home Z afer your bed.g adjustments.
Hope the above makes some sort of sense. If you try the above make sure you are ready to emergency stop things the first few times you try it. It can be easy to get the points and/or the correction wrong!
Having said all of that your posted bed map seems to show a slope from one side to the other which I would not expect to see if bed.g has done its job correctly.
Can you post your bed_probe_points.g so that we can see the actual points being probed when running bed.g.
-
@jltx crap. I forgot I had moved my leveling points outboard a bit to get closer to the pivot points and this moved them a few mm off from my mesh points. But I thought I can't be off >0.1mm Z in just a few mm, so I took a higher resolution mesh and see that I have a horribly distorted bed. So the actual level points are much closer together in Z but if you move in just a bit you will get a large Z variation. However, the (now) precise leveling points are still not within the tolerance that leveling established. I'm seeing 0.013 delta (much better than 0.1) which is higher than the 0.001 coming out of leveling. But it doesn't rally matter when the bed is so bad. I'm not sure what happened to the plate. It used to be very flat and I treated it very gently during the rebuild.
-
@gloomyandy Is it important to re-zero the Z to the level point? I assumed this would all be compensated correctly. My Z endstop is not a Z=0 so I adjust for that in my G31. If I run a G30 and this changes where Z=0 is on every run due to temp variation, etc. won't that screw up my offset? I need to mull on that.
So over sampling the bed in leveling is ok? The algorithm with do a good job averaging? I can try that. I think I will avoid the far left edge since it is such an outlier.
-
@jltx Is there a reason why you don't use your probe to set z=0? Unless you have a very good reason not to (like maybe a tool changer or something) then I'd say that using the probe to set z=0 is a good idea especially so since you are using the probe to level the bed.
I'd not go overboard on the number of points you use in your bed.g routine, I've certainly never tested more than 5 points (which is what I use, close to the bed corners plus centre).
-
@gloomyandy I got bootstrapped from someone else’s config and they did not have that. So no good reason. Are you saying doing a G30 S-2 at one of the leveling points?
I tried to do 5 points and unfortunately my bed is so whacked it cannot find a solution within 0.02.
-
@jltx said in mesh results inconsistent with leveling:
@gloomyandy I got bootstrapped from someone else’s config and they did not have that. So no good reason. Are you saying doing a G30 S-2 at one of the leveling points?
I tried to do 5 points and unfortunately my bed is so whacked it cannot find a solution within 0.02.
There is a process called Setting the Z=0 Datum. This involves moving the probe to a fixed XY location, like the center of the bed, and then executing a single G30.
This process needs to be done:
- after leveling the bed with G32
- before creating a height map with G29 S0
- before loading that height map with G29 S1
Bed leveling can be done multiple times as needed. Using the conditional code features of firmware 3.3 and later you can put code into bed.g that will run the leveling process until specified degree of levelness is obtained.
Frederick
-
@fcwilt said in mesh results inconsistent with leveling:
@jltx said in mesh results inconsistent with leveling:
@gloomyandy I got bootstrapped from someone else’s config and they did not have that. So no good reason. Are you saying doing a G30 S-2 at one of the leveling points?
I tried to do 5 points and unfortunately my bed is so whacked it cannot find a solution within 0.02.
There is a process called Setting the Z=0 Datum. This involves moving the probe to a fixed XY location, like the center of the bed, and then executing a single G30.
This process needs to be done:
- after leveling the bed with G32
- before creating a height map with G29 S0
- before locating that height map with G29 S1
OK. I did not see that documented in https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors
I have been printing just fine without doing that. But I will update my macro. Thanks.Bed leveling can be done multiple times as needed. Using the condition code features of firmware 3.3 and later you can put code into bed.g that will run the leveling process until specified degree of levelness is obtained.
right, I do exactly this. See my bed.g posted above.
Frederick
-
@gloomyandy @fcwilt I’m still not clear on the purpose of the Z=0. Maybe the confusion is I have a Voron with a mechanical Z end stop that is used to set the tool Z relative to bed. The inductive probe is only used to level the bed and probe a mesh for bed correction. All of that is relative. Do I need this extra step of Z=0? What exact command would that be? Since I’m not currently doing that, what bad things might happen? I appreciate the help.
-
This post is deleted! -
@jltx said in mesh results inconsistent with leveling:
Maybe the confusion is I have a Voron with a mechanical Z end stop that is used to set the tool Z relative to bed.
As long as that offset is correct such that when the nozzle is moved to Z0 the nozzle is just touching the bed you're ok. The problem is that correcting the gantry leveling will likely alter that offset. I don't really understand why the voron does it that way. Regardless, you can do both. The mechanical switch can be used like a fast homing switch for Z, then the probe can be used to locate the Z0 point of the bed and do the leveling.
-
@jltx said in mesh results inconsistent with leveling:
Maybe the confusion is I have a Voron with a mechanical Z end stop that is used to set the tool Z relative to bed.
One option you have is to use the Clicky mod instead of the probe and Z switch. IMO it makes things simple and straight forward.
The issue with with magnetic probe is that it doesn't measure well absolute height, hence the extra Z switch that some Vorons use. The Clicky solves this problem.
-
@phaedrux i believe they use a hybrid setup because the inductive probes are very sensitive to temperature. If I were to ignore the endstop and try to just use the probe I would have no way to actually set Z=0, at least no confidence that I was anywhere close at a given temp. The endstop can move a little too with thermal expansion but it seems pretty small by comparison.
-
@zapta I looked at klicky but I don’t think I have enough room. Unless the magnetic sled can discriminate only a few mm for pick up I will lose part of my rear bed trying to avoid accidental mounting.
-
@jltx said in mesh results inconsistent with leveling:
@zapta I looked at klicky but I don’t think I have enough room. Unless the magnetic sled can discriminate only a few mm for pick up I will lose part of my rear bed trying to avoid accidental mounting.
Hi,
Here is a quick-and-dirty video of how I fit a Euclid probe to my FT5. It's a bit hard to see but there was limited space to place the camera.
I added one of these to allow moving the dock into position as needed:
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
