A large number of questions that you see in the DriveWorks forums (you do follow those, right?) all have to do with the interaction between DriveWorks and SOLIDWORKS. Most often, that question involves a DriveWorks user asking how to get the results from a SOLIDWORKS model generation to drive a DriveWorks specification. Whether that means using the mass properties that SOLIDWORKS calculates, a reference dimension from a sketch, Bill of Materials information, or an interference check, people want DriveWorks to run that model while the user is filling in their forms.
Those of you who are new to DriveWorks or new to the use of Specification Macros (“spec macros” as Glen Smith is keen to tell us all the cool kids call them) will not notice anything out of the ordinary when you first see the spec macros form in DriveWorks 16. I mean, you’re seeing it for the first time. But those seasoned veterans who have spent time pulling tasks from the toolbox are bound to be taken aback when seeing spec tasks in DriveWorks 16.
Before we can start troubleshooting anything, we need to first figure out what is wrong. Now I mean this in the most general way. Are we having a problem where the drawing is incorrect? Are we having a problem even getting a drawing to generate when we release? Are we even getting to the point where we can release? Is our computer even able to startup? If the problem is the last one, try turning it off and back on again.
The two biggest themes in DriveWorks 16 (DW16) seem to be 3D Interaction and CPQ. While DriveWorks has always been quite capable of serving all of the needs of the CPQ community, DriveWorks 15 introduced a CPQ “template” (such an inadequate term for as much as it does).
Well, it’s almost that time. The newest version of DriveWorks is in development now. Actually, the newest version is always in development, I suppose. But now, DriveWorks 16 is getting close to its release date. So, what new magic functionality is going to premiere in DriveWorks 16? That’s one big reason why we all go […]
OK, maybe “happy” isn’t really a term one would use when working with the SOLIDWORKS API. I’m not saying that the SOLIDWORKS API is bad, it just…well, it can be challenging at times. But if you insist that you NEED to write custom code (I find it rare that I need to if I use DriveWorks to its full potential), then you certainly can use DriveWorks and the SOLIDWORKS API together.
One of the greatest assets that Razorleaf can claim is a breadth of knowledge across industries and technologies. Recently, I had the opportunity to jump into something really fun and exciting, where you enter product details into a form and magically, models and drawings appear to suit your use case. I’m talking about DriveWorks design automation software. More importantly, I had the opportunity to work with industry expert, Paul Gimbel and learn some things you can only learn by working on real projects.
Tabular data is one of the foundations of the DriveWorks design rule. Rules generally fall into one of two categories: Calculations or Logic, or Lookups. Three. DriveWorks rules generally fall into one of THREE categories: Calculations, Logic or Lookups. The perennial favorites VLookup() and HLookup() join forces with DWVLookup() to allow DriveWorks architects the ability to store tables of static data, like material properties, available stock parts, and so on, and pull values from data for calculations or decisions.
It’s no secret that here at Razorleaf, we do a lot of DriveWorks implementations. And every implementation is always the start of something larger for our clients. There is no such thing as a completed automation project because you will always want to add new options, new products, new outputs, just adding more and more value. With every implementation being totally different, how can we help our clients to extend their implementations moving forward? Easy, we use intelligent, generic, reusable rules.
DriveWorks provides excellent functionality for collecting information and performing the calculations, lookups and logic that our designs require. There are some situations, however, where tools outside of DriveWorks are still employed.