Not Quite AI, but Close—Design Automation with Inventor

THOMAS FITZGERALD: A little bit of a demonstration, instructional conversation if you will, about Inventor Automation. And what it entails in terms of putting or implementing some sort of automation into your company. There's a lot of PowerPoint slides here.

I did, however, create a data set that corresponds with this PowerPoint. So, if there's anybody after the class that would like a little bit more information, I'll be more than happy to pull it up on the machine. Show you the ins and outs of everything but mostly it's just going to be me talking. And then of course, at the end, you guys can ask them questions if you'd like, all right?

Let us begin. Of course, if this is the class that you're supposed to be in. If you think this is about an artificial intelligence, I'm sorry it's really not. This is just all about Inventor. I just thought it was a catchy title, so. Good. I'm glad you're here then.

So, this is me. Tom Fitzgerald. I've been without Autodesk for about-- or just over six years now. I'm an implementation consultant. I focus primarily on Inventor, Inventor automation, iLogic, Vault, and anything related to that mostly in the manufacturing space. OK? I've been a CAD user since 1998.

I got out of the military in 1996 after serving seven years with the United States Army. Let them pay for my college instead of me paying for my college. And then started getting into CAD design, mechanical engineering. And then in 2003, I went and got my certifications for my Microsoft Systems Administrator. Not only do I know the CAD systems but I know networks as well.

And then, yeah. So in 2004 I got that. I got recruited from Autodesk in 2011. Prior to that, I was an independent consultant kind of doing my own consulting work surrounding Inventor automation and Vault work. And then Autodesk said, hey, why don't you come do that for us instead? So I said, sure.

I am a percussionist, a drummer if you will. My passions are World War II history. So, if any of you World War II buffs out there, I'd like to have some conversations with you guys as well. I just started getting into drone flying. So reality capture in drones, really cool stuff. I got my pilot's license.

I also own a Jeep. I live out in Phoenix so I do a lot of off roading, which is a lot of fun. And as stated before, United States Army Vet. That's me in a nutshell.

So. This class. Inventor automation, what is Inventor automation? A lot of people might have their own interpretation of what that is. A view that our use in Inventor, I'm sure to some degree you have some inclination what Inventor automation is.

There's a lot of different ways that it can be interpreted. There's-- basically it's a means for us to be able to understand and get a grip on the repetitive tasks. Those things that we do on a regular basis, every single day, over and over and over again. That is a perfect opportunity to implement some sort of automation.

Why do these things repetitively? Why create opportunities to create mistakes? Have some sort of syntaxed automation application if you will, that can take care of those tasks for us, OK?

Some examples of some Inventor automation. You guys are familiar with parameters, right? You can create a parameter, give it a particular name. You can then associate that parameter to say, maybe a feature if you're talking about individual parts. If that parameter equals a particular value, you can suppress that feature. Or unsuppressed that feature. That's a very rudimentary or basic way of creating a little bit of automation. Being able to control your models that way.

Another way is iLogic. Who's familiar with iLogic? A lot of people. Good, good. Good. I've been working with iLogic since, what? 20-- 2009. 2009, 2010 time frame. Built a couple of demo sets. Anybody seen my conveyor out there? I built a conveyor. I also built a playset. You guys might have seen that one as well, a little play set that has some swings and slides and things like that.

The demo set that I created for this class is-- takes that to a next level. Kind of incorporates some of the lessons learned, if you will, over the last few years-- few years working with clients like yourselves. Understanding what the true need is that you have in terms of automation. What is-- what do we really need to accomplish?

And then of course, you can take it to the next level, where you're writing VB.net code within Visual Studio. You know, I'll put that as an add in. Incorporate it right into Inventor and have all sorts of things occurring in terms of building models, building assemblies, creating drawings. You can do all sorts of different things with your Inventor automation in that regard. OK?

Yeah. Creating iLogic rules to update or format iProperty information. That's a big one. If you're doing that with your templates where you have particular iProperties that you want to make sure that the values are formatted a particular way. Or if a value is an acceptable value. You know, that's a good opportunity for Inventor Automation as well.

Why would you want to use Inventor Automation? Well, you know, if you take 10 people and you put them in a room and you gave them a seat of an Inventor and you said, build this model. What's the chances that every single one of those models is going to be exactly the same? Probably not, right? So, Inventor Automation is an opportunity for us to make sure that we have a level of consistency we wouldn't otherwise have.

