RRF 2.03 pressure advance causes 20% overextrusion

jschall

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...

Phaedrux

Update to 2.05.1 to get on recent code.

Post your config.g.

jschall

@Phaedrux 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

jschall

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.

bot

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.

jschall

@bot
Will check now.

Printing 2 cubes did not cause overextrusion...

jschall

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...

jschall

Logic analyzer capturing, wrote a python script to analyze the results, running the file with pressure advance now, then I'll run without.

Phaedrux

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.

jschall

@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.

jschall

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.440506

Slicer 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.

jschall

The python script: step_counter.py.txt
The data with PA: https://drive.google.com/file/d/16LW2Xb2MWsUTvyCdSjDqBvFwDXq1xOuR/view?usp=sharing

jschall

Ah, the TMC 2660 doesn't have a falling edge mode, only rising edge and both edges. I misread the datasheet.

jschall

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.913924

2.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.

jschall

@Phaedrux said in RRF 2.03 pressure advance causes 20% overextrusion:

Why 8x microstepping on the extruders?

What is recommended?

Veti

@jschall

x16 with interpolation enabled.

also your thermistor config is wrong.

Your bed is 4138 which is the default and very likely wrong.
Your hotends are 4388
So you might be printing at the wrong temperature.

E3D uses 104-GT2 thermistors which is B4725 C7.060000e-8

jschall

@Veti said in RRF 2.03 pressure advance causes 20% overextrusion:

@jschall

x16 with interpolation enabled.

also your thermistor config is wrong.

Your bed is 4138 which is the default and very likely wrong.
Your hotends are 4388
So you might be printing at the wrong temperature.

E3D uses 104-GT2 thermistors which is B4725 C7.060000e-8

Set to 260C/120C. Seems fine to me.

jschall

@Veti

I've done more research and 4725 is the wrong B value. The right number is 4267. I might update my config to match, I don't fully trust the thermal camera's accuracy and it doesn't make sense that the hotends and bed are different when the bed uses the same thermistor.

But I'd need to do some verification on that change regardless.

jschall

Regarding underruns: I'm running the file again now to determine if there are any, but it is most of the way through and there have been no underruns.

Veti

@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:

I've done more research and 4725 is the wrong B value. The right number is 4267.

No its B4725 and C7.060000e-8 if you Specify B and C you switch to the Steinhart–Hart equation which is more accurate over a wider temperature range.

This is documented here
https://duet3d.dozuki.com/Wiki/Connecting_thermistors_or_PT1000_temperature_sensors