Inventor iLogic: Beyond the Basics

JON BALGLEY: So, my name my name is Jon Balgley. This is iLogic-- Beyond the Basics. I hope you're in the right class. I'm really excited to see so many people here. That's great. I have a ton of information that I want to convey today. The first time I ran through a practice presentation, it took 2 and 1/2 hours, so I pared it down a lot. But I'm going to try to use up the full hour. Yeah, so we'll see how it goes.

In the handouts, there's 2 and 1/2 hours worth of stuff there, so be sure to download the handout. And there's lots more things there, the things that I pulled out to make it fit. So, what about me? So I work on the iLogic project at Autodesk. I've been with Autodesk for 12 years. Before that, I worked on Configurator 360 and Inventor ETO, and before that, lots of other CAD stuff in ancient, ancient days.

Today, we're going to look at a couple of different examples. Actually, we're going to look at three different kinds of things, but in two examples. So I'm going to jump right into that. When I talk about iLogic with people, usually I find that there's three categories of iLogic usage-- what I like to call small, medium, and large. Small, medium, large. You can either use iLogic for small things, medium things, or large things.

So the small applications of iLogic, I find-- and you can nod if this resonates with you-- is for what I call nitpicky stuff. Taking care of little details for you so that you don't have to think about them and you don't make a mistake about them. And at most, they're going to save a few seconds of your time if you were to do them manually. They're not big things, but they're small, mostly because you don't want to forget them. You don't want to forget them.

And one point about this is that they operate in the context of ordinary Inventor usage. You're using Inventor in the normal way. You're doing modeling, you're doing assembling, and you're just using it. So it's nicely integrated with regular Inventor and Inventor usage.

Medium applications are where you attempted to save a minute or so of time. So it's not just a really quick, trivial thing that you're trying to automate but, rather, a chunk of work inside of a workflow. So you're still doing ordinary Inventor usage, but it's just one small aspect of the workflow. We're going to spend rather a proportionately larger percentage of our time today on a medium application.

But large applications are different, where you're trying to automate an entire workflow of some kind so that when you're actually using the iLogic application, it's not exactly typical Inventor usage anymore. You're doing something substantially different. You're kind of transforming Inventor into a new kind of tool of some kind. Or you're trying to save hours of time or really enable a person in a very different role to do it.

I was talking with somebody this week, and they were saying that they've taken some process that used to take two days of someone's time, and they've reduced it down to a minute. And so that radically changes your business. Not an easy thing to do, to get to that level of automation, but if you do, it's radically different.

So you can see there's a number of aspects to a large application of it. But the one thing I want to point out is the last item here-- data wrangling. That's a phrase that I've heard. That's a matter of making sure that you have the right files in the right place. Sometimes you'll need to be copying files. And I'm not going to be talking about that aspect of it today, but it's always an important aspect of a large iLogic application, is to do that kind of what I call data wrangling.

So it's always complimentary. It's always going to be there. You can choose to do it from within iLogic, or you can kind of consider it as a separate aspect.

So mostly today, I'm going to-- actually, for the rest of the session, I'm going to be-- close that. I didn't really want to be there quite yet. I'm going to be in Inventor just demoing. We're just going to see-- this is an instructional demo class. And so I'm just going to go through it and talk through how I'm trying to solve particular problems. There is a presentation online that you can download that kind of walks through it, as well, but I'm not going to using that today. So it's all going to be live online on someone else's computer. Pretty scary.

Yeah, so we're going to use this model, both for a small application of iLogic and a large application of iLogic. It's a little small to be a large application. It's only got a handful of parts. Typically, your assembly is going to have a lot more parts. This is a very simple sheet metal cabinet. And the intention of it is that there's a form that goes along with it.

You can change the various aspects of it to-- I want to be in two shelf mode here. You can change aspects about it, like the number of shelves, and it will automatically do that. And you can change the width. Change the width to, like, 26, and it will get narrower. So just by interacting with that form, I'm doing all kinds of Inventor operations. But I'm not really doing a typical-- I don't have to be a typical Inventor user just to use that form, right? So that's why large applications are targeted at a different role or a different person.

