설명
주요 학습
- Learn about advanced troubleshooting techniques using the iLogic editor.
- Better understand how to find your way around the Inventor API.
- Explore error-handling techniques.
발표자
CURTIS WAGUESPACK: Hello, and welcome to "iLogic-- 25 Tips and Tricks to Boost the Octane in Your Inventor Automation." So my name is Curtis Waguespack. That's pronounced pretty much like it's spelled if you take the U out. It's Wag-es-pack Or take the E out and it's Wag-us-pack. Those two letters trip people up, but it's Curtis Waguespack.
So I've used AutoCAD, SolidWorks, and Inventor to design a variety of things over the years. This is a hodgepodge of those things. I know many of you that are watching this probably come from similar backgrounds-- have used different softwares, designing different things, and found your way to iLogic, Automation, and Inventor.
Currently I work as an automation solution for Team D3, where I help professionals like yourself automate their designs. I also teach iLogic classes using now the CAD LIVE platform, which is a Zoom meeting with a virtual machine. So you can just show up and use the virtual machine with all the files loaded and that kind of thing. It works really well. So I teach those iLogic classes about once a quarter or as the demand requires.
So let's talk about you, the intended audience. So some of these tips are geared towards new users and some are towards intermediate users and some are maybe towards more advanced users. What I've tried to do is spread it throughout that experience range. And I think even if some of this is a little bit new to you, it's still worth knowing about so that as you progress with iLogic, you can know that these possibilities are there and just come back and revisit this recording, go through the materials of this class, and find that tip that you remember seeing but weren't quite sure what it was talking about at the time.
So with that in mind, let's jump into it. We've got four main objectives. The first one is just tips and techniques using the iLogic editor. So the first one is multi-line typing. So this is a quick tip that involves holding the Control key down. So what we can do is come in and hold the Control key as we click different places in our rule, as you're seeing here, and it'll put a blinking cursor at all of those places. And then we can just delete and type and change multiple lines all in one place.
So this was a tip that a colleague of mine, Scott Hallmark, accidentally discovered a few years ago. Autodesk had put it in. There was really no documentation on it. And so Scott accidentally did this, and then he stopped to discover it. So thanks to Scott for sharing that with me and sharing that with all of us.
So we can also copy and paste doing the same thing. So here's an example of what we're doing now. We're going to copy this number. And then we're going to select multiple places again, holding the Control key. And then once we have that multi-selection done, we can just-- in this case, we're deleting. And then we'll just paste right in there using the keyboard to do that.
So we can do all of those things-- select, delete, all that kind of thing-- using this Control Select tip here. So here I'm double clicking on those heights. That's maybe not real clear from the video.
But that brings us to a bonus tip there. And that is that when we're in our iLogic editor, we can just double click on a string, and it will select the whole thing for us. That's something when I'm working with people, I see people trying to backspace or select what their cursor. And I think it's just something worth mentioning that you can just double click on that and it'll select the whole thing. It's really useful when we've got those long string names for part numbers and that kind of thing.
So that was tip number one-- multi-line typing. Let's go on to tip number two. This is Booleans and the Not operator. So Boolean, just as a review, is a binary variable that has two possibilities-- true and false. And within Inventor, we can think of a user parameter. That's probably what we work with the most. So our user parameters, if they are a true-false parameter, are Boolean.
So what that means is when we're working with one of these parameters, we often do something like this. We say if this parameter returns true or is true, then we might set some components active or not active with our true-false here. And then we'll have to put a else in to handle the opposite case. So when isLeftHand is false, we would want to change these components to be active or not active in the opposite state.
But what we can actually do is use this IsActive and the true-false parameter and just set them across the equals sign as shown. And because they're both Booleans, we can do that. And then for the case where we want the opposite thing to happen, we would just use the Not operator.
So I see a lot of people working through if-then statements like this where we're basically just creating duplicate code to deal with that opposite case. And we can be a little more efficient just knowing that we can use the Not operator and these Boolean parameters to do this.
So if you're ever unsure about whether you can do that with whatever you're working with, remember that you can hover over, in this case, the IsActive function, and it's going to tell you what it's going to return. In this case, it's showing As Boolean, so we know that it's going to be looking for a true or false and that we can do this.
So here's another example of doing this, where maybe we started off thinking about this as an if-then, and then we realized, really, we can take this whole statement, and it's going to either return true or false. So rather than building out our if-then conditional again, we can just set that opposite of equals sign. And again, we can use the Not operator to return the opposite case.
So lots of opportunities to optimize our code there using Booleans and the Not operator. That was tip number two. Let's move on to tip number three.
So use loops when possible. So here's an example where we have 77 cap screws. And we did what we were just talking about. We've used a Boolean and just set it opposite of our IsActive across the equals sign. And that made it very efficient, but we still had a lot of these components. And so instead of having 77 lines just doing the same thing, we can put this into a loop. And we can optimize this using a variable of I.
And what we're doing here is we're just saying set I to one, and then set I to two. And we're going to loop through this 77 different times. And of course, we're just going to concatenate I and our cap screw underscore for the name. And by doing this, we can have three lines of code instead of 77. So maybe a much more efficient way to do it, but not the way we might think about doing things if we're brand new to iLogic or if we're just starting off with iLogic.
So here's an example of using a loop for each loop to do something very similar. So here we have 26 lines of code, and we're going to get that down to seven lines of code using this for each loop. So we're just going through each component in the assembly. We're checking the first three characters to see if they match the suffix-- the prefix, I should say, that we're expecting to see.
And if it does, then we're going to do what we've been talking about. We just use that Not operator to set the IsActive status. So again, 26 lines down to seven lines of code. That's pretty good. But the best part of this is, what happens if we wanted to add another component to our assembly? Let's say it was a left hand and a right hand latch, so we had both of those in there. We would need to add four more lines of code. We would have to add one here and here and here and here.
And if we're using this loop, we don't have to do anything. As long as it has this prefix or these prefixes, we add the components to our model, and then the code just picks it up. So more efficient as far as keeping our code up to date and that kind of thing as well.
So the bonus tip here is to just look for those opportunities to name things and prefix and suffix them so that we can pick that up with loops later on. So keep those naming strategies in mind as you're building out your model. And then again, it'll be easier to put these loops in place as you go.
So if you're brand new to loops-- and there's a lot of different kinds of loops-- I've created some examples that you can download in these supplemental files here that you can look through that'll help you understand some of the different options. But you could also just search for vb.net-- vb.net Loops or vb.net For Each, or something like that. You'll get examples from the Microsoft help and that kind of thing.
But you can also visit this site called Dot Net Perls. In fact, if you do this search, it's probably one of the sites that's going to pop up pretty quickly. Again, it has a lot of great examples on there that help you understand how to set these up for your iLogic rules.
So that was Use Loops When Possible-- tip number three. Let's have a look at tip number four. So tip number four is called Tangled up in blue (parameters). So we have two ways of writing this line, and we're showing both of those right here. And one of them has height in blue and one of them has it formatted with this parameter parentheses and quote signs. And they behave differently, and that's what we want to understand.
So to help you remember this, think of this as if Old Blue the code hound is watching these blue parameters. And he's looking to see if that parameter changes. And if that parameter changes, he springs to action, and he makes your rule run. I don't know how he makes your rule run. Dogs are amazing.
So here he is. He's watching this blue parameter, and he's focused on it just like the well-trained dog he is. And he's waiting. Is it going to change? Is it going to change? And if it changes, he makes the rule run. What we can do, though, is we can type Parameter, parentheses, and the quote signs, and it will change the way this behaves. And Old Blue, he'll just go to sleep, and he's no longer watching our rule. And therefore, the rule won't run when this parameter changes.
So here's an example of this. Here we have the height parameter set in blue. And so if I were to go over here in this form and I were to change this height using the slider or typing in a value here, this rule would run automatically.
Here's an example when it's not going to run automatically. So again, we formatted this parameter to look like this. And now if we change this, nothing's going to happen. So what we would do is we would put this rule in our form as a button. So we could change the value and then click the button to make that change. And so that's a strategy that some people prefer. They prefer their rules not to run automatically, and so they might format it like this and then just build their form out to have a button that runs the rule explicitly.
Here's the situation that pops up a lot. So in this scenario, we have a rule, and it gets triggered because height changes. And so then when rule one runs, because of the change to the parameter called height, then it calculates the value of something called valve length. And then valve length causes rule two to run. And then rule two makes some changes to these shim diameter parameters. And then suddenly, we get this situation where the shim diameter parameters are running these other rules and things just start cycling and running too much.
And you'll see that. You'll see your model start to flicker. And it takes forever to update and all that kind of thing. And then you're like this. You're like, oh my goodness. This was running so smoothly, and now my configured assembly is grinding to a halt here. So that's because we have too many blue parameters in there.
So there's a few strategies that people use to deal with this. A couple of them is to go into the rule and go to the Options tab. And then we can click the Suppressed button, and that will prevent the rule from running when those blue parameters change. So that's one way to do it. The other way is to use this Don't Run Automatically checkbox, and it'll do much the same thing.
So if you use either of these, you'll have to run your rules explicitly again, either through a button or something like that. What I prefer to do, though, is have a little more granular control over my rules and those blue parameters. And I like to use the blue parameters strategically as triggers. So here's an example where I have everything formatted to where it's wrapped in the parameter formatting syntax. And then I'll just add a couple little throwaway variables up here.
And we're not doing anything with this variable called oTrigger. It's really just watching this for a change. So if it changes, this rule is going to run. So remember Old Blue? He's going to spring to action and make this rule run. And so by doing this, I can still use these blue parameters as triggers, but I have very specific control, and I can easily tell what is going to cause this rule to run.
So in this example, if I changed this type parameter in the form, or again, if I use the height slider or something like that, I can expect that this rule will run. There's a couple other parameters down here-- one called count, and one called spacing. And I can be assured that if we change those with another rule or even just go into the parameters dialog and change them, they're not going to run. They're not going to make this rule run because of the way they're formatted here.
So I keep saying blue parameters. Of course, this is all subjective to your coloring options. So if we go into our rule editor and go to the Options tab, there's this syntax coloring over here. And if you have it in the classic coloring, it's going to be blue, just like I'm showing most of my slides here.
If you're using Dark Mode or maybe any of these other color schemes, the coloring might be a little different. In fact, Dark Mode, you can see that our conditional statement-- they're blue as well. It's a different color blue. Just keep that in mind. When I say blue, it depends on what color scheme you're using. For the most part, though, it is blue in all of these.
OK, there's one other thing to know about the options in here, and that is this Fire Dependent Rules Immediately option. And the way this works is if you have this deselected or unselected, when a blue parameter triggers a rule to run, it'll wait for the whole world-- whole-- let me try again-- whole rule to run. And then that dependent rule will run then
If we have this option selected, what would happen is the rule would run when it gets to that line, that triggers the other rule. It'll step into that rule and make that rule run. So let's say we had a blue trigger parameter right here on line four. This rule would run down to line four, and then it would jump into that other rule and run it. And so oftentimes this is maybe advantageous when we're working with part files down in an assembly. So we'll step down into that part and change that parameter.
And so if we need our logic to change that and then be dependent on that one changing and so on, we might want to have this option selected. The main thing here, though, is to just know that that's an option and that it's a possibility. I typically leave this unchecked and use the throwaway variable triggers is my strategy. But I see people do it all different kinds of ways.
OK, so that was tip number four-- Tangled up in blue (parameters). Let's look at tip number five. This is a quick one. It's called Name Those Entities. So in Inventor 2019, they introduced this. And what it is is they gave us the ability to name geometry in our models-- in our part models, I should say. When we do this, we get this Entities tab in our iLogic browser, and then all of the named entities show up here.
So as an example here, we've got this little model. We want to name this space. So we would select it, then we would right click on it. And when we do, we would get this menu. And so we could choose Assign Entity Name. And then when we choose that, this little dialog would pop up, and we would enter a name-- in this case, Top Face.
So the result would be, again, our Entities tab would show up in our iLogic browser, and our name would be listed under there. So what we just talked about that? You select the geometry you want, and then you right click on it and choose that option to name entities.
What can we name? We can name faces, edges and vertices or points. So you can see, there's a little point right at the edge of this rounded corner. If I wanted to name that for some reason, I could do that. The icons in here show the differences. So the face shows a face selected, the edge shows an edge selected, and so on.
So why do we use this? We use this in order to create assembly constraints with iLogic and to create drawing dimensions with iLogic. So we're going to cover that in the next two tips. And then the other thing we can do with this is we can use these named entities in our iLogic rules with some API calls. So that's handy as well.
OK, so that was a quick one. We're going to build on that in our next two tips. That was Name Those Entities-- tip number five. Tip number six is Extract to be Exact. And we're talking about models here. So let's jump into that. So within our model, we always have our model tree over here. We're familiar with that. But within our iLogic rule, we have the same thing. So we can use that to extract some code.
So in this case, we have a hole here. And we'll just right click on that hole, and we'll get this capture current state. And so when we choose that, it'll bring in all this code. And it'll give us everything it knows or everything we can pull out of that. We may not want to do anything with all of that. We may just discard most of it. But it will give us all of that code so we can just build that into our rule.
There's another way to do it, though. We can choose the hole, then go up here to parameters, find the parameter that we want to work with, right click on it, and then again, we get this Capture Current State pop up. And when we click that again, we get the information that it knows about that. It gives its current state.
And we can get rid of the current state and just use this and set it to something else and work it into our code. Now, we did that two different ways, and we got two different results. So when we captured current state from the whole, we got everything about the whole.
When we went up here to the parameter, we got just the parameter. And of course, it came in a little different on the formatting as well. Even though they're the same parameter, this one came in that blue trigger state and Old Blue showed up. So if we did that, it's going to show up and be a trigger. We need to understand that using it like this is going to make our rule run should this parameter change.
OK, we can also extract a parameter from a subcomponent. So here we're down in a subassembly and looking at the user parameters, and we want to get this size parameter. So we right click on it, choose capture current state, and then it pulls out that line and again gives us the syntax exactly as we need it. We don't have to go look in our snippets folder or try to remember the syntax or anything like that. Just pull it right out of the model.
So let's take a look at this in the context of how we would create the code or extract the code to assemble a model. So here, we've got a little basic LEGO model. We've put it together, and we added constraints here, and we see all of that right there. So the first thing we'll do-- remembering our tip number five, we would open one of those LEGO parts. We go to the top face, right click, and we would get that Assign Entity Name, right click Choice.
We do that-- we would just define the name for the top face, and then we'd just repeat the same thing for the bottom face, save our model, and then we would return back to our assembly. And then here at the assembly level, we would start a rule, and we would go in here. And in this case, we're going to work with LEGO one first. Right click. We'll get this menu. And in this case, we'll choose Capture Current State Components Add. So this will extract the code to add this component to our assembly.
You notice it also pulls in the color or the appearance line as well, since we had applied a color at the assembly level. So that's pretty nice in and of itself. So then we would go and do the same thing for LEGO two. Right click, capture current state. But we're going to use this Components and Constraints Add. So it added the same lines for LEGO two, but it also added these three lines for the constraints for what's involved with LEGO twos constraints.
So that's everything we need to recreate our assembly. So we could put this code in a blank template and run that. So you'll notice, though, on that mate constraint that it pulled in those names that we created by assigning those entity names.
So let's take a quick look at that in action. So here we are. We finished our rule. We'll close that. Now here's our whole thing assembled. And we're going to just delete these two components and start from scratch. So imagine if we had a blank template. That's what we're doing here. We'll run our rule, and it's going to place those two components and constrain them in place. You'll see that it created those three mate constraints right there.
Now, what if we just wanted to delete one of these constraints and start from there? We can do that as well. Run that rule. Again, it puts that LEGO back in and puts those three constraints in. Here, I'll delete the three constraints. Now we'll work with the unconstrained components, and it'll just put them all together. So really quick, easy way to build code or to create code that will build our assemblies. We just build the assemblies first using those assigned entity names, and then we've got the code that we're going to extract out of it.
OK, one other quick tip here-- bonus tip-- is that if we don't want to supply the names-- maybe we don't want to have to worry about, oh, our assembly might already have something called mate one or mate two, and that could cause an error. We can just pass in a null value of two quotes together. And then Inventor will just supply the mate names for us. It'll just index it just like it does when we create a constraint manually. Sometimes we want that to happen. Sometimes we want to actually specify the names ourselves. Just know that we can do that.
OK, quick review on that process. Again, name the faces in the part model. Build your assembly like you normally would, and then go in and capture the current state to pull out that code to add the components and add the constraints. And again, there's an example out there for you in the download files.
So let's take a quick look at extracting the make path for a deeply nested component. So here we've got a part file that's way down in this structure. And you'll note that if I use my model tree in the rule, I can extract that, and it'll give me the whole assembly structure down to that in these curly brackets. So what it does is it creates an array that we call make path to get down to there. So that's just something to know about as well. You can pull that out, use that in other parts of your code as well.
So that was Extract to be Exact in the models-- tip number six. Let's look at this in the drawings as well. So for drawings, this was new to Inventor 2021. And what we can do is we can extract the code to create our dimensions and our drawings with iLogic. So to do this, we just select an edge in the drawing, and then we right click, and we choose iLogic Capture Current State.
So again, right click, and it'll pull up this menu. You can choose that. When we do that, we get this little code clipboard. And so it puts some code in there about the sheet and the view, because we've got to have those things in place, and then it gives us the name. So here's that top face again. Remember, we named that in our part model. So it just pulls that out and says, yeah, that edge is part of Top Face. And then we can do the same thing for the bottom face and so on.
So then we go into our iLogic editor, and we just simply right click and paste, and everything that was on the clipboard will come into our rule. From there, we can use our snippets. We would go to the linear dimension snippet, and we would just double click that and pull that into our rule. And then we'd probably do a little cleanup there.
But the main thing that we're showing here is that we're going to use these named entities, the Bottom Base and Top Base. And we're just going to plug those in to this linear dimension snippet, and then that's telling it to dimension from one edge to the other edge.
So here's a quick rundown of that. We're going to again, right click on that face, choose iLogic Capture Current State, brings up the clipboard. And then we're going to go up and try to get the other one. I had a little trouble just because of the screen capture that was going on there. There we go. It finally popped up the tooltip. I just click on that, and then you see that bring that into the clipboard here. So then we can click OK. And then we go into our rule here, right click, Add a Rule, and then we just paste it into our rule.
There we go. Paste it into our rule, and then go down to our snippets. Find the Add Linear snippet. Double click that. Again, a little clean up-- the snippet comes in with just some default boilerplate code. We don't need that. Our clipboard gave us that. And then we're just going to say dimension from this bottom face. Put a comma in there that tells it the next item to dimension two. So it's bottom face to top face.
Make a quick change here on where the text on the dimension is going to land in relation to the view. And then we click Save and Run to create that dimension. And there it is. We'll delete it. Run our rule again just to see it pop it on there. There we go. So again, you can see that example in our examples. So if you want to refer to that--
So that was Extract to be Exact with drawings. Again, use that to your advantage. Pull that out there. Don't try to write that all from scratch. Extract it out of your model.
So related to that is tip number eight-- Explore iLogic Dimensioning. So you notice we just did that with seven lines of code. That's not much-- seven lines of code to create that dimension. You may have tried to do this with the API in the past before we had the option to do it with iLogic. And I pulled a quick example of that, and it was 62 lines of code to do pretty much the exact same thing we did. But we were actually even, in this example, using work points as some helper geometry, trying to make it easier for ourselves.
So if we were trying to work with the native drawing curves and their proxies, it's even more daunting. And so a lot of people tried this, and they said, oh, that's just not worth it. It's just too much work, and it's not reliable enough, or whatever. And so they just said, I'm not going to do dimensioning with iLogic. I'll just copy drawings, and we'll replace models and replace model references, and we'll just work it out that way.
And so as a result, in 2021, when they released this, I think a lot of people missed it. And so that's what this tip is about, is to say, take another look at this. So oftentimes, I show this to people and they say, wait a second, when did this happen, and how did I miss that? So to answer that question, it's two words. Now, bear with me on this. It's two words-- toilet paper. So to understand that explanation, let's go back in our AU time machine to March 30th of 2020. So we'll hop in our time machine and look at what was going on then.
So Autodesk released Inventor 2021 that had this new iLogic dimensioning in it, and they did that on the 30th. March 15, we had a thing called the global pandemic. So a lot of us were a little distracted by that. And then I asked Google, I said, hey, when did people start hoarding toilet paper? And that happened kind of in between, but right at the same time this was being released. So I think you can see the connection between all this here and why some of us miss that.
Now, maybe not. Maybe it doesn't have anything to toilet paper. But the point here is a lot of us overlook this kind of important release of tools, partially because of what was going on at the time. A lot of us overlooked this because we tried it with API and we didn't quite make the distinction that they gave us an easier way to do this now. So the tip here is just to go through these snippets and kind of get familiar with these and understand it's much easier getting seven lines of code to create that linear dimension.
So again, I've provided some examples here. You can follow those examples and experiment with them with my little simple files versus your actual production work and figure out how to work it into what you do day to day. OK, so that was tip number eight.
We took a little detour back to 2020. We're back to 2024 now. Let's go look at tip number 9.
So this is a quick one called Right-click, Format Rule. So with this rule and with this tip, we just want to look at what happens when our indenting gets a little sloppy.
Oftentimes we're copying and pasting and that kind of thing and we just-- we can backspace or we can use-- there's an indent button in the rule editor. We can do all of that. But it's much faster just to right-click in white space there and choose Format Rule. And you can see that it just formats our entire rule based on VB.net formatting and it's quick and easy. So I see people sometimes backspacing and trying to fix things manually. This is a much more reliable and faster way to do it. So again, right-click in any white space in your rule, choose Format Rule.
There's one little gotcha there. And you notice in this rule up here, I've got an Else If with a space and one with-- they all run together. And if I right-click and choose Format Rule, we would expect this to happen. But, in fact, what we get is this.
These two lines don't indent like we expect. And it's because of the space right there between Else and If. It's just the way it works.
There technically is a little bit of a difference between these two. As far as our code compiling and working, they do the exact same thing. As far as it formatting, it doesn't format the same. So I tend to just not use Else space If, I just use Else If as all one word and don't have to worry about that. But just know that that's the reason things don't indent when you see that happen. So that was a quick one. That was tip number 9, right-click, Format Rule.
Let's look at tip number 10, passing information to another rule. So in this tip, there are three ways to pass things from one rule to another. So let's say we want to pass these three things from Rule001 to Rule002.
The three ways to do this would be through parameters and properties. We should all be familiar with this if we use iLogic a little bit. That's our main way of doing it. So we just are basically writing things to the part file. So these are entities of our document or our file. So we just write it to that file, or to the properties or parameters of the file, and then our other rule just looks them up and pulls from those properties or parameters.
So that's the first one. That's the most common one. But if that's the only thing we ever use, we can end up with all of these extra properties and parameters that we don't want. We just needed them temporarily while running the rule and it kind of clutters up our properties and parameters.
So the other way we can do this is using some iLogic functions that are called shared variables. And so if we look at our snippets, we can find all of the snippets for our shared variables here. They're pretty straightforward. Nobody really has trouble figuring these out. It's basically we create a shared variable, we set the value, and then, Rule002, we get the value from that same shared variable. Again, really intuitive, works well.
The thing we want to know about this is it's just setting in memory. So we're not writing to the file, we're just writing it to memory. And then when Rule002 comes along and tries to get that value, it pulls it from memory and it works really well.
The other thing to note is, when we close Inventor, that goes away. So it's just kind of while we're in that session. So again, that's really intuitive. Nobody has trouble figuring that out.
This is the one where people have trouble making the connection. So we have this option to run a rule with a value map. And this snippet up here, when you look at it, it would look something like this. And we're just telling-- this is the code that's in Rule001. And we run Rule002. And what we expect to happen is something, but nothing happens and nothing keeps happening. And I don't know what I'm doing wrong here, but we move on and we never figure out how to use this.
So part of the problem is Autodesk has arranged the snippets in kind of a, I guess, non-intuitive way. It's obscured by all this other stuff in the way. But really we need to use these two snippets together.
So our first rule, our setting rule, would be up here, Rule001, and we would do what we talked about earlier. In Rule002, we need to have this snippet and use this snippet so that these two things can work together.
So let's take a look. So here's Rule001. And we're going to use that snippet. It comes in like this by default.
But let's take a look at more of a real-world example. So here we've got three pieces of information, length, color, and rack number. We're giving it some values and we're putting all in this value map. And then we hand it to Rule002 using this line here.
So then in Rule002, we'd set it up using this rule argument snippet. And again, it comes in like this. But in practice, it would look something more like this.
So here we've set some local variables and set some default values to those. And then we're using the rule arguments function. And we're just checking to see if they exist. And if they do exist, then we're going to set these variables to the values that were in Rule001. And so information is handed from Rule001 to Rule002 and we pick it up right here. And in this case, all we're doing is showing it a message box just to show it as an example, so it would look something like this.
Pass the information down to Rule002. Oops. Pass information down to Rule002 and then it would get picked up down here. So it works well. It doesn't write to the file. It doesn't write to memory. It's more just of a transactional situation where we just pass something from one rule to the other.
So what happens if we run it just from Rule002? If we do that, it's just going to pick up the default values. This is not going to set these values because they won't exist if we didn't have Rule001 run on the front end of this. So it would just get the default values.
So these examples, again, are out there. You can look at that exact one. Use those for reference in the future. Generally when I point out to people that, hey, these two things go together, that's enough of a nudge for people to get the hang of this. But on our own, I think sometimes we just can't see through all this that's in the way. I don't know why they didn't put those together. There's also a link here to some reference information online for this one as well. So that was tip number 10.
Let's look at tip number 11. So this is adding structure to our code. So here we've got what we see oftentimes in our iLogic rules, and that's just sort of a script or unstructured code, so it just runs from top to bottom and does everything one after another.
What we can do, though, is build a little structure by using sub procedures. And it gives us the ability to make our code a little more modular, reuse those modules of code and that kind of thing. And so let's have a look at that.
So to build a sub procedure, we first have to wrap our main part of our code in this sub main and end sub. So we put those statements on the front and back end of those and then we take our sub procedure, we give it a name, and we do the same thing. We put an end sub at the bottom. And so that's how we build our sub and end sub for the most-- sketch it out, I should say.
And then what we want to know is that when we work with a sub procedure, what we do is we pass in information as shown. So here's my sub procedure name.
And then we're going to pass in these two pieces of information and we hand it down here. And so our sub procedure needs to have some parameters to catch that information. And so it's handed down from the main sub and then caught right here. So we have to define these parameters of the sub. And then we just use those pieces of information. In this case, we're assembling a message and so on.
So let's walk through this and see how it works. So the first thing we're doing here is we're getting a day of the week using the time and date string, just the system string. And then we do the same thing for the time.
So we get the day of the week and we get the time, and then we come down here to line 9 and we call our sub procedure. And we hand it these two pieces of information, DayOfTheWeek and CurrentTime. So it steps down here and drops off those two pieces of information down here. And then this chunk of code is just using it. So all we're doing is assembling a message here. And then, finally, we're showing that to the user in a message box.
And then we continue on. So we did all this right here and then we continue on to line 12. And then line 12 is just updating the current time, so it gets the current time again. And then we do the same thing. Rather than copy and paste in this code, we put it in a sub so we can reuse it. So that's what we're doing here. We're reusing it, doing the same thing, handing that information down to the sub. It uses it to create the message again and then pops up the message box.
OK, so why use sub procedures? Just what we showed there. We can reuse blocks of code without having to copy and paste them. That's probably the main reason to do it, right? It does help us make our code more maintainable and readable. We can do calculations and that kind of thing as well. So keep that in mind. I definitely encourage people to learn how to add a little structure using sub procedures.
Let's go on to tip 12. That's very-- it's going to be a very similar tip.
I'm using functions or function procedures instead of sub procedures. And so they are just like a sub. The big difference is when we hand information down to the function, we also hand information from the function back up to our main sub. So typically we're doing a little calculation or something down here and we just hand the result back up to the main sub.
So let's step through that. So the first thing we're doing here is we're getting the time. We're going to pop it up in a message box just to tell the user what the time is. And then we're getting a second time. And then we're going to take both of those times and hand them down to a function. We drop them off there. Again, we've got parameters set up down here in our function that we receive the information or catch the information. And then what we're doing on these two lines is just parsing this and turning this into a number so that we can do a little calculation.
So we've got our calculation going on here and we get the value of that calculation as a variable called Duration. And then we're making sure that Duration is a string and we're handing it back up to the main sub. So that gets captured in a variable called TimeDelta. And then that TimeDelta is just used to display this message box.
So, again, we gathered some information up here, passed it down to the function, and then we did a little calculation using that information and passed it back up top. Real common way to use a function and some information, do a calculation, and the result back up to the top.
So why use functions? Well, I just kind went through that. It's often about handing a result-- doing a calculation and handing the result back.
So comparing these three things, again, if we don't use subs or functions, we're just kind of creating a script that runs from top to bottom. If we're using sub procedures, we're creating these little blocks or modules that we hand information down and do something with. If we're using functions, we're handing something down and then passing a result back up to the top.
So those three structures compared. I've provided these little examples here, so you can have those for reference and kind of experiment with those as well. So that was tip number 12, using function procedures.
So let's go on to our second set of objectives. And this is about creating a better interface for our iLogic users. So the first one, tip number 13 here is external rules and global forms on the ribbon.
So I forget what release they gave this to us, but we can create something like this where we create some buttons and some-- on our ribbon and so then we can run our rules from a ribbon. So to set this up, the first thing we do is we create an icon-- whatever it is, some sort of picture. I was experimenting with Inventor 2025. The size and the proportions don't really matter. At some point, I think we had to keep it to 32 by 32 and 16 by 16 or something like that. I was using 500 by 500 and it worked fine.
So one thing we want to know is the Inventor will try to remove the background of your image. So basically it's going to remove the color white, is what we want to know there. So oftentimes, if we're using Dark Mode, you get a really awful-looking icon out of that. And even if we're using Light Mode, sometimes we see this kind of white halo around it.
So what I've found works best is just to go ahead and color your pictures based on the mode you're going to use. And instead of leaving it white, I just try to match the application canvas or whatever you want to call it for Light Mode even as well. So if we don't, things like this dog's collar, where there's a void in your icon-- or it'll make a void in your icon, I should say. It'll replace that white with something else. So that's what I've found best to do. And I've found it best just to go ahead and create two separate icons, one for Dark Mode and one for Light Mode.
So here's an example. We've created our two icons. And then, to get this to work, we want to name them a certain way and then place them right next to the rule that they go with. So here's my rule. It's a .txt file, but it could be an iLogic, idb, file or whatever that's called, the extension doesn't matter. We just need the name to be the same. And then we put this on the back end of it.
So in the end, it would look like this. Here's my rule name. And then we would just name it Dark.Large or Light.Large.PNG.
If we wanted to have a different icon for small and large, we could have four different icons. And then when we use the small buttons in Inventor, it would pick up that icon. Use the large buttons, it would pick up a different one. You don't have to do that. I often just do it like this and just have a large icon and use it for the small and large buttons both. But, as I said, it's kind of recommended to have a dark and light version of it.
So when we do this, the external rules folder will pick that up automatically and you'll see the icon show up here. But to get it into our ribbon, we need to go to Tools and Customize. We change this to iLogic or iLogic rules, and then we go over here and we set this to whatever ribbon tab we want to work with. In this case, I'm saying the Tools tab in the part environment. And then we would select our rules over here, use this little Chevron or arrows button to push them over here. We can reorder them.
And then the next thing is these checkboxes here. So let's just have a look at those. So if I don't want to use the large buttons, I would deselect that and it would come out here. There would be little-bitty icons. I've told it to go ahead and show the text. And it shows the text off to the side there.
If I want large icons with no text, I could set it up like that and it would look something like this. And to get the text, I can just hover over it. And you can see a little tooltip pop up here to tell me the name of the rule.
If I choose both, it'll look like this. Now, if I have long iLogic rule names, it kind of spreads out. It's maybe not ideal, but that's how it would come out. So again, I've provided you some examples using some rules and the icons here that you can just plug in and see how that works and use for reference to create your own.
So you can do the same thing for forms. I was talking about rules through all of that, but it's pretty much the exact same workflow. If you have global forms, go to Global Forms tab, right-click, choose Open Containing Folder. That'll show you where your global form files are.
They typically look like this. It's an XML file with a .state XML file. Also, again, just name your icon light or dark and large with PNG on it. Again, that will get picked up and then you can add that to your ribbon as well.
OK, so that was how we do that with the built-in. That was tip number 13. Let's take a look at tip number 14. And we're going to talk about doing the same thing with an add-in, but having a little more control over some of the things.
So last year, AU 2023, I taught a class called Bridging the Gap Between iLogic Automation and Inventor Add-Ins where I kind of walked you through this process, but I also provided a couple of templates to do this. And so you can go out there and download that, watch the video for that-- download the templates, I should say, and the other materials.
But when you do that, you can immediately spin up an add-in that will put these enterprise tabs in here. So I use Acme and Globex as examples, but you would change that in your add-in to be the name of your company or something like that so that you create your own custom tab there. And then it puts these buttons on here.
There were two templates. One was just a simple template that I talked about in the class, and the other one just builds on that. And it has these more advanced buttons that have fly outs and kind of button stacks. Really handy thing to know how to do is to be able to organize things like that.
The other thing to note about this is we have a little more control over the text. So I can wrap the text down into two lines here. And you can see, with our built-in options using tools and customize that we just talked about in the last tip, we can't really do that. It all spreads out if we have long iLogic rule names.
So give that a try. When you load these templates, you get these buttons. And they're wired up. They do something. And then that'll give you an example. So you can build your own buttons with your own rules wired up. Again, you can call your external rules or you can build tools within the add-in as well, but the code on that side.
So here's an example of the extended tooltips that we get with add-ins as well. So we can build out this, add images. We can actually add videos to these as well. So that's another advantage of doing this with tooltips versus the built-in way, through the tools and customize. So again, the AU class from last year, from 2023, shows that as well.
These are the names of those two templates. So again, watch that class and it'll show you how to use those. So that was tip number 14, again, how to add our external rule and global form buttons using the add-in.
OK, so tip number 15 is build better forms. So oftentimes I see something like this where there's a form that's just kind of thrown together with properties and parameters and there's really not a lot of organization to it and it's not real visual.
So here's an example, going the other way, with a lot of buttons and that kind of thing, some tabs to organize things. And so let's talk about how we set this up, maybe why we would set this up as well.
So let's start at the beginning. So how do we add buttons to run rules? So we just go over here in our Form Editor and go to Rules tab. And we can just click a rule and drag it over and that will create some buttons like this.
So another thing about this is we can change the form style. So the default style is very flat-looking. And so if we've added tabs, it's very difficult to see the different tabs and you can see the buttons are kind of flat. And, in this case, the icons aren't fitting on the buttons.
And so what we can do is we can choose the top level of our form in our Form Editor and then go down here to the Properties panel. And that will give us this visual style. So we can change that from the default to something like DevExpress style that will show that and make it look much better and make things look a little more separated and visually compelling.
So here's an example of that we're going to go into. The Rules tab over here, we're going to drag the Deluxe button-- or Deluxe rule over here to create a button. You can see it shows up with no image first. So we down to the Properties for that rule, go out, we select an icon, click Open.
And again, when it comes in, it kind of overruns the actual button. So we're going to go to the rule-- or the form, I should say, and we're going to change from the default style and we're going to pick another style. Don't really love that one. Let's change it to DevExpress style. There we go. I like that much better. So it makes the button pop out. The icon doesn't overrun. And, again, those tabs look much better.
There's some example files out there. You can go do this exact thing you just saw on screen and see how that works.
So another part of this is about how we organize our forms and build our design process into our form. So you're probably not designing pizzas with Inventor, but we're going to use this as an analogy.
So a lot of configured assemblies start like a pizza, right? And we build it by just writing a size and a type and then we go and we start adding options or we start configuring options.
So you can think of that when you build your forms, like how would we build a form to create a pizza? Well, we start with a tab group maybe, right? So add these tabs up here and start organizing things in that way. And what you will find is it will help you organize your design process.
And so let's get off this pizza one. We're not working with pizzas. So here we're designing some sort of industrial machinery and we're doing the same things. We're going to start by organizing our form to configure the size and type, then we're going to specify a motor, material, feed or whatever your options are.
And so when we do this, you'll find that your form suddenly starts to make a lot more sense to new users. So if you're onboarding-- this is one of the things I've seen in the past, onboarding became a lot easier because suddenly people could understand our configurators.
It helped them learn our machinery. So it sort of gamified our design process. So we hire somebody, take them out to the shop, show them the real thing in real life, bring them in, sit them down in front of a configurator, and say, play around with this. We may give them a spec sheet and say, give me one like this, and just lead them through it. But they learn it so much faster than about any other way that I've seen people on-board for designing specific product lines. So think about that and use these forms to bake in your design process.
So you can also use enabling parameters. So here's a thing I think people overlook sometimes as well. So the way this works-- so here, first of all, I've created a group. So I've dragged this Group tool up here and then I've put three parameters, Red, Green, and Blue in here.
And you can see what we're doing over here is we've got a color mixer. We're just using sliders to allow the user to create some custom colors. And we can control whether those are active or grayed out using this checkbox right here.
So if the machine or the assembly is not going to be painted, we don't want them setting a mixed color. It might mess things up in our configurator or whatever.
So we want to disable those controls. So the way we do that is we select the whole group in this case. We could do it for each one of these. But since we've got them in a group, we can do it all in one fell swoop. So we select this group, and then come down here to the properties, and then we just tell it to use this Painted parameter, this checkbox, as the enabling parameter.
So now when it's checked, we can set the colors. When it's not, they're grayed out. So this is, again, a really great tool to know about. I think it gets overlooked a lot.
So also use picture groups. So here's an example of a tank. And it has this little flange here. And there's a seam in this inlet. And so we want our hole to be either lined up or offset, depending on where that seam lands. And so oftentimes with a configurator of a large assembly like this, it's hard for the user to understand what they're changing. So what we can do is provide something like this, a picture built into our form that changes depending upon the value.
So let's have a look at how we would do this. So here we're going to do it with a LEGO. And we're going to first go over here. We're going to add a picture and then we're going to add a picture folder to our form. And you see that come in there, not the picture folder so much, but the picture.
Now we're just going to change these names in the picture folder to match whatever the values are for our parameter. So we choose-- we type Exclude and Include Hole in here and then we simply go down here to the properties and browse out and choose an image. So we've got some images set up there.
We'll do it again down here for the Include Hole, go out and select a different picture. And the last part of this is we go up to the picture control and come down and there's a picture parameters. So we set that to use the whole parameter. As soon as we do that, now the picture is driven by that parameter.
So let's see this in action. We'll open up our form, we'll go to the Hole tab, and we'll change that. And you'll see that the picture changes when we change the parameter.
And so in real life, we often have something that's hard to see. Let's say this LEGO was flipped around the other way and maybe the user can't tell what they're changing. So by giving them this sort of dynamic picture in our form, they can make that connection back to that tank with the flange.
When we're looking at a large assembly, sometimes smaller details are kind of hard and the user will change that. They're not sure what they're doing and so it makes it hard for them to connect. And then, oftentimes, that only gets picked up later down the line. Oh, they configured that wrong and we've got to go back and fix that, or something like that. Building these pictures into the form can help us not have those issues.
So that was build better forms. I think sometimes we're just trying to get iLogic working. And I think, at some point, we forget to go back and make things visual and think about the user experience if we're designing these forms for other people.
So let's look at tip number 16. It's called lockdown global forms.
So here's an example where I'm changing the location of a form. And every time I open it, it opens up in that last location. You've probably seen this happen, right? So wherever I move it, it comes back up there.
So I'm going to go out there. I'm going to right-click on my global forms tab, choose Open location. And then we'll go out to this Lego_state. Notice it has the location information in there. So what I'll do is I'll right-click on that and choose Properties. And I'll set the Read-only on that.
So once this file, this state.xml file is set to read-only, notice I can move that form around and it doesn't matter. It goes right back to where it was. So I can move it off-screen or whatever and it comes back to where I put it.
So by making that file, that .state XML file read-only, it locks that down. So that can be a good thing, but let's look at a scenario here.
So here we have a lady, she likes her Outlook on the right screen and Inventor on the left screen. And so we are working in a group. We put all of our rules and global forms into Vault. And what we do is we have our users check them out. And so this is a common situation or a common setup. And so this all works good for her because it just happens to work for her setup.
So this guy, he would prefer it be this way, where he has his screens or his applications on the opposite screens. But what happens is because that state.xml file is locked, he always ends up with his form in the wrong spot. And it may not be on the opposite screen. It may just be on the opposite side of the screen or something like that, but it doesn't really work for him.
And so what we can do in this situation is just on his machine-- since it is a copy pulled out of Vault, we can unlock that, let him move it over to his side, and then we just lock it back, make it read-only again. And we don't check it back in. We just leave a local on his where we let him adjust that. So this is a helpful thing to know about, is to be able to lock and unlock these global form state files to be able to control not only the location, but the size and a few other things with our global forms.
OK, let's look at our third objectives, and that's finding our way around the API. So let's start off by understanding the API. So this is a common metaphor when we're talking about APIs, and that is a waiter. So in this case, we're using the menu as our interface. That's what we work with. And then our waiter goes to the kitchen and goes to the chef and he takes our request and brings back our food. That's our response. And so, again, a very common analogy for APIs.
So let's take a look at our world, iLogic and Inventor. We can think of iLogic as our interface. And then we work through Inventor's API to actually communicate with Inventors. So again, we're sending requests, but we're sending them through the API and then we're getting our responses back through the API as well.
So with that in mind, we're going to take a tour using the object model. So this is a PDF file that comes with Inventor. And if you go to this location and unzip that developer tools MSI, it'll open that PDF on your machine. And you can look through here.
We're going to just understand it from a high level and understand that it's a kind of a drill-down of collections and objects in those collections. So, as an example, if we're trying to do something with an extrude feature, we would drill down from the application, the collection of documents. We'd get a specific document, we would get the component definition of that document, and now we're working with more collections, right? Feature collections and then extrude feature collections until we get that extrude feature. So that's what this chart is all about, all the parts of the Inventor API mapped out in this drill-down.
With that in mind, we're going to use that to compare something we actually work with every day and know and are familiar with, and that's just a part file. So here we've got the whole part file. We've got the component definition. Component definition is just what makes this part file different from other part files. So that's what that is.
Inside the component definition is the collection of features. So all of these things make up the collection of features or in the collection of features. And then we have just extrude features as a subset.
And then, finally, if we want to wanting to work with Extrusion1, we can get down here to the extrude feature. So maybe we're trying to suppress it or rename it or something like that. So that's what we would be trying to do with the API.
Let's compare this to a rule, an iLogic rule. So here we have a couple lines that gets the application, gets the document collection, gets the actual document-- this part document. Now we're getting the component definition, the collection of features, the collection or the subcollection of extrude features, and then finally we're getting that Extrusion1.
So often, though, we're typing a line of code out like this. So we type .Features.ExtrudeFeatures and so on. So what I want you to do is make that connection between what we've just been talking about and that line of code. So if we flatten that drill-down out, you can see that it's really the same thing. And so when we're typing this out and trying to get that extrusion feature, we're really just drilling down through the object model, the API object model.
So with that in mind, when we put it all in one line like this, it's really the same thing as what I showed you in that other example where we did it longhand. You can think of this as like when you were in school and you were taught to do long division and show your work. Here, we're showing our work. We're building it all out. Here we've kind of combined a couple steps, but we haven't combined it into just one line. But all three of these examples do the same thing.
One thing to note is if I make a mistake or if something isn't quite right, I'll just get an error on line 2. And I'm not sure what part of this the error occurs for. So if I did my-- if I showed my work, I would get an error, like maybe on line 8. And I'd get a very pinpointed error that way. So sometimes I'll put something like this in to start with, error, and say, OK, let me break it out into steps. And then that way I can figure out where the error is actually happening. But other than that, again, all three of these do the same thing.
So that was a very quick delve into the API and understanding what it is and how we use it, how it relates to our iLogic code. Let's build on that and talk about tip number 18, which is declared variables in IntelliSense.
So this is something that a lot of people really struggle with when they start out with iLogic. And when we're typing code, we'll get that little helpful IntelliSense menu and it's predictive in the sense that if I start typing "ex" here, it goes down and I can go, oh, ExtrudeFeatures, that's what I was after anyway. OK, perfect. I'll just select it from the menu.
But what about an example like this? You've probably all seen this. You're going along and you're expecting to be able to find the part component definition and it's not there. We don't see component definition anywhere in that IntelliSense menu. So we're like this lady going, what, what's going on? I saw it last week when I was doing this same thing. It popped up. But now I can't find it. I must be doing something wrong.
Well, the problem is we didn't declare our variable. So we said oDoc equals ThisDoc.Document. And we've got the document, but we didn't tell it that it was a part document. So it doesn't know how to suggest that we can find the component definition because we haven't dialed in enough.
So as soon as we go in here and we add another line that says Dim oDoc as PartDocument, now she can find what she's looking for, right? So she typed "co" and then there's ComponentDefinition magically shows up. Well, it's not magic. We just need to again tell our variable what it is. It's a part document.
So why does it work this way? Here's an example of what's happening when we don't declare it. It knows it's a document, but it doesn't know what type. So it's just a general document. And an Inventor document has things like property sets and so on. But there are specific kind of documents, like a part document and a drawing document, and they have completely different objects and properties. And so as soon as we declare this as a part document, we step over from here and we go to here. And now suddenly we're looking at the right set of objects and collections. And so we can find what we expect to find.
So really important concept is to declare your variables. And then, again, all of this becomes much easier because the IntelliSense starts helping us along when we're in here working with the API.
So all of that was using documents as an example. But it's true of anything here. We're working with an extrude feature. Again, we declare it. We'll get all the things about extrude features, balloons and the drawing environment. Again, we get all the things that pertain to balloons, opponent occurrences, general notes. Again, declaring the variable gets us the right stuff in our IntelliSense menu. So that was tip number 18.
Let's take a look at tip number 19. So this is iLogic API objects versus Inventor API objects. So the short version is they're the same thing. So if we pull off the mask, really, the iLogic and Inventor API objects are the same thing. Knowing how to take the mask off is what we're going to talk about.
So to do that, we're going to use this example. And this is an example where we put a radius dimension on a part in a drawing. So what we want to do, though, is add that typical-- oops, skipped over that.
We want to add the word typical here to our dimension. So we start off with, again, seven lines of code to add this radius dimension. Pretty easy stuff to do. We're going to extract that out. Bam, we've got that working. We're happy about that.
Now we want to go ahead and add that typical or that T-Y-P on the end of our dimension. So we would-- maybe we have figured out an example online or we looked on the API help and we figured out that we need to work with formatted text.
And so we come in here, we get our MyDimension variable that we added here, and we type dot. And we're expecting text or formatted text or something like that to show up. And it doesn't. And so we scratch our head for a little bit and then we say, oh, wait a second, Curtis said that if we declare our variables, we get the right stuff in the IntelliSense menu.
So sure enough, as soon as we declare this as general dimension, now suddenly we can find text and formatted text. And we think, well, that's cool. We figured this out. This is starting to make sense to us. So we run our rule and Inventor or iLogic nopes out at us and says, nope, that's not going to work.
And it gives us a little hint of what's going on here, but this probably doesn't make much sense to us. The part that I want you to notice is this managed thing here, right?
And so what's going on here? What we want to know is that when we create something with iLogic, with the iLogic add-in, our objects get wrapped and thrown into collections. So they get thrown in these IManaged or ICad collections and they get kind of wrapped up in these wrappers that kind of have to do with inheritance and all that kind of thing. We won't get into all of that, but we just want to know that when we're working with a native Inventor object. The iLogic version that we create is in a collection and a wrapper.
So it kind of looks like this. So we're using the iLogic AddRadius snippet. And it creates this as some sort of IManaged dimension that gets wrapped and shoved into this collection.
And we can see that if we hover over this AddRadius function. And we see the word IManaged here. And we see that it's going to create this object as an IManagedRadiusGeneralDimension. So what that means to us is just iLogic stuff. It's going to create this as iLogic stuff. You don't have to think too much more about it. I'll talk a little bit more how you can learn more about that, but that's what's going on. It just creates it as iLogic stuff.
So in order to use this as a Inventor API object, we've kind of got to unwrap it, take it back out of the collection and unwrap it. So what we'll do is just come down here and we'll declare this as a new variable, as a native Inventor object. And then we'll use our iLogic object-- the thing we created up here-- and we'll type dot and we'll get NativeEntity. And we can see if we hover over NativeEntity that it's a radius general dimension, not an IManaged radius dimension. So that kind of tells us this is an Inventor API object, not an iLogic API object.
So this is what this looks like. So we create our object or we create our dimension as an iLogic dimension and it gets wrapped and thrown into collection. And then in order to use it, to add the word typical to it, we have to use this NativeEntity, which means we unwrap it and take it back out of the collection. Then we can get what we need and we can add the formatted text on here to add the word typical.
So one thing to note about this is that it's not always NativeEntity. There's different ways to do the same thing. Here we're working with a view. And you can see in the view, we get NativeEntity. And the tooltip tells us that we're getting the native API view entity. But we could go down further in the list and we get View. So it seems a little weird because we're getting view from View, but this is just a way to get the same object without passing through NativeEntity. And so here it tells us we're getting the Inventor API Drawing View object.
So as we go through these examples, I'm going to show you that the tooltips and the naming is not very consistent. Right here, we're working with an ICadDrawingView. Here, we're working with an IManagedItem. So it's a little confusing to us if we're just kind of new to some of this stuff. Don't worry too much about it. But just understand the tooltips and the naming are not consistent.
Here we're working with an Assembly. And in order to get the Assembly API object, we're just going to use document. And again, we see that we're working with an IManaged, so an iLogic or iLogic stuff. And what we're getting is just the native Inventor object or document, I should say.
Down here with Occurrence, instead of NativeObject, we're just going to use Occurrence. So, again, ManagedComponentOccurrence and then we get the native Inventor object.
Let's see. So here we're working with the Constraint. And here it's just Constraint instead of NativeObject. The tooltip is pretty helpful. It tells us exactly what's going on in this case. Down here with the Feature, again, it's just InventorFeature. So they're all a little bit different, but what we want to know is that we're just looking to take our IManaged or ICad thing and pull the wrapper off or pull the mask off to get back down to that Inventor API object so we can do those things.
So I mentioned I'd show you how to learn a little more about that. If you go to this link, the online iLogic help, all of these IManaged an ICad things, all these interfaces are out there. And you kind of look at them and read a little more about that.
There's a lot of them. And you can see the naming is a little bit different for all of them, but you can drill down in there, understand that a little bit better. If you're not that interested, again, just know that an iLogic object we created, it's a wrapper or a mask put on it that we have to peel away in order to do Inventor API things with it, like adding the word tip to a dimension. So again, just understand there's a mask to be taken off. And that'll help you look for how to do that.
Again, we've got an example of this radius dimension. So if you want to experiment with that and understand how that works, you can look in there and use that.
So tip number 19, that was iLogic API objects and Inventor API objects. Let's go to tip number 20, and that's Access API and programming help files. This is a quick one, but it's something that sometimes we overlook.
So let's take a look. What we do is we come up here in Inventor, we go to the Help. Click Help and then Programming/API Help. And it'll pop up-- this CHM file is what it is. And in here there's all kinds of examples and references. So if you're trying to figure out all of those API reference information, it's right here. And you can go in here and search and that kind of thing.
The example I was using was formatted text earlier. And so we could go in here and look up a Inventor dimension-- or RadiusDimension, I should say-- and realize formatted text is a property of RadiusDimension. And that's where I would add the word typical.
So just knowing that's there is a big help. There's all kinds of other information on how to get started with the API that you can go through in here as well. And again, go to Help and Programming API to get to that. You can also find it online. And so I've provided a reference link as well. So that was a quick one. That was how to access the Help files for the API.
So let's go to our last objective here. So we want to explore development and error-handling tools and techniques with iLogic. So let's have a look at those.
So the first one, I'm not going to go too deep in, but I just want you to know that you can use Visual Studio to debug your iLogic rules. And so one of the things we want to understand about this is that all of our iLogic rules get copies of them made behind the scenes.
So if we edit them or run them, it'll put a copy of that out here in your profile name at this location and it'll make this a .VB file. And so what we can do with that is we can go into Visual Studio and open that file and you can open that up and debug, put breakpoints on it, and that kind of thing. You're just debugging that file. You're not actually changing the original file, but it'll help you figure things out.
I'm not going to go too deep into it because Mike Deck has written a really good article on it on the Mod The Machine blog. And so you can go in here and go through this, the setups for that. He's using-- this is a couple of years old, so he's using an older version, but it all works the same. So go check that out if that's something of interest to you.
Again, I think a lot of people just didn't catch that. That was made available back in 2019. But it's helpful when we're working with maybe you've inherited a 1,000-line iLogic rule or something crazy like that. And that's just a lot to try to debug or improve in the iLogic editor. So we can use this to do that and it's much more helpful.
OK, so let's go to tip number 22, use the iLogic logger. So what is the iLogic logger? Let's start there. So this is a logging tool where we can write out information from our rules. So here's an example where I'm stepping through all the components in the occurrences and I'm writing out three loglines. The first one is the occurrence name, then the part number, and then just a empty space just to create some separation so it's easier to read.
So if I'm working with 10 parts or whatever this is, not that big of a deal. But if I'm working with a hundred parts, this will write out instantaneously versus having to do what we see a lot of times, is this what I call message box sleuthing where, in this case, instead of using the logger, I used a message box and now I've got to click OK every time to 100 parts.
And all I'm trying to do is figure out if I've got the part number right or what some-- oftentimes, I've been trying to compare strings and I'm expecting something to equal this and there's-- one's capital and one's not or something like that, something silly. But until I visually see it, I can't figure out what's going on. So writing that to the logger or message box is really helpful. But if it's a large assembly and I'm looking for one component that's not quite like the others, I've got to click through all these message boxes. So the logger can come in and help us a lot with that.
To access the logger, we can go up and hit that little plus sign right there, right next to the model browser, and it'll come up. And then we can just move this around. We can dock it. We can put it on a second screen, can move it down and put it towards the bottom, whatever we prefer there. Just get it where you like it and you can read all this information.
There's another way to access it. So again, you can go to the plus sign next to the model tab and get it. And you can also go up to the View tab and go to User Interface and you can turn it on and off there as well.
So there's also log level filtering. So if you are in a rule, you can go down to the bottom of your rule editor and you'll see this list right here. And the way this works is this is hierarchical in the sense that TRACE is the highest level and FATAL is the lowest level. And so here I've got a line of each right here.
And let's say I set it to WARN, so it's going to be in the middle. And so when I run the rule, it's only going to write these three lines out. So it's going to go from WARN-- it's going to go from WARN down, WORN, ERROR, and FATAL. And it'll write those three lines out.
If I set it to TRACE, it's going to write all six of those lines out, as is shown here. So just know that's the way it works. The intention here is just to be able to filter down which loglines I want to use. Most times I just use the INFO line for most of my troubleshooting debugging needs.
The other thing to note is that if we set it to TRACE and select this Detailed Trace option, it can help us with that situation where we have too many blue trigger parameters. Remember, we were talking about those trigger parameters cause our rules to run. And if we end up in that situation where one rule is causing another rule and causing another rule and things start turning on and we can tell we've got too many things running, we can use this detailed trace to monitor that.
And so here's an example of that. We've got detailed trace turned on. And notice when I make a change, it shows me what triggered the rules to run. It tells us that we entered the rule and exited the rule. So, again, as I keep making changes in this model, it tells me now we had a different parameter trigger. It even tells us the value.
And so this can be really helpful when we start having that cascade of rules running one after another. We can go in there and figure out what's making them run. So that's why-- we do that by going into our rule editor, setting to TRACE, and checking that Detailed Trace option.
OK, so here we're at tip 25. I've skipped a couple just for time. You can go to the handouts and review that, go to the presentation materials. But let's do tip number 25 here. This is use a code comparison tool.
So you may have been in this situation where you've had things working, you went in to fix something, and you're not sure what you changed to break it. And so what we can do is we can use a code comparison tool like Beyond Compare. And what it does, assuming that you're keeping copies of your files as you change them, we can go in and we can compare those two things. This will work with external tools only, otherwise it's embedded. But you can copy the rules out of your internal rules or however you want to make that work.
And then you can track, visualize, and merge changes together. So, in this case, again, I can see I changed 4 to 2 and maybe that was causing a problem or something like that.
Beyond Compare is a paid app. So if you don't want to purchase something, you can use Notepad++. It has a compare add-in. And then there's one called KDiff, which is an open-sourced and very popular alternative to Beyond Compare as well.
So that was the use comparison tool. Again, a big help for comparing the older version with the current version and seeing what's working, not working, and finding those what we call diffs.
So to wrap up here, go out there, download that supplemental information. There's a collection of rules and then the datasets out there along with the presentation and handout files. So pull those down and give those a try. And hopefully that helps you understand some of these tips, kind of have them in your quiver so that as you go through creating iLogic rules and forms and that kind of thing, you'll know about all this stuff.
So thank you for watching. And I wish you all the luck in your iLogic automation going forward.