Mechanical Modeler

The Contents of the Specification Container - Non Geometrical Features

How to design a non Geometrical Feature - MechanicalElement StartUp and Feature
Technical Article

Abstract

A new StartUp, specially designed to define Non Geometrical Features, was born.  It is named "MechanicalElement" and derivate from "MechanicalFeatur" .

In the following article, we are going to introduce it.

What is a MechanicalElement?

In internal view, MechanicalElement derives directly from MechanicalFeature, just like other Mechanical Features.

 

“MechanicalElement” is a StartUp derivate from MechanicalFeature

 

[Top]

How To Use MechanicalElement Structure?

MechanicalElement has to be used to design features without geometry.
It’s a StartUp which cannot be instantiated directly: it is only derivable.

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

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

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

By default, MechanicalElement does not have any 3DVizualisation.
However, it is possible to add manually Visualisation to your derivate feature implementing correctly specific APIs for Visualization (CATIVisProperties, CATI3DGeoVisu) .

Moreover, your feature will be included in traditional mechanisms like Update, or UI with its visualization under the SpecTree.

[Top]

Field of Application

MechanicalElement can be used, for instance, to design "Analysis Features", or "Measure Features" which don't have geometrical result but which could have visual result.
 

[Top]

Default Behaviors

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

  1. Insertion in Graph / Aggregation Rules:
     

       A “MechanicalElement” can be aggregated under the MechanicalPart, a Hybrid Body, a GS or a kind of MechanicalSet derivate[1].

    It cannot be instantiated directly: to use it, you must create a derivate StartUp. (For instance, "CAAMechaElem" defined in "CAAMechanicalUseCase.CATfct")
     

  2. Copy / Paste:
     

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

  3. Replace:

    "CATIReplace" has to be implemented specifically on your own feature. In deed, this implementation must agree with your feature design defining which types of attribute have to be replaced.

     
  4. Reorder:

    MechanicalElement supports reorder, according to aggregation rules
     

  5. Drag 'n Drop:

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

    MechanicalElement can only be defined In Work Object (DIWO) if it is aggregated under an ordered set.

    As a consequence, under a MechanicalSet, a MechanicalElement cannot be defined In Work Object.


     
  7. CATIContextualSubMenu:

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


     
    Default MechanicalElement's Contextual Sub Menu

     

  8. Update Mechanism:

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

    Please note that aggregating a feature using CATIDescendants:: Append () will not change MechanicalElement ’s Update status !!!

    Note: This is the totally opposite of Sets (GSMTool, MechanicalTool, HybridBody, MechanicalSet …) where aggregating a feature with CATIDescendants::Append() change Set’s Update Status...


     
  9. CATINavigateObject – Visualization in the SpecTree:

        A default implementation of this interface is provided.

    It consists in showing all authorised features aggregated under MechanicalElement with CATIDescendants::Append().

    In other words, all features retrieved by CATIDescendants::GetDirectChildren() and which are not filtered by CATINavigateFilter::IsShown() are shown under the MechanicalElement Node in the SpecTree.

     
  10. CATIParmPublisher:

        A default implementation of this interface shows parameters ("CATICkeParms") aggregated with CATIDescendants::Append().
    If you want to see parameters aggregated under specific attributes, this interface must be re-implemented.

     
  11. 3D Visualisation:

        By default, MechanicalElement does not have any visualization.
    In deed as MechanicalElement is dedicated to design non Geometrical Feature, we decided to provide the littlest implementation for Visualisation (No 3DRep, No Graphic Properties, no Hide/Show)

    However, it is possible to implement directly visualization on your own feature, using correct A.P.I and services (CATIVisProperties, CATI3DGeoVisu)

     
  12. CATISelectShow  & CATIVisProperties - Hide/Show Command:

        As MechanicalElement does not have, by default, any 3D Representation, we provide a default implementations of CATISelectShow and CATIVisProperties interface which disable Hide/Show command.

    This means that nothing occurs when “user” clicks on Hide/Show defined in the contextual menu.

    However, it is possible to implement directly those behavior on your own feature, using correct A.P.I and services

     
  13. User Feature / PowerCopy:

        MechanicalElement supports "User Feature" and PowerCopy. [3]
     
  14. Parent / Children

        Relations between features are linked to attributes and qualities.
    To have a Parent/Children mechanism on MechanicalElement, it is mandatory to create a new attribute on your own StartUp deriving from "MechanicalElement", 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 MechanicalElement StartUp.
    Moreover, Feature Feat.1 will be seen as one of its children.
     

 

BackUp/StartUp mode

A BackUp/StartUp (“FeatureBackUpMechaElem”) has been defined to support basic behaviours for Mechanical Element subtypes if code is not present.
In BackUp / StartUp mode, MechanicalElement instances are replaced by FeatureBackUpMechaEleminstances.
 

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 BackUp / StartUp:

[Top]

How to use Mechanical Elements?

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

[Top]

In Short

MechanicalElement is a derivable StartUp designed to define non geometrical features.

This feature can be aggregated under the MechanicalPart, a Hybrid Body, a GS or a kind of MechanicalSet derivate.

[Top]

References

[1] MechanicalSet StartUp and Feature
[2] Deriving Mechanical Feature
[3] An Overview of Power Copies and User Features
[4] 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.