Firmware retraction conflict?

456 views
Skip to first unread message

Brad Hopper

unread,
Aug 28, 2014, 3:31:03 PM8/28/14
to smoothiewa...@googlegroups.com
All,

I've enabled firmware retraction in slic3r and added the appropriate lines to the config. However, I'm not seeing any zlift and I'm pretty sure I'm not getting any retracts either. Lots of stringiness everywhere.

Is there some other slicer or host setting which might conflict with firmware retraction?

Thanks!

Brad

wolfmanjm

unread,
Aug 28, 2014, 4:34:50 PM8/28/14
to smoothiewa...@googlegroups.com
Use M207and M208 to set the retraction and zlift, you probably have a config-overide file overiding the config settings.
check with M503

Steve Graber

unread,
Nov 14, 2014, 12:48:37 PM11/14/14
to smoothiewa...@googlegroups.com
Brad, did you get this sorted out? I'd like to try firmware based retraction myself one of these days so I'm just curious.

Steve

Brad Hopper

unread,
Nov 14, 2014, 3:26:13 PM11/14/14
to smoothiewa...@googlegroups.com
Steve actually I never tried after I got regular retraction going. Don't quite remember but I think Cura didn't expose a firmware retract option or at least perhaps Rep host didn't for Cura. Keep me posted as I intend to revisit.

wolfmanjm

unread,
Nov 14, 2014, 4:50:15 PM11/14/14
to smoothiewa...@googlegroups.com
firmware retraction works perfectly well if you use a slicer that supports it like slic3r.

Brad Hopper

unread,
Nov 30, 2014, 11:39:01 AM11/30/14
to smoothiewa...@googlegroups.com
OK, according to this post, M209 S1 enables firmware retraction in Cura >v14.3.

I set this and I'm not sure I'm seeing retracts or zlift according to the config file. (I'll have to double check if there's an override set, printing now)

BTW I'm also using volumetric extrusion and have the slicer filament set to the magic number and actual filament diameter set with M200.

I noticed since enabling firmware retraction, that there are gaps whenever there are circular holes, particularly seen at the top of prints.

Note that there are not gaps in the infill or where infill touches perimeters, or in straight lines anywhere, only in circular edges or especially holes.

It doesn't seem like this is present at the bottom of the prints, but it's possible that zheight slightly too close overextrudes near the bottom of prints and then clears up after a while.

Here's a picture:

Brad Hopper

unread,
Nov 30, 2014, 3:06:14 PM11/30/14
to smoothiewa...@googlegroups.com
Oh, here's the post I was referencing:

http://forum.bukobot.com/index.php?topic=3171.0

On Sunday, November 30, 2014 11:39:01 AM UTC-5, Brad Hopper wrote:
OK, according to this post, M209 S1 enables firmware retraction in Cura >v14.3...

wolfmanjm

unread,
Nov 30, 2014, 5:15:23 PM11/30/14
to smoothiewa...@googlegroups.com
M209 is not supported in smoothie, G10/G11 is what firmware retraction uses, and set with M207 and M208
 there is no enable/diisable of firmware retraction. Your slicer needs to generate G10 and G11 for retract and unretract. Slic3r does this, Cura obviously does not support firmware retraction.

Brad Hopper

unread,
Nov 30, 2014, 6:38:15 PM11/30/14
to smoothiewa...@googlegroups.com
I think Cura does support firmware retract but, after a bit more searching around, it seems one must select ultigcode flavor of gcode. Will report back if I can get it going.

robin bussell

unread,
Dec 1, 2014, 9:17:12 AM12/1/14
to smoothiewa...@googlegroups.com

Hi Folks,
is there a discusion on record about the pros and cons of running
smoothie on a delta printer and using either the
delta_segments_per_second or mm_per_line_segment options.

If not, then shall we start one? Is one method "best", if not then what
are the respective tradeoffs?

Cheers,
Robin.

Triffid Hunter

unread,
Dec 1, 2014, 5:54:32 PM12/1/14
to smoothiewa...@googlegroups.com
delta_segments_per_second is preferred.

It uses longer segments for faster moves, which prevents the speed being artificially capped by the length of the move queue.

In theory, long segments run the risk of the nozzle diving into the workpiece, however Z-lift works extremely well on deltas and should be used to prevent this from happening.




--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

robin bussell

unread,
Dec 2, 2014, 4:03:57 PM12/2/14
to smoothiewa...@googlegroups.com
On 01/12/2014 22:54, Triffid Hunter wrote:
> delta_segments_per_second is preferred.
>
> It uses longer segments for faster moves, which prevents the speed being
> artificially capped by the length of the move queue.
>
> In theory, long segments run the risk of the nozzle diving into the
> workpiece, however Z-lift works extremely well on deltas and should be
> used to prevent this from happening.
>
>

Thanks, that makes sense.
So, what sort of frequency can smoothieboard handle? is the default 100
segs/second conservative or on the edge?

Cheers,
Robin.


Brad Hopper

unread,
Dec 2, 2014, 8:48:21 PM12/2/14
to smoothiewa...@googlegroups.com
OK I can confirm that firmware retraction is supported in Cura (at least in 14.09).

This is a per machine setting, found under Machine>Machine Settings>GCode Flavor>RepRap (volumetric)

In this gcode flavor, volumetric extrusion is bundled with firmware retraction. I'm not 100% sure how volumetric extrusion via gcode meshes/conflicts with "tricked" volumetric extrusion with the magic diameter in the slicer and the real diameter in Smoothie.

Regardless, the print looked better than I've seen in quite a while!

Now some tuning of the retract settings is in order!

Reply all
Reply to author
Forward
0 new messages