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:

Point Coordinates

File: PVE-9627, Last Updated: Oct 11 2015, By: Laurence Brundrett

Screenshot 2016-06-28 14.38.42

macro to report the x,y and z coordinates of the points found in a drawing

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:

A model drawn of the Front Plane and the local results as reported by the above macro.

A model drawn of the Front Plane and the local results as reported by the above 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:

Screenshot 2016-06-28 14.37.45

Macro with added coordinate translations

Moving the sketch to the Right Plane is reflected in the global coordinates.

Moving the sketch to the Right Plane is reflected in the global coordinates.

Collapse Nodes

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.

FolderExpandedAndCollapsed

Before and After. The goal is to expand and contract the folders in the model tree

Naturally enough, I first tried the macro recorder, but it came up blank.

Screenshot 2016-06-28 14.43.46

Get a list of the nodes in the feature tree looking for the folders

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.

Screenshot 2016-06-28 14.44.19

Dead end

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.

Screenshot 2016-06-28 14.44.51

From the help files

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.

Screenshot 2016-06-28 14.45.20

A partial solution – the tree can be expanded but not collapsed

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.

Screenshot 2016-06-28 14.45.40

Another partial solution

Screenshot 2016-06-28 14.46.07

A strange way of collapsing the child nodes…

Screenshot 2016-06-28 14.46.25

An unsafe solution

Screenshot 2016-06-28 14.47.03

The final solution

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).

SWS_FileFormat_Image1

The above files contain all the data required to show all of the results plots from a FEA run.

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!

Set the above option flag under Simulation/Options.../Default Options/Results/Results Folder.

Set the above option flag under Simulation/Options…/Default Options/Results/Results Folder.

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.

General Comments

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.