Autodesk iLogic configurations hands on lab class: Your thoughts!

[PaulMunford]

I have the good fortune to be presenting a Lab class at AU 2026 🥳

The title is: 'Autodesk Inventor: Get started with configuration, Practical Strategies for Configurable Assemblies'

The class is planned to be an entry-level introduction to iLogic configuration. Over 3-4 hands-on exercises, I plan to build attendees' confidence, give them a framework for building configurable models, and provide a roadmap for continued learning.

I'm starting with some research. If you were attending this class, what would you expect to learn? What questions do you have about configurations in Inventor? What outcomes would you like to achieve from a class like this?

Thank you in advance for your time. I really appreciate your help 😄

Paul

[hollypapp65]

Like to see the different between iLogic, MasterSketch, ModelState/iAssembly.

I'm using ModelState to build a series of server cabinet.  Different witdh, depth, height.  With different component options.

iLogic is used to switch ModelState (user select from a iLogic From) in assembly to make the final product.

MasterSketch was used to make customized "conveyor section".  Complete custom size.  No repeat.  No reusable manufactured part.

I've seen a few "iLogic config" which are pages of setting parameters.  I don't think they're proper examples.

[PaulMunford]

Thanks @hollypapp65, that sounds like a cool use case for Model states and iLogic forms working together!

I think of Model states (and previously iAssemblies) as table-driven configs. i.e. a finite list of configurations. Each new variation is added to the table.
iLogic allows logic-driven configs. i.e. an infinite list of configurations. New variants can be created on the fly based on user input and logic rules.

'Top down' modeling methods based on derive tools (master sketch, multi-body) work great for changes of size. In my experience, driving top-down changes of size with iLogic rules is cleaner and easier to debug... but can be difficult to apply to complex assemblies. Of course, it's pretty flexible, and both methods can be used concurrently.

'I've seen a few "iLogic config" which are pages of setting parameters.  I don't think they're proper examples.'

What would you like to see in a 'proper' example? What would make an exercise feel like an authentic, real-world problem to you?

[hollypapp65]

---

@PaulMunford wrote:

What would you like to see in a 'proper' example? What would make an exercise feel like an authentic, real-world problem to you?

---

Don't know LOL

Maybe how to "link" all the parts and assembly with iLogic instead of a MasterSketch.

Right now I build all possible size in ModelState and select correct one in assembly.  Use iLogic form only in final assembly to select size and enable/suppress "option" parts.

[PaulMunford]

@hollypapp65 That's great insight - thank you!

Here is an AU class from a few years back. One of the excersizes shows how to pass parameter values from the top-level assembly into the components. It includes a dataset you can use to understand how it is put together. Let me know if it's helpful!

Five Autodesk Inventor iLogic productivity hacks for non-programmers! [Lab] 

[WCrihfield · Accepted solution]

As for "what would you expect to learn?"...

• The practice of 'stabilizing' all assembly occurrence names in the model browser tree by renaming them, so that any iLogic rules which may be accessing them by their names will remain stable after replacing any of the occurrences.  Though if there will be a heavy use of ModelStates in the components, doing occurrence replacements may get swapped for changing which ModelState the occurrence is set to.
• The practice of identifying all the important (driving) variables that we expect to be changing in the design before even starting to sketch anything, then proactively creating UserParameters for each of them with meaningful names.
  • Then, as we create sketches and features, taking advantage of two features of the 'value editor'.
    • The ability to assign a name to the 'ModelParameter' before it is even created, by specifying the new parameter name, followed by an "=" equals sign, then the numerical value.
    • And utilizing (clicking on) the small right-pointing arrow at the right end of the value editor, and using the 'List Parameters' context menu option to display the list of 'renamed' (or User) Parameters, which allows the user to pick one, which will insert its name into the 'expression' in the value editor.
    • And utilize its 'recently used' expressions at the bottom of that context menu, which is also extremely useful.
    • And knowing that we have the same resources available within the Edit Feature dialog boxes, where they have 'value editor' fields.
    • When using these context tools, we can almost avoid needing to directly interact with the Parameters dialog box, or at least do so less often.
      • Not as much of an advantage now that we can leave the Parameters dialog box open all the time, but still nice to be aware of.
