iLogic Assembly requires multiple update button presses

[Shag_Bore]

Hello, I have the beginning of a large assembly. Right now the assembly has 8 pieces of angle, based on the design requirements, I have created a form that drives Length, Height and Width. There is a dummy part file that holds the parameters and then linked to the parts inside the assembly. 

The angle lengths, position and suppression change based on the 3 driving parameters.  I have managed to write the rules to make the assembly work, but I have noticed that I sometimes need to press update button on the form multiple times to ensure the changes update. This isn't really an issue right now, but I only have 8 parts in the assembly, if I have 200, will it still only be  a few clicks or will it amplify and how will I know when the assembly is fully updated? I am not a programmer, so I assume the reason for multiple update clicks is because of my ilogic rule syntax. 

Here is a picture of the assembly and form:

Here is the rule in the assembly that suppresses the parts based on the form inputs. 

'LINKED ASSEMBLY USER PARAMETERS TO PARAMETERS DUMMY FILE
Parameter("PARAMETER_FILE", "LINKED_HEIGHT") = CANOPY_HEIGHT
Parameter("PARAMETER_FILE", "LINKED_WIDTH") = CANOPY_WIDTH
Parameter("PARAMETER_FILE", "LINKED_LENGTH") = CANOPY_LENGTH

'SUPPRESS PARTS BASED ON MASTER PARAMETERS
If LINKED_LENGTH <= 245 Then
Component.IsActive("SIDE_A_ANGLE2_TOP")=False
Component.IsActive("SIDE_A_ANGLE3_TOP")=False
Component.IsActive("SIDE_A_ANGLE4_TOP")=False
Component.IsActive("SIDE_A_ANGLE6_BOTTOM")=False
Component.IsActive("SIDE_A_ANGLE7_BOTTOM")=False
Component.IsActive("SIDE_A_ANGLE8_BOTTOM")=False
Else
Component.IsActive("SIDE_A_ANGLE2_TOP")=True
Component.IsActive("SIDE_A_ANGLE3_TOP")=True
Component.IsActive("SIDE_A_ANGLE4_TOP")=True
Component.IsActive("SIDE_A_ANGLE6_BOTTOM")=True
Component.IsActive("SIDE_A_ANGLE7_BOTTOM")=True
Component.IsActive("SIDE_A_ANGLE8_BOTTOM")=True
End If

If LINKED_LENGTH <= 473 Then
Component.IsActive("SIDE_A_ANGLE3_TOP")=False
Component.IsActive("SIDE_A_ANGLE4_TOP")=False
Component.IsActive("SIDE_A_ANGLE7_BOTTOM")=False
Component.IsActive("SIDE_A_ANGLE8_BOTTOM")=False
Else
Component.IsActive("SIDE_A_ANGLE3_TOP")=True
Component.IsActive("SIDE_A_ANGLE4_TOP")=True
Component.IsActive("SIDE_A_ANGLE7_BOTTOM")=True
Component.IsActive("SIDE_A_ANGLE8_BOTTOM")=True
End If
iLogicVb.UpdateWhenDone = True

Here is a rule from one of the angle parts, they are all written roughly the same way, just have different lengths.

'length requires only one angle, unsuppress miter2 to ensure both ends are mitered
If LINKED_LENGTH <= 245 Then
Feature.IsActive("MITER2")=True
LENGTH = LINKED_LENGTH+ANGLES_OFFSET*2+6
'length requires 2 angles with second angle set to 36" for splice
ElseIf LINKED_LENGTH <= 284.5 Then
Feature.IsActive("MITER2")=False
LENGTH = LINKED_LENGTH-36+4
'length requires 2 angles, angle one is full length, second angle > than 36"
ElseIf LINKED_LENGTH <= 383 Then
Feature.IsActive("MITER2")=False
LENGTH =252
'length requires 2 angles, split evenly up to 40 feet max
ElseIf LINKED_LENGTH <= 473 Then
Feature.IsActive("MITER2")=False
LENGTH = LINKED_LENGTH/2+3.5
'length requires 4 angles, 2 sections, each section has small angle set to 36" for splice
ElseIf LINKED_LENGTH <= 569 Then
Feature.IsActive("MITER2")=False
LENGTH =  ((LINKED_LENGTH+7)/2)-36
'length requires 4 angles, 2 equal sections, second angle on each section > 36"
ElseIf LINKED_LENGTH > 569 Then
Feature.IsActive("MITER2")=False
LENGTH = 252
End If
InventorVb.DocumentUpdate()

  thanks

