Automatic Model Conversion to Modelica for Dymola-Based Mechatronic Simulation
Total Page:16
File Type:pdf, Size:1020Kb
Automatic Model Conversion to Modelica for Dymola-based Mechatronic Simulation Automatic Model Conversion to Modelica for Dymola-based Mechatronic Simulation Tamás Juhász, M. Sc. and Ulrich Schmucker, Dr. Sc. techn. Fraunhofer Institute for Factory Operation and Automation, Magdeburg, Germany [email protected] and [email protected] Abstract some internal model parameters must be fine-tuned, according to model assessment or verification proc- Virtual product development allows us to recognize esses. This implies that an automated model conver- and evaluate the characteristics of a new product on sion is highly demanded in order to accomplish a the basis of simulation at an early stage without hav- good workflow. The designing engineer can inspect ing to build a physical model. Currently the most, the behaviour of the given virtual product by utiliz- widely spread commercial CAE systems do not offer ing a dynamic simulation of that. For a convenient direct support to external dynamic simulation appli- iterative workflow a solution have to be provided to cations. Conversely, dynamic simulation of a de- automate the conversion between the standard output tailed model is required to maintain good correlation format of the source CAD system and the input for- between the behaviour of the real product and its mat of the target simulator. virtual counterpart. In this paper it will be presented, In this article it will be presented that using Robot- that using a partially automated workflow a conven- Max , our .NET-based mechatronic model authoring ient Modelica model translation can be achieved and visualization application mechanical CAD data from the output of a mechanical CAD system, allow- from the widely-spread Pro/Engineer CAD environ- ing the final model to be extended independently ment can be imported, new mechatronic components with new elements from other simulation domains, can be added, thus multi-domain Modelica models considering Dymola-based multi-domain simulation. can be generated and the results of the Dymola-based A .NET-based integrated tool for mechatronic model multi-domain simulation can be visualized in a con- editing and online / offline visualization support us- venient way, even in 3D stereo using various 3D ing advanced 3D (and stereo) techniques will also be technologies, for example by exploiting autostereo emphasized in this article. monitors, polarizer- or liquid crystal shutter glasses. Keywords: Pro/Engineer, Mechatronics, Collision, 2 Translation from CAD data to Modelica, Dymola Simulation, Stereo, 3D Visualiza- tion Modelica models We have interposed an own developed tool into the 1 Introduction design workflow to achieve automated conversion to Modelica models from a Pro/E CAD model assem- Virtual engineering offers a completely new aspect bly (e.g. for mechanics: geometry, mass / inertia pa- of product development, as thereby all sections of rameters, joints). the product life cycle can be independently analyzed Similar work has been done in [1], but using the and in parallel continuously optimized in the virtual AutoCAD Mechanical Desktop system, and a differ- world. Simulation makes the practical verification of ent, shallower structure of Modelica models. Our the desired behaviour possible in early development approach allows a 3 rd party to extend the mechanical stages. model with additional elements from other engineer- It is very cumbersome to manually create a paramet- ing domains in such a way that a designer can still ric simulation model representing a complex product change / fine tune parameters in the CAD environ- that has been designed in a CAD system. Addition- ment (and re-export the mechanical model), without ally it is often the case that in machine production a sacrificing the extra work that another expert might family of component parts with varying parameters have already done within the other model domains, has to be designed repeatedly. Nevertheless the where there might be connections to the previous product planning is usually an iterative practice: mechanical model. The Modelica Association 719 Modelica 2008, March 3rd 4th, 2008 − T. Juh´asz,U. Schmucker 2.1 Basic steps of the translation process 2.2 Building a draft hierarchy out of XML in- formation There is a large amount of commercial and non- commercial applications (e.g.: “3D_Evolution” or A single “Physical Modelling XML” file enumerates “TransMagic”) available on the market offering na- all parts (= XML bodies) in the original root CAD tive conversion between common standard (STEP, assembly (= XML subsystem) from which it was IGES) and other well-known (AutoCAD, CATIA, created. The special RootGround part represents a Inventor, Pro/Engineer, SolidWorks, Unigraphics, fixed point in the environment. Each normal XML etc.) CAD data formats. Thus without subsequent rigid body entry contains information about the restrictions it is assumed our source data is available physical parameters (mass, inertia, surface area, vol- in the format that our CAD system (Pro/Engineer) is ume, etc.) of the given Pro/E part and has at least able to import. two coordinate frames in World space: the one that The translation from a CAD source file to Modelica defines the location of the centre of gravity ( CG ) of description needs the following basic steps: the rigid body, the other that shows the origin trans- formation of the body’s geometry (CS1 ). XML bod- - Assuming the CAD model has already been im- ies can carry any number of additional frames ( CS2, ported into Pro/Engineer , you can export the hier- CS3 … ), which all have a unique integer ID: these archy and geometry information of the actual unique numbers are used by us to find the corre- model to VRML files simply through a click over sponding parts between joints. the File menu “Save as…” command. Note that in a general case you get a main hierarchy file and the As it was mentioned before, the XML file also con- geometries of the subsequent parts in separate tains information about joints, which represent the .WRL files. Geometry information is essential if constraints of the original CAD assembly. Each you want to model collision between the parts dur- XML joint ( Ji) has two integer IDs that are uniquely ing the simulation (see section 3.1 for further in- referencing two different frames (these are named formation). “Base ” and “ Follower ” in a SimMechanics model). - SimMechanics is a single-domain extension of the The special weld joints are used to mount two rigid Simulink environment developed by MathWorks, parts together with no degrees of freedom left be- and can be used for modelling and simulation of tween those. There can also be a series of primitive mechanical systems. Under Pro/Engineer environ- joints between two frames, representing various de- ment the freely available Pro/E-to-SimMechanics grees of rotational / translational freedom between plug-in [2] lets you export the given CAD assembly those parts. In the hierarchy this always implies the to a single (so called “Physical Modeling XML”) following sequence: “ Follower ” “ J1” … descriptor file, which is invented to ease the gen- “JN” “ Base ”, where “a b” shows that “a” is the eration of SimMechanics models out of Pro/E data child of “b” in the hierarchy (i.e. it inherits all trans- in an automated way. The result XML file contains formation from that). Using the XML Joints’ frame global hierarchy-, constraint- and physical parame- references you could build a skeleton (a draft hierar- ter information (inertia-tensors, masses, etc.), but chy) of XML bodies. Unfortunately this does not no geometries at all. imply automatically that the final hierarchical model - We developed an application (it is called Robot- is also ready: the geometries of the possibly colliding Max ) the core logic of which processes the afore- (but point-sized so far) bodies are still missing at this mentioned XML descriptor file matching with point. VRML hierarchy/geometry files, thus generating an In CAD systems it is quite often the case that more internal multibody model out of the CAD informa- parts in an assembly share the same name (you can tion. In RobotMax the internal (original) model can imagine a “template” part that has been used many be extended interactively with various electrome- times as a building element). On the contrary, in case chanical elements (e.g.: with parametrical motors of the target language Modelica, the variable names from a model library: see section 4.1) to form a must be unique inside each model. Via translating more complex mechatronic (multi-domain) model. the mechanical CAD information, a single, pure me- Finally, our tool is able to export its final mecha- chanic Modelica model has to be generated first. tronic model to Modelica models using the built-in This initial model contains only the parametrical conversion module, and on demand by the same bodies and the mechanical joints, which are con- time it propagates the geometry to DXF format nected by “connect” Modelica clauses. All exported mesh files, in order to use those as visualizing bodies and joints must have an individual, unique shapes in Dymola environment. instance name. The Modelica Association 720 Modelica 2008, March 3rd 4th, 2008 − Automatic Model Conversion to Modelica for Dymola-based Mechatronic Simulation As the auto-generation of VRML and XML files are 3 Expanding the standard Modelica independently done, the partially auto-generated library names inside the result files (e.g.: “ Obj01 ”, “ Obj02 ” vs. “ Obj ”, “ Obj-1”) will neither be globally unique The Modelica Standard Library is a standardized and nor match each other. In order to find the corre- free package that is developed together with the sponding entities both in VRML and in XML do- Modelica language by the international Modelica mains, you have to follow a sophisticated procedure. Association [8]. The Mechanics Multibody Library This is in the most cases inevitable, because there are (MML) is a package in the main library providing 3- usually less XML bodies than actual VRML geome- dimensional mechanical components to model me- tries.