Issues with pressure advance since RRF 3.4

Notepad

@oliof I have been looking at the code, and it looks like the PA only uses a linear relationship of pressure to movement speed. Over Christmas I will be looking at ways to add different algorithms to the PA to change it from a linear relationship to maybe accepting a quadratic based algorithm instead

tommyb

@Notepad Any luck in understanding this issue any better?
I basically gave up printing over this , and not just bulging corners but start/end of layer issues. And without specific notes to confirm....prior to 3.x I have beautiful prints on the same printer!
One repeated theme throughout this thread is 0.6mm nozzle with Volcano (and Hemera). This too is my setup (well was since I gave up).

It also seems PA is missing a fundamental understanding considering Vol is a ^3 function and PA has been reported as a linear response function....but since the formulas have not been posted I could be wrong here.

Jerk will always compete with PA for material flow since Jerk reduces residence time but not flow at intersecting travel events, while PA having no knowledge of reduced time intersections event, compensates for excess flow at longer residence (during decel) times and increased flow and shorter residence (during accel) times. It would be really nice if the math were shared and some sort of temporal plot created whereby using the math alone, the zones of goodness could be determined vs wasting so much plastic to try and test this. It sure seems like a mm3/mm travel could be the output and the goal is to show where variation is minimized for various combinations. Every printer is different, but the math is the math and a perfect model should be the starting point. Fudge factors such as bowden tubes stiffness factors deviates from the perfect model, whereas a direct drive might be closest to the perfect model (choose your perfect model).

I finally closed up shop when I had holes, blobs and or bulging corners but never acceptable at all three locations that I could fix. In short I wasted too much time and plastic and finally gave up and stop by here occasionally to see if there has been any new insight.

There has to be a smarter way!

Notepad

@tommyb
Definitely some luck. I have identified a specific line of code that can be modified to allow for a user settable exponent based PA value. I still fully intend to get this tested yet I have unfortunately had external distractions eating up all my spare time to actually implement the change and to validate if it works.

In theory, the change will allow for all current PA values to be respected (by having the exponent default to 1) so behaviour will be unchanged. But when the exponent is raised past 1, it can start becoming more aggressive to match the magnitude of the pressure differential.
It is by no means a perfect process, as I have yet to fully work though all the maths that can be contributing factors, But hopefully it will at least minimise the problem.

The biggest improvement I have made actually came by accident as I was analysing a new nozzle design I have been working on. The long and short of it is just to reduce the maximum flow rate to minimise the amount of cold core printing. This didn't fix the issue, but it did let the issue subside slightly back into the lowest acceptable standard.

Argo

Just wanted to report that with RRF 3.6 (beta) the issue is gone. Pressure Advance works as intended with input shaping.

T3P3Tony

@Argo thanks for confirming that.

Chriss

@Argo Argo is back in town...

CCS86

@Argo

Man, I sure wish the Maestro didn't get kicked out of the party before this issue was resolved.

Phaedrux

@CCS86 said in Issues with pressure advance since RRF 3.4:

@Argo

Man, I sure wish the Maestro didn't get kicked out of the party before this issue was resolved.

The issue is still present in 3.5.4?

Argo

@Phaedrux

Yes but I can't say whether it has improved compare to RRF 3.4 as I can't remember the results anymore as it's almost two years ago.
With RRF 3.6 beta pressure advance is visually unaffected by input shaping. Corners are very sharp with normal PA values.

T3P3Tony

@CCS86 it just not have the power!

droftarts

@CCS86 @dc42 made a build of 3.6.0-beta.2 for Maestro for internal testing, to see how bad it would be. I tried it on my Maestro-equipped delta printer. This was printing at 100mm/s, bed mesh but no IS or PA, and had a large number of hiccups, totalling almost 12 seconds of time in a simple 15-minute print (which is a lot)

=== Move ===
Segments created 88, maxWait 138992ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0/133392 (11888.88ms), max steps late 0, ebfmin 0.00, ebfmax 0.00

While visibly the print looked okay, the lack of FPU on the Maestro means it just can't handle the code complexity. If it was this bad with this simple example, it would just get worse with anything more complicated.

I also tested the same print on 3.5.4. No hiccups, but one Underrun, which is less of an issue than actual hiccups (for some reason I did it without mesh enabled, though)

=== Move ===
DMs created 84, segments created 47, maxWait 10279136ms, bed compensation in use: none, height map offset 0.000, max steps late 1, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 207302, completed 207302, hiccups 457, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1

As a 'cheap' version of the Duet 2 WiFi/Ethernet, the Maestro has had a good run. Duet3D EOL'd it June 2020, and I think the design is nearly 7 years old, back when the RRF 1.x was current. It still works, it just hasn't got the power to support the firmware developments made in that time.

Ian