So one of the key things about using iLogic in large applications is that there is a form, right? And so that's one of the first things to think about. I'm going to close this. I just want to demonstrate a little bit about the form itself. So this particular model really doesn't have that many parameters. It's really kind of simple. Your applications will probably have 5 or 10 times as many parameters that are in here. But even so, you can see that there's a bunch of them here, and you have to set up the form to address those parameters.

So I just want to give you comfort-- you know, authorize you to have complex forms. Expect to have complex forms. Two things I want to point out about forms that you may not be aware of. The first is that there's this option called size limits. And so you can specify a-- if you click this button, you can specify a minimum or maximum size. And those are typically measured in terms of ems, and ems is a resolution-independent unit of measure. So that if your form goes onto a 4K screen, it won't be a tiny size. So that's one thing. You can set the minimum and maximum size.

And the thing that I just want to point out is that when you choose-- depending upon which set of buttons that you choose here, there's different options for what buttons you can choose. If you choose just Done, then it will immediately update upon each change to a parameter in your form. If you choose OK, Cancel, Apply, then you get these different buttons here. Then, it will only update the model when you click the Apply button or the OK button. So you can have different behavior based on that.

For larger, more complex models, you'll probably want the OK, Cancel, Apply scenario. For simpler models, you probably want the one button Done immediate update style. I'm going switch back to-- all right, I guess I'm going to cancel. Cancel? Yeah.

OK, so let's look at some rules. So we're going to start by looking at some small rules, but in the context of a larger application. So this first one-- I'm going to look at, actually, the second one here. Edit the rule. Is a rule to do range checking of parameters. Common use of small applications of iLogic is do range checking to make sure that the parameter value's in range. You saw that I entered a value for the width. I could easily make typos. In fact, on my computer, the three key sticks. So I constantly get 333 instead of-- yeah.

So that's why I have this nice rule here, is to set a minimum and maximum width. So I've got these local variables here. And then, what I do is if the width is too big, if it's greater than the max width, then I have I can do either of these two things or both. I can put up a message box that warns the user to say, hey, it's too big, but I'll just go ahead and do it anyway. Or you can clamp the parameter value to the maximum or minimum. So you can clamp the range, the endpoints of the range.

So I can just do that real quick. Go back to the forms. Click on the form. Change the width to be 99. Num lock, 99. And oh, what happened? It's not making a 99-inch wide cabinetmaking. It's making a 48-inch wide cabinet, right? So you can see it actually changed the value in the form. It didn't go ahead there, and it made only a 48-inch wide cabinet.

So let's look at another example of a-- come back-- small rule. This one, I'm not actually using this one, but it's an interesting one, shows an interesting technique. The idea of this is I want to clamp the values of the parameter to be in 1/2 inch increments, either a half inch or full inch increment. So I've got this nice little thing here. If you just look at this rule here, you can see pretty clearly what it's doing, right? Everybody nod your head that you can see pretty clearly what it's doing. All right, good enough.

So I got this little bit of code here from one of the snippets in the iLogic rule letter. If you go in here, there's a snippet for round to increment, blah, blah, blah. But if I had duplicated this three times in here, it would not be easy to read anymore, right? So what I've done here is created a separate function for round to half, put the snippet in there. And then, to make that work, you have to put the main statement of the rule inside something called submain.

So if you do that, you make the main part of the rule be in submain, then you can have auxiliary functions and subroutines in the rest of the rule file. So that's a good technique when you've got something that's more than trivial in a single rule. You can create your own procedures and subroutines there.

Just a FYI, if you don't have separate functions like this, then you don't need submain and all that. But iLogic will wrap your code in a submain automatically for you. So that's what's happening under the hood. If you do it explicitly, then you have the option of having additional procedures and functions.

