Slicecrafter

[sylefeb]

Hi Everyone,

I am still working hard on the major features of the next release. As part of this effort, I completely rewrote the slicing engine to separate it better from the GPU code and make it faster on simple models (and also better on thin features, bridges, infills, etc.).

For the fun of it, and because I hope this will be helpful, I created an online STL slicer which you can find there:

http://shapeforge.loria.fr/slicecrafter/

To be sure: this is not an online version of IcesL (it does not support scripts or csg, only STL input). However it does use the new toolpath optimizer of the next version of IceSL.

Feedback welcome! (any improvements to this will also directly benefit IceSL).

Sylvain
PS: Maze, this includes the improvement you suggested to the sparse 3D infills.

[Maze Mietner]

I just tried one model with a rectangular base - it seemed that the first layer isn't coded the standard 45 degree zig-zag with constant extrusion as other slicers do, but as 45 degree zig-zag but with lots and lots of movements, printing a line here, another there, and so on. I'm afraid the filament would not stick to the print bed.

[sylefeb]

Hi Maze,

Thanks for the bug report - this is not the expected behavior. Could you please send me the STL file? Which printer profile did you use?

Best,
Sylvain

[Maze Mietner]

Hi Sylvain

I thought I had posted it long ago...well here it is. Checked with http://gcode.ws/

maze

[sylefeb]

Hi Maze - thanks - I confirm something is wrong ; I'll look into it!

[sylefeb]

Fixed! The website is updated, it should work now (you might have to force a refresh in the browser, e.g. Ctrl+F5 in Firefox).

This was due to an integer overflow when computing distances for path sorting -- this would only occur when comparing two distant paths and I did not spot it before. Nice catch! I modified all distance computations to occur on 64 bits, should be well enough now.

Thanks -

[Maze Mietner]

Hi Sylvain

I have spotted another really strange behavior, silly moves (see picture) for orangepilite_base.stl. It's not only on the first layer but also on all other layers...really strange. These silly moves also show up without 45° rotation, I tested it as well.

And then, when it goes to printing: The grid is printed in large 'circles' on one side, while on the other side it is printed with an 'L'-shaped movement. I really like the 'circles' as lot, as this smooths printer movement movement a lot. The 'circles' are quit, while the 'L'-shape makes a lot of noise due to changing directions so often.. So if you could keep the first and remove the latter I'd be really happy.

maze

[sylefeb]

Hi Maze,

Nice catch, thanks for the report - I am on it!

Sylvain

[Maze Mietner]

fyi: 

Cura has similar issues, exept for the silly moves. One side is cirvles, the other L's. Plus it is not printing the bars (forming the grid) as one long line but as two, moving from one bar to the next in the middle of each bar.

There is one thing I would love:

A calibration print, e.g. 3/6/10mm round colums+round holes+quadratic boxes+quadratic holes.

Measure it, input it to the slicer and get perfect scale prints.

Atm I have adjusted my lua/stl for Cura, and if I use something else things go wrong a few 1/10mm.

Is there a public repository?

I'd like to put these files on my octoprint, just to be able to slice offline as well. Maybe someone would even write a plugin for octoprint. Because it is really fast,  faster than Cura on my PC and 100x faster than the existing Cura plugin for octoprint.

[sylefeb]

Hi Maze,

I pushed an update which should fix the silly moves. What happened is that the toolpath planner tries to avoid traveling above holes (to minimize stringing) and has a quick algorithm to do that. In this particular case the algorithm results in this 'comb like' motion. These extreme cases are now detected and replaced by a straight motion => I will implement something better though, as this might indeed produce a bit of stringing in such cases.

Circles vs L: it will likely still produce the same pattern, but I see what you mean and this is something I have been wanting to work on for some time => added to the todo list :)

Bars vs Cura: the new slicer has a special mechanism to deal with thin features that should give it a significant advantage in all such cases.

