LOADING

Type to search

DriveWorksXpress or API: What to Learn and Why

CAD Picks

DriveWorksXpress or API: What to Learn and Why

You’re here because you have SOLIDWORKS. Or maybe you’re thinking about purchasing SOLIDWORKS. A large number of your customer projects are strikingly similar to one another. Project-to-project, perhaps you have 3 wheels in your assembly instead of 5, 7 doors instead of 10, or 15 stairs instead of 12.

Naturally, you started to wonder: is there some way to automate some of your processes in these contexts?

From there, it’s likely you did some investigative research into how you might be able to accomplish this. The SOLIDWORKS Forums, the DriveWorks Blog, and sites like CADSharp.com have led you to this point: pondering whether DriveWorksXpress or the SOLIDWORKS API is a better route to go when aiming to expedite the time it takes to complete future customer projects.

And that, my friend, is exactly what I’m here to discuss with you.

Whenever I discuss this topic with SOLIDWORKS customers, I find myself considering four questions: 1) which is easiest to learn, 2) which is easiest to use, 3) which offers the best integration with other apps, and 4) which offers the best backwards compatibility.

Before I begin exploring these factors, I want to apply a disclaimer here. I plan on prodding the four preceding questions with the understanding we’re interested only in solutions available to all SOLIDWORKS 3D CAD users. I’ll fairly mention—when relevant—cases where a for-purchase DriveWorks solution offers extended functionality, however.

1) Easiest to learn?  

This depends on your background. If you’re familiar with object-oriented programming concepts and you’ve at least written some code in VBA using, say, Microsoft Excel, the SOLIDWORKS API might not be too hard to get the hang of.

On the other hand: if you’re like most people, you probably haven’t coded much. If this aptly describes you, you’re in luck. In DriveWorksXpress, most of the automation actions you’ll apply will be done from within its Rules Builder. On their website, they make the claim: “You don’t need to be a programmer to use the DriveWorks Rules Builder.” Most customers I’ve worked with have found this to be true.

So long as you can understand the concept of a conditional statement, learning how to productively use DriveWorksXpress should prove totally accomplishable.

For these reasons, most users will find it easier to begin using DriveWorksXpress than the SOLIDWORKS API. Your only real prerequisite for learning how to use DriveWorksXpress is having a modicum of SOLIDWORKS 3D CAD experience. To use the SOLIDWORKS API effectively, you need a bit of programming experience, SOLIDWORKS 3D CAD experience, and the patience to engage with and learn the SOLIDWORKS API object model.

Luckily, there are many online resources available to help you learn either one. DriveWorks publically hosts a DriveWorksXpress how-to page taking you through all the steps required to begin and execute a DriveWorksXpress project. If you want to learn to use the SOLIDWORKS API, you can consider taking the SOLIDWORKS API Fundamentals course with a local SOLIDWORKS training provider. An eCourse version of the SOLIDWORKS API Fundamentals course is also hosted directly by SOLIDWORKS via MySolidWorks.com.

And remember: whichever route you choose, YouTube is your friend!

2) Easiest to use?

In this section of our contemplation exercise, we’ll assume you’re a capable VBA coder and you aren’t turned off by the challenge of getting comfortable with the object model of the SOLIDWORKS API.

Let’s say you wanted to make a simple user-driven form that controlled and output the size of this simple part. Ideally, you might want to control the length and width of the part, the thickness of it, and may be the size of the flanges on both sides.

It’s easy to make simple forms in the SOLIDWORKS API (or, more specifically, using the drag-and-drop controls made available via its Visual Basic for Applications interface). It’s easy to make a simple form in DriveWorksXpress as well.

You have more control to customize the aesthetic and UI of a VBA-driven form than you do a DriveWorksXpress form. In fairness, tools made available at the DriveWorks Solo and DriveWorks Pro levels blow the VBA Editor capabilities out of the water in terms of their simplicity and ease of creation.

As the ‘architect’ of your project, the form is a gratifying element to focus on. It makes things look real, after all! But the bulk of your time will likely be spent on writing rules in either context.

As you can see in the short pick-and-click animation below, tasks like assigning DriveWorksXpress to control and drive sketch and feature dimensions are super simple.

If I intended to write API code to drive this specific dimension object using an API-driven script, the simplest version of this implementation would look something like the code pasted below (with comments!):

‘Declare variables for the SOLIDWORKS application and the model in focus.
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2

Sub main()
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc

‘Select the dimension.
boolstatus = swModel.Extension.SelectByID2("D1@Sketch1", "swSelDIMENSIONS", 0, 0, 0, False, 0, Nothing, 0)

‘Modify its value.
swModel.Parameter("D1@Sketch1").SystemValue = "5"

End Sub 

