Taking It to the Next Level: Drawing Automation with Inventor

THOMAS FITZGERALD: All right. Hello, everybody. How are we today? Excellent. This is amazing. I did not anticipate this kind of a turnout. Quite honestly, last year I did a class about just general design automation and how to build a simple product configuration. And when I decided then that, hey, maybe this might be a great opportunity to kind of extend that into some sort of drawing automation, I did not expect this. So thank you everyone for showing up.

So my name is Thomas Fitzgerald. People call me Tom. I've been in the manufacturing industry for about 20 years. I have been with the reseller channel, independent consultant for a little while, I've been with Autodesk for about seven years now. I've been CAD user. I've used all sorts of different CAD applications. CATIA, Solid Edge, SolidWorks, Pro We, Mechanical Desktop, AutoCAD, and then of course Inventor. Those of you that I've met before know we've had several engagements. And working within the manufacturing industry, working with Inventor, I mean, it's really quite a passion of mine and I've really kind of embraced it to allow myself to understand what it is that you as Inventor users really need and what you want to do with Inventor. So staying in touch with the functionality and what it can do and watch it evolve over the years. I mean it's been really amazing.

I went through some Microsoft certification. Got my Microsoft certifications a number of years ago kind of allowing me to understand a little bit more not just about end users in terms of what they do with CAD, but also the systems that support CAD. So being able to work with system administrators and understand that relationship between IT and engineering. And just in my free time, I like to pursue knowledge. I'm really big about understanding a little bit more about World War II. I'm a licensed drone pilot as well. Kind of really interesting being able to capture a lot of different footage that way. And I did a little stint in the United States Army back in the 1990s.

So once again, thank you everyone for being here. This is really quite an experience. So about today. What are be talking about today? Well, we're talking about drawing automation and everybody here probably is familiar with iLogic to some extent. iLogic's been around for a long time. Incorporated into the Inventor application back in 2009. Prior to that it was just an application, an add on to Inventor.

Bunch of guys up in Canada decided, hey, I think there's a need here to develop some sort of software for rules based design. Well, how are we going to do that? What are we going to do with it? Are we going to do it with SolidWorks? Are we going to do with Pro Weer? Are we going to do with something else? They chose Inventor. They chose Inventor simply because of what Autodesk represents. We have a large community. It's a lot of powerful tools. Why not invest in Autodesk? So they did, and now we have iLogic.

So I took this snippet off of online. So December 8, 2008 was when Autodesk acquired logic metrics, iLogic software, and started rolling it into Inventor. So it's been around for 10 years now. So those of you that have used iLogic before, thank you. It's been a journey, I know. But what I want to do today is talk a little bit about what we can do with it that maybe we don't really understand what we can do with it.

OK. So iLogic is one method, one way of incorporating design automation. So what is design automation? Well, it's a means to be able to take things that we typically do in a manual fashion and then use logic or code in order to process that information or do particular things. iLogic is a tool that allows us to do that. We have an interface inside of Inventor where we can generate and create different rules that we want to use to process information and do particular things.

One of the things to remember about iLogic, though, is that it doesn't change how or what Inventor can do. It only changes how we can do things with Inventor. So understand that, there's no magic wand here. There's nothing fantastic happening or things that shouldn't be able to be comprehended. I mean, it's just things that Inventor already knows how to do.

OK. So why would you want to use design automation? Well, there's a lot of benefits involved. Engineers get paid a lot of money and designers get paid a lot of money and we don't want them sitting around just doing data entry and plugging away at the keyboard and the same old, same repetitive mundane tasks over and over again. Let's allow them to use their brains. Let's allow them to use their experience and their knowledge to do things that's much more appropriate, much more valuable for the companies in which they work for.

So there's a lot of benefits involved. It allows us to innovate and be able to really take things to the next level as my class suggests and it allows us to increase throughput. And I think that's one of the biggest things about automating, particularly within design, is it allows us to do more with the people that we already have. How can we extend that? How can we get more out of that? Well, design automation is one of those ways to do that. So that's the how and the why.

