Retract with Slic3r 0.9.10b

Hello,

mostly retraction works fine, but often retraction is too slowly. The reason is that retraction goes simultaneously with moving to the next area. As result there are strings between the areas.

Which configuration parameter must be changed ?

Nobima

You could try increasing your travel speed (in Slic3r). Maybe 170.
You may be extruding too much filament too.

---

_______________________________________
Waitaki 3D Printer

Your proposal can improve the result, but I think it is an software failure. What otherwise should be the reason for retraction simultaneously with moving ?

Not sure what you mean but....the extruder retracts when moving to prevent ooze of the filament which would deposit on the edge of the next Island.. You can speed up the retraction and the amount in Slicr3.

---

_______________________________________
Waitaki 3D Printer

Retraction while moving speeds things up. Why retract and then move when the operations can be done in parallel?

Nobima may have a point here. I have noticed something similar. Example is taken from a SLIC3R output.

This line would cause retraction during travel to new x,y point, and Extruder (E) retraction speed is probably overruled and set to fit that Extruder reach target at the same time as x,y?
G0 X15.535 Y55.780 F1200.000 E18.5 ; travel and retract
F1200.000 E20.0 ; compensate retraction

These lines would do the same but retraction is done first and then travel to
F1200.000 E18.5 ; retract only
G0 X15.535 Y55.780 ; travel only
F1200.000 E20.0 ; compensate retraction

The first line is found widespread in the Gcode from SLIC3R and I do not think any parameters could change that, but hardly a bug.
It probably does give ooze during travel. The second way could be slightly slower performing but nothing to worry about.

Who takes this to SLIC3R developement?

Edited 2 time(s). Last edit at 10/05/2013 07:28AM by justcurious.

Ups......just found out how to edit message above...

Edited 1 time(s). Last edit at 10/05/2013 07:25AM by justcurious.

Thanks justcurious, you described exactly why rapid retraction is disabled if there is a greater distance to next extruder target.

If you really think you have an issue go to the slic3d github repository and enter it as an issue.

I myself find that retraction works quite well.

You don't want retraction to cause the hot end to stop moving or you will cause a crater where it melts the place it's stopped at. I have no issue with the current retraction method, no strings, drips or other.

To jbenardis/tmorris9
Retraction works fine other than the mentioned example when travelling. Take a look into your own GCODE and see the difference
Extruder is normally stopped when retraction is executed and also when retraction is compensated for, it is probably a few ms (1mm at 20mm/s). But this has been programmed different when travelling and causing retraction to take as long as travelling takes to new x,y position which means that retraction now could take seconds for 1mm retraction and causing extruder to ooze all the way during travelling, that is why it would not help to change retraction speed at all. It is very easy to see that you get oozing every time a travel has been made even in small holes.
Of course oozing may have several causes, this detail only make it look worse, because retraction obviously does not work in this case.

Edited 1 time(s). Last edit at 10/06/2013 04:52AM by justcurious.

You're stating that retraction slows down to be coordinated with the entire move just because its on the same gcode statement. That's not proof to me. It all depends on the firmware implementation - whether or not filament movement is coordinated with axis movement.

I haven't studied the code enough to make a statement one way or the other, so I won't make any assumptions either. All I know is that retraction works for me. Since turning it on I have had improved results - and I turned it on over a year ago so I have lots of empirical evidence.

That being said, I was sincere above when I suggested you report this as can issue on github.

Filament movement is made by a fourth axis (or 5th if second extruder). I assume Gcode implementation as a standard referenced does not have different policies dependant on which axis to be moved. Any amount of axis could be involved.
Good that you are satisfied with retraction, Nobima and I suggest a slight improvement according to our experiences and hopefully this would not have any influence on your results, but my opinion is that it could be regarded a bug which have influence on quality performed.
I have reported this as an issue on Github as suggested. whether this means any changes to SLIC3R, i wouldn't have any clue.

Doing a litle investigation I may have found a clue and explanation to why this bug is not always recognized.
My machine is a homebuilt CNC/3dprinter and not actual a reprap construction but fairly close.
In SLIC3R printersettings you can select a G-code flavor output to reach maximum compatibility with your hardware.
I have a default setting of "MACH3/EMC" which normally works for me. Most of you guys probably have a "Reprap" setting here to match HW.
Anyway this seems to do the difference. With Reprap setting this bug disappears but is still present when setting is MACH3/EMC.
I may now have to do some thorough testing to see whether Reprap output can be used with my machine and maybe NOBIMA should do the same :-).
Hope we all learned a bit here.
Justcurious

I also use the Mach3 configuration, so your recognition is reasonable. Can swapping the GCode character for the Extruder from "E" (Reprap) to "A" (Mach3) at the forth axis a acceptable solution ? I am very interested what you will find out !

Nobima

I have been thinking about this whole thing. During extrusion - if the E value is positive for relative or greater than the previous value for absolute - then the E axis has to be accellerated in coordination with the other axes so that the extrusion rate is matched to the speed. However, if the extrusion value is negative (retraction) then the coordination is not really necessary.

I put together a test object that has small cubes on diagonally opposite corners of the print bed. The move between the objects takes a few seconds, but the retraction all seems to happen immediately during the first fraction of a second. During the move itself, the extruder gear does not turn at all.

So to me there are two possible explanations here:
1) the firmware recognizes the negative retraction amount and does not coordinate its acceleration, or
2) more likely, setting the G Code flavor to REPRAP results in 2 separate G Code statements. This latter should be easy to check.

My G Code flavor is set to REPRAP, so perhaps that explains the difference here.

To jbernardis
2) is exactly what happens, but it may be a bit more complicated.
with MACH3 setting, extraction is done inline but with a G0 statement instead of G1 which is a coordinated move. As I understand it G0 should be a non coordinated move which should allow immediate extraction. However I am not sure that my machine is doing that implementation, but may do a coordinated move as with G1.
With RepRap setting, it is always sent as a G1 move but in two separate lines, which could explain the difference.

The G Code reference here indicates that most reprap machines execute the same code for G0 and G1.

So Reprap machines should always have retraction issued in separate lines contrary to extruding commands which needs to be coordinated,
I will have to learn whether RepRap settings in SLIC3R have any bad influence to my machine or maybe I should speed up the building of my next RepRap machine with Marlin control. :-)
Thanks for the information found.

According to Github issuelog (issue #1289), coding of G0 commands with inline retractions are now removed from MACH3 flavor, so this retraction misbehaviour causing slow retractions and ooze, should now have gone with future releases. :-)
This error only relates to users using MACH3 flavor settings with SLIC3R.

Edited 1 time(s). Last edit at 10/15/2013 08:05AM by justcurious.