≡ Menu

How To Build a Compound Property to a Form Inside a Dataset

Share the knowledge

Before we begin I want to thank Don Knab of SiOMSystems for his assistance in verifying my work for this post. His help was invaluable. Additionally, his colleague at SiOM, Yogesh Fegade, has recently started his own Teamcenter Blog, which I heartily recommend with my highest recommendation. Go check it out.

How to See Your NX CAD Model’s Mass Properties on Your Item Revision

Yesterday I got an email from somebody I took the Teamcenter 2007 Application Administration class with several years ago. He reminded me that I had showed him how to display the mass properties of an NX model on the Item Revision, using compound properties. I thought that it would make a good post to show how to do it for Teamcenter Unified. In trying to redo it in Teamcenter Unified I quickly discovered that I had forgotten most of what I knew and had to figure it out all over again. So I decided it would be even better to show you how I figured out how to do it. So, here we go.


Here’s what you should get out of this post.

  1. You’ll learn how to use compound properties to make mass properties of NX CAD models visible on the item revision.
  2. You’ll learn how forms store their properties. It isn’t like how most objects store their properties.
  3. You’ll see examples of how to interrogate the data model to figure out how things are put together.
  4. You’ll likely come away with a better understanding of why I prefer to not use forms for my data model customizations.

What are we trying to do?

A standard ability of MCAD applications, like NX, is the ability to calculate properties such as mass. After all, it’s usually useful to know how much something weighs, right? When we put the data into Teamcenter it would be nice to be able to see those properties in TC, without having to open the model in NX. It turns out that Teamcenter already does store the mass properties. The problem is, they’re sort of hidden.

Where does Teamcenter store mass properties?

If you right-click on a UGMASTER dataset and choose Named References, you’ll see several references, including a UGPartMassPropsForm.
Dojo massprop 03

If open the form, you’ll see all of the mass properties calculated for the model.

Calculated Mass Properties for CAD model

[box type=”note”]This only works if mass properties were actually generated at some point for the CAD model, from within NX. Otherwise there won’t be a mass properties form[/box]

We Need a Compound Property

I suppose that’s better than nothing, but I’d like to see the property listed as a property of the item revision itself. If you recall my previous post covering Teamcenter properties, you’ll know that compound properties let us take a property defined on one object and show that same value on another object, as if it was defined on that second object. The trick here is going to be figuring out the path of relations and object types that we need to traverse to get from an item revision down to a particular property on the mass properties form.

Building a Compound Property

Let’s review how we create compound properties. You start by adding a new compound property to an object type, in this case an Item Revision. You then define a series of segments which link the destination object type to the source object type. Each link is a pair of a relation or a reference type and the type of object to be found on the other end of that relation or reference type. Finally, when you get to the object type that actually has the property in question you add a final segment which references that source property.

Setup: Show the Real Property Names

Set TC_display_real_prop_names=1Before we try to create the compound property, I suggest that we should configure Teamcenter to show the real property names for everything, instead of the display names. I find that real property names are less confusing for this type of thing. We can do this by setting the TC_display_real_prop_names preference to 1 and restarting the client.

Defining the Segments

Starting Point: Item Revision

When defining the compound property, we start with the object to which we’re adding the compound property, in this case Item Revision

  • Item Revision

Segment 1: Item Revision → UGMASTER

UGMASTER is attached to Item Revision by a IMAN_specification relationshipFor the first segment we have to figure out which relationship type connects UGMASTERs to Item Revisions. If you select an item revision containing a UGMASTER dataset and look at the Details tab you’ll see that the UGMASTER is attached with an IMAN_specification relationship.

So that gives us our first segment pair, an IMAN_specification relationship and a UGMASTER object type.

  • Item Revision.IMAN_specification

[box type=”info”]I’m splitting the segment definition between two lines because that’s how it will appear when you add the segments to the property definition in the BMIDE.[/box]

Segment 2: UGMASTER → some sort of form

Properties of the UGMASTER We know that the properties are stored in some sort of form that is a named reference of the UGMASTER. But what is a named reference anyhow? What relationship or property defines the list of named references? And what exactly what type of form is it that stores the mass properties?

