kartchnb / AutoTowersGenerator

A Cura plugin to automate the creation of 3D printer calibration towers (e.g. temperature towers, retraction towers, etc)
GNU Affero General Public License v3.0
139 stars 11 forks source link

Feature request: Virtual nozzle-size test #107

Open KJ7LNW opened 8 months ago

KJ7LNW commented 8 months ago

We have found that adjusting the virtual nozzle size can change the accuracy of a model borders. For example, if you have a 0.4mm physical nozzle and specify 0.35mm in Cura, then it will overshoot in XY while printing, producing slightly larger parts. OTOH, a specifying 0.45mm in Cura will undershoot producing slightly smaller parts.

I would like to calibrate using nozzle size to get the most accurate model borders as measured by calipers. If there was a test that went +/- 0.01mm x10 steps near the nozzle size, then we could measure the print with calipers to see which is the closest to true.

Since this is an XY test, a flat print with posts and holes so it is not a "tower" but could be a useful calibration tool:

_________________________
|  O  |  O  |  O  |  O  |  <- round posts
| ( ) | ( ) | ( ) | ( ) |  <- round holes
|  ■  |  ■  |  ■  |  ■  |  <- square posts
| [ ] | [ ] | [ ] | [ ] |  <- square holes
|0.35 |0.36 |0.37 |0.38 |  <- calibration text
-------------------------

The base could be ~5mm and the posts could be ~5mm high. This doesn't need to be very tall, just tall enough to get a good grip with calipers to test its behavior.

What do you think?

kartchnb commented 8 months ago

I love this idea because it would be very useful. However, I see it being difficult (for me) to implement.

Right now, all of the calibration models involve changes made at layer transitions. This is relatively easy because, with Cura, it's easy to identify when a layer change happens in gcode and update it during post-processing. This calibration, however, would be involve making different changes on the same layers in the gcode, which is more difficult to implement.

I'm not saying it's possible and I think it would be a worthwhile challenge. It will have to go on the back burner, for now, until I or someone else has enough time to implement it.

I appreciate the suggestion! If I can crack this, it will make a lot of other calibrations possible.

KJ7LNW commented 8 months ago

Interesting about the Z-change consideration.

What if each tower were discrete components with the "one-at-a-time" setting enabled? Then the settings could be per island.

kartchnb commented 8 months ago

Perhaps. It's a good thought. I haven't looked into that approach. Thank you!

KJ7LNW commented 8 months ago

Another idea came to me, too:

Lets say that the test build goes from x=0 to x=100, and there are N=10 tests.

Then, any move with 0<X<10 is test1, 11<X<20 is test2, and so-on.

You can easily parse G0/1 X/Y/Z calls with regular expressions (which might be what you're doing already for Z for existing towers).

Then just insert any machine config G-code above the move that would apply to that particular testN. This would allow changing machine settings between test positions on the same Z-layer.