Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.

Model State - Inventor 2022

admaiora
Mentor

Model State - Inventor 2022

admaiora
Mentor
Mentor

No question this time... Just wow!

So many things unlocked with Model States!

 

Thanks @ChrisMitchell01 and to the dev team.

Great stuff!

Admaiora
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

_____________________________________________________________________________
Facebook | Twitter | Youtube

Reply
5,547 Views
61 Replies
Replies (61)

ChrisMitchell01
Community Manager
Community Manager

Hi Adrian,

 

The real credit here goes to PM/XD/Dev/QA teams who have worked on this diligently, with a real customer focus, for the last couple of years. I'll pass on your Thanks accordingly 🙂

 

We're looking forward to seeing the ingenious ways that Model States are leveraged going forward.

 

Cheers,
Chris



Chris Mitchell
PDMS Customer Engagment Team
Autodesk, Inc.

Paul.Normand
Alumni
Alumni

Thanks for the kind words!

To help you get started using Model States, there are 2 new guided tutorials in the gallery; one for parts, and one for assemblies. Set the filter in All Available GT gallery to Recently Added to float them to the top.

 

Feedback welcome!

 

Cheers,

Paul



Paul Normand
Principal Content Developer/SME
Design Lifecycle and Simulation (DLS)
Autodesk, Inc.

creggo
Enthusiast
Enthusiast

This looks great, cant wait to get 2022 installed and give it try. 

 

We had to give up with iParts as the derived children don't maintain feature patterns which are essential for our assembly building. 

 

Is it fair to say this is a complete replacement for the iParts workflow?

Also, how does the model state instances interact with representations?  eg are the LoD/View settings applied across all instances, or can you define for each instance?

 

Craig

0 Likes

PaulMunford
Community Manager
Community Manager

Hi @creggo We released a blog post today that might help answer some of your questions:

https://blogs.autodesk.com/inventor/2021/03/24/whats-new-2022-model-states/

Model states don't replace iParts (iParts aren't going away) but they can be used to create component families in the same way. The difference is that Model states only have one file to manage (no separate Factory and Member files).

View representations remain global, not per-model state, but there is some overlap. For example - Model States could be used to save different Appearance options (Like View representations) or they could be used to override/supress assembly constraints to show components in different positions (Like Positional representations). 

 

Does that help?

 


Customer Adoption Specialist | Informed Design
Opinions are my own and may not reflect those of my company.
Linkedin 

robertast
Collaborator
Collaborator

I join in thanking the Autodesk team. The ModelState is a great tool that opens up many new possibilities. But what I missed first is the ability to change the solidbody name to respond to the ModelState state.

idea 

creggo
Enthusiast
Enthusiast

Hi @PaulMunford , thanks for that. Excellent blog post - cleared up a lot!

 

 

Will it be possible to take existing iParts and convert, or copy the row data into there own instance? 

Either way, it will serve us greatly to finally have single file configurable parts. Our Vault has a staggering amount of duplicate parts for the smallest of variations.  

 

Cheers,

Craig

0 Likes

swalton
Mentor
Mentor

As I understand it, Vault is only aware of Model States if you use Items.   Otherwise Vault just treats a file with Model States as the master and does not display any information about any of the other model states in the file.

Steve Walton
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


Inventor 2025
Vault Professional 2025

brandon.rodriguezN68U2
Contributor
Contributor

What's the difference between model states and representations for assemblies? 

0 Likes

Paul.Normand
Alumni
Alumni

View and PosReps are unchanged. The chart on this page may help:

 

https://help.autodesk.com/view/INVNTOR/2022/ENU/?guid=GUID-B4BF053A-265D-45A3-9563-DEBCF1D6631B

 

Level of Detail Representations did not impact the BOM/parts list and were strictly a memory management tool. They have been retired. Unlike LOD's, each model state can have unique iProperties and DOES impact the BOM.

If you need separate files that can be managed and released, use iParts/iAssemblies.

If you want a single file, then use Model States.

Cheers,

-Paul



Paul Normand
Principal Content Developer/SME
Design Lifecycle and Simulation (DLS)
Autodesk, Inc.

johnsonshiue
Community Manager
Community Manager

Hi Brandon,

 

On top of what Paul mentioned here, the main difference between Model States and other Reps is in geometry, parameters, and properties. Each Model State can have different geometry (feature suppression or parameter values), different parameter values, and different Properties (mass and most of the iProperties). Instance-level BOM property override (Default vs Reference) is captured. Suppressed component is deducted from the BOM table.

You may document a design in different states without having to create multiple files. Also, the annotations (MBD, 3DA, and Drawing) all react to Model State appropriately.

Many thnaks!

 



Johnson Shiue (johnson.shiue@autodesk.com)
Software Test Engineer

robertast
Collaborator
Collaborator

@johnsonshiue  написал (-а):

Instance-level BOM property override (Default vs Reference) is captured. Suppressed component is deducted from the BOM table.

Are you really responding properly? Will this happen in the future? 😉

Here  

 


 

PaulMunford
Community Manager
Community Manager

@creggo I am not aware of any migration tool for iParts to Model states. You can open the iPart table in excel, so it wouldn't be difficult to copy the row data out, and then copy it back into a model state Excel table.

 


