A large number of questions that you read 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.
Well, the problem lies in the fact that DriveWorks treats a DriveWorks specification (spec) and a SOLIDWORKS model generation as two thoroughly separate entities. The DriveWorks programming interface (API) has separate objects for the SpecificationContext and the ModelGenerationContext. These classes are even in separate libraries and namespaces.
The Key Difference
The critical point is that these two contexts are not tightly connected and, in most cases, do not even exist at the same time. DriveWorks specification flows include a task named Release Models. This task essentially builds a script of steps for SOLIDWORKS to perform. The specification context, where you fill in your forms, builds these instructions. But the specification context is being run by the DriveWorks Live server in most cases. This machine is rarely a machine equipped to run SOLIDWORKS. So, the specification context creates these instructions for SOLIDWORKS and the Autopilot to handle when they can get around to it. With the specification and generation contexts being so separate, often opened by different computers, there really is no direct mechanism for those two entities to interact.
But there are ways to leverage SOLIDWORKS results in DriveWorks. The methods available are all dependent upon the actions that you want the results to perform. If your goal is to affect the SOLIDWORKS model generation based on the outputs, you can leverage model generation tasks. Model generation tasks (or “genTasks” as Glen informs us they are known to the kewl kids), can be looped and there are also genTask Conditions that will evaluate SOLIDWORKS dimension values, mass property values and even custom property values. Generation tasks can allow you to continue working with the model or drawing based on the results.
If your goal is to have your SOLIDWORKS results drive information or actions within DriveWorks, this is possible, but will require you to pass information to some neutral location, then reopen the specification (or create a new one) and read that information into your spec. Triggered actions allow DriveWorks Autopilot to watch for files to appear, then kick off a specification transition. If you have SOLIDWORKS information written to a text or XML file, you can have your Autopilot watch for that file. Once the file with the information from SOLIDWORKS is created, Autopilot will reopen the specification and complete the tasks. If further interaction is required, you can notify users that their results are in, and they can continue the specification flow (or “specFlow” as it’s known). With some creative specFlow, tasks and conditions, DriveWorks is quite capable of creating SOLIDWORKS model optimization loops.
Without Autopilot, you could open SOLIDWORKS and generate the models right there and reopen the specification on your own. Taken one step further, you can utilize the OnDemand model generation available when specifications are run within the SOLIDWORKS Task Pain. This still does not provide interaction between the model and the specification, but it will allow the user to generate within SOLIDWORKS, and enter values into the awaiting forms by reading the resulting model.
The most important concept to understand is that the specification, where the user fills in forms or Autopilot performs tasks, is a complete separate entity from the generation which creates SOLIDWORKS models and drawings. The specification provides information to the generation in the form of the instructions that SOLIDWORKS needs to build your clones. To return the favor, and have the generation provide information back to the specification, the information needs to be placed in a location where the specification can retrieve it. This could be a file, a database or some other mechanism. With the looping, tasks and conditions available in specFlow and genTasks, you can create very powerful iterative and generative systems using nothing but 100% standard DriveWorks functionality. It’s just…that…easy.
Do you have methods that you’ve used to have SOLIDWORKS communicate with DriveWorks? Do you have ideas or applications where this might be useful? Toss them into the comments below.
The post The Most Misunderstood Concept in DriveWorks Automation appeared first on Razorleaf.