Let’s take a look at the properties of the UGMASTER dataset itself (right click, view properties). Halfway down you’ll see a property called ref_list. Hey, that sounds sort of like it may have something to do with named references, doesn’t it? And it appears to have three forms and a .prt file attached to it, just like we saw in the named references view earlier. In fact, if you double click on the forms you’ll find that the second one down is in fact the mass properties form.

So now we know that the first half of this segment is a reference called ref_list.

But what type of object is ref_list pointing to?

  • Item Revision.IMAN_specification
    • UGMASTER.ref_list
      • ???

Segment 2, continued: What is the form type?

Property view of Mass Properties FormOkay, so we know how to get to the mass properties form, but what type of form is it, exactly?

To answer that, instead of opening the form, view its properties (right click, view properties). Yes, viewing properties is different from opening the form.

When you do this you can see the type of form listed in the header. It’s a UGMassPropsForm form. So now we can complete this segment.
[box type=”info”]Actually, we already knew the form type from when we had looked at the named references of the dataset earlier, but it’s nice to have a second way of confirming our work.[/box]

  • Item Revision.IMAN_specification
    • UGMASTER.ref_list
      • UGPartMassPropsForm

We’re almost done, Right? (not so fast, skippy)

Up until now things have been fairly straight forward. Now they get a bit trickier.

We have traced a route from the Item Revision, through the UGMASTER, and now we’ve landed on the UGPartMassPropsForm. Since mass is a property of this form we should be able to apply the final segment now and be done, right?

  • Item Revision.IMAN_specification
    • UGMASTER.ref_list
      • UGPartMassPropsForm.mass WRONG!

In preparing this article we did try that and it didn’t work. The result was zero even though the form did have a mass value. Frankly, I think this is worth reporting a PR to GTAC.

Anyways, let’s take a look at the definition of the UGPartMassPropsForm object in the BMIDE.

Definition of UGMassPropsForm

Forms are Secondary Business Objects

Notice the Storage class is Form. Since the storage class has a different name from the business object, we know that this business object is a secondary business object. This means that this form has the same properties as the base class of Form. If we look at the Form business object we’ll see, unsurprisingly, that it does not have any mass properties defined. So, how from where does the UGPartMassPropsForm business object get its mass properties?

Forms have two Storage Classes

To answer that question, look a bit further down. Notice the field called, Form Storage Class. Its value is a storage class called UGPartMassProps (note that it does not end in …Form). This is actually the class where the properties are stored. For reasons long since forgotten, Forms, as originally implemented in iMan, used a second storage class to store their custom properties. The primary storage class for forms, Form, just defines basic attributes common to every type of form — date created, owner, last modification date, etc. It’s this second storage class we need for our compound property.

(Okay, the rumor I’ve heard was that the second storage class was used for performance reason on the ancient hardware on which iMan originally ran. The second storage classes were direct children of POM_object and so, supposedly, look up was faster).

UGPartMassProps Class

Segment 3: UGMassPropsForm → UGPartMassProps

Form Business Object
So how do we get from the form to the UGPartMassProps class?
Let’s take a look at the properties that storage class Form defines. We’ll sort them by the inherited column since the relevant property is most likely defined at this level. To me, there are two that look interesting, form_file and data_file. However, form_file is a string[32] property, so that can’t be the reference we’re looking for. form_file though, is a reference type of property. So that just might be the right one.

Okay, I’ll cut to the chase. It is the right one. But feel free to try some other property if you think that’s a more likely choice.

So now we have our third segment.

  • Item Revision.IMAN_specification
    • UGMASTER.ref_list
      • UGMassPropsForm.data_file
        • UGPartMassProps

Final Segment: mass properties

Now we can finally finish off the compound property. We just have to select the mass property as the final segment.

  • Item Revision.IMAN_specification
    • UGMASTER.ref_list
      • UGMassPropsForm.data_file
        • UGPartMassProps.mass

Defining the Compound Property

Here’s what the actual compound property definition looks like in the BMIDE.

Compound Property in BMIDE

This compound property will show the mass value from the UGPartMassProps form as a property on the item revision itself. Pretty cool, eh? You can use the the same principle to show any of the other mass properties, or any of the properties stored on any of the other forms which are attached as named references. That’s even cooler.


