ilogic Best Practices and Fundamentals for Success

THOMAS FITZGERALD: Hello, everyone. Thank you for joining my Autodesk University class around iLogic best practices and fundamentals for success. My name is Tom Fitzgerald. I am a principal solution architect with Autodesk. I've been with Autodesk for about 10 years. Let me go to the next slide here, and then we can get into this class.

So been in the manufacturing industry since 1997. Yeah. That's a considerable amount of time. I'm sure there's a few people that are going to be watching this video and participating that can understand what the 90s and the early 2000s were like in terms of the manufacturing. Been using 3D CAD software since 1998.

Like I said, been with Autodesk for about 10 years now. I am also a Microsoft Certified Systems administrator. Got my credentials back in the early 2000s. In my free time, when I'm not working for Autodesk, I'm a World War II historian. So I like to watch a lot of documentaries, read books, and visit the many places around the world, and really absorb that historical information in those historical experiences.

I also did a stint in the military way back during the first Gulf War. Nearly seven years in the United States Army. So that's a little bit about myself.

And what is iLogic? So iLogic fundamentals for success, we need to know a little bit about iLogic. Well, iLogic came about back in 2008 time frame, so we're about 13 years into using iLogic. Basically, iLogic is a means for us to be able to add intelligence and logic to our designs, both the 3D models, as well as the 2D documentation that supports those 3D models.

So it allows us to capture that information, generate different rules for that logic, and to enhance that experience in terms of being able to consume the models and the drawings in which we generate.

So previous to iLogic there was really a gap around how can we take our engineering information and apply it to the models in the drawings in order to facilitate standardized ways of being able to develop content? Now, if we look back before 3D applications, we were reliant upon the board, the drafting board, and then, of course, digital drafting board, being AutoCAD, and then, of course, 3D design.

So being able to take a lot of that intelligence and that product knowledge and all that other information, and to be able to incorporate into the models to be able to extend the functionality. Well, that really benefits a lot of engineering companies and a lot of engineering departments in order for us to do a little bit more with what we have.

So going into that, what are the benefits of iLogic? A few of these benefits are, well, because we're able to dynamically change models based upon specific criteria, input information, now, we can develop proposals rather quickly. If you work in an engineering department where you have to do quotes and be able to provide information before one of your customers commits to purchasing some of your products.

Well, you want to be able to quickly be able to develop that quote. But at the same time, you don't want that to go to nothing. You want to be able to reuse that information and rely on that information. If you're going to go through the process of developing specific information for a quote, why not continue using that information?

So iLogic not only allows you to develop quotes, or proposals, quickly, but then to be able to take that information downstream through your engineering process. So it's not just one and done, or create and then disposed of. Allows you to standardize consistency into your design practices, reduce repetitive tasks. This is a big one because if you can predict specific workflows, if you understand what is necessary, step one, step two, step three, and it's very predictable, and it's very defined. Well, that is a perfect opportunity to start incorporating iLogic.

You can reduce rework by allowing the logic, which never takes a break, always works the same way time and time and time again. Well, it reduces that opportunity for human error. So it allows us to reduce the amount of rework and mistakes that we might make by leveraging iLogic.

This is a big one for me. It gives you more time to innovate because, think about it. If you're taking your repetitive tasks and you're offloading that to automation, well, it grants your designers and engineers more of an opportunity to focus on things that stir their imagination or prompt their creativity, those things that lend itself to innovation. So automation is a mechanism, is an avenue to approach better and more innovation.

And of course, it increases throughput. So like I said before, it allows you to do more with what you have. And in some instances, to be able to do more with less. So that's one of my favorites as well.

If you want to start using iLogic, I'm going to assume many people that are participating or watching this video, well, I'm sure you have some influence or exposure to iLogic, but if you're new, and maybe you don't understand all the different concepts, well, some helpful skills for being able to use iLogic and leverage it in the best possible way, become familiar with the Inventor API.

So the Inventor API allows us to be able to generate and produce code that runs Inventor. So those things that you have to do manually, you can legitimately, in most instances, develop some automation to do those particular tasks.

