Crooked Prints with sailfish and slic3r

[Alex Huff]

I just updated to Sailfish and also started using Slic3r with WingCommanders config files. As a first print post upgrade I decided to make this: http://www.thingiverse.com/thing:23030 which I sliced in Slic3r, then used RepG to save as xg3. I got some weird results....

Check out the pictures, but it seems like the y axis is shifting after each layer, causing the parts to build at a slant. I need to do some trial by elimination to see whats going on here but I just thought I would ask if anyone has seen this before? Im not sure if this is a sailfish thing or a Slic3r thing. In slic3r I changed the gcode flavor to Sailfish, should I not have done this and left it set to makerbot?

Any help is appreciated!

Alex

[Dan Newman]

Slic3r may be sending G92 commands to reset the position after each layer.
That has been reported to work in the past with Sailfish by funbart. But
it's not something which I test. However, if it's not working then I suppose
you could get slight skews if the position isn't reset the way it thinks it
will be. HOWEVER, I thought that slic3r and KISSlicer only reset the
E (or A & B) positions with G92.

But, and here's the interesting part, there's an issue with using G92 when
connected over USB to the bot with RepG: it doesn't work. When RepG sees

G92 Exxx

it is being told to set the E axis position to xxx. Unfortunately, RepG
is too clever by half and when connected to the bot wants to send the
coordinates for the X, Y, and Z axes as well. It doesn't need to -- it
just wants to. So, since it is connected over USB to the bot, it queries
the bot for the current position and then changes just the E axis part of
that position and sends that back. Unfortunately, the position it got
initially is likely garbage…. So rather than just set the E position,
it tries to set X, Y, Z, and E and ends up getting garbage for X, Y, and Z
which it then sends back and thus causes a problem.

Why is there garbage when it asks for the current position. Well, tracking
the current position from RepG's space of millimeters in absolute coordinates,
into the bots space steps in absolute coordinates, then into toolhead space
with offsets, then into and through a queue of planned segments is a big
headache in a bot with limited code space. So, MBI back around their 5.3
or 5.4 firmware stopped doing that. (When they first added acceleration to
their firmware, they dropped support.) We retained it in Sailfish just
enough to make G92 work. But we didn't also make querying the position work.
So, if you print connected to the bot over USB and use G92 then you can
see problems. (Comes up with Cupcakes which is how I first analyzed this
issue.) So, if you're printing over USB then this is just yet another
reason to not do so and instead print from an SD card.

And, on the other hand, this may not be the problem you're seeing.

Dan

[Alex Huff]

I appreciate the detailed response! However I never ever print over USB, I always use the SD card for both convenience and reliability. Im going to try a few other prints tonight and see if I get similar results.

I really like using slic3r because of its speed. Hopefully this problem will be easily resolvable with a change of a setting.

Any further thoughts? All are appreciated

Alex

[Dan Newman]

On 16 Feb 2013 , at 3:46 PM, Alex Huff wrote:

> I appreciate the detailed response! However I never ever print over USB, I
> always use the SD card for both convenience and reliability. Im going to
> try a few other prints tonight and see if I get similar results.
>
> I really like using slic3r because of its speed. Hopefully this problem
> will be easily resolvable with a change of a setting.
>
> Any further thoughts? All are appreciated

Does the gcode have G92 commands in it? Such as every layer? And if so,
what do they look like?

You might also look in RepG at Machine > Onboard Preferences and see
if you show a Tool Count that isn't 1. If it's 2, then toolhead
offsets will be established which could be doing something odd, although
I don't see how.

Dan

[Alex Huff]

I just noticed that Slic3r has a checkbox for "Use relative E distances". It is currently unchecked. Should it be checked? Could this be what was making it reset after each layer?

On Saturday, February 16, 2013 6:33:04 PM UTC-5, dnewman wrote:

[Alex Huff]

The gcode does have "G92 E0" at each layer. Is this what you were referring to?

[Dan Newman]

On 16 Feb 2013 , at 3:55 PM, Alex Huff wrote:

> The gcode does have "G92 E0" at each layer. Is this what you were referring
> to?

Yes. And that may potentially be the source of the problem. Hard to say since
funbart (who has a Rep 1) has indicated that things work for him with 7.1 and he uses
KISSlicer which I believe -- but do not know for a fact -- also uses G92. The
code here is identical between a Rep 1 and Rep 2.

Dan

[Alex Huff]

I checked the "Use relative E distances" box and generated gcode for another part and the G92 lines of code are gone all together. I guess im going to give it a whirl and try and print it unless you (or anyone else) thinks I should not attempt to print using relative E distances

[Dan Newman]

On 16 Feb 2013 , at 4:03 PM, Alex Huff wrote:

