Slicing bug - a missing layer.

[zapta]

I am trying to print a simple cylinder but Simplify3D misses one layer in the slicing (see picture) which prints two disconnected parts. The model passes all the mesh tests in Simplify3D and when I try to separate it into connected surfaces it stays as a single model. This is weird. I sliced many parts with Simplify3D and never had a similar problem.

Another wired thing is that if I raise the object along the Z axis by 0.01mm the problem disappears. (the object is well placed on the Simplify3D bed, using the drop model command).

It's not just a missing layer because Simplify3D actually slices them as two individual models, with the bottom one having top shell and the top one having bottom shell.

I am using version 3.0.2 on Mac OSX 10.11.14 (Macbook Air 11").

[img]screenshot.png[/img]

Attached is a zip file with the STL, FFF and GCODE files.

[dkightley]

A .factory file would be much better than a zip file full of individual files.

[zapta]

A .factory file would be much better than a zip file full of individual files.

Thanks. I was not aware of factory files. Attache is a factory file with this project. Can you reproduce the missing layer?

[dkightley]

I have a couple of solutions:

1) Change the layer thickness setting in your profile to 0.2001

or

2) Double click on the model and change the X rotation to anything other than zero. Try 1.00.

Both will result in a perfect slice!

Some will say there is an error in the model's mesh.....but I am beginning to think that as this seems to be cropping up too frequently and there's a very subtle bug in the slicer code that trips up on something, and causes a layer not to be resolved.

[zapta]

Thanks dkightley. Yes, this is what I noticed, a small change like the Z offset I mentioned earlier 'fixes' the problem.

This is clearly a bug because the mesh is correct and if it is incorrect, the Simplify3D mesh detection correction tools should detect and fix it. They don't.

This is probably caused by sloppy coding that is based on floating points and lossy operators (e.g. division).

Does Simplify3D response to bug report like this? Is it likely to be fixed? Seems to be a serious bug in the core functionality of this product.

[dkightley]

This is probably caused by sloppy coding .......

I think that comment is a little harsh. When there is the potential for a range of data to process varying from very little to huge amounts, ensuring that 100% of the possible scenarios are covered is very difficult to achieve......and almost impossible to test for!

[Wurstnase]

This missing layers is really nasty. Actually you need to control the complete slicing layer by layer to determine such issues.

[zapta]

This is probably caused by sloppy coding .......

I think that comment is a little harsh. When there is the potential for a range of data to process varying from very little to huge amounts, ensuring that 100% of the possible scenarios are covered is very difficult to achieve......and almost impossible to test for!

I saw more than one computational geometry algorithms that are implemented naively using floating point (vs fixed point or a dense grid of integers) and end up with inconsistency and corner case issues due to the lossy nature of floating points. Integer based implementations require more attention to details are are consistent and rock solid. That's what I meant. It's a speculation of course based on the the fact that any small change 'resolves' this corner case and the inconsistency between the model separation and slicing algorithms.

Edit: the model in this case is very simple, a single cylinder.