Pressure Advance: Discussion for Future Development

bot

Can you post a gcode file you’ve printed and had bad experiences with in regards to PA?

CCS86

I can't remember with confidence which files I tried and failed to get a good result. The next time I have that issue, I will set the code aside.

I decided to try to make a test print that I hoped would replicate my PA issues for demonstration. Just a short, narrow print, which necks down from an 8mm width, to 2mm width. This object is copied 4 times, printed one at a time, with M572 D0 S0, S0.5, S1.0, S1.5.

I photographed the results with my macro lens, but it's really hard to make judgement from the photos. In hand, they all look similar. If anything the S0 print looks best. With PA enabled, you certainly lose a bunch of time.

QuintBrand

I relate to your ideas and findings. I have a nimble though, so bit different situation. A nimble has trouble to keep up wit PA due to its high gear ratio (as noted on duet website). So although direct drive it has some "bowden like" behavior in PA. My findings:

using Marlin routine I need S0.54
using the Python script approach I need S0.6
in real printing I find better results with S0.4

So lower than in the tests with I think relate to your observation on for the under extrusion on very short lines.

I have no need anymore for coasting in cura, and overall I have better quality. I hope and think you do too right? It's about improving it even more.

So I think your idea on the minimum amount of time could work well. I'm wondering if it should be time or travel length though? That would take out the need to tune each time when you print with different speeds for different prints, or even when using different speeds while printing different features.

I think having both options would be best to tinker with.

Also I would think it would be even nicer if one can give two parameters:

length/time No PA
length/time Full PA.

And an interpolation in between to give a sliding PA value?

No idea how hard to implement, but I bet it would be a selling point when this works well (I'd be happy to test when indeed working well.

While think about it: anybody know how to modify a gcode file to search for short line length and putting an M572 in front (and after) to change the settings with some existing scripts or something to prototype test?

Cheers Q

QuintBrand

Seems little interest CCS...

Slzer

I ended up just using 0.5 for my PA on my long bowden setup despite all tests indicating more or less no change until 1.5-2 range.

I'm actually getting quite nice results but I was simply limited by what didn't cause the extruder to sound like a machine gun

Exerqtor

@Slzer

That's exactly what i ended up doing to (well i setteled on 0.4), even though i would get the most consistent pressure somewhere close to 2, but it sounded like my BMG was one nudge away from exploding at that point

Designed new extruder mounts so i could move the extruders over the build area (corexy machine) and shorten the bowdens down to 300mm ish, so 0.4 isn't that much off.

CCS86

@QuintBrand said in Pressure Advance: Discussion for Improvement in Bowden Printers:

Seems little interest CCS...

Were you waiting on my feedback? It sounded like you were generally agreeing with me and not asking questions.

I don't think "length" is a better parameter to use for filtering over "time". We are dealing with time based phenomenon, ie lag between extruder drive motion > nozzle pressure > nozzle flow rate. How fast the print head is traveling doesn't impact these things.

Edgars Batna

I have resorted to printing without PA now. In my case I observed that the extruder reverse motion gets skipped on consecutive small segments, thus all my over-extrusion issues ensued.

I also dug in the Firmware and at some point it just stopped being fun as there are multiple approximations related to step generation which smell bad. Having no handy HW simulation tools it just took too long to debug with all the variables.

I saw Klipper implements "smoothing" for PA, so I started moving to it to test it out. While there are pros and cons between Duet and Klipper (I still like the Duet), but at least in Klipper the CPU basically only runs the step pulses, so no need to deal with interrupts being late or whatnot.

Not finished yet, tho.

QuintBrand

@CCS86

Hey, no I was not trying to push you in any way, but actually trying to support this tread from sliding away as I think it is an excellent idea to get the "gun" effect out of the printing with PA .

I think bit time and length would be nice. I agree that if we'd "need to choose" time is probably better, but when printing at (quite) different speeds for infill, walls etc I think length is also nice.

I also went from 0.4-0.5 found from testing to 0.2 to ease the printing somewhat and get good results anyways too.

RyanP

@Exerqtor said in Pressure Advance: Discussion for Improvement in Bowden Printers:

@Slzer

That's exactly what i ended up doing to (well i setteled on 0.4), even though i would get the most consistent pressure somewhere close to 2, but it sounded like my BMG was one nudge away from exploding at that point

Designed new extruder mounts so i could move the extruders over the build area (corexy machine) and shorten the bowdens down to 300mm ish, so 0.4 isn't that much off.

Answers like this make me not feel alone in the world.

Slzer

@RyanP said in Pressure Advance: Discussion for Improvement in Bowden Printers:

@Exerqtor said in Pressure Advance: Discussion for Improvement in Bowden Printers:

@Slzer

That's exactly what i ended up doing to (well i setteled on 0.4), even though i would get the most consistent pressure somewhere close to 2, but it sounded like my BMG was one nudge away from exploding at that point

Designed new extruder mounts so i could move the extruders over the build area (corexy machine) and shorten the bowdens down to 300mm ish, so 0.4 isn't that much off.

Answers like this make me not feel alone in the world.

Aye me too... Most calibration things I can see the difference and select a good balance (although often having to run multiple parameter ranges to get a matrix of options - stringing control being a good example here, move speed, retraction length, retraction rate wipe etc.) but this one feels like black magic hah

Exerqtor

Just saw this tutorial pop up, note that it is for klipper-fw, but it should be translateable for RRF to i think. Gonna try it tomorrow and see what numbee i end up with this time

https://www.lpomykal.cz/anycubic-kossel-klipper-pressure-advance/

CCS86

@dc42, any thoughts on this?

CCS86

@dc42 I was really hoping you would weigh in here!

CCS86

@dc42

dc42

I'm sorry, I don't have time to look at improving PA until I've implemented input shaping. But I've bookmarked this thread so that I can return to it. Pressure advance smoothing is something I was already thinking about.

Hergonoway

while we're at it, is there any impact using DAA (Dynamic Acceleration Adjustment: M593 with F != 0) during PA calibration process? DAA is related to acceleration where PA is jerk related, technically one shouldn't alter the other result but... heavy doubt

or is it better to turnOFF DAA, calibrate PA, then calibrate/turnON DAA ?

dc42

DAA might reduce acceleration, so it may affect PA - but only because in reality, PA should not be applied linearly. I think I would be inclined to calibrate DAA first followed by PA, however I haven't tested doing it both ways so I may be wrong.

pkos

Forgive the reference, but that's the way Klipper does it. First you do input shaping and only then PA.

Speaking of input shaping - since you are looking at it - are you also considering the option of using an accelerometer (like adxl345) to get the measurements?

dc42

@pkos said in Pressure Advance: Discussion for Future Development:

Speaking of input shaping - since you are looking at it - are you also considering the option of using an accelerometer (like adxl345) to get the measurements?

Yes.