Best posts made by jschall

See also https://forum.duet3d.com/topic/18412/rrf-2-03-pressure-advance-causes-20-overextrusion/21

Steps as counted by logic analyzer connected to step and direction pins:

Without pressure advance:
fwd_count 1942964
rev_count 961423
net_count 981541
mm 2484.913924

Same file with pressure advance set to 1.0:
fwd_count 6334445
rev_count 5157566
net_count 1176879
mm 2979.440506

Logic analyzer output, no pressure advance
Logic analyzer output, pressure advance 1.0
Python script to count steps

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.

For now this is confirmed only on 2.03, will do an upgrade to at least 2.05 and probably 3.1.1 soon.

@bot tried reducing the resolution of the STL to about 0.5mm and it still totally overextrudes, but turning it down in the slicer seemed to work better... weird.

I am out for the weekend now, so no more experiments for a while.

Need to grok the code. Sounds like it needs some low level improvements on top of any improvements to pressure advance, based on what @Edgars-Batna is saying.

Funny, I just quit my software job, was hoping it was forever. Didn't even last a day.

@deckingman So why the hell is bowden so popular? It isn't simpler, it isn't cheaper, it isn't better.

@bot said in bug: pressure advance causes overextrusion:

@jschall It seems like you've lost interest, based on the other thread. What model of logic analyzer were you using? Do you have any tips on how to get quickly up and running measuring step pulses in the way you did?

I used a Saleae.

I will still test 3.1.1...

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.

https://gist.github.com/jschall/98f9459590cfad6bbe413f3b49c266eb

No underruns.

Hi, bought an E3D ToolChanger about a month ago, totally new to RRF and duet.

https://github.com/Duet3D/RepRapFirmware/issues/421

I have my esteps calibrated correctly. I can have my printer extrude a given length of filament and the extruded filament will be just under the expected length and it will weigh what I expect it to weigh.

I reduced my extruder jerk, acceleration and max speed to ensure no missed steps.

Nonlinear extrusion is disabled.

However, when I print this part with pressure advance on (set to 1.0, calibrated using this script), it weighs 20% more than I would expect it to weigh based on the total extrusion in the file. If I have pressure advance set to zero, it weighs just under the expected weight.

I've tried with and without retractions, with the slicer set to generate relative moves, and with the slicer set to generate absolute moves.

At the end of the print, the reported extruder position is almost exactly what it is supposed to be.

So, questions:

• Which variable exactly in the code does the reported extruder position come from?
• Can someone give me an introduction to the codebase? Is there developer documentation somewhere?
• Is "COMPENSATE_SPEED_CHANGES" typically enabled by default? I have whatever firmware came on the board.
• Is "stepsPerMm" logged somewhere?
• Is there a way to count total steps on the extruder drive?

jschall created this issue in Duet3D/RepRapFirmware

closed Part 20% over weight predicted by slicer #421

@dc42 just hoping to bring this to your attention, I'd really like to work out what is going on here.

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

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

@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

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
Will check now.

Printing 2 cubes did not cause overextrusion...

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