iAssembly vs Modelstates?

[mchi_topsoe]

Now when Autodesk have introduced Modelstates, are people still using iAssemblies/iParts?

It looks like ModelStates can do pretty much the same with an embedded Excel Sheet.

We are looking at implementing Variant management in our product lines, and mapping Parts to the Item Master. It looks like both methods can suffice the need. Any reason to choose one over the other?

[Gabriel_Watson]

The Model States approach can bloat a single file if you are dealing with too much data or too many variants. However, it is a lot more straightforward to manage in a Vault folder structure, and to auto-assign multiple items to a single file's Model States, rather than have to select many files to items:
https://help.autodesk.com/view/VAULT/2024/ENU/?guid=GUID-A6C34246-4C97-4EC9-B3CD-79B4DCB68A52

Model states allow you, for example, to define variants in pairs, where 2+ can share the same part number and thus the same item (for example, if one model state represents an earlier/inventoried part, but it can be considered the same as the new builds).

P.S.: Lastly, model states might be way way easier to copy design... since iAssemblies/iParts are a bit of a pain and exception.

[Frederick_Law]

Do a test.

ModelState interface is easier to change member in assembly.

ModelState is slow on check in.

Still "new" and got a few problems.

iPart, iAssembly will get bloated also.

Vault is not 100% working with ModelState yet.  Can't view different Modelstates.

Browser Tree only show ModelState file name.  ModelState name is shown in () but may not show in export.

I just wrote iLogic to rename browser to ModelState part number.

[mluterman]

The only thing that really screwed me up with Model States in an assembly is the fact that you can/will have "extra constraints" for each model state for the same items. I never realized that until I was "suddenly" able to move items around. Then I had to rethink all of it. Next time, I will only use Model States at the part level and ViewReps at the assembly level. (but Model States do help when generating parts lists where you can hide suppressed items for each Model State and have separate parts lists for each).

[Frederick_Law]

Yes, I have ModelState assembly with parts assemble at different location in different ModelState.

Not a pos rep.  Think shelve at different location in cabinet.

I use pos rep mostly on door Open, Close.

Also need to be careful on "Factory Scope" and "Member Scope".

[IgorMir]

I use iAssemblies and iParts. I got absolutely no problems with using them. They are efficient and relatively easy to manage.
Best Regards,

Igor.

---

@mchi_topsoe wrote:

Now when Autodesk have introduced Modelstates, are people still using iAssemblies/iParts?

It looks like ModelStates can do pretty much the same with an embedded Excel Sheet.

We are looking at implementing Variant management in our product lines, and mapping Parts to the Item Master. It looks like both methods can suffice the need. Any reason to choose one over the other?

---

[johnsonshiue · Accepted solution]

Hi! This is an interesting question. In general, Model States offers better documentation experience. You may annotate the drawing views for one variant. The drawing views for other variants can be easily done by copying and pasting the sheet and activate the particular variant. The same workflow on iAssembly/iPart may lead to missing or sick annotations more easily and rework would be necessary.

Depending on the original source file size (iam/ipt) before converting to Model States, the assembly/part file may become very big when more variants are added, because those states are individual member files stored inside the iam/ipt file. iAssembly/iPart don't have the same behavior since each member is a distinct member iam/ipt file.

Many thanks!

[IgorMir]

Hi Johnson,

And why is it "less convenient" documenting iParts comparing to documenting the Model States? The process is absolutely identical. The drawing is Saved As and a new version of an iPart is selected for the base view.  All the information, pertaining to the new child documented - gets updated.
Depending on the complexity of the new child there might be some sick dimensions to look after. Which is not a big deal. Besides, I think the Model State will have the same issues too. For example - if the first iPart child is of a rectangular shape and the second is a round one - will the dimensions stay attached to all the geometry, once the different model state is selected?
Cheers,

Igor.

---

@johnsonshiue wrote:

Hi! This is an interesting question. In general, Model States offers better documentation experience. You may annotate the drawing views for one variant. The drawing views for other variants can be easily done by copying and pasting the sheet and activate the particular variant. The same workflow on iAssembly/iPart may lead to missing or sick annotations more easily and rework would be necessary.

