pa calib: batch mode for pa pattern

[buzzhuzz]

Description

Add batch mode for PA pattern calibration: generate a set of tests for a given list of accelerations and printing speeds. Better to use in conjunction with #7178

Screenshots/Recordings/Graphs

pa-pattern-batch-mode.mp4

(screen recorded on a build with both current and #7178 PRs applied)

Tests

Limited testing. Community testers are welcome.

[cochcoder]

Really nice work so far!

Would it be possible to print as many pa tests as possible on one build plate in object-by-object mode? It would help save even more time when testing for adaptive pa, while also keeping the results accurate. (At least that's how it seems in my head)

[igiannakas]

This is fantastic, thank you very much for picking this up and doing the work on it! Awesome :)

[igiannakas]

A suggestion if I may - the Pa pattern test is of fixed Y size. We also know the build plate size. Could we add a function that arranges as many as possible in the Y direction and spacing the cubes by the Pa pattern test plus some margin?

[buzzhuzz]

@cochcoder, @igiannakas, thank you for suggestions.

In theory this is possible, however we could be limited by tool head collision check algorithm we currently have for by-object print sequence which is taking into account vertical projection of the tool head and does not care about approaching angles of the nozzle and part cooling vents.

It may not be an actual issue since this test is only 4 layers tall. However we also need to consider a possibility user will have custom cooling like UFO featured at NeedItMakeIt video :

[igiannakas]

I don’t think it’s necessary to print by object - the Pa value is set at the start of each line. We could issue the same for print speed and acceleration commands so the test is consistent on a print by layer approach :)

[buzzhuzz]

Somehow, the idea to pack several tests to a single plate is growing on me. I'll check what could be done.

[jeremytodd1]

I'm +1ing the thought for multiple PA pattern tests on one print sheet. I initially thought that was what this pull request was for, but then I watched the little video clip and was surprised it was still spitting out the tests on individual plates still.

I think it'd be very nice if we're able to condense the entire adaptive PA testing process in just a couple of print sheets. Doing them 1 at a time takes forever.

[buzzhuzz]

@jeremytodd1, originally idea of this change was to reduce a manual work associated with tests setup since it was too many manual steps to configure single tests as well as need to manually track how much tests were made and which are left.

Small update: it seems we'll going to have multiple tests per plate. I still need to do some cleanup and testing, but most of the changes related to custom gcode generation is done.

[buzzhuzz]

I think I've got something worth testing:

pa-pattern-batch2.mp4

The only problem remains is related to UI: you should slice model either at first plate and switch plates at gcode preview page, or use "slice all" button. Somehow slicing does not work yet if you slice not the first plate.

[buzzhuzz]

It is time to test this PR.

On my side I've done few prints on my Creality V3 SE (220x200, 3 patterns per plate)
I've also did test slicing for Bambu A1 to see how those tests will be placed. As a result I've changed padding a bit, so now 4 patterns fits A1 plates (so should on X1 and P1, too).

Current implementation enables multiple pattern per plate for rectangular plates only.

[igiannakas]

I haven't tested it yet but just noting down some of my experiences with the PA test and the code around it:

1. Because the PA test is a mix of a physical object (the cube) and the custom g-code (the pattern) we need to make sure the print parameters are set correctly after printing the cube perimeters.
2. What this means is setting acceleration and print speed every time to match the requested values before the pattern starts printing and after the cube.
3. We also need to be careful with retraction and un-retraction - again because the gcode state machine doesnt know of any retractions & wipe operations performed on the cube vs the custom gcode part of the test

I think you've got that covered but thought just to make a note for testing purposes, especially on how these areas are handled.

[buzzhuzz]

I have checked Acceleration and Speed set correctly for each pass (there are commit specifically for this), but I did not pay attention to other parameters assuming they are the same for all tests.

[dewi-ny-je]

Found a bug. I have PLA silk limited to 8 mm3/s. If I set batch to speed 40,95 and then I slice ok, max vol. speed is 7.73. If I set 40,100 it generates the cubes, then once I click "Slice", it crashes.
crash_Fri_Dec_06_22_44_42_0.zip

[dewi-ny-je]

Also, the PA window is resizable, but nothing resizes. Either the elements should be resizable, or the window should not be.