Customer Adoption Specialist | Informed Design
Opinions are my own and may not reflect those of my company.
Linkedin 

mcgyvr
Consultant
Consultant

@PaulMunford wrote:

Model states don't replace iParts (iParts aren't going away) but they can be used to create component families in the same way. The difference is that Model states only have one file to manage (no separate Factory and Member files).


@PaulMunford or others..

iParts/iassy are just staying around to support legacy data right?
Is there any reason to use iparts/iassemblies on new designs other than thats just what a company has done in the past?

Any benefit to iparts/iassy that model states can't currently do?

 

I'd assume that model states will continue to get updates/improvements while iparts/iassemblies are essentially just frozen in time now. 

 



-------------------------------------------------------------------------------------------
Inventor 2023 - Dell Precision 5570

Did you find this reply helpful ? If so please use the Accept Solution button below.
Maybe buy me a beer through Venmo @mcgyvr1269

PaulMunford
Community Manager
Community Manager

@Anonymous iParts are still needed for adding libraries to content center, and because iParts generate individual member files, they can be tracked in Vault (basic) individually*. So there might be a couple of reasons to keep using iParts for your standard components.

I imagine that Model states might replace custom iPart members? I also think that Model states might be more useful for representing components that are adapted during assembly, but that don't have separate part numbers. For example - a plate that is designed to be bent to the required angle during assembly.

 

I expect that there will be uses for model states that we haven't thought of yet - I'll look forward to hearing what you do with them!

*Vault professional can track each model state which has a seperate part number using the Items master, so individual files aren't needed.

 


Customer Adoption Specialist | Informed Design
Opinions are my own and may not reflect those of my company.
Linkedin 

admaiora
Mentor
Mentor

Just 2 points:

The first is important. When you display a Part List in a drawing (and there is a model state with suppressed comps) we see:

 

COMPONENT XX   QTY  0

Componenets with zero qty should be set invisible as defaults

 

The second,

if you use a multibody approach and you have model states with different bodies just make not visible in the Bodies folder the non existent bodies in that Model State.

At the moment if will see all the bodies, visually, in the Bodies Folder.

If I have 10 Model States with 50 bodies teorically present in each model state I will see always 500 bodies in the Bodies Folder, even if they are empy/non-existent.

I see big pontential too in trhe multibody/model state approach

Admaiora
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

_____________________________________________________________________________
Facebook | Twitter | Youtube

0 Likes

admaiora
Mentor
Mentor

@PaulMunford wrote:

@Anonymous iParts are still needed for adding libraries to content center, and because iParts generate individual member files, they can be tracked in Vault (basic) individually*. So there might be a couple of reasons to keep using iParts for your standard components.

I imagine that Model states might replace custom iPart members? I also think that Model states might be more useful for representing components that are adapted during assembly, but that don't have separate part numbers. For example - a plate that is designed to be bent to the required angle during assembly.

 

I expect that there will be uses for model states that we haven't thought of yet - I'll look forward to hearing what you do with them!

*Vault professional can track each model state which has a seperate part number using the Items master, so individual files aren't needed.


Actually Model State are suggested for component (CC) families.

At least it seems from this picture:

 

XE.jpg

Not sure that it cool be (at the moment) possible to pubblish CC as Model State

Admaiora
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

_____________________________________________________________________________
Facebook | Twitter | Youtube

0 Likes

johnsonshiue
Community Manager
Community Manager

Hi @robertast,

 

Yes, I think my statement is correct as of 2022. The BOM property I was talking about was the instance BOM Structure property (Default -Doc Setting vs Reference). This particular property can be configured for any instance in a given Model State. For example, you have Part1:1 and Part1:2. Both roll up in one row since they are the two instances of the same part. Now, for Model State1, Part1:1 can be set to Default BOM Structure, while in Model State2, it can be set to Reference. In this way, Part1:1 will be counted in MS1 but discounted in MS2.

Please note that this is limited to BOM Structure property, not Item Number or Instance Properties, which are not yet supported in Model State.

Many thanks!



Johnson Shiue (johnson.shiue@autodesk.com)
Software Test Engineer

johnsonshiue
Community Manager
Community Manager

Hi Brian,

 

I personally think iPart/iAssembly and Model States are two different things for different purposes. There could be some overlapped. But, the problems they are trying to solve are different. Like I have said repeatedly, iPart/iAssembly were meant for creating library components. The members are individual components and they are clearly defined on the table. Once they are authored, they should be locked up in a library folder without changing frequently. As we have seen, due to lack of Model State-like workflows before, iPart/iAssembly have been leveraged for that purpose. Users can easily get into confusing behaviors: regular vs custom, sick drawing annotations, and incomplete update (out of sync member).

Model State on the other hand is more flexible. First, all the variances are stored within the same file. Second, it can be treated like one component in multiple states (stages) or several components wrapped in one. Updating process is much straight forward. Each state can be documented easily without much rework.

Many thanks!

 



Johnson Shiue (johnson.shiue@autodesk.com)
Software Test Engineer

robertast
Collaborator
Collaborator

I totally agree with @johnsonshiue   ModelState is a new but very great tool and I will have to learn how to use it to my full potential. Many of us will have to replace old thinking...