About Annotation Templates with Knowledgeware Actions

This section describes the support and behavior of knowledge actions within annotation templates.

Integrating knowledge actions into annotation templates is a method to create complex annotations combining several attributes or using computations.

This page discusses:

See Also
About Annotation Templates

Concepts

Annotations such as grid, elevation, spot, etc. use annotation templates. A template is an extended 2D component in a detail sheet. For more information about 2D components, see 3D Modeling: Mechanical Systems: Drafting User's Guide: Working with 2D Components: Creating a 2D Component Reference.

Annotation template supports knowledge actions and provides some advanced behavior that can be implemented with Enterprise Knowledge Language (EKL). The behaviors are as follows:

  • Action is run each time an annotation based on its template is updated.
  • The inputs of an action are resolved with either the selected annotation input feature, its representation instance, or any occurrence up to the root product.

For example, you can do the following:

  • Display the number of stiffeners under a panel
  • Display the number of rebars or pillars in product or assembly
  • Display a specific symbol based on the part material
  • Make a complex computation involving mathematical operations and conditions
  • Reference several attributes of different objects

Usage of Knowledge Actions

Annotations with knowledge actions use attribute links. If you want to have the result of the knowledge action through an attribute link and a link template in the same text, an attribute link must be used instead of the link template.

Create a action. The relation is added to the Relations set under root product. Cut and paste it under the Relations node under the template.

The action to be managed by template has to respect the following rules:

  • Action has to be aggregated under the relations set of a template.
  • Action has to valuate an output parameter aggregated under the parameters set of a parameter with a different value for each of its results. It is required for the annotation to be properly updated.
  • The inputs of an action are resolved with either the selected annotation input feature, its representation instance, or any occurrence up to the root product.

Combination of a Link Template and an Action Output in One Single Text

Create two separate texts in the annotation: to combine a text with a link template and texts that are the result of an action (Text with Attribute(=Parameter) Link) into one annotation.

If you want to combine them as two sub-texts into a single text: As attribute link and link template cannot be mixed in a single text, it can be convenient to replace the link template with a simple attribute (=KWE parameter) link and to use action to manage link template. You can perform the following steps:

  • Create a Knowledgeware (KWE) parameter under the parameters set of a template.
  • Create an action in which the parameter is a set from the PLM attribute of the action input.
  • Use the attribute link on KWE parameter to insert the result in the text and mix with other possible Attribute Links to KWE Parameter(s).

For example, if you want to have a link template such as: Part.Name, you have to perform the following steps:

  • Create the parameter MyPartName under the Parameters set of the annotation
  • Create an action in which you valuate this KWE parameter:

    `Sheet2(Detail).MyAnnotationTemplate.ASDDrwAnnotationTemplate.1.Parameters.MyPartName`=Part.Name

  • Insert an attribute link to MyPartName in your text.
  • Insert an attribute link to another KWE parameter to a second sub-text in the same text.

When instantiating the annotation template, the annotation is routed to the 3D part. The action updates the MyPartName parameter, and the sub-text with the attribute (-parameter) link is updated with the Part.Name link template.

The instantiated annotation with a text having sub-texts, each pointing to a KWE parameter, are computed from a link template (for example, a PLM attribute) or any criteria set in the KWE action.

Routing

Specify the following type as input to the action:

  • Feature: to route the action to a geometric feature of the representation.
  • SldStiffener: to route the action to the SFD Stiffener feature.
  • SldPlate: to route the action to the SFD Plate feature.
  • Drawing: to route the action to the Drawing Representation Reference (typically for a title block).
  • VPMInstance: to route the action to VPM Instance of the Occurrence corresponding to the selected 2D geometry.
  • VPMReference: to route the action to VPM Reference of the Occurrence corresponding to the selected 2D geometry.
  • ProductOccurrence: in case the action needs to evaluate attributes on the instance or reference, or to navigate on the occurrence.

    The instance can be retrieved from occurrence using ProductOccurrence.Instance, the reference can be retrieved using ProductOccurrence.Reference, and the parent object of the occurrence can be retrieved using ProductOccurrence.Owner.

The above are typical examples. In certain cases , using Feature lets you navigate in the EKL code to a higher level parent.

Default Routing and Application Specific Routing

The following methodology is used to get the object corresponding to an action input argument from the selected 2D geometry. By default, the action inputs are evaluated with either the geometric feature corresponding to the selected 2D geometry, its representation instance, or any occurrence up to the root product. This is also applicable for annotation with link templates.



Using the default routing (as shown in the above flow chart), you can retrieve object types like VPMInstance, VPMReference, ProductOccurrence, 3DShape, etc. from the selected 2D geometry.

Note: If an object type is supported, its inherited types are also supported. For example, the object type 3DShape inherits from VPMRepReference, so VPMRepReference is also supported as it's derived type is supported.

If no object is found for the action inputs using the default routing, you can use application specific routing. For more information on supported applicative types, see Object Types and Action Inputs.

Note: The retrieval of action inputs from the selected object works only if any associativity exists between these objects.

For example, it is possible to retrieve an insulation object from a geometry or feature representing a piping pipe if insulation is defined on this pipe.

Routing Using Enterprise Knowledge Language

In certain cases, you cannot get the required input object for the action using the above routing methodologies. For example, consider the drawings in manufacturing context. The annotation actions in such drawings are routed using the manufacturing product structure and not with the CBOM product structure. Multi-Discipline Drafting provides a EKL function GetCBOMProductOccurrence to get CBOM product corresponding to a given manufacturing product.

The following methodology is used to get the CBOM product:

  • Get the resulting manufacturing product from the drawing.
  • Get the manufacturing process from the resulting manufacturing product.

    The process data is loaded if it is not already in the session.

  • Get the CBOM product context from the manufacturing process.

    The CBOM product structure is loaded if the data is not already in the session.

  • Using the design product instance in the resulting manufacturing product, the corresponding CBOM product is retrieved.