[dewi-ny-je]

Maybe it's late to ask, but I have to point out that I find quite cumbersome to be asked to provide speed and acceleration, when the actual parameter used by the adaptive PA algorithm is flow rate and acceleration.
First of all, there's the bug I mentioned which crashes orca if the resulting flow rate exceeds the filament limits so inputting flow rates would make it easier to circumvent it (while it's being patched).
Second, dynamic/adaptive PA in filament settings requires flow rate and acceleration, besides PA value. Why would then the calibration tool for that specific feature require me something different?

Would it be possible to switch from speeds to flow rates, and use the layer height which is set in the usual settings to obtain, internally, the speeds?

I think it would be way more user friendly and consistent.

[SoftFever]

@buzzhuzz It looks nice! Thank you.
I found an small issue, the objects are not visible in the "Objects" tab, which makes it difficult to check accel and speed for each pattern.

[buzzhuzz]

Sorry for late reply. I had some work to do last month. I'll check bug mentioned by @dewi-ny-je and problem mentioned by @SoftFever somewhere next week.

[buzzhuzz]

Would it be possible to switch from speeds to flow rates, and use the layer height which is set in the usual settings to obtain, internally, the speeds?

This is a good question actually. Despite flow rate being metric which actually defines the print speed, users usually referring to the speed in mm/s as a printing speed metrics. In addition to this, only print speed in mm/s available in print configs. Current implementation uses mm/s as it inherits configuration used previously. Having dedicated text field just for the speeds we might input volumetric speed there and offload volumetric to linear speed recalculations to the calibration flow.

It could be implemented and I kind of like switching to volumetric speed as an input for PA calibration routine. @Noisyfox , @igiannakas , what do you think, would it be good change?

[dewi-ny-je]

From my point of view

1. speeds were the unit of measure in the past, because slicers didn't have volumetric flow capping, but today with fast printers most of the time the print speed is limited by flow rate, the slicer has quite high speeds set which is not usually reached
2. independently from the usual practice, if the final output of the calibration is based on flows (as the text field for PA in the filament settings is), flow should be used
3. it feels a bit wrong to input speeds and then having to rely on the flow printed on the patterns to produce the calibration numbers!

[buzzhuzz]

Now all objects could be found in objects tree:

Unfortunately, I wasn't able to reproduce crash with the flows greater than max defined by filaments.

Additionally, I've tried to implement Volumetric speed inputs for the PA pattern calibration. It works mostly OK, but result flow for the patterns does not match values specified within configuration due to some rounding errors within calculations.

I may revert back to linear speed inputs if needed.

[dewi-ny-je]

@buzzhuzz

Unfortunately, I wasn't able to reproduce crash with the flows greater than max defined by filaments.

It seems I also cannot with your latest build using volumetric inputs. I'll report back once more tests are done.

[igiannakas]

hi there! I've been testing this for a little while and got a few inputs for your consideration:

Use of volumetric flow vs speed
While indeed adaptive PA is using volumetric flow as the model input, this presents a couple of challenges that are more apparent the more you use the feature. Namely:

1. Usability
2. Compatibility with single PA tests

basically I am in agreement with your comment above here: #7199 (comment)

Pressure advance, from when developing adaptive PA, is observed to depend on volumetric flow rate (for which speed is used as a proxy) and acceleration.

When not using adaptive PA, typically a user calibrates for a specific speed (usually an in-between the external and internal perimeter speed), at a specific layer height which they mostly print at and with an acceleration that is typical of the external features they print. This gives a good all round calibration when not using adaptive pressure advance. Yes indeed the effect is that print speed + layer height + line width -> flow rate but the user calibrates for a print profile, not a specific flow rate, hence that mental disconnect if that makes sense.

By requesting the test being done in terms of flow rate, it is incrementally difficult for the user to set the input parameters, especially if they have no interest in adaptive PA (eg. bambu lab users for which the feature is not appropriate, or for filaments that are infrequently used).

When using adaptive PA, the user is intended to calibrate again in the speeds and layer height they use the most. That is because the mathematical model used has zero delta error in predicting a PA when the input parameters match the calibrated model parameters. Eg. there will be no deviation between forecast PA and measured PA for a specific print speed, layer height and acceleration.

