RRF 2.03 pressure advance causes 20% overextrusion
-
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.
-
This is a good resource for the resolution setting.
https://youtu.be/Hvw3DrVAeTA -
@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:
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.
Very nice find!
I started a thread recently to brainstorm further PA improvement ideas. Over-extrusion was one of my issues. I am running RRF 3.1.1.
-
Probably going to focus my efforts mostly on scrapping bowden and going to direct...
It is just too painful to deal with.
-
@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:
@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.
Forgot to mention that my observations also indicated that there's not enough CPU to keep up with tiny moves + PA on the Duet 2. This was also why I stopped debugging.
As for using Bowden, yeah, sort of "forget it". BUT, this issue is not limited to Bowden. As far as I could tell there is no way to completely avoid the issue, but resolution (and in turn the CPU usage) makes it worse.
It is possible that some trivial printers out there sort of work, but, the same way as my prints were dismissed as "not real", I'll just pretend those people don't exist either.
-
DC42 has added this to the list to investigate.
-
@Phaedrux said in RRF 2.03 pressure advance causes 20% overextrusion:
DC42 has added this to the list to investigate.
I am waiting for the results from @jschall on RRF 3.1.1.
-
Oh man, this update process is not working...
There just aren't clear instructions anywhere...
So, I've uploaded Duet2and3Firmware-3.0.zip, and clicked yes when it asked if I want to update. It complained about missing iap4e.bin, but it updated the web control to be very pretty. I searched around for any clear documentation, didn't find any, and assumed that I needed to rename Duet2CombinedIAP.bin to iap4e.bin and upload it. I did that.
Now I still have a very pretty web control, but it just won't update the firmware to 3.0. No error messages whatsoever. What is the actual process to do this?
-
Duet Web Control 2.0.4
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later + DueX5
WiFi firmware version 1.23 -
Got it. Had to find iap4e.bin from a really old firmware release. Had to find out about this by googling a forum post. I'm sorry, but what the heck? Why not document this in the release notes, or just put the file in the release bundle? Jeez, that's really bad.
-
@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:
Got it. Had to find iap4e.bin from a really old firmware release. Had to find out about this by googling a forum post. I'm sorry, but what the heck? Why not document this in the release notes, or just put the file in the release bundle? Jeez, that's really bad.
It is in the release bundle. iap4e.bin is included in the .zip file updates for RRF 2.05.1, 2.05, 2.04, and some earlier releases.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in RRF 2.03 pressure advance causes 20% overextrusion:
It is in the release bundle. iap4e.bin is included in the .zip file updates for RRF 2.05.1, 2.05, 2.04, and some earlier releases.
It is not in Duet2and3Firmware-3.0.zip
-
@Phaedrux said in RRF 2.03 pressure advance causes 20% overextrusion:
Update to 2.05.1 to get on recent code.
Post your config.g.
I did suggest you update to 2.05.1 first.
The issue of missing IAP files does come up and should be better addressed in the documentation. I'll see what I can do about that.
-
Currently running the test on RRF3.1.1. It is with x16 microstepping+interpolation, but I'll do a new control test with no PA as well.
-
Where the heck in the code are the reverse pins written?
Also my logic analyzer keeps failing.
