GD&T: Presentation of Geometric Tolerances

From WikiSTEP

Jump to: navigation, search

This sections deals with the presentation of Geometric Tolerances, and their attachment to the relevant “represented� GD&T information. This is very much a first pass as defining this information and is heavily based upon the exchange of 3D Associative Text, as defined in “Recommended Practices for 3D Associative Text – Release 4 – January 13th 2000�, available as a download from www.cax-if.de or www.cax-if.org.

It is envisaged that both this document and the 3D Associative Text Recommended Practices will evolve as further implementations of both come into being. The intent is to provide this as a basis for further improvement, in such a way that the structures and methods defined form the basis for those improvements and are to be left as is, such that any files following these procedures are not rendered obsolete or unconformant in the future.

I would like to acknowledge the considerable input made to this section of Lothar Klein and Giedrius Liutkus of LKSoft Gmbh. who have both put in a great deal of effort to lay these foundations and ensure future interoperability.

Contents

Geometric Tolerances as 3D Text

The method for exchanging the Presentation of Geometric Tolerance Data is to leverage the 3D Associative text capability developed in STEP and tested by the Cax-IF. The plus point of this approach is that either the Representation, the Presentation or both can be processed by a post-processor, depending on the capabilities of the receiving system. This means for fully intelligent systems, such as UGNX and CATIAV5, both the represented and presented GD&T can be exchanged, whereas for viewing systems where the representation is not stored, such as JT, the data intent can still be exchanged.

In order to simplify the STEP files containing this data, some changes and enhancement to existing STEP Modules will have to be implemented. This document will assume that these changes are already in place, but will draw the attention of the reader to them at the appropriate points.

Associating GD&T Presentation and Representation

The link between the Presented GD&T and the intelligent Representation is crucial. This gives the systems capable of handling the intelligent GD&T the information required both to maintain the intelligence, and to place the presentation of that data on the screen for the user to see.

The method proposed for instantiating this relationship is the same method as used in 3D annotation to associate the callout with a connection point on the geometry (i.e. The associated geometry for the text). This method defines a shape_aspect entity to contain the associated geometry connected to the leader line. As the GD&T representation also uses shape_aspects or subtypes of shape_aspects, then these can also be related to the callout in the same way. The instantiation for these is shown in the following diagrams:

Presentation Representation for Datums new.png

Figure 27. Presentation/Representation for Datums

In Figure 27, the Representation, contained in the DATUM entity, is linked via a shape_aspect_associativity with the name attribute set to "GDT Presentation", to the shape_aspect linking the presentation, contained in the DRAUGHTING_CALLOUT entity, and the entity to which the leader line is anchored. This link can be used when processing the GD&T Representation, to find the text position and anchor point for the Presentation, without having to process the full 3D Annotation set.

For Datum Targets, the structure is similar to that in Figure 27, except that the Representation shape_aspect subtype is Placed_datum_target_Feature, rather than Datum.

For the associativity between the Geometric Tolerance Feature Control Frame, and the 3D Annotation set defining the presentation of this, the structure is slightly different. This is due to Geometric_Tolerance not being a subtype of Shape_aspect, and so not being a valid participant in the shape_aspect associativity relationship. However, the Geometric Tolerance does need to have a shape aspect associated with it in the Representation, in order to define the Feature being toleranced, and so for the Representation to Presentation associativity, we shall use this entity. This leads to an instantiation as shown in Figure 28.

Presentation Representation for Geometric Tolerances.png

Figure 28. Presentation_Representation for Geometric Tolerances

Presenting the GD&T as 3D Associative Text

This section describes the current thinking on presenting the GD&T using the mechanisms provided by the 3D Associative Text Module. As this is a static document, the reader is directed to the STEP Wiki site, maintained by LKSoft GmbH, where the latest ideas on resolving this are to be found. Once a clear way has been identified to map this data to STEP, then this document will be updated to reflect what is on the Wiki Site. The address for this site is :

DATUM Labels

The Presentation of Datum labels is quite straightforward, using the methods defined for 3D Associative text. Figure 29 shows the STEP entities involved in the instantiation of a Datum label.