Well actually, let me take this back for a second. So a little bit about design automation. So I'm going to show you something as a little bit of a demonstration. Now, last year when I did this class, it was kind of funny because I wanted to pack in a lot of content, and in order for me to be able to do that, I wanted to just kind of create all sorts of slides within the PowerPoint. Kind of overwhelm people and be able just to talk to it so I can get all that information in there. Well there's a lot of comments about the fact that maybe being something of this nature we want to do a little bit more demonstration. So I'm going to try to do more demonstration, less PowerPoint today, to kind of give you guys an idea of what it really looks like and what it's all about. OK?

So one of the first things here is about the design automation aspect of it. Let me get out of here, go into Inventor. So I built a product configurator last year as an Inventor add-in. So not iLogic per se. Leveraging the Inventor API allow me to then create a way to build an assembly just by plugging in a little bit of information.

OK. So one of those things, what I did is I built this add-in. And I have it up there. It's called LSC. You see it on the far right there. It's a little rocket configurator. Who doesn't like rockets? Everybody understands what rockets are and things like that. So I built this little interface all within the add-in. Now, you don't necessarily have to do it this way. You could just do this all through iLogic if you wanted to, but add-ins really give us a way to kind of give the user a great experience in terms of what they are already familiar with. Everybody knows that there's a ribbon across the top with different tools and whatnot. So why not streamline that? Why not allow end users to share that experience or have a common experience without being disrupted and what they do normally?

OK. So if I plug in some values, here is terms of what is my payload parameters? What am I putting in the space, and of course where am I going to put it? So once I have all these things defined, then I can go and select Accept. Actually, I want to go back here. Eight, four. I want that to be eight. There we go, and hit Accept. Once I plug in those parameters what I am doing in the background-- and I have the SQL Server instance that has a whole bunch of information and a series of database tables and it's perusing through there. It's searching through there to find all the parameter values that meet those particular conditions. And then from there we're allowed to select what kind of rocket we might want to build and go ahead and say Build.

And if I select Close here-- now, maybe you don't understand that very well. But essentially what it's doing is going out to a pool of parts and it's bringing them in and assembling them based upon different rules that I have within the add-in. OK. So nothing fantastic here. We've all seen product configuration before. OK?

So what if I want to build something a little bit differently? Let me think here. This is going to be 16, this is going to be 10, and this is going to be 100. And instead, I'm going to take this all the way to the moon. And what are my options? Well, the SLS heavy. So I'm going to build this instead just so you can kind of see. Now, within that same assembly, I removed all the components that were necessary and brought in other components, constrained them together, leveraging the normal behavior of Inventor in terms of building assemblies. So once again, just a simple little product configurator.

Now, once we have that in place, I'm going to go ahead and I'm going to save this assembly and I'm going to give it a name. I'll just call it SLS Heavy. And I'm going to save that. OK. Now that I have that, let me pop over here to my PowerPoint, present that once again.

So now that we know what design automation is, as opposed to an end user going out to their directory, finding all the sub components that they might need, bring them into assembly, constraining them altogether, well we can apply logic to make that happen. Well, the next step. Now that we have the models, that's one thing, but where's the real value? The real value is with the drawings, right? Those are the things that we send out to potential customers in terms of quotes, right? Or what about fabrication? What about manufacturing? Well they're going to need 2D documentation as well.

So this is the whole point of building up that drawing automation. So what is drawing automation? Well it's the means to take 2D documentation, develop some sort of logic to automatically create these 2D docs, these drawings. OK. What is necessary in order for us to do that? Well, if you know how to use Inventor, which of course is a critical aspect to all of this, is you have to understand what Inventor does and how it works in order to be able to leverage it.

If I was an end user and I wanted to start creating 2D documentations, well, what would I have to do? Inside of a drawing I have to define how many sheets do I want? What size are those sheets? What kind of views do I need? Within those views, are there certain components that are turned on and turned off? I want to be able to develop these views to represent and convey the accurate information necessary for manufacturing and fabrication.

Obviously a parts list needs to go along with. We need to know the cont or the quantity of different components that are involved within an assembly, and then of course, the all important dimensions and balloons. What are the sizes? What level of accuracy are we trying to convey within our drawings?

