Don’t Ditch Your Home-Grown PLM

YourCompanysApp Does this situation sound familiar? Your company has an in-house system for doing some portion of what is now part of Teamcenter (or Windchill or Aras or…). The Powers That Be have decreed that Teamcenter will replace the homegrown software. Everyone hates the old system. It old and complicated and ugly. When it was new it was state of the last decade’s art. Everyone, from management to users, wants to know how soon it can be replaced and decommissioned.

Well, I’ve been pondering this question myself lately. I think I have the answer you should give them. I say, tell them that you will never get rid of the old system.

Here’s why — and what I think you should do instead.

Git, and why We Need Distributed PLM

git logoLike any good software developer, I use a source control system daily. But I’ve fallen behind the times. The latest source control paradigm out there is something called a Distributed Version Control System (DVCS). The two main DVCS’s are Git and Mercurial. GitHub, which hosts git projects, seems be getting written up weekly in technology and business publications. I’m playing catch up, but now I understand what the big deal is. The PLM world needs to take notice. We need Distributed PLM systems.

Here’s why.

Killing Memory Errors with the STL

Pull up a chair and let me tell you a story from my early days as a professional programmer. It’s about how I screwed up, and what I’ve done since then to make sure that mistake is never repeated.

I’m going to ramble for a bit but I promise that I’ll get to the point eventually.

One of my first big tasks as a programmer was to update, in preparation for an upgrade, some iMan and Unigraphics code I inherited. For you younger kids out there, iMan was the predecessor of Teamcenter Engineering and Unigraphics later bought IDEAS and became NX.

The code was a mess. Of course, every programmer always thinks that code done by someone else is a mess. But this really was. There were single functions that would have taken two dozen sheets of paper to print out — double sided. My favorite was a family of functions that instead of returning values or modifying a parameter via a pointer updated fields in a global array. One function would update element 0, another would update element 1, etc. And then other functions would know which element to read. But that’s besides the point.

This code was prone to unrepeatable memory crashes. Memory errors are like that. One function would allocate memory, typically for a string or arrays, and then pass the pointers back to their callers. The callers would be responsible for freeing the memory — unless they passed the allocated pointers to their callers who would then have the responsibility, and so on.

If you’re familiar with this type of code you know that it is error prone. Freed memory is read, allocated memory is allocated again, etc. These types of bugs can be hard to track down. Sometimes there’s a problem in an execution path that’s rarely taken. Or sometimes the pointer will still point to valid data so long as the OS hasn’t seen fit to reuse that space already. Nine times out of ten the code will seem to work fine, and then on the tenth try the OS will actually use that address for something else and the program crashes.

Whack a MoleI didn’t care much for this type of code, but it would have taken a massive overhaul to make any substantial change. Being new on the job and new to this code base I was reluctant to make too many changes to it. So we tested the code until we found a problem and then I’d hunt it down and try to fix it, and then we’d repeat the process.

Over and over and over and over. Think, whack-a-mole.

Eventually we couldn’t produce any more errors so we decided it was finally ready to release.

So we went ahead with the upgrade. And then… (cue dramatic music) …nothing much happened. The upgrade went about as well as upgrades ever do. There were some snafus here and there, but no show stoppers.

So a week later I left for my first PLM World users group conference.

And then all hell broke loose.

A Trick for Updating a Precise Assembly Quickly

Introduction

Assembly and Component items
Assembly and Component Both at Rev B

There are times when a precise assembly structure is incorrect; the revisions configured aren’t the ones you’re actually using when you’re working on the assembly. This often becomes an issue when it’s time to release the assembly. You want the BVR (BOM View Revision) to accurately reflect the revisions of the components that were actually used when working on the current release. Maybe the assembly was already released with the incorrect BOM and you, as an administrator, need to fix it. Or you might try to fix it in Teamcenter’s Structure Manager by removing the wrong revisions and replacing them with the right ones. But that can take a lot of time and it would be easy to make a mistake. So, what to do?

Precise Rev Rule configuring wrong revision
Precise Rev Rule Configures Rev A of the Component

Here’s a trick that you can try that will let you quickly fix the assembly structure without opening the CAD tool at all or doing a lot of manual work on the assembly structure.

The Polls are now Open!

Note: New polls added, see below

Hey there, everyone. Just a quick note to point out the polls that are running in the sidebar and also on the new page, Polls, polls, polls. Please take a moment to answer a few.

I’m playing around with a new polling plugin for WordPress (the framework that the Dojo runs on). We’ll see how it works out. Other than being PLM or Teamcenter related, there’s not much connection between the questions. I think it will be interesting to get a sense of how you all are actually using Teamcenter.

I’ll also include the current polls after the jump.

take care,

Scott

Bottom-Up Release is a Lie

Top-Down vs Bottom-Up ReleaseIn my work in the PLM world (ha! See what I did there?) I often hear that release must be bottom-up. But from what I’ve seen that is rarely what is actually done. In truth, release is usually done top-down. We say that components need to be released before the sub-assemblies they go into, and the sub-assemblies need to be released before the assemblies they go into. But that isn’t necessary. It is often not even desirable.

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

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.

Where Was The Dojo Last Week?

I was offline for most of last week. So, just what was I doing?

Flamenco Beach, Culebra Island, PR

I think I may have found the future home of the PLM Dojo Educational Center and Retreat

3 Master Model Concept Misconceptions

If you’re around NX for very long you’ll hear someone talk about the Master Model concept. It is an important concept. It comes up in the various forums from time to time. Usually when people as, What is the master model concept? There are no shortage of answers offered. But I feel that most of the discussions miss the mark. I think there are a lot of misconceptions about the Master Model Concept. I am going to try to clear some of them up.

Master Model Definition

If I’m going to discuss what people get wrong about the Master Model Concept, I should at least try to provide a definition of what it is. Here is how I define it

Master Model Concept:

A method of separating a CAD model definition from data which is dependent upon the CAD model but does not define the CAD model itself. This separation is achieved by storing the CAD model definition, called a Master Model, within one file and each piece of dependent data within separate files which refer to the Master Model, typically by including it as a component within themselves. Typical examples of dependent data types are drawings, machining tool path definitions, and FEA analyses.

Now, on to the misconceptions.

4 Steps to Follow When Updating Workflow Templates

Teamcenter’s Workflow Designer interface is horribly bad. Just one of the flaws is that workflow templates do not have proper revisions. I mean, just think of the irony here. Pretty much the primary task of Teamcenter is to allow you to track what changes have been done to a piece of data. And one of the primary tools in Teamcenter is the workflow template. But they didn’t give you the ability to easily keep track of changes to your workflow templates.

But that’s not all, they set it up so that any time you make a change it’s instantly saved to the template. It’s not like most other applications on your desktop where you can say, “Oops! What was I thinking? Time to close without saving!” Even other TC applications give you that ability, Structure Manager and Access Manager to name two. So they make it really easy to make inadvertent, permanent, changes to your workflow template and really hard to figure out what exactly has changed. Lovely.

Unless you’re capable of never making a mistake when working with workflow templates, you need a system that will keep you out of trouble. Here is mine.