7 Replies Latest reply on Aug 10, 2016 1:00 PM by Chris Mackedanz

    Running SolidWorks API programs in batch mode

    David Lear

      We have a number of Automation programs we have written in C# that we use to automated Engineering processes. Currently, these are all launched manually by the Engineers. Some of these can take a significant time to run so we want to investigate running these in some type of batch process. Has anyone tried running API programs in batch mode? Anyone know of any 3rd party tools that could be used to schedule, manage the batch process?

       

      Does Solidworks accept command line arguments when starting up?

        • Re: Running SolidWorks API programs in batch mode
          Christian Chu

          Try this - Keith R. can help you out

          • Re: Running SolidWorks API programs in batch mode
            Chris Mackedanz

            It is possible to write a new macro which calls the other macros / programs.

             

            I wrote one which reads a text file to determine which macro to run for our macro which releases our drawings.  I ran into a problem in that if we just set up a macro button to launch directly into the release macro I could not do any updates to the code unless everyone closed there SolidWorks as it would occasionally not release ownership of the file and therefore I could not save the changes I made.  It was really annoying because it doesn't really give you a good warning that your file isn't actually being saved!

             

            Once the changes have been tested I can open the text file and update the file path to call out for the correct version.

             

            You could do something similar where you write one macro which would launch the other macros.  It would give you some flexibility in being able to add an interface where your engineer could choose which ones to run.  You might want to look into update each one to give better feedback to the main program that calls them to ensure they ran correctly and what to do if they did not run correctly.

             

            There is a way to have a macro launch with SolidWorks by adding something to the shortcut path line a command line argument.  See here: https://forum.solidworks.com/message/159467

            • Re: Running SolidWorks API programs in batch mode
              Deepak Gupta

              You can look into running them via SOLIDWORKS Task Scheduler > Custom Task OR check #TASK

              • Re: Running SolidWorks API programs in batch mode
                David Lear

                Thanks for the quick responses. We currently have a number of standalone c# programs each performing separate steps or phases in the Engineering process. Each system we sell is Custom designed so we are modeling many systems a day. As an example, we have a tool in which the Engineer opens their top level system assembly, answers a couple of questions, and the program builds a complete 5 or 6 page assembly drawing. On larger systems this might take 25 or 30 minutes.

                 

                Our idea is to setup a tool where the Engineer could answer the questions and submit the job to a batch que when they go home at night. The SolidWorks portion can be complicated but I think we can figure something out. I'm a little more concerned about the how we schedule and manage the jobs overnight. For example, what if Solidworks hangs or crashes on job 5 of 100.

                 

                I'd rather not have to write my own job scheduling/management tools if I could avoid it.

                  • Re: Running SolidWorks API programs in batch mode
                    Amen Allah Jlili

                    Component object model worst nightmare is unattended automation.

                     

                    Quoted from  https://support.microsoft.com/en-us/kb/257757

                    "All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.

                     

                    Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment."

                     

                    While the quote above pertain to Excel being automated on the server side environment, the same actually applies to SolidWorks in the case of unattended automation. Not trying to disappoint the OP, I still think this is do-able but the batch program must include a lot of checks and balances so all it's guaranteed.

                     

                    I think this would be an interesting challenge! Send me an email to amen@cadhero.com or by pm

                    • Re: Running SolidWorks API programs in batch mode
                      Chris Mackedanz

                      See Deepaks response about using the SolidWorks task scheduler.  The challenge will be handling problems like if it does only manage to run 5 of 100 "jobs" how do you keep track of that, can you set it up where it does eventually "time out" of a job and moves on to the next one and generate an error report that gets saved somewhere that makes sense, or even emails it to who ever needs to see it?

                       

                      Then there is the problem of how do you input the the answers to those few questions?  I'm thinking a simple text file would work where you could put that info.

                       

                      Basically you would need a program which would check to see if there any text files, and how many there are.  Then for each one read the text file get the answers to those questions.  Then run your "standalone" programs feeding them the answers from the text files.  You would want to add some robust error handling to make sure that the "standalone" programs complete correctly or don't get stuck.  Then when they are done they move the text file to an _Archive folder.  Any text file not in the _Archive folder hasn't been run, or ran but didn't successfully complete.