(My first post here.) I feel printer tuning is still to a large extent a black art that we should be able to turn into a systematic process. As an experiment, I wanted to see if there was an easy way to calibrate the pressure advance coefficient and hacked together a short python script that generates a sequence of fast and slow linear extrusions.

In this case I did a rather extreme version where print speed changed between 5 mm/s to 100 mm/s, and the pressure advance setting changed from 0 to 0.2s over 10 mm z height.

In this case the optimal setting looks to be 0.074s. (Extruder is direct driven Titan Aero.)

I've attached the script advance_cal.py and sample test.gcode if anyone else wants to try. The gcode assumed the bed center is (0,0) and likely requires a preamble (heaters, cooling fan etc). I pasted those from another file.

Is this generally a valid approach, or am I missing something?

edit: Updated script to support a bed center parameter, proper print height for z0, and python3 compatibility.

I reconfigured my 3 stepper/leadscrew bed to use 3 independent drivers instead of 2 (getting a DueX2 for the one extra driver needed) and added a mechanical endstop on each axis homing the bed like a delta printer. It works well – but one thing I wanted to test was how repeatable the endstops were.

The firmware doesn't seem to offer a way to test this apart from possibly reconfiguring the endstop under test into a temporary zprobe – so I made a simple simple firmware hack to addH4 option to the G1 command to stop – but not re-home the axis on an endstop hit. I could then log the reported Z pos and repeat multiple times for the three different endstops. Plotting the results as histograms:

Some interesting observations. The green and blue endstops seem to be accurate to within ±2 µm (when doing the final homing at 100 mm/min feedrate) which was better than I expected. The orange one had a few outliers –(late triggering) of up to -12 µm – which is probably still not a big deal but higher than necessary. I'll replace this endstop eventually.

One simple way to improve the homing accuracy that I've used in the past on another firmware is to multi-tap the endstop (e.g. 3,5 or 7 times) and pick the median value. The way RRF is designed though I don't see a straightforward way to implement this. Maybe if there was a g-code command to add the current position to a median accumulator register – and another g-code to move to the accumulated median position plus an offset this could all then be implemented as macros. This functionality could also be used for improved bed probing accuracy.

Anyway, just thought I'd share this. Having a way to measure endstop accuracy seems like a nice feature to add (something like the H4 option described above), and a way to improve endstop accuracy by filtering out outliers by picking the median position.

The issue is solved now. Thanks everyone for valuable input.

The fact that I got slightly different grain density between 0.6 and 0.4 mm extrusion width made me suspicious. Looking deeper at the grain patterns, comparing them side-by side, I found that they were not perfectly consistent print-to-print. This made me suspect something mechanical.

The other clue was the fact that the grain patterns changed not with Z, but with layer count. Basically, the shift happened every time the y axis moved. And what could mechanically gradually shift several centimeters over the duration of a print? I could think of only one thing. The recirculating balls in the linear bearings. So I took my y axis apart. The motion of the two bearings felt perfectly smooth when moved by hand, but I still took them apart, took all the balls out – cleaned them with mineral spirits and dried them with ethanol – and among the small pieces of dust and debris that came out of one was what looked like a tiny piece of aluminium shaving. Repackaged them with PTFE grease and issue solved.

@phaedrux said in Curious wood grain pattern on Core XY prints:

0.08 seems a little high for a direct drive extruder

I calibrated it using this technique: https://forum.duet3d.com/topic/6698/pressure-advance-calibration Really quick method to get the value dialed in accurately. (The only other thing I needed to do was to increase the default infill-to-perimeter overlap setting in my slicer, since you can no longer rely on blobbing at the end of long infill lines to fill in the gaps.)

@rcarlyle said in Curious wood grain pattern on Core XY prints:

Is it more visible at higher print speeds or lower print speeds?

Changing print speed made almost no difference at all.

Here's another example on a different printer with a different extruder. Holding the print up to the light clearly shows the inverted color gradients showing differences in extrusion volumes.

