Slic3r 1.1.7 printing paths <less schizophrenic?>

I recently upgrade to Repetier-Host 1.0, and with that I upgraded my Slic3r to version 1.1.7 . I forgot what previous version of Slic3r I was using but it was probably well before version 1.0.

Anyway, I'm printing some small lines with iterations in them, they are exactly 1 layer thick and a few layers tall around 4 or 5. Before I upgraded to the new Slic3r 1.1.7 I had no problem printhing these models, the printing path would print most of the lines from left to right consistently, liken to writing in cursive or script. Upon the upgrade to 1.1.7 the slicing / tool paths have become quite schizophrenic, now with version 1.1.7 of Slic3r, it doesn't really print from left to right , now it will print a little here and a little there, left and right constantly on one row, this ultimatley results in a bad print.

I spent all day yesterday re-slicing my model(s) with various settings and doing dry runs but I cannot get the printer to print more smoothly, from left to right with minimal tool path iteration.

As far as the model itself, nothing has changed.

Any ideas on what I could do? It's definitely in the slicing, because when I loaded up older gcode models (done in a previous version of Slic3r) the files printed the way I needed them to.

I've attached some images, one shows an in-progress screen-cap of what's happening, as you can see the printer just extrudes here and there, instead of making a consisten line.

Any help would be wonderful.

Edited 1 time(s). Last edit at 08/09/2014 06:40PM by VDrom.

I've gone back to v0.97 because of the crazy toolpath movements.

---

_______________________________________
Waitaki 3D Printer

Okay, good thing I'm not the only one having issues with derranged toolpaths. Version 1.1.7 of Slic3r is not fairing well with small detailed models. Indeed the order in which the newer versions of Slic3r prints, to me, seems utterly illogical.

I will revert back to 0.97 and thank you for reminding of what version you're on, I hope things will smooth back out again, the past few prints have been VERY frustrating.

*One last note, is that I have another printer running on an Azteeg X1, and it's printing the sameway just fine on Slic3r, maybe my firmmware needs some tweaking and finessee on the printer that's not getting it right on version 1.1.7 of Slic3r, it's running on RAMPS 1.4. Is there anything I should look at in the firmware code? The printer actually does run a little shakey / jerky when compared to the other printer running on the Azteeg. Ultimately it seems that some really fine tuning is needed if I still want to continue using 1.1.7 of Slic3r.

Edited 4 time(s). Last edit at 08/11/2014 05:10PM by VDrom.

Well, at the end of the day, its the firmware that interprets the g-code it receives so anything's possible I guess. Maybe that's something I should look into before rejecting later versions?

---

_______________________________________
Waitaki 3D Printer

Hmmm, but its the gcode that tells the printer to move to specific coordinates, extruded, etc. And if the gcode is generated by Slic3r then I think most of the problem is lies in the printing paths determined by the slicing software.

As far as firmmware, I'm using Repetier, though I havent tweaked around with it in a while. I could probably stand a lesson or two on how to smooth out the movements of the printer itself, my jerk is set pretty low via EEPROM at .20, but that hasn't seemed to make much of a difference.

Anybody?

So I may have found a possible resolution (which I may have had enabled on an older version), and that's turning on "avoid crossing perimeters" but Slic3r is hanging up on "exporting gcode" it's been like this for a good 5 hours or so. I've tried massaging a few settings and checking the model in NetFabb but nothing thus far is making this thing crank out a gcode file. =(

Still at a loss.

Edited 1 time(s). Last edit at 08/14/2014 01:25AM by VDrom.

Can you post the STL?

---

_______________________________________
Waitaki 3D Printer

I am going to try and slice one more time with some scaling/rotation changes I made to the model and some different gcode settings. If it hangs I will post the .stl here.

*As a reminder - I am trying to get the model to slice with "Avoid Crossing Perimeters" as I believe this resolves my original issue with the "schizophrenic" tool paths. I know it usually takes longer to slice with this setting enabled, so I've turned up my processing threads; they've actually been turned up with the past few attempts to slice.

Wish me luck!

Edited 1 time(s). Last edit at 08/14/2014 11:09AM by VDrom.

Okay no luck. I even tried using Slic3r 1.2.0 experimental (claiming it has faster slice times with "Avoid Perimeters" enabled), but it kept giving me a runtime crash upon "exporting G-code."

Anyway - here is the .stl file:

[www.dropbox.com]

My print bed is AT 200 x 200mm and upon loading the .stl file I scale up the model to the following sizes before slicing.

x 2.258
y 2.52
z 2.5

*Also in the Slic3r settings I make 2 skirt-loops around the model at -1mm or 0mm distance from the model, this is so I can easily peel the model off the bed after printing.

Edited 1 time(s). Last edit at 08/14/2014 12:42PM by VDrom.

*I don't know if this makes any difference, but the version of Slic3r that I was using where it was printing the print I've posted in a more consistent order was Slic3r version 1.0.0RC2. It seems as if any version preceding that generates the toolpaths in such a way that causes the print to fail - see posts above.

I've been trying everything to correct this in version1.1.7 but to no avail, it looks like I'll have to stick with the older version until "something" changes. But if anyone has any suggestions on what I could do that would be great, I would really like to be using the latest version of Slic3r.

Thanks.

That STL came up with problems when I checked it. I've run it thru Netfabb to repair it but it looks like a threadbare carpet!
Too big to upload here so suggest you run it through Netfabb your end.

---

_______________________________________
Waitaki 3D Printer

Thanks for looking into this Waitaki, maybe that's what could be causing the tool path issues. Though I could of sworn I've checked these models in NetFabb before for errors, but I will see if my version of NetFabb needs up to be updated and will double check again.

*Most recently I tested out Slic3r V1.0.0RC3 and it seems to be printing out these kinds of models fine too.