3D Geometry and tolerance modeling for physical ...

International Journal of Research and Reviews in Mechatronic Design and Simulation Vol. 1, No. 1, March 2011 Copyright © Science Academy Publisher, United Kingdom www.sciacademypublisher.com Science Academy Publisher

3D Geometry and tolerance modeling for physical simulation Benaissa El fahime 1,3 , Nabil Moujibi1 , Bochra Rzine 1 , Karim Jaballi2 , Mohamed Radouani3 . Laboratoire de Génie M écanique, Faculté des Sciences et Technologies, Route d’Immouzer - B.P. 2202 Fès, M aroc, M echanics M odelling and Production Research Unit (U2M P), University of Sfax, Sfax Engineering School (E.N.I.S.), Soukra rouad km 3. B.P 1173, 3038-Sfax –Tunisia. 3 Laboratoire M écanique Energétique et Procédés. Ecole Nationale Supérieure d’Arts et M étiers, B.P. 15290, El M ansour - M eknès, M aroc 1 2

Correspondence should be addressed to Benaissa El fahime, [email protected]

Abstract – Physical simulations of mechanical systems are not affected by the real geometry of objects. Most simulation systems model mechanical parts by their centers of mass or by some geometrical features such as moments of inertia. Therefore, designers are always asked to separate the geometry of the physical model. The aim of this work is to establish a library for geometrical physical simulation of mechanical systems. Our proposal is to integrate the 3D geometric features in the simulation system physical Modelica. The Modelica standard library and its available tools provide facilities for the representation of 3D geometry. This geometry is associated with physical objects included in the models simulated Modelica. To take into account geometric imperfections in physical simulations, we also provide an extension of the geometric model by the introduction of the products geometrical and dimensional tolerancing. This paper discusses the details of syntax and implementation of this approach .

1.

Introduction

Currently, modeling systems are widely used in most applications. Created models include relevant information and data [1]. Several factors are essential for simulation and visualization of physical models:  Volume, mass, center of mass position and inertia matrix must be automatically evaluated for each body.  Full geometric information for collision detection in contacts between the bodies is required.  Contact forces affecting the behavior of the physical model must be calculated. For some applications the geometry associated with physical models can be used for simulation. For others, simulations and geometry are independent. For example geometry is ignored in the electrical modeling, partially used in the dynamic analysis of mechanical systems (the kinematic outline is usually sufficient). However, a complete and accurate description of geometry is necessary for the visualization of physical processes. The most important features that should be available in the visualization environment are:  Primitive graphic objects with vertices coordinate (point, line, triangle, etc.). These coordinates can be constants or variables calculated during the simulation;  Objects with fixed shape that change position and orientation over time (rigid body visualization).

 

Visualization of forces, speed, acceleration etc. Visualization of objects that change their shape during dynamic visualization (non-rigid, flexible body visualization).  Surfaces splines;  Colors. Modelica [2] is an object-oriented language for modeling dynamic systems. The Multibody Simulation Library (MBS) is scheduled for that purpose. The dynamic properties of bodies are obviously in dependent on their geometry. This circumstance is only used in MBS for a limited set of bodies with primitive shapes (box, cylinder, etc.) [3]. Furthermore, the shape of the bodies is not utilized for collision detection and contact force computation. This work aims to establish a geometrical library for the physical simulation of mechanical systems. Our proposal is to integrate the 3D geometric features in the MBS physical simulation system. To take in account geometric imperfections in physical simulations, we also provide an extension of the geometric model by the introduction of the geometrical dimensional tolerancing products. In this paper we dis cuss the syntax and implementation approach details.

2.

Graphic representation of objects

In a graphic or geometric model there is only a tree-like graph with structural information, numerical constants and variables. These are not equations, not functions, not

International Journal of Research and Reviews in Mechatronic Design and Simulation

