SolidWorks API Puzzles
The SolidWorks API is the most difficult programming I have ever encountered in my career. Is it that programming for 3D modelling is by nature complicated? Or is it that the SolidWorks API is a particularly horrible implementation?
Here are some of our programming puzzles from the SolidWorks API:
File: PVE-9627, Last Updated: Oct 11 2015, By: Laurence Brundrett
Getting the X, Y, Z coordinates of sketch points by macro is useful. SolidWorks has a sample macro on their web site. However, the routine provided only provides results local to the sketch plane. Here is a simplified version of the macro:
The problem is that the results remain the same no matter what plane the sketch is drawn on. The points in a 2D sketch are always relative to the sketches plane. Coordinate transformation is required to translate the 2D sketch coordinates into the 3D world. The macro with coordinate transformations:
PVE-8776, Last Updated: Apr 8 2015, By: Laurence Brundrett
Finding the correct interfaces and members to use with the SolidWorks API can be very challenging. For amusement I recorded most of the steps I took solving a programming challenge: how to expand and contract folders in the SolidWorks feature tree.
Naturally enough, I first tried the macro recorder, but it came up blank.
Needing to start somewhere, I looked through the feature tree to determine what type of object the folder is? The results “FtrFolder” I actually knew the answer was “FtrFolder” already, this is one way I could have found this out if I didn’t know. Is it possible to select the folders? With the “FtrFolder” type the answer is yes.
That turned out to be a dead-end. The folder could be selected, but I could find no way to expand or collapse folders from the IFeature or IFeatureManager interfaces.
I found the ITreeControlItem interface, probably by searching the help files for “FtrFolder” and following some links. This is an extract from a sample found in the help file. Note the folder is now called a node of the feature tree, but other items on the tree are also nodes. Items in nodes are Children. The process starts with a TreeRootItem. It uses a recursive call methods to access all children nodes.
I made a simplification of the SW sample. If a folder “N2” is found at the main level this routine will expand it. Partial success. However it will not collapse the folder.
Here is another dead end. Main3 above is simplified. It will expand all main level nodes if swChildNode.Expanded = True, but will not collapse the nodes if equal to false.
But the sample code from the help file can expand and collapse nodes! The answer is probably that the .Expanded member only works to collapse nodes at the root level. It can expand at any level. When the root node is collapsed all children nodes are also collapsed. Here is a routine that works (It is written to be called from a routine that already declared the swModel and swFeatMgr.)
Here is one solution for expanding the folders I need. It simply looks at the node text. If a match is made, it is expanded. My folders are always a child of the root node, so no traversing of children or children of children is required, and no identically named nodes will be found. When done I have to use the CollapseAllNodes3 routine. Again it is written to be called from a routine that has already set swModel and swFeatMgr.
Here is a safer way of expanding a node, if the node to be expanded exists at any level of child, and more than one node might have the same text. Here a feature is passed and the full name of the feature is used to ensure that the correct node is expanded. This routine only looks for nodes at the lowest level so this would not be an issue. Again it is written to be called from a routine that has already set swModel and swFeatMgr.
A few more steps were involved that are not shown here. Looking back I do not know how all the steps were taken, perhaps because it was not all logical – some guesswork and intuition were involved which remains a fuzzy process. All the required information was found in the API help files, but getting at it was not always easy.
The destination is not the one expected, but it works.
SolidWorks File Format
File: PVE-4631 / PVE-9259, Last Updated: Aug. 24, 2015, By:LRB
Background – Which Files!
SolidWorks Simulation (SWS) results are stored in a proprietary *.CWR format. SWS creates intermediate files during the analysis and combines them in the CWR file at end of run. SWS uses the standard Microsoft IStorage interface to create the CWR file, so it is possible to open the CWR file with the stg file examiner (formerly available from Microsoft Support).
It is not necessary to extract the files from the CWR container file. Setting the save intermediate files in SWS prevents the above files and more from being erased after a run. The above list shows which files from the many available are important!
Most of the files are in proprietary binary format; a few are text providing SWS run time messages. The order of execution can provide useful information on the file contents. FEA programs solve for displacement before stresses, so file time stamps can hint at what will be in a file. A large FEA run provided the following approximate run sequence:
ELF -> LCD -> EFF -> OUT -> STE -> GEN -> MAS
All dimensions and stresses are stored in metric: m and N/m^2
ELF File Format – Element Flexibility? – File #1
The ELF format contains node ordered data. This file type has been examined for models with 3, 4, 6 and 10 nodes per element. The file contains data for 6 degrees of freedom for each node, whether the degrees of freedom are required or not. Plate models use 6 degrees of freedom per node, solid and axisymmetric 3 degrees per node. The data start point changes with the number of nodes per element. Data is in single precision.
See the macro “ExamineELF” in the attached spreadsheet ELF File Examiner to examine data in 3,4,6 and 10 node per element models. Other node counts have not been tested. These macros use an array write command that cannot process huge files – make sure all of your data is imported before using.
LCD File Format – Displacement – File #2
The LCD file contains node ordered data. This file type has been examined for models with 3, 4, 6 and 10 nodes per element. The data always starts at 370h. The nodes always have 6 degrees of freedom, required or not.
See the macro “ExamineLCD” in the attached spreadsheet LCD File Examiner to examine data in 3,4,6 and 10 node per element models. Other node counts have not been tested.
This data exactly matches the results from the Displacement listing.
EFF File Format – Unknown – File #3
The purpose of the EFF file has not been determined.
See the macro “ExamineEFF” in the attached spreadsheet EFF File Examiner to examine data in 3,4,6 and 10 node per element models. Other node counts have not been tested.
OUT File Format – Solver Messages – File #4
The OUT text file contains a plain English language report.
STE File Format – Stress and Strain – File # 5
The number of nodes per element, and if the model is a shell or solid is required prior to reading the STE file. The STE file contains stress and strain data per node per element. The stress for a node is the AVEARAGE of the stress for that node in all elements that it occurs in.
As an example, we use this data for our linearization program. For each node on the linearization line, we average the stress for that node as reported by all elements that connect to it. All other nodes are ignored.
See the macro “ExamineSTEFile” in the attached spreadsheet STE File Examiner The spreadsheet has been tested for 3 and 6 node per element plate models and 4 and 10 node solid models. Other node counts have not been tested. Enter the nodes per element and “plate” or “solid” options in the spreadsheet before importing the file. This macro does not contain array fast write methods, so large files will take a while to examine. The results will not match your stress plots until all nodal occurrences are averaged.
To examine Axis-Symmetric models, set the correct number of nodes per element (3 or 6), but set the plate/solid option to SOLID.
GEN File Format – Original Node Coordinates – File # 6
The GEN binary file contains nodal coordinates prior to displacement in meters. Number of Elements is stored at 18Ch and the number of nodes at 190h. Data starts at 408h. Each record of singles is X, Y, Z and followed by 10 unwanted singles.
See the macro “ExamineGENFile” in the attached spreadsheet GEN File Examiner. No difference in file format has been noticed for 3, 4 or 10 node per element files.
MAS File Format – Unknown – File # 7
Data blocks are long – contents are unknown.
We developed this access method because we had difficulty getting raw data out of SWS. SWS provides a series of API function calls to access the data in open files. We tried that method and it took hours to get data out of a large file. SWS also has a series of export data commands in the drop down menus. They also are slow – it would take up to 10 hours to export the data from a large FEA run. We successfully used this file format information in VBA to extend our stress linearization spreadsheet to directly access the CWR file results. We can get at the data we need quickly and easily.