Everybody has different skills. Everybody has different ways of interpreting how to get something done. Maybe one person might use an extrusion as opposed to a revolution. You might get to the same place, but is that really what you want to accomplish? Does it really make a difference? These are the questions that you have to ask yourself.

So, it allows us to do more with the resources that we currently have. Anybody seen-- or everybody saw the keynote speaker yesterday when Andrew was up there talking about doing more with less? Making it better, right? Inventor Automation that's-- that's exactly what we're trying to do here.

Let's take the people that we already have, let's allow them to do the work that they truly need to do, and not worry about those mundane, repetitive tasks over and over again. We want high quality individuals with high skill sets to be able to work and make the money that they want to make, contribute to the company in such a way that is beneficial for everybody, and not have to do those simple little things over and over again.

Helps us reduce engineering bottlenecks. Now, if you had 50% of whatever you did in terms of manufacturing. If that was off the shelf, really modular, consistent. You know, that's what we want to work on. That's where you put your automation. That allow your engineers, your designers, your drafters, whomever, to be able focus on those custom things. Those things that you typically don't have to engage with or do on a regular basis. It allows your people to be able to do more with their time.

Produces opportunities to understand and evaluate the current state of your models and your processes. I mean, your models are your IP. That's the important stuff, right? You want to make sure those things are correct. You want to make sure the information that is within them is accurate so that way you can use that information in downstream business systems.

Say you're using a PDM or a PLM, some of that information that comes from those models needs to flow through that pipeline. Let's make sure that it's good here first. By understanding your design processes and your models, that's going to make that a little bit easier.

And then lastly, like I said before, your engineers and designers can focus on the things that are really important. Not those repetitive things over and over again. Work on nonstandard, or R&D, or even feasibility projects as opposed to the day to day activities.

In this class, like I stated, there's all sorts of different ways that we could do Inventor Automation. Very simple things like creating templates to some degree can do that. But in this class, we're going to focus on what I feel is the foundation, the starting point. Let's make sure our models are accurate. Let's make sure our configurations are good. And from there, we can work downstream. We can work through our processes, OK?

Here's a little video that I created. This is the data set. It's nothing more than a means for me, as a user, to plug-in some information and have Inventor respond to that information that I plug-in.

This data set is about building different rockets. I want to go to the International Space Station. Or I want to go to the moon. Or perhaps I want to go to Mars. Maybe my payload is of a particular size or particular weight. All those variables make a difference of what kind of vehicle is going to take me to where I want to be, right? So, that's what it-- in this class, that's what we're going to be focusing on is how do we do that? What are the things that are necessary to do that?

Four aspects of automation. Through my engagements with customers and the projects that I've been on, I've been able to boil down this type of automation to four different things. And those four things are, 3D models. The first thing, the most important thing is, let's make sure our models are right. And let's make sure we have some level of consistency. Some sort of standardization. Some sort of organization involved with our models.

Then we have external data sources. In my Visio workflow here, we can see how all that works together. We have Inventor as an engine to do all the work. We have a model, either a pool of models or a library of models, however you want to call it. And we use our user interface, if one is necessary, in order to answer the questions that we otherwise couldn't have. If there's criteria involved with our automation.

Sometimes a user, a human being is going to have to make that decision for us. If we can accurately understand our process and understand what all the different criteria and conditions could possibly be, we may not even need a user interface. Perhaps we can write it all out where all the decisions are being made for us. Because we-- were that intimate. We understand our processes that well.

And then lastly is the logic that ties all that together. What kind of logic is necessary in order for us to build this kind of configuration? Are we working with just individual part models? Do we have sub-assemblies? Do we need to engage with Vault at all? What about any of the drawings that might be associated to this? So, there's a lot of potential here. A lot of opportunity.

Once we have our foundation set, once we have the beginning good to go and we're comfortable with that, we can tie it all together. Using information from an MRP or an ERP system. That might be valuable to us. How can we use that? Why recreate information over and over again? Let's try to use it. OK?

Things to note in order to be successful with your automation plan. Obviously, you want a plan. You want to get together with the individuals that understand your processes, your engineering processes, the workflows, as well as you possibly can. Then you can-- you need to engage with these people and come out-- come up with a good plan of the different steps that you're going to take in order to accomplish that.

That requires specific individuals. People that understand Inventor very well. People that understand the Inventor API very well. People that perhaps might be a coder or understand different .net languages. VB, C sharp. Maybe they understand Visual Studio. You have to have all this knowledge and bring it all together in order to implement a good automation plan.