variables. To add geometric or graphic information to a Modelica model two alternatives can be cons idered, Figure 1:  Using classes In the Oriented Object Programing paradigm, a class declares the common properties to a set of objects (attributes representing the objects state and methods of representing their behavior). It is possible to restrict the set of objects represented by a class through an inheritance mechanism. In this case, we can create a new class who adds new properties related to the first one. Figure example 1 of Modelica classes with graphical.  Using annotations: Generally an annotation is a comment, a note, an explanation or any externally remarks that can be attached to a document The classes might contain special annotations which define geometric and graphic properties. Annotations in Modelica are tree-like structures with labeled branches and attribute values. Currently annotations are used for icons, diagrams and documentation, example 2.

If a class defines its own geometric annotations it can refer to the annotation of the parent class and attributes the components of the class, for this purpose a special keyword (Super) and a keyword Component (name) are introduce. If a class doesn’t define its own shape attributes, then the shape of the superclass and the shape of components are just joined together. Example 3: Definitions of some Modelica annotations with geometric information. model Sp Annotation( PrimitiveGeometry( {Sphere(p={0,0,0},radius=1)} )) end Sp;

This annotation define a primitive sphere model Sp1 extends Sp; Real r; annotation( primitiveGeometry( {Sphere(p={0,0,0},radius=r)} )) end Sp1;

Example 1: A Modilica Class defining a s phere. model C "using Classes" PrimitiveGeometry x(c={Sphere(p={0,0,0},radius=1)}); ... end C;

Example 2: Annotation defining an icon in Modelica. annotation( Icon(coordinateSystem extent={{-100,-100},{100,100}}), graphics={NameOfVendor (Circle(center={0,0},radius=5))} ));

The first alternative (using classes) requires creating a Modelica visualization library (with a set of Modelica classes) and adding new classes for particular geometric structures to this library. Sometimes there is a need to include some CAD graphics formats directly into the Modelica model code. In this case annotations are used for storing extra information about a model, such as graphics, documentation or versioning, etc. They are effectively ignored when the model is compiled for the purpose of simulation.

3.

A MODELICA Model Structure

The classes in a Modelica model have components (variables) of types defined by some other classes. Instantiation of variables and equations always starts from the last (the main) class of the model (this class corresponds to the root node in the tree of Modelica classes), and continues recursively to the components. The geometry of bodies used for simulation or visualization included in a Modelica model is specified recursively. The shape in a Modelica application is a combination of the shapes of all instances declared in the last class (the main) of the textual presentation of the application model.

19

This annotation overrides the annotation inherited from Sp.

4.

Syntax of geometry in Modelica

Typically, graphics formats can be set in Modelica using two main approaches:  Specification of a set of primitives (triangles, spheres, etc.) and operations (translation, rotation, extrusion, etc.).  Use of an external graphics format such as STL[5], VRML[6], DXF[7], etc. The structure of the library data that can be used to describe geometrical data is shown in Figure 1. 4.1. Syntax for specifying external formats To import external graphic formats format such as for use in a Modelica model, we must specify the identifier of the format, the file name and identify of the components of the file. In this case an annotation is attached to the component as in the example 4: In this example the external file in STL format that describes the 3D geometry of an object surface. This format is just one of the available portable formats for description of static rigid bodies. It may include subcomponents in the description of geometry, and it is possible to access sub-components through a unique name or a sequence of names. Example 4: An STL file imported in Modelica Annotation( ExternalGeometry (format="STL",file="part.stl", component="17"))

Geometry (used in annotation(…)) External Geometry

Direct Geometry

Primitive Geometry

___________________

String format String file String component

Point3D

_________________

____________________

________

String format String code [:]

Primitive c [:]

Real [3]

Primitive

ExternalPrimitive

Construction

Face

Node

____________

_____________

Real color[4]

Primitive c [:]

Position

Super

Component(name)

Triangle

Index FaceSet

Translate

Rotate Matrix

Rotate

____________

_____________

_________

______________

_______

Point3D p[3]

Point3D p[:] Integer idx[:]

Point 3D p

Real[3,3]matrix