The iLogic rule editor does contain some predefined snippets, or code blocks, that you can use. You can quickly paste them in and modify them. But it doesn't really do everything that you want to be able to leverage in order to build out large automation projects, or even compliment all the different types of things that you might want to do.

So even though the snippets are there, it's always very helpful to be able to rely on the Inventor API in order to extend your capability when using iLogic.

Inside of the Inventor helps, there's a lot of different resources around the Inventor API. There's also some samples to kind of get you started if you want to really understand what iLogic can do for you.

The other thing that's going to be very helpful is to be able to be familiar with VB.net. So VB.net is the native language for iLogic. So if you're familiar with VBA, so Visual Basic for Applications, VB. net is very similar. There are some things that are slightly different, but it's a very easy transition if you're very familiar with VBA.

Become familiar with common code writing best practices. And those are some of the things that we're going to be touching on in this class is some of those code writing best practices. There's a lot of information online. Quite honestly, a lot of the things that I have to do when I find myself in a particular position where I don't know the answer, I leverage Google. Stack Overflow and even the Microsoft website has a lot of information about how to implement different functions, different methods, how to construct your rules and your code in such a way where it's efficient and optimized.

So once again, some of those things were going to be talking today in this class.

So about what we're going to be talking about today. iLogic fundamentals for success. There's going to be five things that we're going to be discussing. We're going to be looking at variables and being able to declare and understand the things about different variables. Conditional expressions. What if this happens versus that? How are we going to handle those different conditions? So working with conditional expressions is going to be very important.

Being able to understand loops and what loops do. Being able to do something until we want it to stop. Maybe we don't know when it needs to stop. Maybe it varies. Being able to construct loops in order to handle how to deal with many different iterations is going to be helpful as well.

Collections. Sometimes we have to go and access information. If you have a tendency to rely on Excel, or even a SQL database to access information about your models and drawings, being able to go and collect that information and store it somewhere where we can reuse it over and over again is very beneficial in terms of performance. You don't want to be going back and forth to an Excel file all the time to acquire information. Sometimes it's good to access that Excel file, grab all the information you need, hold it in different collections, and then use the information within the collections because it's much, much faster.

And then lastly, subroutines and functions. Being able to organize your tasks within iLogic rules, to be able to call different routines and functions as necessary in order to make our code more efficient and, once again, optimized. All right. So let's get into it.

So the first thing we want to talk about, I want to talk about, rather, is variables and what variables are in relation to iLogic. So I'm going to step over here now into Inventor. And I have a drawing opened up, and I've got a few rules in here. And I'm going to demonstrate a couple of different things.

So when I talk about variables, let me go into one of the rules in which I've written here. I'm going to pull that over, and we're going to take a look here. And inside of my rule editor, we're going to see that in this rule, at the very top here, I have a number of declarations, and that's predefined by that dim statement there. So dim, like this third line here, so line three. If I highlight that real quick. So dim odak as drawing document equals something. So this is a very common format in terms of declaring different variables. And all a variable is a placeholder. It's a container, if you will.

I'm going to declare a variable, and I'm going to give it a very specific name. After I give it a name, I want to give it a type. What does this variable contain? Does it contain text? Does it contain numbers? Does it contain numbers that have decimals? Does it contain some other object that I need to access within the Inventor API?

So we have an opportunity not only to give variables a name, but what we call typecasting, a means to be able to say, OK, variable. This is the type of information in which you're going to contain. It allows us to be very prescriptive and definitive in terms of the types of variables we want to create, what they're going to contain, and how they're going to behave.

Now, this is very important simply because we can, inside of iLogic, we can create very basic variables. So if I just go into this other rule here, if I wanted to create a variable just in iLogic, if I was just watching a video, and I wanted to create it, I could do something like say, oPart equals this is a part OK.

Now, iLogic will accept that. It will understand that if I create a name of something that doesn't already exist, iLogic's going to assume that I want to create a variable. And because I'm telling it to equal something, I'm giving it a name, and then I'm going to give it a value after the equal sign, in this case, because it's in quotations, iLogic can interpret that now I've created a variable that is going to contain text in it. So it's going to be a string value. It's going to be a string variable.

