Open qwertymodo opened 1 year ago
borland1
commented
1 year ago Can you post some sample mesh data at various temperatures? If the bed temperatures across the plate were the same, there should not be any significant differences in bed flatness over wide temperature changes. Likewise, for small differences in bed temperature, there should not be significant differences in mesh data ( e.g., PLA bed temp vs. PETG bed temp ).
SFRSKZ
commented
1 year ago this bothers me a lot with pinda 2. from 60 c to 70 there is a 0.3mm difference. g76 is pretty difficult to calibrate for me. wish printer would remember the offset that match different temps.
qwertymodo
commented
1 year ago Can you post some sample mesh data at various temperatures? If the bed temperatures across the plate were the same, there should not be any significant differences in bed flatness over wide temperature changes. Likewise, for small differences in bed temperature, there should not be significant differences in mesh data ( e.g., PLA bed temp vs. PETG bed temp ).
Here are some meshes, all taken on the same machine. I've gotten much more significant differences on one of my other machines in the past, but it's not currently running, so these are a bit more subtle.
22C:
( 15,218) (218,218)
0 1 2 3 4 5 6
6 | +0.07 +0.04 +0.03 +0.02 +0.02 +0.04 +0.06
|
5 | +0.03 +0.01 +0.01 -0.00 -0.00 +0.02 +0.06
|
4 | +0.02 +0.01 -0.00 -0.01 -0.00 +0.03 +0.05
|
3 | +0.04 +0.02 [+0.01] -0.00 +0.01 +0.03 +0.06
|
2 | +0.04 +0.01 +0.01 -0.02 -0.01 +0.02 +0.05
|
1 | +0.06 +0.02 +0.01 -0.01 -0.01 +0.05 +0.05
|
0 | +0.12 +0.06 +0.04 +0.05 +0.02 +0.05 +0.08
0 1 2 3 4 5 6
( 15, 15) (218, 15)60C:
( 15,218) (218,218)
0 1 2 3 4 5 6
6 | -0.03 -0.04 -0.03 -0.04 -0.04 -0.03 -0.03
|
5 | -0.03 -0.03 -0.02 -0.02 -0.02 -0.02 -0.01
|
4 | -0.01 -0.01 -0.01 -0.02 -0.01 +0.01 +0.02
|
3 | +0.01 +0.00 [+0.01] -0.01 +0.01 +0.02 +0.03
|
2 | -0.00 -0.01 -0.00 -0.02 -0.02 -0.01 +0.01
|
1 | -0.02 -0.03 -0.02 -0.03 -0.04 +0.00 -0.03
|
0 | +0.00 -0.02 -0.02 -0.01 -0.05 -0.03 -0.03
0 1 2 3 4 5 6
( 15, 15) (218, 15)85C:
( 15,218) (218,218)
0 1 2 3 4 5 6
6 | -0.06 -0.06 -0.05 -0.06 -0.05 -0.07 -0.07
|
5 | -0.05 -0.04 -0.03 -0.04 -0.03 -0.04 -0.03
|
4 | -0.03 -0.01 -0.01 -0.01 -0.01 -0.00 +0.01
|
3 | +0.00 +0.01 [+0.02] +0.01 +0.01 +0.01 +0.02
|
2 | -0.02 -0.01 +0.00 -0.02 -0.03 -0.02 -0.02
|
1 | -0.04 -0.04 -0.03 -0.05 -0.05 -0.03 -0.06
|
0 | -0.04 -0.05 -0.04 -0.03 -0.07 -0.08 -0.08
0 1 2 3 4 5 6
( 15, 15) (218, 15)115C:
( 15,218) (218,218)
0 1 2 3 4 5 6
6 | -0.15 -0.13 -0.10 -0.10 -0.12 -0.13 -0.16
|
5 | -0.11 -0.08 -0.05 -0.06 -0.06 -0.07 -0.09
|
4 | -0.06 -0.04 -0.02 -0.03 -0.03 -0.03 -0.03
|
3 | -0.03 -0.01 [+0.01] +0.00 -0.01 -0.01 -0.02
|
2 | -0.06 -0.03 -0.02 -0.03 -0.04 -0.03 -0.05
|
1 | -0.10 -0.08 -0.06 -0.08 -0.09 -0.07 -0.13
|
0 | -0.13 -0.11 -0.11 -0.11 -0.14 -0.15 -0.19
0 1 2 3 4 5 6
( 15, 15) (218, 15)
gudvinr
commented
1 year ago One of the biggest factors that causes bed mesh changes is the temperature of the bed
Unless you use very thin plate it should only result in vertical expansion. If it bows, either bed mounting is rather bad or bed itself made of something that shouldn't exist.
With that being said, issue you're trying to solve isn't caused by mesh leveling system and what you're suggesting is just a workaround for underlying hardware issue.
That can be mitigated by simply putting G21 Lx in your slicer for material with higher bed temperature/
E.g. in prusa slicer you can even have conditions like this:
{if first_layer_bed_temperature > 0 && first_layer_bed_temperature < 65}G29 L1{endif}Unfortunately, Cura doesn't have macros like Prusa Slicer, nor does it have any ability for custom start gcode on a per-material basis, so there's no way to automatically select the correct bed mesh based on the bed temperature. As for why this happens, it's not a bed mounting issue, as I've confirmed by completely removing the bed tensioner wheels to ensure that it wasn't an issue of over-constrained thermal expansion causing the bowing, and it still happened exactly the same. My best guess is that it's due to uneven heating, which can be measured clearly with a non-contact thermometer. The bed gets hottest in the middle and cools off around the edges. The hotter the set point, the greater the temperature delta, and therefore the greater the bowing. Sure, my suggestion is a "workaround for a hardware issue" but that's technically true of the entire concept of software bed leveling, this is just one more way to improve it.
plampix
commented
1 year ago As a workaround, you could use the 'Gcode Macros' plugin for octoprint, and define a macro that loads the proper mesh for the required bed temp.
qwertymodo
commented
1 year ago As a workaround, you could use the 'Gcode Macros' plugin for octoprint, and define a macro that loads the proper mesh for the required bed temp.
That assumes I'm using octoprint. In my case, that assumption may be correct, but notwithstanding that assumption is not always true.
gudvinr
commented
1 year ago Unfortunately, Cura doesn't have macros like Prusa Slicer, nor does it have any ability for custom start gcode on a per-material basis That assumes I'm using octoprint
Point is that there are ways to mitigate that right now and apart from you it doesn't seem like an issue for anyone else.
Buying machined aluminum plate realistically would be way faster than waiting for this feature.
that's technically true of the entire concept of software bed leveling
Concept of software bed leveling doesn't care why you have potato bed because it doesn't matter. Once you start printing, conditions are more or less stable so there's no real need for dynamic bed mesh manipulation.
This just adds complexity. It's unnecessary thing when adding slot loading to your start gcode already does the job.
I think there are ways to do that even in Cura, e.g. by using post processing scripts, plugins or whatever else.
And there are cases where you might need to use different profiles that do not depend on the temperature. For example, different bed sheets might need different meshes (or at least different mesh offset) or you might want to squish some PLA flavors a bit more without having to change bed temperature, etc.
There's no way to cover all these cases which also pretty solvable by putting the right line in start gcode.
borland1
commented
1 year ago There is a G-code (M503) feature in Marlin that allows saving configurable Settings in EEPROM to a file (SD-card), but I know of no way to upload such Settings from a file to EEPROM. I assume these Settings include the bed leveling Mesh data. If Marlin was revised to allow Restoring EEPROM Settings from a file, that might be a good workaround solution.
gudvinr
commented
1 year ago There is a G-code (M503) feature in Marlin that allows saving configurable Settings in EEPROM to a file (SD-card), but I know of no way to upload such Settings from a file to EEPROM.
No need to because OP already uses UBL which stores mesh data separately in "slots" from which you can load mesh with G29 Lx. You can have quite a few of those.
qwertymodo
commented
1 year ago Buying machined aluminum plate realistically would be way faster than waiting for this feature.
I'm not "waiting" on this feature. I'm suggesting it as something that would be helpful for a lot of people using cheaper printers where a "proper" machined and stress-relieved bed plate costs more than the entire printer itself, so no I don't consider that a reasonable alternative.
Concept of software bed leveling doesn't care why you have potato bed because it doesn't matter. Once you start printing, conditions are more or less stable so there's no real need for dynamic bed mesh manipulation.
This is true for temperature-caused warping as well. Once your bed is up to a certain temperature, the shape of the bed is more or less stable to what it was the last time you printed at that same temperature. However, the same is not necessarily true of that same bed at a different temperature.
And there are cases where you might need to use different profiles that do not depend on the temperature. For example, different bed sheets might need different meshes (or at least different mesh offset) or you might want to squish some PLA flavors a bit more without having to change bed temperature, etc. There's no way to cover all these cases which also pretty solvable by putting the right line in start gcode.
That's why I said the feature should be given a flag in the gcode command, making it an optional feature, not a hard-coded function. You can still manually load whatever slot you want if that fits your needs better.
DVSVIDEO
commented
1 year ago Instead of storing a bed mesh with different temperatures, you should have a solution like the one I use successfully under the klipper firmware: Adaptively mesh is the name. How it works:
Triangulix
commented
1 year ago Point is that there are ways to mitigate that right now and apart from you it doesn't seem like an issue for anyone else. Buying machined aluminum plate realistically would be way faster than waiting for this feature.
This is an issue for many other people. Us other people just didn't write a report since your reply was completely foreseeable.
Is your feature request related to a problem? Please describe.
One of the biggest factors that causes bed mesh changes is the temperature of the bed, which leads to increasing amounts of warping as the temperature increases. However, that warping is often very consistent at a given temperature. Because of this, the ability to store multiple bed meshes and quickly switch between them could be improved significantly by storing the temperature of the bed that the mesh was probed at, and then add a gcode flag to automatically load the mesh slot closest to the current bed temperature. Currently, the only way to use the multiple mesh slots for different temperatures requires you to remember which slot is for which temperature, and manually switch slots any time you change bed temperatures (i.e. when changing materials).
Are you looking for hardware support?
N/A
Describe the feature you want
The feature involves two parts, both involving the addition of a new flag to the unified G29 command. There aren't many letters left unused, so I'll just pick 'N' for the sake of example. The 'N' flag can optionally be followed by a number indicating the bed temperature for the mesh, or it can be omitted (or if that isn't possible, a value of -1 can be used), in which case the current target bed temperature is used (not the current exact temperature because that can fluctuate).
The first part of the feature comes into play when storing the mesh, and simply takes the value of the 'N' flag, whether explicit or implied from the current temperature, and stores that value as part of the bed mesh data. If the 'N' flag is completely omitted, then the current temperature should be used.
e.g.
G29 S1 N65 ; Store the current mesh to slot 1, for temperature 65 G29 S2 N95 ; Store the current mesh to slot 2, for temperature 95 G29 S3 N ; Store the current mesh to slot 3, for the current bed temperature
The second part of the feature comes into play when loading the mesh. The 'N' flag is also used here, and can again take an explicit value or else use the current bed temperature. When the 'N' flag is included along with the 'L' flag to load a mesh, instead of loading the last-used mesh, it looks through all valid stored meshes, and loads the one with the temperature closest to the 'N' value. If more than one mesh has the same temperature, or is the same closeness to the 'N' value, just choose the first one, or maybe if one of the possible options was the last-used one, choose that, or however you want to resolve the issue, that's something that can be figured out.
e.g. (assuming the meshes above are the ones currently stored)
G29 L N45 ; Load the mesh in slot 1, because 65 is the closest match G29 L N80 ; Load the mesh in slot 1, because slot 1 and 2 are both equal matches, so load the first one G29 L N ; Load the best match depending on what the current bed temperature is
Additional context
N/A