The wonderful thing about design automation, is that we can work with so many situations where we handle a large number of unknowns. The frustrating thing about design automation is that we can work with so many situations where we handle a large number of unknowns.
So you’re at a party, and there’s this programmer that you really want to impress. What do you do? OK, before you start hitting me with the question of why a programmer is even at a party (in case you haven’t heard, we don’t get out much), I’ll tell you the answer. All you have to say is, “Wow, I love RegEx” then just keep nodding in agreement as they launch off onto a glorious tirade about how poorly underutilized and underappreciated and how powerful regular expressions are.
There are a few quite different mindsets of DriveWorks implementers that you’ll find in the DriveWorks community. The primary difference between them lies in their views on the subject of structure.
100% design automation is generally unachievable. You’ve heard me say it before and I’ll say it again. 100% design automation is generally unachievable. And it is not the fault of the tools, it’s just the nature of process and automation. There will always be a balancing act between investment in time, money and effort with the value of business results. This fact can have some very significant and, to some, unsettling implications.
In Part 1 of this series, we discovered that using a Microsoft SQL Server (MS SQL or SQL Server) database will provide tools to handle large data sets, small data sets, complex data sets, dynamic data sets and even data that we share with other systems. But just what are those tools? How do I leverage SQL Server to processing these types of data with DriveWorks? What keywords should I put into my search engine to learn more More MORE? That’s what we’ll answer in this column.
Database. Just seeing the word can make people want to call a consultant. Luckily, I know where you can find one. (You can’t blame a guy for trying, right?) While DriveWorks provides a tremendous amount of rule driving functionality, when it comes to crunching raw data, the undisputed ruler of that domain is the database. Well, I’m here to spill the secrets and give you the basic concepts that you need to leverage Microsoft SQL Server (aka SQL Server aka MS SQL) for your DriveWorks data.
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).