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.

Objectives

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.

I know I should lay off the BMIDE, but I have another complaint suggestion.

As you probably know a BMIDE data model has lots of dependencies and most of those dependencies exist within the data model itself. For example, a property may have a naming rule attached, and that naming rule may depend on a List of Values (LOV). The property, naming rule, and LOV all exist within the data model.

But data models also contain external dependencies. These are dependencies on things that aren’t in the data model. They are expected to be defined in the Teamcenter instance before the data model is deployed. And those are the problem.

I’ve spent a lot of time working with Teamcenter’s BMIDE over the past year. When I use a tool a lot I start thinking of ways to improve it. So I thought I’d share a few of the ideas that I’ve had. None of these would require changes to Teamcenter itself. These are all simply changes to the BMIDE interface. I’m currently using Teamcenter 8.3. I haven’t looked at Teamcenter 9.1 yet, so it is possible that some of these are already available.

I don’t claim that any of these suggestions will revolutionize the BMIDE, but I think they’d improve it for me. Maybe they’d improve it for you too. Please take a look. Give me your opinions on these. Even better, make your own suggestions.

Editing The Data Model

1. Inherit name of compound property source When I create a compound property I usually give it the same name as the source property. The BMIDE should give me the option of automatically inheriting the source property’s name instead of having to manually type it and triple check it to be sure I got it right.
2. Create multiple Compound Properties at once Usually if there’s one property I want to map from one object to another, there’s at least two. After drilling down through the types and relationships to get to the correct source object I should be able to multi-select multiple properties to map at once.

The comments section for my earlier post about icon customization in Teamcenter 9.1, kicked off a discussion between me and The Teamcenter Heretic® about the BMIDE. I think a fair summary of Heretic’s position is that the older command line tools from iMan worked very well and that the BMIDE is overcomplicated and unreliable.

Since a discussion of the BMIDE is probably a topic of interest for many of the Dojo’s visitors I thought it should be promoted into its own post. You can review the earlier post’s discussion to catch up. And now I’ll try to lay out my thoughts on the topic.

Because I like to torture myself by reading what’s new and cool in the latest Teamcenter version, which I likely won’t be able to play with for a long time, I started to read through the What’s New document for Teamcenter 9.1, which you can check out for yourself at GTAC’s website.

One thing that jumped out at me, because we had just been discussing the rigamarole that you currently have go through, was the news that as of TC 9.1, icon configuration will be done directly inside the BMIDE. You no longer will have to create a separate Eclipse project to customize your icons.

From the documentation:

I like the sound of that. I’d much rather have a single BMIDE template to maintain than a template and a separate eclipse project.

Icon Overlays

It goes on to say this, which I think was pretty interesting:

As far as I know this is a new capability (please correct me if I’m wrong). I can think of plenty of uses for icon overlays. A common user request is to make more about an object’s state graphically obvious.

How well does it work?

Okay, the 64,000 dollar question is, has anybody tried this yet? How well does it work? If you’ve had a chance to deploy a TC 9.1 data model that customizes icons, let us know how it went.

Here’s a story about the latest snag we’ve encountered in the process of migrating from Teamcenter Engineering to Teamcenter 8.3.

I’ve got a tip to share today, but frankly, I’m hoping someone out there has a better solution — so if you do, please leave a comment and enlighten me!

Which BMIDE Template Version is Currently Deployed?

One advantage to the new BMIDE way of developing a data model is that the data model now exists as a set of XML files which can be managed with a version control system. It is very useful to be able to track changes to the model over time and to be able to coordinate development with others, however the problem is, how can I tell which BMIDE template version is actually deployed to each specific instance of Teamcenter?

Without the label this would just be a painting of a pipe

Have you ever found yourself talking to a user on the phone who has no idea what a BOM View Revision is, so you end up trying to describe the icon they’re looking for? It’s the one with the three colored boxes that looks a bit like a two pronged fork….

Or how about datasets? Most of them use the generic icon of a gear and the default name is the Item Revision’s ID. There’s nothing like having three objects datasets with the exact same name and icon that you know are actually different types. Oh, and those two that do have custom icons — you can’t remember what the icons mean.

Yes, A picture is worth a thousand words, as the saying goes. But sometimes a few words would be a lot more useful. So today, if you’re using Teamcenter 8.1 or higher, we’ve got a tip for you to add a few descriptive words to your Teamcenter interface to make things a bit more clear. And best of all, you don’t have to write any custom code to do it.

One of the things in my current to-do list was to figure out how to display a LOV value along with it’s description. For example, If I wanted to attach the foundation level Model Velocity Unit LOV to an attribute then the possible values would be the numbers 1–7. More valuable to the user would be to show them the descriptions, which include m/sec, mm/sec, in/sec, etc.

Well, I didn’t know how to do that. Fortunately for me, I came across Dave Merrit’s “technical how-to get stuff done better and faster blog,” Dave’s Rave and his how-to post on how to attach both an LOV value and description to properties.

Like Johnny Carson used to say, “I did not know that.” So thanks, Dave!

You know what? Users are a pain in the butt. An awful lot of the work that goes into setting up Teamcenter is directed towards preventing users from making too big of a mess of things. And the very first thing that users will try to do to screw up your database is to mess around with the part numbers they assign to data. If a part number is supposed to be XXXX-YYYY, and you don’t have the proper controls in place, you’ll be pretty lucky if you don’t end up with thirteen variations of it: XXXX-YYYY, XXXX_YYYYY, CURLY.XXXX-YYYY, LARRY.XXXX-YYYY, MOE.XXXX-YYYY, XXXX-YYYY.REWORK, my_left_bracket.XXXX-YYYY, projectZ.XXXX-YYYY, etc. etc. ad infinitum, ad nauseam.

I know because I’ve had to deal with the mess users have created, and because I used to be one of those users who contributed to the mess. (doh!)

So, what kind of proper controls can you put in place? Well, keep reading…