Now, that's fine that iLogic understands that. But we also have to realize that sometimes we're not the only ones that have to deal or work with the code in which we generate. So me personally, if I was creating this, and I knew I alone was going to be working with the code, this might be OK. But realize there might be other individuals that have to deal with your code. So being able to convey more information about what your code is doing, how it functions, and the expected behavior, is going to be important when you want to start scaling with larger design automation projects.

So even though this is acceptable, we want to do our due diligence and ensure that we're outlining what kind of variables we're creating for those individuals that might have to work with our code later on. So that's why doing a name value pair and typecasting your variables is going to be extremely important. OK.

The other variables that exists inside of iLogic are called shared variables. Now, let me go over to a different rule here. And let me see. I think this one might work. So shared variables-- So rather, let's back it up.

So the variables in which that we were just talking about are those that exist and live solely inside the rules in which we're running. OK. So if I created a series of variables and did some activity, those variables would only be exposed and accessible within the context of that particular rule. Shared variables, on the other hand, give us the opportunity to populate variables and then share them across many iLogic rules.

So it's a place, it's a means to take a variable and store it within the application, the Inventor application, and then all the different rules can access that information. So creating a shared variable is quite easy. You just use this shared variable, and then what do you want to call the shared variable? And then, of course, what's going to be in that shared variable?

So unlike other variables, where we actually give them a name, and then we typecast them, shared variables, because they're strictly iLogic, you don't have to typecast them, which is beneficial in a number of ways because the fact that you can basically put anything you want inside of a shared variable. You can put a single object, like a double, a number with a decimal, or a text sentence, or string value. You can also put in collections, like a list, or an array.

So if you had an array that had numerous values in it, string values or decimal values, you can create a shared variable and contain that array within that shared variable, and then share that across many different rules in order to be able to use them.

So in the case of this XML file, I'm storing a text value in it. But there's other rules that I have here, like create lists, where it allows me to create a collection, like right here, where I'm creating-- I'm creating a list. And then what I'm doing is I'm telling the list, right here. So I'm adding information to a list as I'm looping through, and then I'm telling this shared variable to store all the elements or all the information within that list, so that way I can share it across numerous rules.

So if you're going to go and collect a bunch of information, you can store it in a shared variable and share it across many different rules. So that's the variables in a nutshell. And that's really a recommended way of using variables.

So beyond variables, the next thing I want to talk about are conditional expressions. And this is really the root of how or why you want to use iLogic, because when we're talking about working with 3D models, there's basically two ways that you can look at models. Models that once you generate them, once you create them, they are what they are. It's a particular shape, form. It has a particular function. Once it's developed, it's given a part number and then it exists out there, and that's just the way it is. Those are what we call, basically, static components, or static files.

The other part, or the other type of file, is a dynamic file, one that could vary or change at some given time or point in time. And the way that they are dynamic is by understanding what different conditions could exist. So conditional expressions facilitate the means for us to be able to apply those different conditions.

So going back over to Inventor here. Some of the conditional expressions that we see a lot are if, then, else if, and and if So if I scroll down here, here's a case right here of a if and an and if type of statement or expression. So that highlighted code right there. So if i equals 1. So if there is a variable, so in this case, I have a variable called i, and it has a value of 1. So if i equals 1, then it's going to do the bit of code that meets that particular condition. So it evaluates the condition. If it meets that condition, then it's going to run that code within that condition.

So in this case if i equals 1, well, it's going to create a drawing view. It's going to use a particular model state. It's going to name that model view, and then it's going to show the label.

Now, if the condition is something else like, say, if the condition is two, or if the condition is three, then we want to do something else. So outlining your code by using an if, else if, or if else statement is a way for us to be able to define the different conditions that might exist, and then what we want Inventor to do when those conditions exist.

So there's a couple of different ways that you can use if, else if, and if statements. So as I have it here, basically, I have five different conditions that I want to manage. If i equals one, two, three, four, or five. Most of the time you might have only two or three different conditions, if and an else if.

