UBL Stubby prints

[Nocturnal42]

So it seems all my prints are coming out distinctly stubby (short in the Z axis). They are approximately 1.6mm too short. Which corresponds with the mesh offset around where the print is on the bed. Would I be correct that this is G29_Correction_Fade_Height at work?

If it is fade at work, would it not make more sense to fade to mean mesh height, rather than Z 0? It should be a less drastic correction, at least where the standard deviation is less than the mean mesh height.

[Roxy-3D]

Yes. I think what you say is true. There is a command to shift the mesh so the mean is 0.000. (G29 P5 C) But probably you want the area where your part is located to be at 0.0000 It may be worth while to add the ability to use an X & Y parameter to the command so you can force what part of the bed is at 0.0000

Please keep thinking about this. With a 1.6mm correction in the center of the bed, we need to figure something out that works for you (and everybody else too!). In the mean time, you can set the Fade Height very high, but you will end up with the mesh distortion on the top surface of the print.

[Nocturnal42]

Well that explains why G29 P5 never worked for me. I was missing a parameter.

[Roxy-3D]

I'm not sure what the 'Right' solution is. The fact that the bed is going up and down sort of implies that any dimensions for the printed part will be off. By fading the correction to 0.0000 at least those imperfections are not propagated to the top side of the print. But that may not be the correct behavior for some types of parts.

I'll code things up how ever it needs to be. But I need help thinking through what the best solution is to this problem. (And I think that answer varies depending upon who is printing what. So a very general case and adaptive solution might be best???)

[Nocturnal42]

So how does G29 P5 actually work? I tried it, my print is no longer noticeably stubby, it is however, abridged. It's still 1.6mm short, but now the first several layers are permanently etched into by build surface instead of being squished.

[Roxy-3D]

Well... G29 P5 and the Z-Home of the nozzle are not directly tied together. They are independent of each other. (At least right now.) But it may be they should be interrelated.

[Roxy-3D]

@Nocturnal42 The more I think about it... I'm leaning towards saying the location that is used to home the Z-Axis should be at 0.0000mm in the Mesh. That drastically simplifies all the math. Would it be problematic to have the printer home in the center of the bed and to call that Mesh Correction value 0.0000mm ?

If a person decides to change their home position, it would be trivial to adjust the Mesh up or down such that this stays true. And in fact, it maybe the system can just take the Mesh and adjust it based on where the Z-Axis Home happened.

Also... I'm thinking it may make sense to give the user the ability to turn off the Fade Height Correction.

[Nocturnal42]

To be fair, I was fairly certain they weren't before I did it (also why I saved my mesh before doing it). This is an area where the documentation might need improvement. My read of it implies that '''G29 P5''' is the final step in proper mesh creation, and I don't recall reading anything about having to adjust my Z axis height. The problem I see with connecting them directly is what method do you use for the z-offset and how do you deal with storing it when the mesh is stored?

How do you determine where the centre of the bed is? its not going to be centre of travel in most cases. I think centre of the mesh is a good default. For most people it's probably going to be close to the centre of their build area, with an option to manually select a point.

[Roxy-3D]

(also why I saved my mesh before doing it).

Yes!!! Always save multiple copies of your Mesh!!!! There are plenty of slots to store them in. Use them! Incidentally... You don't actually have to save things to experiment. Unless you 'Store' or 'Save' a Mesh, nothing should change in the EEPROM. Just the loaded copy in RAM is in danger of getting mangled.

How do you determine where the centre of the bed is? its not going to be centre of travel in most cases. I think centre of the mesh is a good default. For most people it's probably going to be close to the centre of their build area, with an option to manually select a point.

I think in general... Probably 95% of the people print things in the center of their of the bed. So probably, it would make sense to normalize that area of the mesh to 0.0000 mm. (so this is a further refinement of the earlier thinking that where ever the printer homes should have its Mesh point normalized to 0.00000 mm.) With regard to P5 being the final step... I didn't mean to imply that. Just as P0 and P1 are sort of mutually exclusive. Mostly, the 'P' numbers go in order. But that doesn't mean that a person needs to do each one. For example: It might be perfectly fine to do a P1 and not do a P2 to manually probe. Instead, you do a P3 to fill the unprobed areas.

I wish @jbrazio would come off of 'Holiday' and help me with documentation!

[Nocturnal42]

Yes!!! Always save multiple copies of your Mesh!!!! There are plenty of slots to store them in. Use them!

I do, and I did (once I figured out I actually had to manually save them :-(). I even wrote a function that would repeatedly auto probe the mesh and store it into different spots, just so I could compare the results (related side note, my inductive probe seems to take one run through before the readings really stabilize).

I agree most people center prints on their bed (approximately), the thing is Marlin has no idea where the center of my bed is. All it knows it the length of my axes, and the center of my bed is not the center of my X/Y axis. Your not thinking about printers that don't home to the bed. Which is why I think the center of the mesh is the best choice as it's most likely to be near the center of the bed in most cases.

They are called "Phases" and are numbered sequentially. To me that implies the equivalent of calling them steps. Which you move through sequentially from start to finish, possibly skipping one or two depending on circumstances.

[Roxy-3D]

the thing is Marlin has no idea where the center of my bed is. All it knows it the length of my axes, and the center of my bed is not the center of my X/Y axis. Your not thinking about printers that don't home to the bed. Which is why I think the center of the mesh is the best choice as it's most likely to be near the center of the bed in most cases.

Marlin knows where the X & Y Min and Max positions are. So I can set it up to default to the middle of those. And it would be good to allow the user to over ride that calculation. Some people are not going to want to print in the center of their bed.

  #define MESH_MIN_X X_MIN_POS
  #define MESH_MAX_X X_MAX_POS
  #define MESH_MIN_Y Y_MIN_POS
  #define MESH_MAX_Y Y_MAX_POS

They are called "Phases" and are numbered sequentially. To me that implies the equivalent of calling them steps. Which you move through sequentially from start to finish, possibly skipping one or two depending on circumstances.

Yes. I understand the source of the confusion. The root cause of this is GCode only allows single letter parameters. And they can't be reused. And then some (like T and M) are not officially allowed. So, in order to keep some 'meaning' to the parameter letters, some names do get forced.

[thinkyhead]

And then some (like T and M) are not officially allowed

T is okay as an argument. It should always refer to the tool index.

[Roxy-3D]

T is okay as an argument. It should always refer to the tool index.

Or in the UBL G29 case: to say all Tools will have Three-Point-Leveling applied to them.

[thinkyhead]

Or in the UBL G29 case…

That would make UBL the first GCode in the history of the world to use T for something new. Breaking all kinds of new ground. I'll have to inquire with CNC world and see how they favor this revolution, whether they appreciate its necessity.

[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.