DriveWorks Solo 16: How To: SOLIDWORKS Best Practices [send feedback...]

How To: SOLIDWORKS Best Practices

This article discusses best modelling practices for automating assemblies, parts and drawings.

In-context Design

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 Solo 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:

  • One main purpose of design automation systems is to capture the intelligence and rules of the design, and make them easy to understand and edit. If the rules are being represented by model or assembly relations, these rules are not being documented and cannot be controlled and updated.
  • The use of In-context features can have serious repercussions if non-associative files (like DXF, JPEG, IGES, etc.) are required, as the export may occur before assembly relations are resolved.
  • In-context features slow model generation and make the assembly more complex to work with.
  • In-context relations are invisible to the design automation system. This could cause confusion when models do not seem to follow the rules that have been created in the ETO system.
  • Bottom-up modelling more closely mimics the real-life processes of manufacture and assembly.
  • In-context relations must be known by any user that wants to change the model as these relations are inherently unidirectional. 
  • Changing In-context relations requires far more work than adding or modifying a rule in the design automation system.
  • Writing external documents or to an external database will usually require up to potentially all of the model information, therefore this information needs to be calculated in DriveWorks or obtained from DriveWorks anyway and would result in extra work for SOLIDWORKS to recalculate the models.

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.

Assembly Equations

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.

Design Tables, Configurations and Derived Configurations

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

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.

Mirrored Components

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.

  • Copy

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.

  • Opposite-Hand Version

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

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.

Read only models

All master models used by DriveWorks to create the new models from should have full read/write access.

Table of Contents