And then lastly, sketch symbols. Nothing more than text or different things that we want incorporated within the drawing. Maybe it has to do with different specifications or things like that. We want to make sure that we're putting those inside of the drawings as well.

So what does this all look like? What do we need to do? Well, what I'm going to show you here in a moment is what do we do after we configure the model? How do we save out a drawing? How do we create, name, and activate different sheets? I'm going to show you that within the code as well. How to create scale and locate views, how to control component visibility, how to create and manipulate the different parts lists, adding dimensions, adding balloons, and then adding and manipulating the sketch symbols.

So all of this we're going to do inside of iLogic rules. This is not going to be part of an add-in. This is not going to be anything special. It's just going to be iLogic. So what does that look like? Here we go. If I bring up Inventor here, let's make sure we're presenting, and end that. There we go.

All right. So now that we have our model, one of the first things I want to show you is how do we get that drawing? How do we get that initial drawing going? OK. So I created a rule and I'm going to crack this open so we can take a look at it.

Actually, you know what? Before I do that, let's walk through this. Do you guys want to see what this does first? I think that'll be a little bit more important to kind of frame the conversation per se. So if I right click on here I'm just going to run this rule. What it's going to do is it's going to ask me what template do I want to use? Just like if I was an end user. If I wanted to start creating a drawing of my assembly here, I have to define a template. So understanding and working with templates, creating those templates in order for it to use. Just going to use this template that I've created previously. And inside of this template is where I have the iLogic rules.

So we're going open that and then I'm going to get prompted, well, do I want to open it now? Now that I have it, now that I have it saved out, do I want to open it up or not? Do I want to start working with it? Yes or no? Well, in this case, I'm going to select Yes and it's going to activate that.

OK. Now that I have the actual drawing file available, now I want to start generating those things that I pointed out before. How do I create the sheets? What about the views, component visibility, so on and so forth? Well what I'm going to do is I already have the safe copy S rule, which I'll go into in a little bit here, but initially I want to start this off by starting to create some different sheets. And I have these rules kind of chained together in such a way to allow me to start doing that. So first thing I did was I generated a sheet. I scaled the sheet, I sized it, I gave it a name, and then I started placing the view. So it generated a few views, put in a parts list threw down some balloons and some dimensions, filled in some information while I have a drawing.

I mean, granted this isn't something that you're going to use for fabrication and manufacturing, but the concepts are right there. Everything that I just suggested previously I've done right there in that drawing and it didn't take very long either. And there's a few things that are happening behind the scenes that you may not even understand or even appreciate to some degree.

OK. So what does this look like? How did I get here? What did I do. Well, the first thing I did is if I go back over to the assembly from the context of this assembly, how did I go out and create a drawing? How did I do that and then create the drawing and then of course name the drawing and then open it up? How do you do that? So if I go in here and I edit this rule, one of the first things that I want to say about this iLogic or all of my iLogic rules that I've created is the simple fact that very rarely do I use the iLogic snippets.

And you'll notice as we go through the code here that you won't see a whole lot of actual ideological snippets being used. Everything that I do I leverage the Inventor API. Why do I do that? Well, simply because that's where all the power comes from. If you're using Inventor and you go up to the ribbon and you start pushing buttons to do different things like generate a view or lay down a dimension or anything like that, you're effectively calling on the Inventor API to do something. So why not leverage that within the automation as well?

The iLogic snippets will get you part of the way and it's really great to start if you're a beginner. If you really want to start understanding the context and the structure and the architecture of developing code, the snippets are great. However, they don't do everything that we want to do. Not only that, the snippets are just a starting point. That's not everything that you can potentially do with the Inventor API.

So why not go straight to the API and start using that? Well, that's a great suggestion Tom, however I don't know anything about the Inventor API. Well, if I were you, I would start doing a little bit of research. Me personally, I've never gone to any coding classes. I'm not a programmer, I'm an Inventor user. I'm a 3D modeler. That's all I've ever really done in terms of engineering. Everything I've learned here were from either other resources within Autodesk or Google, YouTube, other online learning sites to kind of give me a way to understand what it is I'm trying to do.

