Hey all,

We've developed some in-house software which utilizes the EPDM/SolidWorks API to find an assembly by part number, loop through its BOM and find correlating drawing files for every part in the bill of material. We then grab the drawing file, load it into SolidWorks and export it as a PDF to a network location. Our ERP software then consumes these PDFs for preview and printing. We are essentially generating all of the drawings required to manufacture a given order.

We have found that there is a slight bug in the software we have developed where the incorrect bolt configuration is called for in the BOM table on the drawing itself. The assembly drawing contains a reference to 'hex bolt_ai.sldprt' - a tool box hex bolt part; the assembly calls for a specific configuration of this bolt. We have found that when the drawings are generated from our system, the bolt that is called for is the system default configuration of that bolt (the '@' configuration). However when I analyse the computed BOM of the assembly, it is truly calling for the correct configuration (a 2 1/2" length configuration) while on the drawing, it is calling for the incorrect and default configuration (a 1 1/2" length configuration).

I have reviewed the code and ensured I am getting the latest version of all files and that the configuration is correctly passed around. I have added extra code to try and show the requested configuration and do a rebuild on it - no success. In some reading on OpenDoc6 API method, I found an interesting note on the "Configuration" parameter:

"Configuration

Model configuration in which to open this document

• Applies to parts and assemblies, not drawings
• If this argument is empty or the specified configuration is not present in the model, the model is opened in the last-used configuration"

Originally we were not passing a value into this parameter, however now the system has been updated to leverage configuration wherever it is applicable. However, from the API documentation, it is noted that this parameter has no impact on drawings.

I have a feeling that it has something to do with the drawing's related assembly being in an incorrect configuration. I am, however, loading every single part/assembly in the BOM hierarchy (including the upper level part) with its referenced configuration (the OpenDoc6 API calls) and additionally requesting it to show the requested configuration (ModelDoc2.ShowConfiguration2()) and to rebuild that configuration (ModelDoc2.ForceRebuild(False)).

To make things a little bit more bizarre, I executed this system locally on my workstation; this is after I had opened the problematic assembly in SolidWorks. When the code is executed from my local system, the assembly drawing is generated with the correct reference to the 2 1/2" hex bolt. However, from the exact same code, when executed off of our server the assembly drawing is generated with the incorrect reference to the 1 1/2" hex bolt. This leads be to believe that it is not strictly a coding problem but also related to something with the machines it is running on. The only thing I can think of is that the assembly was first loaded on the server through API calls - at that time we were not providing a configuration, so it loaded the system default configuration which referenced the default hex bolt. Now that we are providing the configuration, I feel the assembly is not updating to call the new hex bolt.

Any help or suggestions on what to look into would be greatly appreciated. Is there an explicit way tell SolidWorks to refresh the BOM table on the drawing, request a specific configuration of a drawing (as OpenDoc6 notes configuration is not applicable when opening drawings), or debug why the BOM table is referencing this incorrect hex bolt? We are unable to open the file through EPDM/SW in any way that it displays this incorrect hex bolt reference - it is only when generating off of the server through the API.

Message was edited by: Curtis Watson (removed duplicate sentence).