What is SOLIDWORKS API and what can it do?

The SOLIDWORKS API, or Application Programming Interface, allows the automation of repetitive and tedious tasks within SOLIDWORKS. Custom applications using the SOLIDWORKS API can be as simple or as complex as desired, for instance, the API can be used to create simple macros. Macro’s, at their core, are just a preprogrammed sequence of events. Sequences of mouse clicks can be recorded and automatically inserted into a new macro by using the SOLIDWORKS macro recorder. Simply start the recorder and then perform the set of actions you’d like repeated. That will produce a very simple VBA macro that can be replayed at any time.

More functionality can then be added to a macro by editing it in the built-in VBA macro editor. All sorts of things can be added, including logic and intelligence, prompts to the user to send warnings and other information or to gather user input and selections. SOLIDWORKS Standard, Professional, and Premium all come with the ability to use, create, and modify macros.

It is also possible to create more complex applications by using C#, VB.net, or C++. These programming languages can be used to create custom add-ins and stand-alone applications that can launch and run SOLIDWORKS without a user’s interaction. See below for an example of a custom SOLIDWORKS add-in.

Ok, but can you be more specific about what the API can do?

The API can be used for anything that can save a designer time. It can also be used to accomplish things that normally could not be done by SOLIDWORKS. Such as inserting a user coordinate system at a specified X, Y, Z location or setting a file to automatically perform additional actions whenever the model is rebuilt, such as updating a general table. Other interesting ideas are adding a watermark or some visible label to a part model that cannot be deleted or removed. BOM tables can be exported to CSV or Excel. Custom properties can be populated from an Excel spreadsheet. And the list goes on.

It is important to note that SOLIDWORKS macros are based on VBA. This is the same language used by Excel. So, if you have ever made an Excel macro, the concept is the same in SOLIDWORKS. The main difference is that SOLIDWORKS has its own set of API calls (contained within a VBA reference library) that are used to interact with SOLIDWORKS, just as Excel has its own set of calls for interacting with spreadsheets.

Creating your program as an add-in instead of a macro can provide several benefits. For instance, they can be more stable, run faster, and be more reliably updated for new releases of SOLIDWORKS. Also, some things just work better as an add-in. The downside for many is that they take more programming experience to create, and the upfront effort is greater.

When should I consider turning to the SOLIDWORKS API for a solution?

The best use cases for creating an application using the SOLIDWORKS API are:

1. Performing repetitive or tedious tasks.
2. To perform an action or series of actions that are not available inside the SOLIDWORKS or PDM user interfaces.
3. To save money by not having to manually do all of the above every day, one click at a time.
4. Eliminating user error by automating tasks.

You said something about automating SOLIDWORKS PDM?

SOLIDWORKS PDM has its own API, and it’s just as powerful as the SOLIDWORKS API. The main difference is that there are no PDM macros. There are only add-ins and stand-alone applications. This means it must be programmed using C#, VB.net, or C++ (no VBA).

Since PDM is focused on file management, references, and tracking data, most custom applications for PDM also focus on those areas. They can manage file references, check things in and out of the vault, send custom notifications, and manipulate data card properties (and much more).

Another great thing, is that custom tasks can be set up for users to run on-demand or can trigger automatically on workflow transition (hopefully you are familiar with PDM workflows?).

Some add-ins are what I call ‘hybrid’ add-ins. These are add-ins in PDM that are designed to utilize both the PDM and SOLIDWORKS APIs. With these, PDM can automatically open files in SOLIDWORKS and perform specific actions. And it can use the information in PDM to determine which files to process. Information PDM can use include bills of materials, where used lists, file references and data card variables.

This section probably deserves its own blog… there is a lot I could write about here.

Ok, I have an idea! …now what?

Planning out your custom application is one of the most important steps – aside from actually getting it working! The first thing you need to do is describe what you want this program to do and write it down. Writing it down will force you to actually define it as opposed to just having an idea in your head that can change over time. It is very important to have a targeted goal in mind, even for the simplest of macros.

