Automation is a tool which now found in most software, from Microsoft Excel to engineering software. With Automation, rules are created for tasks to be run automatically within that set of constraints. These allows you to obtain an insight for many different conditions within the set rules without having to spend too much time on it.
Inventor Automation runs in the same sense, while the automation can take the form of a variety of things 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?
In the various processes of fabrication and manufacturing of 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. As an example, updating iproperties information. 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.
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
Parameters and Properties
Autodesk Inventor is a “3D Parametric Design Application.” 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 – 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.
2) User Parameters – 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.
3) Reference Parameters – parameters created when Inventor defines a Driven Dimension. If you’ve ever seen this dialog box when working in the Sketch environment.
4) Linked Parameters – 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
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. Having a standard relieves some of the confusion when writing logic.
Declaring variables is actually extremely simple. In iLogic, it’s simply writing a name and giving it a value:
Length = 12
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 = 12
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.
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
Conditional Expressions and Loops
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
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 False ‘Do Something Else
‘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)
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)
For i = 0 To (items.Count – 1)
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.
Example files obtained from Autodesk University.