Bug? In Retraction and Movement Junction
-
@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)
-
@davekeogh Those are some clean prints, but I do clearly see my issue on them.
-
@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? -
@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?
-
@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.
-
@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.
-
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 ? -
@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. -
@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...
-
@hackinistrator it only happens on the stop point. Not the start point or "de-retraction"
Coasting and wiping does not resolve the issue either. -
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 . -
@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.
-
@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
-
@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.
-
then please upload your s3d factory file , without firmware retraction .
-
@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. -
@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.
-
@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:
-
@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.
-
@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.