DriveWorks Pro 15: In Context or Top Down Modelling (KB13103024) [send feedback...]

In-Context/Top Down Modelling

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.

Model Generation Method

DriveWorks allows models to be generated by one of two methods:

  • OnDemand
  • Queued (Automatic or Manual)

See Info: Model Generation Behavior for more information.

When using OnDemand generation, In Context references will not be updated at all.

When using Queued generation, In Context references will be updated to a depth of one level.

When using Queued Generation, a DriveWorks implementation lets the user specify at the top level, based on the overall requirements of the assembly and then builds from the bottom up.

In effect DriveWorks replaces in-context design with rules.

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 Engineer-To-Order 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.
  • DriveWorks is only able to change the references in in-context relations when they are only 1 level deep. Anything going to the second level will stay as the master model references and possible cause the model to fail generation.

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).


Knowledge Base Article Ref:KB13103024

Table of Contents