With Ilogic switch from Model States [Primary] to Substitutes [1174538]

[michael_janssenCN38L]

Hello dear inventory community.

We are looking for a way to switch the level of detail in the model state using an Ilogic code. (see picture)

We make userparameters (Level of detail) = "Low" and "High"

Would anyone have any suggestions?

Greetings Michael

[WCrihfield]

Hi @michael_janssenCN38L.  Using UserParameter values to control which ModelState is active is not a good idea, because those ModelStates have control over the UserParameters, and each ModelState can have a different value for that same UserParameter.  If you change the value of a UserParameter in one ModelState, then that same UserParameter may have a different value when another ModelState gets activated.

Below is an example of how to find these ModelStates, and how to activate the substitute one.  Some documents may not have any ModelStates, some may only have the one original one, and in those cases, there is no ModelState 'factory' yet.  So, checking how many ModelStates a model document has is often a good first step.  Then, when there are 2 or more ModelStates, the first one is always the Master/Primary one.  However, that first one is not always the 'factory' one.  The factory is simply whichever ModelState is 'active' at that time, when there are 2 or more ModelStates present.

Sub Main
	Dim oADoc As AssemblyDocument = TryCast(ThisDoc.FactoryDocument, Inventor.AssemblyDocument)
	If oADoc Is Nothing Then Return
	Dim oMSs As ModelStates = oADoc.ComponentDefinition.ModelStates
	If oMSs.Count < 2 Then Return
	Dim oPrimaryMS As ModelState = oMSs.Item(1)
	Dim oSubMS1 As ModelState = Nothing
	For Each oMS As ModelState In oMSs
		If oMS.ModelStateType = ModelStateTypeEnum.kSubstituteModelStateType AndAlso _
			oMS.Name = "1174538" Then
			oSubMS1 = oMS
			Exit For
		End If
	Next 'oMS
	If oSubMS1 IsNot Nothing Then oSubMS1.Activate
End Sub

If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.

[michael_janssenCN38L]

The idea behind this is.

We would like to reduce the level of detail of all purchased parts using an ilogic code. (Reducing file size).
So we have the option to change the level of detail if necessary.

If we now want to install the 20 different purchased parts (substitutes), we would like to be able to use an Ilogic code to switch all the different purchased parts with the user parameters = Hig and Low once if necessary.

Hope you understand me?

[michael_janssenCN38L]

I tried your code. First of all, thank you very much for your support.

Here's what happens.
Your code switches to the substitute.
But there is no way to switch from the substitute back to the primary.

Since there is no Ilogic Coce to be found in the Substitutes Modelstate.

[michael_janssenCN38L]

[WCrihfield]

Hi @michael_janssenCN38L.  I am not that familiar with substitute ModelStates, because I never use them at work.  We do use ModelStates, but just not substitute ones.  It sounds like a completely different file is created, and a different document is stored in that file than the one stored within the current file, and when you switch to that substitute ModelState, it switches from referencing the document in the current file, to referencing the document in that other file instead.  And that other file does not have your iLogic rules stored within it.

This seems like a primarily performance based option, rather than a configuration based option.  The primary purpose of the old LODs (LevelOfDetailRepresentations) was to record suppression, which was used to unload documents from Inventor's session memory, for performance reasons, but was later adapted by many for BOM control purposes also.  I avoided LOD's for the most part, due to the restrictions they introduced, and mainly used DVRs (DesignViewRepresentations) and BOMStructure control (Normal, Reference, Purchased, Phantom...) for BOM control.

There is a 'API Sample' for creating an assembly level substitute ModelState, but it is in VBA, instead of iLogic.  I am not sure if that is what you are trying to do by code here, or if you just want to have two regular ModelStates at the assembly level, with one being where the purchased parts are normal, while when the other is active, that makes all the purchased components within the assembly be switched to their own substitute ModelState versions.  If the second option is what you wanted to do, then you would have to create substitute ModelStates within each of those purchased parts, then at the assembly level, set each of those assembly components to that substitute ModelState, and have those assembly component level ModelState settings all recorded on that one normal assembly level ModelState.  That way, when the one assembly level ModelState is active, all the individual purchased components look normal, but when the other assembly level ModelState is active, all the individual purchased components are set to their substitute ModelStates.

[michael_janssenCN38L]

First of all, thank you.

The problem with the model states for me is that the file size almost doubles. That's why I have problems with it mentally.

The substitutes reduce the file size by half. Or am I wrong mentally?

The purpose of the whole thing is to make large assemblies faster. We're trying to get away from buying all the step parts. Build these purchased parts yourself.