Point3D dir Real angle

Quadrilateral _____________

Point3D p[4]

Sphere

Extrude

________

________

Point3D p Real radius

Primitive prim Real depth

Figure 1: Description of geometric annotations structure

4.2. Annotation defining primitive Geometric Points, segments, triangles, quadrilaterals, spheres, prisms, parametric surfaces, etc., are primitive objects that can contain a geometric model. So the following types should be available: type PrimitiveGeometry=Primitive [:]; record Primitive; // has no specific components end Primitive; type Point3D = Real [3]; record Face extends Primitive; Real color[4]; /* RGBA */ end Face; record Triangle extends Face; Point3D p[3]; end Triangle; record Quadrilateral extends Face; Point3D p[4]; end Quadrilateral; record Sphere extends Face; Point3D p; Real radius; end Sphere record IndexedFaceSet extends Face; Point3D p[:];

Integer idx[:]; end IndexedFaceSet

An annotation defining a triangle may be presented as follows: annotation( PrimitiveGeometry({ Triangle(p={{0.1, 0.2, 0.3}, {1.1, 1.4, 2.2}, {2.4, 2.1, 0.5}}), ));

4.3. Annotation defining primitive transformations A node is a primitive witch defined as: record Node extends Primitive; Primitive [ : ]; end Node

Translate, Rotate and Scale define primitives transforms from an old coordinate system to the new coordinate system. Corresponding definitions are: record Position extends Primitive end Position; record Translate extends Position; Point3D point; end Translate; record Rotate extends Position;

International Journal of Research and Reviews in Mechatronic Design and Simulation Point3D direction; Real angle; end Rotate;

data depending on form tolerance type and its value. Corresponding class definition:

record RotateMatrix extends Position; Real [3,3] matrix; end RotateMatrix; record Scale extends Position; Point3D size; end Scale;

Example 5: annotation of sphere translation annotation( PrimitiveGeometry({ Node({ Translate( point={0,0,-1}), Sphere( point={0,0,0}, radius=1}) }));

5.

We define SizeTolerance as:

Geometric tolerancing by its nature can be modeled as objects in the object-oriented programming paradigm [4]. It can be modeled from a general parent class where the variables are 3D solid model data or data validated by the user. Tolerancing parent class is designed to define different tolerance types and their associated data, Table 1. T able 1. tolerance types and associated data structure

Size

Form

Orientation

Required Information Fa_N o, UpToLim, LoToLim Fa_N o, TolType, TolValue Fa_N o, TolType, TolValue, M atCon, Datum

model FormTolerance extends tolerances; { Vector form =new Vector(); FT(int face, String TolType,float TolValue ) {faceNo=face; toleranceType=TolType; tolValue=TolValue; form.insertElementAt (new Integer(faceNo),0); form.insertElementAt(TolType,1); form.insertElementAt(new Float(TolValue),2); } public Vector getFormTol() { return form; } }

5.2. Size tolerance class

7ROHUDQFLQJUeprHsentation

Tolerance Type

21

Remarks Fa_N o: a pointer referring to the face UpToLim : upper tolerance limit LoToLim: lower tolerance limit TolType: type of applied tolerance TolValue: tolerance value M atCon: material condition Datum: an integer reference to a datum Datums: Integers refer to datums (2 or 3)

The five categories of tolerance classes have been developed for form, location, position, runout and profile, which extend a parent tolerance class through inheritance. The parent tolerance class is designed to define different tolerance types and their associated data. Another class is developed to modify, delete and add tolerance to 3D solid model. Each tolerance class type provides a prototype for all of its objects. A tolerance type class provides a common structure and behavior for the tolerance type. 5.1. Form tolerance class We define FormTolerance class that provides a prototype for all form tolerance types; such as straightness, flatness, roundness and cylindricity and storing the associated

model SizeTolerance extends tolerances { Vector size =new Vector(); public void sizeTolerance1 (int [] face, float upperLimit, float lowerLimit ) { upperTolLimit=upperLimit; lowerTolLimit=lowerLimit; faceNo=face[0]; faceNo1=face[1]; Integer khh= new Integer(faceNo); String ko = khh.toString(); size.insertElementAt(new Integer(faceNo),0); size.insertElementAt(new Integer(faceNo1),1); size.insertElementAt(new Float(upperTolLimit),2); size.insertElementAt(new Float(lowerTolLimit),3); }

The objects for all types of tolerances are saved in vector data structures as they can dynamically grow or shrink as needed; a distinct advantage as compared to the standard Array data structure. A data element can be inserted into or removed from any location of a vector with a single method invocation. Vector based data structure has been selected to represent tolerance data as it would be very synergistic to tolerance modeling. The tolerance modeler is directly integrated into 3D solid model system and can act on data in 3D CAD files. The data in the model of tolerance are not independent entities in the database of the solid model.

International Journal of Research and Reviews in Mechatronic Design and Simulation

6.

Conclusion

In this work an Object Oriented Programming approach for modeling 3D geometry has been developed. The data structure based on the vector representation has been chosen to represent the dimensional and geometric specifications because it would be very synergistic to the tolerances modeling. Looking ahead to validate this approach, an extension of this work on examples cited in the standard GPS is envisaged.

References [1] [2] [3] [4]

[5] [6] [7]

22

Juster N. P. Modeling and representation of dimensions and tolerances: a survey . Computer Aided Design. Volume 24- n°1. Pages 3- 17. 1992. Modelica Design Group. http://www.modelica.org Martin O., Hilding E., François E., Cellier. Modeling of Multibody Systems with the Object-Oriented Modeling Language Dymola, Nonlinear Dynamics. Kluwer Academic Publishers. 9:91-112. 1996. Monir M. K., Ibrahiem M. E., Rajit G., Shiv P., Khaled. A. M. Geometric dimension and tolerance modelling and validation system based on object oriented paradigm for 3d solid model. Proceedings of Insert Conference Abbreviation. ASME International Mechanical Engineering Congress. IMECE2004. November 13-19, 2004, Anaheim, California. 3D Systems, Stereo Lithography Interface Specification, 3D Systems, http://www.vr.clemson.edu/credo/rp.html. VRML Consortium, VRML Repository, http://www.sdsc.edu/vrml/ AutoDesk, AutoCad documentation. DXF Format, http://www.autodesk.com

Benaissa EL FAHIME is currently a Ph.D. student at Mechanical Engineering laboratory - Faculté des Sciences et T echniques of Fez. His research activities concern the representation of mechanical tolerances in the Bond Graph models of mechatronic systems.

Karim JABALLI received his PhD degree in Mechanical Engineering in 2009 from Ecole Centrale Paris in France. He is currently an assistant professor at the National School of Engineers of T unis (T unisia). His research interests include production system modeling, manufacturing tolerancing, GPS, CAD-CAM software. Nabil MO UJIBI is currently a Ph.D. student at Mechanical Engineering laboratory - Faculté des Sciences et T echniques of Fez. His research activities concern tolerancing techniques in CAD-CAM systems.

Bouchra RZINE graduated from National Higher School of Engineering (Crafts and T echnologies, ENSAM Morocco). She is currently a Ph.D. student at Mechanical Engineering laboratory - Faculté des Sciences et T echniques of Fez. Her research interests include mechatronic systems design and kinematics, Dynamics of machines. Mohammed RADOUANI is an associate professor at the National Higher School of Engineering (Crafts and T echnologies, ENSAM Morocco). He obtained his Ph.D. thesis in Mechanical Engineering from Prestigious training college for teachers and researchers in Technics (ENS of Cachan, University of Paris-south XI France, in 2003) and his Habilitation of supervising scientific research Dissertation from Faculty of Sciences-Meknès in 2009. His research work is dealing with specification and inspection of mechanical systems according to the ISO standards. He is also interested to products numerical engineering.