So if it's true or if it's false, if it's up, if it's down, if it's left, or if it's right. So most of the time there's typically two conditions, but you're going to find there's going to be instances where you'll have three or more. And usually, what I try to do is if there's like four, maybe five, conditions, no more than five, I'll almost exclusively use if, else if conditional expression.

The other type of conditional expression that you have is a select case. And a select case is inside of our Inventor or iLogic rule editor, we have different keywords that we can access for creating different subroutines and different functions and case selects and loops and if then else if statements. So different ways for us to be able to quickly generate some information around how we want to develop our conditional expressions.

So the other way, like I said, is if you want to use case select. I'm not going to save that rule. And I'm just going to go into this other rule here. And the easy way of understanding case select is if you have numerous conditions, I like to use-- If you have more than, say, five conditions, I like to use select case.

So select case, very simple. Select case, and then it's going to say, well, what is your case? And then, we just basically back it up and say, and select. So that's our-- sorry. It's case select. I always get that one backwards. There we go. And an and case. Is that the way it is? No. I had it right the first time. Select case. Select case. Oh, the fun of doing a live demonstration. And then end select. And then we need to define, well, what is our case? What are we going to be managing or monitoring in our case?

So if it's like a dimension, we could say dimension or something like that. And then all we have to do is just define what are our cases. So in our first case, if dimension happens to be 1.5. Well, then we're going to do something. What if our case is-- so it's very similar to if else if, where we're defining what case do we want to manage, which could be a parameter. It could be a property. It could be a different variable. There's a number of different things that we want to monitor in our select case. And then based upon how that value changes, we can then run different codes.

So it's very, very similar to if else if. However it's a little bit less code to write. It's a little bit easier to understand, particularly when you have many, many different conditions. So that's my preference in terms of developing different conditional expressions using select case. All right.

The next thing that we want to talk about, loops. So loops are one of my favorite things. And the reason why I say that is because a lot of the times when I'm working with customers we have to, or they really want to, be able to collect a lot of information, and/or understand a current state of a model.

So understanding the current state of a model, well, a lot of the times what you have to do, particularly if it's in an assembly, is you have to iterate through the assembly structure to understand how many subassemblies do I have? How many individual components are there? Is there a particular component that exists within a sub assembly?

So being to be able to loop through all the different instances or components or subassemblies that exist within an assembly, is going to be valuable if you have to start understanding the state or status of a particular assembly. OK.

So once again, let's go back over to Inventor. And I'll show you a couple of things around different loops. Let's see here.

So one of the things that I like to do for loops is to do what they call a do loop. And that is what I've highlighted right here. So a do loop, in this particular structure, basically we're telling iLogic to do something until a condition exists. OK. So to break this down, I'm going to do, well, what am I going to do? I'm going to go to an Excel spreadsheet, and I'm going to read values within particular cells in my Excel spreadsheet. I'm going to pull those values in, and I'm going to populate some variables that exist within my iLogic rule. OK.

So the first thing I'm going to do is, right now I've set this increment to number two. So in this case, it's going to loop through this Excel spreadsheet, and it's going to go to cell A2, and it's going to get that information, and it's going to go to B2, and C2, and so on and so forth. And then it's going to collect that information. And then it's going to do another-- it's going to loop through the different drawing views until it finds a very specific view of a particular name. And then it's going to exit out of that loop.

And then it's going to take all this information that we've just collected from the Excel spreadsheet, 0.1, 0.2, a view name, a sheet number, and it's going to pass that information to a routine that I've created that is going to create a linear dimension. And we'll get into routines and functions here in a little bit.

But once it does that, then it's going to change the increment. So it's going to bump the increment up to number three. So we've set the increment to be number two. We're going to do something. Then we're going to set the increment to number three. And then by doing that, what I'm telling iLogic now is, hey, look at the cell value of A3 now. So the first column A3, and if there's nothing in that cell value or if it's empty, then we can terminate the loop. OK.

So we've started at two. We've gone through and collected everything from the different cells in the second row. And then look at row three to see if it's populated. If it is, let's go get that information. Then go to row four and see if there's something there. And it keeps doing that until it finds an empty row, which then means, well, I'm done.

