RRF 2.03 pressure advance causes 20% overextrusion
-
@dc42 just hoping to bring this to your attention, I'd really like to work out what is going on here.
-
@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:
However, when I print this part with pressure advance on (set to 1.0, calibrated using this script),
how long is your bowden tube? A Value of 1 is VERY high.
Very long bowden (800mm+): S0.7 and up
also reducing extruder jerk is counter productive for pressure advance.
also you should consider updating to at least 2.05.1. 2.03 is very old.
-
@Veti said in RRF 2.03 pressure advance causes 20% overextrusion:
@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:
However, when I print this part with pressure advance on (set to 1.0, calibrated using this script),
how long is your bowden tube? A Value of 1 is VERY high.
Very long bowden (800mm+): S0.7 and up
790mm. The value for PC is higher than the value for PLA. It is tuned correctly.
also reducing extruder jerk is counter productive for pressure advance.
also you should consider updating to at least 2.05.1. 2.03 is very old.
No significant changes to pressure advance since then according to the history in DriveMovement.cpp. Not opposed to upgrading, just don't think it will change anything.
-
@Veti said in RRF 2.03 pressure advance causes 20% overextrusion:
also reducing extruder jerk is counter productive for pressure advance.
It shouldn't change the number of total steps taken.
-
pressure advance does really quick movements back and forth.
there could potentially be slipping filament. the titan extruder does not have the tightest grip on the filament.
-
@Veti said in RRF 2.03 pressure advance causes 20% overextrusion:
pressure advance does really quick movements back and forth.
there could potentially be slipping filament. the titan extruder does not have the tightest grip on the filament.
The right way to confirm a firmware issue vs a mechanical issue is to log the net steps sent to the motor driver through the entire print. It should be exactly or almost exactly the same on the print with and without pressure advance.
That said I'm personally almost beyond a shadow of a doubt on a firmware issue.
-
Another observation is that overextrusion does NOT happen when I just print a simple cube. I suspect it may have something to do with travel moves or something.
Anyway, there's got to be an asymmetry in there somewhere...
-
Update to 2.05.1 to get on recent code.
Post your config.g.
-
Using extruder 2 (counting from 0) to print
And some stuff stored in memory currently:
M566 Maximum jerk rates (mm/min): X: 500.0, Y: 500.0, Z: 60.0, C: 6.0, E: 800.0:800.0:200.0:800.0, jerk policy: 0 M566 M572 D2 Extruder pressure advance: 1.960, 0.000, 1.000, 0.700 M203 Max speeds (mm/sec): X: 583.3, Y: 583.3, Z: 20.0, C: 83.3, E: 33.3:33.3:33.3:33.3, min. speed 0.50 M201 Accelerations (mm/sec^2): X: 6000.0, Y: 6000.0, Z: 400.0, C: 400.0, E: 6000.0:6000.0:1000.0:6000.0 -
Going to try printing two cubes, to see if it is travel moves that are causing the problem.
Then I'll update to RRF 2.05 at least, if not RRF3.
-
Are you seeing any underruns on the prints that are overextruded? Perhaps, if there are underruns, the moves that are not being ammended would have had PA applied to them, to balance other moves, but because of the underrun the PA was not applied in a balance manner.
I'm not sure if this is actually possible, it's wild speculation, but it's a scenario I've wondered about before.
-
@bot
Will check now.Printing 2 cubes did not cause overextrusion...
-
I'm really surprised there's no counter anywhere for total steps taken on each drive. Maybe I should try to add that (would have to work out how to build).
Alternatively I can hook up a logic analyzer and have it count the steps...
-
Logic analyzer capturing, wrote a python script to analyze the results, running the file with pressure advance now, then I'll run without.
-
Why 8x microstepping on the extruders?
M350 E8:8:8:8 C8 I0
What are the actual extruders?
M566 X500 Y500 Z60 C2 E800:800:1200:1200 ; Set maximum instantaneous speed changes (mm/min) M203 X35000 Y35000 Z1200 C5000 E2000:2000:2000:2000 ; Set maximum speeds (mm/min)Your max speed is a bit low and might be limiting your retraction speeds.
-
@Phaedrux said in RRF 2.03 pressure advance causes 20% overextrusion:
Why 8x microstepping on the extruders?
M350 E8:8:8:8 C8 I0
What are the actual extruders?
M566 X500 Y500 Z60 C2 E800:800:1200:1200 ; Set maximum instantaneous speed changes (mm/min) M203 X35000 Y35000 Z1200 C5000 E2000:2000:2000:2000 ; Set maximum speeds (mm/min)Your max speed is a bit low and might be limiting your retraction speeds.
8x microstepping on extruders would be the default setting for E3D's toolchanger, I haven't touched that.
The extruders are E3D titans.
I reduced maximum speeds because I was starting to get skipped steps when commanding high speeds through the interface.
-
Does Duet configure the trinamics in rising edge or falling edge mode?
With PA at 1.0, as counted by a python script analyzing the output of my Saleae (assuming rising edge mode):
fwd_count 6334445
rev_count 5157566
net_count 1176879
mm 2979.440506Slicer says 2.48m filament use. Duet web interface confirms, says the file has 2481.7 mm filament use.
Next up, PA at 0.0. If this comes out correct, it will be incontrovertible proof that there is a firmware issue with PA causing overextrusion.
-
The python script: step_counter.py.txt
The data with PA: https://drive.google.com/file/d/16LW2Xb2MWsUTvyCdSjDqBvFwDXq1xOuR/view?usp=sharing -
Ah, the TMC 2660 doesn't have a falling edge mode, only rising edge and both edges. I misread the datasheet.
-
With no pressure advance: https://drive.google.com/file/d/1oFvrJnxZc6fvLlGZqTdCqO7GB4Zfzdy_/view?usp=sharing
Python script output:
fwd_count 1942964
rev_count 961423
net_count 981541
mm 2484.9139242.48m, dead on what the slicer expected.
Proof positive that PA causes overextrusion and that this is a firmware bug, NOT a mechanical or configuration issue.
