Bug? In Retraction and Movement Junction
-
Sorry I have not had the chance to test this in builds newer than 3.1.1
But I have tested for the issue across the last year in builds up to 3.1.1, please let me know if it was fixed in 3.2.x or if this is just an inherent issue of the Duet2Wifi drivers.
Tested on various versions of the Duet2wifi Official and cloned as well as derived board designsI have seen a significant issue in what I am guessing the Retraction and Movement Junctions within the firmware. Or something with the drivers used on Duet2 boards?
I have tested this in the following machine style configurations and can reproduce the issue 100% of the time
- Delta (1.75mm) w/0.4mm nozzle
- CoreXY (1.75mm & 2.85mm) with 0.4, 0.6, 0.8mm nozzles / with E3D V6, V6 with volcano, bowden and directdrive, with 1.8 stepper motor)
- Prusa/Mendal i3 style drive systems (Prusa Mk3 Bear, Ender3, as well as custom build) (1.75mm & 2.85mm) with 0.4, 0.5, 0.6, 0.8, 1.0, 1.2mm nozzles / with E3D V6, V6 with volcano, bowden and directdrive, with 1.8 and 0.9 stepper motors)
- Prusa style with IDEX (1.75mm) with 0.4, 0.5, 0.6, 0.8, 1.0mm nozzles / with custom geared extruder and hotend
- Ultimaker style drive system(1.75mm & 2.85mm) with 0.4, 0.8mm nozzles / with E3D V6, V6 with volcano, bowden, with 1.8 stepper motor)
- All noted machines tested with E3D TItan extruder (Genuine), Bondtech QR's, Bondtech BMG (Genuine) where interchangeability was possible due to filament sizes. (yes I did various QR direct drives to test this, talk about a massive print head)
Yes, I have been troubleshooting the issue for about a year now and printed over 25KG of filament in 5-20min test prints trying various slicer and firmware settings across all these configurations
- Most commonly used filament type in tests was PLA (dozen or so brands, it didn't matter)
Slicers used and have no impact on the result.
- Cura (various versions)
- PrusaSlicer (various versions)
- SuperSlicer (various versions)
- Ideamaker (various versions)
- Simplify3D 4.1.2
Image - Random test of the issue that I quickly found on my phone for a "visual" example. This one appears to show more of a worse case example of the issue.
Issue: Excessively large-stop points when using retraction.
No amount of retraction distance/speed, coasting, wiping, flowrate adjustment, nozzle size change, or filament size.. appears to affect the overall end result with the exception of causing the issue to get worse in some cases.
Sometimes the result is "less" noticeable on the print, but the issue is still there.- Note: This issue is strangely still seen even with flowrates below 80% when the layers won't even properly extrude the "Stop point" is still seen clearly.
Image - Both with 0.8 or 1.0mm nozzle (sorry I forget at this point). Left showing issue with a VERY long wipe, right showing the issue at 80% flow rate with no wipe.
Hypothesis: There is a "lag" of sorts between the retraction command being processed and the next move command following it.
The printhead will dwell for just a moment (sometimes an unmeasurable amount of time but can be seen in the print result) during a retraction before moving to the next position.
This is most easily seen when introducing a long coast or wipe (like 2mm+) after a retraction in slicer settings. The result is a "pause" and small over extrusion at the retraction point as well as at the end of the coast/wipe as well, essentially causing what I would describe as 2 stop points on the same ending segment.Before people tell me "you need to adjust your acceleration/jerk etc values" I have already play with values from 10-20000 in 100's of variations that I could think of that would (and wouldn't) make sense following the example configs across the internet from anything like an i3, delta, and even the railcore configs. As well as spent countless hours digging thru the forum, Facebook and Reddit using whatever "recommended" values I found for any configuration of machines on all my machine tests.
From a lot of my research, it appears whenever someone runs into this issue and posts about it the issue is brushed aside or just abandoned and the person reverts to marlin (which is about where I am at this point)
"You need to tune Pressure advance to fix this" - No, Pressure advance appears to have little to no impact on the issue.
This mostly addresses issues with start points NOT stop points, this issue is related to STOP points.Known Fixs:
-
Hide your seam in corners - really? You do know not all models have corners right?
-
There is an "apparent" known fixed floating around the internet that you MUST use very specific models of stepper motors for your extruder to get around this issue.
I have tried this as well, while it mostly fixes the issue it does not completely fix the issue.
Likewise, this is an incredibly silly acceptable fix as I can pull literally any odd model motor out of my junk drawer and use it as an extruder motor on marlin powered machines and get significantly better results even before any real tuning of firmware or slicer settings. -
Use marlin and abandon reprap firmware, this appears to be the most common when people notice this issue
Facts about the issue:
There is a noticeable pause when preforming a retraction rather than a smooth transition to it even with a 0.1mm retraction at 70mm/s
In some circumstances, there is a pause as well after the retraction.
Using a nozzle size larger than 0.4mm makes this issue more visually noticeable in the print itself however has no noticed impact on the "pause" duration causing it.Conclusion:
I am not here to harp on the firmware or the controller boards. I really love the DWC interface and I really love how I can make configuration adjustments on the fly without recompiling firmware EVERY time.But the issue I'm encountering makes the firmware/controller pairing completely useless for me.
-
This post is deleted! -
So to recap your long post, the issue you are facing is a small pause in head movement when doing retraction?
-
@whosrdaddy Yes, sorry it was so long, figured I would dump as much information as possible instead of responding to countless questions or recommendations that I have seen when this issue arises.
There is a "pause" of some sort I believe to be causing this issue.
-
I have had this issue in the past.
When you use mesh bed leveling (G29) or Z-hop make sure your Z-axis acceleration values are high enough. -
@whosrdaddy I have played with z axis values as well.
Unfortunately, zhop on or off has basically zero impact on this issue.
I have done this with and without mesh leveling as well.
I can reproduce the issue on all stop points on the "layer" as well.. so if there is multiple models printed at once on the layer all of them would have the issue eliminating any impact the z axis might have on this test.
-
I see. If I were you, I would try to narrow down the playing field here, you are going to broad.
Please post your current setup, config.g and a sample gcode file that exposes the issue so other people can try to reproduce the issue. I have 3 duet 2 wifi based printers and like I said, I had a similar issue in the past (which ended up being to conservative Z axis acceleration values in combination with G29) but none of them have the issue you are experiencing. As it stands now, it is hard to tell what your issue could be. Making a small video could also be helpful. -
@whosrdaddy I honestly thought I have narrowed the issue quite well considering I was able to reproduce the issue even on a delta machine.
Let me find one of my more universal configurations and gcode that would meet your request.
-
just focus on one printer and let's use that one to debug the issue (I only have cartesians
). -
@jatmn thanks for posting the comprehensive run down of the issue. As has already been mentioned it would be helpful to narrow down the variables a bit. can you select the machine that's easiest to experiment on and then let us have the config.g and a simple test gcode that reproduces the problem.
One of the first things will be to turn off all coasting and slicer feedforward type things and then tune pressure advance.
Cheers
Tony
-
@T3P3Tony As noted in my tests, pressure advance has minimal to no effect on the noted issue.
However, I will generate the requested information and post my results.
I am going to run a current test print with the gcode as well to go with the results for consistency. -
Have you tried jerk policy 1 yet? (M566 P1)
The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.
Can you share an example config file and retraction settings?
-
@Phaedrux Not seen this one, will have to look in to it. Thank you.
-
The printer in this test is a customized version of a Prusa Bear MK3
- Independent Z axis motors
- Bondtech Direct Drive
- Genuine V6
- Ultistik Flexplate
- 10mm Rods on Y axis
- Pinda Probe (however I have not set up temp compensation yet )
- Duet2Wifi
Duet Web Control 3.1.1
RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23
*Note: This is literally my best printing RRF machine, however prints on it are useless for final product/use so I have to print anything I plan to actually use on my Prusa mini
Requested files:
config.g
test gcodeImage: Test print of the gcode.
Filament: Fillamentum Vertigo Grey (unfortunately my slicing settings are slightly off for this brand of PLA but shows a more clear example of the issue)
This issue is less apparent but still there with the generic pla I was printing with yesterday with the same settings.
The test gcode prints 2 of these side by side at once, with no zhop, no wipe/coast and with pressure advance.
Image: Machine in question
-
@jatmn Here's your problem... Your jerk settings are very low!
M205 X3 Y3 Z2 E3 ;set max instantaneous speed change in mm/secRemember that RRF uses mm/min not mm/s.You'll be wanting values in the range of 500mm/min (particularly for your extruder!). FYI, I run my BMG with an underpowered pancake stepper at 750mm/min jerk with no problems.With it so low atm, your printer is having to wait at the end of the line for the extruder to actually carry out the retract move. If you put on somepressure advance too (I don't see it in your config though), you'll also get the same problem where the extruder settings limit your carriage speeds on printing (coordinated) moves
Edit: Just realised your using M205 which is in mm/s (I usually use M566 which is in mm/min...). It's still a bit low though
-
Those values are in mm/sec not mm/min im not using the default M566 version your referring to.
https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M205_Set_max_instantaneous_speed_change_in_mm_sec -
Regardless of mm/sec or mm/min they are still very low.
For example my typical jerk values are x900 y900 z60 e3000 in mm/min on a basic corexy
-
Made some tests by feedback noted so far.
Top down
#1 Gcode Provided with no changes
#2 Gcode Provided with firmware change M566 P1
#3 Gcode Provided with firmware changes M566 P1 & I changed M205 ... E50No notable difference in the issue.
-
Maybe post your config-override.g as well for completeness? Since you do run an M501 at the end...
-
Also do you get the same results with pressure advance turned off? I see M572 D0 S0.05 in the cylinder gcode.
Can you send me the stl also? I want to see how your gcode, vs my gcode varies.
