NX Assemblies is based on the concept of virtual Assemblies. This means that the assembly file is a collection of pointers to the component part files and their positioning data. In such an environment, when you open the assembly file through NX, components shown in the assembly are referred to as the occurrences of the original component part files or the prototypes. An assembly can have multiple occurrences of a given prototype. All the multiple occurrences have a common prototype but exclusive positioning data.

Quite a few KF functions require occurrence hostpointers in order to perform their tasks in the context of the assembly. For Instance:

• ug_body_testInterference()

• ug_getResultOfIntersection()

• ug_body_testContainPoint()

• ug_checkClashBetweenSolids()

• ug_askMinimumDistance()

So far these functions and classes were given indirect access to occurrences, under the guise of "Prototype - Instance Path" pair. In such cases, these functions and classes accepted "Prototype - Instance Path" directly fed by the user or through an Open User Interface Styler application. Consequently, corresponding prototype hostpointer along with the instance path helped to infer the occurrence.

The concept of occurrence simplifies the above phenomena by allowing the users to select occurrences from assemblies using Open User Interface Styler GUIs and pass them on to the above mentioned classes and functions. It should be noted that existing classes and functions that support the "Prototype - Instance Path" concept also accept occurrence hostpointers as well. In addition, the following functions operate on hostpointers:

• ug_isObjectOccurrence()

• ug_askProtoOfOccurrence()

• ug_askOccurrencesOfProto()

• ug_askOCCFrame() 

In addition to these, nx_constraint also accepts occurrence host pointers as discussed in the next section.

The extraction classes such as ug_extract_curve, ug_extract_body etc. can also accept occurrence hostpointers in order to be instantiated. For instance, so far extracted curves were instantiated as:

(child) linked_curve: {class, ug_extract_curve,

File_Name, "Axle",

Object_Name, "Pick",

FromPath, path1:,

ToPath, path2: };

With the introduction of occurrences the "object name" can be the occurrence Hostpointer in which case "Filename" and "From Path" are superfluous and thus can be unspecified. Note that the "ToPath" is required since the occurrence of the work part must be indicated. However in addition to the existing "Xform_Path" this can also be a HostPointer of any occurrence of the work part occurrence. As before the "ToPath" list may be empty but only if there exists a single part occurrence of the work part in the displayed part. As noted previously the occurrence hostpointer must belong to the work part.

The Open User Interface Styler can accept a mask option, “Work_Part_Occurrence”, that indicates that an occurrence hostpointer should be returned rather than a hostpointer to the prototype object when you specify mask option  ”Any_in_Assembly”.

However, an Occurrence Hostpointer only returns if it is a member of the work part. If the work part is not the displayed part, then the Open User Interface Styler does not return occurrence hostpointers. KF can only support the referencing of Occurrence Hostpointers from a rule or attribute when they are both members of the same part. The system will not permit inter part references to occurrence hostpointers.

To summarize, mask option "Any_in_Assembly" enables the selection of occurrences but specification of mask option "Work_Part_Occurrences" indicates that an occurrence hostpointer in the Work Part returns and not the Hostpointer of the prototype object.

For example, suppose there is a selection button on the Open User Interface Styler dialog named "Pick Object". The selection mask is set for curves, edges, "Any_in_Assembly" and "Work_Part_Occurrences". The mode of selection is simple and the "Xform_Path" entry indicates that in the event of an occurrence selected an "Xform_Path" list should be returned. Assume also that the work part and the displayed part are the same.

(list) pick_Mask: { Curve, Edge, Any_in_Assembly, Work_Part_Occurrence};

(list)  pick_Mode: { Simple, Xform_Path};

The pick_object_action list would consist of four entries in the following order:

{ <Occurrence Hostpointer> ,{ Xform_Path }, "part name", "proto name"};

If "Work_Part_Occurrence" was omitted we would have the prototype hostpointer as the first list entry.

From the perspective of these operations on Occurrence Hostpointers, KF system behavior is consistent with that of existing Hostpointer support. Thus any change to a prototype should be reflected in any Instance or Function that references its occurrences via Hostpointer. The existing behavior with respect to deletion of Hostpointers is also preserved. Currently, for example, if I have KF function that references a hostpointer that is subsequently deleted, the hostpointer reference remains and at evaluation time the function will fail. Again this is behavior common across all NX Automation languages.

 #! NX/KF 3.0 
defclass: occ_update (ug_base_part); 
(list parameter) objectOne: ; 
(list parameter) objectTwo: ; 
#+ 
Set the Mask so that Occurrence Hostpointers are Returned 
if the Work Part is the Displayed part. Also Set the Mode 
to ask that an xform_path be returned in the event that an 
occurrence is selected. 
#- 
(list) objectOne_Mask: { Solid, Any_in_Assembly, Work_Part_Occurrence}; 
(list) objectOne_Mode: { Simple}; 
(list) objectTwo_Mask: { Solid, Any_in_Assembly, Work_Part_Occurrence}; 
(list) objectTwo_Mode: { Simple}; 
#+ Fetch the hostpointers and the xforms from the selection lists. 
Note that the object in the xform path list returned by the User Interface 
Styler is a Part Occurrence Object. 
#- 
(any) solid1: nth(1, objectOne:); 
(any) solid2: nth(1, objectTwo:); 
#+ 
Make some simple queries on the Hostpointers 
#- 
(Boolean) is_occ: ug_isObjectOccurrence(solid1:); 
(any) proto: ug_askProtoOfOccurrence(solid1:); 
(List) occ_list: ug_askOccurrencesOfProto(proto:); 
(Frame) transform: ug_askOCCFrame(solid2:); 
#Calculate the minimum distance between occurrences 
(List) min: ug_askMinimumDistance(solid1:, solid2:); 
(Point parameter) cyl_orig: nth(2,min:); 
(Point parameter) cyl_top: nth(3,min:); 
(Vector parameter) cyl_dir: cyl_top: - cyl_orig:; 
(Number Parameter) cyl_height: nth(1,min:); 
#+ 
Create a connector between the two Part Occurrences using 
the two selected solids as the reference geometry. 
#- 
(child) connector: {class, ug_cylinder, 
Diameter, 50; 
Height, cyl_height:; 
Direction,cyl_dir:; 
Origin,cyl_orig:; };