Which companies are using Catia in India

A practical semester in India

What may at first sound like the headline of a story with a dramatic outcome from the pen of George Orwell, in reality introduces an article that should briefly describe what this Nico actually works on throughout the day. As one or the other from the group of highly esteemed readers may have already taken from earlier entries in this blog, the writer of this text can call himself a student of computer science. Well, what among other things do computer scientists do? Right, they write programs! During my internship at MBRDI here in Bangalore, I was given the task of implementing a specific program. What made it necessary? What should the program be able to do and what is its current status? These and more exciting questions will be answered below!

Question to the reader: How would you proceed if you were given the task of using a CAD system such as, let's say, CATIA v5 from Dassault Systèmes to generate a gear whose properties must be taken from a corresponding drawing? Let us assume that the result is a gear whose teeth are in the shape of an involute. This type of gear is extremely important in mechanical engineering not only because of the simplicity of its manufacture, but also because of the many advantages it offers: The favorable meshing ratios of involute gears ensure uniform torque transmission and also have the pleasant property of lower noise levels. and heat build-up when compared to other types of gearing. Let us also assume that you have two options for successfully completing the task:

  • Manual construction, an activity that is not only time-consuming but also quite complicated, as some values ​​have to be calculated from the input parameters of the drawing, which are needed in the course of the construction and whose formulas in turn have to be taken from one of the international standards.
  • The automated construction via a program that allows you to enter all the required parameters in its user interface and then, after you have clicked on an inconspicuous button labeled "Create", the associated gearwheel with the aid of the CAD program within a few seconds generated.

For all readers who have come to the conclusion in this second that option two is the more pleasant and better choice - and most of them should be - I now have bad news: Said program only works with CATIA v5. This fact would not be a problem at first, if it weren't for the small but not entirely unimportant detail that a momentous decision was made at the highest level of Daimler AG in 2010, which probably pissed off some people at Dassault Systèmes brought: From 2015 the entire group should no longer use CATIA as a CAD system, but the NX program from Siemens / Unigraphics. I am unable to judge whether this decision is correct or not, but what is certain is that licenses for CATIA have also become a valuable asset at MBRDI these days, because they are extremely rare - there are still a few licenses because the migration work to Siemens NX is still going on are not fully completed, but it would be extremely difficult to obtain one of the coveted licenses to run the gear production program, even if only for a few seconds. So what do you do if you want to create a gear in NX? In the end, all that's left is manual construction, right? No not really! This is exactly where the scribbler of this text comes into play, whose project task is to rewrite the same program for automated gear generation in such a way that the user can enter the same parameters and then get the same gear as the old one Program based on the former - just in NX and not in CATIA (NX version 10, mind you). The necessity of the project is therefore clear, and the advantages for the user are obvious: Let us assume 30 seconds for the time that the program needs to generate a gear from the values ​​entered by the user manual construction, which according to the local colleagues would take a full working day of about 8 hours, 30 minutes, an acceleration of about a factor of 1000! A question like “What would change in our gearwheel if we set parameter X to value Y?” Can of course be answered in no time using the 3D model in Siemens NX, even simple analyzes of the geometry and thus their quick and easy comparison are made possible by the program. The task of my project is roughly outlined, but of course I don't want to withhold a more detailed view from the readers! Before we deal with further considerations, however, here is a brief information of a general nature: For various reasons I am not allowed to publish the name of the program, which is why I will simply call it "The program" in the following, based on the title of the article whereas its predecessor, which created the gears in CATIA, is called "The Old Program" (yes, it is very creative indeed!).

Perhaps one of the esteemed readers has already asked himself how a budding computer scientist should write a program that uses precise user input to generate the associated gear in Siemens NX, a task that requires a deeper understanding of what a gear actually is is to be constructed and which connections of its properties result from it. In addition, for such an undertaking it is probably not entirely awkward if the writer of the program is already a little familiar with Siemens NX. In fact, in the course of my studies so far, I have been able to get to know numerous meaningful and important things, but so far, topics that would have dealt with CAD systems or even with gears have not been among them. So it happens that my knowledge of the above-mentioned topics is quite manageable when I start working in the trucks department of MBRDI in Bangalore at the beginning of March 2015. When I see the source code of the old program for the first time, three things quickly become clear:

  • Oops, the old program is implemented in Visual Basic 6, a programming language that I didn't know at the time. Thankfully, however, the focus of Visual Basic is on being easy to learn!
  • Oops, the old Visual Basic 6 project cannot even be compiled: Too many CATIA-specific libraries are already missing at this point and since the source code accesses them very often and very early in the program sequence, it would not make sense either to simply remove the references to the libraries from the project. Debugging the old program bit by bit as it interacts with CATIA and getting to know how it works is no longer an option.
  • Oops, from point two it follows that hardly any parts of the old VB-6 project can be reused. The nice thing, however, is that all of the formulas that my colleagues put together from one of the international standards for calculating numerous values ​​from the input parameters at the time the old program was implemented, can be transferred almost identically to the new program!

Before we can start working on the implementation of the new program, some not entirely unimportant framework conditions have to be defined:

  • How will the program communicate with Siemens NX?
    A server-client approach is available for this: The server is started in Siemens NX and only has the task of wrapping NX-specific objects nicely and with a loop, in order to then publish them on a local URL and then go to sleep . The client - "the program" - fetches the objects from said URL and unpacks them again so that they can be used to communicate with the system via the NXOpen interface and to be able to carry out individual actions.
  • What is the procedure for the question of when NX actually has to perform which actions?
    First of all, it is very important to understand which individual steps the old program carries out to generate the geometry in CATIA. These then have to be mimicked in NX and recorded using the journaling tool. This extremely useful tool offers the possibility of recording individual steps that NX takes “behind the scenes” when the user is doing something specific in the graphical interface. Example: A user creates a line from point A to point B (this line could, for example, be the X-axis of the local coordinate system for the geometry to be created). In this case, the journaling tool produces source code in Visual Basic .NET (alternatively also in other programming languages) which, when executed again in NX, produces exactly the same line. The procedure is clear: Using the source code of the old program, use the source code of the old program to divide the generation of the gear wheel into many small, atomic steps, execute them in NX and record them with the help of the journaling tool, in order to free the output of unnecessary ballast and to generalize so that, to stay with the example just mentioned, the generation of the line does not only work from a certain point A to a further certain point B, but rather with any start and end points. The choice of programming language fell on Visual Basic .NET, also because the colleagues who implemented the old program in Visual Basic 6 will probably feel at home in the new programming language immediately, should changes or extensions have to be made when I do I'm back in Germany once again and at least can't be in Bangalore anymore.
  • How can you ensure that the program is easy to maintain and expand?
    The old program refers to CATIA very early on - all calculations are carried out in conjunction with the CAD system, a fact that is unproblematic as long as the system is available. As we have already noticed, however, CATIA licenses are very rare in the fields of Daimler AG and thus also in its subsidiaries, which means that the old program can no longer be executed. This fact gives cause for reflection: Can't the new program be made at least to a certain extent independent of any CAD system? And: Is it possible to write the program in such a way that only a certain module has to be replaced if a new CAD system is to be operated again, so that only this particular component has to be rewritten, but not the entire program? Both, my dear readers, are possible!

After these framework conditions have been established, the following rough picture emerges for the architecture of the program:

The four layers of the program.

Now let's take a small leap in time! How were the framework conditions just mentioned implemented or, in general: What is the current status of the program? Let's divide the answer to this question into the four different layers of the program:

The user interacts with layer 1 of the program, the graphical user interface. Its task is to receive all input parameters and, if the user so wishes, to save them in a database. Even the old program was completely independent of CATIA in its user interface. What does the user interface look like now?

The main window of the program. I entered the values ​​at random; they are neither read from a drawing nor do they come from an internal database.

Perhaps a reader is wondering what about the colored markings in the ValidationArea on the bottom right. Pay attention! Well, the four values ​​that are highlighted here with green or yellow are entered by the user, who in turn has taken them from the drawing. Using the other values ​​from the drawing that he entered, the program then calculates the values ​​itself in layer 2. If an entered value matches its calculated equivalent, it is highlighted with a green background, if not, it is given a yellow background and the calculated value is displayed immediately below it. In this way, the user has the opportunity to validate his input values ​​- if he has entered a completely wrong value anywhere, the calculated values ​​will deviate more than just a hundredth or thousandth (as is the case above). This means that the program provides feedback at any time about the correctness and completeness of the values ​​entered.

In layer two of the program, the calculation of the values ​​takes place which are necessary to validate the user input and which are partly required later in the generation of the geometry (layer four). Layer two is also independent of any CAD system.

Finally, layer three ensures that all values ​​that have been calculated in layer two are written to an XML file. This fact was preceded by a fundamental consideration: Should the calculated values ​​be made visible to the outside world at all? The answer to this is: Yes, that is desirable, because even if NX is currently not available, the user should still have access to all values ​​that are in the course of the program execution up to the point of an error message that the program cannot access NX may have been calculated. This makes scenarios conceivable in which a user can use the values ​​for other purposes and at will. However, some readers may have noticed that layer three also creates another file: the NX-specific one Expression File. In the course of the execution of layer 4, if a connection to NX can be established, this is imported into NX via the server-client connection and then serves as the basis for all further steps that are carried out in layer four. Even if NX is not available, it will Expression File generated.

The execution of layer four only starts if the program can establish a connection to NX, which is exactly the case when the user has started the server in NX that publishes the specific objects on the local URL. Once this is done, the objects are unpacked again in layer four and then used to create the gearwheel step by step. This not only contains the values ​​that the user entered in layer one, but also all those that were calculated in layer two based on the former and finally written into the XML file in the course of layer three (the NX- specific Expression File Due to the requirement that the entire geometry must be fully updateable even after it has been created, it only contains the direct input values ​​as simple numbers; all other parameters are imported with their formula into NX, which then carries out the entire calculation again in a fraction of a second - this redundancy is accepted so that the user can access all calculated values ​​in the form of the XML file even without the availability of NX Has).

After roughly considering the four layers of the program, a crucial question now arises: To what extent has this structure achieved the goal that the program should be able to be expanded as easily as possible? Well, in the end only layer four is dependent on NX, all other components of the program also work without any activity from the CAD system. The interface between layers one to three and layer number four (“layer” - my favorite word today!) Is deliberately kept very narrow; only that Expression File connects these components of the program with one another. If a new CAD software is to be used, all that needs to be done is to write a new module for layer four that is able to interpret and transform the general information in the XML file so that it can be used to generate the gearwheel this new CAD system can run. On closer inspection of this approach, however, a disadvantage of the same quickly becomes apparent: How can layer four transfer information back to the layers above, in particular to the user interface? Completely right - not at all. Example: It would not be possible (or better: possible yes, but rather chaotic) to implement something like a simple progress bar in the user interface - due to the narrow interface between CAD-independent and CAD-dependent program components, corresponding information cannot be passed on.Layer two can (and must) communicate with the user interface, for example - it is necessary that the latter has knowledge of the validation results - but once we are in layer three, there is no turning back, because then communication is only possible Be done “downwards”, never the other way around.

Now, after we have briefly dealt with the various layers of the program, it is time to take a look at the execution result of the program, which is to say: a finished interlocking that is created when the program is executed with the input values ​​shown in the user interface above .

A possible execution result in Siemens NX.

What further steps should be taken in the program? Well, it is planned that a head break and a bevel on the face will be implemented soon, but apart from that, the program is in its final stage. Of course, at such a stage it is important to check whether the execution results are really correct, and since the top edge breakage and face chamfer are additional features that the old program was unable to generate, numerous test runs have already been carried out and then theirs Results are not only compared with profiles that were originally created in CATIA by the old program and then saved as Dumb bodies (“Stupid bodies” that have neither generation parameters nor updateability) have been imported into NX, but also with those that are the result of analysis software that is very often used at MBRDI.

Comparison of a tooth profile with its equivalent generated by the analysis software. The deviations are ...

... from case to case sometimes a little more, sometimes a little less, but unfortunately ...

... I have not yet managed to reduce it to less than a few thousandths of a millimeter. Yet…

... the program could already be used successfully in the course of a simple analysis!

Finally, I would like to draw a brief interim conclusion. Of course, it is correct that my knowledge of the Siemens NX CAD system (version 9 at the start of the project, the update to NX 10 has now taken place) and of course the question of how a gear is actually designed was very manageable ( not to say: zero…). Of course, it is also true that I still cannot describe myself as someone who would be particularly well versed in the areas mentioned, but I believe that I have been able to gain numerous, very valuable experiences in the past few months, not least Visual Basic .NET, which I had never gotten to know before, turned out to be an extremely powerful programming language that I enjoyed working with shortly after the start of the project. Much more important, however: Working with the NXOpen interface, with NX itself and of course with gear-specific questions was a lot of fun! Of course, I also owe this to the great team and my great boss, Albrecht Köllermeyer, who also taught me some important things that are not of a professional nature. The visit of the professor who supervises my project at MBRDI, Prof. Dr. Peter Heusch: During his one-week stay, he was not only able to establish numerous contacts with well-known IT companies in Bangalore and thus make an internship in Bangalore much easier for students of Faculty C of the Stuttgart University of Technology - internship applications usually get lost in the documents of various HR departments, so that in these cases without personal contacts the chances of success are very limited - but also support a certain student in his project. All in all, in view of the extremely interesting work here at MBRDI, I decided to also deal with the topic of NX automation in the course of my bachelor thesis - if someone has fully penetrated and understood the NXOpen interface and knows how to use it correctly, so the possibilities of what is feasible with the interface must be virtually endless!

Posted on by Nico Krieg Posted in GeneralTagged automation, automation, CAD, CATIA, Daimler, MBRDI, NX, practical semester, program, Siemens, gearing, Visual Basic, gearLeave a comment