Bug? In Retraction and Movement Junction
-
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.
-
config-override.g as requested
; config-override.g file generated in response to M500 at 2020-06-08 22:33 ; This is a system-generated file - do not edit ; Heater model parameters M307 H0 A114.3 C401.1 D2.6 S1.00 V23.8 B0 M307 H1 A571.4 C175.6 D5.1 S0.25 V24.1 B0 ; Workplace coordinates G10 L2 P1 X0.00 Y0.00 Z0.00 G10 L2 P2 X0.00 Y0.00 Z0.00 G10 L2 P3 X0.00 Y0.00 Z0.00 G10 L2 P4 X0.00 Y0.00 Z0.00 G10 L2 P5 X0.00 Y0.00 Z0.00 G10 L2 P6 X0.00 Y0.00 Z0.00 G10 L2 P7 X0.00 Y0.00 Z0.00 G10 L2 P8 X0.00 Y0.00 Z0.00 G10 L2 P9 X0.00 Y0.00 Z0.00Pressure advance turned off as requested
same first 3 as before
#4 Gcode as Provided with firmware changes M566 P1 & M205 ... E50 change as well as setting pressure advance to 0.0
Made the stop point worse, as well as started to cause issues for the start point.
Requested STL model
STL Model
However this request actually makes zero sense, it does not matter what my slicer is generating, I already clearly stated I can 100% reproduce the issue in nearly any slicer.
Also as mentioned, I do not see this issue with Marlin-powered machines with similar configurations or hardware.
