- When the input or the output of a relation (parameter, formula, rule,...)
is a constraint parameter, the parameter used by the relation is the
constraint parameter of the reference.
|
- When the user switches to a flexible assembly, the constraints are
instantiated and the parameters of the instance constraint are not driven by
the relation.
|
- When a list is taken at the level of a rule entry, it is necessary
not to call operators on this list will modify this particular list.
If
called, the valuation of the rule is triggered again because the rule is
valuated each time one of its entries is changed. However, it is
possible to use these operators for actions. These operators are not
valuated automatically in this case.
|
- When a list is taken as input of a rule, it is necessary not to call
operators that modify the list (as AddItem, Append, for example).
If
called the evaluation of the rule will be triggered again because the
rule is evaluated each time one of its entries change. However, it is possible to use these operators for actions. Actions
evaluation is never triggered automatically.
|
- The output parameter (the one that is valuated) of a formula cannot be a
publication. The bypass is to use a rule.
|
- If you want to edit a formula located in another document (not the UI
active one) in the Formula editor, a warning is displayed and the formula
editor is grayed out.
|
-
Locked Parameters can be valuated by a formula.
|
- Parameters accuracy ratio is limited to
10e-8 . For example,
a and b are considered as equal if
|a-b| <=
10e-8 * max (|a|,|b|) . Changing a parameter value from a
to b will not be taken into account in this case.
|
- Do not use geometrical features valuated by a formula as the construction
support of sub-elements. Geometry built by
knowledge does not store history of its topology and sometimes you may
encounter problems in updating links.
|
- To add a formula in a relation set which is located at the
user defined location, you need to first create it at root
relation set and then reorder it to required location.
|
- Do not use geometrical features valuated by a rule as the
construction support of sub-elements. Geometry built by knowledge does not
store
history of its topology and sometimes you may encounter problems in updating
links.
|
- The change of graphic properties on geometrical datum
generated by knowledge is not stable.
|
- If you create a rule driving formulas activity, you might encounter
update problems.
|
- If you create a rule driven by a geometrical feature (to valuate a
datum, for example) valuating the activity of this feature, an update
cycle might occur. This cycle will only be detected during an update.
It is recommended not to use the valuation of feature attributes in rules
like PartBody\Pocket.1 .Show = false for example. In this
example, the pocket is an input of the rule and if you write in the same rule
PartBody\Pocket.1\Activity = false , you will get an update
circle since the pocket has an impact on the rule, which has an impact on the
pocket activity which has an impact on the pocket. We recommend that you
create two different rules: one driving the activity of the feature and the
other one driving its attributes.
|
- If you access a feature attribute in a rule, the modification of the
attribute value does not launch a new evaluation of the rule. Only
parameters modifications (parameters available in the Formula editor) launch
a new evaluation of the rule.
|
- If you use geometrical features computed by rules to build
geometry, the selection of faces, and edges may not work
properly.
|
- When a Generative Shape Design datum (point, line, curve, surface, for
example) is valuated by a relation and this relation cannot be properly
valuated, the geometrical output is not in update error, but it keeps its
previous result.
|
- It is highly recommended that you do not copy/paste parameters located
in a given document type to another document type even if
it is supported for Parts > Products. It is not supported in all other cases.
|
- A parameter cannot be an input and an output at the same time in a same
rule.
As an example, it is not possible to do the following:
if MyBoolean == True { ... ... MyBoolean == True }
Knowing that the valuation of rules can be synchronous, this particular type
of operation possibly generates cycles. However, this kind of syntax is authorized when actions are performed
because actions are started only one time. This kind of syntax is also
authorized for an action embedded in a reaction because a reaction cannot be
fired while its action is performed.
|
- The list of attributes under the
AttributeModification
event do not react consistently with a defined reaction. When
you select the AttributeModification event, you can
select the name of the attribute on which you want the reaction
to actuate when the attribute is modified. This particular
functionality do not behave consistently. However it has a
predictable behavior on the attributes which are also
parameters.
|
|
- When a reaction is invoked on an update event of an
object, the reaction should not modify the content of this feature to
avoid
cyclic update impact. For e.g. If a reaction is invoked on the update of
a geometrical set that contains a list, if the list is modified by the
reaction the part is never up-to-date.
|