Bug? In Retraction and Movement Junction

dc42

@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.

@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.

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.

If your GCode issues a retraction command (either G1 E-xxx, or G10) followed by coast or wipe, then this is exactly what I expect. But I would not expect a slicer to generate such code. If it did, then pressure advance should help to reduce the blob

To help us investigate this, please can you do the following:

Upgrade to firmware 3.2 and confirm whether the issue still exists.
Ensure that your X and Y jerk settings and extruder speed and acceleration settings are the same in RRF as you use on the Marlin-based printer.
Set the extruder jerk quite high, at least 600mm/min and maybe as high as 2000mm/min. Some (older?) versions of Marlin don't control extruder jerk properly during printing moves.
Set jerk policy 1 in the M566 command. This makes RRF behave more like Marlin in respect of jerk. Note, a combination of jerk policy 1 and very high extruder jerk might cause skipped extruder steps during retract and reprime move, so watch out for this.
As the cylinder is printing, change pressure advance every few layers so that we can see the effect. I suggest you start from zero, and increase it in increments of half your usual pressure advance setting or less. You could also try switching jerk policy between 0 and 1 the print, to see if it makes a visible difference.

Note. the effect of jerk policy 1 changed in RRF 3.2, so it is worth trying the effect of jerk policy 0 or 1 again if your previous test used a version of RRF prior to 3.2.

oozeBot

@dc42 We have been fighting the same issue. I haven't had a chance to update to 3.2 final, but have been actively testing all the 3.2 betas. We are drawing the same conclusions and even went as far as testing the same gCode on our old Marlin based machines, which is not exhibiting the same artifacts.

As of now, we've found nothing to fix this - including both jerk policies. However, I will upgrade to 3.2 final today to see if there are any changes.

Here is a screenshot of the render in Simplify3D.

And the printed model:

dc42

@oozebot, where that corner seam shows a bulge in your photo, I presume there was a layer change. Do you know in which direction the perimeters in those layers were printed?

If the bulge happens at the end of printing a perimeter, just before a retraction and travel move, then you should try increasing pressure advance.

jatmn

@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

Move while extruding
Stop, Dwell
Retract
Dwell
Move to new position
de-retraction

Marlin

Move while extruding, Quick junction to retraction
Dwell if retraction is long (more than about 1.5mm, or has slow retraction speed/jerk)
Quick junction to new position and de-retraction.

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.

OwenD

I decided to try printing a few of these cylinders.
I'm running an E3D V6 through about a 400mm bowden tube, so although I get reasonable prints, it's not an exceptional printer.
I used Prusa Slicer and have seams "aligned" which in this test I believe is worst case scenario.
I've used ABS at my normal settings.

I definitely get a small seam at the start/finish.

Looking at the G Code that Prusa Slicer gives me, there is no retraction or un-retraction in this area. I have it set to not retract when travel moves remain within the perimeter.
So retraction can't be the cause of the seam (in my case), nor any "pause" you may notice. I couldn't see any such pause when the tool moved from one perimeter to the next, but if the were a retract I would expect one.
Some of the posts above suggest your slicer IS doing retractions and/or unretractions at the junction.

I set Prusa slicer to alter the pressure advance every layer from zero up to the current Z height divided by a factor.. Over four prints that factor was 1000, 500, 100, 10
So in effect, I tried various levels of pressure advance from zero to levels which gave me terrible prints, but nothing changed the seam.

I therefore feel pressure advance has nothing to do with it.
My normal PA setting is 0.09
Given the very small line segments we're talking about here I don't know how much pressure advance could actually be applied/useful in this object.

I believe the reason is that the tool orifice is round and the tool path generated by the slicer never fully over laps the centers.
Therefore even with perfect extrusion, there will always be a slight divot.
This is what prusa slicer shows

this is what a Gcode analyzer shows

This is what it looks like if I draw the points in CAD