But like I said before, that's the most important part, is you have to understand what you want to do. If I want to create a sheet inside of a drawing, how do I do that? Well, personally I just go online and go to YouTube and see if anybody else has done something like that. And that's how I got started until I really started to understand what they're trying to accomplish. And then from there start looking through the Inventor API help, and things just really started clicking. They started making real good sense in terms of what I need to do.

So for this example right here of how do I go out and I want to create a drawing of an assembly that I've already created? Well, this is how we do it. You're going to notice a couple of things here. I create my first subroutine there. I call it sub main. And this is a good common practice to be able to organize. So I have a sub at the top and I have a sub at the bottom, and this allows me to do a couple of things like be able to collapse the code and organize the code.

I know that back in the day when I started creating different configurators and writing logic in iLogic, it was just this one big, long string of code, numerous lines. Trying to troubleshoot that, trying to debug that was nearly impossible. But if you organize it and you construct it in such a way, it makes things a whole lot easier, particularly things like indenting and spacing and commenting, adding different things in order for you to understand what's happening with your code.

You're also going to notice that if anybody's used iLogic, at the top I say if parameter configure eight, yes, then do something. OK. This is just a common thing in terms of instead of just typing the parameter and anything in the iLogic, if it's a recognized parameter it's always going to come in as a blue color. Well, I specifically call that parameter by using the parameter object there. OK?

Another thing, just a little bit further down there is shared variables. How many people know what shared variables are? Shared variables are extremely powerful, especially in the context of what I'm doing here. A variable inside of iLogic allows us to-- it's a placeholder. It's a means to put a value somewhere. OK. But a shared variable is not at the phi level, it's at the application level, which allows me then to set a variable and use it through numerous files within the Inventor session. I don't have to recreate that or I don't have to create it and then save it out somewhere and then recall it later on. It's right there within the context of the session. So it allows me to go from one file to the next to the next. And because that's exactly what I had done here, I went from the assembly and I want to transport or share that information with my drawing. So generate and create shared variables, set them, and then you can call them later on from other files. So very powerful to use shared variables. OK?

So further on down then, I'm not going to go too far into this. But essentially, those are the big things. I'm calling a file where I want to open it. I'm setting different variables and then I use those to create and then open this document.

So this is a big one. Used message boxes, feedback information to your users. There are some input boxes that you can create inside of iLogic as well where you can ask an end user for a value or to do something. Not just feed them information, but require information back and then use it through your code later on. OK? So in this case, I'm asking, would you like to open up the drawing now? If they say yes, then I'm running a bit of code to open up that file that I just created. If they say no, it does nothing. So yeah, very simple. And then of course if there isn't one to create from, it's going to throw up a little bit of an error to let you know something's happening.

And you really should do that. Being able to generate the code and make it do something is one thing, but being able to generate the code and then of course have some feedback for your users is going to be even more helpful. And you notice down here I have another function. So now one of the things that I always try to enforce or suggest rather when working with clients about developing code is use common code writing practices, use subroutines, use functions. Being able to apply some variables to this function, have it churned through that, and then have some sort of result from it that you can use later on. Very, very powerful and you should use that as well.

Also, it allows you to call on these functions through various different moments throughout the code. You don't have to rewrite it every single time. Redundancy is a huge thing you want to try to avoid inside of when writing your code because what happens if you have to edit it? Now instead of adding it in one location you have to add in numerous locations. What if you miss a location? More debugging to do. So if you can condense your code, use functions as much as you possibly can, this will save you a lot of time and a lot of overhead. And if you do start debugging and you do start understanding where there might be problems, you know exactly where to go. This one function is where my problem's at.

So from there, now that I have that drawing I know how to open up, now I want to start creating my views and everything else associated to my drawing here. OK? So through the other rule inside of the assembly, I'm actually calling on this first Save Copy As rule inside of the drawing. So this is really where the power's at. This is what's actually doing the work in terms of I've set a bunch of shared variables in terms of the drawing name, the assembly name and what I want to call it. I'm going to pass it here and then now I'm going to recall that information and then use it in this lower function to not only save the assembly, but replace the reference because anytime that you create a drawing it needs a reference. You have to have a reference. If you don't have a reference, how are you going to generate views inside of Inventor?

