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.
- You’ll learn how to use compound properties to make mass properties of NX CAD models visible on the item revision.
- You’ll learn how forms store their properties. It isn’t like how most objects store their properties.
- You’ll see examples of how to interrogate the data model to figure out how things are put together.
- 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.
If open the form, you’ll see all of the mass properties calculated for the 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
Before 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
Segment 1: Item Revision → UGMASTER
For 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
So that gives us our first segment pair, an IMAN_specification relationship and a UGMASTER object type.
[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
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
But what type of object is ref_list pointing to?
Segment 2, continued: What is the form type?
Okay, 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]
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?
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.
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).
Segment 3: UGMassPropsForm → UGPartMassProps
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 is a string 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.
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.
Defining the Compound Property
Here’s what the actual compound property definition looks like in the 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
- Forms have two associated storage classes.
- The storage class that stores the custom form properties is linked to the form by a
- 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_namesconfigures the display to show us real property names instead of display names
- I would love to hear if anyone does something similar with other types of CAD datasets besides NX.
- You can actually pick
UGMASTERand 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!