The green lines are travel moves (albeit short)
The green circles represent the point where extrusion for that perimeter will start.
The white lines are the travel path.
So given that during the travel move the nozzle pressure is (presumably) dropping, I think that the start of the next travel move will have a slightly narrower extrusion width than when at full pressure, so the start of the line would be more like a teardrop.
It would also bend inwards at the change of direction slightly.
Couple that with the fact that the toolpath stops short of the same point at the end and you have to intersecting circular points that don't meet up at a point where the extrusion is the same width.
By stopping the print early, you can see the variation in extrusion width in the area, although the nozzle travel move effectively "wipes" the junction so you can't see lines at that point.

It's actually clearer on the first layer, but I use different layer height and extrusion factors there so it may not be entirely representative.

If the tootlpath did meet up on center I'd expect a bulge, so I fully understand why the slicer uses the path that it does.
It'd take some custom G code generation to test it I guess.

So in conclusion I'm struggling to see how RRF is the cause of this if it's only following the toolpath provided?
Nor do I see how Marlin would do anything different in this scenario, but I can't test that and don't discount your experience.
Unless there's something going on in the background of the firmware in terms of junction deviation at these travel moves I can't offer any answers that would point to a difference that could be attributed to firmware?
Someone with more in depth knowledge of the firmware would have to weigh in on that.

jatmn

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

@jatmn, have you tried using jerk policy 1 with RRF 3.2 yet?

bot

Also, increase your X/Y jerk above 3 mm/s. Make it 10 mm/s for a test.

Phaedrux

@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 retraction

I thought the results looked better, but ¯\_(ツ)_/¯

I think that was only with 3.1.1 though, and not 3.2.

jatmn

@dc42 said in Bug? In Retraction and Movement Junction:

@jatmn, have you tried using jerk policy 1 with RRF 3.2 yet?

yes

jatmn

@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 retraction

I 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

Phaedrux

Can you show a comparison photo of the results of those settings and the print from the PrusaMini?

jatmn

@Phaedrux

That was posted above already, but here it is.

Grey was RRF
Red was Prusa Mini
alt text

Video with more clear detail of the issue

hackinistrator

currently my only running machine is a modified prusa mk2 . still using marlin .
if i'm using retraction , its easy to tune the seam to be a bulge or a void . invisible seam is impossible .
i dont see how its not tunable with rrf , same way it is with marlin .
i will try to connect it to duet board and compare.

T3P3Tony

@jatmn having finished another bit of detailed investigation i am now looking at this. The video and pictures are helpful, along with the detailed description.

Is it a fair to say in summary the key difference in that on a Z seam there is a "bulge then gap" effect, where as the mini/marlin printed part is something of a gap with no bulge?

Will look to recreate this using your posted gcode and settings, although i don't have an identical machine - should be able to get close.

jatmn

@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.

T3P3Tony

@jatmn thanks, I am going to be testing without PA initially to help rule that out.

Luke'sLaboratory

For what it's worth - I also have been experiencing less-than-optimal seam performance as well, similar series of troubleshooting steps, PA tuning, jerk/speed/accel adjustments, slicer tweaks, slicer changes, hardware updates, and the like on 3.2 (and earlier betas) I do not use aligned seam, so the bulges are everywhere and are just tiny zits.

I haven't changed my jerk policy yet and will change that to see if it resolves, but I eagerly anticipate the results from the work you all are doing.

T3P3Tony

@jatmn Just as an update I did a number of cylinder prints here on a delta and e3d toolchanger. I can see a similar seam presentation as you showed with some variation between slicers (Cura, ideamaker, Prusa slicer) but not enough to be conclusive. I also tried the latest beta firmware and spent a not entirely fruitful time with pressure advance settings.. I ended up ordering a well regarded small printer that does not run RRF to use as a comparison machine. It will be interesting to set it up with both control options and run the same gcode through to see what changes.

Argo

I'm having quite the similar printer, Bondtech extruder, Bear frame and so on with Duet 3 Mini 5+ and RRF 3.3b2.

So I also did a test cylinder and like to share my results. Printed in PLA with PA set to 0.056.