Bug? In Retraction and Movement Junction

jatmn

@hackinistrator it only happens on the stop point. Not the start point or "de-retraction"
Coasting and wiping does not resolve the issue either.

hackinistrator

if it happens at the end of perimeter , why are you retracting there? retraction before infill start ? for what .
show me your s3d gcode please .

jatmn

@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

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

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

the gcode file you added (from ideamaker) has firmware retraction enabled . but you didnt set any parameters in firmware retraction with m207 command .
so its using your default values (whatever they are)
so your slicer retraction setting actually DO NOTHING .
you need to decide if you want to use firmware or slicer retraction setting , them calibrate settings per need .

G1 X116.010 Y94.820 E0.0458
G10
G0 F9000 X115.667 Y94.528
;TYPE:WALL-OUTER
;WIDTH:0.450
G11
G1 F720 X116.320 Y93.820 E0.0473
G1 X117.028 Y93.167 E0.0473

see G10 and G11 commands in your gcode are firmware retract and de-retract. slicer settings irrelevant

jatmn

@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

then please upload your s3d factory file , without firmware retraction .

jatmn

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

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