Here are some of the key things we have learned:

  • Named references are attached to Datasets by the ref_list property.
  • Forms have two associated storage classes.
  • The storage class that stores the custom form properties is linked to the form by a data_file property
  • Opening a form is different from viewing the form’s properties. The latter displays information about the form object itself. While the former displays the custom properties the form stores about its parent object.
  • The details view can be used to show you the relationship with which one workspace object is attached to another.
  • The preference TC_display_real_prop_names configures the display to show us real property names instead of display names

Further investigation

  • I would love to hear if anyone does something similar with other types of CAD datasets besides NX.
  • You can actually pick Form instead of UGPartMassPropsForm and Dataset instead of UGMASTER and the compound property will (mostly) still work — I wonder if there is a difference in performance.
    • One exception that Don found was that if the Item Revision had both a UGMASTER and a UGPART dataset attached, both of which had a mass property, then the compound property failed to display any value.
  • I’m curious if there are any plans to do away with the secondary storage classes for forms. I suppose that would could introduce big backward compatibility issues though.

If anyone has any insight to share on these or any other related questions, please share them in the comments below. Thank you!

  • Jeremie FEBURIE

    good post …

    I use compound properties very often.
    In a relational datamodel, it is a huge functionality to display on one place properties from other objects …

    I recommend you to set compound of the deepest level of objects (not on ItemRevision, Form)
    – first reason is that the risk is to display empty value (because of many objects found)
    – second one is to avoid performance issues

    The only thing that miss is that we can’t query on compound properties
    Do you know that it is planned for Teamcenter 10 ?

    • http://plmdojo.com/ Scott Pigman

      Thank you for the comments.

      Your point is well taken about not placing the compound property directly on Item Revision. I chose that for my example simply because I wanted to make the example generic (generic to NX users, anyhow).

      I had heard that TC was going to start supporting more functionality for non-persistant attributes. I’m not sure if that includes runtime properties or not or just compound properties. I believe the Access Rule Tree is also supposed to start supporting these properties. I haven’t heard if that made it into 10 or not (10.0 is out for beta testing now).

      • Jeremie FEBURIE

        The recommendation to set the compound as deeper as possible in the business object hierarchy is not always true.

        Sometimes, businesses need to display the same attribute for all objects whatever their item type..

        In this situation, the best practice is to set it at “ItemRevision” level to avoid setting it for each item type in your datamodel. (maintainability of your TC implementation)
        In your example, if you have NX dataset under all Item whatever their type, you can set it to ItemRevision …

        Regarding Teamcenter 10, we don’t have more details in fact… sometimes, they make some announcements that they don’t respect at the end…

        wait and see in june or july when 10.1 will be released for non beta testers 😉

        • Teamcenter Heretic

          Well, it may seem “easier” to set this type of thing at the root level of the BO, but if you EVER want to change your mind, you may regret doing this.

          Think long and hard about properties and where you place them.

          This is less of an issue with compound/run-time than it is with persistent properties for sure but still worth consideration.

          • Jeremie FEBURIE

            yes, you are completely right … this is the same for persistent , relation and runtime properties

      • Raj

        I am unable to create a run time property on the Item revision Form for NX weight attribute.
        Is it possible to travel from Revision form to Item Revision or till Item Level i.e. Upward movement?

  • Don Knab

    Very nice Scott. I hope you didn’t write that in one breath!

    One other thing to note within NX is the requirement to enable saving of mass property information. File / Options / Save Options / Generate Weight Data. I think that is unselected by default. Unless that is selected, the MassProps form is not created in the Named Refs.

    I also verified what happens if Generate Weight Data is turned off again. It looks like the MassProps form is deleted on the next save after a model change. This was good to see.

    • http://plmdojo.com/ Scott Pigman

      One breath? Ha! Hardly. Although when I started I thought it would be a fairly straightforward and simple little post. Boy, was I wrong!

      Thank you for the additional information, that’s very good to know. Thanks again for your help!

  • limann zerga

    Hi Scott,

    You’ve written : “This only works if mass properties were actually generated at some point for the CAD model, from within NX. Otherwise there won’t be a mass properties form”

    My problem is that I dont know how to generate the mass properties in NX. Could you explain how to do it ?

    Thank you

  • Vivek Shand

    Hi Scott. Thanks a lot for the post. I shall try a similar thing to get mass from CATIA V5 as well.

Optimization WordPress Plugins & Solutions by W3 EDGE