Issues with pressure advance since RRF 3.4
-
@CCS86 said in Issues with pressure advance since RRF 3.4:
@deckingman why are you taking this so personally?
You seemed to be suggesting that low jerk could be used generally. I pointed out that your test was very specific an not representative of general printing. Not sure why that would offend you.
Because I'm trying to broaden our collective understanding of how jerk works in "real life" by doing extensive testing. You've taken that post in isolation and reached completely the wrong conclusion. Had you bothered to look at my previous posts you'd have seen that I'm not suggesting anything of the kind - quite the opposite in fact. Thus far with other tests (just scroll up a bit), I've shown that the longer the segment length or greater the angle between segments, then in order to maintain fluid motion at near constant speed, the higher jerk needs to be. Personally I get best overall prints using a jerk of 1500 but I've shown that, if the segment lengths are short enough or the angle between them is shallow enough, then you can use much lower jerk - down to 100 in certain cases.
To my mind, this qualification is better than simply stating "..........printing curves composed of linear segments requires moderately high jerk" as you have done.
But if people are not going to bother looking at the other data I've produced, and wish to filter my output to focus on one individual snippet of data, then I'm wasting my time.
-
@gloomyandy said in Issues with pressure advance since RRF 3.4:
@deckingman Thanks for running those tests. The results are inline with what I would expect...
My understand of the code is that it will be the angle between the segments that impacts the required jerk setting for smooth motion, not the length (though obviously when decomposing a curve the two are related). The feedrate for the segments is also part of this, in that higher feedrates will require the angle between the segments to be shallower (and thus a closer approximation to a straight line) for the same jerk setting to allow smooth motion.
Yes, I agree. It seems to me that higher jerk is more "universal" in that it works better than low jerk where the segment angle is high but works equally as well as low jerk where the angle is shallow.
-
@deckingman The question is what are the downsides of high jerk settings. Klipper mentions that it can impact input shaping, but I've no insight into that. But I also have a sneaking suspicion that some of the PA problems that folks are seeing may be down to high jerk values. If you have a high jerk setting then when the print head arrives at a 90 degree corner it may be moving with that velocity, I suspect that (at least on some/most printers, which may not be super mechanically stiff) this may result in the extruder depositing filament "beyond" the corner and so cause a "corner bulge".
-
@gloomyandy I kind of find the opposite - If the jerk is too low, the extruder goes round the corner too slowly, and this leaves a corner bulge. I find that a jerk of no less than 2100 is required in combination with my other settings to control corner bulge. I am using a delta with direct extruder.
-
@Adrian52 Interesting, that is a pretty high jerk setting, what speeds and accelerations are you using? I'm running a toolchanger with relatively low jerk (around 300mm/min, acceleration 8000mm/s^2) and highish speeds (up to 150mm/s) and don't seem to have any real problems with bulging corners (I do have plenty of ringing at those speeds though, if the part I'm printing needs a better finish I use 80mm/s for perimeters).
-
@gloomyandy I think we need to separate out extruder jerk from axes jerk.
For any XYE move, the lowest jerk will apply to all the other axes (where the extruder is treated as an axis) in order to keep everything in sync, so it makes sense to set extruder jerk high so that it doesn't slow down the other axes.
But when it comes to PA something else comes into play which is applied only to the extruder. The XY axis moves as normal but the extruder speed is modified. It is accelerated faster at the beginning of a move and decelerated faster at the end but the overall feed amount is kept the same. Again, it seem that high extruder jerk is better then low with PA.
When you say ".....klipper mentions that it can affect input shaping......" do you happen to know if they are talking about axes jerk or extruder jerk or both? Also, does high axis jerk help with IS or is it a case that high axes jerk can induce ringing which therefore amplifies the benefit of IS? (That's just me being cynical).
-
@deckingman I don't think klipper allows different jerk settings per axis. See the docs here: https://www.klipper3d.org/Config_Reference.html#printer you specify the square cornet velocity (which is the nearest thing to jerk that Klipper has) to the printer, not to an axis.
As far as I can tell (from looking at the Klipper source) square cornet velocity is not applied to the extruder.
It seems that Klipper also has problems with curves and square cornet velocity, see the discussion here: https://github.com/Klipper3d/klipper/issues/4228
-
@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
-
@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!
-
@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.
-
Just wanted to report that with RRF 3.6 (beta) the issue is gone. Pressure Advance works as intended with input shaping.
-
@Argo thanks for confirming that.
-
@Argo Argo is back in town...
-
Man, I sure wish the Maestro didn't get kicked out of the party before this issue was resolved.
-
@CCS86 said in Issues with pressure advance since RRF 3.4:
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?
-
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. -
@CCS86 it just not have the power!
-
@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.00While 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 -1As 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
