iLogic Code to change between Model State on an Assembly

iLogic Code to change between Model State on an Assembly

frahaman7SKBG
Advocate Advocate
9,665 Views
28 Replies
Message 1 of 29

iLogic Code to change between Model State on an Assembly

frahaman7SKBG
Advocate
Advocate

Hi guys, 

 

I need some help with iLogic. I have an assembly where 8 of the 10 parts are driven by Multi-Body Model State. The source Multi-Body part has multiple Model States with various sizes. I would like to have a form in the Assembly where the user enters the Model state that they want their assembly to corresponding to.

 

From my basic understanding of iLogic, we want the iLogic rule to open all the  8 individual components and change the Multi State to what the user entered in the form. With the help from the post below, I was able to run external rules where the code goes to the individual components and changes the model state. The difficulty I'm having is where I want to incorporate the Form function with user input for the Model State. Currently I'm opening the source code and manually changing the Multi-State name, I would like to change this so the users don't mess around the source code and just uses the Form to change between the Model States. 

 

 

https://forums.autodesk.com/t5/inventor-ilogic-api-vba-forum/change-drive-part-model-stage-using-ilo... 

 

0 Likes
Accepted solutions (2)
9,666 Views
28 Replies
Replies (28)
Message 21 of 29

t_fransman
Advocate
Advocate

Yes all of the files are derived from a skeleton ( mulitbody solid) it is accessing to the table under derived components that is my issue. I will copy design and try it though and let you know if it works. 

0 Likes
Message 22 of 29

t_fransman
Advocate
Advocate

Thank you 

0 Likes
Message 23 of 29

t_fransman
Advocate
Advocate

Sadly this rule has no effect on the parts derived from the mulit-body solid all are still Primary so no effect

 

t_fransman_0-1719499175541.png

 

0 Likes
Message 24 of 29

WCrihfield
Mentor
Mentor

OK.  Was there any error messages?  If not, it may be because I use Try...Catch...End Try statements a lot where something might fail, but since I was in a hurry, I did not incorporate any feedback messages or Log entries on the 'Catch' sides of them in that code example.

 

One thing that comes to mind is the 'IsModifiable' property check just inside my 'ChangeModelStateOfDerivedPart' Sub routine.  If that is False, then it would have just skipped over that document.  This can often be False simply because it is seen as a 'ModelState member', if the component is referencing a model file that has multiple ModelStates in it.  If this is true, then it may be skipping nearly all of them.  There needs to be a better, or more accurate property for checking this type of status.

 

On top of that, I do not believe that if the 'host' part has multiple ModelStates in it, that the currently active ModelState in that 'host' part (the part with the other one derived into it) will record, or have any control over, which ModelState the 'source' part (the part that is being derived into the other) is set to within the derive settings.

 

Does the 'source' part have all the same ModelStates in it that the 'host' part has in it?

 

Would it be OK to include instructions within the code to update the main assembly between where the code works on each component or referenced document?  This can be pretty slow in really large assemblies, but not so bad in smaller ones.  It may be needed though in situations where there are a lot of ModelStates being used in assemblies.  The link below to an online help page describes this situation a little bit, but only provides a very brief example code.

To Modify an Occurrence Parameter with a Model State

 

We may have to start with a smaller, simpler code that you can try running from within the part itself, just to make sure the core code for changing which ModelState the 'derived in' source model is set to within the derive settings is working OK for you.  Once that is established, we can try modifying the custom Sub routine in my code to work around that 'IsModifiable' issue.  Essentially what needs to happen in that code is to get a copy of the existing DerivedPartDefinition object, then change that property value (ActiveModelState), then set that DerivedPartDefinition object back as the new value of DerivedPartComponent.Definition property.  Then probably update the part it is derived into.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes
Message 25 of 29

t_fransman
Advocate
Advocate

no sorry, no error just doesn't do anything at all. 

0 Likes
Message 26 of 29

t_fransman
Advocate
Advocate

yes the skeleton and the assembly have the same names of model states. And it changes the skeleton because it's top level but the derived parts do not change. Even if i put the parts top level they do not change i could have then used view reps to make the weldments though i'd rather not do that.

0 Likes
Message 27 of 29

t_fransman
Advocate
Advocate

""Would it be OK to include instructions within the code to update the main assembly between where the code works on each component or referenced document?  This can be pretty slow in really large assemblies, but not so bad in smaller ones.  It may be needed though in situations where there are a lot of ModelStates being used in assemblies.  The link below to an online help page describes this situation a little bit, but only provides a very brief example code.""

 

 

if it works yes

0 Likes
Message 28 of 29

kwilson_design
Collaborator
Collaborator
@JhoelForshav the code your wrote works great. What if I want to change the model state of each occurrence independently? For example, I place two of the same part files with model states into an assembly, but I want to control the model state of part 1 occurrence separately from part 2 occurrence?
Regards,
Kenny
If this post solved your issue please mark "Accept as Solution". It helps everyone...really!
0 Likes
Message 29 of 29

kwilson_design
Collaborator
Collaborator

@JhoelForshav thanks for the code. It seems to work for most of my components in my assembly, however I am running into an issue with it doing anything for one of my components. The component that uses the "Worm_Gear_Design" multi-value property isn't changing model states at the assembly level. It is built the same method as the other components that do work correctly, so I'm at a loss on why this component is giving me an issue.

 

I put a green check mark next to the components in the browser tree and parameters that are working with the code within the assembly. I put a red X next to the component and parameter that is not working with the code despite it being configured exactly the same way as the other two components that are working fine.

kwilson_design_0-1726762301328.png

 

Here is the code of yours that I modified....

Sub Main

Dim oAsm As AssemblyDocument = ThisDoc.Document
Dim oDef As AssemblyComponentDefinition = oAsm.ComponentDefinition
For Each oOcc As ComponentOccurrence In oDef.Occurrences
	Try
		ChangeState(oOcc, Design)
		Catch
	End Try
	
	Try
		ChangeState(oOcc, Arm_Trial_Dimension)
		Catch
	End Try
	
	Try
		ChangeState(oOcc, Auxiliary_Wheel_Assembly_Design)
		Catch
	End Try
	
	Try
		ChangeState(oOcc, Worm_Gear_Design)
		Catch
	End Try	
	
Next
End Sub
Sub ChangeState(occ As ComponentOccurrence, stateName As String)
	occ.ActiveModelState = stateName
End Sub

 

 

iLogic, Parameters, and Model State for the components...

 

This component works....

kwilson_design_3-1726761728619.png

kwilson_design_4-1726761792573.png

kwilson_design_2-1726761688920.png

 

This component also works....

kwilson_design_6-1726761878185.pngkwilson_design_7-1726761947818.png

kwilson_design_5-1726761847880.png

 

 

Yet is the one that is not working for some reason....

 

kwilson_design_9-1726762020789.pngkwilson_design_10-1726762041204.png

kwilson_design_1-1726761630788.png

 

Any help me figure out the issue would be greatly appreciated!!

Regards,
Kenny
If this post solved your issue please mark "Accept as Solution". It helps everyone...really!
0 Likes