Issues with pressure advance since RRF 3.4
-
Yup, that does not surprise me. I‘m also getting similar results with RRF 3.3 / 3.4 - IS on / off.
So what would be the next step to find the issue?
-
I can reduce the corners by going very high with the retract and detract. Before I consciously noticed this for the first time, I had PETG 0.2mm with 20mm/s retract. Now if I go to 60 or even 80mm/s the corners get smaller.
Also, the corners get smaller when I slice at <60mm/s.
I've already tried a lot, like reducing values with ACC and Jerk, but all without success.
If I didn't have to run so many cables to my Toolhead, I would swap my Board to rule out that it's the Hardware. Because I have a Board as a replacement on which the Klipper is flashed as a test. -
You mean replace the mainboard or the toolboard?
We already had someone test with and without the toolobard. Results were the same. -
@Argo I've reviewed the posts in this thread and so far I think we have had the following theories....
- It is a new problem introduced with 3.4 (but going back to 3.3 seems to produce the same prints).
- It is a problem caused by using a toolboard (but using the same extruder etc. directly attached to the control board produces the same prints).
- Infill and possibly other perimeter lines causing the bulge, perhaps also issues with extrusion rates. I don't think this one ever got investigated fully.
- Various other examples of bulging corners, but unfortunately no examples showing a better print with the same hardware setup but a different configuration/firmware.
Don't get me wrong obviously some of the prints have bulging corners, but to some extent 3D prints always have and the trend towards faster speeds and accelerations have tended to make this worse. PA and the like can try and improve things, but I'm not sure it can ever fix the problem completely. I also suspect that the use of more outer perimeters (in the past 2 was common, these days 4 seems to be used a lot) may be contributing a little here as a small bulge in each one accumulates, but that is just speculation on my part.
Unfortunately unless someone that is seeing the problem can come up with a setup that demonstrates the issue with one firmware/configuration but does not have it with another when using identical hardware, filament etc. (and that setup can be used to test any changes, debug builds etc.) then I'm not sure how to move things forward. @jay_s_uk has been running various test prints with both RRF and Klipper trying to reproduce things but I don't think he has been able to see any real difference (when using similar speeds/accelerations etc.). I've also tried a bunch of things and have not been able to come up with a test case.
If folks think that this is a problem with RRF PA and that other firmware (Marlin/Klipper) does a better job (again with the same hardware and similar speed acceleration, flow rate etc.). Then perhaps they can post examples of that?
-
@Argo
I have a Duet 3 6hc running on Klipper. But I can't test it because otherwise I would have to lay 13 cables to the print head and unfortunately I don't have the time to do so. -
I've found a work around for the issue.
Super slicer has this fancy feature called "Between extrusion role change G-Code".
So I've added the following code for PLA:
{if extrusion_role=~/ExternalPerimeter/};[extrusion_role] ; ExternalPerimeter M572 D0 S0.080 ; Pressure Advance {elsif extrusion_role=~/Perimeter/};[extrusion_role] ; Perimeter M572 D0 S0.080 ; Pressure Advance {elsif extrusion_role=~/OverhangPerimeter/};[extrusion_role] ; OverhangPerimeter M572 D0 S0.080 ; Pressure Advance {elsif extrusion_role=~/InternalInfill/};[extrusion_role] ; InternalInfill M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/TopSolidInfill/};[extrusion_role] ; TopSolidInfill M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/SolidInfill/};[extrusion_role] ; SolidInfill M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/BridgeInfill/};[extrusion_role] ; BridgeInfill M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/GapFill/};[extrusion_role] ; GapFill M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/Skirt/};[extrusion_role] ; Skirt M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/SupportMaterial/};[extrusion_role] ; SupportMaterial M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/SupportMaterialInterface/};[extrusion_role] ; SupportMaterialInterface M572 D0 S0.05 ; Pressure Advance {elsif extrusion_role=~/ThinWall/};[extrusion_role] ; ThinWall M572 D0 S0.05 ; Pressure Advance {else};[extrusion_role] ; Unknown generic handling M572 D0 S0.05 ; Pressure Advance {endif}Result are strong infill and sharper corners.
The "solution" feels like a hammer though
But at least I can use the printer again for functional parts. -
@Argo That's interesting. So basically you are using a different PA value for perimeters to everything else? Do you have a picture of a part using this?
Hmm just a thought is the speed or acceleration used for perimeters different to the rest of the model?
-
Speeds
Acceleration
For testing purposes I already tried printing everything with one speed and acceleration setting. I really tried almost everything to find out what's wrong
Somewhere in this thread I did also post some examples of prints with too much PA which ended up in incomplete infill lines but nicer corners.Here is the result with the extrusion role gcode:
It's still far from perfect. The bottom left corner is still bulging. I think it's because it takes a short bit of time until the gcode is processed (buffer maybe?). The bottom left corner is always the starting point after the infill is being printed. The other corners are somewhat ok.
For the example I used PA of 0.05 for everything except perimeter which used PA of 0.09. Quite the difference... -
@Argo I was wondering if perhaps there might be some scope for speed or (given how you have things set) acceleration based PA... So basically allowing the firmware to dynamically vary the PA settings based upon some other element of the print process...
In respect of that lower left corner does adding M400 before the PA change for perimeters help?
-
Good idea, I’ll try the M400 command tomorrow.
As for acceleration based PA. Does this maybe relate to the issue?
https://forum.duet3d.com/topic/28533/pressure-advance-and-variable-flow-ratio -
I could only find out with firmware 3.3.0 that, for example, my Z-axis ran softer with the same jerk and ACC and not as hard as with 3.4.x Maybe you should look in the direction of the braking behavior? If I get it in time I will flash my Z axis again to 3.3.0 and then film it again with 3.4.x.
-
Unfortunately M400 does not help.
I also found a another issues that comes with high PA values for external perimeter:
The marked area is where the seam is. This is expected with a PA value of 0.08 - 0.09 but needed for nice sharp corners.
Result with PA 0.05 (everything except perimeter) and PA 0.085 for perimeter with M400 usage. Bottom left corner is still bulging:
At least we see now what effect pressure advance has with different settings at the same printed object.
Maybe a post processing script might improve the quality even further with a logic that analyzes the gcode file for sharp corners so that the high PA value isn’t used for all perimeter segments (to prevent defects at round sections) but only for sharp corners. -
I can confirm that this flaw does exist in 3.4:
-
@Chriss Do you have an example of a setup that does not have this overshoot? So for instance are you saying that you did not have the problem with 3.3 (with all other settings the same)?
-
@gloomyandy Well, what can I say here? It was fine with 3.3 back than. I printed enough test cubes etc.
I print mostly technical parts. This overshooted corners are na no go with them.
-
Here pic from a 90° corner with rrf 3.3:
(Yes PA was not very well tuned, but you get an idea) -
@Chriss So the real test is to switch back to 3.3 change nothing and see if you get the same results, I realise this is a pain to do, but so far we have not been able to identify an example of a change between 3.3 and 3.4...
-
@Chriss Oh and if you do run this test, you may need to disable any input shaping you have added in 3.4, I'm not sure what having a 3.4 input shaping command will do to a 3.3 setup... The goal is to have two prints one with 3.3 one with 3.4 using identical config.g and identical gcode files, one has the problem the other does not. That will hopefully give others things to work with to identify the problem...
-
@gloomyandy if you don't have 3.3 try a higher Z jerk and acc. flash 3.4 and the axis runs much more aggressively. could this also be the case for x and y?
-
@Heartleander81 If you think there has been a change between how Z jerk and acceleration works in 3.3 and 3.4, then I think you should probably create a new thread to discuss that. Are you using CAN boards for your Z axis?
