Slic3r issue on Replicator - only one issue left!

I've been working on getting Slic3r working on my Replicator.

I've nailed everything except an issue wherein every time a new layer is printed, it is shifted 0.6mm in the X axis (to the left, to the left).

I've attached a photo for you folks.

AND: The gcode generated by slic3r (nickel_test_slic3r.gcode)
ALSO: The gcode start / end I use in replicatorg (Dual_Head_start.gcode / end.gcode)
PLUS: The gcode for the same stl as generated by replicatorg. (nickel_test_RG_SF.gcode)
BUTWAITTHERESMORE: The config from slic3r (replicator.ini)
My intention is to create a good Replicator profile for slic3r so that I can share it around.

After gcode is generated from slic3r, I edit it and manually insert the start / end code, replacing some of the slic3r code at the beginning. (See files)

Does anyone have any suggestions about what I should try next?

Thanks!

I quickly went through the gcode files and what popped out was the speeds which can cause lost steps easily.

Slic3r:

Travel speed of 130mm/s
Z speed of 130mm/s

RepG

Travel speed of 60mm/s
Z speed of 45mm/s or 60mm/s ?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I'll turn those down and give it another try after a large print I'm working on has finished.

Thank you for taking the time to look at this!

No dice. I lowered it to 40mm, and the same thing happened, very very slowly.

What a strange thing! Any other recommendations as to where I might look?

thanks!

Unfortunately it could be a lot of things.
Rule out mechanical issues first.
If your using Marlin firmware try reducing the acceleration.
Try adjusting the pot on the driver that's skipping both too low and too high can cause it.

Thanks for the reply!

I'm sure it's nothing mechanical, as I'm getting AMAZING prints out of the stock firmware / replicatorg. My desire to use slic3r is coming from the extra features, and MOSTLY the ability (experimental and all) to extrude support material from a different extruder. I have the dual replicator, and 5 pounds of PVA (got an absurd deal), so the first app that helps me generate support material from a second extruder will win my love forever

Your SF generated code never resets E with a G92 (I suspect makerbots firmware has no over flow issues and does not require it) But Slic3r is generating them at the end of each layer. They may be whats causing your issue. The only way I can think of testing it is to set SF to reset the extruder as often and see if it causes the issue. The only work-around I can think of is using relative extrusion so it has no reason for the G92's.

If you can confirm it is the issue you should file a bug report on the Slic3r git page.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

if G92 E0 is causing offsets in X, then that's a firmware issue, not a slic3r issue

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Well, I can disable G92 E0 for makerbot output (as I did for Mach3 output, since Mach3 seems to do huge pauses upon receiving it), but I need a serious proof that Makerbot firmware has serious troubles with it...

Ok, folks.
I did NOT have much time to work on this yesterday, but expect to have more tonight.

I set it to relative E, and the output was interesting. I printed this: [www.thingiverse.com]
just as I had in my attached above tests. It seemed that every 40mm or so, the filament would stop feeding and I would get a 10-15mm hole in the output.

After spending FOUR HOURS slicing Yoda in ReplicatorG/SF, I want Slic3r to work more than ever!

What will help you all most? Photos? Video? Heck, I'll give someone remote access and a webcast of the printer.

I apologize for not having more meaningful results from last night - timing was awful. I can do far more tonight.

For relative E to work the firmware needs to know you are using it. I do not know makerbot firmware at all so I am not sure how you go about this. For RepRap firmware you go into the firmware and change it and then re-upload the firmware.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Bruce,

Have you had any luck since you last posted? I've also got a Replicator, and am trying to reproduce your results. What I've been noticing is that the infill on solid using your settings have "gaps". I dropped the speed, and I haven't seen the "shift over" issue, but the prints definitely don't look as clean as the ones skein makes.

-M

I haven't had any further luck. I've put it to the side until I can go and look through the Replicator firmware.

That said, I turned the speed down to 40/40, and still saw the offset. Can you share your settings that avoided it?

Total fluke...

Next time I ran the code, total failure. I opened a support ticket with MBI about the issue, as well as talked to Sound on IRC about possible ways to avoid needing G92 E0. Although, since the firmware _supports_ dimension, and acceleration, there is no reason it should be jinking around like that.

Ethan "closed" my slic3r ticket, but I've re-opened it. This firmware fault needs to be found and fixed.

-M

Take a look at the latest Replicator release:
[www.makerbot.com]

It adds Slic3r support directly into ReplicatorG, as well as Miracle Grue. Most importantly, it includes acceleration support in SF. It's not the most mature implementation you've ever seen, but it's absolutely a massive improvement, especially when printing things that don't require AMAZING quality (lots and lots of bottle openers for instance).

Enjoy!

The problem is most likely the ReplicatorG program. I don't thing it is the firmware.
I had the exact same problem but it affected my Y-Axis with each layer.
My solution was to switch to KISSslicer and then I have a post-processor program that converts the G92 E0 lines (that KS generates with each layer) to a continuous E value.
You are welcome to try this program, download at

[dl.dropbox.com]
E-mail me if you have questions on usage.
I like this patch since it integrates into KS transparently. Only problem is that RMS.exe (written in VB4) is really slow.
I get perfect prints of the Replicator.

Good Luck,
Don
starkey.don@gmail.com

Since version 0.9.0, Slic3r does not reset the E values when the Makerbot output is selected (thus no G92 E0 commands are written).

No more need to post-process your G-code to make RepG happy.

Hello, an old post maybe, but as Makerbot Replicator owner and changes of firmware, I have a request about changing the Gcode for the Toolchange for dual prints.

First: I also switched to Kisslicer. The maker also made a Makerbot flavor firmware, adding up the E values. Now there is an alternative firmware (Sailfish) available (by Jetty and Dan). This firmware hasn't the problems with the G92 E0 commands.
Only, for dual extrusion there is some postprocessing needed in regard of the Toolchange. in the Kisslicer firmware that is to add the G55/G54 commands Makerbot uses for their coordinate system.

It seems that Makerbot is changing some stuff: they are abandoning that G54 coordinate system now, storing the extruder offset in the firmware. I discovered the possibility of dual prints of Slic3r,now that I had a new look at Slic3R, together with Repetier-Host.

I'm very enthusiastic about Slic3r! It is easy to use, very fast and most important dual extrusion for objects as well support!
Repetier-host gives good 3D info regarding stl's and Gcode also dual print Gcode.

The only thing is that the Makerbot flavor (adding up E values) won't work with the "combine multi material STL's" still producing Gcode with the G92E0 command in it. For me that is not a problem, using the Sailfish firmware.
I have only the following request, to avoid the post processing the Toolchange now is:
T0 ; change extruder
G92 E0 ; reset extrusion distance
The Replicator needs to see the G92 E0 commands first, otherwise it won't apply the firmware Tool offset. It has to be:
G92 E0
M108 T0
(so also with the M108 command, only T0 won't change the tool)
so for the other tool it of course has to be
G92 E0
M108 T1

It would also be nice that the temperature change of the HPB uses the M109 command instead of now the M140 command.
I hope this is possible, because post-processing is not easy for a beginning user.

After using Slic3r a lot: would it be possible that the "slow" infill / surface patterns having a bug, because when using these only the perimeters are printed (so no infill or top/bottom). The "not slow" patterns are working well.

I hope someone can help with this, but I'm new here, I don't know yet who the developers are.

Thanks!
Bart












Sound Wrote:
-------------------------------------------------------
> Well, I can disable G92 E0 for makerbot output (as
> I did for Mach3 output, since Mach3 seems to do
> huge pauses upon receiving it), but I need a
> serious proof that Makerbot firmware has serious
> troubles with it...