Bug? In Retraction and Movement Junction

davekeogh

@jatmn cheers. I do try. I'll try the same print on my skr running RRF tomorrow.

Do you have shots from prints running Marlin?

jatmn

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

@jatmn Just had a quick flick through this thread so I might have missed something. But in a recent post, you mentioned a 1mm nozzle. Is that what you are using? If so, that is the most likely cause of your issues. It most certainly explains why you don't need to use pressure advance because it is highly unlikely that there would be any build up of pressure that needs to be compansated for.
Have you tried a more "normal" size nozzle?
Another thing, have you ruled out all mechanical defects? Are all the gears and hobbed bolts secure on their shafts inside the extruder?

Uhm.. please read just the first post, forget all the rest of the thread it will give a more clear answer of whats going on.. unfortunately non of your comments applied to anything going on at all.

jatmn

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

@jatmn cheers. I do try. I'll try the same print on my skr running RRF tomorrow.

Do you have shots from prints running Marlin?

my post just before my comment to you has a link to a video showing a print off my prusa mini vs my first print shown in tests here off the RRF test machine.

hackinistrator

honesty , i read the thread and i'm yet to understand what the actual issue is ?
whats wrong with those seams ?
your mini print and the other look almost identical to me .
am i missing something ?

jatmn

@hackinistrator if you watch the last I think 5 seconds of the video I posted this appears to have the best shot at the very end of the video showing the issue.

In the video if you turn the sound up you can hear my finger nail catch on the red print (prusa mini) this is my nail catching inside the seam which is otherwise even on both sides. The grey print which is the one in question you can clearly see my nail get stuck on the seam but only going over it from one direction. This is the step in the surface between stop and start point, not a gap between the 2 that my nail catches. This is why it's only catching from one direction.

The stop point where retraction is triggered is over extruded. This results in a "bump" in the surface of the shell of the model which generally causes significant issues with parts I print as it causes issues for round objects and thru holes.
It also results in a square having one corner being budged out while the other 3 are clean.

hackinistrator

@jatmn ok , so you are trying to get rid of the bulge at the seam , right ?
does this happens when filament de-retracts ?
if so , use negative extra restart distance. if you have simplyfy 3d , try setting extra restart distance to -0.1 , if not enough set -0.3 , -0.6 etc ...

on some filaments , i sometimes have this bulge at the start of the perimeter due to excessive pressure , even without retractions . in this case , in s3d again , go to layer change script and set G1 E-0.2 . if not good enough set G1 E-0.5 etc...

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?