@deckingman said in Pressure Advance Calibration:

@digitalvision Did you really mean extrusion rate between 5 and 100mm/s or did you mean print speed? I suspect the latter as an extrusion rate of 100mm/sec is nowhere near attainable and would relate to a print speed in the order of 5,000 mm/sec.

Yes, I meant print speed – thanks for pointing that out. The theory being that with proper pressure advance the extrusion width should remain constant independent of print speed and acceleration/deceleration.

@wilriker said in Pressure Advance Calibration:

@digitalvision Might be relevant to other trying to test: this is python2 syntax and won't run with python3.

Thanks – updated the script to be python 2/3 compatible. Apologies for the messy script too – this was literally a 15 minute hack.

@obeliks said in Pressure Advance Calibration:

So if I want to have gcode for printer with 0,0 on the corner I need to change to this?
curr_x = 110
curr_y = 110

I updated the script to allow a bed center setting.

I encountered a similar issue the other day on my CoreXY printer. Here's a PLA spiral mode print of a ø20mm cylinder, 0.1 mm layer height, 0.4 mm extrusion width limited by the slicer to 5 s per layer which translates into ~12.5 mm/sec nozzle speed or 0.5 mm^3/s.

I first suspected z stage issues (the vertical period is ~.5 mm (5 layers) which is a quarter the z stage pitch), but wanted to test if it could be extruder related when I noted that the diagonal patterns spiralled around the print. The horizontal period for the pattern is ~6.3 mm – and this doesn't correspond to a the step size (~96 steps/mm @ 16 microstepping) and is also far too small to correspond to the hobbed gear tooth spacing. Still, I tried another print with a wider extrusion width of 0.6 mm to see the effect on the pattern and somewhat surprisingly the phenomenon disappeared completely:

Repeating this with higher print speed also eliminated the issue. So my suspicion is that when printing with too low of a flow rate the nozzle back pressure is insufficient to preserve a laminar flow and the result seems to be a periodic pulsing pattern.

I haven't seen this phenomenon with other filament, and this particular one has the most amount of die swell I've ever seen – free air extrusion from a 0.4 mm nozzle swells to 1.7 mm.

@obeliks said in Pressure Advance Calibration:

@digitalvision Thanks.
Now can someone explain my stupid ass how to output the result to a file?

Try:

python advance_cal.py > advance_cal.gcode

@wwmotorsports

Here's a suggestion for a quick experiment that might help narrow down the cause.

• Print a single walled cylinder diameter 100 mm without infill. Spiralized/vase mode should work. No bottom layer needed. Make sure the print is centered on the print bed. Observe the print to see if the pattern appears.

• If it doesn't appear clearly change the object to an equilateral triangle.

• If the pattern it doesn't appear, add a second perimeter and infill.

• If the pattern is asymmetric it is probably related to one of the three towers / arms. The direction of asymmetry could tell you which.

• If the pattern is symmetric around the bed center, increase the extrusion factor to 150% (can be done during printing – for a single walled print this is equivalent to increasing the extrusion width by 50 %).

• If the pattern changes in frequency or pitch angle – it stems from the extruder.

• If it doesn't change, it's likely motion related.

To see if I could separate extrusion from motion effects, as an experiment, I built a small jig to measure the thickness of a single-walled print. I then printed a 150 mm long print with uniform print speed (50 mm/s), but varying extrusion volume (0.7 -> 0.4 -> 0.7 mm extrusion width) as a step function. One caliper of the jig measures thickness (mechanically magnified 4x) and another the x position along the test print. Manually measuring a number of positions gave the following result. I'm treating wall thickness * layer height * linear distance as an approximation for extrusion volume here (ignoring the fine layer induced surface structure).

For a first quick experiment, I'm pretty happy with how nice the data looks. Interfacing digitally with the calipers would make this a lot quicker though.

