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
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 SubIf this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.
Wesley Crihfield
(Not an Autodesk Employee)
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.
Wesley Crihfield
(Not an Autodesk Employee)
@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).
Wesley Crihfield
(Not an Autodesk Employee)
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?
