It’s logical to consider that the order of the code in your rule can determine whether it needs to be run twice to complete or not, however there is another cause for this that many people are unaware of and that’s what I’ve decided to cover today.
So, there are two different types of Parameters and they both behave differently which can affect the outcome once a rule has run. The first type we will look at is the most common parameter- the “double click the name in the rule editor” blue parameter.
This parameter does what it needs to all things considered, including updating the rule if you rename the parameter in your model. What makes this Parameter special, however, is it will hold onto a value, and only change to that value when the rule finishes executing.
This characteristic of the blue parameter can cause problems, however.
Let’s examine the small example below.
If I know Frame_Width is 100 when my rule starts, I would expect the code to make the Length of the Horizontal_SHS component 200. But that’s not the case. The reason for that is after changing the Frame_Width to 200, we now know it will hold that value until the rule finishes, then update to 200. As a result, the Frame_width that is used to drive the length of the SHS part is still 100. Running the rule a second time will cause Frame_Width to be the expected 200 and the component will update correctly.
So, that’s a pain. There is however a way around this characteristic, and that’s where our second Parameter type comes in handy.
Enter the Purple and green parameter, technically referred to as a “Dynamic Parameter”. This parameter uses a String indicated by the “Quotation marks” and won’t update on its own if you change the name of the parameter. On the surface they play the same role, however, the dynamic Parameter has an extra trick up its sleeve.
If I was to run the same code but using a dynamic parameter instead of the normal blue parameter, we would get the desired result the first time.
The reason for that is a dynamic Parameter forces the parameter to take the new value as soon as it's set instead of waiting for the end of the rule to distribute the new value. So, after the first line, Frame_Width will be 200, and as a result, the Length of the SHS part will be 200.
If you find your rules need to run twice, check the order of the code in the rule remembering it runs top to bottom followed by what type of parameters are getting the values needed to execute correctly. For those extra tricky cases, combine your checks with the iLogic Logger I detailed in my previous Episode.
With each Inventor release, Autodesk adds new features and abilities in iLogic, so if you’ve been using it for years or considering using iLogic but you’re unsure if it’ll suit your needs, contact us. We provide various iLogic training from the very basics to more tailored courses.
As cybersecurity threats continue to evolve, some of the biggest risks to your organisation might not be obvious. In this month’s IT Bulletin, we shine a light on three critical security concerns that are often underestimated or overlooked entirely. These issues can silently compromise systems, leak data, or be exploited without detection.
The latest updates to Factory Design 2026 bring powerful improvements to connector class creation, workflow efficiency, and overall performance. From a brand-new Connector Class dialogue to enhanced 4K compatibility and stability upgrades, these changes are designed to make your design process faster, smoother, and more intuitive.
Efficiency, accuracy, and innovation are crucial for staying competitive in the industrial landscape of today. Manufacturing and engineering companies face increasing challenges in managing product development, ensuring design accuracy, and optimising workflows. That’s where Computer-Aided Design (CAD) and Product Lifecycle Management (PLM) come into play.