Limitations

Relations

  • 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.

Parameters and Formulas

  • 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.

Design Tables

When working with design tables in .xls format, the Undo command may not work properly.

Attributes

The Activity and Layer attributes cannot be used in drafting applications.

Rules

  • 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.

Sets of Equations

In set of equations, there is no control of units coherence (like in rule, check, formula).

Macros with Arguments

It is impossible to use the InputBox Visual Basic function in the definition  of macros with arguments on unix. The SelectElement method on Selection object does not work either (on all Operating Systems).

Checks   

The Reframe On command has no effect on Knowledge Advisor Check. Reframe On can be used only on geometrical objects. Knowledge Advisor checks have no geometrical representation. This behavior is consistent with the Reframe On command accessible from the contextual menu. 

Loops

A loop can only generate items in the document it belongs to. So, in the graphic opposite, the loop cannot generate items in Product3.

this restriction applies also to assemblies made up of different parts. A loop located in one of the Parts cannot generate items in another Part of the assembly.

Reactions

  • 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.
  • If you work in a Product which:

    • Contains a Part containing 3 parameters X, Y, and Z.

    • Has 3 parameters A, B, and C.

    • Contains a Design Table driving the parameters A, B, and C

    • Contains a Reaction whose source is A and which executes the following action: X = A, Y = B, and Z = C.
      If you modify the configuration of the Design Table, it is not possible to guarantee the order in which the parameters will be valuated. When the reaction is launched, it is not possible to guarantee that the parameters will have the expected value.

  • 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.

Lists

A list located at the product level can contain items located in the Product itself, and in Parts located below the Product. But a list located in a Part cannot contain items located at the Product level or in another Part.
In the picture opposite, ListProd1 can contain any item located in Product1, Part2 and Part3. ListPart2 can contain items located in Part2 but it cannot contain items located in Part3 or in Product1.

Identical Names

If two elements that can be incorporated within the rules have the same name in the text of the rule itself, there is absolutely no way to differentiate them.

When the highlight in the specification tree is made from the highlight of the text as in the case of the rule syntax check, we search the element by its name in the text from the rule, and we take the first one we find.

If we have, like in the screenshot hereunder, a parameter and a point with the same name (AAA in this example), we have to choose either the parameter or the point.