Calibration: excellent point, I'll definitely think about this. The main difficulty is to relate the measurements on the part to the correct internal parameters (flow, nozzle width, small features vs large features, etc.), but that is worth a try.

Public repo and offline version: These are not available yet, but we are considering these possibilities. I looked into octoprint a while ago, I believe it would be possible to send the gcode directly to an octoprint server (instead of saving to a file). Do you think that would be a good feature to have?

Best,
Sylvain

[Maze Mietner]

Hi Sylvain

Well, for the calibration I think you would have to adjust the path, because

-the nozzle size is usually quite accurate

-lowering the flow rate doesn't give thinner walls, but weaker walls with little gaps. That shouldn't be modified.

I'm not sure if your slices takes into account the printed walls are always a little bit thicker than the nozzle diameter. Normally it should do this, based on volume flow. Maybe you could add an option to allow users to edit this value, as I'm pretty sure it is different for ABS, PLA and every other material.

I just mentionend Cura as it is widely used and available for a long time, and I just found it had similar issues. Not to mention it crashes quite often, while IceSL and slicecrafter didn't crash for months now.

OctoPrint: I wouldn't do any integration into octoprint, but rather suggest to go for a standalone (node.js-served) application, coming with a simple API. (Of course it would be nice to have such a feature, but integration with octoprint is needed to get the API authentication tokens to work with the octoprint API. Then, users will ask you to pull the printer parameters from octoprint as well....and things get very complicated soon. Or think if octoprint would change its API or file structure you'd have to change as well). As long as it is a standalone application it is ok to enter printer parameters here as well, and if it has an API users can integrate it into octoprint if they want to.

Btw: Can you add a button to save the gcode file (At the moment slicecrafter and IceSL ask you to save the g-code directly after slicing, before showing the visual result. However I usually want to check the visual output first, then eventually save only if everything looks ok)?

I'll test the slicer again...

maze

[sylefeb]

Hi Maze,

I just pushed a new version of slicecrafter with a revised ordering of paths. This will give you the 'circles' in all cases. That ended up being a rather big change and it is still a bit fresh, please let me know if you spot any issue while testing.

Thanks for the info on Octoprint, and these are good points regarding calibration. Noted for the save button!

Sylvain

[Maze Mietner]

Tried it, and it looks ok.
Another issues, this time regarding infill: it looks like you're using the same infill method that you use for large infills also for small gaps too. Two observations:
-The infill is printed first. On the 1st layer it it is very unlikely that it will stick to the bed. Printing it last might be a better option.
-It might give better (and faster) results if the gap between two adjacent lines would be filled by a third line (with the amount of filament depending on the distance between the two lines)

[sylefeb]

Hi Maze,

I pushed an update that fixes the order of infills and perimeters for this case. I have been testing print quality today and made a number of improvements.

There are different types of dense infills in slicecrafter, and the one that was printed first is the 'gap filler'. This fills the gaps left when creating a shell by erosion of the previous contour -- that part is quite different from what I was doing in the previous version of IceSL. For some reason I was printing them before the perimeter, but I also found that this sometimes damaged surface quality (plus the problem on first layer).

> It might give better (and faster) results if the gap between two adjacent
> lines would be filled by a third line

I agree that would be great to do whenever possible -- detecting such cases is actually quite difficult (but I had that in the previous version, I'll think about  it as processing is done very differently now).

[Maze Mietner]

> It might give better (and faster) results if the gap between two adjacent
> lines would be filled by a third line

I agree that would be great to do whenever possible -- detecting such cases is actually quite difficult (but I had that in the previous version, I'll think about  it as processing is done very differently now).

Somehow the slicer detected this case already. At the "picture processed_1.2.png" you can see two lines in the direction from the upper left to the lower right corner that are straight already. I hope the infill is adjusted to the available space, not trying to squeeze in a line with 100% width into the small gap. I didn't slice anything on the new version yet, that picture is from the previous version.