Note that this is the first instance of change to the existing standard, as the pre_defined_terminator_symbol entity does not at present contain the concept of a "datum triangle" and will require this to be made available. In line with the style of the standards at present, this will probably be instantiated as an "open triangle" and a "filled triangle". The alternative is to define this symbol as the set of curves which define it's shape, which would require more STEP entities to be instantiated.

Datum Presentation.png

Figure 29. Datum Presentation

In the Leader_Curve entity is a complex instantiation of :

This gives it the ability to style the leader curve, as well as providing a link to the geometric curve defining the leader in 3D space. The EXPRESS definition of annotation_curve_occurrence specifies that the styled_item should be a curve. This would allow the leader line to be one of the unbounded types of curve, which is meaningless. For implementations of this functionality, it is required that the underlying geometric representation of the leader be a subtype of the Bounded_Curve entity. It is also suggested that this restriction be implemented in the standards, perhaps as an additional restriction to the draughting_annotation_occurrence entity in AIC 504, as this already contains restrictions for Text and Symbols.

The Leader_Terminator entity is also a complex instantiation, in this case of:

For the terminator symbol, it's position in the model is defined by the placement attribute of the symbol_target entity. What is currently unclear is how to define the size of the terminator symbol, as there is no mechanism to define a box size for the symbol as there is with text. In order to define this, which is a requirement for CAD systems, I suggest that the height and width of the symbol be stored in the scale_x and scale_y attributes respectively, defined in the unit system of the view on the model (e.g. as a ratio measure applied to "one" unit).

The annotation_text_occurrence entity is a complex entity, made up of:

Where the item to be styled is the composite_text or text_literal.

One major problem, from the viewpoint of GD&T presentation, is the inability to simply define the box presented around the text defining the Datum letter. One way of doing this is to define the text_literal as the text_literal_with_delineation subtype. Part 46 states that the AP can define the delineation types, and I propose that we use this for GD&T. In the case of a Datum, I would suggest a delineation of "rectangular frame". This approach is in keeping with the approach taken within the CAD systems. If this approach is taken up, then I suggest that a full set of "frames" as used by the CAD systems are collated and applied into the relevant standards in one go, so as to avoid further changes in the future. An alternative approach is to draw the box as a set of curves associated with the text_literal. This approach allows for the styling of individual "sides" of the box, e.g. Different colours, but it is unclear at present whether any CAD system could support this level of detail.

DATUM Targets

Datum Targets are presented in a similar way to Datum Features. The additional elements of the Datum Target above and beyond the Datum Feature are the Target Symbol (i.e. The circular boundary around the target name and value) and a representation of the target area. The instantiation for the Datum Target is shown in Figure 30.

Datum Target Presentation.png

Figure 30. Datum Target Presentation

Depending upon the type of target area. The Datum_Target_Callout will contain either an Annotation_Point_Occurrence (for a point target), an Annotation_Curve_Occurrence (for a line target) or an Annotation_Fill_Area (for a rectangle or circle target area).

Similarly to the Datum Feature, the Annotation_Occurrence entities are instantiated as complex entities. Also the Text_Literal or Composite_Text styled by the Annotation_Curve_Occurrence may have associated curves, defining the Datum Target Symbol itself. Some CAD systems do not have access to these curves, and thus must make the decision to draw the Target symbol based on the Callout type.

Feature Control Frames

The mapping of a Feature Control Frame to a callout is somewhat more complex than that for the Datum Feature and Datum Target. This is mainly due to the combination of text and symbols that make up the GD&T presentation of the data. This is instantiated in the STEP file as a geometrical_tolerance_callout, which consists of an annotation_symbol_occurrence, representing the frame of the GD&T callout, and a collection of annotation_symbol_occurrence and annotation_text_occurrence to define the contents of the cells of this frame. The leader line and terminator symbol attached to the feature control frame are modelled as for the datum_feature, except using "open arrow" rather than "open triangle" as the pre_defined_terminator_symbol. Once again, most of the entities are instantiated as complex entities due to multiple inheritance. Figure 31 shows the structure of a feature control frame in STEP.

Feature Control Frame Presentation.png

Figure 31. Feature Control Frame Presentation

Personal tools