So if you construct your Excel spreadsheet in such a way where you're adhering to those particular rules of understanding that a process is going to loop through and access and collect all that information until you hit an empty row, then you can terminate that loop, and it's collected all that information, and then it's done something. OK.

So loops are very, very helpful if you need to do something until a condition exists.

Another loop is what we call a for each loop. So in the case of what I've highlighted here, so for each view that exists within all the views in my drawing, look for a very specific name, a view with a very specific name, rather. And then once you get that name, once you find that view, then we're going to stop looping. OK.

We're going to terminate that loop. So this is another way to-- I don't know how many views might exist. They could be on the first sheet. They could be on the second sheet. It doesn't really matter. All we need to understand is I want to look through all the views until I find a view of a very specific name, and then I'm going to do something with that view.

So in this case, we actually have a loop inside of a loop to do something by collecting information and creating the linear dimension. OK.

So loops are very, very valuable in the sense of, think about if you had to change the title block in a drawing that had 15 drawing sheets. Well, you'd want to-- maybe this drawing has 15. Maybe there's another one that has five. Maybe there's another one that has 100. If you don't know, loops are very, very valuable in order to say, OK, I'm going to loop through until we basically get to the end, and then I can go on to something else. So that's loops in a nutshell.

The next thing I want to talk about, collections. Collections come in a couple of different flavors inside of iLogic. There's going to be two that I'm going to show you that I use most often when it comes to being able to access information and store it somewhere for so that way I can use it later on.

A couple of different ways that I like to use-- that I like to use collections. Let's see here. Let me go into this rule here. So there's a couple different ways that we can create collections. One way that I like to create collections is-- actually, maybe, let's go to this other rule here. Let's go to this rule right here.

So one way that I like to use collections is basically called a list. OK. So I'm going to create a list. I'm going to give it a name, and then I'm going to tell it what type of information goes in it. So in this case, I know that I'm going to store text information or string information inside of this list. OK.

So the way that we populate the list, so now that I've created the list, I want to add some information to that list. So what information do I want to add? Well, it's very simple. Use this method where you call the name of the particular list, and then, add, and then what value do you want to add?

Now, in this case, I'm very explicit in terms of the value that I want to add. But you can use a combination of other variables that go and collect information, say, names of components, or some property value out of a component. You're going to iterate through an assembly, and you want to get a property out of those components. Well, you can iterate through and then populate that array-- or that list, not by an explicit string value, but some other property, or rather, variable that was populated from some other method. OK.

So it's very easy to populate information in collections. Once you have that information in the collection, well, there's a number of different things that you can do with that collection. And this is why I like to use list as opposed to other methods is, if I want to do something with this list now, so if I go list parts, and I hit dot. You're going to notice that I'm going to get this menu that's going to pop up, that's going to show me all of the different things that I can do with this list.

Maybe I want to add something to the list, or I want to add a range, or I want to find the-- or if I want to clear the list because maybe I want to use this list for something else, or it's revolving and I want to add information, consume information, from that collection, then dispose of that information and then repopulate it. So I can clear either the whole list or very specific items from the list. I can, understand, does it contain a specific value?

So if I had a long list, one way that I could find out if something exists in that list is to iterate with a loop through all of the information in that list. Or I could use this contains function, that it does it automatically. I don't have to generate the code for the loop to loop through the list. Basically, this is a method to be able to search that list for a specific value to find out if it exists and then do something with it. OK.

So contains is a valuable method to use when generating lists. How many items are in that list? Maybe I need to know how many exist in that list. Maybe I need to find or see if something exists in that list. The index of, this is another good one that I like to use. Sometimes-- I was, well, quite honestly, I was on a project recently where I had to use the long form of a product name and then the short form, or an abbreviated name, of that product.

So from a user perspective, they want to see the long version or the long name. It's very descriptive. It's very easy to understand. It's very familiar. However, when selecting the long value, we want to pace the short value in some other property. So being able to create two lists with the long name in the short name, and then find the index in the long name, and then find the corresponding index in the short name, is very valuable. So index of is very useful in that case.

