6 Replies Latest reply on Oct 9, 2014 8:37 AM by Curtis Watson

    SW/EPDM API, Issues with Drawing Configurations

    Curtis Watson

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

        • Re: SW/EPDM API, Issues with Drawing Configurations
          Curtis Watson

          I'd like to add that when I log onto the server (where we experience the issue when the drawings are generated from it) and manually open EPDM, find this drawing and open it, it appears correct on the screen. It is only when we generate this drawing through API calls do we experience the incorrect bolt configuration reference.

          • Re: SW/EPDM API, Issues with Drawing Configurations
            Jim Sculley

            Is the code running on the server using the same login credentials you are using to perform testing?  If not, is the vault view on the server set up so that the same vault view is used by all users who log in to the server?  If the vault views are separate, and you aren't logging in to the server with the same credentials that the code uses, the code's vault view may be different than yours and you would never know it.

             

            Incidentally, wouldn't it be much easier to maintain a PDF directory where PDFs are generated by the users when the SolidWorks drawings are ready to go then simply grabbing those as needed.  Making them on demand, every time seems like a waste.  I wrote an add-in here that simply looks for SW drawings entering the Approved state (when users perform transitions) and then generates a PDF at that point (from the same client machine, where the drawing is guaranteed to be up to date).  If drawings are revised, the PDFs are regenerated when the revisions are approved.  The PDFs are then available for consumption by other groups in the company and are always up to date compared to the SW drawings.  No server code necessary.

             

            Jim S.

              • Re: SW/EPDM API, Issues with Drawing Configurations
                Curtis Watson

                Thanks for the reply Jim.

                 

                That idea was proposed after we had completed this approach - agreed it sounds like a much simpler solution to the case. Since we were unaware of any problems with our approach, we continued to utilize it rather than investing further time into the solution. We might need to reconsider this however moving forward.

                 

                As for the vault views - there is a single vault view installed on the local hard drive of the server. All users that log into this server access the same vault view. In my testing, I utilized the same EPDM login to access this vault view so that vault security, etc. was not a factor in the testing. So, the same vault view and same login credentials are being utilized.

                 

                In regards to generating drawings upon approval - how did you handle the roll out of this? Obviously moving forward, drawings would be kept in sync and updated. However, we would need some sort of batch to generate these PDF drawings for all existing drawings?

                  • Re: SW/EPDM API, Issues with Drawing Configurations
                    Jim Sculley

                     

                    In regards to generating drawings upon approval - how did you handle the roll out of this? Obviously moving forward, drawings would be kept in sync and updated. However, we would need some sort of batch to generate these PDF drawings for all existing drawings?

                    I have an add-in where I put all sorts of utility functions for things like this.  I run it only in Debug mode so that normal users never see the various commands.  One command simply creates a PDF for the selected file (or files), transitions it to the proper state and synchronizes the PDF revision with the source drawing revision.  Our workflow didn't have the auto PDF generation code in the beginning, so once it was added, I had to go back through all the existing drawings and generate the PDFs.

                     

                    Jim S.

                • Re: SW/EPDM API, Issues with Drawing Configurations
                  Curtis Watson

                  I got in contact with my VAR - we set up a GoToMeeting and did some brainstorming. All-in-all it seemed that all of the code was correct but there was something with the 'hex bolt_ai.sldprt' file that was out of the ordinary - other parts in the BOM table on the drawing, which also rely upon configurations, were displaying the correct configuration. It was just this hex bolt giving us problems...

                   

                  I felt that there was something conflicting or the file was locked and could not be updated correctly - I was making calls to get latest version and to explicitly show/load a specific configuration... it wasn't working. I asked the VAR if there was a way to purge the local view files or cache. He pointed me in the direction of logging into the server, selecting the root folder of the problematic file and going to Tools -> Clear Local Cache -> Un-check 'Do not remove Toolbox files.' -> Click 'OK' button.

                  epdm clear cache.gif

                   

                  After clearing the caches as shown, we executed the same test case and had our drawings correctly displayed. We are going to monitor the case - if it is not isolated and arises in the future, we may end up purging the local cache on a nightly basis. This will likely incur some extra network traffic/server IO for having to retrieve the files again daily as requested; however our internal infrastructure is robust enough to support this.