So, you start off with planning. Acquiring the right resources. Those individuals that know what it takes. Those individuals that are talented and that can provide and contribute to the overall project.

Need for visibility. You have-- you can't go through an Inventor Automation process or implement some sort of plan if you aren't into-- if you don't know what you're doing. If you don't know your information. You have to know your processes.

You have to know how you're building your models, what are they being used for? Understand every little aspect of it. And if you don't, put the team together that does. That's-- the power is with the people and they know what's going on.

What's the status of your models? I can't count how many times I've engaged with a customer that said, yes our three models are good to go. Of course, we have migrated in three years but they're good to go. No. Every single engagement I do, every single customer, there are files out there that you have no idea what's going on with them.

This is challenging. This is hard. I have customers that have over 4 million files in their PDM. I mean, how can you really grasp what's truly going on with all your models? Well, it takes that special someone. It takes a CAD manager or some other manager that has-- fully understands the power of what your models can truly do. And take care of them. And maintain them. You have to be able to maintain them.

And, do you have a standard? Believe it or not, some of you in this room, you don't have a standard in your engineering processes. You use Inventor out of the box. You're assuming everything is going to work for you the way that it is. And that's not the case.

Every company is unique. Every company does things slightly different. Inventor has the capability of being able to accommodate that, but you have to have a standard. Is that standard available? Does everybody have an ability to get to that standard? Do they have to jump through a lot of hoops to understand what that is, yes or no? So, have a standard. Build a standard. Come up with people that can put that together for you. And has it documented and available.

This last one. You have to know where you're starting from in order to know how to get where you want to be, right? We're all in Vegas right now. If I say, hey, who wants to go to Miami? Well, how do you get to Miami? Well, it depends. Are you starting from Vegas? Are you starting from San Diego? You have to know where you're at. You have to know the current status in order to proceed.

The first aspect, 3D model development. This is a big one. That's why I put it first. This is the big one. Everybody that uses Inventor has an idea of how to use the tools to build your models. But, how are you doing it? Are you doing it utilizing a standard? Do you-- have you created a series of different templates? Leverage those templates, create your templates. Make sure you have your parameters in there, your properties.

If you have a series of different templates that give you a starting point. Maybe it has geometry involved already. You want to turn on and off some different features. Whatever the case might be, leverage your templates. Don't assume that the ones you get out of the box are going to do what you need for them to do.

Implement design standardization. What are your iProperties named? What are your parameters named? Are you using material? I know a lot of companies that use the default material that comes out of inventor. They're not really taking or leveraging all the power that comes with that. Understanding mass analysis and weight and everything. Those things are important. Those things are important and you should be using them. If you aren't using materials or defining your materials accurately, please try to do that.

And then, your model development process. Like I stated earlier, do you typically use Revolution? Do you typically use Extrusion? When to use a whole as opposed to a cut, you know? Those things are important and understanding what the power of the different features or how you go through the process of developing your models is important.

And if you're not already trying to understand what they are and what those processes are, you should be. So, as you leave here and you go back to your workspace, please try to do a deep dive and analysis of your information. This is your IP. This is your money right here.

You know, previously when all we had was The Board or we had AutoCAD, you know, that was a little bit different. We had to make sure the drawings were dead on otherwise there would be mistakes. This is no different. You know, our models is where everything else is derived from. So, make sure they're accurate.

Parametrization. There's some people in AutoDesk that have a really tough time saying that word. But you should be levering parameters. User parameters versus model parameters. Who knows the difference? Who knows the difference between user-- yeah? Couple, three, four, five, that's it?

In a nutshell, model parameters are the ones that Inventor creates for us as we go through a design process. I create a rectangle, I want to extrude it. It's going to create some parameters in order to control that.

User parameters are the ones that we create. We have control of them. We give them a particular name, we give them a particular type, we give them a particular value. We have total control over them. Interesting to note if you are using model parameters, as you understand if you start removing some constraints and removing some dimensions, what happens those model parameters? Your D1, your D2, D3, D4? They start going away, right? You delete them, they go away.

User parameters don't. You create them. They stay there until you delete them. You can reuse them over and over again So try to use User Parameters as much as you possibly can as opposed to Model Parameters. I will take your one question, otherwise we're saving them for the end, OK?

AUDIENCE: In regards to the Model Parameters, are you actually naming all your model parameters as well as your User Parameters?

THOMAS FITZGERALD: Well, first, I don't use model parameters, I just let Inventor take care of those. Anytime I-- if I know that I have a specific parameter down I want to manage, I just create it as a User Parameter. Yeah, absolutely. But you can name your Model Parameters as well. That's-- there's nothing truly wrong with that. I'm just a consistency kind of person, so if you start down one path, you should maintain that one path. That's just how I roll, OK?

With User Parameters, we can create a number of different types. Is it-- is it a numeric? Is it a Boolean? Or true or false? Is it a text? Is it a multi-value? We have a lot of power with our parameters in terms of what kind of information we want to store within them and how we want to use them.

Naming convention. This is big guys. A lot of people, when need start naming their parameters, you want to be able to identify your parameters at any moment. You want to have some sort of standardization in terms of how you name things.

Some people use acronyms. Some people use abbreviations. Me personally, I add as much descriptive information in the name as I possibly can. So what if it's 20 characters long? Who cares? You just double click on it. Control C, Control V if you need it to paste it. You don't have to retype that. The important thing is to be able to identify your parameters and what do they do. So, use descriptive names as much as you possibly can.

If you use a descriptive name with a number, say I have parameter one, parameter two, parameter three. Always put the numbers at the end. As you start creating your different logic utilizing parameters, you will find that having numbers at the end is far easier than if they were somewhere in the middle. Like say, work plane one tangent or something. Don't put the numbers in the middle, put them at the end. Makes things a lot easier, OK?

Static or dynamic. Who knows the difference, right? Static models, they never change. Typically static models are things that we might get at a content center or something that a vendor might provide for us. Things that we don't have design control over typically are static models. Somebody provides it for us or we buy it or whatever. Something like that. Hardware, hinges, brackets, things like that that we don't necessarily create.

Static models. These things are the best. Static models, you don't got to worry about anything. You just go and you consume them. You bring them into your assemblies, you use them, everything's good to go.

Lack of design responsibility. At the last point, very rarely do you ever need to-- ever need to change them. Sometimes you'll put them into a library. I mean, if you're using a PDM, you might have them in a library. Nonetheless, static models, very easy to use.

If you do create them yourselves, though, try to incorporate Best Modeling Practices. And if anybody has any questions about what those might be, we have a lot of resource about what Best Modeling Practices are on the internet. Or you can talk to somebody like myself, I'd be more than happy to tell you what you may or may not be doing wrong.

All right. If it's dynamic, on the other hand, you know these things are changing. These things could change. Are they features that are changing? Or are they individual-- are they parts that are changing? If you are creating or using dynamic components, make sure parametrization. Make sure you're using your parameters accurately. You name them good. They're associated to your features as well as you can possibly make them.

And create a pool of base or template models. And the reason why I say that is because of this last point of, how can we reuse dynamic information? I mean, if it's one configuration in one assembly, you don't want to go and change that for another assembly because it could then alter the previous assembly it was being used in, right? You want to make sure they're unique somehow.

If you use a good naming convention and you do need to work with dynamic components, the steps are very simple. First, you need to identify, does this model already exist? And if so, then I'll reuse it. But if it isn't, then you can go to your pool of parts and say, OK, this is close to what I want.

So, I'm just going to tweak it. I'm going to adjust the parameters. I'm going to save a copy of it, giving it a different name so now it's unique, and just bring that back into the assembly. Do a Component Replace.

So, the steps are very logical. They make a lot of sense. So, just incorporate that within your logic as we start talking about that. Those steps. First, check to see if it exists. If it does, use it. If it doesn't, make it and then use it. It's that simple.

Dynamic components, though, are much more difficult to manage and control. What is your naming-- your file naming convention? How do you be-- how can you identify those components that already exist if all you're working with is a file name? There's a lot of trickery going on there but you'll see as we progress through this that we can alleviate some of that.

Form, fit, and function. What do my models do, you know? We can create models all different ways and if we don't organize and we don't classify them, if we don't understand how their-- they work together. A pump is a pump. But a pump, you know, what if it has a four bolt or a whole bolt, or one that might have five, or whatever. However it might work, you have to understand how they work in terms of their categorization.

Form, fit, and function. If you can get a good grip on what your form, fit, and function is in terms of your classification, that will work with us as we go downstream to start working with external data sources. Because then we can capture that unique information about different files that fall into a particular class. And we can identify them, as you will see.

