Issue with Model States in Derived Parts (Multi-Body Skeleton Workflow)

[alexander.naljot]

Hello Inventor Community,

we are working with a skeleton IPT containing multiple solid bodies, which we derive into separate parts. In these derived parts, we want to use different model states because we need to add extra features and create variations.

The problem:

• Inside the derived part, suppressing/activating bodies per model state works as expected.
  I am using iLogic with a Select Case structure to access individual derived bodies and control them per model state. This works perfectly inside the part file, but unfortunately, it does not work at the assembly level when switching model states.
  
  
• However, when we insert this part with model states into an assembly and try to switch model states there, it does not work. The control seems global, not per model state.

Thank you for any help.

[CCarreiras]

Hi!

I belive it doesn't work in the assembly because when you change the model state in the assembly doesn't trigger the iLogic rule doesn't in the part.

Q:

Why don't you use the multisolid directly in the assembly? Why the "derive" extra step?

[alexander.naljot]

Hi CCarreiras,
thank you very much for your quick response!
Regarding your question about why we don’t simply add model states directly in the multi-solid skeleton and then control them in the assembly:
Our skeleton (multi-body part) is extremely large and complex, with over 250 parameters that drive the entire geometry. If we were to add model states directly into this skeleton and then manage them in the assembly, the file would become even bigger and much harder to maintain.
That’s why we decided on this approach:

We derive individual components from the skeleton.
In these derived parts, we add extra model states with additional features that are specific to those components.

This keeps the skeleton lean and focused on geometry control, while allowing flexibility in the derived parts without overloading the main file.
I hope this clarifies the reasoning behind our workflow. Thanks again for your input!

https://docs.google.com/videos/d/1RuhjroIia_HhMqSt1dJw4kFxTFWF8yB4D-bgnpyHYd0/edit?usp=sharing

[CCarreiras]

OK...

Well, im using 2026 version and it seems to work.
I don't know if it's a case of version, or something we did different (i tried to follow your steps).

[alexander.naljot]

Reply to  CCarreiras:

thank you for sharing your video – it was very detailed and helpful!
I’ve tested this workflow in Inventor 2026 as well, but unfortunately, I’m still experiencing the same issue: model states in derived parts don’t behave as expected when inserted into an assembly.
Could you possibly show how you implemented this with iLogic?
Specifically:

Did you use Select Case statements to switch between different model states?
How did you structure the logic to control the derived bodies per model state?

I’m curious because in my setup, I use Select Case in iLogic to access individual derived bodies and activate/deactivate them per model state. This works perfectly inside the part file, but when I insert the part into an assembly, the model state control does not apply as intended.

Any insight or example code would be greatly appreciated!

Thanks again for your support.

[johnsonshiue]

Hi Alexander,

The behavior does not look right to me. It could be an Inventor API bug or a Model States bug. Please share the files with me directly at [email protected].

I would like to understand the behavior better.

Many thanks

[CCarreiras]

Hi!

@alexander.naljot I did the same process as you, closer as possible... similar iLogic rule (first part of the video)

It works at some level....  (midle part of the video)

but it's not yet a stable process: What i notice is, i have to force the derive part and save it, to be able to use it correctly later in the assembly.(final part of video)

So, is not a secure process now, because it looses the connection easily, and we have to force again to work well in assembly

 

@johnsonshiue probably this can be fixed

@alexander.naljot , can you share your test files to have a try in 2025 and 2026 version?

[alexander.naljot]

Hi  CCarreiras,
thank you so much for your quick response and for sharing your video – it was very helpful!

I will send you my files shortly. After watching your video, I noticed that you used the same workflow as I did. However, in your assembly example, you only inserted one part with different model states.

Could you please try inserting multiple derived parts into the same assembly and then switch between different model states? I’m quite sure this will not work as expected.

In the meantime, I have also tested this in Inventor 2026, and the issue persists – the same behavior occurs. This makes me think it might actually be a bug.

Thank you again for your support! I really appreciate your help!

[CCarreiras]

@alexander.naljot 

Adding several instances of the same part... kind of works...

[alexander.naljot]

Hi CCarreiras,
thank you very much for your quick response and for the detailed video – it clearly shows that everything works smoothly on your side.

It seems this might actually be a bug in Inventor 2025. The strange thing about this is, Yesterday I tested the same workflow in Inventor 2026 on Beta Tester platform and encountered the exact same issue.

Could you please share your files as well?

Thanks again for your help – I really appreciate it!

[CCarreiras]

Another test...
Two different derived parts, with several instances.

After forcing the derived part... it start to work smoothly..

I will try with your files in version 25 and 26...

[CCarreiras]

My test files in 2026 version attached.

[CCarreiras · Accepted solution]

To rule out the problem... Did my files work?

Your files can work after force the derived part (in version 2025, which has similar behaviour in 2026):

What i mean by "force the derive part"?!

- First, the derived part model states doesn't work in assembly... but...

...If a change the model state it the assembly, and then go to the derive part and activate the same model state and save, it will update in the assembly, and keep working.

- Do the same for each model state: Change in the assembly, go to the derived part and select the same model state and save.

Instead of big explanation, here is a video with the workflow:

Your files in version 2025 working (at least in my pc).

Try them a see if they still working... or you need to "force the derived part" again (if so, the workflow is not secure to use in a big scale)

@johnsonshiue probably there's a room to enhance this workflow.

[alexander.naljot]

Hi CCarreiras,
I tested your workflow in Inventor 2025 and 2026 on(https://feedback.autodesk.com/)  using both my parts and your shared parts, and everything works perfectly following your method.
Thank you so much for your help – I really appreciate it.

[johnsonshiue · Accepted solution]

Hi Folks,

Alexander did share the files with me.  While I am still trying to understand the issue, I think I know the reason why it behaves this way. The behavior he was looking for isn’t supported by Model States yet. It is because Model States does not allow the user to configure Derive. You may derive from a given Model State. But you cannot drive such relationship within the derived part.

To overcome the deficiency, an iLogic rule was added to force the Model State to update on a per Model State member basis. This is not a good idea. iLogic rule should only be used to modify properties or parameters or features applying to all members (factory edit scope). If an iLogic rule modifies member specific properties, it is like attempting to modify the Model State table, which defeats the purpose of having a Model State table. I don’t think it will work. At least, this is not how iLogic should be used in a part with non-Primary Model States.

Instead of trying to change the derive source, there is a simple workflow to fulfill the requirements. Try using Delete Face command with Heal option checked (Modify -> expand it -> Delete Face) and select each lump. In this case, there will be three Delete Face features (one for each of the body). Then suppress/unsuppress the ones to fit the need.

Please try it out and see if it works better.

Thanks again!

[alexander.naljot]

Hi  johnsonshiue,
thank you very much for your quick response! I already tried your suggested workflow, and it works as you described.

However, as you correctly pointed out, the main issue remains: in derived parts, I cannot access or control individual configurations via model states. This limitation makes it difficult to manage variations efficiently.

I believe this functionality is very important, so I’ve decided to create an idea in Autodesk IdeaStation requesting the ability to access model states or individual bodies in derived parts through model states.

Thank you again for your help – I really appreciate your support!