Depending on the original source file size (iam/ipt) before converting to Model States, the assembly/part file may become very big when more variants are added, because those states are individual member files stored inside the iam/ipt file. iAssembly/iPart don't have the same behavior since each member is a distinct member iam/ipt file.

Many thanks!

---

[mchi_topsoe]

It seems there is no real difference between the two methods in terms of functionality. But what about PDM/PLM. If one cad part represents one Part in PLM. It can be tricky to work with change management.

[IgorMir]

Hi Michael,
Can't really comment in depth on this one. The way I manage files is fairly solid and doesn't give me any grief. 

But then again - other companies might have different requirements for their file management. I don't think - there is a silver bullet to nail it all. I, for one - put human's logic and common sense as a highest priority in anything I deal with. 

It works for me. 🙂
Cheers,

Igor.

---

@mchi_topsoe wrote:

It seems there is no real difference between the two methods in terms of functionality. But what about PDM/PLM. If one cad part represents one Part in PLM. It can be tricky to work with change management.

---

[johnsonshiue]

Hi Igor,

The iPart member files are individual ipt files. So when the annotations are attached to a drawing view of an iPart member, they may lose association when the view is changed to a different member. This issue is less problematic with Model States where all members are wrapped within a file.

Another advantage of using Model States is that the features and parameters are recognized. For iParts, besides Holes and Threads, none of the parametric features are recognized in retrieving model dimension or feature-based component pattern for example.

Many thanks!

[IgorMir]

Hi Johnson,

Thanks for the comment, always appreciated!
But the question of mine still stands. If the shape of the model changes dramatically (from flat to round, as it was discussed in another topic a few days ago) - will view dimensions loose its associations with the model?
As for the feature based component pattern recognition - it is a bonus, of course. In a mean time I have to link parameters to the assembly when dealing with the iParts patterns. Fortunately - I don't have to do it too often. 🙂
Cheers,

Igor.

---

@johnsonshiue wrote:

Hi Igor,

The iPart member files are individual ipt files. So when the annotations are attached to a drawing view of an iPart member, they may lose association when the view is changed to a different member. This issue is less problematic with Model States where all members are wrapped within a file.

Another advantage of using Model States is that the features and parameters are recognized. For iParts, besides Holes and Threads, none of the parametric features are recognized in retrieving model dimension or feature-based component pattern for example.

Many thanks!

---

[Frederick_Law]

---

@IgorMir wrote:

If the shape of the model changes dramatically (from flat to round, as it was discussed in another topic a few days ago) - will view dimensions loose its associations with the model?

---

Yes, it will.

Because most likely they use different sketch.

With iPart, user define which feature and parameter are added to table.

ModelState will capture any changes and add them to table.

[IgorMir]

The sketch can be a shared one. Hence - using the same geometry for both version of the part.

The dimensions will get disassociated due to different topology of the solid objects. At least - I think so. 🙂
Cheers,

Igor.

---

@Frederick_Law wrote:

---

@IgorMir wrote:

If the shape of the model changes dramatically (from flat to round, as it was discussed in another topic a few days ago) - will view dimensions loose its associations with the model?

---

Yes, it will.

Because most likely they use different sketch.

With iPart, user define which feature and parameter are added to table.

ModelState will capture any changes and add them to table.

---

[Frederick_Law]

Think different shape washer/spacer with through hole or tap hole.

A series of square, round, triangle, hex washers.  All fit in same circle.

Drawing won't pickup dimensions for each shape but hole note will work for the hole.

Technically, all the parts in a machine can be model in one ipt with modelstate.

Not that I'll recommend that 😜

[ivan_rados]

I was just looking to find the best solution Model States vs iPart/iAssembly before I start to go in the Design direction since it is a company path direction.

Saving to Vault is an important consideration for me so right now the only question is will the Vault be able to handle the requirements of Model States. How many different components, model states or assembly size in regards will the Vault be able to handle decently.

Model States are the obvious choice and since I came across this thread, and I saw this discussion of changing a square to circle and see the dimensions on drawing change decided to give it a try and I was able to put it down on a simple part.

[jimm_motyka_777]

Being our Vault Administrator, I prefer MS items. We are slowly flipping the old iParts and iAssemblies to MS items "as needed".  On the admin side, MS parts and assemblies have been much easier to work with and manage within Vault.