And then of course, use Work Features. In this type of automation, basically all we're doing is we're configuring in an assembly, OK? All sorts of different components, we're going to bring together in a particular configuration.

What does it take to do a configuration? It only takes two things. First, we have to identify a file that we need. And then we have to understand how it relates to everything else within 3D space, right? That's it. So if we know what file we need and we know where it is positioned, x,y, and z, that's all the critical information that we need, OK? But there's a couple of different ways that we can go about getting there.

And as we get into this, you'll see that. It's nothing more than either you're going to bring it in, you're going to position it, x, y, and z. And then you're going to lock it down. Or you're going to bring it into the assembly and you're going to constrain it to something. But then you have to understand how all these relationships work, right? So Work Features will allow us to get past that as you'll see here shortly.

So, the second aspect is External Data Sources. What is an External Data Source? Why should we even use it? Well, as I stated before, we have files out there that are classified, they're organized, they do particular things, and we want to make sure that they-- we're preserving specific information about them. Like I said about the pump, one has four bolts, one has five bolts. That might be something critical that you want to store within an external data source, so you can quickly retrieve that information to understand how to make a decision. Should I use this component as opposed to that component?

External Data Sources come in a number of different ways. But it's definitely specific information about our models that we want to capture that we otherwise wouldn't be able to get. How do I know what kind of pump I need if all I'm working with is an arbitrary or random sequential file name? You know, that might be a little bit more challenging. This is why External Data Sources become very important.

What is an External Data Source? What does it look like to us? Well, it could be in another Inventor file. If you've used iLogic before and you're working within assemblies, you know in the iLogic rule editor, we-- the sub-components are exposed, right? We can see the components that make up an assembly. Not only can we see the components, but we can see the parameters and some other information about it. The data that's stored within the model could be a data source if we look at it that way.

Another one is an Excel spreadsheet. Everybody's familiar with Excel. So it's super, super easy to use, for the most part. We can create all sorts of different tabs and write information. So Excel spreadsheets are really powerful in that regard as well as SQL Server.

SQL Server is a little bit more challenging, but still very, very powerful. A lot of information we can store there. We can retrieve information at will. And it's-- I personally like working with SQL Server in terms of building automation.

And then you can even use XML, Text file, or an Microsoft Access Database for those that want something a little bit low-- lower key. Or maybe something that you might be more familiar with in terms of storing your external data.

So, things to consider about external data. You have to have a complete understanding of your information. I'm going to reiterate that more and more throughout this session. But understanding your information in terms of form, fit, and function. Capturing that specific information about your particular models based upon their class, or how they're organized, or their standards, or whatever. They have to be organized to some degree. And then you can capture that specific information and put in your data-- or your data source.

Classification, identify the commonality of model classes. What is the same about them and what's different? Because most of the time, it's what's different is what we want to capture within our External Data Sources.

Excel spreadsheets. Everybody's familiar with Excel. Most everybody knows how to work within it, write information to different cells. So, within Inventor, we already have a relationship with Excel. If anybody is familiar with iParts, right? There's always an Excel spreadsheet in terms of iParts. That could be embedded within the file itself or not.

We also use spreadsheets-- for Embedded, if we have like-- we want to capture information within the model itself or the assembly itself, we can use Excel embedded inside the model. We can link parameters, have you ever done that before? Link parameters to an Excel spreadsheet. You know, you're in the parameter dialog box, you got that link button at the bottom. You could link it or you can embed it.

One of the things about embedding a spreadsheet. One of the limitations of if, everybody knows it has that one cell there that says, where do you want to start in your spreadsheet for your parameters, right? You can say either cell A1, A2, A3. And that's because it only reads from where you start to where this no-- the next row is broken.

So, it's really limited in what it can do. I can only read a certain way. Either horizontal, vertically-- but if there's a broken row or column there, it stops reading it. And it only reads from the first sheet. So you can't get information from other sheets directly, indirectly you can but not directly. With this, using an Excel spreadsheet with your automation, you can-- the Excel API is exposed. You can read and write to cells.

I've even done projects where, if an Excel spreadsheet doesn't exist, I'm going to create it. I'm going to store it somewhere and then I'm going to format it. I'm going to create all sorts of different tabs. I'm to make sure they're written a certain way. Then I'm going to write all the different rows and columns that I might need. You can use that-- or do that through the Excel API, write within Inventor. So, a lot more functionality if you do it that way as opposed to just some of the built in functionality inside of Inventor.