The 2^nd thing you should do is build an outline. Ok, this is something you can maybe skip if you are just building something quickly or it’s only for yourself. Overall, it’s a little bit like writing a paper. Pick a topic, write a summary, then outline what the program should do. Use plain English and write down step-by-step what the application will do. This will also help when a year from now you’re trying to remember what this thing does.

Here is an example:

Summary: A SOLIDWORKS Add-in, that on the click of a button, will use the value of an existing custom property as the basis for a SQL query in a custom database. It will then use the returned string to automatically create 2 new custom properties in the currently open SOLIDWORKS part file.

Outline:

1. The installed custom SOLIDWORKS add-in will have 1 icon.
2. The add-in will only run on the currently open and active SOLIDWORKS part file.
3. A configuration file will hold the custom property name, SQL query, and SQL connection string.
4. The user must fill in the source custom property before running the add-in.
5. Clicking the button will read the active document’s custom property value and run the SQL query.
6. The values of 2 custom properties are filled in using the information returned by the SQL query.
7. The custom properties will be created if they do not already exist.

In this case, the application was designed as a SOLIDWORKS add-in and would be written in C# programing language. This would allow for better handling of the SQL query than is available using VBA macros.

As you may have noticed, something like this could also be used for ERP integration. A full solution would need to be able to push information to the SQL database instead of (or in addition to) pulling from it.

But I’m not a programmer, can I just have someone make me whatever I want?

Yes! …provided it is possible. CATI has an amazing development staff that is ready to help. Our developers have been programming custom applications for decades. We would follow the same basic process I’ve already discussed, starting with what do you want to accomplish? Can any of it be done already with out-of-the-box functionality in SOLIDWORKS or PDM? Then we’ll help to refine your need and can get started building it for you.

Any recommendations on SOLIDWORKS API design?

The API is an amazing tool to help your designers and potentially other departments in your organization. The API is not intended to replace your designers, it is intended to increase their productivity. I usually recommend starting with one main goal for automation and then if you need more, to grow it from there. Many people try to put too much into an application at once and the scope can either grow out of control or never get finalized. It is often easier to pick a starting point, use it for a while to figure out if there are any other enhancements you would like made, and then do both the enhancements and additions at a later time.

I hope this has helped clear up what the API is and how it could benefit you. It has so much flexibility, if you are looking for more information, the online help files are available here: Welcome – 2022 – SOLIDWORKS API Help.

Regards,

Joe Phillips
Application Engineer II
Computer Aided Technology

In January, InFlow Technology officially released our new PDF conversion tool for SOLIDWORKS PDM Professional. The new application, called InFlow CONVERT, extends the capability of the out of the box PDF conversion tasks, with over 100 available source formats and improved scalability and performance.

Improved performance

InFlow CONVERT can send PDF publish requests to one of many configured “PDF Drones,” built to process hundreds of requests an hour. If your PDF conversions are not keeping up with demand, simply add more drones to improve the speed. The InFlow CONVERT command center will automatically determine which drone is available and send the request.

More file support

InFlow CONVERT supports PDF conversion of over 100 drawing and office file formats. Included are the common drawing files types, such as SOLIDWORKS SLDDRW, AutoCAD DWG, Inventor IDW, Microstation DGN, and others. In addition, InFlow CONVERT supports major office file types like Adobe Photoshop, Excel, Word, Powerpoint, Visio, Publisher, TXT, Email MSG, and image types like BMP, JPG, and GIF.

Tight Integration

InFlow CONVERT uses EDrawings Professional for PDF conversion, providing an exact match to the Preview in SOLIDWORKS PDM Professional. Many PDF converters use native SOLIDWORKS to create the PDF, which can lead to quality issues, as SOLIDWORKS can shift views or dimensions as the drawing is opened. InFlow CONVERT uses integrated EDrawings for SOLIDWORKS files, thus eliminating issues related to drawing rebuilds. What you see in PDM is what you will see on the PDF.

InFlow CONVERT is developed by the InFlow Labs team of software developers.  This team has developed hundreds of custom solutions for SOLIDWORKS PDM over the last 10 years.  Reach out to our team for your custom needs.

