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)

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

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?

@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 :

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 :)

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

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.

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

I think I've got something worth testing:

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.

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.

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.

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.

@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 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?

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.

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

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.

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 :)

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

@SoftFever any chance you could review this potentially for inclusion in the beta? Have been using this feature since October with no side effects from what I can see :)

@igiannakas indeed.
The (last year I checked) greyed out check boxes look however a lot like a work in progress so they should be fixed before inclusion.

I dont think the greyed out boxes issue is present any more - at least not in the latest cut I'm using right now :)

@dewi-ny-je , even if thhere are any GUI relaed issues present, their fixes not gonna happen in this PR due to:

1. This change uses existing functions to add checkbox. No checkbox behavior, nor styling is changed here
2. Any GUI styling changes/fixes are not related to the core functionality of this PR

There are #7289 created to address this issue.

@buzzhuzz
Could you also update the WIKI so that people know how to use it?

@SoftFever , I'm not sure how to do tihs. Should I make a comment here or how do I make a pull request for a wiki page?

Take a look here for inspiration: #6491

basically update this doc here: https://github.com/SoftFever/OrcaSlicer/blob/main/doc/Calibration.md

I've modified "Calibration" and "adaptive-pressure-advance" adding batch mode details.

quick conflict resolution if you dont mind @buzzhuzz - following merging of this PR: fbfbb09

Thank you @buzzhuzz for your work. The document is fantastic ;)

@igiannakas Thank you for reviewing testing it, you are amazing!