SQL Server. Everybody's-- at enterprise level, they're very familiar with SQL Server. Not only that, if you are using Vault, if you have a PDM in place, most likely you already have an instance of SQL Server. You could leverage that. That's what I do a lot is, because of the fact that they are using Vault, I already have the instance there. I create some clean databases populated with my information. And now I can use it with my automation. And there are free versions out there that you can use. SQL Server Express. Really from a cost perspective, it might even be easier that way.

You can also leverage SQL servers stored procedures. Maybe my logic inside of whatever language I might be using can only gather so much information or can consume that information a certain way. I can leverage SQL to do some of that as well. Grab information from one table and another table, bring it together. And now it's going to output information that I might be able to need with-- or use with my Inventor automation. A lot of power involved there as well.

And then, other business systems. I've worked a project with a customer that they have a sales tool. And sales individuals are plugging in all sorts of information. It uses its own logic in order to derive particular values. And now engineering, there's a break there. Sales has this information, engineering has this information. So, we created some intermediate databases that would go out and capture information from the sales tool, index it in to their engineering database, and now they can consume that within engineering. Without having to communicate with anybody, no e-mails, nothing else. They just push a button, it uses that, and now they're building assemblies.

I've never used XML. Not in Inventor automation, at least. Or text files. Or an Access database. But, because of Visual Studio, if you do use Visual Studio in order to create your logic, that stuff is wide open. I have no doubts whatsoever that you can use XML, text files, or anything else. That is-- and if anybody is already doing something like that, I'd like to talk to you because I want to get a better grip on that as well. Thank you.

All right. Number three, User Interfaces. Like I said earlier, at the beginning is, typically user interfaces are a means for an end user or somebody to make a decision. Like I said, if you don't have to worry about it. If you can write the logic to accommodate every single condition and every single criteria, you may not need a user interface. But most the time we do. Somebody has to make some sort of decision in terms of this or that or something else.

What are user-- what-- what are u-- user interfaces look like? They-- most of the time, all they do is just trigger different events. They're a means for us to pause a process, make a decision, hit go, and then continue with that. So we're triggering logic or triggering rules or something along those lines.

Like I said there, if-- does a human need to make a decision? If so, then you'll probably need a user interface. And user interfaces could come in many different flavors. If you guys are familiar with iLogic, we can create iLogic forms right inside of Inventor, right? We can create forms that live within the files themselves, forms that are external that you want to pull up maybe at an application level. You want to share them out to make sure that everybody has the same UI, you can do that.

They're very user friendly. They have a good tool set to create some very basic forms, to accomplish different tasks that you might need in terms of your UI. But they can be low security. If they're inside of the file, you know, they're exposed to the end user, they can go in and tweak that and move things around. And that may not be what you want.

And they mostly just-- they only work with parameters, iProperties, and other rules. So, there's no other mechanism to extend your iLogic form to do other things. So, it's limited functionality in terms of an enterprise level. If you're not at enterprise level, you're just trying to do some simple tasks and you need a basic UI, use iLogic forms. Nothing wrong with that whatsoever.

Visual Studio. Now, if you really want to go all out, use Visual Studio. There's so many tools available. Buttons, radio boxes, pick list, checks-- check boxes. All sorts of different ways that you can develop your UI's using Visual Studio.

It's distributable. If you create a series of windows forms, you can output a DLL, throw it out there somewhere, connect that to Inventor and now everybody is using that DLL for their windows forms, right? It's a higher level of security. Typically this DLL will be out somewhere on the network, IT can then preserve that and control who has access to that. now your end users aren't going to go around and mess arou-- mess around with your UI's.

And you have full functionality of enterprise level automation in terms of building your UI's. But, because of the Visual Studio IDE, we can also write all our logic right in there as well. OK? So, it gives us a lot more flexibility in terms of how we want to structure and organize our automation.

And lastly, inside of the Rule Editor, if your guys aren't familiar with it, there's four tabs at the top of the Rule Editor, which shows you the tree. There's one for wizards. And there's an actu-- there's an iLogic wizard if you want to connect to a DLL.

So if you use Visual Studio, you create yourself a series of windows forms, you have that DLL. All you've got to do is just run that wizard, point to DLL and it will populate the rule for you. So now, inside of Inventor, you can access that DLL readily.

