Slic3r configs for Replicator 2

[Wingcommander whpthomas]

Anyone who does not currently have PyPy installed for ReplicatorG and would like to try a faster slicer out - I have got Slic3r working for the Replicator 2. You can download my Slic3r configs from the usual place http://www.thingiverse.com/thing:39050 for these sorts of things ;)

Use the Flle->Load Config to set each configuration. Save a 'Replicator 2' printer settings,'PLA 1.75' filament setting (and maybe one for any other filament sizes you have eg. 1.69) and one print setting for each config (100, 200, 340 micron). You still need to use ReplicatorG to load the sliced gcode files to export the x3g file to print from your SD card.

Slic3r can be downloaded from here http://slic3r.org its OSX, Windows and Linux compatible.

Slic3r is a fast slicer, and the default infill pattern also prints fast. You can also make hollow objects like vases really easily.

[Wingcommander whpthomas]

In my experience, ReplicatorG/Skeinforge prints HQ (0.1mm layer height) better than MiracleGrue or Slic3r. In Makerware skeinforge does not currently use Pypy (a python compiler optimiser) so its about 5 to 10 times slower. There are instructions on how to install pypy on a mac for use with ReplcatorG in an previous thread.

Others had mentioned that Slic3r was fast, but no-one had set it up for the Replicator2. So being curious I though I would give it a try. Not convinced as yet that Slic3r is any better than Makerware/MiricleGrue.

So bottom line - the ReplicatorG/Skeinforge/Pypy combo is fast, accurate and configurable, but has a bit of a learning curve to master - which means lots of calibration test prints etc.

However, if you are happy with the quality that Makerware/MiricleGrue puts out - stick with that.

[KM Design]

I've been interested in trying Slic3r for a while so I was excited to see your profiles. I did my first test last night and had some interesting results. Slic3r is definitely fast. I was printing something with some small extruded text (4mm text extruded about 1mm) on the top flat surface and with Slic3r. The text was close to perfect. With Miracle Grue and Skeinforge most of the text has been missing completely. Needless to say I was impressed. The sides of the object are almost perfectly smooth with no banding even at 0.15 but the top and bottom show visible banding and still need some refinement.

Kevin

[Wingcommander whpthomas]

Cool - keep us posted if you teak some settings that get a better result. Photographic comparisons are always a treat as well ;)

[Alex Huff]

I posted a new topic on this but perhaps it belongs here. I downloaded your profiles for slic3r, selected "sailfish" from the gcode flavor menu (because i just upgraded to 7.1) and used repg to export the xg3. I got some weird results (see pics). It looks like the y shifted each layer. Has anyone else experienced this? Should I not select sailfish from the gcode flavor menu?

Alex

[Dan Newman]

On 16 Feb 2013 , at 6:23 PM, Alex Huff wrote:

> I posted a new topic on this but perhaps it belongs here. I downloaded your profiles for slic3r, selected "sailfish" from the gcode flavor menu (because i just upgraded to 7.1) and used repg to export the xg3. I got some weird results (see pics). It looks like the y shifted each layer. Has anyone else experienced this? Should I not select sailfish from the gcode flavor menu?

Not too sure why you are raising this in yet-another-thread. Honestly, this isn't
even a makerbot-operators topic and you should post it in the Sailfish forum, jetty-f...@groups.google.com.

That said, do you know what the "Sailfish" selection does in slic3r? If you do not know what
it does, then try not selecting it. It's a new option, no one seems to know what it does,
and slic3r is known to work with Sailfish without it. Stands to reason that you
might want to try not selecting it…. Sailfish runs on Makerbots. Stick to a "makerbot"
profile/selection in slic3r.

Dan

P.S. As I stated in the other thread you opened, the authors of Sailfish don't even know what
this setting means in slic3r. No one on the slic3r team mentioned this to us so it's news to
us. It could mean anything. To the best of my knowledge, you're the first person to try using
it. Jetty and I certainly never tested it with Sailfish.

[Alex Huff]

Ill give it a shot and report back. Thanks for all the help

[Dan Newman]

On 16 Feb 2013 , at 6:40 PM, Dan Newman wrote:

