Model States and Custom Values

[6.Day.Old.Filet-O-Fish]

I have created an Assembly which will have a handful of Model States which will select components based on the PIPE DIAMETER users select. This already works as expected.

I would also like users to be able to put in their own PIPE LENGTH, which drives one part of the assembly.  This seemed straight forward. I was using CASE to switch between STATES. I added a custom parameter into my assembly. When each CASE is fired, it also runs

	Parameter("SPREADER_BAR_PIPE:1", "Length") = sb_pipe_length

which sets "Length" to the user's parameter. Except I get an error...

"Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))"

Do I need to do something special to part parameters which change when dealing w/ assembiles w/ model states?

**EDIT**

My co-worker ran into this problem on Friday as well, clued me into some weird oversights on how Model States was designed.

I removed Model State from the part which needs custom length, cleaned up code, and it works well now. One big problem though...

I had to avoid user parameters in my iLogic, because it updates the Model States spreadsheets, thus I can't use the built-in 'Forms', and the iLogic snippet forms are too short, not good UI.

Is there ANY WAY to exclude a user parameter from Model States? That would fix everything!!!

Otherwise I feel like we were sold on Model States, and it's nothing more than a trap for our use.

[WCrihfield]

Hi @6.Day.Old.Filet-O-Fish.  No, I do not believe there is a way to specify that you want to exclude one specific UserParameter from being included in all current and future ModelStates.  Generally speaking, if the ModelStates were all created after that one UserParameter already existed, and you did not attempt to change its value while any one ModelState was active after that point, then it should not be included in any of them yet.  However, after that point, if you change its value, that change will likely be recorded by one or more ModelStates, depending on which way you have the MemberEditScope setting at the time the change is made.  Manually, that setting is on the Manage tab, Author panel, and is represented as a drop-down list with 2 possible values ("Edit Factory Scope" or "Edit Member Scope"), but that setting can also be controlled by code (ModelStates.MemberEditScope property, with its value a variation of the MemberEditScopeEnum).  When making parameter changes by code to a file that has more than one ModelState, you usually need to make sure this setting is set the way you want it before making those changes, then if set to the 'Member' variation, you need to make sure you are working with the correct Document/ModelState.

It is often a bit more complicated to deal with some of these things by code when ModelStates are involved, than it used to be before they were involved.  Most things can still be done, but now may require a lot more code than before in certain situations.  If you want to have a Parameter that you are not able to change its value, then you may be able to create a different type of parameter, such as a ReferenceParameter (usually automatically created by 'driven' dimensional constraints in a sketch), or a DerivedParameter (derived into this document from another document, so is greyed out in this document, and only changeable from the other document), or a TableParameter (linked to an Excel file, so greyed out, and only changeable from the Excel file side).  Just some thoughts.

[6.Day.Old.Filet-O-Fish]

I think you solved a big piece of it for me. Just last week I put together a rule for passing data to/from an embedded excel. I could use an embedded excel at the top level assembly to pass values down to lower docs not using model states. I bet I could do it to ones using MS too but would be a bit more involved.

I'm also concerned that at the end of the day our engineers need to export these one-off models. That is going to be the real PITA. Am I going to have to add a MS check/edit into a recursive loop? I don't think I have the grey matter for that.

The acceleration in design itself MS gives can't be ignored. For this one design, using MS I put together my initial design at least 4x faster and w/ 4x fewer parts than having done it traditionally and switching states is near-instant compared w/ how we achieved this before. W our more complicated designs, this could be much larger savings.

[WCrihfield]

Hi @6.Day.Old.Filet-O-Fish.  There is also a new tool to help with this sort of thing, that you may be able to use in the code you posted above.  Within an iLogic rule, there is a new set of settings available for some of the basic iLogic snippets, just for helping us in situations were there may be multiple ModelStates involved.  The following lines of code are just examples of these settings, but are not immediately usable.

'"one to rule them all"
iLogicVb.MemberEditScope = MemberEditScopeEnum.kEditAllMembers
'the rest, for individual control
iProperties.MemberEditScope = MemberEditScopeEnum.kEditAllMembers
Parameter.MemberEditScope = MemberEditScopeEnum.kEditAllMembers
Component.MemberEditScope = MemberEditScopeEnum.kEditAllMembers
Feature.MemberEditScope = MemberEditScopeEnum.kEditAllMembers
Constraint.MemberEditScope = MemberEditScopeEnum.kEditAllMembers
Joint.MemberEditScope = MemberEditScopeEnum.kEditAllMembers

But to be able to use these, you must first create an operating system 'environment variable' named "iLogicAllowMemberEditScope", and set its value to 1.  This lets you specify ahead of time (before using those snippets later in the code), whether you want all or one of these iLogic snippet tools to effect just the active ModelState, or all ModelStates that may be present, when you use them later.  And below are a couple more links that you may find helpful.

ComponentOccurrence.ActiveModelState (Read/Write - String)

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=GUID-418B956A-AC3F-48D8-BEBC-FC28C4B51DA2 

https://forums.autodesk.com/t5/inventor-programming-ilogic/is-quot-master-quot-model-state-name-loca... 

[Frederick_Law]

Factory State and Member State.

It is annoying to remember to set before adding parameters or iproperties.

To clean up the table, edit it manually.

Find the one you want to delete and set it all to same value.

Exit table and save.  Open table again and delete the column(s).

[6.Day.Old.Filet-O-Fish]

@WCrihfield I'm def going to have to look into this more. Thx.

@Frederick_Law The end user for these models isn't always a designer. I need a non-Inventor-savvy engineer to be able to get the model from vault, edit it thru a form, copy/design it fresh w/ the edits, and not have to know about model states or embedded excel files. We solved all this on 500+ part assemblies w/ Inventor 2020 but it was a bear. MS should accelerate a lot of this, but it's gonna take some work to figure it out. If Autodesk Inventor devs here this, adding a way to exclude specific parameters from Model States within the (FX)Parameters menu would fix a LOT of issues.