Library file using Model States

[PolemEngineering]

I'm working on a test, where I try to translate the functionality of iParts and iAssemblies to Model States.

We are a project organization that frequently uses library components to achieve a customer-specific end product.

The problem I run into is that when switching between Model States (via Representation...) the document gets dirty.

This is undesirable because I want to use the file with the pre-defined model states as a library file.

So if I place the library file with the last active Model State (that's how it's configured here, I think) in a new, empty assembly. And then save this assembly, then only the assembly file will be saved.
If I switch to a different Model State, followed by a save, Inventor wants to save both the assembly and the library file.
The latter with the text "Write enable (not checked out from Vault), Mass Property Update, Model State Updates".

*Test is with 1 assembly (with 2 Model States) and 1 part (also with 2 Model States). Switching the Model State of the Assembly  also replacing the Model State of the dependent Part. So actually a 2-stage rocket.

Doing the test with only the Part containing the 2 Model States, this problem does not occur.

Is this configurable?

I was very happy with the ability to use Model State dependent iProperties to create x number of Items in the Item Master in Vault. Theoretically, this is much easier to manage. A Model State Factory would be very easy to use in our models. Switching between different variants is then almost as easy as the Change Size of a Content Center member.

[swalton]

To the best of my knowledge, using Inventor 2022 and Vault Pro 2022:

Changing the active model state in a file will dirty the file.  Once the file is dirty, Vault will want to check it out to save any changes. 

Inventor and Vault (with file-based revision control) will still trigger the dirty-checkout-save workflow if the file is in a Vault Library or in a Released state.  The dirty-checkout-save workflow may not be as important if using Item-based security and revision control. 

We have limited our use of Model States partly because of this behavior.   

[BDCollett]

2023.2, changing model states does not dirty the file. 

Either with placing a part with model states in a new assembly and changing the state of said part, changing model states of an assembly, or with linked model states between assembly and part.

Obviously if you add more model states it will be dirty.

[PolemEngineering]

I'm currently using Autodesk Inventor Professional 2023.2. Forgot to mention it. I used to have it in the footer, but this causes confusion with older posts.

Changing Model State in a Part document does indeed not dirty the file, but changing Model State in an Assembly document (which also changes Model State of above mentioned Part) does dirty the Assembly file.

Above is all pre-defined. It seems logical to me that adding new Model States does dirty the file...

Another problem is that the Mass changes to N/A when changing State. Although I just noticed that updating the Physical Properties does not lead to a dirty document.
This requires another test with iLogic-rule on Part Geometry Change or another event.

[BDCollett]

---

@PolemEngineering wrote:

Changing Model State in a Part document does indeed not dirty the file, but changing Model State in an Assembly document (which also changes Model State of above mentioned Part) does dirty the Assembly file.

This does not cause the file to become dirty for me in 2023.2 

Do you have some iLogic that is being triggered to cause this possibly?

---

Another problem is that the Mass changes to N/A when changing State. Although I just noticed that updating the Physical Properties does not lead to a dirty document.
This requires another test with iLogic-rule on Part Geometry Change or another event.

---

This seems to happen with the parts but not the assembly. Which is a little strange and annoying.

[PolemEngineering]

@BDCollett The only iLogic I have is the one triggering the Physical Propeties:

mass = iProperties.Mass

This doesn't make the file become dirty. Even with  a clean document, without any iLogic, the same happens.

[johnsonshiue]

Hi! Let me clarify a bit. The correct answer to the file dirtying on activating a Model State is actually it depends. When you create a Model State in a part or assembly, it is like adding a new geometric representation. As a result, when activating a Model State, the file is dirtied as if you make change to the parameters or suppress a feature. However, if the Model States have been consumed by a drawing (or an assembly), simply activating it does not dirty the file. This is because the Model State has "elaborated" due to consumption, such switching is like opening a file without changing anything. As a result, the file will not be dirtied.

Many thanks!

[PolemEngineering]

I try to understand.

English is not my native language, but what you are describing seems to be exactly what I imagine.

I was under the impression that I could use Model States as an alternative to iParts and iAssemblies.
The first part of your text suggests that it is logical that the file is corrupted become dirty when activating a Model State.
However, the last part (However, if the Model States have been consumed by a drawing (or an assembly),...) suggests that there is a way to make this possible.

Where is my thinking error?

I have 3 files attached: ModelStatePart.ipt (containing a few states), ModelStatesAssembly.iam (Contains a number of States which also controls the State of the part). Both of them suppost to be static library parts. Third document is an project-based assembly in which I want to show/use an instance of ModelStateAssembly.iam. None of these are touched by iLogic or the like.

Switching to another ModelState of ModelStateAssembly.iam (from within Example.iam) results in dirtying the files, see screenshot.

[johnsonshiue · Accepted solution]

Hi! I don't recall saying the files were corrupted. If I did, I was wrong. Was it on a different discussion? I thought the file size increase was caused by corruption.

Certainly, you can leverage a component (part or assembly) with Model States as a library component. To do that, you need to make sure the Model State is elaborated in the file (generating the "member" document within the file). You need to consume the Model States in order to elaborate. One way to do that is to start up a new assembly, place each Model State in the assembly (just as what you were doing) -> Save. Once the Model States are elaborated, you can consume it else where without dirtying the component file itself.

To prove my theory, you can drop the part you attach to a different assembly -> Save. The part will not be dirtied.

Many thanks!

[PolemEngineering]

Corrupted is the wrong term. I meant the file become dirty. I will try to correct this text.

I will try what you suggested. Thanks.

[PolemEngineering]

This seems to work perfectly!
Somewhat labour-intensive, but manageable with use of a cleverly applied iLogic script.

[RajSchmidt]

As I understand the technology, a Model State is just another representation of the model’s geometry stored in the same file. Hence your file size grows with each new state. However, simply creating a new state does not create the actual geometry. This happens only when you switch to that state and save the file.

Maybe that explains your problem: Maybe you created the different states by adding them in the spreadsheet? Then your file is clear. Now you used it in an assembly and activated a state. Only now the geometry is created and your file gets dirty.

A possible solution could be to run through your table once and activate and save each state. Perhaps using some iLogic?

[johnsonshiue]

Hi! Yes, you are right. When the Model State is authored, the actual geometric representation isn't fulfilled, beside the active state. In order to have multiple Model States coexisted, they need to be "generated", like iPart/iAssembly member files. The difference here is that the member "files" are all wrapped within one file.

Many thanks!