4 Replies Latest reply on Mar 26, 2014 6:43 AM by Chris Cassettari

    Are the DriveWorks internals available to us users?

    Ramon F. Herrera

      As always, there is a compromise between ease of use (DriveWorks) and control over every detail (C#).


      We are trying to decide which one of the approaches is best for our operations, including the possibility of:


          (C) Both of the above.


      Can DriveWorks be combined with C# API programming?



        • Re: Are the DriveWorks internals available to us users?
          Artem Taturevych

          Yes, DriveWorks Pro has an open API. Not sure about Solo and Express.

          • Re: Are the DriveWorks internals available to us users?
            John Kangas

            Solo and Xpress don't have an sdk available. There is an sdk for Pro. Something to keep in mind is that the provided code snippets are generally in VB.Net, so if you do need to work with the Pro sdk you'll need to be comfortable either working in or translating from VB.Net. Also, the documentation is, um, sparse... But if you've worked with sdk's provided by small software companies before, that's nothing out of the ordinary.

            Pro also gives you the option of running Solidworks vba macros after model generation, which would give you the option to tap into any Solidworks-based coding you have available. As a developer working with Pro and Solidworks, I've found that handling the common Solidworks-side tasks with Solidworks macros to be beneficial in regards to encapsulation of automation methods and also in providing access to these tools for manual drafting tasks.


            If you'd be deploying forms to non-Solidworks-users that will produce models on demand, that's what Driveworks Pro is for. Otherwise, if your users would be at Solidworks stations anyway (which would have access to any SW addins or macros), I'd suggest Solo or Xpress - And if you change your mind later and decide to upgrade, Driveworks projects scale upwards very well.


            I guess what I'm saying is that while Driveworks is a very efficient way to handle tedious modeling, any extensive automation project should be expected to need some custom code sooner or later. Driveworks is really quick and easy to set up to handle basic modeling tasks; I can typically start setting up a basic assembly in the morning and be testing the same day (caveat - I've had lots of practice! :-) ). But that darn radius dimension that consistently gets set 20 feet away from the drawing after a rebuild? There's a vba macro for that.