The different types of Parameters
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.
