UBL does not compensate enough

[arvydas]

Summary

I am using Marlin 1.1.8 release and UBL seems to work, but it is not compensating enough the build plate tilt.

My setup

• Marlin release 1.1.8
• CR-10S 500mm x 500mm x 500mm
• Genuine BLTouch
• UBL with 10 points on each X and Y axis
• Using skew compensation for XY

Source and configuration

Ignore the name on the repository, I am actually using Marlin 1.1.8 release

https://github.com/arvydas/CR-10S-Marlin-bugfix-1.1.x

The repository could be missing a few changes I have made so will push them tomorrow.

Steps I do

M502
M500
M501 ; reset everything
; don't have Gcode for this, but I preheat he bed to 50C at this point
G28 ; home axis
G29 P1 ; run UBL
G29 S ; save mesh
M851 Z-0.5 ; adjust Z offset
G29 A ; activate UBL
M500 ; Save EEPROM

Description

Once the above commands are run, I can tell that UBL is active, because if I place the nozzle 0.5mm above the bed and move in diagonal corners of the bed with G1 X10 Y10 and G1 X450 Y450 I can clearly see that the Z axis moves accordingly. The problem I am experiencing is that the compensation is not working. On the left side of the build plate nozzle gets closer to the build plate by 0.3mm and on the right side of the bed nozzle is about the same distance too far even though I have set Z offset to -0.5. Everything is fine in the middle of the build plate.

If I try to start printing a test square of about 450mm it looks as if the bed inclination is not compensated enough: the left side of the print scrapes the bed and right side of the print is too far away. My bed has an inclination of about 1mm based on the topology report, but as far as I am aware UBL should be able to compensate for it. Getting the bed level on this massive printer is a huge pain!

Am I missing steps to correctly initialize UBL? Please let me know if you require any additional data and I will be happy to post it here. Would be very grateful for any suggestions on how to fix this issue as without UBL my 3D printer is unusable :)

[Roxy-3D]

You should have the z-offset set correctly prior to generating the mesh. Otherwise your mesh numbers will be off because the probing system won't be returning accurate numbers. Probably, you should set

#define Z_PROBE_OFFSET_FROM_EXTRUDER -.5

in your configuration.h file.

I suspect the reason you are seeing no correction on the left side is because your mesh is not fully populated and accurate. Do a G29 T and you probably will see a bunch of dots. Those are unknown mesh point values. You can fill them with 'reasonable' values by doing G29 P3 T until you see them all gone. The filled in values were never measured, so they are just reasonable guesses. That is OK. They just need to be good enough that you can run a G26 C P O2.5 command.

Once you complete a G26 C P O2.5 command... Any area that is not perfect can be edited. You do that with G29 P4 R and push the mesh points up or down based on what the filament looks like at each mesh point. If the filament isn't adhering to the bed very well, push the mesh point down a little bit. If the filament is too squished because the nozzle is too close to the bed, raise the mesh point up a little bit.

And then save the edited mesh and do another G26 C P O2.5 and G29 P4 R edit cycle. Very quickly, you will have a perfectly tuned mesh and have good adhesion on the entire print bed.

[arvydas]

First @Roxy-3D kudos for UBL implementation. Impressive stuff! Thanks for replying so quickly.

I was under impression that z-offset is irrelevant to UBL P1, because it is a constant that can be adjusted with M command or within the printer's UI. I just updated the Z_PROBE_OFFSET_FROM_EXTRUDER, but it had no effect to the issue I am experiencing.

My mesh is fully populated and I am printing tests within the outer points being tested. If I run G29 P1 command just once followed by G29 T I do not see any dots in the topology report.

I redid everything again, but tried to level the bed as best as I could with a tilt of about 0.4mm.

This is the test I am trying to print. Left side layer height 0.17, right side layer height is 0.27. My slicer settings are for 0.2mm first layer height. The tilt is very consistent and gradual.

Left corner:

Right Corner:

I tried to print the pattern with G26 command some time ago, but I got lots of stringing. How do I set the retraction? There is a parameter, but what does the retraction multiplier mean for that setting? The mesh feels like it is OK, it baffles me that the tilt is so consistent.

Purely out of curiosity I disabled now the skew compensation, because I saw in one of the issues posted here that it was causing problems with automatic bed leveling for someone else. The tilt is even worse now!

It seems that the z-offset changes along the x axis. Could this be a mechanical issue? Z axis is driven by two motors on left and right sides.

[arvydas]

Just tried to do G29 J3 before the print and it did not have any effect on the tilt...

[Roxy-3D]

I was under impression that z-offset is irrelevant to UBL P1, because it is a constant that can be adjusted with M command or within the printer's UI. I just updated the Z_PROBE_OFFSET_FROM_EXTRUDER, but it had no effect to the issue I am experiencing.

