Mechanical Modeler

The Contents of the Specification Container - Non Geometrical Features Set

How to design a Set dedicated to Non Geometrical Feature - MechanicalSet StartUp and Feature
Technical Article

Abstract

A new Sort of Set, specially designed to aggregate Non Geometrical Features (i.e. MechanicalElement instances [1]) was born: The MechanicalSet.

In this article, we are going to define it's field of application and it's default behaviors.

Note: Before going further in this article, it might be interesting to have a look at the article dealing with MechanicalElement [1]


What is a MechanicalSet?

In internal view, MechanicalSet derives from MechanicalRoot, just like other already-defined sets (HybridBody, GSMTool etc…).
 

 “MechanicalSet” is a StartUp derivate from MechanicalRoot

 

In user view, this set is defined to ONLY aggregate MechanicalSet, MechanicalElement and their derivatives.
Please, note this aggregation is done without any order !

 

 MechanicalSet's aggregation rules

 

Consequently, MechanicalSet can be defined as a non ordered set designed to only aggregate MechanicalSets an MechanicalElements.

 

[Top]

How To Use MechanicalSet Structure?

    MechanicalSet is a “base StartUp” defined to aggregate, without any order, MechanicalElements or MechanicalSets.
It cannot be instantiated directly: it is only a derivable StartUp.

Consequently, to use a kind of MechanicalSet, you will have to create a new StartUp, derived from MechanicalSet, in your feature catalog, just like you do when you want to create a StartUp deriving from a Mechanical Feature [2].

 

For example, let’s create a StartUp “CAAMechaSet”, derived from MechanicalSet, in the catalog “CAAMechanicalUseCase.CATfct”:
 

document `CAAMechanicalUseCase.CATfct`{
   container CATFeatCont {
      catalog_manager `MechMod.feat`
      Feature CAAMechaSet MechanicalSet@`MechMod.feat’ #startup {
      }
   }
}

[Top]

Field Of Application

MechanicalSet can be used, for instance, to design an "Analysis Set", or a "Measure Set" which aggregates analysis features designed with MechanicalElement StartUp.
 

[Top]

Default Behaviors

In this section, we are going to list all behaviors supported initially by MechanicalSet 's derivates.

  1. Insertion in Graph / Aggregation Rules:
     
  2. Copy / Paste:
     

    In front of "Cut/Copy/Paste", MechanicalSet (and its derivates) has the same default behavior as GSMTool.

    This means that, cutting a MechanicalSet, all aggregated features are cut. Moreover, pasting a MechanicalSet, all aggregated structure is pasted.
     

  3. Reorder:

    MechanicalSet supports reorder, according to aggregation rules…

    This means that MechanicalSet can be reordered under the MechanicalPart and that it can also be reordered under another MechanicalSet.
     

  4. Reorder Children:

    Even if MechanicalSet is a non ordered Set, it support "ReorderChildren" command. This means that it is possible to "reorder" its children which consists in changing the index of aggregated feature (i.e Features aggregated with CATIDescendants::Append() ).
     
  5. Drag 'n Drop:

    MechanicalSet supports “Drag and Drop”, according to aggregation rules, using CCP protocol.
     
  6. Define in Work Object:

    MechanicalSet can be defined In Work Object (DIWO).
    However, MechanicalElements, aggregated under MechanicalSet, cannot be defined In Work Object.

     
  7. CATIContextualSubMenu:

    A default implementation of this interface define this default contextual SubMenu:


     

    Default MechanicalSet 's Contextual Sub Menu

     

  8. Update Mechanism:

    MechanicalSet supports Update mechanism according to Feature Modeler's rules (Attr IN, OUT, NEUTRAL).

    As other Sets, MechanicalSet 's Update Status depends on aggregated features ones. This means that its update Status depends on its aggregated features (i.e Features aggregated with CATIDescendants::Append()).

    As we provided a global standard Update Mechanism, please, do not re-implement "CATIOsmUpdate" Interface.

     

  9. CATINavigateObject:

    MechanicalSet has the same behaviour as GSMTool in showing aggregated components in the spec tree.
    This means that MechanicalSets and MechanicalElements aggregated a root MechanicalSet using CATIDescendants::Append() will be seen in the SpecTree.

     
  10. CATIParmPublisher:

    MechanicalSet has the same behaviour as GSMTool in showing aggregated parameters in f(x)
    Indeed, f(x) will show all parameters aggregated under the MechanicalSet, using specified implementation of CATIParmPublisher defined on aggregated features.
    Moreover, traditional parameters aggregated directly under the MechanicalSet will be seen.

     
  11. 3D Visualisation:

    MechanicalSet doesn’t have any visualization behaviour. Indeed, as it is designed to aggregate non geometrical feature, its default Visu is restricted to its minimum (i.e. no visu displayed, no Graphic properties, no Hide/Show).
    However, it is possible to implement directly visualization on startup derivate.

     
  12. CATISelectShow  & CATIVisProperties - Hide/Show Command:

    As MechanicalSet doesn’t have any 3D Representation, default implementations of CATISelectShow and CATIVisProperties interface disable Hide/Show command. This means that nothing occurs when “end-user” clicks on Hide/Show defined in the contextual menu.

     
  13. UDF / PowerCopy:

    Currently, UDF / PowerCopy are not supported by MechanicalSets

     
  14. Parent / Children

    Relations between features are linked to attributes and qualities. Default design of MechanicalSet doesn’t have any attribute valuating parents.
    To have a Parent/Children mechanism, it is mandatory to create a new attribute, on your own StartUp deriving from "MechanicalSet", and to value it with its parents.
     

    Let's take the example described in the table below:

     

    Structure Example for Parent / Children


        In this example, Feature F.1 will be seen as a Parent of the applicative Feature deriving from MechanicalSet StartUp.
    Moreover, Feature Feat.1 will be seen as one of its children.

     

  15. CATIReplace:

    CATIReplace has to be implemented specifically on your own Set, if you want to allow replace mechanism. In deed, this implementation must agree with your feature design defining which types of attribute have to be replaced…
     

[Top]

BackUp / StartUp Mode

    A BackUp/StartUp (“FeatureBackUpMechaSet”) has been defined to support basic behaviours if code is not present.

In BackUpStartUp mode, MechanicalSet instances are replaced with FeatureBackUpMechaSet instances and icons, in the spec tree, are replaced by this one:

Most of default behaviors, defined in the last part of this documentation, works in BackUp/StartUp mode. However, some behaviors are specifically restricted in order to prevent data's corruption.

 

Default Behaviours restricted in BackUpStartUp Mode:

[Top]

How to use MechanicalSet?

To have a look at the use of MechanicalElement, please refer to specified article [3]

[Top]


In Short

MechanicalSet is a derivable StartUp designed to aggregate non geometrical features (i.e. ONLY MechanicalElement or MechanicalSet' s instance) with specific default behavior.
 

It aggregates non geometrical features without any order: it is a non ordered set.

[Top]


References

[1] MechanicalElement StartUp and Feature
[2] Deriving Mechanical Feature
[3] MechanicalElement / MechanicalSet Use Case
[Top]

History

Version: 1 [Mar 2007] Document created
Version: 2 [June 2007] Document updated: Use Case added
[Top]

Copyright © 1999-2007, Dassault Systèmes. All rights reserved.