Sean

[WCrihfield]

Hi @Shag_Bore.  This situation will be pretty difficult to diagnose remotely, but I will try to help a bit with the code you posted, to see if a few minor changes might improve performance.  In your first code, before those 3 lines of code using the 'Parameter()' snippet...add a line of code just before them, like the following:

Parameter.UpdateAfterChange = True

That will cause a document update after each following Parameter() snippet line, to make sure the change has taken place, before proceeding.  And the last line of code you are using is really meant to be used at the start of (or before the end of) a rule, as a preparation.  It is not used for causing an immediate document update where it is used.  The last line of your second rule is the normal iLogic snippet for causing an immediate document update.  However, you may notice that, like many of the iLogic shortcut snippets, those lines of code to not indicate or let you specify which document they will act upon.  I believe that if they are used within an internal (not External) rule, then they will default to targeting the document that the rule is saved within, not necessarily any documents being referenced by an active assembly.  So, you may need to specifically force the document holding your linked parameters to update, after those lines of code that are for changing their values.  That can not be done with one of those simple iLogic snippets though.  You may want to get a direct reference to that Document object, then use its Document.Update2(True) method, just to be more secure about it.

As for the Component.IsActive() snippet lines in your first rule (and the Feature.IsActive() snippet lines in your second rule), the 'IsActive' term basically means 'Suppressed = False'.  And when suppressing or unsuppressing multiple things in a series, the sequence in which you do those is usually very important.   They usually need to be suppressed in one specific order, then unsuppressed in the opposite order.  This is primarily due to dependencies.  If component or feature X depends on component or feature Y, then you can not suppress Y before suppressing X...and similarly you can not unsuppress X before unsuppressing Y.  Sometimes when performing those actions in the wrong order, it may throw errors, but it may not always do so.

[Shag_Bore]

---

@WCrihfield wrote:

You may want to get a direct reference to that Document object, then use its Document.Update2(True) method, just to be more secure about it.

---

 Hey @WCrihfield , thanks for taking a look, if I understand correctly, I should use the Document.Update2(True) method to take the values I input in the form, make sure the parameter dummy file updates, then allow the individual parts to be updated?

---

As for the Component.IsActive() snippet lines in your first rule (and the Feature.IsActive() snippet lines in your second rule), the 'IsActive' term basically means 'Suppressed = False'.  And when suppressing or unsuppressing multiple things in a series, the sequence in which you do those is usually very important.   They usually need to be suppressed in one specific order, then unsuppressed in the opposite order.  This is primarily due to dependencies.  If component or feature X depends on component or feature Y, then you can not suppress Y before suppressing X...and similarly you can not unsuppress X before unsuppressing Y.  Sometimes when performing those actions in the wrong order, it may throw errors, but it may not always do so.

---

I have taken this into account, every part in the assembly is dependent only on the master height, length, width parameters. The parts are not dependent on other parts, ie. constrained to each other. The parts are fully constrained to the origin.

attached is a very basic example of what I am constructing. I haven't fully developed it to work smaller than 120" or larger than 624" as those are not needed for my design. Any parameters in between should adjust the angles and acm panels accordingly.   

Have a look, it feels clunky, again, I am sure it is because of how I have written the rules and the sequencing of what updates first, as you have said.

Thanks!

[Mathias_CompC]

TL;DR

Try not relying on rules in components to update the component in question when in an assembly environment. Rules in Components * many = sluggish and errorish.

This is quite similar to a model I've made that produces a "box" for angles and square tubing. I don't think I've written any iLogic assemblies with rules in parts that need to execute for the assembly to function since... a long time ago with a few very large ones as an exception. One issue I had that is similar to yours is most often related to rules in children or other dependant rules not firing at the correct time. My model in question looks something like the attached picture.

Instead of feature control in the respective part and exchanging parts via suppression I control the active state of the part feature from the main "placeable" assembly like:

ThisApplication.SilentOperation = True
ThisApplication.ScreenUpdating = False

'A bunch of stuff

If PartA_Bool = True
	Feature.IsActive("PartB", "Chamfer2") = True
	Constraint.IsActive("BA_ChamferConstaraint:1") = True
	Constraint.IsActive("B_EndConstraint:1") = False
	Component.IsActive("PartA") = True
	Logger.Info("Part {0} has been removed", PartA_Identifier) 