Justin Webster
InFlow Technology

Companies that contact InFlow are generally not looking to buy a PLM solution. Rather, they are looking to solve complex issues in their organization. Often times, the connection between the issue and the definition of PLM is somewhat cloudy. Therefore, my goal in this series is to discuss some of these challenges that InFlow has addressed with PLM and some of the measurable success that our customers have achieved.

“Getting the right info…to the right people…at the right time”

It is a wonder that engineers don’t wear shoulder pads to work.

This statement has nothing to do with the dangerous nature of product development or the other cool thoughts that come to mind when considering shoulder pad imagery (Note to self: set TIVO for the NFL draft on Sunday).

Engineers are constantly tapped on the shoulder at work, both literally and via electronic forms of tappery: purchasing asking for a PDF to send out to a vendor for a quote, sales requiring an ISO view to share with a prospect, marketing looking for images for the catalog, manufacturing confirming that they have the correct revision, etc.

In many ways, traditional PDM systems have caused a lot of this tapping: The software keeps all non-engineers locked out for security reasons OR licenses are just too expensive to roll out the rest of the organization. Therefore, those outside of engineering are forced to continue tapping on shoulders.

One of InFlow’s customers called after extensive shoulder surgery. This particular customer has nearly 1000 employees in 3 locations, and they had gone through several pilot programs to test 3D viewing technology. They found several holes in these solutions.

First, they were too expensive to roll out to everyone in the organization. At an average cost of $400 – $1500 per floating license, the company would have had to invest a minimum of $40,000 in software to obtain a bare minimum number of licenses to support their user base. Second, all of the 3D viewers were too complex for what most people needed: a 2D drawing to review, email, or print. Lastly, the 3D viewers often require a better graphics card than many users had on their current computers in order to work effectively.

Between pilots, the company had one person that was responsible for document control, and he would send out an average of 7 copies of each print. This added up to a lot of wasted paper and a lot of confusion (for example, which copy of this drawing is latest version?).

InFlow recommended that the customer add Connexus to its current SmarTeam PLM system. Connexus serves as the bulk printing, publishing, and data distribution solution for all company employees that do not have access to PDM. Connexus is set up to automatically generate a PDF file upon a file’s release in PDM. No matter which location the employee resides, s/he can search for a drawing, ECO packet, or spec sheet on the web, then simply choose to view it, print it, or email it. Each item is time and date stamped to coincide with the company’s ISO standards. Best of all…Connexus does not require a license any user licenses. Therefore, it was economical to roll out to the enterprise.

In the 2 years since InFlow’s customer rolled out Connexus, they have seen a 40% increase in the availability of prints, a 58% decrease in the paper wasted on the shop floor, and increased employee satisfaction based on the availability of data…and their collective shoulder is making a full recovery from the incessant tapping that it had endured for years.

When using Connexus web, you can add the number to search for directly into the URL.

Here is an example URL:
http://sevans4/cnxdocrequest/Default.aspx?name=26700245*

This will open the webpage and execute the search using the passed in value

Please contact  Inflow Technology if you need any further help.

Here is how it works: install our InFlow Technology Print Server software on your server (this could also be a workstation).  Configure your printers.  Change a couple settings in PDMWorks Enterprise and you will have a new menu available at the “right-click” that will show “Batch Print”.  From windows explorer or from search results, the user will be able to highlight a set of drawings, right-click, “batch print”, and a print job will be sent to the server where all the processing is done.

Just go to the printer and wait for your prints.  If you want, it will also print all the documents to PDF and leave them in a default directory on your server so that you can go get them using Windows Explorer.  Both the Batch Printing and PDF Publishing can also be triggered on a transition so that all the drawings can be printed upon “release” triggers in PDMWorks Enterprise.

If you are printing SolidWorks, AutoCAD, Word, or Excel, we can use the native programs to print the files. We can also plug in a 3rd party viewer that can print 100’s of file formats, including SolidWorks, AutoCAD, CadKey, SolidEdge, Pro/Engineer, and others.

Questions…contact InFlow Technology.