So one more small rule is this one. Let me close this and show what it does. I've got this rule that's going to give me a warning if this distance is too small. If you make a very, very narrow cabinet with a very wide window that might be too little metal-- is that the right way to say it-- in that little area there. So I have a little rule that checks for that-- keyhole warning.

So I'll come back to this line of code here. So this is a rule that's just going to give us a message if there's not enough space there. And what's interesting about it is that I can't clamp one particular parameter or another, because there's multiple interacting parameters here. So I have to interact with the user and ask the user, which one do you want to change? Tell the user, which one do you want to change?

So, how does this one work? Well, I'm not even going to bother to check. This is a Boolean parameter, a true/false parameter. So I'm not even going to check if I'm not doing any cutting, if I'm not having a window at all. And if there is, then what I'm going to do is reach into the door panel and grab this available size space parameter. And that's a reference dimension in the part. Excuse me. So a reference dimension in the part.

So it's just there. It's in a sketch. It's measuring the distance between two edges. It's very straightforward. And so that determines the available space. I do some arithmetic here to calculate the space that's needed. And if the space needed is greater than the available space, then I pop up the message. Right? Very straightforward.

There's two interesting things here. The first is that using the parameter function does not trigger the rule. Any changes that impact the available side space reference dimension are not sufficient-- without this line, without the first line, it's not sufficient to trigger the rule. So I had to put these trigger statements in here explicitly in order to make the rule be automatically triggered. So all I have to do is just mention the parameters that are contributing to this reference dimension and assign it to a dummy variable.

So this is just a dummy local variable. You can name it whatever you want. It's common to call it trigger, because that explains why it's there. And that's what triggers the rule to run. The other thing that I want to mention is that the available side space depends upon-- or testing the available side space depends upon the actual current values of these parameters. So it's important that this rule comes after this other rule here, which we're going to talk about next, which actually sets the parameter values in the component parts.

So one thing you may not be aware of is that the rules can be dragged to be in a different order. So I put my keyhole warning at the bottom here. The rules can be dragged to be in a particular order. When there are multiple rules triggered by parameter changes, iLogic runs them in order. And sometimes, the order matters. So sometimes, the order will matter.

So, for example, this other rule that we saw earlier, the check width range, we wanted it to clamp the value of the width before it actually started processing it. So it was important that that one came before the rules that do the actual processing. All right, I'll put this back up here somewhere.

OK, so we're going to now jump into how do we do that processing. So this rule here uses a technique that I call top-down data flow. Top-down data flow. It's my phrase, not a standard thing. And the idea is that the top level assembly has the information that is needed to control the rest of the assembly. And this iLogic rule is going to push the data down into subcomponents to allow the subcomponents to do whatever they need to do. So top-down data flow, an iLogic rule, pushes the data down to component assemblies.

And you can see here how it does it. It's not magic. It's just saying, well, the door panel's height is going to be set to be the height of the height parameter in the top level assembly and so on. You don't have to exactly match the names here. The names can match if it makes sense, or they can not match if it doesn't make sense. So here, in the door panel, I want the width. There's a parameter called width assembly, and I want to push the width parameter from the top level assembly down into that parameter.

And so I'm doing this for all the various components that are in this model, pushing them down. And so this rule is called parameter links. And so it's linking the top level assembly's parameters to lower level component's parameters. Top-down data flow. Now, there's nothing in Inventor outside of iLogic that is aware of this. There's nothing in Inventor outside of iLogic that's aware of this.

So that can lead to some occasional odd situations. Like if I just go behind-- if I just become an ordinary Inventor user and open up this component part and then I go to the parameters and I happily-- oh, by the way, did you know that there's this filtering mechanism here? If you've got a lot of parameters, you can just look at the key parameters. It gets rid of all the D zeros and so forth. So it makes it easy to spot things.

Well, if I change the width, go in here and just kind of go behind iLogic's back and change the width to be 24, it works just fine for the part. But what happened in the assembly? I've got about the cabinet body is too big, and so nobody did that. There's an old joke. A man goes into a doctor's office and says, Doctor, it hurts when I do this. And the doctor says?

