Slicing woes

[Mattasmack]

Hi, We've talked on the photonic3d forum about using Photonic3D with .stl files (vs. bundles of .pngs from Creation Workshop), but now that I've encountered what looks like an actual bug, I thought I'd take the conversation here.

The software is failing to print some fairly simple .stl files correctly and I don't know what is going on.

The file I tried to print is here: https://drive.google.com/file/d/0B7y_A8ddaez3VDhMcXI2eXRpb1U/view?usp=sharing It's two pieces that will be stone mountings in a jewelry piece I'm working on; I'm trying to print just these components out first to make sure they fit the stones before I finish the design of the whole thing.

This is how it came out: https://drive.google.com/file/d/0B7y_A8ddaez3d2gwUVRSMTFVXzA/view?usp=sharing The rectangular piece is filled in rather than hollow, and the right third or so of the circular mount is as tall as the other piece for some reason.

I normally run the software on a Raspberry Pi attached to my printer. To investigate I loaded it onto my PC and ran the slice browser on this .stl file ... and it looks just fine. So I don't know what's going on and I don't know how to investigate further. I've tried printing two different versions of this file with slightly different dimensions and both had the same error.

Log bundle is here: https://drive.google.com/file/d/0B7y_A8ddaez3dEJzUGhwOFBmaVU/view?usp=sharing

I've printed one other design from .stl successfully.

Any ideas?

[WesGilster]

Wow, that's disappointing. I just quickly ran your model through a few slices and everything looked great.

Using the on screen customizer I took a quick peak at slice numbers 14, 74, 109.

You'll probably notice that each of those numbers corresponds to a change in the vertical structure of your prints. 14 is the last slice of the base for your stone mount 74 is the last slice of your stone mount. 109 is the last slice of the cube structure.

All look perfect from a slicing standpoint, which is what I initially thought was the problem. Next I'll need to take a look at your log file.

[Mattasmack]

Log bundle is here: https://drive.google.com/open?id=0B7y_A8ddaez3dEJzUGhwOFBmaVU The print was yesterday and I grabbed the bundle just a short while ago, but I haven't done anything else with the printer between yesterday and now so there is hopefully not too much irrelevant stuff in the logs.

[WesGilster]

Logs in Photonic3d work through a gradual escalation and cleanup process based on factors like size and date. That means when the current file(cwh.log) is too large or the next day arrives, the logs get rolled into a zip file. Then after 5 rolls, the oldest file gets deleted. This helps keeps keep your disk tidy and doesn't allow it to fill up your disk due to logs. The log bundle downloader only pulls cwh.log though and none of the other log files on disk. Since a day went by on this, the logs rolled and I didn't get any information about your print. In fact, there are only about 8 lines in the cwh.log file. Could you manually download the files from the Raspberry pi and attach them here? They will have the format: /opt/cwh/cwh-01-26-17-22-41-59-1.gz

I'm also manually running your print to see if I can see any funky business going on there...

[WesGilster]

Did you use any customizers or image manipulation calculators with this print? I'm having some trouble reproducing this problem when I print it manually.

[Mattasmack]

Aha, here's the previous day's log.

I didn't use any customization on this print. I did on the other print that came out successfully; I used a customizer to print three copies at once. Incidentally, when I printed that one Photonic3D seemed to skip the startup gcode, though it executed all the per-layer code as expected.

cwh-01-26-17-21-22-59-1.log.gz

[WesGilster]

I fixed the problem when skipping the gcode header on using customizers. This was happening because customizers allow you to restart a print from the last point that you left off. This would mean of course that the header would need to be skipped. Unfortunately, this was happening on every print that used a customizer. Still looking into your print issue though...

[WesGilster]

I fixed an insidious little repaint bug that certainly could explain the main problem you are describing. It would even describe why both parts printed at the same height and why the box printed solid. Since I haven't been able to replicate those drawing artifacts, I can't be sure that it fixed your specific issue though. This has been released in development.

[Mattasmack]

I'll give it a shot! Not sure if I'll be able to try a print today, but will do so ASAP. Thanks!

[Mattasmack]

That fixed it! The print came out perfectly this time.