7 Replies Latest reply on Aug 8, 2018 11:18 AM by Chris Vos

    Solidworls changes part orientation on saving as STL

    Chris Vos

      I've been having this strange issue with saving parts as STL files since using SolidWorks 2018, and I finally remembered to make screen captures so that I can ask about it here.

       

      This issue crops up roughly 40% of the time when I save a part as an STL file and it is driving me mad, because the only way I have found to 'fix' it is to close down SW and open my part again, so I hope someone here may be able to shed some light on why this is happening and what I can do to fix it.

       

      What happens is this: I regularly export files as STLs for 3D printing purposes, and because SW has the y-axis as up instead of the z-axis up like most 3d-printers have, I have learned to insert a custom coordinate system that has z-up that I can use as the output coordinate system when saving as STL.
      This used to work flawlessly in SW2017. In SW2018 however, seemingly randomly, SW decides to change the orientation of my parts as if this custom coordinate system was the default coordinate system before saving the STL. This causes the bodies in my part to visually change orientation and outputs an STL in which the parts are still oriented the wrong way. So it negates my fix for correct orientation for 3d-printing and forces me to open the STL in another program and rotate the parts to the right orientation manually, which ads unnecessary extra work. I have noticed that the first export with the desired output coordinate system selected after building or opening a SW part file always works as expected, and the issue only happens on subsequent STL exports from the same file.

       

      SolidWorks_Issue_STL-Export_01.png

      SolidWorks_Issue_STL-Export_02.png

      SolidWorks_Issue_STL-Export_03.png

       

      About half the time this issue happens, after I save the STL with the parts mover around, the parts even keep being displayed as having changed their orientation in the SW main window. Because everything is displayed in the wrong position though, this prevents me from being able to work on the part any further. If I then mouse over the construction steps in the feature tree, I do get to see the orange edges preview of the parts in their correct orientation. So it appears that SW does 'know' the correct orientation still, but displays the parts as if the second coordinate system is now the default. (I don't have screenshots of this right now.) This is sometimes fixable by going into one or more features and okaying out of them again, or changing some value for a feature and then okaying out. But often the only way to get my correct display back I need to exit SW completely.

       

      Does anyone know what could be happening here and what I can do to prevent this in the future? As I said I haven't found any clear reason for this happening and it appears to happen quite randomly but far more often than is good for my sanity. (Maybe a bit more with more complex parts, but as you can see from the screen shots above, pretty simple parts also get messed up like this.)

        • Re: Solidworls changes part orientation on saving as STL
          Paul Salvador

          Hello Chris,..just curious.. can you do a test?...export as parasolid using your coordinate system.. open the x_t and saveas STL... does it work?

            • Re: Solidworls changes part orientation on saving as STL
              Chris Vos

              Hi Paul,

               

              I tested as you suggested. Exporting to parasolid using my custom coordinate system and then opening again in SW shows me the parts oriented according to the custom coordinate system. (Which I think is the correct expected behavior.) Then saving this as an STL with the default coordinate system as reference gives me an STL in which the parts are oriented the way I want (z-up). I have tried twice and in both cases the export orientation did not mess up when exporting to parasolid with the same model that does mess up export to STL.

              So, what does this tell me?

               

              SolidWorks_Issue_STL-Export_04_parasolid.png

                • Re: Solidworls changes part orientation on saving as STL
                  Paul Salvador

                  Hey Chris,.. it was a guess and workaround I have used and you may need to use.

                  When I saw you used Move/Copy, it reminded me about some problems I've had using "Move/Copy" (mainly using Insert Part.. and the orientation would be incorrect!?).

                  Yeah, not sure what this tells you/us much but I wonder if this is a new Move/Copy bug.. or something else somebody maybe aware of.... anyone know?? 

                   

                  ..and,.. the next guess was related to STL exporting in the Positive XYZ Space... that is, could the other body in the negative space be moving/flipping to move into the Positive space?

                    • Re: Solidworls changes part orientation on saving as STL
                      Chris Vos

                      I wasn't aware of a known move/copy bug, but I thought I'd try if the move/copy features had anything to do with it. However even with the move/copy commands deleted from the tree my part still gets flipped when I try to save as STL for a second time (or third, or forth, etc.). First time still works as expected.

                       

                      SolidWorks_Issue_STL-Export_05_NoMoveCopy.png

                       

                      I am not sure what you mean with your description of the next guess, but thanks for trying to help me figure this out!

                        • Re: Solidworls changes part orientation on saving as STL
                          Paul Salvador

                          Chris... "positive space"... sorry, I did not explain.. as another test, in the STL Options,.. check   "Do not translate STL output data to postive space" and see of that works?  (image attached)

                          pos-space.png

                            • Re: Solidworls changes part orientation on saving as STL
                              Chris Vos

                              I tried checking 'Do not translate STL output data to positive space', but when I do SW flips my part 180 degrees when saving to STL instead of the 90 degrees from before. (So in the preview the shape ends up below the top plane in the example image below.) So this setting clearly does something, but still not what I would expect. It displays like this regardless whether I use the default of the custom coordinate system as reference for output. The STL file I end up with is oriented the same way as the other erroneous outputs, not oriented z-up but at 90 degrees flipped to this.

                               

                              SolidWorks_Issue_STL-Export_07_PositiveSpace.png

                            • Re: Solidworls changes part orientation on saving as STL
                              Chris Vos

                              Trying without move/copy in the tree made me think that this issue may be related to one of the other features I used, so I decided to try with a new file with a minimum of features used (simply an extruded hexagon), and even here the issue arises when I try to save as STL more than once after making the part.

                               

                              SolidWorks_Issue_STL-Export_06_basic.png

                              SolidWorks_Issue_STL-Export_06_basic2.png

                               

                              I think my SW2018 may actually have this issue with every part, but the reason that I only noticed it about 40% of the time before is that I don't always save the same part as STL multiple times. (I do save the same part to STL multiple times quite a lot when working on a part with multiple variations that all need to be 3d printed, but not always on the same day/without closing the file and/or SW in between.)

                               

                              Could someone else try to replicate this issue? I have attached the basic example file from the screenshots above.