AUDIENCE: Don't do that.

JON BALGLEY: Yeah. Everybody hear that? The doctor says, don't do that. So the same rule applies here. Don't do that. Yeah, exactly. So I can change this by going in and resetting the width, 44. Look, there's my keyhole warning there. Yeah, don't do that.

Next, so, parameter links, top-down data flow, only managed by iLogic. One implication of this is data wrangling. Because we're pushing data into the component part files, we're changing the part files. So if you're making custom cabinets like this for somebody, you're probably going to want to have a copy for each order that you make. So that's the data wrangling that I'm talking about. Outside of what I'm demonstrating here, somebody has to make a copy for each order. And you can build that into your iLogic, or you can choose not to.

So let's look a little bit more about how we're managing the design of the cabinet from the rules. The window and the other cutouts on the door-- well, let's see. We've got a manage window rule here. So, first thing that I want to point out is that, first, I had the parameter links rule that we were just looking at. And that was controlling the top-down data flow, pushing the parameters down into the components. And I could put everything into one big giant rule, but that seems like a bad idea to me.

So one thing to be aware of is to split your logic-- loosely speaking, your logic-- into multiple rules so that you don't have any one rule that's enormous. Try to, where it makes sense, where the logic is disjoint from the other rules, then keep them in separate rules. If the logic is interrelated, then sure, keep it in one rule. So where logic is disjoint, keep it disjoint. And where the logic is interrelated, keep it related.

So this manage window rule is pretty straightforward. It's controlled by this front cut parameter. And so if that's true, then we're going to suppress or unsuppress, whichever way it goes, the features in the part. So feature.isActive is controlling the suppression state of the feature in the part.

So a couple of things to notice about this. The first is that the part is relatively stupid. The part is not aware of the suppression going on here. So we're letting the assembly control it. And so that allows you, also, to divvy up the, loosely speaking, logic of what's going on. So the logic stays in the assembly, and the part stays relatively dumb. That can be a good technique. I want to generally hold questions until the end. If it's a quick one, I can--

AUDIENCE: How do you deal with filename changes?

JON BALGLEY: How do you deal with filename changes? Actually, I'll get to that in a little bit, or there's an interesting thing. We'll see if it answers your question. Oh, I missed it. I'm going to go back. Thanks for the tip there. Yeah, coming back to this earlier rule about changing the parameter values. In all these uses, I'm using the function parameter, the parameter function. In all these cases, I'm referring to the part name here. I'm referring to the part name.

And that's fine. iLogic will do that. But there's this one case down at the bottom here. The shelves, which I'm going to show you in a second, are individually suppressed or unsuppressed based on how many there are. So in some scenarios, there may not be a bottom shelf. And so in that case-- let's do that here. If I go to the forms and change it so that there's only a middle shelf and no bottom shelf and then change the width-- come on. 26. Change the width. Look what happened to the shelf. The shelf didn't update.

Because I was referring to it via the component name, by the component name. And so if it doesn't find it, it doesn't do anything, and it just kind of leaves it the way it was. So the solution to that is to refer to-- and you can see it down below here. You can use the filename instead of the component name. Change this. Comment this out. Come on. Come on, fingers. Comment that out. Save. Close. Form.

And I go back to the form and let it recalculate everything. Come on, fingers.

AUDIENCE: The shelf is longer than the [INAUDIBLE] width.

JON BALGLEY: Say that again?

AUDIENCE: Your shelf was longer than the [INAUDIBLE] space.

JON BALGLEY: Yeah, that was-- right. I forgot to hit the button. That's the problem, is because it was referring to it by the part name, it didn't actually do it. And so referring to it by the filename will get it no matter what the part name, the occurrence name, is. Referring to it by the filename. So it used to be grouped by the part name. Now it's by the filename. Was that related to your question?

AUDIENCE: Yeah. No, it was [INAUDIBLE]

JON BALGLEY: All right, then I'll get it later. OK, so let's look at how the shelf rule works. How am I doing time-wise? OK. So the shelf is controlled by the-- of course, again, I'm splitting my logic into multiple rules. The shelf is controlled by this shelf spacing rule. And it could've been done with a pattern, no question. A pattern could have handled this scenario. But for training purposes, we're doing them as individual shelves.

And so if the number of shelves is one, it disables two of the shelves and leaves one active. If it's two, then it disables the middle shelf and leaves the other two active. And if it's three, then it enables them all. That's the basic idea here. So the component.isActive function does two things. Let's take a look and see here.

If we go to the Model tab, you can see that with only one shelf visible, it's suppressed these other two components. So to suppress a component, you have to be in a custom level detail representation. Hi, Dave. Thanks for nothing. You have to be in a custom level detail representation. So you'll have to actually create that. You can do a new level of detail, as necessary. And then you can call it whatever you want. A lot of people choose to call it the iLogic LOD. And then the suppression happens in the context of that LOD.

I'm going to save this file here. Let's see if I can save. Yeah, that's OK. Unfortunately, or maybe unfortunately, the bill of materials always looks at the master LOD. So now the master LOD might be out of sync. But what iLogic does with the component.isActive is two things. First of all, it suppresses it. But in addition, it marks the non-active ones with the reference BOM structure so that they don't appear in the parts list.

So in the parts list, there's only one shelf-- the normal state one-- and the reference ones are left out. So that's something to be aware of, that iLogic takes care of that, within reason. It marks the suppressed ones as reference, and if you set it back to being active, it'll turn them back into normal components.

The other implication of all of this is that by using suppression to control the content of the assembly, that implies that you need to have all the components there initially, and some of them get suppressed. So you have to build what I call a master model. Maybe that's an overused term, but a model that contains all of the possible components have to be present in the assembly, and then your rules will turn off some of them. Or you can start with some of them turned off, but your rules will turn them on and off. But they must be present to be suppressed.

So that's the core of a large application. So we've looked at how it can turn components on and off. We looked at how it can control the overall size. We've looked at how you can utilize small rules in the context of that. And then, in a second, I'll go into some more exotic ways to do things in the context of this example. So let me get the guy behind you to repeat his question first.

AUDIENCE: So if the filename changed, the actual IPT filename changes, then doesn't refer to that file anymore, so it won't work in iLogic, will it?

JON BALGLEY: Yeah. So the question was if the actual name of the file changes, how can you handle that in iLogic? Let me put my handy-dandy rule here. If you're just changing parameter values, then this statement in here is referring to a filename. It's code that is executed. I mean, here, I'm using a constant string, but you could use any kind of rule to compute the string based on how the file has changed.

So I'm not quite sure how you expect the file to have changed. Could be an iPart, for example, or whatever, I guess. I don't know.

AUDIENCE: I think he's talking about like if you do copy design or something like that. So if you're involved in copy design, you get all new filenames.

JON BALGLEY: So the question is if you use copy design, there's both Vault design and there's iLogic copy design. I think they both have the same issue. So, there's no good answer to that, and you have to be aware of it and change the filenames. Yeah, Dave, comment?

DAVE: Yes. In general, unless there's a need for it, you should write the rule referring to the occurrence name, and that occurrence name can be locked down so that if the filename's changed, the occurrence names don't. The rule refers to the occurrence names, so the rules would continue to work. So unless you have a good reason for it, refer to the occurrence name when you write the rule rather than the filename.

JON BALGLEY: Good point. Pros and cons of the example here, right?

DAVE: So, in general, try to [INAUDIBLE] the occurrence name, unless you're forced, for some reason, to refer to the part. Then, it gives you sort of a relative way, right?

AUDIENCE: A workaround that I have is on a situation like this, we would just call all the parts the job number dash. So, then, I write a script that runs at the very beginning called prefix. It looks at the assembly file, extracts that, and applies it to the [INAUDIBLE].

JON BALGLEY: Right, so you can do that kind of thing. Great, thank you. I'm going to-- yeah, go ahead.

AUDIENCE: I'm sorry. You were talking about the level of design. Now, what about if I have-- can I also switch between different levels of design?

JON BALGLEY: Can you switch between different--

AUDIENCE: Level of design.

JON BALGLEY: Different level of detail?

AUDIENCE: Yes.

JON BALGLEY: Yeah, level of detail. Yeah. Yes, says Dave.

DAVE: With a straight reference to the Inventor method [INAUDIBLE].

AUDIENCE: Only with the [INAUDIBLE].

DAVE: We don't have a snippet for it, I don't believe.

JON BALGLEY: No, I don't think so.

DAVE: There's no snippet for it. There's no reason why you can't just call it the direct [INAUDIBLE]. It's fair game, right? The snippets cover the [INAUDIBLE].

[INTERPOSING VOICES]

DAVE: That's right.

AUDIENCE: [INAUDIBLE]

JON BALGLEY: So the question was can I switch level of details? And the answer was, yes, you can use the Inventor API to do so. That's the next topic for the second half of today, is using the Inventor API. So, a few other things beyond the basics. So, let's see.

One thing that I might want to do in this kind of a custom cabinet scenario is have some kind of order ID, right? You're making new orders every day, so you probably need a new number. Well, suppose I want the different parts in here to contain a property that shows that value. Well, I could do the same kind of thing. Use my top-down data flow thing, make sure they all have a parameter called order ID. But sometimes, that might be a pain in the neck.

What I'd really rather do is just say, you know, hey, all parts in this assembly, wake up. I've got a new order ID here. Do whatever you need to do to it. Sounds good. So if I change this, just to show you how it works. 999, return. And then if I look at the iProperties of the door, it's going to have a little comment that says, this is for order number 999. Yeah, that's what it's going to do.

So I could have done that the same way they did all the other dimensions, but I'm going to do it a little differently in this case. So I'm going to have a little rule here. A little rule that does a lot of stuff. First of all, we're going to use a feature called shared variables. So shared variables is a feature of iLogic that allows you to share data between multiple files in the same session. Lets you share data between multiple files in the same session.

So you can create a shared variable just by doing this-- picking whatever name you want and assigning a value to it. That creates the shared variable. So in this case, the shared variable happens to have the same name as this parameter, and that's OK. But they don't have to have the same name. It can be any name that you want. And then any other file in the session can refer to this shared variable.

All right, so we set up that shared variable. And then, here's where I'm going to use some combination of the Inventor API and some advanced iLogic stuff to do something kind of cool. So first, we're going to get the current document. This is the top level assembly. Then, I'm going to use the Inventor API to get all reference documents. And all is a recursive thing, so it goes all the way through the whole hierarchy.

And then I'm going to go through-- I'm going to have a loop that goes through all of those referenced documents, all the subdocuments. And what I'm going to do is for each of those, I'm going to try to get the rule named processOrderId. All right, so I'm using this advanced iLogic thing called getRule that will return either a rule object, if it has one, has such a rule, or nothing if there is no such rule. So if it's not nothing, then I'm going to use this again, advanced logic thing called runRuleDirect. It'll run the rule. And if it was nothing, then it just does nothing.

So what's this going to do is when this rule is triggered in the normal way, it assigns this shared variable and then says, go through the whole hierarchy of files and see if there is such a rule called processOrderId and run it. Well, that's good. So let's look at this door panel, go to the door panel. And the door panel actually has such a rule, has a rule called processOrderId.

And if I look at that, it's just going to do something fairly simple. It's just going to set the-- well, I guess it's going to access the shared variable. It's going to first carefully check to see if it exists. And then, if it does exist, that's the value it's going to use. If it doesn't exist, it's going to use the string, Not available. And then it's going to concatenate that to this string and then assign it to the comments high property. So it's just doing whatever thing it wants to do.

So the parent just says, hey, all children in my assembly, you go off and process the order ID however you want to do it, and I don't really care what you do about it. And if you don't care about it, then you don't have a rule by that name, and it just goes off and it happily ignores you. So this is an example of using a shared variable in place of a parameter to communicate between files within the same session. Shared variables are not saved anywhere. They're not saved anywhere. They're just for the duration of the session.

You can also use try-catch. I use this sharedVariable.exists to find out if it exists, but you can also use a try-catch. You can try to get it. If it doesn't exist, it will get an error. You can use a catch to provide an alternative. Kind of cool. Kind of cool. Well, that seems like a kind of a useful thing. Don't you think that's kind of a useful thing? Yeah?

So maybe I have other designs, other models, that want to do this same kind of thing. Maybe I make sheet metal desks and sheet metal other things that have similar forms. So what I could do is-- I'm going to go back to the cabinet here-- take the code from that broadcast rule, and I can use it-- oh, I don't have external. Sorry, different thing here. Good. Well, I'll go through some more workflow.

I can put the code into a external rule. Kind of running short on time here. Just trying to decide whether I should dive into that or go through some of the other stuff. Yeah, I guess we'll dive into it. All right. So, to do that, to use an external rule-- first of all, they normally show up here, because you've normally got them pre-set up.

To set up the external rules, you have to tell iLogic what folder the rules live in. Each external rule lives in its own file, and those files live in folders. And so under the Tools menu ribbon, in this little kind of dropdown area here, the iLogic configuration dialog is hidden. So you can go there, and you can set the iLogic rule directories there. So let's see. I'm going to add this here. Going to go to c colon temp. Sorry, Steve. iLogic class, cabinet, external rules back up. Yeah, that sounds good.

So, there we go. All right, so there are my external rules here. That is just a folder. So it lives here in this folder. And these are just ordinary text files. I think I can open with-- well, you can open them with Notepad. They're just ordinary text files. You just open them up. You can see everything in there. Or you can, of course, edit them in iLogic, right?

So if I double-click on this, you can see I've got the exact as I had there earlier, and it's OK. Now, the thing about external rules is that because they're not tightly associated with a specific Inventor document, you can't trigger them automatically by parameters. So there's no blue parameter names in here. External rules have to be run explicitly by something. And so that's what I've got, going back to my other rules here. I've got version 1.5.

And so what I do here is I set the shared variable, and then I just run this external rule, run the external rule. And so that will do the same thing, in this particular case, because the code is the same. But the nice thing is that I can use the code from that external rule in some other design and do the same thing. So that's a simple case of using an external rule. The external rule is available to all designs, and it's not tightly locked down to a particular file. All right.

So, who's feeling smarter, a little smarter? A little smarter? There you go. Got a brain for you. Anybody else need a brain? Yeah. Two brains are always better than one. Who else needs a brain? All right, well, had an interception there. OK. All right. Yeah.

So the second half is using iLogic in a medium way. And what I want to do here is, first of all, get my notes set up here. Oh, stretch, yeah. That was the stretch. What I'm going to do for a medium application is I'm going to create a drawing-- a little tool that lets me-- I've got, somewhere in here, some data files, these little CSV files, that just contain some snippets of data.

Let's pretend that it's a common thing that I want to insert those tables onto my drawings, and only those tables. And I don't want to have to browse for them. And I want to make sure that I always get the exact tables that are available. So Inventor has a insert. You can do this from a command here. If you pick a file, it'll happily do that, but you have to browse for it. And maybe you can get the wrong one or something. So I want to have a special command that does that. Save this ASD.

So the first thing is I probably am going to need a-- oops, where's my-- manager parameters. I'm probably going to need a parameter that says what kind of table do I want to insert. I'm going to change this to all. So I'm going to create a new parameter. Did you see I have three of these-- contacts, contributors, locations? So I'm going to call this table type and give it a value of locations. So now I've got that there.

But probably, I should have the ability to choose from several. I can use the multivalue feature. So I can say make it multivalue. Some of you are nodding, yeah, and so I can make a couple of other options here. Contacts and, what it was, contributors. So add. OK. Now I've got a little dropdown list here. So the way I want it to work is I'm going to make a little form that-- not a rule. I want a form. Or maybe I'll make a rule.

I'm going to eventually need a rule that will insert a table, right? Insert table. And let's just give it a dummy thing for now. Anybody notice anything funny going on here? Save. Close. All right, so we're going to need a form. And so this will be a very simple form. It's a very simple application. It's a medium application. I can put the table type on the form, and I can put the rule on the form.

And if I change the names, I could change the names to be a little more friendly. But pretty quickly, I've got a little thing here that lets me pick from those three things. And I can also kind of insert a table, and it will run that rule. How do we actually insert a table? Let's see here. So I want to change this from being just a dumb message box thing here to doing something with inserting a custom table. Sorry. I'm not Steve.

So if I go to the snippets here, I'm going to find that there's nothing about tables in the snippets. iLogic is not going to give me any help here if I go to the drawing things here. Even if I go to the advanced drawing thing, there's nothing about tables in here. But there is something about drawing sheets. And so what we're going to look at here is how to use the Inventor API in a seamless fashion from within iLogic rules.

So here, I've got a snippet. That gets me started. That gives me the Inventor API object for a sheet. I can say, let's assign that to a variable. All right, well, that seems like a start. Probably tables have something to do with sheets, right? So probably, I'm going to need to create a table, also. So I'll call it my table, and I can do something with the sheet. Now, watch this. This is something new in 2018.2. I'm using 2019 here, but this is the feature of 2018.2, which is going to be announced in a few minutes. So if I press dot-- yeah.

[APPLAUSE]

Yeah. So now you can browse through the Inventor API, the iLogic API, and even though the .NET API. And if you're writing your own class libraries, it will go through those, too. So it's very convenient to use here. So now you can just look through here and say, well, I don't know, but let's look at custom tables. That sounds good.

Well, what do I have to do with custom tables to make it work? Well, press dot. Oh, look at that, add. That sounds good. Oh, look at that. Add CSV table. That sounds even better. All right, so let's do that. And you can type open parenthesis, and you can see it automatically types at the close parenthesis for you, but you can type over it. And it gives you all the argument names. It gives you some information about the specific argument.

So here we are. So CSV filename. I'll get that in a minute. Let's put in a dummy variable for now. If I type comma, and it's going to highlight the second argument. Oh, placement point. Well, it's going to be a point 2D thing. I don't know how do that quite yet, so I'm going to put in another dummy variable. Title. Oh, I can make the title be the table type parameter, right, so it gives me the same name. Comma.

Use first row for headers as Boolean. Yeah, that sounds good. Let's make that be true. All right, so that's there. That's pretty good. Now I've just got these two dummy variables to fill in. All right. How are we doing time-wise? So I need a dim filename equals. I don't know. What do I want to put in there? Well, I can just go over here and grab this whole thing, for a start, and put that-- lost it. Come back.

Control-A, Control-C, come back. Go to the right place, Jon. There we go. Control-V. There we go. Slash locations.csv. That seems like a good start, at least for a test. And then we need the PT, the point, right? So when you're using the Inventor API, you're going to see a lot of these geometric objects that don't actually appear in the model. And this is one thing that you need to know about using the Inventor API, which is using the Inventor API is a critical part of using iLogic beyond the basics. So I'm comfortable talking about it that way.

PT equals-- and to get these kind of geometric things, you just have to know this particular thing. You get those by this application dot transient geometry. So this object here, this application dot transient geometry is your source for all of those geometric objects. And so you can get them by saying create and then create the right kind of thing, point 2D. Sorry, question? Yeah.

And then, if you type open parenthesis, then it tells you, oh it needs an x-coordinate and a y-coordinate. What coordinate should I use? Well, maybe I'll put it in the middle of the sheet. So I can say sheet.width divided by two comma sheet.height-- look how nice that is to type that-- over two. And then that's my point. Save and run.