> I checked the "Use relative E distances" box and generated gcode for
> another part and the G92 lines of code are gone all together. I guess im
> going to give it a whirl and try and print it unless you (or anyone else)
> thinks I should not attempt to print using relative E distances

RepG *always* turns the extruder distances into relative coordinates.
So, under the hood relative e distances are all that are ever seen by
makerbots. The only difference will be the presence of the G92.

Dan

[KM Design]

I've used WingCommanders Slic3r config files successfully to slice things for my Replicator2. I had no trouble with shifting layers, quite the opposite actually. The sides of my objects are smoother than using RepG or Makerware. I'm not using Sailfish so your issue is likely the interaction of both things.

Kevin

[Dan Newman]

On 16 Feb 2013 , at 4:25 PM, KM Design wrote:

> I've used WingCommanders Slic3r config files successfully to slice things
> for my Replicator2. I had no trouble with shifting layers, quite the
> opposite actually. The sides of my objects are smoother than using RepG or
> Makerware. I'm not using Sailfish so your issue is likely the interaction
> of both things.

But you're probably also not telling Slic3r that you're using "Sailfish"
and instead telling it "Makerbot". I'm one of the two developers of Sailfish
and I have no clue whatsoever what slic3r does when you tell it "Sailfish".
Indeed, it's news to me that slic3r even has a "Sailfish" setting. (I've
only tried to use slic3r once and it was not a good experience, but that
was about 6 - 8 months ago.) If I were to try slic3r, I'd tell it "makerbot".
Again, since I have no idea what telling it "Sailfish" means.

Dan

[Joseph Chiu]

I was installing the latest RepetierHost today to set up a Bukobot for L.A. Makerspace - I noticed that the bundled Slic3r has a Sailfish setting, and was going to start playing around with that.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dan Newman]

On 16 Feb 2013 , at 4:34 PM, Joseph Chiu wrote:

> I was installing the latest RepetierHost today to set up a Bukobot for L.A.
> Makerspace - I noticed that the bundled Slic3r has a Sailfish setting, and
> was going to start playing around with that

You'd think they might let Jetty or myself know about it. Again, I have
no clue whatsoever what it might do. It certainly wasn't tested by jetty
or myself. Just sayin'.

Dan

[Darrell jan]

Alex,

Did you look at the gcode with a visualizer like Repetier or Pleasant 3D? Just to see if maybe the gcode is OK, then it would be a printer problem.

Darrell

[KM Design]

Hi Dan,

True enough, I am using the Makerbot setting. I was only confirming that the basic profiles do work and don't exhibit the layer shift that Alex is seeing.

FYI here is a screen shot of the Slic3r preference and what the tool tips say.

Kevin

[Dan Newman]

On 16 Feb 2013 , at 4:50 PM, Darrell jan wrote:

> Alex,
>
> Did you look at the gcode with a visualizer like Repetier or Pleasant 3D?
> Just to see if maybe the gcode is OK, then it would be a printer problem.

Ummmm. Even if the gcode looks okay, it may still be a gcode problem and NOT
a printer problem. The problem with DIY 3D printing is that in the early
days the firmware developers couldn't be bothered with reading the gcode
standards. Instead they implemented gcode syntax and behaved like it was
the wild west where anything goes and cooked up their own flavor of commands
and called it gcode. Net, net Makerbots (and other DIY 3D printers) don't
speak actual gcode. They don't even speak what I'd consider a dialect of
gcode. For instance, they completely botched the concept of tool changes
even though the CNC / gcode world had figured it out in, oh say, the '70s.

So, off the soapbox. Just because the visualizer shows it as okay does NOT
mean it's okay for a Makerbot. Thus, just because it looks okay in a
visualizer does not mean that it's a printer problem. It still may be
a (wanna be) gcode problem.

Dan

P.S. And no, I'm not sorry about the soap box. The DIY 3D printing
community is really off in left base with their "gcode". And, it
makes life difficult for the folks writing toolpath generators (i.e.,
slicers). Had the folks doing this bothered to read the freely available
gcode standards and then adhered to them, we wouldn't have these
problems. Or, what problems we had would at least resolve into, "You
incorrectly implemented section X of standard Y. Go fix your broken
implementation".

P.P.S. I'm a standards wonk having been on ANSI and IETF standards
groups for quite some time and occassionally called on to play standard
"lawyer".

[Alex Huff]

Kevin, just so i understand you correctly: you are running Sailfish 7.1 on your bot and you use slic3r/repg and you leave the slic3r set to Makerbot? I assumed (wrongly so i guess) that since my rep2 has sailfish firmware then I would want to select sailfish from the slic3r settings.

thanks

