What Is iLogic?
For the most part, people who use any type of desktop application understand what automation is. If you’ve used Microsoft Excel you may have heard of Macros, tools developed and designed within Excel to accomplish a specific task. Inventor Automation is very much the same in the sense that while the automation can take the form of many different things, in essence, it is a tool or a series of tools to automatically accomplish a specific task, process, or function. iLogic is one form of Inventor Automation.
iLogic is a functionality of Inventor that allows users and administrators to create logic in the form of VB.net to accomplish tasks. Rules are developed and organized using snippets and other code writing statements to run at given times to consistently do some of the work engineers and designers need to do.
You could develop a series of iLogic rules to do things like updating iProperties based upon different model criteria or Replacing Components in an assembly based upon selections made in an iLogic Form, or even update text blocks within an associated Drawing. The list is long as to what iLogic can do. The question is, what do you want it to do for you?
Why Should I Embrace iLogic?
Now that we understand what iLogic is, let’s take a look at the reasons why you might want to incorporate iLogic into your engineering processes.
First, in my experiences working with manufacturing companies big and small, all over this world, fabricating and manufacturing many different types of products, one thing always rings true: there are patterns and repeatable plays in every environment. The key is to find the ones where iLogic can be of assistance. This simple task requires an intimate knowledge of all the places Inventor plays a part in your process.
Say for instance, you have a specific format for the iProperty Description of your 3D models or any of the iProperties for that matter. If the formatting is predictable, if it is standardized, then this is a situation where iLogic can come to the rescue. You could develop logic to collect information from the model, transform that information, and then overwrite the iProperties with the correct, newly formatted information. It is always correct, it is always consistent, and it never asks for a coffee break.
Related: Taking It to the Next Level: Drawing Automation with Autodesk Inventor with Thomas Fitzgerald
Configuring Inventor to Use iLogic
What do I need to do to Inventor to effectively use iLogic?
Although iLogic is included in Inventor and you can start creating and using iLogic right away, it’s helpful to understand that there are some settings that should be addressed in order to use iLogic to its fullest extent. The iLogic Configuration button allows users to configure different settings to define where Inventor will find supporting information.
Users and administrators will want to modify these settings to control where Inventor will find External Rule directories, as well as the order priority for those directories. Users can also define the directory location Inventor will find any DLLs, or Dynamic Link Libraries. DLLs are the output from Microsoft Visual Studio for the development of custom User Interfaces to drive and trigger iLogic rules and other logic.
The settings dialog box gives users the opportunity to set what file extension External Rules will be saved as and the default Logging level in which debugging information can be produced. There are also some Security Options settings to protect computer and network systems from potentially hazardous code running within the Inventor environment. There will be more information about External Rules and Debugging later in this document.
Internal Versus External Rules
Which one should I use and when?
iLogic Rules come in two flavors, Internal Rules and External Rules. Either type of rule is created similarly within the context of Inventor in the iLogic Browser.
Internal Rules are rules that are created and stored within the context of a file. Part, Assembly, and Drawing files all have the capability to store, compile, and run rules to affect each file differently. External Rules are pretty much exactly the same, however, they are not stored within Inventor files. Because Internal Rules are stored within the files, they are exposed and accessible to the users that have permissions to those files. External Rules are stored in a directory either locally on a user system or central on a server, geographically agnostic.
Because External Rules are stored in a folder outside of the files, there can be a higher level of security to those rules. Yes, users can open and see the rule code, however, system administrators can control access and editability by defining Folder Permissions to the External Rules folder. For this reason, External Rules are preferred in an Enterprise environment where numerous users might want to run code throughout the design process. If conditions do not require permission control or if multiple users do not need to utilize the rule logic simultaneously, then perhaps Internal Rules are sufficient.
Both types of rules are visible within the iLogic Browser, as seen in the images below.
Right clicking on either type of rule can control features like Suppressing or Unsuppressing rules to control when they are triggered, deleting rules, or removing them from the list.
Parameters and Properties
How should I use them?
Autodesk Inventor is a “3D Parametric Design Application.” Well, what does that mean? Parameters are named value placeholders of a specific type. Most parameters in Inventor are numeric in type and are associated to dimensions that control geometry. As parameter values change, the dimensions associated to those parameters change as well, graphically updating the models. There are essentially four types of Parameters in Inventor:
1) Model Parameters
2) User Parameters
3) Reference Parameters
4) Linked Parameters
Model Parameters are those parameters created by normal Inventor behavior. In the Parameters dialog box, these are automatically named as d0, d1, d2, etc. Model Parameters are controlled by Inventor, meaning they are created and deleted as necessary by the system.
User Parameters are those parameters created by users. They can be Numeric, Text or String, or True/False or Boolean. User Parameters are especially important because these are created by users, consumed by many different features as well as iLogic code, and are not created or deleted by normal Inventor behavior.
Note: Creating User Parameters by applying a naming convention and type is the preferred method of using parameter information in iLogic rules. Although you can rename Model Parameters, it is not the preferred method to use.
Reference Parameters are created when Inventor defines a Driven Dimension. If you’ve ever seen this dialog box when working in the Sketch environment:
Selecting Accept in this situation would create a Reference Parameter. In the Parameters dialog box, you will see the parameter name and value, but you cannot change the value. You can change the name, which is helpful in using the value in iLogic code.
Linked Parameters are those parameters linked to Inventor from, typically, an Excel Spreadsheet. When a user updates the names and values in the Excel Spreadsheet, those changes will reflect in Inventor, ultimately driving dimension values, controlling features, managing assemblies, etc.
Properties, or iProperties in Inventor lingo, are additional descriptors or other valuable information about your files. This is sometimes referred to as Metadata. Properties are nothing new and can be extremely useful when trying to collect a lot of data about files. Filename, File Size, Author, Modified Date; all of them are Properties. Most of the time, when working with iLogic and Inventor file data, Filename and File Path are the two most common Properties to handle. Other popular Properties are, Part Number, Stock Number, Description, Mass, Cost, and Custom Properties. All properties are Read, most properties are Write Enabled.
Declaring Variables, Typecasting, and Shared Variables
How important is it to use this coding mumbo jumbo?
iLogic is code, plain and simple. Although one does not need to be a programmer or even know how to write code, embracing some of the basics of code writing best practices will get you a long way. This is because there are some standards that all programmers understand. Declaring variables and Typecasting is one of those standards. Why is this important? Well, it’s like speaking any language. Having a standard relieves some of the confusion when writing logic.
Declaring Variables and Typecasting
Declaring variables is actually extremely simple. In iLogic, it’s simply writing a name and giving it a value:
Length = 20
Once I have a variable created, then I can do things with it. I can read the value and process it in a calculation, or I can write to it to update something else. Even though typing a name and value pair is acceptable in iLogic, a better way, leveraging a code writing best practice, is to type the name, give it a “type”, and then providing a value:
Dim Length As Double = 20
What this does is tells iLogic to create a variable that will only hold a “Double” value, and then provide the value. This is called Typecasting. It ensures that only a specific value can be provided to the variable. If I would try to provide a String or Text value to the Length variable, my code would fail. I have found that by providing a type allows me to use much more complicated code in my rules as well as understanding and visualizing the flow of information. As an example, if I write a statement in a rule that conducts a mathematical calculation, and I receive and error, then I know that any of my variables that are of the “String” type are not at fault.
The following are examples of different kinds of Declaring Variables and Typecasting:
Dim cylinderHeight As Double = Parameter("CylinderHeight")
Dim fileName As String = "This is a string value!"
Dim holeCount As Integer = 2
Dim occurrenceName As String = String.Empty
Dim plateWidth As Double = Nothing
You’ll notice that in the last two examples, I did not provide a value, or rather, an empty value or nothing. There will be occasions that you may need to declare a variable, but you may not know the value as of yet. In this case, you can maintain consistency by declaring the variable, typecasting, and providing something on the other side of the equals symbol. This is also helpful for debugging code to see if a value is or is not being provided programmatically.
If you were paying attention, you’ll also notice the first example where I declared a variable, typecast, and set the value to be equal to the value of a User Parameter. This method will be useful when constructing the logic needed for calculations, passing values to other constructs, and manipulating other parameters. It is also useful when you need the either get or set the value of the User Parameter immediately, at the time the code needs it. This is why new users to iLogic experience problems when running rules, expecting a specific behavior, but Inventor seems to “lag” behind a step. Take a look at the following examples:
cylinderHeight = CylinderHeight
Dim cylinderHeight As Double = Parameter("CylinderHeight")
Both these statements do similar things but not quite exactly. The first example declares a variable that could be of any type, with a value equal to the User Parameter. Because the text color is blue, Inventor recognizes the User Parameter. Because Inventor recognizes the User Parameter, any rule that is unsuppressed using this format, will automatically run. You many or may not want rules to run that way.
It also means that the variable will be set to the value of the User Parameter at the time from the last Update. If logic had changed the User Parameter value between the time the variable needs the value and the last update, then the User Parameter value is out of date. This is why an Update is required, and sometimes it seems numerous Updates are required to get the desired result.
To get past this, you can do two things. First, use the second statement. By declaring the variable, typecast, and use the “Parameter” function, you set the variable to be the value of the User Parameter directly, ensuring the value is up to date. It also gives you more control over when rules run. Second, use the “RuleParametersOutput()” iLogic snippet. This will keep all the User Parameters up to date. Then conduct an Update to ensure the models associated are up to date as well.
Shared Variables
Previously, we were discussing code practices about variables, but Shared Variables are a feature of iLogic. When declaring variables in an iLogic rule, that variable is only accessible within the context of that rule. If you need to create a variable and set its value to use within numerous rules, then Shared Variables are the answer.
In the iLogic Snippets Panel in the iLogic Rule Editor, you can find the Shared Variable functions under the Variables index.
To use Shared Variables, we will follow a similar process as when declaring other variables. First declare the Shared Variable, provide a name for the Shared Variable, then provide a value. The value can be a static value, or it can be the value of some other variable, parameter, or property.
SharedVariable("VariableName") = "This is the value" SharedVariable("cylinderHeight") = Parameter("CylinderHeight")
Once a Shared Variable has been declared and a value provided, then it can be consumed and updated as necessary.
Dim cylinderHieght As Double = SharedVariable("cylinderHeight")
Use the other Shared Variable functions to see if a Shared Variable exists, or to remove any and all Shared Variables from memory.
Conditional Expressions and Loops
Does a human always have to make a decision?
In normal interaction with Inventor, we have the luxury to look at the graphics window and select geometry to decide what to do with it. In an assembly, we can understand how components relate to one another. When we start looking at iLogic rules, we sometimes need to define the decision-making path by understanding the different conditions that might exist within a design. Using expressions that define the different conditions is a means for users of iLogic to accomplish those tasks.
The most common Conditional Expression is the If Then expression. It looks something like this:
If someValue = True Then
'Do Something
Else
'Do Something Else
End If
In code, we look to see if a condition exists and if it does, then the code will do something. If the condition does not exist or if a different condition exists, then the code will do something else. We can extend this functionality to look for numerous conditions, like the following:
If someValue = True Then
'Do Something
ElseIf someValue = False Then
'Do Something Else
ElseIf someValue = Nothing Then
'Yet Do Something Else
End If
This all looks easy and it makes perfect sense; however, there is a limit. One could easily expect the conditions to continue indefinitely, but after a certain point, it becomes confusing as to what is really happening, especially when you start adding in additional Operators. In my opinion, once you get past three or four conditions, there are better ways to handle the situation.
Another common Conditional Expression is the Select Case method. It works similarly, but to me, it’s much easier to read and understand, not to mention, less code to write. Select Case looks like this:
Select Case someValue
Case True
'Do Something
Case False 'Do Something Else
Case Nothing
'Yet Do Something Else End Select
As you can see, it’s a little easier to understand and it’s very easy to scale for the number of conditions you might have to accommodate.
One of the most essential methodologies used in writing code is the concept of Loops. Using the example of iterating through an assembly to get the names of the occurrences, Loops allow us to go through all the occurrences without having to know how many occurrences exist. Constructing code and developing logic is all about understanding patterns, consistency, and predictability. Sometimes there are methods that can be used to accommodate unpredictability. Loops are those methods. Here’s an example of a For Next Loop:
Dim counter As Integer = 3
For t As Integer = 1 To counter
MessageBox.Show("Number of Iterations: " & t)
Next
In the example, we defined the starting point of the Loop, number 1. We also defined the ending point of the Loop, counter which is set to 3. So that means, the Loop will iterate three times to produce a message box. If we don’t know the ending point for the Loop, we could do count the items in a collection and make that our ending point. Check out this example:
Dim items As New List(Of String)
items.Add("Pizza")
items.Add("Sandwich")
items.Add("Milk")
items.Add("Eggs")
For i = 0 To (items.Count - 1)
MessageBox.Show(items(i))
Next
In the example, we created a collection, populated the collection, and then informed the Loop to iterate as many times as there are items in the collection. If you notice, we start the Loop at 0 and end the Loop at the count minus 1. This is one of those situations where understanding Indexing is important. Indexing is nothing more than identifying a starting point. Typically, it’s either 0 or 1. In this type of collection, the first item in the list actually starts at 0, not 1.
Thomas Fitzgerald is a senior implementation consultant specializing in Inventor Automation and Data Management. Thomas has consulted with a large number of companies with a very diverse exposure to both large and small engineering departments. Thomas has over 20 years of experience within the mechanical design and manufacturing industries using numerous Autodesk products. He is an Autodesk Certified Instructor as well as having his Microsoft Certified Systems Administrator credentials.
Want more? Download the full class handout to continue reading.