I mean you have to understand these things ahead of time in order to start writing out your code. OK. So I have this file, I've replaced the reference to the assembly that I generated earlier, and now I have my starting point. I have my drawing, but there's nothing there. Now I need to configure that, OK? So what do I do? Just as I stated before, if you know how to use Inventor you know the logical steps in order to create a drawing.

Step one, sheets. I need sheets. So what does this rule look like? It's nothing more than defining how many sheets I need and what those names of those sheets might be. OK. And there's a lot of different things that you can do, a lot of different best practices, like creating arrays or collections. So if you need to create a drawing set that has 50 sheets, no problem. You could do it a number of different ways. You could do it where you create an array and then you start populating that array or collection to make sure that you're accommodating the number of sheets that you need. OK?

I've seen people use loops in order to do that and then they have to define how many or the count of those. But what if you don't know the count? What if it's a variable in itself? Maybe in one situation you need five sheets, another situation you need 10 sheets or so on and so forth. There's a number of different methods you could do to accomplish that. One of those is to create a collection or use an external data source. This is something I had talked in last class last year about external data sources and working with design automation is sometimes you have a bulk of information or a mass of information.

Now, writing all that or hard coding it within the rules can be challenging. Not only that, it's really not user friendly. And if you need to make changes or if you need to be conditional about it, it's not really the best way to do it. But using an external data source is a great way to do that.

Example of an external data source, an Excel spreadsheet. Everybody knows how to use Excel. You just start plugging information in rows and columns, you make a connection through an iLogic rule, and then you can feed that information or consume that information. Another external data source, XML files or SQL databases, Access databases. There's a number of different ways that we can store information that we might need to call on later on. In my rules here, I'm using Excel spreadsheets.

All right. So what sheets do I need? And then if you start becoming familiar with the Inventor API, you're going to understand that we use a lot of enumerators or enums. I've seen instances where you can call in a numerator by name. Most of the time I try to use the code that's associated. And this is all defined within the Inventor API help as well. OK?

So what sheet size do I need? In this case, it's going to be a D size. I just know that because I know that. But 9, 9, 8, 8 is D size. And then if you hover over that it's going to give you a little bit of information, hovering over things in iLogic.

How many people are using Inventor 2018 update two or newer? All right. So more than half of you. This is good. If you're not already using in Inventor 2018, at least get Inventor 2018. And update two allows us to do basically like IntelliSense, where if you hover over code inside of iLogic, it's going to give you some hints as to what you should be doing or what that architecture might look like.

In the case of a call here, I'm not doing any calls. Well, right here. So I want to get the active document object in order to do something with it. Just by hovering over it it's telling me that this is a read only property that's going to give me the active document from the document class. So it's getting the active document. That's step one. Let's get the active document and then we can start manipulating it, OK? So it's these processes of understanding the steps necessary.

So I have some comments here kind of explaining exactly what's happening. Add number of sheets and then name them, delete sheet colon 1 because I don't need that initial sheet anymore because I've just created new sheets and I've named them. So I'm going to get rid of sheet number one and then I'm going to activate the main sheet, throw down a border, throw down a title block, and then I'm going to the next rule. So this is what I mean about chaining them together, is I'm doing a particular function, I'm accomplishing something, and at the very end now I want to go to the next rule.

Other methods that I've done in this situation, what if there's an error? What if something happens when I'm trying to create that sheet? Do I necessarily want it to go to the next rule, which is add views, if I haven't really accomplished what I want to do initially? No. So sometimes you'll want to throw down some error reporting or checking in order to make sure that everything is satisfied first before going on to the next step. OK? In this case, this is a fairly simple rule and what it's trying to accomplish, and the possibility of error is next to nothing. So I don't have to worry about doing an error checking or conditioning in that respect. And then after that I'm going to go and start adding my views, OK?

So what does ad views look like? So I'm going to open up this guy. And this gets a little bit more complicated. As we know when we create views inside of drawings, being a human being doing it, being able to see that sheet in front of us and understand its width, its height, things like that, appropriately and accurately locating them and scaling them, how do we do that? We do that from a visual standpoint. Well, code doesn't have a visual standpoint. So you've got to define every little thing. OK?

