Introduction
This article covers a broad range of capabilities enabled by the power of iLogic within Autodesk Inventor, from some of the fundamentals to how more powerful functions can be applied. Specific topics include developing standards-based designs, capturing engineering knowledge, developing recipes from existing assemblies to help build new designs, creating drawings using the latest updates within Inventor, and retrieving data from other data sources, in addition to automating functions within a model such as updating CAM toolpaths and FEA studies.
Related: Inventor iLogic Best Practices and Fundamentals for Success with Thomas Fitzgerald
Fundamentals
The gateway to automation needs to begin somewhere, with the starting point often being the creation of intelligent models that will be used within the design and manufacturing process.
Over the years, organizations have been asking for a way to capture their design and engineering intent, taking labor-intensive tasks out of their day-to-day activities by building engineering knowledge into their models. One benefit this brings, is introducing a level of consistency and standardization into the process.
In recent years, organizations have also been looking at how they can build a better up-front consumer experience. This usually develops into a requirement to provide a mechanism to make their design data available sooner, so they and their customers can take advantage of mass customization workflows.
Last but not least, automation isn’t purely down to design functions. Being able to benefit from any generated information downstream, such as business systems, is becoming a key requirement for most design and manufacturing companies.
iLogic Improvements
Up to and including Inventor 2018, when creating an intelligent assembly, the user had to rely on creating all possible iterations within a single design, effectively requiring the generation of a 150% model for each design type. By then suppressing or replacing parts, users were able to interactively drive assembly changes.
With Inventor 2019, Autodesk introduced the capability to start capturing recipes for designs. This effectively allowed a user to start with a blank sheet each and every time to build up new assemblies.
Now with Inventor 2021, Autodesk has extended the capabilities within the drawing environment, adding further flexibility and enabling greater automation options, in addition to making the design automation within Inventor available on Autodesk Forge.
Saving Time
There are some quick wins, things that can make everyone's life easier, by removing tedious tasks and saving minutes. Then there are the more complex solutions, potentially taking longer to develop but ultimately saving hours of effort for every action.
Modularization
Let’s look at modular construction as an example of where design automation capabilities would benefit an organization. Each aspect of the design needs to be positioned and sized to suit, allowing for enough variation to develop a unique outcome.
Every time a new design is required, rather than re-create and re-document for each variation, design automation allows for faster reuse of existing design data, the design knowledge to be maintained within the models, and an overall increase in engineering productivity.
By capturing the knowledge and variation allowance, quicker interactions can be achieved whilst automating the documentation. Outputs also aid faster project turnarounds.
iLogic Rules
Within Inventor, iLogic uses visual basic as a foundation with predefined snippets that can be used to build rules. These rules can be stored locally within a model file or shared as a global rule that can be stored on a network or even compiled into a dynamic link library (via tools such as Visual Studio) to limit team members making changes.
Logic Statements
The most common logic statement when generating rules is using the If, ElseIf, Else, End If rule. Most users will use this type of statement throughout their automation development.
One of the benefits of the If, ElseIf, Else, End If statement is, it can easily make allowances for outcomes that may be outside the expected result. This is why it is always important to finish a logic statement with an Else statement, as it always gives you an outcome no matter the result. Otherwise you may end up with errors that cause the rules to terminate prematurely.
It is also good working practice to avoid creating overcomplicated rules.
When relying on a Boolean parameter (True/False), it is always good practice if possible to directly reference it if needing to add / remove parts, suppress / unsuppress features. This makes reading the code easier and removes unnecessary lines within a rule.
Another way of accommodating logic is to use a Select Case, Case, End Select statement. This allows for easier interpretation of logic that has specific defined values and variation.
Rather than having an overcomplicated If, ElseIf, Else covering expected and intermediate values, the Case definition allows value sets to be defined that are easier to understand.
Best Practices
Instance names within the Inventor browser are important to pay attention to. When capturing iLogic, Inventor by default uses the instance name to define the reference within iLogic; for example, to find and pass parameters.
By overriding the Inventor model instance name, no matter what happens to a design, whether files are renamed or copied, the iLogic rule will still be able to find its associated model reference and run.
Also bear in mind, Visual Basic (which iLogic is based upon) and Inventor parameters are case sensitive, so you need to make sure there is consistency when defining and referencing any naming conventions.
Although some power users may take advantage of Visual Studio to create custom complex forms, there is much that can be done out of the box using the Inventor embedded form creation capability. However, it is important to understand how the form's predefined button options will affect updates, after parameters are changed.
Leaving an iLogic form as the default means for every parameter change, the model will update, which can become time consuming when working with large updates.
If it makes sense for a user to input all their options before a model update occurs, make sure you change the predefined button behavior to allow for an OK or Apply.
Automation Planning
Before you jump into creating any code, it’s always good practice to plan out what the expected outcome should be and how you think you’re going to get there.
Breaking down the design elements, understanding their complexity, the parameters and rules required, makes it much easier to develop configurations using a more methodical workflow.
Taking a look at the example here, when separating the changes and what’s staying the same, you get a
much better feeling of the controls that need to be in place, as well as the core ‘data management’ requirements for the model.
Highlighting the different changes within the design also gives you a better understanding of the potential benefits design automation will deliver for your project.
Where to Place Your iLogic Rules
When defining iLogic rules, it’s important to understand where these should be created and stored. Users can create rules that are embedded into files or stored externally within a common shared location.
If rules are being embedded into models, there are additional considerations such as:
-
What rules need to be defined within the top-level assembly?
-
What rules should exist within the subcomponents?
-
Are there any external references that need to be considered, such as an Excel lookup and what direction the information will flow?
Sometimes, even when most of the parameters or options can be driven at the top level, it doesn’t mean they should be.
There may be a reason to create rules further down in the model structure, for either simplification, model sharing, or because some should be run at the part level. Rules placed at the part level are often there to make sure anyone using that part has access to the relevant logic as well as controls, such as material and appearance, that need to be driven from the part level.
Part appearance and material are often changed or updated. Within an assembly environment, you can override a parts appearance, but remember, this is only applicable to the design view that is current at the time. This may be as required because the component may be painted once assembled, so has no effect on the manufacturing detail of individual parts.
However, you might want to change the part appearance itself. By defining a text parameter within the assembly that references a valid appearance and a rule to pass this to the part file, a part level rule can be created to update the part appearance relying on the part level parameter.
To start with, the part will only need an equivalent text parameter using a valid appearance name, even though it may be eventually overwritten just to ensure no error message is displayed on creation.
Equations
Just because you can, doesn’t always mean you should. There are still lots of Inventor functions that can be utilized outside of iLogic; for example, when generating parameter-based equations.
Although you can build equations linked to parameters within iLogic rules, remember there is the native Inventor parameter dialog box. To understand how a model has been generated, you can often look first at the model parameters to try and understand the relationships between values. If this is hidden away within an iLogic rule, it may be more difficult to appreciate and understand.
Building Assemblies
Defining Positions
Being able to build assemblies through code relies on knowing what parameters and positions are available, in addition to using standard naming conventions as well as appreciating how an assembly could be built.
For example, when assembling components, we can position them using fixed coordinates or with constraints relying on Faces, Edges or Vertices, and Work Features. We also now have the flexibility to create named geometry that can be referenced when defining any component position.
Geometry Labels
When creating a configuration that is switching out components: if it's constraining using default work features, as long as the normals are all in the right orientation, nothing more needs to set up or created.
However, if constraints are reliant on Faces, Edges and Vertices, users will want to ensure the same positions exist within all related components. This is where iLogic Geometry Labels can now assist users, not just with assembly but also drawing annotation automation.
Geometry Labels can be either manually created within Parts, or a user can rely on the default naming conventions when capturing the code within iLogic.
If an assembly has different options, with all choices being mated in a similar manner, we can use a combination of methods to fix their relative position.
Tip: When switching between options in the same position, to make things simpler, always try to make sure each Geometry Label or Work Feature has an identical name.
Boolean Parameters
When components are to be added or deleted, all that is required is a simple Boolean parameter. If the parameter is set to True, the components will be added, when False the related components will be deleted from the assembly (not suppressed).
Managing Adding / Removal of Components
To define an assembly configuration, a user only needs to capture the snippet of the components that need to be controlled. The captured code can be enhanced using the available snippets that includes the Manage Components snippet.
Bill of Materials
When automating assemblies, you still need to consider what method works best for your situation. Depending on the type of configuration being applied, do you really need to switch out parts?
In this example, Configuration #1 will have two unique parts (in red), the left and right. The bill of materials will list two different part numbers.
Configuration # 2 could be defined by deleting and adding new components (or replacing); however, if managing separate files isn’t a concern, another option may be to leave the model referencing two unique files.
An iLogic rule could then be defined to suppress the relevant features and override the part number to match. Although we will still have two different part files, the bill of materials will show a new part number with a quantity of two.
Just because we can use methods to remove, switch out, and add components, again depending on the situation, it doesn’t always mean we have to.
Drawing Automation
In previous Inventor releases, users would have had to rely heavily on the API to add any level of automation to their drawings. If a design had different components being added and removed, then dimensions would sometimes need to exist and other times not, resulting in consideration of how to best manage orphaned annotations.
What’s New
Now with Inventor 2021, users will see new iLogic snippets that can be used to create annotation such as: Hole Notes, Balloons, Centerlines, and various Dimension types.
Annotations
As long as the model edges are visible within the drawing view, users can select and capture the current state. This places a code snippet into the new iLogic clipboard, whilst users can continue adding references until they are ready to build out the function they require.
Ideally, geometry should already be labelled within the modeling environment, as it means the code can be standardized to allow for certain named geometry. Remember that labelled geometry is applied only to parts.
Want more? Download the full class handout to read on.
Demir Ali joined Autodesk in 2012 from Advanced Micro Devices (AMD). He is currently working as a senior technical sales specialist within the Design & Manufacturing team, covering the UK and Ireland. He has over 20 years experience working with the Autodesk manufacturing portfolio, starting with AutoCAD R12 for DOS, then moving onto Inventor when first released in 1999. He is primarily now focused on the Product Design & Manufacturing Collection, Vault, and VRED. When not at work, he enjoys spending time sculling on the River Thames, mountain biking, getting out on the motorbike, and being a busy dad of two.