Else
	'Reverse
End If

'More stuff

'Finally and on Error:
Logger.Info("Rule [0} {1} with {2} errors. Log at {3}", RuleName, SuccessTracker, ErrorCounter, LogFile)

ThisApplication.SilentOperation = False
ThisApplication.ScreenUpdating = True
InventorVb.DocumentUpdate()

In many of our assemblies I've completely stopped using suppression of components, and I dont think I would suggest anyone to design in a way that requires ModelStates in Inv-2021. We will soon(tm) upgrade to 2023 and when we do I have a "short" list of models to go over and check them for iLogic functionality, mainly but not only regarding references to its own document as there appears to be a significant restructuring of the references to itself more akin to iParts/iAssemblies, but I hope it will go smoothly. 

What I meant with that was, that I've really liked working with "ThisAssembly.BeginManage" and then actually added/removed the components in the assembly. Everything is quicker, more reliable, and less bloaty.

[Shag_Bore]

---

@Mathias_CompC wrote:

In many of our assemblies I've completely stopped using suppression of components, and I dont think I would suggest anyone to design in a way that requires ModelStates in Inv-2021. We will soon(tm) upgrade t

---

I am pretty sure this is he ultimate solution to my issues, but as of right now 2016 doesn't support model states, and there are many more ilgoic snippets that would be useful also in 2024 version.

thanks for the reply, for some reason I didn't think I could control the part features in the assembly level. I am almost done the current model, but for the next variation of the model, I will try your rule method.

Thanks! @Mathias_CompC 

[WCrihfield]

Hi @Shag_Bore.  Attached is a text file containing an alternate version of the original rule you posted here, but this version is done using primarily Inventor API code, instead of those iLogic shortcut snippets.  The only truly iLogic code in it is the 'ThisDoc.Document' phrase.  I have not tested this yet though, since I don't have your data set.  I also created a separate Sub routine that should work very similarly to the iLogic snippet 'Component.IsActive()', but shows you most of the code that gets ran in the background every time you use one of those shortcut snippets.  I included 4 lines of code for updating documents, but left 1 line (line 15) commented out for now.  That line of code calls the Rebuild2 method on the main assembly, which forces all entities within the assemblies scope to be computed again, even if they may not need it.  That can sometimes accomplish what a normal Update2 method will not, but it is also usually more costly in performance, so there is a trade-off.  Just thinking hypothetically about this situation...if the main assembly itself does not know that some components parameters are laterally linked to each other, then it would not know that they need to be updated when the source file' parameters have changed, if the source file does not even contain any geometry that would change as a result of the changed parameter values.  Just thinking that maybe the Rebuild tool may help get around that hurdle, but I am not sure.  And sometimes doing stuff the long way helps you understand the details of what's going on with more clarity.

[Shag_Bore]

Hey @WCrihfield ,

I  will save this rule for the next iteration on the model as I am sure it is the better way to automate it. I have spent quite some time writing out the rules and the current model is working and updating well. As @Mathias_CompC suggested, I made all the changes to the parts happen in the assembly level and not at the part level. I broke the main rule down in the assembly into multiple rules to update each type of part. Right now, the parts update without having to press the update button repeatedly. 

I do have one more semi-related question, in my form, when I change any parameter, the assembly updates immediately in between parameter changes, is there a way for me to be able to change all three parameters then press update and update the assembly all at once? What I mean is, when I change the length in the form, then jump to the width input box, the assembly starts to update and rebuild before I can change both parameters.

Thanks!

[WCrihfield]

Well, the first thing that comes to mind is the difference in behavior between an internal iLogic form, and a global iLogic form.  When using an internal one, the model will react instantly to changes made in the form.  But in global iLogic forms, since there is no 'local' document, there is a disconnect, and changes made in the form will not take effect until you click the Apply button, which 'sends' the changes to the document that was 'active' (showing on the screen) when that global form was launched.  And if you include a button in the form for running an internal iLogic rule, there will be a setting for that button called "On Click Action" (not available when the rule is external), and in its multiple options, you will usually want to choose an option which includes the Apply command, before running the rule.  So, if using a global form, you would most likely be able to make multiple changes, then click Apply while the form remains open, then make more changes if needed before clicking Apply again and/or clicking OK or Done.