[Dan Newman]

On 16 Feb 2013 , at 5:27 PM, Alex Huff wrote:

> Kevin, just so i understand you correctly: you are running Sailfish 7.1 on
> your bot and you use slic3r/repg and you leave the slic3r set to Makerbot?
> I assumed (wrongly so i guess) that since my rep2 has sailfish firmware
> then I would want to select sailfish from the slic3r settings.

Kevin wrote that he's not using Sailfish. However, if he's using
MBI's 7.0 firmware, then he actually is using Sailfish as regards
the relevant parts of the firmware. Confusing, no? (MBI's 7.0
firmware uses Sailfish for the acceleration planner, stepper interrupt,
and the handling of that part of the gcode.)

Dan

[KM Design]

Dan is correct. I am using MBI's 7.0 firmware not Sailfish 7.1. Slic3r is set to Makerbot.

I like standards because they make for predictable behaviour. I find all these non-standard standards cause a lot of trouble and confusion...

Kevin

[Dan Newman]

On 16 Feb 2013 , at 5:27 PM, Alex Huff wrote:

> Kevin, just so i understand you correctly: you are running Sailfish 7.1 on
> your bot and you use slic3r/repg and you leave the slic3r set to Makerbot?
> I assumed (wrongly so i guess) that since my rep2 has sailfish firmware
> then I would want to select sailfish from the slic3r settings.

Hmmm, I guess I followed this one up in a different thread.

This turned out to be a RepG bug and has nothing to do with Sailfish. The bug
has been in RepG for quite some time and is associated with how RepG (incorrectly)
turns a G92 command into a s3g/x3g command which it then sends to the bot.
RepG was botching this and since the G92 command effectively translates the
coordinate system, it was producing a slow skewing of the print with increase
Z height.

Sailfish, as it turns out, was just faithfully executing the bad s3g/x3g from
RepG. The only reason Sailfish got caught up in this is because the slic3r
folks know that MBI has had a longstanding bug in their firmware for the G92
command and so if you tell slic3r to generate gcode for "makerbot", it doesn't
use the G92 command. However, slic3r also likes to use G92 and it knows that
Sailfish correctly handles G92. So, when slic3r was told that it was slicing
for Sailfish, it went ahead and used G92. That then triggered the RepG bug.

For folks in the jetty-firmware group, they know that I've made available a
version of RepG that fixes this RepG bug. It also fixes another bug I discovered
in which RepG actually has +/- 1 step positioning errors in about half the
move commands it outputs! While that sounds bad, in reality you won't see much
print difference with it fixed as the mechanical positioning error in the
stepper motors is significant as well. But, it's a tacky bug IMO.

Dan

[funmakerBart]

Just an addition to the posts above, maybe it can help to start with Slicr3 with the settings I use.

Slic3r can produce Gcode without G92 E0 command with the Makerbot firmware flavor for single colored prints. But it falls back to the G92 E0 command when slicing for dual colored prints. MB firmware can't handle that, so you need Sailfish when printing dual. 

You need Sailfish anyway for consistent printing as well convenient features. Not to mention the great support Dan and Jetty giving..

The config settings attached to this file can be used for MB firmware as well (the T0 and T1 versions set to MB firmware flavor). But look carefully at the the Gcode generated, because Slic3r has the habit to insert some unwanted toolchanges just for retraction of the inactive extruder.

Maybe I said it already; you have to use Sailfish..

The settings are based on the use of RepG40 with the new toolhead offset system. When using RepG39 you can copy-paste the start/end  Gcodes from RepG. Dual printing is difficult with RepG39 and Slic3r and requires postprocessing of the Gcode file.

It's now set to the Sailfish flavor firmware, which means Slic3r automatically inserts the right toolchange when printing dual. 

Also: the material settings for PLA, ABS should be about right, but measure the filament you use and change the value in Slic3r

Same for the used temperatures for the HPB and extrusion. They can all be set in the Filament tab. Slic3r adds this setting in the Gcode.

Slic3r has it's own retraction and prime settings; maybe you have to tweak them. Since there are no M101/M103 commands, the firmware retraction and prime of the Sailfish firmware won't work.

There are specific Gcodes attached to each printer setting, I use a little different start/end code. When to be sure, just copy and paste your Gcode you normally use with RepG in the Gcode fields. The temperature settings can be left out, but the M6 commands still has to be in there.

I think you have to load the configs in three times in Slic3r.

I made the settings more basic then I normally use, so look at the settings, mainly the Gcode fields, if they are in the range normally used with RepG.

When wanting a good 3D representation of the Gcode you can choose to use the combined software Repetier-Host, which includes the latest version of Slic3r as well.

http://www.repetier.com/download/

Bart