As such, the user should be using calibration parameters that are as close as possible to the real world use of the printer - eg. if they print external perimeters at 50mm/sec, internal at 150mm/sec and sparse infill at 200mm/sec, a calibration model of 50-100-150-200 should be executed. At the typical layer height they use.

Therefore, using flow rate as an input to the calibration process would make the calibration workflow more convoluted:

1. Because for single PA test users they have to figure out the flow rate of the print and use that in the test
2. For adaptive Pa users, it would be tricky to confirm whether they are close to the intended speeds they intend to print at

Therefore I would recommend that this change is reverted to the test. The only benefit this has is to make the calibration model numbers round, while introducing a change that is not immediately intuitive for users.

Bugs:
In addition, there are a few issues with the impemetantion as it stands right now.

1. The volumetric flow speed input is an integer - this should be a float if volumetric speed is to be used (especially as smaller nozzles are much more sensitive to this)
2. The Outer Wall Speed text box is set incorrectly when a test is performed with a single PA and single acceleration value

Hope this is useful :)

[dewi-ny-je]

@igiannakas are people really printing at a certain speed? I don't think so: I have (and all standard profile follow this approach) a higher than needed speed, which will be limited based on filament profile.

This is why I assumed flow rate makes more sense: I have literally no idea of the speeds I'm printing at, I know that PLA is set to 14 mm³/s, ABS 17, either one in Rapido/HF/HS variant does, in my printer, 24 mm³/s. Speeds follow.
Also, I might change layer height and I'll still maintain maximum flow rate.
The default profiles for my printer also don't change speed depending on layer height (0.16 and 0.2 mm, at least, while 0.08 and 0.30 are clearly a different case).

Knowing speeds is something that dates back to i3 times, when people knew 60 mm/s is standard speed, 90/120 high speed, and 20-30 mm/s the speed for slow/difficult filaments.

Now? I wonder.

Whoever does batch mode is not unlikely printing using my approach, so I think at least the option to input flow rates (as floats, as you pointed out) makes sense.

[igiannakas]

@igiannakas are people really printing at a certain speed? I don't think so: I have (and all standard profile follow this approach) a higher than needed speed, which will be limited based on filament profile.

This is why I assumed flow rate makes more sense: I have literally no idea of the speeds I'm printing at, I know that PLA is set to 14 mm³/s, ABS 17, either one in Rapido/HF/HS variant does, in my printer, 24 mm³/s. Speeds follow. Also, I might change layer height and I'll still maintain maximum flow rate. The default profiles for my printer also don't change speed depending on layer height (0.16 and 0.2 mm, at least, while 0.08 and 0.30 are clearly a different case).

Knowing speeds is something that dates back to i3 times, when people knew 60 mm/s is standard speed, 90/120 high speed, and 20-30 mm/s the speed for slow/difficult filaments.

Now? I wonder.

Whoever does batch mode is not unlikely printing using my approach, so I think at least the option to input flow rates (as floats, as you pointed out) makes sense.

They are - let me explain why:
Resonances:
All printers have resonances at certain speeds that are requiring you to avoid certain print bands - see below for example my voron for example.

This requires you to avoid certain zones when printing things like external perimeters to avoid creating VFA's and internal features to avoid resonating the motion system.

Hence print profiles are tuned to allow for specific speeds with the volumetric flow rate being the overall cap for the filament/hotend combo.

What you'll see above are three major zones - a low vibration one up to around 65 or so mm/sec - a resonant zone from 65-105 or so, and a lower resonant but not as low as the first one, from 105 and above. This means that for best quality I need to print below 65mm/sec.

Therefore based on the vibrations profile for my printer I have tuned 2 separate profiles

1. a high quality one that prints external perimeters at 60mm/sec and internal features above 110-120mm/sec and
2. a high speed one that has external walls at 120mm/sec and internal features at 150mm/sec. This still gives great prints but can result in slight surface quality variations just by the nature of the higher amplitude vibrations in that region compared to the lower speed one
3. In both profiles I'm using 250mm/sec speeds for solid and sparse infill.
4. Top and bottom surfaces printed at 40mm/sec for appearance purposes

This way I avoid the resonant zone between 65mm/sec or so and 105mm/sec.

