Model States Retaining Parameter Data After Deletion

[Lewis.Young]

Hi All,

I've come across an issue today which I believe is unwanted behaviour to do with the model state table. If this is by design, then it would be good to understand why.

First I create a constraint between two components in an assembly. In one model state, that constraint has a value of 20mm and in the other model state it's 25mm. Because there is a difference between states, this has automatically created a new column in the model state table editor, with the header of the column showing "d5" (or whatever model parameter name is used for the constraint value). Makes sense so far... I have an existing constraint between existing parts and it's being controlled by the two different values. Great.

Now lets say I delete the constraint. This will automatically purge the d5 parameter (if it's a model parameter, user parameters will persist) that was storing the value, because it's now redundant and not being used by anything. This is normal behaviour as far as I'm concerned. But if I now open up the model state table, there is still a column showing the two different values for that parameter. The header of the column says it's controlling "d5", but if i look in the parameter list, this parameter doesn't exist anymore. This is really confusing, because there's nothing I can see indicating that the model state column is controlling a non-existent parameter.

I could understand if it was a user parameter and still existed in the parameter table, but the persistence of non-existent model parameters in the model state table doesn't make much sense to me. Maybe I'm just missing something... but perhaps there could be a tickbox to auto delete columns of non-existent parameters, or at the least throw out a warning message or highlight the column a different colour? 

[hollypapp65]

It happens all the time.

[johnsonshiue]

Hi Lewis,

The behavior sounds that Inventor does not properly manage the Model States table and delete the obsolete columns accordingly. I have seen such table before but I am not able to reproduce the behavior. Do you have the files that can reproduce the behavior from scratch? If yes, please share them with me directly at [email protected]. I would like to understand it better and see how it can be corrected.

Many thanks!

[Lewis.Young]

Hi @johnsonshiue 

Attached are some test files. If you open up the assembly and delete just the insert constraint, you'll see that the d0 parameter is purged, but its model state column persists. However, at the same time, the Insert:1 suppression column does get purged. Now, if you just delete one of the parts (which in turn auto deletes the constraint), that's even worse. In that scenario, both the Insert:1 & d0 model state columns persist, even though neither of them exist anymore.

I have some larger assemblies where I have about 30 columns of redundant data and the only way I can check if it's safe to delete the column is to manually cross reference every single column with existing constraint names & parameter names. Most of these aren't even created on purpose. Too often I'll place an item into an assembly while I'm in member scope, create a constraint, then adjust that constraint. I then switch to a different model state at some point and realise that silly me, those new parts I placed are now suppressed because I had single member scope when I placed them. So then I unsuppress them in the browser tree. Now if I check the model state table, I will have 2 completely redundant columns, one for the part suppression, both rows saying "Compute". The same for the constraint suppression, both saying compute. And then if the constraint or either part gets deleted, it will give a 3rd redundant column, the parameter value. Obviously this workflow isn't how it should be done, but this is practically what happens when I work fast and realise that I had the wrong member scope active (happens a lot unfortunately...)

I like how the model state table has the tickboxes to highlight member differences. In the example I gave, this works well when you have rows that both say "compute" as it shows that both model states are the same, so the column could safely be deleted. But it would be good if that was taken a step further and there was some indication of columns that are controlling non-existent parameters/constraints.

Thanks!

[hollypapp65]

Open file, edit sketch.  Delete one of the dimension.  Exit sketch.  Edit model State Table.

Attached file is before dimension delete.  IV2023.6

[kacper.suchomski]

Inventor deletes an entry in the table only if the value is overwritten again in all MSs at the same time (by editing the generator range).

Inventor will not delete the table entry when the parameter is deleted, and even if the parameter has the same value in all MSs, if it was set individually.

Yes - this is an old mistake.

@johnsonshiue please look at the video.

Here I have shown the behavior of the Inventor model state parameter table in three work scenarios after changing the parameter value - serial value change, individual value change and parameter (operation) deletion.
In addition to describing the scenario, I undo other operations during blurring so that each case describes an individual, continuous workflow.

[johnsonshiue]

Hi! The behavior also seems to be reproducible on an iPart on Inventor 2015.

Many thanks!

[hollypapp65]

Also in 2026.2.

[sgsherbahn]

This is a huge issue for large assemblies that have multiple linked model states in 2025. If an item is removed from one of the sub-assemblies, missing file errors will come up but no modeling errors after ignoring them. If using vault, inventor will try to find the missing file via vault. 

Depending on the size and complexity of the large assembly, the model performance will be affected. The workflow I have adopted is to purge all model states, to delete the excel document, and rebuild model states.