What are my views? Where are they going to be located at? OK. So this guy right down here I created an array or a collection of points, four of them to be exact, of where those four views are going to be located at. Above that I've defined some variables and some values that basically take the sheet height and the sheet width regardless of what it might be. If it's A size, if it's D size, whatever the case, I'm going to take that and first I want to do some sort of calculation against it so that way I can make sure that the views are always in the same location relative to the sheet size. OK?

So that's some of the first things I'm doing. And then once again calling on those shared variables because I want to share those throughout my rules to make sure that I'm using consistent values and consistent information. OK? And then from there I'm going down here and I'm setting some view styles. What if it's shaded? What if it's wireframe? What if it's neither? What if it has hidden lines? I want to be able to represent that. Once again these are going to be through the enums.

And then after that, then I want to create the view. So I'm setting a whole bunch of variables, I'm collecting all this information in terms of what I want to do with the views, and now once I have those I want to generate those views. So I'm just doing a loop, a four loop, a four next loop. Start with number one, go to number two, then three, then four. So I've identified some conditions. If it's number one it's going to be a base view. If it's number two it's going to be a projected view. If it's number three it's going to be a detailed view.

Each of those have different requirements. Once again in the Inventor API these functions clearly outline what those requirements might be. In terms of my base view, what's my model reference? Just as if I was an end user and I wanted to create a view I have to select-- that dialog box comes up and it says, well, what view do you want to create or what's the reference? So we have the model reference, we have a point, we identify the scale based upon the calculations I did further up in the rule, view orientation and view style.

Some of these are requirements and some of them are variance, or rather they're not required. So if they're not required, sometimes you don't have to do that. But if they are required or if it's something that you specifically want to detail within your drawings, then obviously you want to include that within your functions here. So add base view, add projected view, add a detail view, so on and so forth.

And then after that I'm going to go and start creating the parts list. So in order to create a parts list inside of an Inventor drawing you first have to have something you want to create a parts list from. Generally that's a view. So that's why it's the next rule to go in place.

Below that I have some other functions here. What if I want to recreate this? Well, if I want to recreate this I have to tell Inventor, OK, delete the views that are currently there so that way I'm not layering view on top of view, on top of view, on top of view. You want to make sure that you're cleaning up after yourself as well. So having a delete in there somewhere on occasion you can create it as a function so that way you can call at different times. You don't have to have it within the code string there every single line. OK?

And then, of course, how do we scale it? So I created this function down here that I can pass information from all the views through this in order to be able to determine what the view scale should be relative to the sheet size. So once again if the view name contains ISO in it-- so if it's an ISO view I want to do something a little bit differently than some of those other views. So I'm on to scale those a little bit differently, OK? And if we go back to the drawing here you're going to see that.

This ISO view is slightly smaller than the other views. I just have it in there as a representation. So I have a conditional statement in there that says, well, if it's the ISO view make it a little bit smaller, but the other views I want much larger.

OK. Component visibility. If I have something within the view that I want to turn off-- I mean, guys, this rocket example is super, super simple. I understand that and I know that a lot of companies out there, the products in which you guys create and the views that you need to generate, there are lines. There's geometry everywhere. Some of that you want to represent, some of it you don't. So turning on and off different components within those views is going to be absolutely necessary.

So I have some things here and I'm not actually doing it within this example, however this is the code to do that. So I'm identifying what views I want to affect or manipulate, and then from there what I did here is I created these two variables right here and I call them Name Check Value. So basically I'm populating a variable. It's a string variable that says, OK, later on if I turn through the views and any of those views contain this information in it, then do something with it. If it doesn't, then don't do something with it. So it's a way for me to create a variable to do a check against the name.

And as I go down now I'm going to go through the different sheet, I'm going to go through the different views, and once I find the views that I want to do then I'm going to turn off the visibility of those occurrences. So I have to loop through the assembly that's associated to the view, go through each one of those components. Now, what if it was an assembly that has sub assemblies and what if those sub assemblies have other sub assemblies and then finally down to the components? Well, then you're going to have to do a little bit more complex of a loop, so that way if we find components within the context of an assembly that have sub occurrences, go through those sub occurrences, those different leaf nodes in order to find those components that have the appropriate name or meet the criteria of the name check values that I've created up there.

