Assembly updating component parameters

[alikhan.ganayev]

My problem is I'm making a product configuration and many times some features won't update. For example, within a component of the assembly I would write a rule that changes the position of holes depending on the length of the part. The position of the holes will only change if I go to the part and run the rule manually. I don't understand why the parameters can't just update on their own once the length of that part changes. This is the case for multiple components. Would be happy to clarify further. Inventor 2022 / Windows 10.

[WCrihfield]

Product configurations can be complex, with lots of stuff going on, so there are lots of questions that need to be asked/answered first.  Updates within an assembly can be caused (or prevented) by many things.  There is also an 'Application Option' for assemblies called 'Defer update', that may be involved.  If that is checked (turned on), then some automatic updates will not happen, so you must always manually click the update button to see the result/effect of certain changes.  There are too many other possible things to list and go over here.

In the example you mentioned, you created a 'local' iLogic rule within a component, that is supposed to change the position of holes depending on the length of the part.  But then you said that rule will only work when you open that component and manually run that rule.  If you want that rule to automatically run when something happens, you must set certain things up in order to cause that behavior to happen.  There may be multiple ways of accomplishing this behavior, depending on the situation and how other things are set-up.

When you use the unquoted names of 'local' parameters within 'local' rules, that will cause that rule to be triggered to run every time the value of those parameters change within that document.  This is the simplest form of iLogic automation.  The next form of automation is using the Event Triggers dialog (Manage tab > iLogic panel) then dragging the rule's name over under an event name.  Doing this will cause that rule to be ran whenever that event happens.  The next form of automation is when you create your own event handler code to have more control over when the rule will run.  Whichever form of automation you may end up using, that still may not be the end of the story yet, especially when assemblies or drawings may be involved.  The code within that local rule must also be set-up correctly, or it will fail when triggered to run, and that local document is not the 'active' document at that moment.  When you open an assembly, then intend to somehow effect or interact with any of the other components within that assembly, that main assembly will generally remain the 'active' document.  So if a local rule within a component is triggered to run by something that happens at the assembly level, if any line of code in that local rule is attempting to reference or use the 'active' document (for things like iProperties or Parameters), they will be targeting the main assembly, instead of that local document.