I'm not sure why the first segment didn't converge to the same value as the last one – but I can see some minor ripples that look like the print needs a bit more cooling towards the end of the first segment that may pollute the measurements a bit. I'll retry with some delay between each layer to allow for more cooling next time.

@dc42, when running at constant linear speed but varying extrusion rate like this pressure advance doesn't seem to have any effect. Is that expected?

I'll redo this for a few different extrusion rate pairs and see how well I can get the current model to fit.

@dc42 said in Pressure Advance Calibration:

Yes, that's the same model as assumed by the pressure advance algorithm.

Cool. Thanks for confirming!

Have you tried repeating the measurements with pressure advance of about 0.2sec applied?

Yes, but in short it doesn't work. Pressure advance doesn't seem to be applied when doing extruder feedrate-only changes like I do here. E.g.

G1 X40.000 Y100.000
G1 X140.000 Y100.000 E2.4945 F3600
G1 X200.000 Y100.000 E3.4923 F3600
G1 X260.000 Y100.000 E1.4967 F3600

Outside of this test – running pressure advance with a time constant of 0.2 leads to severe under-extrusion during deceleration moves. It is a direct drive non-bowden extruder where I get best results with pressure advance of around 0.08s.

Here's another more precise measurement with a corresponding linear model fit.

The lagging extrusion compared to the model on the last positive impulse is curious and consistently repeatable. My only hypothesis so far is that the extruder melt pool cools down during the high rate impulses sufficiently to increase the viscosity and slow down the response – but that's far fetched. It shouldn't be related to deceleration since the acceleration ramp should be much much shorter (0.03 s) than the scale here.

@dc42 said in Firmware issue: forced stop between print and non-printing moves:

What the firmware actually does is to apply jerk only between printing moves, because the purpose of allowing jerk is to permit the printing speed to be maintained when there is a small change in printing direction, such as when printing a curve. When jerk is not allowed, if one of the motors is stopping then they must all stop in order to remain synchronised.

I can see that this will cause a problem if you use coast-to-end. I guess this hasn't been raised before because pressure advance is a better solution than cost to end, so Duet users rarely use coast to end.

I have made a note to review this in time for the next major release after 2.02.

Thanks. Agree re. coast specifically but other variants are useful. I feel extruder jerk should probably always be enabled – at least I don't see a downside with that.

An issue I found is that RRF (2.02rc3) doesn't allow the printhead to move continuously across extrusion and non-extrusion moves. I noticed it when experimenting with manual pressure advance – but I believe this causes slicer features such as "coasting", "wiping" and "wipe during retract" to not behave optimally. Here's an example of gcode that causes problems:

G1 X105.000 Y100.000 E0.4963 F2250
G1 X105.078 Y100.000 E0.1039 F2250 ; advance
G1 X145.000 Y100.000 E2.6556 F2250
G1 X145.078 Y100.000 E-0.1039 F2250 ; retract
G1 X185.000 Y100.000 E1.3278 F2250
G1 X185.078 Y100.000 E0.1039 F2250 ; advance
G1 X225.000 Y100.000 E2.6556 F2250

Here, the printhead is supposed to be moving at a continuous speed (37.5 mm/s) along the x axis, while switching between two different extrusion widths – but when printing the print head decelerates down to zero at the retract move – causing a huge blob in the print.

Modifying the firmware like this