So like I said, there's a lot of different things that you can do here by using lists. When I found this a number of years ago, one of my most valuable methods that I use when constructing iLogic code, creating lists. And like I said, you can create lists of string, of double, of decimal, of Boolean. So there's other ways that you can create. You can type cast your lists in that fashion.

Just to give you an example of how this works. I just wrote this up real quick. So I've created this list. I've added some information to the list, and now I want to do something with that list. So I've declared a variable called count. It's of an integer type. So it's a whole number. And then, so it's going to feed back the number of items that I have in this list. And then it's going to pop up a message box to show me the number of items.

Now, from there, I just want to know, well, what is the index? What is the number? Where does it lie within the list? The item called pipe. So my expectation that it would be the first one within the list because of how I'm adding that information to the list. So let's run this, and let's see what happens. OK. So I'm going to run it.

So right now, it's telling me there's three items within that collection. I'm going to hit OK. But it's going to tell me that the first item is zero. And that's because whenever you create list, guys, you have to remember, lists are zero based index, so zero index based. So the first item is always is 0. The second item is number one. The third item is number two. So on and so forth. So if you're going to use lists, you have to understand that it's zero index base, or zero based index, so that way you can accommodate your code to ensure you're accessing the appropriate value within that list. So I wanted to demonstrate that way so you can understand.

The other way that you can create a collection is like what I've defined here. So let me highlight this code right here. Well, actually it's just this one line. So in this case, I consider these arrays. Well, lists are arrays, as well. But I like to distinguish between a list and an array simply because an array typically has a capacity. OK. So in this case, I've created a variable called oPoint, and in parentheses here, I'm saying, well, there's only going to be five slots within that array. And then, what type is it? So I'm typecasting it as in Inventor, Inventor 0.2 D. OK.

So in this case, oPoint number one is going to be of that value. oPoint number two, three, four, and five. So I can create a variable, give it a capacity, a linear capacity, and then I can populate each one of those slots, if you will, within that array.

Now, it's also important to note that you can create arrays using variables. So say, for instance, in one instance, you need an array that only has a capacity of three, but in another instance you need an array that has a capacity of say, eight. Well, you could use a variable to control how many you need at any given point in time.

So in this case, as opposed to explicitly typing five in there, I could come up here, and I could come up here and create a variable. So dim oPoint, let's say, 0Point count as integer, right? But I'm not going to give it a particular value. Maybe I use some other method to populate that integer and give it a count. Then I can come back here. Control C, And then say Control V. So that way the next time that this array is used, it's going to be however many slots or whatever capacity I need when I need it.

So you don't necessarily have to be explicit in terms of how many are there. You do have to understand, well, does it vary or will it always be consistent? And they should always be questions that you're asking yourself when you're creating different variables and collections and loops. Is it persistent? Is it consistent? Or is it variable? OK. All right. So that's what I have for collections, being able to collect different information.

Now, onto subroutines and functions. So the last section that I want to talk about, subroutines and functions. Now, guys, this is extremely valuable inside of Inventor, rather, inside of iLogic, particularly, when you're constructing your rules. Actually, I'm going to open up this other one because this is one of my favorite rules that I've ever put together. And what it allows us to do is to automatically create and place dimensions on drawing views within an Inventor drawing.

And then, how we do that is by, like I said before, I have this main section of code. So this is my main routine. And this is a methodology, a construct, that I use on a regular basis because if you don't use this methodology, if you don't create a main routine, it doesn't give you an opportunity to create subsequent routines and functions. So if you're going to use other subroutines and functions, you want to make sure that you're identifying your first subroutine or routine as your main routine. OK. So this is going to be the main bit of code that drives everything else.

So this is the intent or the task that you're developing within the code. And then you're going to create other routines that you'll use as you process this main routine. OK.

So what we're doing here is I've created a series of variables, and then I've populated some variables. And then what I'm going to do is I'm going to, like I said before, I'm going to loop through all the different rows that are in this Excel spreadsheet. And I'm going to collect that information, and I'm collecting it because it's basically all the inputs that Inventor needs in order to programmatically create a dimension.

