Firmware retract - auto retract

[Kenzu]

Hey

I cannot get auto retract to work. I have set #define FWRETRACT in configuration_adv.h Put M209 S1 in my gcode

This is my retract settings

ifdef FWRETRACT

define MIN_RETRACT 0.1 //minimum extruded mm to accept a automatic gcode retraction attempt

define RETRACT_LENGTH 2.5 //default retract length (positive mm)

define RETRACT_FEEDRATE 25_60 //default feedrate for retracting

define RETRACT_ZLIFT 0.1 //default retract Z-lift

define RETRACT_RECOVER_LENGTH 0 //default additional recover length (mm, added to retract length when recovering)

define RETRACT_RECOVER_FEEDRATE 15_60 //default feedrate for recovering from retraction

endif

It does not detect retracts at all.

Thanks

[whosawhatsis]

Can you post the gcode you're using? Just throw it on pastebin or dropbox or something and drop a link here, and I'll see if I can figure out what's going on.

[Kenzu]

I will post i tomorrow. My printer is not at home. Another thing. I dont understand feedrate? is it mm/s or mm/m? 25*60 = 1500mm/m, but on the LCD menu i can max set 999?

[whosawhatsis]

What slicer are you using? Some features like Slic3r's "Wipe before retract" break Marlin's ability to detect reversals by moving the X/Y at the same time as the reverse E move (Slic3r will also give an error if you try to use this with firmware retraction enabled). BTW, telling your firmware to use firmware retraction is really the better way to do it if it's available, which it is in most modern slicers (though Cura's implementation is tricky to use).

[Kenzu]

I use Simplify3D and have removed all retraction related settings in the program. It does not support G10-11 :( Sadly I am sick today so did not get to my printer today to post the gcode. But what about feed rate? How should I set that? Den 23/02/2014 19.06 skrev "whosawhatsis" notifications@github.com:

What slicer are you using? Some features like Slic3r's "Wipe before retract" break Marlin's ability to detect reversals by moving the X/Y at the same time as the reverse E move (Slic3r will also give an error if you try to use this with firmware retraction enabled). BTW, telling your firmware to use firmware retraction is really the better way to do it if it's available, which it is in most modern slicers (though Cura's implementation is tricky to use).

Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/800#issuecomment-35838124 .

[whosawhatsis]

Ah, well that explains it. You need to leave retraction in so that Marlin has something to detect as an attempt to retract, which it then replaces with firmware retraction.

I wasn't aware that there were LCD settings for firmware retraction, but I've found the code and will look into it. For now, I recommend setting them by Mcode, in mm/min.

[Kenzu]

Okay, but what's the point with firmware auto retraction if I have to set it in slicer? Den 23/02/2014 19.14 skrev "whosawhatsis" notifications@github.com:

Ah, well that explains it. You need to leave retraction in so that Marlin has something to detect as an attempt to retract, which it then replaces with firmware retraction.

I wasn't aware that there were LCD settings for firmware retraction, but I've found the code and will look into it. For now, I recommend setting them by Mcode, in mm/min.

Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/800#issuecomment-35838345 .

[whosawhatsis]

The slicer has to tell the firmware when to retract somehow. Autoretract is just detects the slicer's attempts to retract and replaces them with firmware retraction. Advantages include being able to modify retraction settings mid-print, or between reprints without reslicing, and it also handles some things better that slicer-based retraction (for instance, setting different retraction and recover speeds, which I've found makes a huge difference).

[Kenzu]

Okay ;) but would it be possible to detect a travel move right after a move with e feed? Den 23/02/2014 19.22 skrev "whosawhatsis" notifications@github.com:

The slicer has to tell the firmware when to retract somehow. Autoretract is just detects the slicer's attempts to retract and replaces them with firmware retraction. Advantages include being able to modify retraction settings mid-print, or between reprints without reslicing, and it also handles some things better that slicer-based retraction (for instance, setting different retraction and recover speeds, which I've found makes a huge difference).

Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/800#issuecomment-35838527 .

[whosawhatsis]

It would probably be possible, but there might be times when you don't want to do that. I'll give it some thought and see if I can see any issues. The obvious issue is that it would cause problems if it was mixed with the existing behavior of firmware retraction, but maybe I can implement a second mode for autoretract (M209 S2) that would behave this way.

[whosawhatsis]

Generally, you want the slicer (which has a lot more information about your print than the firmware) to decide when to retract and when not to. Slicers have a pretty standard feature, for instance, that skips retraction when the travel following the retraction is less than X millimeters (which could be detected in firmware if the travel move is a straight shot, but not if the travel includes some kind of seam-hiding move or routes around other objects) or if a travel move stays within the interior of an object and doesn't cross perimeters.

