I tried calibrating the adaptive PA and the results clearly show lower PA with higher acceleration, and higher PA with higher speed.
But I have a clone CHT, not a straight bore nozzle.
I think I’ve figured it out! It’s back-pressure on the nozzle from the print surface!
I’ve been doing some more tests with my Flashforge Adventurer3 which doesn’t support Pressure Advance, but I can simulate it in gcode. It has a longish bowden and lots of print artifacts that suggest it would benefit from PA. It’s also not very fast.
My tests also repeatedly indicated that Kf drops at higher velocities. This didn’t make any sense; why would it get easier to push out each mm^3 if you push faster? I was struggling to think of why; backlash, friction, sticktion, etc… none of these would really match what I was seeing.
Then I was doing some super low-speed prints (1mm/s with zero extrusion) in tests as a way to try and identify when the back-pressure was fully relieved by retraction, and I kept getting signs that the flow rate was almost independent of the pressure; it was going to extrude a line almost the same thickness regardless of incremental changes in pressure advance. Watching closely it finally hit me.
The nozzle is extruding into a bead of cooling filament that is pressed against the print surface. Below a certain pressure threshold it cannot push past that bead and the flow is effectively zero. So what actually drives the flow rate at these low pressures is nozzle movement, moving away from the flow-blocking bead. At a constant head speed and with sufficient feed rate it will draw a pretty consistent line, with the bead smearing behind he nozzle. The advance pressure doesn’t make much difference because the flow rate is dominated by the back-pressure and nozzle speed moving away from that back-pressure.
At higher nozzle speeds and flow rates, the pressure for the flow rate through the nozzle starts to dominate. I suspect the back-pressure will still be there and might be pretty constant at any speed for a given layer height, track width, and extrusion ratio. since the smearing bead shape will be pretty much the same for the same track shape regardless of the speed. It might drop a bit as speed increases because the smearing bead has less time to cool and will flow better, but i’m not sure how much difference that would make. I don’t think the bead cools much under the nozzle at even super slow speeds.
But the pressure to push through the nozzle increases with flow rate, and the total pressure needed is the sum of the back-pressure and the flow-rate pressure.
This suggests that maybe a better but still simple model would be linear with velocity (or maybe velocity squared) but also with a constant offset. The constant offset would vary with the track shape (mostly layer height, but also line width and extrusion ratio).
I don’t have all the tests and numbers finalised yet, but so far linear with a constant offset is looking like it might be pretty good, at least for the speed ranges my Adv3 can do.
I’m still not sure if the flow pressure should be velocity or velocity squared yet. It might depend the flow rates, with lower flow rates being close to linear, and higher flow rates hitting the Bernoulli velocity squared behaviour.
An un-accounted for constant back-pressure offset would affect how PA looked depending on the speeds you looked at. At really high speeds you might not notice it at all and see PA as increasing with speed. At mid-speed ranges it might look like PA is constant. At low-to-mid speeds you might see PA as decreasing with speed.
I haven’t really thought about how changing acceleration might affect things yet. I don’t think that’s something I can change on the Adv3.
What does it mean you can simulate PA in gcode?
I can generate my own gcode that does what printers with PA support does in firmware as per the Kinematics docs, messing with the extrusion deltas vs the X and Y deltas.
I started down this path when I realised that retract/restore on printers without Pressure Advance is actually relieving/reapplying the accumulated advance pressure. In the FlashPrint gcode output, when it had a retract at the end of a fast line and then restore at the start of a slow line, it would spit out a big blob. Usually the slow line was slow because it was part of some fine details, which the blob makes a mess of.
So I wrote a gcode post-processor in Python that would adjust the retract/restore distances based on the calculated accumulated pressure advance and print speeds. This needs to know what the pressure advance Kf value should be, so I wrote some more Python to emit gcode for pressure advance calibration, fiddling with extrude vs X Y speeds. This has made me notice the non-linearity and try to figure out a better pressure advance model.
That kinda simplifies the story a bit… there was quite a few diversions along the way, the biggest being because I initially thought the blobs were a cooling problem so I invented and implemented a better cooling model that fiddles with fan speeds as a function of the extruded heat, again by post-processing the gcode.
Which gcode command do you use to move the extruder forward and backwards to increase or relieve pressure?
I thought PA cannot be obtained via gcode
The gcode mostly just consists of a bunch of G1 X<n.nn> Y<n.nn> Z<n.nn> E<n.nnnn> F<nnnn> instructions where the X,Y,Z arguments are the position to move to in mm, E is the extruder drive position in mm, and F is the speed in mm/min. For Adv3 these arguments are all absolute positions, so the E argument is the mm of filament extruded and generally keeps incrementing throughout the print. The gcode most slicers generate includes moves (changing XYZ without changing E), draws (changing XYX and incrementing E), retractions (reducing E without changing XYZ), and restores (incrementing E without changing XYZ).
You can almost instantly relieve pressure by retracting the extruder… giving an E value that is less than the previous E value, or slowly by just incrementing E slower than it squirts out the nozzle. You can apply pressure by incrementing E faster than it squirts out the nozzle. Note that if your printer calibrates with pressure advance Kf=1.0 it means that any (so fast it’s effectively a) step increase in E will take about 1sec to mostly extrude out the nozzle. Maintaining a pressure advance requires just incrementing E fast enough that it stays ahead of what’s come out of the nozzle.
So you can dynamically adjust the advance pressure by emitting gcode that increments and/or decrements E at different rates relative to the XYZ movements that lay the track.
What is true is it’s not really possible to do it very accurately or efficiently in gcode.
The gcode generally descibes the intent of the extrusions, but it doesn’t describe exactly what the printer should do. The gcode says “go from this position to this position at this speed extruding this much filament evenly over that distance”, but the printer can’t do that exactly because it has to accelerate from the speed it has from the previous instruction, and decelerate to the speed it needs for the next instruction. While it’s accelerating or decelerating it needs to also accelerate and decelerate the extrusion rates to match the speed so that the extruded line is consistent.
The printer firmware knows exactly what speed it is going at any moment, so can calculate the exact extruder speed needed to extrude the consistent line requested by the gcode. Printers with firmware that supports PA takes into account that the rate filament is extruded out the nozzle doesn’t exactly match the extruder rate, but requires extra extrusion to give the pressure needed for the desired flow rate. Printers that don’t support PA effectively have Kf=0.0 and assume extruder rate equals nozzle flow rate.
The gcode cannot know exactly what speed the printer is going at any moment to give an accurate corresponding E value. However, if you know roughly how your printer interprets gcode into actual movements, you can kind of figure it out, and generate gcode that the printer will interpret into movements that include PA compensation.
The kinematics doc describes how the firmware interprets gcode into movements using constant acceleration rates. If you know the acceleration rate of your printer, you can emit gcode that splits a single line into three lines for the acceleration, constant speed, deceleration phases and give them extrusion values that result in the pressure advance ramping up and down with acceleration/deceleration.
But even without all that… just changing the Flashprint generated gcode to dynamically adjust the retract/restore distances to take into account PA will fix the “big blob on restore for slow line after retract from fast line” problem.
I finally got to test @dmbutyugin 's nonlinear PA and it’s really impressive, with much better seams and cleaner sharp corners that wiggle less.
Still need to do a bit of tuning, though. I fired off this print with parameters estimated using spreadsheet math.
I was using all offset and no linear component, and I think it needs a bit more linear and a bit less offset.
…I guess I can say that my original ask has been fulfilled.
I finally got my THE 100 together and tuned it, and Dmitri’s PA test plus nonlinear PA plus input shaper sync plus time offset gives me absolutely immaculate corners at all speeds and accelerations. I tested up to 50k accelerations and 300 mm/s, and it produces perfect corners even down at 5k acceleration.
With Bowden, high acceleration comes with tremendous demands on the extruder, but I chose my extruder and motor to be as fast as possible. Now the only issue is that for small parts PA itself runs over the filament too many times to print a simple 3DBenchy well.
Nonlinear and time offset does help a lot on direct drive as well though. I tuned an SV06+ to perfection and it’s noticeably better than normal old linear PA.