+++ b/src/Movement/DDA.cpp
@@ -330,7 +330,7 @@ bool DDA::Init(GCodes::RawMove &nextMove, bool doMotorMapping)
                else
                {
                        directionVector[drive] = (float)delta/reprap.GetPlatform().DriveStepsPerUnit(drive);
-                       if (drive >= numTotalAxes && nextMove.coords[drive] > 0.0)
+                       if (drive >= numTotalAxes && nextMove.coords[drive] != 0.0)
                        {
                                extruding = true;                                               // flag this move as extruding even if the number of extruder microsteps is zero
                        }

makes it treat the retraction just like any print move and eliminates the glitch in the print:

What is the reason for forcing the printhead to come to a complete stop between printing and non-printing moves?

Here are measurements from three different step functions in extrusion rates:

And here they are individually:

I'd not completely trust these measurements. There is some hysteresis in the measurement jig that makes these values not perfectly repeatable (probably varies by up to ±5 % when remeasured), and the lower speed extrusions suffer from some extrusion pulsing that makes a width measurement more questionable. That being said – the general shape and trends should be fairly accurately captured.

Let's try to create a simple model: Assume there is a property p that roughly corresponds to what one could call 'pressure' inside of the hot end, and let's assume the rate of change of this property with time corresponds to

p'(t) = i(t) - o(t),

where i is the input rate (feed rate) of filament into the hot end, and o is the output or extrusion rate of molten plastic from the nozzle. We then assume that the extrusion rate is a function of this property p: o = f(p). The simplest possible function is a simple linear correspondence:

o = k*p

for some k. Substituting this function into the change rate p'(t) gives:

p'(t) = i(t) - k*p(t),

Which gives a simple differential equation. Fitting this to the data to find the model parameter k yields the following results:

The optimal model parameter found was k = 6.507 (the unit for i and o is mm^3/s). While this extremely simple model is obviously not a perfect fit (there seems to be some second order lagging extrusion), it still seems to explain most of the observed behavior.

@dc42, would this model be similar or even identical to the one currently used?

@synapsis, it's a bit hard to see from that photo, but here's roughly what I think you see:

It's a bit weird that the four different bands look so different from each other. What are your jerk and acceleration settings? What type of extruder?

For the right setting here, I'd try the orange arrow location. Above it pressure advance is too aggressive leading to under-extrusion during deceleration.

@deckingman said in Pressure Advance Calibration:

I just think of "jerk" as a necessary evil that we have to put up with.

Based on some experimentation I theorize that some "jerk" might actually be advantageous and make the motion smoother. Consider the motion platform a dynamic system (difference in actual vs commanded nozzle position). This can be modeled as a spring-damper system, which models e.g. ringing artifacts. "jerk" effectively puts some pre-tension on the spring in this system which in some of my tests seems to lead to a more faithful adherence to a linear acceleration profile, and in turn make the assumption pressure advance is based on more accurate.

To see if I could separate extrusion from motion effects, as an experiment, I built a small jig to measure the thickness of a single-walled print. I then printed a 150 mm long print with uniform print speed (50 mm/s), but varying extrusion volume (0.7 -> 0.4 -> 0.7 mm extrusion width) as a step function. One caliper of the jig measures thickness (mechanically magnified 4x) and another the x position along the test print. Manually measuring a number of positions gave the following result. I'm treating wall thickness * layer height * linear distance as an approximation for extrusion volume here (ignoring the fine layer induced surface structure).

For a first quick experiment, I'm pretty happy with how nice the data looks. Interfacing digitally with the calipers would make this a lot quicker though.

I'm not sure why the first segment didn't converge to the same value as the last one – but I can see some minor ripples that look like the print needs a bit more cooling towards the end of the first segment that may pollute the measurements a bit. I'll retry with some delay between each layer to allow for more cooling next time.

@dc42, when running at constant linear speed but varying extrusion rate like this pressure advance doesn't seem to have any effect. Is that expected?

I'll redo this for a few different extrusion rate pairs and see how well I can get the current model to fit.

@deckingman said in Pressure Advance Calibration:

Pressure build up in the hot end is both a function of how fast you try to cram filament into it and also the time that you maintain that filament speed (within limits). The pressure build up continues way beyond the acceleration phase and well into the constant speed phase. So if you only calibrate it during the acceleration and deceleration phases, then when you start to do long moves at highish speeds, you'll find that more compensation may be needed.

I may have mischaracterized this approach as only being "acceleration and deceleration ramps", as with moderate acceleration settings it really contains long periods of constant speed extrusion – and as you say you can see pressure effects persisting for a long time after the acceleration ramp.

But hey, I'm not going to labour the point. If you are happy doing it that way, then that's fine. I have a different way of calibrating pressure compensation which works very well indeed for me (edit - and there is no asymmetric requirement for the start of a move and the end of a move) .

I'd love to learn more. I proposed this approach since it was fairly easy and quick and gave consistent results that seem to improve print quality significantly compared to not doing any calibration. I'd be the first to jump on a better method. My only disagreement would be with the claim that there is something fundamentally wrong with this approach – like it's abusing a parameter to fudge something mostly unrelated. I still think it's a sound approach.

I just get nervous when people suggest that changes should be made to the way something in firmware works (in this case pressure advance) to suit their particular test method. In a nutshell, "it ain't broke (for me) so please don'y fix it".

I don't think I ever went as far as suggesting a firmware change – especially not based on a synthetic test like this. I merely meant that with a single parameter there is a slight compromise to be made. E.g. in one case I could see a pressure advance parameter of 0.055 being the ideal for the deceleration phase while 0.050 provided a more uniform correction for acceleration. If one picks a balanced value between those you are probably not far off.

@deckingman said in Pressure Advance Calibration:

I have an upcoming blog post that includes pressure advance in the testing, and I think it will surprise quite a few people.

Looking forward to it.

@deckingman said in Pressure Advance Calibration:

Which all comes back to what @RCarlyle has been saying and what I have been banging on about for quite some time, in that whilst this technique may give improvements, it's using pressure advance to compensate for non-pressure related problems.

I'm not sure I follow. This test is all about pressure related compensation. The script ramps extrusion up and down between two extremes and allows selecting a setting that gives an as uniform result as possible.

The lag time between an XY move accelerating up to speed and the extruded filament accelerating up to the same speed, is not the same as nozzle pressure build up.

The fact that the slope of the extrusion ramps are tied to xy acceleration is not necessarily wrong. That's exactly the ramps you will encounter during printing.

Here's a mental model: If you change the minimum speed in the script to exactly match your max instantaneous speed change ("jerk") setting, and shrink the length of the short segments (pattern_width) to something insubstantial like 0.1–0.5 mm, the extrusion profile generated here will perfectly match the one you get if you print for example an outline of a cube, or do linear infill.

The short segments are stretched out here is because it exacerbates the effect. It allows all (most) of the excessive pressure to bleed off, and separates the effects of overpressure during deceleration from the underpressure during acceleration. The purpose is to make the effect more apparent in order to make tuning easier. I don't think this is adding a systematic error to the process – but I may be wrong.

The thickness of the short segments is (generally) not related to nonlinear extrusion. It s a long continuous blob – exacerbated by the profile.

If you look at the last image I posted, the extruder moves left-to-right on the front outline of the print. On the bottom part of the print you see severe underextrusion during acceleration (gaps in the print) that correspond to what you would see when printing sparse linear infill. This is the opposite of pressure build-up – but also corrected for by the pressure advance parameter.

I reviewed the results I posted above and the reason I saw a color gradient on the short extrusion segments is because of over- and under-extrusion due to pressure lag. Basically, with insufficient pressure advance the short segment tends to become one long elongated blob. If one modifies the script to increase the length of the short segment (pattern_width) the center of the slow segments are not thicker than the centers of the fast segments when measured with a caliper on my tests on two different printers. That is not to say that others may see nonlinear extrusion effects already at 8mm^3/s. If one is concerned about this, I'd recommend increasing the length of the slow speed segment.

So the method seems valid. I can also report that print quality is improves significantly: this approach virtually eliminates corner and infill blobbing, and under-extrusion during fast sparse infill moves.

Also worth noting is that the single parameter pressure advance model doesn't completely eliminate all acceleration dependent effects – there seems to be some nonlinearities left. There is also some asymmetry in respect to acceleration and deceleration that isn't modelled completely.