|
Overview |
A Knowledge Fusion application is defined as the combination of a KF class that has an associated Open User Interface Styler dialog. You can add KF classes without an associated Open User Interface Styler dialog to NX parts using the Add Child Rule option in the KF Navigator. But once the UI is present, the class graduates to become a KF application and is made available in the Applications dialog box.
KF applications can contain almost any kind of content, including NX features. They can be very complex or very simple, but they behave in a very KBE-like way. They are somewhat unique in the context of NX in that they behave in a purely demand-driven manner.
For a large number of KF applications, this behavior provides a very powerful and flexible way to utilize knowledge automation. However, there are times when the application designer really wants to package and deliver knowledge content such that it behaves like a normal history-based feature inside NX. It is for this purpose that Siemens PLM Software provides the %nx_application class — the foundation of the Knowledge Feature.
Knowledge Features can contain almost any content or logic, just like normal KF applications, but a Knowledge Feature has the additional ability to appear in the Part Navigator and update at a particular timestamp during the model update process. This allows a KF programmer to extend the NX data model with KF code, creating custom (and in many cases, highly proprietary) feature types.
These Knowledge Features behave just like any other feature provided by NX, in that they can:
Automatically understand their parent/child relationships relative to other features
Be reordered within all the same bounds as other features
Be suppressed and unsuppressed like other features (including the accompanying automatic suppression/unsuppression of downstream features)
Provide useful feedback to commands like Information→ Feature or the Dependencies pane in the Part Navigator
The key is timestamp behavior. Some Knowledge Fusion applications intentionally exploit the non-sequential, demand-driven nature of true Knowledge Based Engineering, and timestamp behavior would be an extreme limitation. In these situations, a regular Knowledge Fusion application would be most appropriate.
Other Knowledge Fusion applications are more process or analysis-oriented, and do not actually create any persistent objects in a part file. Many such applications fundamentally operate on (or investigate) a model after the update is done. Such applications generally have no need to participate mid-stream in the update itself, and thus a normal Knowledge Fusion application would be most appropriate.
At other times, you may want to embed process or standardization knowledge into the parametric features comprising a particular model. Often this is manifested as a desire to group together (or create in unison) several features as a "superfeature" or "design element" or "archetype". The Knowledge Feature is a very powerful tool when you need to apply the knowledge mid-stream during model update, or if you use the knowledge to coordinate the addition of several features in a specific way.
User-Defined Features are another tool in the NX product that allows modeling features to be grouped, prepared, stored, and reused in new contexts. However, User-Defined Features offer very little ability for complex configuration of features. Also, UDFs always use a system-generated UI.
If no configuration of features is needed (conditional swapping of alternative construction methods, for example) and the system-generated UI is sufficient, then UDFs would be the appropriate tool to use. However, Knowledge Features allow for much more flexible UI possibilities, and can, in fact, be used to simultaneously add, control, coordinate, and configure multiple UDFs in a design, and do so in conjunction with other features as well.
Once you've decided that a Knowledge Feature is the most effective way to approach a problem, use the %nx_application mixin in your code by replacing the reference to "ug_base_part" with "%nx_application". To get the feature-like behavior fully working, you need to tell NX a little bit about how you want this particular function to behave. You use the following attributes to specify certain behaviors and provide NX with the information it needs to treat your Knowledge Feature correctly.
|
icon_name: |
This attribute specifies the name of the icon that displays beside your new feature in the Part Navigator. This icon is a 16 x 16 pixel bitmap (bmp) using up to 256 colors. You can create icons with your icon editor of choice, or even with Microsoft Paint. You can get out-of-the-box NX icons by taking bitmap names from menu (.men) and toolbar (.tbr) files found in the /UGII/menus directory. Warning: UGS does not guarantee the consistency of internal, system bitmap names from release to release. Use them at your own risk. Because this attribute is just a normal KF attribute, the logic in your feature can actually change its display in the navigator if desired. |
|
application_name: |
This attribute is related to the previous one - it specifies the feature name that appears in the Part Navigator. Again, this is specified using a normal KF string attribute, and as such, this name can be changed on the fly to reflect detail that may be useful to the user of your feature. |
|
use_slaves?: |
This attribute specifies whether or not to make child features slaves of this KF application feature. Setting the value of use_slaves?: to TRUE wraps all of the features contained in your Knowledge Features and displays it as one feature in the Part Navigator. It also activates the re-ordering of update based on the specified list of child_order:. If you set the value of use_slaves?: to FALSE, update is based on the KBE derived parent/child relationships. |
|
child_order : |
This list attribute is used to specify the order in which child classes are updated. Without this, NX needs to perform a potentially costly process to sort out the order for the child classes. This attribute is actually used only when the use_slaves?: attribute is set to TRUE. |
|
input_geometries: |
This attribute helps to ensure that the model update order is correct by "unbinding" all objects in this list each time the model updates. Without this, rules may evaluate one step behind the model. Any geometric inputs should be added to this list by attribute name. (Note that this is not the attribute reference chain — the name of the attribute has the final colon removed.) |
|
output_geometries: |
This attribute is similar to the input_geometries: attribute in that all geometric outputs should be added to this list by attribute name, and not by reference chain. By default, this attribute is calculated automatically by recursively collecting the non-feature wireframe geometric output of the Knowledge Feature class. If your Knowledge Feature class contains non-feature wireframe geometric child rules that you do not want to be part of the KF feature (for example construction geometry), then specify this attribute in your KF feature class. Typically, the value for this attribute is an empty list. |
|
values_to_cache: |
Anything referencing the input geometries list needs to be handled if the parent is not alive. This is very important when the input is tied to a feature. If the feature is suppressed from the Part Navigator, the feature needs to handle that. If a reference to input geometries is made to a suppressed feature, the KF feature causes an error. You can use the values_to_cache: attribute to solve the problem. This attribute maintains a cached version of the referencing attribute and uses the cache if the feature is not alive. It is important to realize that NX understands and automatically takes care of the cases in which clear dependencies exist between dependent modeling features. This attribute is only needed in the rare cases where calculations in KF create dependencies that may not be visible to the modeling engine. This attribute is similar to the input_geometries: attribute in that if attributes are added to this attribute, they should be listed by attribute name, and not by reference chain. |
|
value_to_reference: |
If it has been determined that an attribute must be listed in the value_to_cache: attribute, then anywhere that attribute is referenced within the Knowledge Feature, the value of that attribute must be extracted using the value_to_reference: method. This method checks first to see if the parent objects of the attribute are "alive." If so, it calculates the correct new value. If not, it retrieves the last valid value from an array and returns it instead. Note that this method also uses the NAME of the cached attribute, rather than a reference chain. %ask_parent: By default, the parents of the Knowledge Feature are determined from the input_geometries: attribute. However, if the use_slaves?: attribute is set to TRUE, you need to specify this attribute in order to inform NX what possible parents your Knowledge Feature has. This attribute is different than the input_geometries: attribute in that it is a list of attribute references, not attribute names. If your Knowledge Feature consists of multiple levels of KF classes, this attribute should be specified in the top level class only. |
Class and Quantity
Knowledge Features does not solve the issue with class and quantity that depend on geometry. You still need to use the %ug_create_instance mixin class. The can use the %nx_application class and the %ug_create_instance class together and mixed in to the same KF feature class. You would code your KF feature class as needed for the %ug_create_instance mixin and add the attributes described above to make the class behave like an NX feature. The one difference is that instead of specifying a list of child rules in the child_order: attribute, you must list the attributes that call the ug_createInstance function.
Layer Display in the Part Navigator
In some cases, Knowledge Features do not display a layer number in the part navigator like other features.
Until NX 4, each modeling feature was always associated with only one solid or sheet body. Because of this, a unique layer could be identified for the body associated with each feature, and this layer was displayed in the Part Navigator.
Starting with NX 4, certain NX modeling features can produce multiple bodies, and these bodies can potentially end up on different layers. Knowledge Features also have the potential to create multiple bodies (or other geometry) on multiple layers.
In general, if the output_geometries: attribute is empty, then no layer displays in the Part Navigator. If something is specified, then generally the layer of the first entity is displayed.
Booleans
In typical KF classes, it is possible to combine the creation of a solid feature with a boolean operation on another target solid. For example, you can create a cylinder using a ug_cylinder child rule and perform a boolean operation at the same time by specifying a target solid and operation type.
However, within the context of a Knowledge Feature class, it is recommended to separate the feature creation and the boolean operation into separate child rules, for example a ug_cylinder child rule and a ug_boolean child rule. This is because unpredictable results or errors can occur during model update when the two operations are combined in one child rule.
Note:
If a given nx_application class has user-class child rules, we recommend that the user class also be derived from the nx_application class.