And how do I know this? Well, like I said at the beginning of this video, if you understand the Inventor API, and you understand where to go inside of the Inventor API, it identifies how you need to construct your different methods in order to make Inventor work the way you want it to work.

So if I want to create a linear dimension, well, the inputs, the required inputs, to create a linear dimension that Inventor needs, it needs to know what sheet are you working on. What view are you going to place the dimension on? What are your connecting points? Where do you want to place the dimension once you've identified your connection points? Is it going to be horizontal? Is it going to be vertical? Is it going to be aligned? What kind is it?

And then do you want to add any comments to your dimension because that's a feature within Inventor when you create dimensions. You can give it a comment.

So these are all the requirements for creating any given dimension in a drawing programmatically. So essentially, what I'm doing is I have this main routine that goes and collects all the information I need from the Excel spreadsheet, and then provides that to this call, which is basically calling this lower level subroutine and passing all the input information necessary in order to create that linear dimension.

So I'm calling this routine. I have all my input variables, and now, down here, I have my actual routine. I'll space that out a little bit. And now it has my input information. So this is all my input information and their particular typecast. So is it an object like a drawing view? Is it a string? Is it an integer? Whatever it might be, I need to identify that within my routine itself.

Now that I have that input information, then I can start processing that information by creating the necessary work points on those-- or Yeah, the necessary work points in order for me to understand where do I need to connect my dimension. Where am I going to be placing this dimension? Is it going to be the left of the view, to the top of the view, to the right of the view, to the bottom of the view? So I need to know where am I placing the dimension.

And then, of course, lastly, where am I going to be placing the text? How far away from the view am I going to be placing it? Is it going to be close to the view? Is it going to be further away from the view? I want to make sure I'm spacing them out programmatically so I don't have dimensions layered on top of one another. So I need to have some sort of strategy to understand if the first one is here, I need to offset the second one, and then the third one and the fourth one so they don't overrun one another.

And then lastly, now that I have all that identified, this is the actual Inventor API call to create a dimension. We have to identify what sheet is it on? Add the linear dimension. Give the points. Give the geometry intent. And then what type of dimension is it? And then lastly, I'm going to center that dimension text between the two points.

So what does this all mean? Well, I have a main routine that collects the information necessary to create the dimension, and then I pass all that information to another routine that actually creates the dimension itself. OK.

And another example of what I'm doing here. So-- not add dimensions. Don't want to do that one again. If I go to add views, I have some routines here. So once again, I have my main routine. So this is, once again, where I'm collecting all my information and organizing it in such a way where I can then pass it to a lower level routine that is going to do something. Like in this case, once I create a drawing view, I want to make sure that my drawing view is scaled in such a way where it fits on my drawing.

Well, in order for me to do that, I don't want to do it explicitly because, depending on what I'm creating or drawing of view of, is it a water bottle or is it an automobile? The scale is going to vary depending on the type of view, or the view reference, that I have, the model reference.

So as opposed to being explicit in terms of the view scale, I'm just going to pass some information to this lower level routine that's going to do the calculation for me. It's going to understand what is the size of the sheet I'm working with? How much real estate am I allocating to this view? And then it does a little calculation to determine what scale factor I need to adjust the view to in order for it to fit into that allocated real estate. And then I set that view scale.

Another routine that I'm doing here is every time I want to generate views, if I need to regenerate a view for some reason. Maybe the model reference changed. Or if I use this at a template level, and I leave this code there, I can quickly generate numerous standardized drawing packages even though the model reference might be different.

Well, I want to make sure that I'm removing any of the previous views that are there so that way I can generate and place new views if the information has changed for some reason. So I don't want to explicitly delete all the views. So what I've done is I've created this other subroutine that goes and deletes the views any times I run this bit of code. So it's going to set some basic information. It's going to go and clean up my drawing, and then it's going to create the new views and then scale them after that.

So a means to create calculations, what I like to call helper routines, or helper functions, where you pass some information to it. It processes something, and then it takes you back to the original bit of code to continue on processing other things. So very, very valuable if you're going to be using loops, having routines and functions help out quite a bit.