If they meet those values then I'm just basically turning them off. And that's what I'm doing here. So set visibility to that occurrence. If it meets that requirement then turn it off. It's that simple. So just like an end user. I mean if you task an end user do the same thing, they have that knowledge inside of the head. We need in their heads. We have to provide that knowledge to the code in order to understand that, OK?

Adding a parts list. This one's a little bit easier, adding parts list, because the requirements they're fairly simple. As long as we have views we can create a parts list. And Inventor does that some of that heavy lifting for us. Some of our settings indicate hey, if I'm going to create a parts list automatically put it in this upper right hand corner, automatically attach it to the border. So it does some of that work for us where we don't have to define nearly as much of that.

So in this case, the first thing I'm doing is if there is an existing parts list, let's go ahead and delete that guy. That's why I had that try catch there. If there isn't, of course, then go over it and then we're going to create it based upon the drawing view number one. Now, you can define it based upon if it meets a criteria name. In this case, I always know that the first view that I put on this sheet in this drawing, it's going to utilize that in order to generate the parts list.

OK. And then where do I want to place it? I'm going to place it in the upper right hand corner. If not then I'm going to create a 2D point. If there's no border then I'm going to place it somewhere. So I'm expecting there to be a border, but if there isn't a border then where do I want to locate it in that regard? Once I have that all done, then we're going to go on to the next rule.

Are you guys seeing a common pattern here in terms of how I'm writing this code? I put everything into a sub, a main sub, run all that and then call on different functions, as I want different things to churn through or calculate or do anything along those lines. OK?

Reorder bomb items. I created this rule as an example for a different customer that perhaps as I start changing my assembly, it's going to update my parts list. And one of the things that happens is sometimes those item numbers get out of whack. It's not all sequential like I want it to, or perhaps there's different components within the parts list, the different rows. I want to move those around, or maybe depending on what's in the view, I want to turn those things off.

OK. So I'm just doing a simple re-number here. So I'm getting the drawing document, getting the parts list, and then I'm just doing a simple re-number. And then of course once I re-number it I'm going to overwrite those in the bomb. Remember, the information that comes with the information that populates the parts list and the balloons inside of drawings comes from the bill of material, right? So we have to affect the bill of material to have the drawings automatically update in that regard.

Now that I have that parts list, I have everything good to go, now we come to the big ones. These are the hardest ones. Now, whenever I talk to customers and they want to start automating drawings or do things like this, everything that I've talked about up to this point most people really understand. I mean it's common sense in terms of how to generate drawings.

The hard part is placing the balloons, placing the dimensions, because as an end user it's very simple for me to say, OK, I want to place a balloon and then point it to some object or entity within a view, and Inventor does that work for me. But if I'm not an end user and I'm not selecting it, how do I tell Inventor to point to an entity? How do I tell it to point to a particular component within a view? Is it 2018, 2019? If you're using the latest Inventor, we have an ability within Inventor to right click on some geometry inside of a 3D model and then assign a name to it.

And has anybody seen that, that functionality assigning names to faces, edges, things like that? OK. So that's very, very important and somebody indicated to me earlier that, hey, that's a really cool feature. It's brand new. We weren't able to do that before. Well, not really. I mean the ease of use to be able to do that hasn't existed before. But it's leveraging a common concept that people have been using for a while, particularly in terms of automation. And that's assign attributes, assigning some sort of tag or a label to geometry within an assembly so that way we can call on that later on. OK?

And so that's what I've done here, is I have inside of my model here some faces and if I go into the rule here, I have some edges that I've applied some tags to and I named these tags Balloon as I've highlighted right there. So essentially what I'm doing in this rule is I'm going to the assembly that makes up that view and I'm just iterating through every single component within that assembly. If that assembly has some assemblies then I'm going to go through those sub assemblies. If those sub assemblies have components I'm going to go through those.