Mesh Bed Level Issues
-
@phaedrux thank you for your reply. As with the original Prusa bed, mine is fixed with aluminum spacers and cannot be adjusted currently.
Ive been following your suggestion and tried 10:10 Mesh leveling, but the result is pretty much the same. What confuses me the most is not the uneven result, but that it seems that the compensation fails at the orange / purple areas, as these are close to each other one is to low and one is way higher.
M557 X30:140 Y40:140 P10
Results:
-
Hi,
In your config.g file you have this:
; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X185 Y186 Z200 S0 ; set axis maxima
In your homeall.g file you have this:
G1 X138 Y132 F3000; Z safe homing G30 ; home Z by probing the bed
Where did you get those X and Y values - they do not appear to be the center of the bed?
To create your height map are you still using G32 to invoke bed.g instead of G29 to invoke mesh.g?
Remember that before creating a height map or loading an existing heightmap you need to use G30 at the center of the bed to set your Z=0 datum.
Are you doing that? The heightmap.csv you posted suggests you may not be setting Z=0 - at least not correctly.
-
@fcwilt Hi, thank you for taking the time to take a look at my problem.
You are right, its off center. Ill try to rectify it. Should the nozzle or the sensor be at the center of the bed?
It was subject to several tinkering changes, but its not center you are right, I thought it compensates for it as the heighmap is the heightcompensation based on the G30 in homeall.g. Therefore thought it doesnt really matter where the reference z=0 is measured because each point individually is again measured during mesh leveling (G29).Nozzle centered would be X:92.5 Y:93, if senor should be centered, then i would just add the offset (X:-33,5, Y:-26).
In my start g-code I use:
G28 ;Home G29;
To G28 home (I guess it calls homeall.g) and then use G29 (mesh.g).
Ill test it again with nozzle centered to the bed during G30 and will report results. I will also attach my mesh.g
-
@fcwilt unfortunatly the result didnt change, when using the center in the homeall.g
G1 X92.5 Y93 F3000; Z safe homing
The heighmap now looks different, but in general yields the same information (at another z-height). I retested it center + probe offset but I didn't behave differently. Still pretty much the same print result.
as I dont have a mesh.g I also cannot share it (according to documentation it instead just uses G29 S0).
-
Have you tried the same print in different locations on the bed? Do you get the same results in those other locations?
It might also be worth trying the same print (in the same location) but with the spring sheet rotated say 90 degrees. This might give an indication as to a possible problem with the evenness of the sheet or coating (as the owner of a twotrees Saphire plus I'm not very impressed with their QA).
-
Well your bed looks fairly "smooth" just tilted.
I would find a way to manually level your bed to minimize the mesh compensation needed during printing.
Here is an simplified example of how I implement mesh.g - I have added some comments.
; mesh.g ; called to probe the bed and create the height map needed for mesh compensation ; ============================================ ; G29 with no parameters will invoke this file ; ============================================ ; ==================================================== ; these may not be necessary but it is safe to do them ; ==================================================== M290 R0 S0 ; cancel baby stepping G29 S2 ; cancel mesh bed compensation ; ================================================================================== ; the G1 command below moves the PROBE to the center of the bed ; the code computes the center based on XY min/max values and probe XY offset values ; ================================================================================== G1 X{((move.axes[0].max + move.axes[0].min) / 2) - sensors.probes[0].offsets[0]}, Y{((move.axes[1].max + move.axes[1].min) / 2) - sensors.probes[0].offsets[1]}, F1800 G30 ; do single probe - sets Z to probe trigger height - if trigger height is wrong Z position will be wrong M557 Xaaa:bbb Yccc:ddd P20:20 ; define 400 point probing grid G29 S0 ; probe bed and create height map ; ==================================================================== ; I disable mesh compensation here so manual XY moves are not effected ; I re-enable mesh compensation in my print start code ; ==================================================================== G29 S2 ; cancel mesh bed compensation
-
@fcwilt
Not trying to hijack. Do you have a link to any resources where I can read up on why G29 should be used instead of G32?I recently upgraded to RRF3.3b3
-
@64bit https://duet3d.dozuki.com/Wiki/Setting_up_automatic_probing_of_the_print_bed
Obsolete information
The remainder of this page describes G32 bed probing for bed compensation, which is no longer recommended. For G29 bed probing, see Using mesh bed compensation.
-
@megaloduet Appreciate it. Seems as though Ill have no real benefit from changing at this time.
-
@megaloduet G32 is NOT obsolete, and is still recommended. It's best to get your bed as physically level as possible; G29 mesh compensation is to compensate for anomalies in the bed surface, not for a skewed bed (though it can).
G32 just calls bed.g. You can use this in a number of ways; if you have multiple independent leadscrews (2, 3 or 4), they can level the bed plane: https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors
You can also use it if you have manual bed adjustment screws: https://duet3d.dozuki.com/Wiki/Using_the_manual_bed_levelling_assistantThe part of G32 that is obsolete is defining points to probe, which then creates a very crude bed mesh. It was deprecated in RRF 1.18.
Ian
-
@droftarts said in Mesh Bed Level Issues:
The part of G32 that is obsolete is defining points to probe, which then creates a very crude bed mesh. It was deprecated in RRF 1.18.
Ian
Thanks for providing that information. You saved me some work.
Frederick
-
@64bit said in Mesh Bed Level Issues:
@megaloduet Appreciate it. Seems as though Ill have no real benefit from changing at this time.
Unless in the future, behind the scenes, G32 and G29 do something unique to leveling (G32) or mesh compensation (G29).
If you "convert" now to using G32 and/or G29 as intended you will be ready for any future changes.
Frederick
-
@droftarts do you have an advice in regards to the topic main problem ?
-
Two things have been suggested so far that stand out as good next steps.
- rotate the build surface and see how it changes the problem.
- try and shim up or adjust the bed mounting to remove that tilt.
Couple other things I can think of. Clean the build surface thoroughly. PID tune the heaters.
-
@megaloduet said in Mesh Bed Level Issues:
@droftarts do you have an advice in regards to the topic main problem ?
I wonder if it has anything to do with trying to print on a tilted surface?
When you look at some of the graphics showing how the filament is laid down as a flattened strip adjusting the height alone doesn't compensate for the fact the surface is tilted.
Is the tilt enough to be causing your problem? I just don't know, I have never tried to print on a surface as tilted as yours.
All of my printers either have manual leveling screws for the bed or do automatic leveling using multiple Z steppers and the beds are pretty well leveled.
Here is one of my printers height map. You can see that it has some unevenness but overall it is level.
-
@phaedrux rotating the buildplate 90° has a slight improvement.
Will test another buildplate tomorrow and also clean both.Shouldn't the meshbed leveling be capable of compensating the slight tilt? As done by the original Prusa ?
Have ordered springs and knobs to adjust the bed will also try this (I am afraid I can't use it because of narrow space between Y carriage an frame)
PID is tuned, this one I ruled out already.
Will report the progress tomorrow with both buildplates cleaned. If both show the same artifacts I think at least we can rule out the buildplate.
Next guess would be move the print around on the buildplate, maybe de magnets in the bed interfer with the hotend and push it down while printing over magnets ? Does this sound reasonable to test?
-
Yes mesh compensation can adjust for some amount of tilt by moving the nozzle up and down, but if the tilt is extreme there is also nozzle geometry to think about. One side of the nozzle will be closer to the bed than the other and might cause some dragging/digging. Not sure if that's what's happening here, but might be part of it?
-
@megaloduet said in Mesh Bed Level Issues:
@droftarts do you have an advice in regards to the topic main problem ?
Get the bed plane flat, so that bed mesh doesn’t have so much to do. My guess is that Z is binding moving up and down, or there’s some other inaccuracy in Z movement, which is why there can be a difference between one line and the next, or even within a line (it will usually be worse when going down).
As the machine is a bed slinger with dual Z, most likely the two Z motors are out of sync, so one side (the left) is lower than the right. This may be enough to cause binding. Adjust one motor up or down until the bed plane is level. Or if you have a spare stepper driver on your Duet, separate the Z motors, and let the firmware level it up; see this, follow instructions for two motors, which is how I have mine set up: https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors
Ian
-
@droftarts regarding the both z steppers, I also thought in this direction but could not find how others fix it. Seems that I got alot new hints how to tackle the issue. Irrespective the other Tipps I think a proper way to sync the motors is anyhow a good idea
-
IF you have a free driver you can put each Z motor on it's own and then control them independently to do tilt correction.
https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors