You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I created a model of a mostly serial robot structured the following way:
main.sldasm
|- link1.sldasm
| |- part11.sldprt
| L part12.sldprt
|- link2.sldasm
| |- part21.sldprt
| L part22.sldprt
...
The origins and joint axes are located in the linkx.sldasm files.
In earlier™ versions of the tool and Solidworks, this made no problem. To the contrary, it allowed for the model to be structured in a logical way, and the coordinate systems only had to be defined in a canonical manner when finishing the subassemblies. We always created this reference coordinate system in the origin of the subassembly. The export then produced the STL files with the origin in the same origin as the subassembly, and everything worked out fine.
With the current version however, this does not work anymore. All STLs are now created with the origin set in the origin of the main assembly. If all files are loaded into blender, the robot is built together as it is in main.sldasm, opposite to all lying on top of each other with their origin in (0|0|0) (how it should be).
The text was updated successfully, but these errors were encountered:
This has been a known issue with SolidWorks in the past and is not related to a bug with the exporter. Generally, SolidWorks versions from 2018 are most affected.
Might be related to #87 and #103
I created a model of a mostly serial robot structured the following way:
The origins and joint axes are located in the linkx.sldasm files.
In earlier™ versions of the tool and Solidworks, this made no problem. To the contrary, it allowed for the model to be structured in a logical way, and the coordinate systems only had to be defined in a canonical manner when finishing the subassemblies. We always created this reference coordinate system in the origin of the subassembly. The export then produced the STL files with the origin in the same origin as the subassembly, and everything worked out fine.
With the current version however, this does not work anymore. All STLs are now created with the origin set in the origin of the main assembly. If all files are loaded into blender, the robot is built together as it is in main.sldasm, opposite to all lying on top of each other with their origin in (0|0|0) (how it should be).
The text was updated successfully, but these errors were encountered: