I’m trying to print the part shown in S3D 3.0.1, pictured on my standard 8-layer solid adhesion platform. Only the front end at the top of the image and the sides reach down almost to the adhesion platform. The back end is open, as is the entire underside.
Using a 25% support fill with alternating 45 and -45 degree layers, this print fails reliably and repeatably the same way. At some hours into the print, noted on the second image as height “A”, support material stops printing entirely. Some time later noted at height “B”, the remaining layers of part geometry start to print offset in negative Y about 6 to 8 mm and the printing of support material resumes, leading of course to a hideous mess. This is what the part looks like after the mess is cleaned off it.
So if I change the support style to 0 degrees and 30% – which I had wanted to avoid because I know the sheets of support material will warp – and cut the scale by half, the part prints perfectly.
I tried to print this version at full scale, with 0 degree support webs, and the print failed again.
Interestingly, support material stopped printing at precisely the same place as when it was crosshatched. However, when support printing resumed, the remaining geometry did not displace.
Because the part fails reliably when scaled up, I’d be inclined to suspect an STL error. However, I’ve run every STL check I can find and there’s no record or indication of unwelded verts, reversed faces, duplicate edges or faces… nothing.
I had suspected it might be a USB communications error, but I’ve set S3D’s timeout to 30 seconds and fiddled with timeout on the PC’s side too. I have noticed, however, that the S3D timeout value changes back to the default 10 seconds every single time I open Process Settings. I don’t think that’s supposed to happen, so I have no way of telling if it’s actually being set to 30 seconds.
I was printing from the PC over USB. My USB cable is premium quality, and my computer is fast, fast, fast with USB regularly used for instrumentation and data collection. If it were a random communication glitch, I wouldn’t expect the print to fail in precisely the same way each time.