Or to put it another way, how do you handle large assemblies in your company?

Greetings Michael

[WCrihfield]

@michael_janssenCN38L.  That makes perfect sense.  You are not wrong to want reduced file sizes, and not wrong about however you want to accomplish that result.  Reduced file size is another way to get better performance.  Less stuff for Inventor to be thinking about at one time, and less stuff being held in its working memory set, equals faster processing, less lag, and happier users.

At our company, some of our assemblies do get pretty large, sometimes many thousands of components.  However, not all of those components need to be present / available at all times while working on the main assembly.  So sometimes we will create one or more custom ModelStates just for recording that we want some of the large sub assemblies to be suppressed.  Then we will have that ModelState active while we work on other aspects of the main assembly that are not directly interacting with those suppressed sub assemblies.  And when we want to be working with those large sub assemblies, we may have a different ModelState active in which some other sub assemblies or components are suppressed.  So, different ModelStates have different areas of the assembly included or not included.  This process does not include any 'substitutes', just suppression of components (and/or features and other things related to the suppressed stuff).  Since there are no substitutes, there are no extra files just for those substitute versions of any of the components.  Seems simpler to me, but then again file size is not really something that we think much about at my company, and suppression along may not actually reduce file size like substitution may, so this is just an opinion.

However, we do use something a bit different than some might.  For instance, some purchased items which are complex in design, and would normally be an assembly, we have created 'resizable', multi-body part documents of, as configuration based template parts.  So, what would normally be an assembly component representing a large, complex sub assembly, is actually an internally configured single part type component, with all most of the same detail as the assembly would have (these will often be seen in product layouts by customers in design reviews, prior to production release).  This may or may not improve performance or reduce file size, but it it super efficient for us, and greatly reduces the number of files being referenced by our main assemblies.

But every company is different, so there is likely no right or wrong way here.  Just what works best for you and your company.  If what you saw in the VBA sample looks like what you want, then we can convert that to iLogic, change what needs to be changed, and try that.  But if the second process that I mentioned sounds more correct then it will be a more complex overall task, and some manual actions may need to be taken first (creating a substitute ModelState for each of the purchased components, within each of those purchased components).

[MjDeck]

Hi @michael_janssenCN38L , I am looking at issues relate to iLogic rules in substitute model states.
Have you resolved your question, or are you still looking for ways to activate different substitutes?

[AndrewHumiston]

Afternoon,

i will echo what Wesley stated. Model states by them selves with not drop the file size. the best way i have found to compare it to is an ipart factory that has all the combinations housed inside one file. so it makes perfect sense when you file size is getting larger.

one trick we use is to create a derived part of large files and then use those in assemblies. switching between states is pretty simple as Wesley outlined above. i don't believe you would gain anything unless you placed the substituted file inside the assembly, as far as saving file size goes. by selecting that state in the substitute tree you are only actively seeing that representation, not that actual substituted file.

hope this helps.

[michael_janssenCN38L]

We solved it differently (hopefully). We created 2 individual iparts. The original construction file (1188003) in (high level) mode. This also contains an ilogic code in which we reduce the ipt in a controlled manner in (low level) mode. From this reduced ipt, we create a new ipt (1195324) using "derive". In this new ipt file, the base model is suppressed. The base model (1188003) is then switched back to the "high" level using ilogic.

Finally, we create an assembly (1195325) and insert the reduced (low level) ipt (1195324) in "Primary mode". Next, we insert the ipt (1188003) (high level) ipt using "Substitute".

We also added work planes and axes as Mounting:1 to Mounting:4. This simplifies the installation of one assembly in another assembly. This can be easily switched on and off using representation.

Hopefully you understand the process.

I would be happy to hear your approval or criticism. The goal is to develop a sensible workflow.

Don't forget that this workflow only makes sense for library parts that are not changed afterwards.

We suspect that purchased parts, which are unfortunately still available in step format, are unnecessarily bloating our assemblies.
Because we install a lot.

For us, getting rid of the substitute in Inventor has the big disadvantage that we cannot bring the parts down in a controlled manner.

I hope you understand my process.

Attached are the files

[AndrewHumiston]

Michael,

that sounds like a good way to do it, a little cumbersome, but i think as you work and use this flow you may end up morphing how things work.

i agree the substitute is a bit of a game changer as its gone now. but Adapt and overcome is the name of the game now.

please feel free to keep me in the loop, i'm interested to see how this work flow works for you. i love to try new things and see what other have come up with.

please DM me as i like to bounce ideas around too.

thanks for following up.