I loaded the stl file, enlarged it slightly to 1.15% and started it printing. I checked before going to bed to make sure it was working. The raft and first layers of the print looked fine. This is what I found this morning when I checked it out. Note the missing support in the spiral which caused an ugly failure in the print.
No, I did NOT check the No Supports option in the print Preferences. So now I have the opposite issue that I had before. No supports are being incluced where they are obviously necessary. This is why it is imperative that Cetus add supports to the preview. Now, before every print that may require support, I have to stop and ask myself "Do I want to potentially waste time and filament on an experiment to find out if the software will do what it needs to do?"
Cetus,
You have the link to the item in Thingiverse. You can download it yourself and see if it works for you. After loading the stl file I did enlarge it to 1.15%. Please tell me that scaling an stl file doesn't break your software. I am running this on a Mac. Is this another case where the Mac software is broken? Is your software only going to include support from the build platform? Without support showing in the preview there's no way for me to know just what the app is going to do.
Thank you
P.S. I have no idea why the forum inisists on inserting a laughing face at the start of that last paragraph. I did not include it in my post.
Can't help on the support issue but for some reason using words that start with a capital "p" results in the laughing face. At least that's what I've found.
I used Cetus on my PC and it appears to be incuding supports so this is likely a bug in the Mac version of the software. Note the extra raft on the right and the beginnings of supports on top. That wasn't there on the print from my Mac.
There is no support preview on the Mac or PC version. The specific model I was working with required an additional piece of raft to go under the support which made it obvious in the preview that support was going to be generated. The support itself does not show up. I wish it did. As it stands now the only way to figure out if your support settings are getting what you want is to print the piece and see what you get.
[quote][size=2][color=#999999]cyberhugger post at 2017-2-8 21:26[/color][/size]
There is no support preview on the Mac or PC version. The specific model I was working with required …[/quote]
How do you manage the settings for the LokBuild surface? Can't get a good print without raft (have the same issue without the LokBuild) the printing start too high...
I've tried several calibrations in order to adjust the height and nothing works for me, I've just seen "nozzle offset" maybe I should give a try?
I have not been able to get consistent results from the Cetus for raft-less prints. Sometimes it seems to work and sometimes it doesn't. The only way I can get close is trial and error on the nozzle level. If the part doesn't stick then I go into the calibration stuff and lower the height by just a tiny bit and try again. I'm talking lowering (increasing the number) by 0.05 or less. You can't do that with the +/- keys. You have to actually enter the number. A heated bed would help a lot so keep hoping to see that as an option we can get. Without a heated bed you're going to be limited to relatively small prints if you don't use a raft.
One thing that I did find that helps is to make sure your LokBuild is really clean. I wipe it down with a microfiber cloth before a print just to make sure I'm not printing on top of some dust or finger prints. I haven't tried to clean it with alcohol yet but that might help too. Don't use anyting higher than about 70%.
Not sure how I got to this thread, but since I’m here , I’ll add my 2 cents…
The main reason this print failed is because the stl file is NOT suitable for printing using a slicer without advanced stl file error-detection and repair functions. The stl file, as linked at the beginning of this post, is seriously flawed at exactly the point-of-failure shown in the picture.
Scaling the stl file will amplify the flaws.
It’s unfortunate, many stl file repositories do not employ proper stl file quality control…it’s a cost that is mostly unrecoverable, so they rely on the authors to submit error free content.
Also unfortunate, Tiertime and their product’s are noted as the root-of-the-cause of this print-failure… when most definitely the stl file IS the root-of-the-cause.
edit: I should also note that I cannot connect the stl-file errors with the lack of supports where needed…heck…this post is 2 years old…who knows what the slicer software was doing back then. My point here is… stl files should be checked for error-free geometry before use in 3D printing processes, and that is the responsibility of the author… and ultimately the user when asking for support when connected to an stl file.
Cetus need to include an auto check on loading a file to see if it needs repairing.
For models like this can you chuck the model into MeshMixer (not sure on platforms it is available), you can generate branching type supports in MM and export to a complete model containing needed supports, plus it can analyse and repair problem objects. It’ll get you a printable object at least. I use this approach for complex medical models where the cetus supports can interfere or cause damage removing them.
@sil , tks for chiming in here…I also use Meshmixer. I primarily used Netfabb prior to Autodesk’s acquisition, Autodesk has an impressive list of tools for digital design. Rhino3D is my tool of choice for 3D CAD and always check the geometry throughout the design process to catch any flaws before they become unruly. Just love using Grasshopper! I use tolerances of .0001mm and loosen to .001mm when needed…for extremely complex geometry I sometimes use a .01mm tolerance. I have found using extremely tight tolerances as the normal and then loosening to make things work, I rarely experience stl file errors. I know .0001mm is waaay overkill, but I’d rather loosen than have to rethink/redesign the desired geometry!
Personally I avoid using CAD as a term, to me its 3D Modelling. But I guess today I should move to CAD, when I started in the mid 80s using computers to make 3D objects for various purposes the two were distinctly different. My path led to the rendering path instead of gaming or manufacturing and so my software of choice remains Lightwave3D. My licence is a couple of versions behind before home 3D printing became a market. As a result my LW can produce models not manifold for printing. My experiences indicate the common way problematic objects get created by any program is when using boolean operations where two objects are added,subtracted, intersected, etc. I combine Lightwave with Tinkercad to produce STL files which are clean to print. Tinkercad does great job just taking an imported wavefront OBJ file and immediately able to save a clean stl with no work needed. I suggest anyone using a modelling program that sometimes produces failing files to try this trick. For me I’ve pinned it down to the boolean tasks in Lightwave at fault but being able to import and export OBJ files in both LW and Tinkercad means when I need to use those i can take my files between the two programs freely.
My point about cetus adding an auto stl check on loading I maintain is needed in all slicers as its clear people rarely bother to try printing their own objects before uploading to places like thingiverse which means we download expecting a printable model and waste material finding out its garbage. It should be an obvious courtesy that slicers and printer control software auto check loaded files to help their customers out. But its not likely to happen if they dont see an obvious short term profit to do such good.
I suspect you are right about boolean operations for some programs. Rhino3D will not allow boolean to run without spot-on geometry when very high tolerances are used …it will give hints to where geometry errors exist. I run boolean operations mostly when I’m close to finishing a model, otherwise I’m using simple join commands so I can easily back-out. Either way I’m running a quick mesh command to confirm clean geometry throughout the design process. I cannot remember the last time I created an stl with errors.
Back in 2013 when I joined 3DHubs they were using Netfabb when files were uploaded, but even then flawed stl files would get through, I suspect they were using a less expensive license.
One of these days, error-checking and a “done” authentication stamp will become part-of custom-branded slicers stl-file-loading requirements if the slicer program doesn’t have stl-file error-checking, either that or they will get very tired of being blamed for print-errors and spend the cash to include a module like Netfabb in their slicer for their printers.
, I’ll add my 2 cents…
…it will give hints to where geometry errors exist. I run boolean operations mostly when I’m close to finishing a model, otherwise I’m using simple join commands so I can easily back-out. Either way I’m running a quick mesh command to confirm clean geometry throughout the design process. I cannot remember the last time I created an stl with errors.