Part strength:
The higher the print speed and (hence flow rate) the lower the part strength. For my high strength profile I limit the print speed to 60mm/sec - 110mm/sec and 150mm/sec for sparse and solid infill.

While you can achieve the same by reducing the overall flow limit of the filament, I've found it more useful to be able to tweak the specific print speed of individual features to cater for the strength characteristics I care about. For example if I plan to push

Print quality:
Even if the hot end can push significantly higher flow/volume I find that limiting the external feature print speeds to well below its limits allows for much higher external surface quality. Tweaking the speeds allows to target quality where you need to. Specifically:

1. external features printed slowly,
2. sparse infill printed at the flow limit,
3. solid infill at the flow limit, top and bottom surfaces at a comparatively slow speed to achieve smoothness.

Also dont forget material changes in appearance the faster you print - for example this is the reason I've implemented this change here: #5148
As the faster you print the lower the material shine, while still being within the flow limits of the material. So I'd argue that print speed is as relevant as ever, or possibly even more, with fast printers precisely due to how materials behave the faster or slower you print.

So for me, I treat the flow rate as a global speed limit for the material, while using print speeds as the primary parameter to achieve the objectives I need - speed, quality, strength and at what balance with each other, if that makes sense?

[buzzhuzz]

Thank you for your testing and in-depth discussion on calibration approaches.

Let me revert volumetric speed configurations and return back to linear speeds in order to complete this PR. We could discuss calibration inputs in separate issue/PR.

[buzzhuzz]

@igiannakas , I've fixed special case when only 1 value is given for either speed or acceleration. Now global config shows actual test values in this case.

[dewi-ny-je]

If speeds have to be entered, it makes even more sense to save the last used values so I'll get them without having to calculate them each time.
It's useful also for people using speeds as input.

@igiannakas I'm still unsure so many people approach the issue like you, since those resonance graphs are not even obtainable on the vast majority of printers... Probably basic users use speeds without adaptive PA, intermediate use adaptive PA with speeds capped by volumetric flow like me, and very advanced users go back to speeds for optimal optimisation.
Ideally the users should be allowed to enter either one, speed or flow.

[igiannakas]

You can get those resonance graphs on any machine running klipper - it’s the shake tune plug in which for the Voron community is very popular tuning wise :)

For non klipper machines the orca VFA test does something very similar.

I’d strongly recommend any user to be tuning based on speed and using flow as a cap and not go out max speed on all features. You can get some very good prints like that.

all of the below were printed on my V2.4 350 with the above strategy :)

[dewi-ny-je]

@igiannakas

You can get those resonance graphs on any machine running klipper - it’s the shake tune plug in which for the Voron community is very popular tuning wise :)

Not really, not all Klipper printers are open to add modules and not all are on the latest klipper, or can be updated to it. Qidis cannot, for example, unless heavy changes are applied. I could use an old SnT on my Q1, but X-3 series cannot.

Not to mention that in Qidi forums I see many people asking what to do with those graphs, so even those who can, can't do always much with them.

You are a very advanced user (suffice to say you coded the adaptive PA and various patches to klipper, isn't it?) so your point of view tends to be skewed and assume a bit too much from the users.

For non klipper machines the orca VFA test does something very similar.

Ok, this is a stronger point, of course, which everyone can ACTUALLY do, unlike SnT.

I’d strongly recommend any user to be tuning based on speed and using flow as a cap and not go out max speed on all features. You can get some very good prints like that.

all of the below were printed on my V2.4 350 with the above strategy :)

yeah they look as clean as my ABS prints on my Q1 Pro without doing anything of those speed and frequency optimisation but simply capping top speed automatically based on layer and max flow rate, so not a great argument to support doing a much more complex tuning for no improvement.

Let's put it another way to proceed further: no matter whether we like flows or speeds for this batch PA tuning, do we agree that in both cases having the last set of values inputted by default would save all of us time? I'll save the speed/flow conversion, but if it's precompiled with the latest values, it's a one time only annoyance. You don't have to do the conversion, but still easier to have already there the values you would input again.

I think that, considering the amount of typing alone needed to input maybe 9-16 lines (3x3, up to 4x4), offering the previous set of calibration points makes sense.