Weird alternate slicing on the same part when duplicated

[boxcarmib]

Here's what I get when I slice a single copy of the part.

Here's what I get when I drop a 2nd part onto the build plate OR do a copy and paste of the part and do a centre and arrange

Here's the only thing that works... copying the part and pasting it while in simplify 3D and NOT doing a centre and arrange.

Anyone have any idea what's going on here?

[boxcarmib]

Oh... and for those of you who want to try it out yourselves... here's the STL file...

ptj_mitre_gear.stl

(2.47 MiB) Downloaded 183 times

[wirlybird]

Try adding or subtracting a value of something like 0.000001 from the layer height and see if it helps.

Also make sure both parts actually are setting on the bed.

What does the first layer look like in the preview mode? Look normal?

[dkightley]

Try using the repaired shape file attached....

[boxcarmib]

In reply to wirlybird... minute adjustments to layer height have no effect... and yes, the first layer height looks fine.

To dkightley... thanks for the repaired shape file... what did you do to repair it?

I did a bit more looking around and see that at least historically S3D has had problems with unwanted bridging which is what this appears to be... and although dkightley has provided a repaired file, to my way of thinking this is clearly a bug in simplify3d... in that if it can slice a single copy of an object correctly it should be able to slice multiple copies of the same object on the same bed correctly. Maybe they'll get around to doing something about it in the next release.

Thanks for all your help!

[dkightley]

I used the Windows10 app 3D Builder to repair the shape file.


And regarding your comment that there is a bug in S3D, have a think about this....


You have two record players. One will play a cracked record, the other refuses to play the same cracked record. What is faulty, the record or the record player??

[boxcarmib]

I think I see what you're getting at but I believe it's a little more subtle than that. I think it's more like there's just one record player and one record... and you can only play the record once. If you play it a second time, then the player skips and jumps and makes a mess of it. Perhaps you may liken it to playing a dusty record (clearly one needs to be an old timer here... like what's a record player anyway? )... the player gets through it okay the first time, but so much dust has accumulated that if you start over again it just becomes too much for the player to handle. So to parse the analogy, the record player is S3D and the record is the STL file. Where does the fault lie? Is it failure to dust off the record before playing it, or is it failing to blow the dust off the needle after each play? To my way of thinking there's more of an onus on the player than the record in that there's no practical way for someone making STLs to determine if 'multi-plays' will cause problems... the example I provided fails on the 2nd play... but what assurances do I have now that it won't fail or the 3rd or 4th or nth play? To my way of thinking there's some failure in S3D to re-initialize a variable somewhere that's causing the problem and should be corrected. I would agree with you if we were talking about two STL files, one with a single object, and the other with two copies of it, but this is a single STL file with a single object and I think its reasonable to expect a slicer that provides for copy and pasting multiple instances of the exact same object that it should in turn slice any occurrence of it correctly.

[wirlybird]

I think the layer height adjustment was something DK found out that worked when S3D tries to add a "solid" top to an open area. It seems it can get confused to the exact height and using that minute adjustment it changes the calculation.

Doug can elaborate or correct me!!

[dkightley]

Nothing really to add to whirlybird's post...as he's quite correct.

The OP has made his mind up as to how and why the solid layer is being generated...and I do not feel inclined to try and change his mind. I'm busy 7 days a week at the moment, and getting home tired...and simply can't be bothered to argue the toss after advising the correct course of action to resolve a known and well documented (on here) issue with defective shape files.