This article discusses best modelling practices for automating assemblies, parts and drawings.
In Context or Top down design is functionality within SOLIDWORKS that gives a designer the ability to control dimensional information in sub-assemblies or parts from another part or assembly in the model. DriveWorks builds any new requirements from a specification from the bottom – up.
An advantage of bottom-up design is that because components are designed independently, their relationships and regeneration behavior are simpler than in top-down design. Working bottom-up allows you to focus on the individual parts. It is a good method to use if you do not need to create references that control the size or shape of parts with respect to each other, or if you use DriveWorks.
Although SOLIDWORKS allows the use of Top-Down Assembly modelling and in-context relations, the use of in-context features is not an ideal tool to use for a true design automation system. In-context features are best used in a proto-typing environment where continuous changes are required before a design is proven, but introduce limitations for a finished design that requires documenting and driven by a rules-based system. Once set up, a DriveWorks implementation lets the user specify at the top level, based on the overall requirements of the assembly. In effect DriveWorks replaces in-context design with rules and then builds from the bottom up.
When DriveWorks creates the models and assemblies it builds from the bottom up and will create a base level part, the drawing and any alternative file formats at the point it opens the file. Because of this bottom-up approach, higher level assembly relations are generally discouraged for a number of reasons.
While design automation systems like DriveWorks allow users to blend the power of SOLIDWORKS with the power of the design automation system, the final word in determining design aspects should lie with the design automation system. In-context features should be minimized in favour of rules.
Although the use of in-context relations is discouraged, there are a number of methods that can be applied if these SOLIDWORKS functions need to be used. The first thing to be aware of is that DriveWorks will replace any in-context references in an assembly, however, any 2D data produced from child components will not be updated until the drawing has been opened manually. To get around this associate all part drawings that require updating to the top level assembly. This way DriveWorks will create all the parts from the bottom up, then rebuild the assembly (updating the relations), then move on to the drawings. As the drawings are being created the parts will be refreshed to get the current view which will show the parts as they should be (updated by the assembly relations).
References used in SOLIDWORKS Equations are updated to a depth of one level only. In our experience the use of equations impacts model generation speed and requires multiple rebuilds if equations are ordered out of sequence. We also recommend storing behavioral rules within the rule engine for maintenance purposes.
Configurations can be switched by rules in any new file created. New configurations are not created.
When a sub component of an assembly is required to have its configuration switched, but the sub component is not driven by DriveWorks, this can be done by capturing the instance of the sub component in the assembly. The result of the rule for the instance is required to be the name of the configuration to switch.
New files can have unused configurations deleted by using the wildcard symbol at the front of the configuration name to be used.
Configuration specific properties cannot be captured. If a custom property exists with the same name as the configuration specific property, and has been captured, the driven value will be populated in all properties with that name.
When using SOLIDWORKS versions earlier than SOLIDWORKS 2010 mirrored components will not update when the seed component is changed by DriveWorks.
If a mirror component exists that does not require to be driven the seed component and mirror will be used in it's existing state in any variation generated by DriveWorks.
The mirror component feature should only be used when the mirror component is a true copy or mirror of the seed component. If the mirror component could differ from the seed we recommend creating and capturing an independent component.
When creating a mirror component the mirror can be a copy or an opposite-hand version of the seed components.
A new instance of the seed component is added to the assembly. The geometry of the copied component is identical to the seed component, only the orientation of the component is different. So when the seed component is captured and driven by DriveWorks the copied instance will have identical geometry.
A new document or new configuration is created in the SOLIDWORKS assembly.
- New Document
This will create a new file with links to the seed component. When the new seed component is generated by DriveWorks a new name is given to the resulting component, and the reference to the mirror component is lost. Therefore do not use this option if the mirror component is required to be driven by DriveWorks .
- New Configuration
This will create a new derived configuration in the seed component. Any changes made to the seed component will be reflected in the derived configuration. This option is recommended when mirror components are required to be driven.
Virtual parts can exist in an assembly but cannot be controlled by DriveWorks. Virtual parts are saved internally in the assembly they are created in and have no physical file available for DriveWorks to control.
All master models used by DriveWorks to create the new models from should have full read/write access.