>
> On 16 Feb 2013 , at 6:23 PM, Alex Huff wrote:
>
>> I posted a new topic on this but perhaps it belongs here. I downloaded your profiles for slic3r, selected "sailfish" from the gcode flavor menu (because i just upgraded to 7.1) and used repg to export the xg3. I got some weird results (see pics). It looks like the y shifted each layer. Has anyone else experienced this? Should I not select sailfish from the gcode flavor menu?
>
> Not too sure why you are raising this in yet-another-thread. Honestly, this isn't
> even a makerbot-operators topic and you should post it in the Sailfish forum, jetty-f...@groups.google.com.
>
> That said, do you know what the "Sailfish" selection does in slic3r? If you do not know what
> it does, then try not selecting it. It's a new option, no one seems to know what it does,
> and slic3r is known to work with Sailfish without it. Stands to reason that you
> might want to try not selecting it…. Sailfish runs on Makerbots. Stick to a "makerbot"
> profile/selection in slic3r.

So, I played around with some gcode with G92 E0.0 commands in it. Sailfish handles
them just fine as previously tested by various slic3r and KISSlicer users. The
real issue is that RepG may not handle them fine. When connected over USB, there's
the problem I mentioned previously. However, I generated some s3g/x3g with RepG
(no bot connected) and saw that it can have issues there too. RepG tries to track
the current coordinates and fill in the missing ones from the G92 command. And,
I'll see it be off by 1 about half the time,

150: Move to (-681,-714,28,0,-1) dda_rate: 5552 (relative: 18) distance: 0.518652 feedrateX64: 4608
151: Extended Machine position set as (-682,-715,28,0,0)

So the actual position was (x,y,z) = (-681, 714, 28). But then it told
the bot that the position is (-682, -715, 28). That's off by one in both
X and Y. So, now the subsequent printing will be shifted in X and Y by 1.
If that happens again in the same direction in another layer, then it will
shift again. It's easy to see how this will cumulatively skew the entire
print. I saw at least half the G92 commands I put in have this defect.
It's probably a rounding error of some sort: in producing the coordinate
to move to, RepG is doing one sort of calculation with a resulting roundoff
error. But in producing the machine position, it's doing a different calc
with it's own roundoff. (Roundoff as you convert from millimeters to integer
steps.) My guess is that they are accidentally accumulating into the Extended
Machine position the roundoff error left over from the move-to position.
But, that's just a hunch.

At any rate this is a RepG bug which RepG 40 - Sailfish has inherited from
RepG 40. It's not a Sailfish firmware bug -- the problem is in the s3g/x3g
generated by RepG.

Dan

[Dan Newman]

OOn 16 Feb 2013 , at 6:23 PM, Alex Huff wrote:
>>
>>> I posted a new topic on this but perhaps it belongs here. I downloaded your profiles for slic3r, selected "sailfish" from the gcode flavor menu (because i just upgraded to 7.1) and used repg to export the xg3. I got some weird results (see pics). It looks like the y shifted each layer. Has anyone else experienced this? Should I not select sailfish from the gcode flavor menu?
>>
>> Not too sure why you are raising this in yet-another-thread. Honestly, this isn't
>> even a makerbot-operators topic and you should post it in the Sailfish forum, jetty-f...@groups.google.com.
>>
>> That said, do you know what the "Sailfish" selection does in slic3r? If you do not know what
>> it does, then try not selecting it. It's a new option, no one seems to know what it does,
>> and slic3r is known to work with Sailfish without it. Stands to reason that you
>> might want to try not selecting it…. Sailfish runs on Makerbots. Stick to a "makerbot"
>> profile/selection in slic3r.
>
> So, I played around with some gcode with G92 E0.0 commands in it. Sailfish handles
> them just fine as previously tested by various slic3r and KISSlicer users.

> …

> It's probably a rounding error of some sort: in producing the coordinate
> to move to, RepG is doing one sort of calculation with a resulting roundoff
> error.

I looked in the RepG sources and sure enough. It has stored in memory
the current position in units of millimeters. When it outputs the
move-to coordinate, it converts that current position from millimeters
to units of steps AND adds in any accumulated round off. But when
it outputs the same current position as part of a "set position"
command, it doesn't add in the accumulated roundoff. Hence the discrepency.
This discrepancy accumulates from layer to layer causing the skew you
see. Some models will have a accumulated roundoffs when the G92
occurs, and others won't. So some models will exhibit this RepG bug
and others won't.

So, I modified my copy of RepG to also put in the accumulated roundoff
in the set position coordinate and now no more discrepency. I guess I'll
include that fix in "r6" of RepG 40 - Sailfish.

If you'd like to test the change, let me know and I'll see what I can
do to get you a copy. Problem is, the distributions are large and I
don't have a good place to park it but I'm sure we can work something
out.

Dan