In general... When you change a Configuration.h setting that can be changed (and stored in the EEPROM) you should do a M502 followed by a M500. That reads the default value from configuration.h and stores that value in the EEPROM.

But to your point... The Z_PROBE_OFFSET_FROM_EXTRUDER number is independent from UBL. But it is a key value for the probing system that is shared among all the bed leveling systems. UBL will still probe and build a mesh with an incorrect number. But really... You want accurate numbers in use during the whole process.

My mesh is fully populated and I am printing tests within the outer points being tested. If I run G29 P1 command just once followed by G29 T I do not see any dots in the topology report.

OK! That is unusual, but it just means the probe can reach all defined areas that the nozzle can reach. That can happen when the inset is larger than the *_PROBE_OFFSET_FROM_EXTRUDER.

I redid everything again, but tried to level the bed as best as I could with a tilt of about 0.4mm.

This is the test I am trying to print. Left side layer height 0.17, right side layer height is 0.27. My slicer settings are for 0.2mm first layer height. The tilt is very consistent and gradual.

Those pictures look very reasonable... Are you deliberately having the left side at .17 and the right side at .27 ? Most people would try to physically level the bed a little bit more if they can. The bed leveling should handle that tilt. But the less it has to handle, the better it works. What about those print pictures has you concerned?

I tried to print the pattern with G26 command some time ago, but I got lots of stringing. How do I set the retraction? There is a parameter, but what does the retraction multiplier mean for that setting? The mesh feels like it is OK, it baffles me that the tilt is so consistent.

G26 defaults to using 1.0 mm of retraction and 1.2 mm of re-prime length. Those values seem to work well with most printers. There is no way to set the values independent of each other (short of making a quick change to the code:)

  void retract_filament(const float where[XYZE]) {
    if (!g26_retracted) { // Only retract if we are not already retracted!
      g26_retracted = true;
      move_to(where, -1.0 * g26_retraction_multiplier);
    }
  }

  void recover_filament(const float where[XYZE]) {
    if (g26_retracted) { // Only un-retract if we are retracted.
      move_to(where, 1.2 * g26_retraction_multiplier);
      g26_retracted = false;
    }
  }

But really... You can ignore the 'stringing'. The purpose of G26 is to see how well the nozzle is positioned at all locations of the bed using the mesh points as a guide. If the filament is printing with the right amount of squish to it... That is what you care about. And if not... You can use that information to edit the mesh point and make it better.

Purely out of curiosity I disabled now the skew compensation, because I saw in one of the issues posted here that it was causing problems with automatic bed leveling for someone else. The tilt is even worse now!

I have been very busy and have not messed with skew compensation. I presume it works. But I have never used it.

It seems that the z-offset changes along the x axis. Could this be a mechanical issue? Z axis is driven by two motors on left and right sides.

Are you saying the mesh points have different values along the X-Axis? If so... Yes, that is typical. The bed Z motors should be in lock step with each other. But if you do a G29 T it is very likely you can see a tilt to the bed when looking at the mesh point values.

[arvydas]

Thanks for the clarifications about z-offset. I noted them and will make sure that Configuration.h has the values from now on.

No I am not deliberately setting the inclination of the bed. Those pictures posted are probably the best I have ever seen in regards to tilt issue, but I was printing at -.6 z-offset and adjusted the gcode to generate at z=0.2.

I reset everything to defaults printing at -0.5 z-offset and gcode at z=0 I am now getting the head scraping the build plate on the left and way too high on the right.

Skew compensation seems to have no effect so you can indeed assume it works.

I understand the concept of bed topology. Here is the way my bed looks for UBL:

READ: Bed Topography Report:
READ: 
READ: (0,4)                           (4,4)
READ: (5,495)                        (460,495)
READ:   0.149    0.011   -0.139   -0.387   -0.638  
READ:  
READ:   0.164    0.091   -0.111   -0.237   -0.457  
READ:  
READ:   0.071   -0.085   -0.036   -0.196   -0.315  
READ:  
READ:  -0.053   -0.028   -0.118   -0.235   -0.259  
READ:  
READ: [-0.139]  -0.012   -0.057   -0.175   -0.297  
READ: (5,10)                            (460,10)
READ: (0,0)                             (4,0)
READ: ok

Top left corner in the image below is the (5,10) position of the bed.

Shouldn't UBL compensate whatever topology of the bed is?

Is it possible to tilt the whole mesh with a G-code command?

[Roxy-3D]

Shouldn't UBL compensate whatever topology of the bed is?

Yes. But... it is more complicated than that. The auto probing is pretty good. It gets you pretty reasonable values. But it isn't perfect. Just doing the probing with the nozzle and bed heated up versus not heated will show differences.

I reset everything to defaults printing at -0.5 z-offset and gcode at z=0 I am now getting the head scraping the build plate on the left and way too high on the right.