Visual Studio add on. iLogic forms built right inside of Inventor and iLogic. Visual Studio forms output a DLL but you're still writing-- typically you're still writing all your logic in iLogic. If you create an Add-In, this is really cool. This is really the way that you want to do it.

Most of the time, customers love this because you can streamline it. You can incorporate it right inside of Inventor. You can create panels, you can create buttons so it looks like it's a part of your application. Doesn't look hokey, so to speak, right?

You can-- it-- you-- it loads right when you fire up Inventor. It's always available. It's super easy to update. You just load the project back into Visual Studio, make your changes, I'll put your ad in, and now everybody's happy, OK? Very, very high security. Is not exposed to anybody. Most general users don't have any idea how to get to that information. But it's out there and you can leverage the iLogic rules if you want to.

You're not tied to use VB.net, just like in iLogic you are. It's basically the only language you can use. You can use C# inside of Visual Studio to use the Inventor API in order to start creating your logic. This particular data set, anybody that's interested in seeing it after this class, I can show you but I use an Add-In to make that-- make it look real good. Like I said before, streamline it inside of Inventor. Makes things a lot easier in that sense.

Number four and lastly, the Logic's. Now this is always the most complicated part. I have all these models. I have an UI. I have an external data source. How do I bring it all together? The logic is the glue for all that. It goes out and it takes information from your UI inputs. It goes and grabs information that you've defined from your external data source and it churns all this information to ultimately do, what? What files do I need and where do they reside in 3D space? That is the ultimate questions that we need to answer in this type of automation.

What does it take to configure components in assembly? I just answered that question for you. You have to understand what components you need and where they reside in 3D space. What kind of relationship do they have with one another inside of that environment? If you can answer those questions, then you can create these-- this automation very easily.

Come to embrace the Inventor API. How many people here are very familiar with the Inventor API? One, two, three, four, five? OK, getting there. Look into this, guys. If you want to put in automation into your process, you have to have some familiarity with the Inventor API. Yes?

AUDIENCE: [INAUDIBLE] I'm not a programmer [INAUDIBLE]. Can I still get a lot of value out of iLogic?

THOMAS FITZGERALD: Absolutely. Simply because the iLogic Rule Editor already has some predefined snippets that you can use. It kind of lays out the format in which you might want to put things together and you can easily change those things. Inside of the Rule Editor, there's a lot of different colors involved. And those colors, based upon what you're writing, mean certain things. Is it a recognized parameter? Is it a-- is it something-- some sort of logic that needs to be run? There's all different instances in which you can use the iLogic Rule Editor to kind of understand that. And kind of build your skills in terms of writing code.

And then learn the basics of VB.net or C# if that's what you're into. There's a lot of information out there on the internet. YouTube videos galore. And at the end, I have some links here to kind of-- some places that I regularly go to to answer some of the questions that I have when I'm writing my own automation.

Ah, the Inventor API. The Inventor API, it's just a means for us to write code to trigger and do certain things inside of Inventor. If I go and hit a button on my panel inside of my Inventor session, it's used in the Inventor API. It's triggering some sort of event to run some sort of code to do some sort of action, OK?

So, we're going to do the same thing. But in order for us to do that, we have to be familiar with the API. Inside of Inventor, if you go up to the-- oh, I don't have it on this but inside of Inventor User Interface, you can go and hit the little question mark and it gets you to the Inventor API help.

In there, there's all sorts of different samples, the object model is in there if you want to do anything in terms of creating constraints, or manipulating parameters. Or you can even create geometry on the fly if you want to. I mean, it's-- I'd say a good 95% to 96% of every little task you could do inside of Inventor, there's API code for. So it's not 100%, but it's dang close.

And then reference information online as well as sample programs. Oh man, I can't count how many times I've been thankful for the sample programs that are in there. Most of the time they're in VBA. So, slightly different. So, a little bit of syntax editing going on between VBA and .net but it's pretty straightforward. Yes, go ahead and go in there and look. There are some sample programs in there just to kind of get you familiar with the structure of the code that might be necessary. And some of the terminology that might be helpful for you as you start perusing online and getting answers questions-- or questions answered there as well.

ILogic. Should you use iLogic? Well, yeah. You can definitely use iLogic if you want to put in some automation. The IDE, the Rule Editor is simplistic. However, I've always attributed iLogic as the doorway to the Inventor API, OK? It's a really cool interface to use. If you start becoming familiar with the API, you start using general code writing practices in VB.net.