Naturally, you’ll probably want something more complex than that if you plan on providing a UI to the user, allowing them to input dynamic values of their own that can/will change the value of specified dimensions.

In simple terms: the fact that DriveWorksXpress allows pick and click automations without the need to type or familiarize yourself with any API-level code can be a big plus in terms of usability!

3) Integration with other apps?     

Before I begin my explanation here, I want to enlighten the reader that DriveWorks does provide integration solutions at its Solo and Pro levels. I’ve worked with customers during implementation and support endeavors who were successfully using DriveWorks products with SOLIDWORKS PDM, for example. DriveWorks also has its own API at these tiers.

At the DriveWorksXpress level, there is no built-in integration with other applications. DriveWorksXpress runs akin to an add-in, where it functions entirely within the SOLIDWORKS 3D CAD interface. The file structure basically consists of the following: the master CAD documents—parts, assemblies, and drawings—that you will drive when automating your projects, and the MDB file which externally stores your DriveWorks project data (think: rules, forms, etc).

With the SOLIDWORKS API, like many other APIs, you can let your imagination run wild with possibilities. For example: a few years ago at SOLIDWORKS World 2016, I presented how one could use the SOLIDWORKS API in conjunction with the Microsoft Word API to automate feature statistic reporting.

You can think of the SOLIDWORKS API this way: it provides the ability to act as a user would, without the interaction of a user. You can create rich applications leveraging the API using languages like C#, C++, and more with the SOLIDWORKS API reference libraries included in your development projects.

4) Backwards compatibility?

Many readers may be aware of this already, but in case you’re new to SOLIDWORKS 3D CAD: file versioning is an important consideration.

Consider the following scenario: A user opens a part file, last saved using SOLIDWORKS 2017, within SOLIDWORKS 2019. The user makes a change, then saves this file. From here on, this file can no longer open in its native .sldprt format within SOLIDWORKS 2017. Using SOLIDWORKS 2018 SP5.0, you will be able to view body level information for the purpose of viewing and/or incorporating the part in assemblies and drawings.

If you’re interested, the SOLIDWORKS Web Help contains more information on version-to-version interoperability.

Naturally, when it comes to the API and DriveWorksXpress, you may have interoperability concerns regarding any proprietary versioning either of these areas are controlled by, respectively.

Whenever I’ve taught the SOLIDWORKS API Fundamentals course, I’ve made it a point to hit on this very topic while familiarizing my students with the SOLIDWORKS API Help documentation. The API Help is instrumental for anyone hoping to use the SOLIDWORKS API—it not only catalogs the available calls and interfaces, but provides lots of examples using commonly-practiced languages like VBA, VB.NET, and C#.

Whether you’re accessing the API Help from the web or from within SOLIDWORKS 3D CAD (either is fine), you’ll notice snippets like the one shown below as you begin your investigations into areas pertinent to your own applications:

The screenshot above shows the “Availability” section, which you’ll find for many calls within the API Help documentation. If you intended to write a macro using “FeatureExtrustion3”—the most current call available to execute what we know as “Boss Extrude”—you’d be fine using this call in any version 2014-later.

However, if you used this call exactly as it’s listed here in, say, SOLIDWORKS 2013, you’d run into some issues. The call would not be recognized, as it did not exist in that version.

Therefore, if this is a concern of yours, checking the availability status of your calls is smart to do. Using older version calls isn’t always advisable, but you can try to use them—and they just might provide more interoperability.

In terms of DriveWorksXpress, it’s important to keep in mind that—much like the SOLIDWORKS API—you’re simply having a system perform tasks automatically that a user would usually perform in a slower, manual fashion.

Therefore, if you’re running DriveWorksXpress in SOLIDWORKS 2019 and having it copy files last saved in SOLIDWORKS 2019 whenever you make new, customized projects, the resulting files from this project run will only be fully-editable inside of SOLIDWORKS 2019 and future releases.

In terms of the MDB file that houses the DriveWorksXpress-specific metadata, you can attempt to use a MDB file last saved in SOLIDWORKS 2019 in a SOLIDWORKS 2018 version of DriveWorksXpress, but otherwise, you’re mostly wed to the interoperability constructs governing usage of SOLIDWORKS files and their own versions (as discussed earlier).

Do you still find yourself with questions regarding the topic of which road to go down? Reach out to me on Twitter (@ServicePackSean) – it’d be wonderful to hear from you!


About the Author

Sean O’Neill is a Senior SOLIDWORKS Support Engineer at Fisher Unitech. He is a graduate of Villanova University and remains based out of the Philadelphia, PA area. He is a Certified SOLIDWORKS Expert (CSWE), a former SOLIDWORKS World Presenter, and a former SOLIDWORKS VAR Marketing Manager. You can follow him on Twitter: @ServicePackSean

Tags: