Discover the flexibility of iLogic in Inventor to improve your processes.

PASCALE BRASSAT: Hi, everyone. This is a presentation "Discover the Flexibility of iLogic in Inventor." And today, I want to talk a little bit about the possibilities you have with iLogic in Inventor and what iLogic is in general. And I will also show you a little bit of an example. And let's continue.

OK, first of all, a little bit of general information about myself. So my name is Pascale Brassat. I'm working at Claudis Peters Projects in Germany.

Since 2007, I'm using Inventor. And since the version 2010, I'm using iLogic. Back then, it was a small add-in you had to add to your program to use iLogic.

My background is, I learned technical draftsman. And then later on, I studied at university mechanical engineering and informatics, so it was a combination of both. So I bring a little bit of both worlds together-- the 2D stuff, this 3D modeling, the engineering staff and informatics. And it helps a lot.

One of the main products I want to talk about and we are using in this presentation is Inventor. Inventor is a 3D CAD system of Autodesk. I think I don't have to tell much more about it. It's a parametric system, and that's the main word, you can say.

And the other one is iLogic. iLogic is an add-on that is fully integrated in Inventor, so it is directly inside of Inventor. When you install Inventor, you directly have access to iLogic.

iLogic, you can compare it a little bit with VBA, the Visual Basic for Applications in the past. It is also dialect of Visual Basic, so it's written in the same manner, you can say. It has some additional functionality that is even not included in the API, like component.component Inventor elements. So that's something even the API doesn't have.

iLogic is very easy to learn, from my perspective, because it's like writing a simple text-- so if something is happening, then do something. And so you do not have to pay very much attention to very specific syntax, like having specific brackets or semicolons at the end or whatever. It has flexible usage. That's a very good thing. So you can use it in nearly every environment inside of Inventor.

You can use it inside for drawing stuff. You can use it for modeling. You can use it for your presentation.

You can use it for nearly everything. So you can also use every functionality in the API directly inside of iLogic. So that's a very good thing.

So you can write text out of your Inventor. So if you're not happy with standard parts list functionality, for example, you can also bind Office products to it, so that's quite cool. That's also a possibility of combining it with external tools like the standard dotNET. So if you have Visual Studio, for example, you can directly use it from there.

Another thing which is quite good is event triggering. So you can directly decide when a rule-- a rule is a small program inside of iLogic code-- is being triggered. So maybe you want to do something before the document is saved. So you can say, OK, Before Save. So when the user hits the Save button, then this event is triggered, and maybe you fill out some iProperties or whatever.

From my perspective, except the frame generator, you can say everything is up to your hands what you can do with it. So tons of possibilities, really. So limitless, you can say, from my perspective

Now you come to the big question-- but what can I do or what should I do with iLogic? So I have iLogic as technology at my hand. So what can I do with it? So you have a quite cool tool, but how to use it?

So from my perspective, you have three recommendations. First of all, as a repeating an easy-to-solve task. So that could be something like you want to reduce five-click daily task into one click. So just hit the button, and it's doing something.

Or maybe reducing the failure inside of filling out iProperties. So maybe only just transport value from textbox 1 to textbox 3, and 4, and 5, and 6. So that's a daily task that you do maybe hundreds of times a day.

But each time, it takes a couple of seconds or minutes to do. And it could be easily performed by a simple program. That's the first step, I would say.

So the second step, where we as a company are using it mostly, is to create part libraries. So we have our own components we are using inside of Plant design. And we have millions of variants, so really thousands of options, and so on. And it is quite easy to create a simple model which can fulfill all those different variants.

So you have maybe only 10 lines of code. But it could result in thousands of possible variants. And so if you try that with iParts, for example, you will fill out line after line after line. So it's quite more work to do than just simply create it inside of iLogic.

And the third recommendation, from my perspective, is, if you have a task which really needs specific knowledge of a person in your company, you can also use this user's knowledge and put it inside of a program to preserve it for the future. For example, I have no big knowledge of a specific product and/or company, but I am needing to use it inside of Plant. So it's easy for me to use it, and place a part, and configure a part, for example. And in the background, some programming is calculating the correct shape, or the correct design, or whatever.

It controls everything that is set by the program. So I as a user do not know anything about the product itself. I only know where it's being used. But the rest was done by somebody else. So that's a preservation of knowledge inside of programming, inside of a part. That is something we also do very often, you can say.

It has also to do with age structure inside of the company. So today, it's more like one person is leaving the company, and knowledge is almost gone. If he's old enough, so he's leaving the company.

And normally, you're replacing this person today at the date when this person is leaving the company or maybe one month earlier. So the new person has no time to really learn this knowledge. So you can have manuals, yes, of course. And we also have them. But to have it directly inside of the product itself helps a lot.

Now we come to a simple example for these three recommendations. The repeating simple task-- in this case, for example, it is this 3D model of a simple part. But normally, we don't only need the 3D model, we also use the 2D. Because we have very complicated plans, so we do not have all the features inside of 3D and so on.

So maybe you customize a building. And you do not have the building, but you have a 2D plan. So in the shop, the time is too short to create this 3D model of the building to give maybe a proposal to the customer. So in this case, we are using 2D.

So in this case, we have this 3D model, for example. So this is just an example. It could be much more complicated.

But we are needing-- because the people who are using 2D are not fully in the control of the 3D. So they know 3D, of course, but they are not in daily use. So maybe it's taking them too long to create the 2D views of the 3D model.

So it's easy for us to say, OK, I open up the 3D model, go to a drawing, and just say, OK, I need all the six standard views of this part. In this case, we are placing only the front view of the part. And then we are hitting a button, selecting the front view.

And then it will create the six views of it and will place them nicely so that you have all the same distances between the views so it's really looking nice. And then you can send this drawing directly to the person who is needing it in 2D. So it's perfectly done.

And afterwards, you can also say, OK, from all our products, I want to have the six views. So you can also say, OK, let an iLogic rule configure all the parts to the possibilities, save them all, and then create drawings through all of them. So that you can create a 2D library, for example, completely automatic in the background. So that's also possible. So that's just a simple example of what to imagine, what is possible.

The library itself-- we have this injection duct we are planning. And as you can see, you need only a few parts to create a piperun like this one if you had it, say, configurable. So you can say, OK, I can choose the angle of the bow, or I can choose the sizes of the straight duct, and so on.

So you can just simply create piperuns like this one with only a few parts. So that's the second one. So that's very, very easy to do and very, very effective to use.

The last one is the most complicated one, I want to say. So if you really want to put knowledge inside of the programming, you have to do a lot of research at the beginning. Yes, for sure. But later on, it is really worth the effort.

So you're really sitting there, and you're just using a part. Or you're just typing in a value, and you get the correct result, and so on. So you can do this kind of stuff inside of iLogic. And it helps a lot.

So in our case, we have, for example, the cooler system which is quite complicated. It has lots of variants. And it has a lot of things to think of, really.

So you choose this design, the other design is not possible. Or you can only choose different sizes if you have chosen a different design. The dependencies between all those values are set in the background.

So if you choose option 1, then it goes straight forward to the next options. And if you choose another option, then it goes to the next question for the user. It is not possible to choose something that is technically not possible.

And that really saves-- it really makes it easier for all in the company to say, OK, what comes out of the First Department, for example, is really working. And if you need some special designs, of course, it's always possible. But we have to have a part that is really good from the beginning. This is worth the effort.

And for me, later on, if I had a job, for example, I'm not doing very often, so I have it one time a year. But if I have it one time a year, I need to dig into thousands of manual pages and so on to learn how it works. It costs me much more time to do that once a year then to have it done one time ever to have it inside of the program.

Now the thrilling question is, how can I solve that with iLogic? iLogic from the basic needs nothing more than Inventor, that's it. So we only need Inventor. Inside of Inventor, you need iLogic browser and an idea, of course.

So you need to know what you want to do. The most important thing for you is, you need to split an idea and multiply ideas. So that you say, OK, this idea is maybe too big.

Maybe I split it into two different ideas or two different projects. So that you are splitting your main idea into pieces to say, OK, I solve piece after piece to get the whole thing done. So that's the thing, I can say, sometimes it helps.

In iLogic itself, for the starting, if you never have done anything with Visual Basic, the snippets are helping a lot. So inside iLogic editor, on the left-hand side, you have a browser with tons of features you can use-- how to change the parameter, for example, how to suppress features, how to work with drawing sheets, put out a message box, and so on. So it is tons of prepared stuff that you directly can use.

So it's not like in VBA in the past when you record a macro or something like that. But it is quite helpful. And you can also save your own snippets there. So if you have a line you always need inside of your program, whatever it is, put in inside of the snippets and use it.

And don't forget about the options. The options in iLogic means you can decide if you want to trigger a rule automatically. So maybe if a parameter is changing, then you can directly say, OK, if a parameter is changing, and this parameter is inside of a rule, then this rule will be triggered automatically or not.

So we are using that normally not only in case of the major rule. So we have in the parts a major rule, which is controlling the sequence of everything that comes next. So that makes life easier and, in overview, much more better.

For user, a very important tip is, don't search inside of Google or whatever. Don't search for iLogic in a specific search. It could be that you find the correct answer. But normally, it's hard to find.

In the past, it was much more hard to find because iLogic was not so big. But if you search for maybe VB.NET as additional search term or API, you will find something that looks like iLogic. It is mostly dotNET. But you can directly use it inside of iLogic with small changes.

So maybe the Application object-- for example, Inventor.Application-- is maybe not Inventor.Applicatiom inside of iLogic. It is This.Application. Or you have This.Document or something like that.

So that's iLogic. But you have only to make small changes to make it work inside of iLogic. And you have a very large number of entries or results inside of internet search you can choose from. So that's a very important tip.

So how it looks in iLogic if we will do some programming? If you have seen Visual Basic for Applications, you will directly see, oh, OK, I know that. So in this case, it's what I told you. It's the readable style of iLogic.

So you can just can see that I have written, you can directly read it. If the document type of the current document is a Part document, then continue, otherwise, don't. And then in this case, it's a combination of multiple surface bodies into one. So it's just a simple example.

So you can see you are counting the surface bodies. And if the number of the counting is larger than 1, then please continue, because 1, you have nothing to combine. And then you are collecting all the surface bodies and placing it together to one. So that's coming at the end. So it's very, very readable.

So sometimes, you really must know a little bit about what you have to type in to get this out. If you press dot, that it offers you something you can do with this function. That's a little bit better when you do direct programming in dotNET, but it's working quite well. So it's working quite well.

And you have access from the iLogic editor directly to everything inside of your model. So you can directly use all the user parameters, you can see all the features, you can see everything. So you can just get access to everything.

So if you want to change your parameter, it's very easy to connect it with a different parameter. It's very easy. So I really don't use the Parameter dialog anymore except creating new parameters. The rest is done completely in iLogic.

So iLogic events, I talked a little bit about it. It's After Save Document, or Before Save Document, After Open Document, or the event trigger starting on any parameter change or whatever. We are also using this kind of writing. So we are saying, run the rule automatically, but only on reaction to a parameter change.

So then we are just typing in this simple line and saying, OK, if PDM_T is changing, then please run this rule. That is everything this line is doing. So it's not that we want let a rule run on each parameter change. So we only want to run it on specific parameter changes. So that's how we do it.

You can also create very simple iLogic forms. As you can see, I'm not a native speaker, I'm coming from Germany. So the dialog box is still in German.

Sometimes, it's not so easy to change your parameters inside of the Parameter dialog, the classical one way to define new parameters. So in this case, iLogic forms really help. So you're just saying, create a new iLogic form.

And then you can also create external rules, and global rules, and global forms, and so on. But if you want to have it only specific for one document, you just simply say, add a new form. And then you can drag all the parameters from what you want to have inside of the form for the user. So that's quite nice.

If you had the Parameter dialog box, you have all the parameters. So the user doesn't really know what to change. So you can mark them as key parameter. Or maybe you can write a comment or whatever. But it's hard to control.

So it can end somewhere where you think, maybe this one is the right one. So then he destroys the model. So in this case, you can directly guide the user a little bit from his perspective to the correct values.

And you can also rename them. So we are always using dem_ at the beginning, and we don't want to show it. So you can make it as a clear text. So you can maybe say, OK, I want to have a plate. I want to have a socket with height, depth, and if you want to have a handle or not. So that's working quite well and is very, very useful.

Combine multiple solutions-- what do we mean with that? What I told you earlier. So please split your ideas in smaller pieces because it's making a better overview. It's very hard to have some kind of 1,000-line program, where you need hundreds of hours to get through to find what is done and in what position. So that's what I mean with combining it a little bit.

At Claudis Peters, most of the times we have per document one main rule. And this main rule is starting some sort of a sequence. It's not like the legacy order that you're placing the rules inside of iLogic, and it's running from one to another rule.

So we are really saying, OK, we are starting one rule. And this rule is calling all these up rules. You can also create it as a subroutine or subfunction inside of your iLogic, that's possible. But in our case, it was much easier to create simple standard rules, you can say, that are repeating in all of the parts, so in all of the documents.

So we have, for example, the Size, Cases, and so on. Instead of height, name, weight, hollow stuff, and so on, we have standard rules that are appearing in all other documents. And it's quite easy to create them very automatically and say all of them are there. And then you have only two or three that are different per document. And that makes life quite easy because we have also come to that in the next side.

You really have the possibility to create also external tools which are creating rules for you. That's also possible. And it's very easily possible, you can say.

So we have created a tool that is doing, you can say, mainly programming. So it's identifying key parameters and then setting something more. So as you can see, you can call rules from the same model. So you can just say, OK, I want to run this rule at this point or this time. And then you can also say, I want to change parameters, or I want to call rules inside of a component inside of an assembly, for example.

And the other important thing is that you have to think of the name. So please change the browser name of your component so that's easier to identify, so that you do not have maybe the file name or something like that. So just rename it somehow that you can identify it a little bit better inside of your iLogic. So that's just the tip, and it's working quite well.

Combining technology from iLogic with other technology-- let's say you are using something like a dotNET program you've written. If you see this line here, for example-- you can call every program you want from inside iLogic. So you can just say, I want to have this program open at this point.

So maybe it's doing something. So it's providing a list or something like that that you need for the next step inside of your iLogic. Or maybe you had a calculation program or something like that. So you are just doing something, and then you say, OK, at that point, I need this calculation program inside of Inventor.

You do not have to search somewhere else. Just put it inside of the global forms, for example, as a button. Press the button, and then you have your true. And in this case, it is an example-- iLogic creator tool we are using in the company.

So we follow standard library parts. We have what I told you, an amount of same rules in each part, so they are not deferring very much. So you're building up a model, and you're deciding which are the key parameters. You're giving the parts the correct names, and the components, and the features, and so on. So that's according to regulations that you have to rename the key parameters in the specific way, for example.

And then you're starting a program. And it's reading all of this information. It's looking through the parameters and say, OK, you have key parameters. Key parameters are maybe user-chosen parameters, so that has to come inside of iLogic form or something like that.

And then you can also define limits, for example. You can say, OK, if it's a minimum value or the maximum value, you are only adding minimax to the parameter name and entering some values. And then the program is also reading this as a minimum and maximum and directly using it also for the dialog boxes for the users, so that the user is only able to change parameters inside of limitations.

And it's maybe also to add colors to a part which are not standard, for example. So in our case, we are needing a special red transparent color or something like that, which is not in each of the templates, for example. Or if you get a native Inventor file, and it's not there. So just simply add this color to this part.

So you can also solve it with iLogic. Just hit the button, the color is there. So you do not have to look for template, import it or whatever. And that makes life very, very easy.

And in my daily work, if I do something, I really think, is it possible to automate it in some way? So is it possible to make it easier? And also colleagues of mine are coming around saying, Pascale, it's taking too long.

Every 10 minutes, I have to do this step, and it's getting on my nerves. Can we make it automatic? And most of the time, I can say, yes, we can. So it is very, very simple to do also.

We have a large amount of solutions in the moment, where we can pick all the right ones and just combine it differently. And so you have a new tool, you can say, or new combination. So the cupboard is full of tons of ideas.

It's quite nice if you have someone in the company who's doing programming in dotNET, for example. Just use technology from them to combine it with your tool. It's also possible.

And the conclusion of everything is that iLogic is a very, very flexible tool, in my opinion. I even cannot really imagine of a thing that is not possible. It's only a matter of time.

So if sometimes an idea takes a little bit longer to solve, but we have also the Autodesk forum to discuss, to ask help, and so on. So read it to say, I want to solve this problem. Is it possible?

And it's a very nice community. So you just can ask a question, and most of the time, you will get a very good answer and very quickly. And it's very helpful.

And normally, you just as a beginner, it's hundreds of thousands of possibilities you can use. So just if you say, I need to create a rectangular shape, for example, and always in the same manner. So just create a button. Or more complex shape. Maybe a rectangle was a bad idea, but a little bit more complicated shape.

But you always need it. And you need parameters for it and so on. Just do iLogic, which is creating your parameters inside of your model. So you do not have to create a template or something like that. Just use a simple template, do everything else as a programming globally. And just press a button, and everything is there.

So you do not have to think about hundreds of templates. Or you need multiple templates because user 1 is not using this, and user 2 using it, or user 3 using it differently. So just forget about templates and creating everything inside of the templates.

Just think about the possibilities of iLogic. So hopefully, it was a little bit fun to follow, and it was something you learned out of this presentation. And I wish you all the best.