@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.
@jatmn said in Bug? In Retraction and Movement Junction:
However, it has little to no impact on the stop points.
I'm not sure why you think that. It would have an impact on both. Think about what it's doing. It's shifting the amount of extrusion forward or back in time. It's reducing the amount of extrusion before a stop.
I know this is how it's supposed to work in theory. (or by design)
However literally every one of my tests proves otherwise, or at least the results of the print are proven otherwise.
This is significantly more clearly shown when you run a 1.75mm or 2.85mm Filament on a 1mm nozzle (Which I have noted to have done already)
With an excessively high Pressure Advance value you can cause a significantly delayed start point resulting in a measurable gap between the stop and start points. (on one test I had a 1.5mm gap between the points!)
However, with that, you can still have this over extrusion effect on the stop point even with those settings.
Sorry, I don't have a picture of that, it was a test I had done about 2-3months ago.
As for the result I am looking for, something like this.
Top is Original #1 test from this thread
Bottom is a random print I just did on my Prusa mini
Here is a video that details the 2 prints above
Grey is off mentioned test machine, Red is Prusa mini
Video Link
(also screw Akismet.com spam checker flagging my posts as spam when I edit them)
@dc42 said in Bug? In Retraction and Movement Junction:
@jatmn, thanks for your clear description of the issue.
@jatmn said in Bug? In Retraction and Movement Junction:
please let me know if it was fixed in 3.2.x ...
I fixed a bug that caused pauses between moves during the 3.2 firmware development cycle. I think that this bug was only introduced earlier in the 3.2 cycle, but I am not completely certain. So it's worth trying firmware 3.2 if you haven't already.
I will look in to this in the 3.2 update today. However it has for sure existed in 3.1.x as my machines all run 3.1.1 as well as at least 1-2 versions prior to that and had the stated issues.
@jatmn said in Bug? In Retraction and Movement Junction:
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.
The print head is supposed to dwell at the current position during any pure retraction move, until the retraction is complete. This is how slicers generate the code, and also how firmware retraction works. But as soon as the extruder motor has completed the retract movement, then of course the next move should start immediately. However, if pressure advance is in use, then depending on the pressure advance setting and deceleration, a retraction may have started even before the retraction command.
I am not a programmer so I don't actually know how this is being done in marlin from a programming standpoint however from a visual standpoint let me describe how this appears. The personality between the two firmware are very much different in this action when you start watching them closely side by side.
Note: This is using slicer retraction not firmware retraction.
RRF
Marlin
Even while Dwelling Marlin still appears to complete the actions faster, or produce less issues at least.
Anyhow I will give 3.2 a go now as well and report my findings.
@T3P3Tony That is correct a "bulge than gap" and in my tests pressure advance has more effect on the gap and start point and less of an effect on the stop (bulge). Values high enough to affect the bulge result usually in a significant gap (actually a hole all the way thru) and under extruded start point.
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 designs
I 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
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
Slicers used and have no impact on the result.
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.
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.
@T3P3Tony That is correct a "bulge than gap" and in my tests pressure advance has more effect on the gap and start point and less of an effect on the stop (bulge). Values high enough to affect the bulge result usually in a significant gap (actually a hole all the way thru) and under extruded start point.
That was posted above already, but here it is.
Grey was RRF
Red was Prusa Mini
@Phaedrux said in Bug? In Retraction and Movement Junction:
@bot Well he did try these settings: https://forum.duet3d.com/post/202855
M566 X900 Y900 Z120 E3000 ; set maximum instantaneous speed changes (mm/min) M566 P1 ; Set jerk policy to mimic Marlin and uses jerk between all moves. M203 X12000 Y12000 Z600 E6000 ; set maximum speeds (mm/min) M201 X4000 Y4000 Z300 E3000 ; set accelerations (mm/s^2) M204 P800 T2500 ; set print and travel accel M572 D0 S0.035 ; PRESSURE ADVANCE M207 S1 R0.0 F3000 T1500 Z0.0 ; firmware retractionI thought the results looked better, but
¯\_(ツ)_/¯I think that was only with 3.1.1 though, and not 3.2.
these settings were tested again on 3.2 results was basically same as in 3.1.1
@dc42 said in Bug? In Retraction and Movement Junction:
@jatmn, have you tried using jerk policy 1 with RRF 3.2 yet?
yes
Sorry this has been an.. lets go with an emotional day so my testing started late today.
Im still running a number of tests with the new 3.2 firmware as well as attempting to try and tune the motion system better..
As I mentioned in my very first post, slicer does not matter.
I am well aware prusaslicer's default settings do no use retraction usually in this junction.
However to rule out that therefore its not related to the issue is a little short-sighted and rather just raises more concern.
Your analysis as stated would mean that prusa's own machines print with results like this, my A/B prints show a print off my Prusa Mini which was sliced with prusaslicer and does not have this issue as shown. (powered by marlin)
However in saying this. This actually further proves at least to me there is indeed some sort of issue in the junction planning on RRF. You don't see the pause because your not retracting but still see the issue I see. This issue wouldn't matter to me if it was a issue found in marlin, having used marlin for several years prior to RRF I can for sure say this issue does not exist in marlin which is why it sticks out as a issue to me in RRF.
While I am currently still running tests for firmware 3.2 currently I can say the results are.. sorta? better? ish? may just not as predominate for sure still producing more or less same issue. Again with minimal influence by Pressure Advance settings as im currently running PA towers right now to see how it changes. I can say my same settings and gcode as posted before in this thread produces basically the same results.
Using low values encourages more of a bulge on the stop point and when the value is increased enough to resolve that, the start point is under extruded causing the same "step" effect in the surface. Im not referring to a seam, im referring to a miss-matched surface.
(
General like the image above, while this is normal with a PA value that is too high causing under extrusion. My issue is similar except the start point is the correct width but the stop section is larger than the nozzle diameter.
I am not the only person with this issue i know many people with this issue that have shelved their RRF powered machines or just completely pulled the board out and loaded a Marlin powered board in the machine.
As I have mentioned in my first post, every time this issue comes up everyone either writes off the issue as resolved when its not, or just abandons the thread. Usually resulting in the user being frustrated and discarding the duet product for something else.
@dc42 said in Bug? In Retraction and Movement Junction:
@jatmn, thanks for your clear description of the issue.
@jatmn said in Bug? In Retraction and Movement Junction:
please let me know if it was fixed in 3.2.x ...
I fixed a bug that caused pauses between moves during the 3.2 firmware development cycle. I think that this bug was only introduced earlier in the 3.2 cycle, but I am not completely certain. So it's worth trying firmware 3.2 if you haven't already.
I will look in to this in the 3.2 update today. However it has for sure existed in 3.1.x as my machines all run 3.1.1 as well as at least 1-2 versions prior to that and had the stated issues.
@jatmn said in Bug? In Retraction and Movement Junction:
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.
The print head is supposed to dwell at the current position during any pure retraction move, until the retraction is complete. This is how slicers generate the code, and also how firmware retraction works. But as soon as the extruder motor has completed the retract movement, then of course the next move should start immediately. However, if pressure advance is in use, then depending on the pressure advance setting and deceleration, a retraction may have started even before the retraction command.
I am not a programmer so I don't actually know how this is being done in marlin from a programming standpoint however from a visual standpoint let me describe how this appears. The personality between the two firmware are very much different in this action when you start watching them closely side by side.
Note: This is using slicer retraction not firmware retraction.
RRF
Marlin
Even while Dwelling Marlin still appears to complete the actions faster, or produce less issues at least.
Anyhow I will give 3.2 a go now as well and report my findings.
@hackinistrator
1, gcode you want is in this thread already
2, don't assume everyone uses S3D just because you do
3, it's 3am here I'm going to bed and not wasting more time on this back and forth with you.
@hackinistrator Uhm please refer to the start of the thread. You appear to not be understanding the root issue or the tests already preformed in this discussion. As your disputing findings unrelated to your assumptions on a test that was already discussed and reviewed with the person that requested it.
@hackinistrator I have posted gcode in this thread of 2 different examples.
And why would you not retract leaving a perimeter? Just because you leave a perimeter it does not mean the layer has completed. Im sorry I don't quite follow your logic on this one.
@hackinistrator it only happens on the stop point. Not the start point or "de-retraction"
Coasting and wiping does not resolve the issue either.