[bkubicek]

the idea to have it in lcdwas to have an option to see the difference in retraction distances and such in print, to find optimal settings. also, for delta robots, some extension would be nice, to have increasing z-lifts with z height: if you are high up, the print might wobble if you move in layer, hence it is better to z-lift. This could be done in the same style.

Bernhard

On Sun, Feb 23, 2014 at 8:27 PM, whosawhatsis notifications@github.comwrote:

Generally, you want the slicer (which has a lot more information about your print than the firmware) to decide when to retract and when not to. Slicers have a pretty standard feature, for instance, that skips retraction when the travel following the retraction is less than X millimeters (which could be detected in firmware if the travel move is a straight shot, but not if the travel includes some kind of seam-hiding move or routes around other objects) or if a travel move stays within the interior of an object and doesn't cross perimeters.

Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/800#issuecomment-35840322 .

[Kenzu]

Okay I have now tried with retraction enabled in Simplify3D and it does retract, but with Simplify3D's settings. FWRetract does not detect it and replace settings.

attached gcode https://drive.google.com/file/d/0Bxi31Nhfkw_sZnp3TTlqcWVNQjg/edit?usp=sharing

edit: I can see via LCD that FW Auto Retract is enabled.

[whosawhatsis]

I see some retractions that should be detectable in there. I'll try the code on a machine in a bit, but I'll have to do some modifications to the code first because it's generated with zero at the center, and my zero is in the corner.

[Kenzu]

cool, I have tried with a gcode made with Cura (not ulticode) and it's the same. Does not detect it. I have z-lift in firmware to be sure i can se when it's firmware or slicer retraction.

[whosawhatsis]

Found the problem. Somehow the changes I made to fix this bug previously got lost, must have accidentally reverted them in my test branch before merging over to a clean branch to submit a pull request. I've re-applied the changes and submitted a new pull request: https://github.com/ErikZalm/Marlin/pull/805

[Kenzu]

Nice, will give it a test tomorrow. Can you please fix the LCD menu too. I only think there is a problem with feedrate and resume rate. Max is now 999 via menu, and I run 1800mm/min.

[whosawhatsis]

@Kenzu It looks like the change is safe to make, but I'm not set up to test it here. You can grab this branch to try it out: https://github.com/whosawhatsis/Marlin/tree/fwretract_lcd

[Kenzu]

Sure,will test it to tomorrow. Maybe you could take a look at this then? https://github.com/ErikZalm/Marlin/pull/730 I'am not a coder, so it just a hack i made for my dual fans on my prusa dual x carriage. It does work on my machine, but I don't know if my coding/hacking is ok, per Marlin standard. :-)

[Kenzu]

Okay. fw auto retract is working now with the same file. :-) @whosawhatsis I have tested your branch and the LCD menu problem is not fixed. I does behave different, now it starts over when it hits 999, so i starts at 0.

[andrewsil1]

Whosa, you mentioned earlier in the thread that you get big differences by using a different (lower?) recover speed than for the retraction itself. For the semi-noob here, what is the benefit you get, and what guidance would you give for trying to determine the right settings for each?

[whosawhatsis]

@Kenzu Thanks for testing. I'll need to familiarize myself more with how the LCD code works.

@andrewsil1 You want to retract as fast as possible without your extruder skipping to zero out the pressure in the nozzle, but when it's time to repressurize the nozzle, you want to do it closer to the speed you will be extruding while printing so that the nozzle pressure can equalize before it starts moving.

[boelle]

is this still an issue or has it maybe been fixed in the main branch?

[boelle]

please open a new issue if this is still present in the current bug fixing branch

https://github.com/ErikZalm/Marlin/tree/Marlin-v1-bug-fixing

[OhmEye]

I'm curious if this fix was fixed and if so which branch/commit it was. I just merged my own mods with current dev branch yesterday and FWRETRACT is working but if I use gcode without G10/G11 the autoretract seems to miss half or more of the retractions and I'm poking around the issues and commits as a first step looking into it. So I'm curious to know if there are indeed any current known issues with autoretract before I dig into it deeper.

[thinkyhead]

@OhmEye Autoretract is not on the radar at the moment. Post a new issue about it, I recommend. It sounds different from this issue, and we definitely want to keep an eye on things like this, especially if it might reveal an underlying problem. If you can isolate variables involved that will help a lot (whether affected by jerk, acceleration, or anything like that). But meanwhile please post about whatever you are able to figure out.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.