STL files

I recently tried to use an STL file created with the V16 STLOUT in a 3D printer.  The printer's software will not accept the file, though it works well with STL files created with other CAD software.  I also noticed while working with this that Windows Explorer sees a BricsCAD-created STL as an IGES file but sees all other STL files as STL.  The BricsCAD-created STL files are viewable in generic STL viewers.

Has anyone else had success using BricsCAD STL files for 3D printing?

Comments

  •  I use Ver 15 and communicator and export successfully on a regular basis to STL for use with a 3d printer.
  • I will mention one possibility.  If you have the file type extension turned off in Windows, but have the STP as part of the name, it may look like a STP to you, but windows is only looking at the last part after a period.  E.g. myfile.stp,iges may display as myfile.stp if file extensions are off.

    -Joe
  •  Which printer/firmware/slicer is having problems? I routinely use BricsCAD to create STLs for slicing with Simplify3D (S3D) and have used them in Slic3r, RepG, Makerware, and FlashPrint.

    I usually go the menu route as File | Export | Save as type | Lithography (*.stl), which creates a binary STL, identical to using STLOUT with the default binary option. Non-binary (ASCII) STLs also work in S3D but I haven't tried them in the other slicers.
  • Joe Dunfee: My file type extension is turned on - it drives me crazy to not be able to see file types.  But I have seen that happen on other PCs.  I am sure that these files are truly STL.

    Richard Webb: I was originally using Cura because a copy of it came with my printer.  Yesterday I installed Slic3r, thinking the problem might be in Cura, and got the same result.  It's interesting that you are not getting the same results with Slic3r.  If it was a single model, I would think that there was a glitch in it that was causing problems, but it's every BricsCAD-generated model.  I have exported STLs both from the menu and from STLOUT, with the same result.  Are you using a 32 bit or 64 bit BricsCAD?

    I have also tried STL export from older versions, thinking that it might be an issue with V16.  I was considering sending a support request but probably won't since you have been successful with Slic3r.
  •  Curious. I'm running the 64-bit version, although I do have the 32-bit installed just in case I need the VBA capability (which I haven't for many years, so I really ought to just drop installing that one).

    Attached is an STL that I did yesterday for Ninjaflex 50 g sample spools. No drama at all. Just checked it on Slicer 1.2.9, too, in addition to my usual S3D setup. Original DWG also attached. 

    NS-1.stlNS-1.dwg

  • I'm using the same Slic3r version as you and 64 bit BricsCAD.  I will look at the files you posted tonight and relay what I find.

    I have also used my AutoCAD at work to export one of my BricsCAD models to STL, just to see what happens.

  • Richard Webb: now I am more confused.  The STL file that you posted behaves as it should in Cura; the STL that I created from your DWG file also makes a usable STL.  So that would mean that I am creating models that will not export correctly as STL.  I have, as a test, even created a simple solid disk - something that I know could have no un-sliceable features, and it could not be sliced in Cura.  I'm at a loss.
  •  Curiouser and curiouser. Here's a DWG from BC16(64) of a simple 10x10x10 cube and the associated ASCII STL. Take a look at both and then compare to an identical cube and STL created from scratch on your system.

    The cube's first point was 0,0,0 and second 10,10,10 so I was surprised to see a 0.01 offset on all of the points in the STL file. I assume that's to ensure that the object lies in the positive octant. The offset by (0.01 0.01 0.01) is preserved when the cube's STL is imported. Curious, again.

    Looks like the binary STL files have the same offset: i.e., a vertex at 0x3c23d70a which is IEEE-754 single precision floating point for 0.0100000. Hmmm

    Anyway, try starting with a new, clean profile via the User Profile Manager and, if that's good, try adding any startup template files one at a time.

    cube-10.stlcube-10.dwg

  • Multiple variables are involved when creating STL output. One of these, FACETRES, is stored in the dwg, which could explain some of James's issues.

    See also:
    https://forum.bricsys.com/discussion/24343
  • It turns out that this was all caused by my ignorance about slicing software and STL files.  When I tried using other template files, the first that I tried was the default metric.  It created an STL that the slicing software liked.  I then tried the default imperial template; it did not produce an STL that the slicing software liked.  It was then that I realized that the slicing software apparently assumes that all units are millimeters (and STL apparently does not specify a unit type as CAD files do).

    Because all the models that I exported to STL were small and in inches, they were seen by Cura as even smaller metric parts.  Cura defaults to certain standards like a .8mm shell thickness; because my imperial models were all less than one inch thick, I think that Cura could not proceed because it saw my model as less than the combined shell thicknesses.  Scaling the imperial STL files up solved the problem.

    Thanks to all that responded and eventually led me to understand the problem.  I apologize for not seeing this sooner.
  •  Yep -- happens a lot in the metrically-challenged part of the world. I remember the first part I sent out for prototyping, a long time before I had ever heard of things like "slicers." Just a simple, six-inch hemispherical radome with a few mounting holes. The online site's autoreview/autoquote came back with (paraphrasing) "Dude! That part is way the $#% too small to build." 

    So, I tried increasing the wall thickness.   ;-)  Took a while for the light to come on...
This discussion has been closed.