RRF 2.03 pressure advance causes 20% overextrusion
-
@Veti said in RRF 2.03 pressure advance causes 20% overextrusion:
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.
-
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.
-
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.
-
@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 -
@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.