• When we think of 'configuration' in Inventor, two main strategic resources immediately come to mind:
  • iLogic &/or Inventor API
    • In my opinion, the iLogic rules & forms route offers the most flexibility for building design intent & logic into nearly any design, both in early learning stages, and in advanced scenarios.  However, it can also have a longer learning curve.  Often the more we learn about it and the more familiar we get with it, the more valuable it becomes to us.
  • One or more of the following 'Table-based' resources [ModelStates &/or iParts/iAssemblies &/or Content Center]
    • Using the 'table-based' resources like ModelStates (and similar) may be the simpler and more stable option at first, when they suit the situation.  Especially for those not yet familiar with [coding, iLogic, or Inventor's API], and/or simply don't have the patience or inclination for learning about iLogic.
    • However, when we start mixing the two together (iLogic & ModelStates), the iLogic (coding) portion has the potential for getting a lot more complicated.  Primarily because of how much more complicated it is to make changes to documents & components by code when they have multiple ModelStates associated with them.
      • Therefore, when I create a new complex design which requires one of these strategies, I tend to either use exclusively iLogic OR exclusively ModelStates, but try not to mix the two, if at all possible.  And determining which strategy to use early on is usually a case by case judgement call, based on experience.  Hopefully those types of challenges when mixing the two strategies together will be lessened over time, as we get more specialized tools available to us through iLogic and the Inventor API though.
      • Since LODs (Level Of Detail Representations - prior to 2022) were primarily designed to record & control object suppression statuses, then ModelStates replaced the LODs in 2022, it would seem like the most basic and logical use of ModelStates would still be for recording & controlling object suppression status.  However, I still see a lot of iLogic rules containing long lists of 'Component.IsActive()' type lines of code, based on parameter value tests.  In situations like that it would seem simpler to create a few ModelStates in which all of those parameter values and suppress/unsuppress settings were already established, then simply switch between the ModelStates as needed, either manually or by code.  However, adding multiple ModelStates into the mix can come with a heavy cost if there is a lot of other iLogic stuff involved, by making all of that more complicated.  That balance point can be difficult to predict early in a large or complex design.  It can also be a difficult lesson to teach others, due to the number of possibilities in either route.

[PaulMunford]

@WCrihfield This is excellent, Wesley - thank you so much!

I'm glad you mentioned the Inventor API. I think I will zero in on Model States as one hands-on example, and iLogic as a separate hands-on example. I'll qualify that we won't get hands-on with iParts/iAssemblies or the API in the lab, but I'll include information in the handout for anyone who wants to learn about them.

I'll make it clear that Model states and iLogic can co-exist (but that it can make debugging errors more challenging). 

Thank you! This is really helping me to clarify the class!

[WCrihfield]

Glad I was able to help a bit.

Since you mentioned the terms 'entry level' and 'get started' in your original post, maybe it would not be too silly to quickly mention the important differences between ModelParameters, UserParameters, & ReferenceParameters (among others).  Most folks interested in that type of class will likely already be well informed/experienced in that area, but in a mixed crowd, building on a solid foundation can be important.  A quick mention that when we delete things like sketch dimensions and features, that also deletes the ModelParameters associated with those objects.  And if the name of a deleted ModelParameter was being cross-referenced (used) in the equation or expression of another Parameter somewhere, Inventor will usually not warn us about that, leaving us thinking that everything is still OK.  A ladder with missing or broken rungs below your current position is not 'OK' though.  A driver's ed' type 'scare tactic' to help guide folks towards fully utilizing UserParameters whenever possible, to help avoid accidentally deleting something important. 😄