First... I suggest you shift to a 10 x 10 mesh. 5 x 5 will work. But you will have more control and be able to track the surface of the bed better with 10 x 10.

What ever you decide to do... Remember... You get to edit (and change) what ever the auto probing discovers. If you move the nozzle to the left side and do a G29 P4 R you can raise each of the mesh points where the nozzle is scraping by .1 mm.

That is the purpose of the G26. It lets you see how the filament is being extruded at all locations across the bed. Even though the auto probing is pretty good... It is not perfect. And by doing a G26 you can see the flaws. And then move the nozzle to the bad area and use G29 P4 R to edit those mesh points.

Is it possible to tilt the whole mesh with a G-code command?

Yes. But lets not do that right now. The mesh based leveling is very good. Most people do not need anything else. Let's just focus on getting a mesh exactly accurate for your machine and then we can play with the more complicated stuff.

[arvydas]

The auto probing is pretty good. It gets you pretty reasonable values. But it isn't perfect. Just doing the probing with the nozzle and bed heated up versus not heated will show differences.

Have done the comparison, works very well.

First... I suggest you shift to a 10 x 10 mesh. 5 x 5 will work. But you will have more control and be able to track the surface of the bed better with 10 x 10.

Will do. I switched to 5 x 5 mesh in order to be able to more quickly run tests. Somewhat 10 x 10 mesh takes ages to complete...

What ever you decide to do... Remember... You get to edit (and change) what ever the auto probing discovers. If you move the nozzle to the left side and do a G29 P4 R you can raise each of the mesh points where the nozzle is scraping by .1 mm.

This seems like a nice workaround to the issue that I am having, however the tilt is very consistent and even across the bed even though you have seen the topology of my bed. I think that there has to be something in the code causing this or this could be a mechanical issue. I would like to get to the bottom of either one of them. If this was an issue with just a few points or one area of the bed, then mesh editing would make sense. If I make any changes to the frame and have to run UBL again I would need to repeat the manual mesh editing again...

Yes. But lets not do that right now. The mesh based leveling is very good. Most people do not need anything else. Let's just focus on getting a mesh exactly accurate for your machine and then we can play with the more complicated stuff.

Please hit me with the complicated stuff. I can handle it :-) I have invested too much time in this 3D printer to let it go easily.

I have looked at the development docs on the website, but can't find much info about the actual development/debugging process. Is it mostly a matter of putting logging code and debugging based on the output? I have full AVR development and debugging stack with hardware.

[Roxy-3D]

This seems like a nice workaround to the issue that I am having, however the tilt is very consistent and even across the bed even though you have seen the topology of my bed. I think that there has to be something in the code causing this or this could be a mechanical issue.

UBL uses the same probe system that all of the other bed leveling systems use. When this kind thing happens, a lot of times it gets traced back to the cable bundles are pulling harder on the nozzle on one side of the bed versus the other side. Or some other mechanical issue that exerts more force on one side than the other.

I would like to get to the bottom of either one of them.

I understand. But what ever the probe system is measuring is what UBL uses.

If this was an issue with just a few points or one area of the bed, then mesh editing would make sense. If I make any changes to the frame and have to run UBL again I would need to repeat the manual mesh editing again...

Yes. But my experience is once you have a well tuned mesh... It is many months before you will find a need to regenerate it. Eventually, with lots of printing the linear bearings show some wear. And another situation that can force you to regenerate the mesh is if you crash the nozzle into the bed (or part) and one z motor keeps turning and the other one does not.

Yes. But lets not do that right now. The mesh based leveling is very good. Most people do not need anything else. Let's just focus on getting a mesh exactly accurate for your machine and then we can play with the more complicated stuff.

Please hit me with the complicated stuff. I can handle it :-) I have invested too much time in this 3D printer to let it go easily.

Check out the G29 J stuff. You can do some simple things like a G29 P0 to zero the mesh, and then G29 J to watch it probe 3 points and tilt the measured plane.

I have looked at the development docs on the website, but can't find much info about the actual development/debugging process. Is it mostly a matter of putting logging code and debugging based on the output? I have full AVR development and debugging stack with hardware.

Yes... debugging is a little bit difficult on the AVR's. A good experiment would be doing the G29 P0 and G29 J to invoke 3-point mesh tilting (of a 0.00 mesh) based on the measured points. And that code has some debug (and certification) code that can be uncommented to prove the 'correctness' of the generated solution.

[arvydas]

Huge thanks for the insight and explanations! My goal right now is to have a look at debug info and what kind of numbers I am getting for the actual moves when I move the head close to one of the edges of the bed.

Will come back to this thread when I find something.

[evanfoster]

@arvydas were you able to figure it out?

[arvydas]

@evanfoster I'm afraid not...

[thinkyhead]

@arvydas — Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands. You may have better luck with the most recent code.

[github-actions[bot]]

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.