RRF 2.03 pressure advance causes 20% overextrusion
-
@Veti
Thanks, will correct that, then. -
-
Well, this is interesting thank you for doing this.
-
@bot said in RRF 2.03 pressure advance causes 20% overextrusion:
Well, this is interesting thank you for doing this.
Any suggestions where to go from here?
-
please do upgrade to the latest firmware.
even if there is a bug in 2.03 i doubt that we will see a rrf2 bugfix.
so it would be good if you could retry this in rrf3.
-
Ok, I need to upgrade anyway.
-
I had analyzed this issue multiple times before as well and 2.05.1 had only minor improvements related to PA. Based on my findings something happens on the step generation level, probably CPU running out, causing moves to be done before reverse motion (there is some code in there that basically aborts moves before they are done, you'd need to analyze it yourself as I've wasted more time than I'd like already and I have no means of analyzing stepper control). I eventually gave up using PA on my printer as it ALWAYS overextrudes for me and I've ruled out every mechanical issue, too.
I think that it will get worse, if you upgrade to 3.x, as it probably uses more CPU.
-
@Edgars-Batna said in RRF 2.03 pressure advance causes 20% overextrusion:
I had analyzed this issue multiple times before as well and 2.05.1 had only minor improvements related to PA. Based on my findings something happens on the step generation level, probably CPU running out, causing moves to be done before reverse motion (there is some code in there that basically aborts moves before they are done, you'd need to analyze it yourself as I've wasted more time than I'd like already and I have no means of analyzing stepper control). I eventually gave up using PA on my printer as it ALWAYS overextrudes for me and I've ruled out every mechanical issue, too.
Interesting. How did you come to your conclusions? Did you ever write them up?
-
@Edgars-Batna said in RRF 2.03 pressure advance causes 20% overextrusion:
I think that it will get worse, if you upgrade to 3.x, as it probably uses more CPU.
Think the main changes for RRF3 were around making it more configurable at runtime, currently making the jump myself. Guess there are more advance features available, but not sure if CPU use will be effected. Interested to learn more there.
-
@jschall Yeah, I created various topics, but it wasn't easy separating printer from firmware, as my build wasn't as polished back then. It was mostly treated as a printer hardware issue. Just look at topics created by me and you'll see multiple threads.
This is the latest one: https://forum.duet3d.com/topic/16840/printer-refuses-to-do-a-certain-print
I added detailed logging to the firmware in the meantime and wrote a program which counts how much extrusion the movement planning actually wants to command and it added up. The only thing left were the step interrupts themselves and the barely understandable second part of DriveMovement::PrepareExtruder (PA step computation) in the code. Without means to analyze stepper signals I stopped debugging.
-
Currently trying reducing the detail of the model so that the slicer creates fewer moves. We'll see if it makes any difference.
-
What slicer are you using?
-
@bot
PrusaSlicer. Changing the Resolution setting in Print Settings->Advanced from 0 to 0.1. -
@Edgars-Batna That's why I went to the logic analyzer, because I knew it would just be constantly dismissed as a mechanical issue if I didn't remove everything mechanical from the equation.
-
Interesting. I’ve recently gone the other way, and increased the hard-coded minimum value of resolution (thanks to mr Batna here for telling me about that), as well as made a few other changes to increase the resolution of the output. I’m very interested to hear if going the other way as you are helps alleviate this issue. If so, I’m gonna be very sad hahaha. I want tons of resolution, not to give it back!
-
Had a very similar issue when I was generating exposure points from slice data for metals machines. In my case it was a typo in the way I carried over leftover travel over a sequence of tiny vectors. My code effectively walked around the contour of vectors and dropped points every so many microns, not too disimilar to what our systems need to do - but instead of exposure points it's step requests from the stepper drivers. When the vectors were substantially less than the point distance things went funky.
-
Significant reduction in the overextrusion after reducing resolution, but not gone. Will try reducing it more.
fwd_count 7139947
rev_count 6062246
net_count 1077701
mm 2728.356962 -
You are like an angel, coming down to save me from months more of frustration! I've been working on the "solution" to this problem that I hadn't ever been able to pinpoint.
Can you try also lowering PA by a factor of 10, with various resolution settings, and comparing the results? I want to know how much this effect scales with PA, and if there is a safe amount of PA we can apply to high-resolution gcode.
Thanks again.
-
@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.
-
@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:
Funny, I just quit my software job, was hoping it was forever. Didn't even last a day.
this isnt a job, this is fun.