≡ Menu

Teamcenter Data Migrations, Part 1 — Common Problems

Share the knowledge

The subject of migrating NX CAD data into Teamcenter has come up recently in discussions I’ve been involved with. Data migrations have also been one of the more interesting projects I’ve personally worked on, so I thought it might warrant a post or two.

I’m going to start off buy discussing some of the problems I’ve seen with the raw data, the part files that needed to be migrated into Teamcenter. I suspect that many of the issues I dealt with are pretty common and not specific to any one CAD application (or even to CAD data itself).

Common Data Migration Issues

My hope is that by identifying the issues up front you’ll be able to prepare for them proactively. Here are the main problems with the source data which I have seen:

File Naming Issues

The first set of issues revolves around how files are named. Here are the types of issues I’ve cataloged:

Correctly named files

Okay, not really an issue per se, but sometimes it seems that this is the exception rather than the rule.

Prefixed or Suffixed File names

These are files that have the correct part number (or whatever) in their file name, but then there’s some sort of extra information in the form of a suffix or prefix. scotts_part.1234567 or 1234567-rework, for example.

Legacy naming rules

If your company has been around for awhile, or bought a bunch of other companies, then it’s likely that some of your legacy data conforms to rules which are no longer valid for newly created data.

Missing revision

This is more specific to NX data, in particular, which can have the revision of the file included in the file name, e.g. 123456_01 → Rev 01 of part 123456, 123456_A → rev A, etc. Sometimes though you’ll just have a part named 123456 and you’ll have to guess which rev it’s supposed to be.

Invalid file names

And sometimes parts have file names that don’t match any approved naming standard at all. I’ve seen three main causes for this:

Concept Parts

Part files created to try out an idea for a project where the user didn’t pull an actual part number. The part may never have been used for a production drawing, a file with a proper file name may have been created by a save as operation, leaving this one behind, unused, or the worst case offender: the part is referenced by a drawing but called out with its “real” part number on the face of the drawing.

Customer and Supplier Parts

Parts that come from suppliers and vendors typically don’t conform to your naming rules.

Personal Files

In every single CAD department I’ve ever worked with sooner or later someone has brought up the idea that their archives contain the drawings for the deck somebody is building on the back of their house.

  • These stories often include mention of how the person who did this was able to buy the exact amount of wood and nails to complete the project without any scrap.
  • Okay, I confess, I have used CAD to layout bookcases I was installing in my basement. They came out awesome — however, I learnt that my ceiling isn’t quite as straight and as flat as in my CAD model. I may have had some scrap.

Problems with the files themselves

Once you get past the problems with the file names, you still have problems with the actual files. Examples:

Versions of a part kept in multiple directories

Usually the expectation is that all versions of the same part are kept in the same directory or in a well defined set of directories. But sometimes that doesn’t happen and what you think is the latest revision of a file is in fact not the latest because the latest is in some other directory that you don’t even know about yet.

Duplicated file names

The next item is a variation of the previous. Here, not only are there multiple directories with the same file in them, but there’s actually two or more files with the exact file name in multiple directories — and you get to figure out which of those is in fact the most “correct”. More often than not the files are not actually identical.

Different versions of same file name

This is an extension to the various part naming issues mentioned above. Now you may see more than one style of naming the same CAD file, 123456-01 and foobar.123456-01, for example. If your file naming convention includes revisions in the file name you may get lucky and there will only be one variation used per revision — curley.123456-01, larry.123456-02, moe.123456-03, where the 01, 02 and 03 are the revisions.

Missing files

Next, you have files that other CAD files refer to, but which are missing from the OS. Three reasons for this are,

  1. The files were deleted
  2. The files were renamed at the OS level but other files are still looking for the original name
  3. The files were created in a user’s local directory and never moved to the common filing system

Corrupt files

Finally, sometimes files just go bad and you just can’t work with them any more. These need to be repaired or replaced.

Just the beginning

Today we’ve just looked at identifying some of the common issues—and if you have more to add, please tell me about them in the comments. Later we’ll discuss some of the decisions that have to be made, such as: do you want to migrate every single file? Every version of certain files? Or, certain versions of certain files? So, please stay tuned.

  • Marc Henert

    Scott, you may want to mention problems related to part family template and children files.
    I have had various issues as listed:
    1)  Multiple people changing the same template file at the same time or creating the child part and not filing the template part which creates what I call a lost child.
    2) Making another part from an existing child.
    3) Template part file renamed via OS or deleted from the system which creates a reference in the cache of the assembly part.
     
    Also there are differences between native NX and   integrated NX part family functions.
    As an example, in native the filename may end with a space character by accident and no error occur but, in integrated mode this is a problem.
     
    As file are cloned into Team center it writes references in the existing item for impact analysis (where used) process.  You must have write access in order to update this data.  If the file has been released this is a problem.

    • http://plmdojo.com Scott Pigman

      Marc, those are some interesting examples. Thank you for sharing!

      I think we avoided many  issues with #1 by having a dedicated team for handling library parts that kept a pretty tight lid on who modified the templates when. But I wonder if that would explain some of the oddball problems.

      What is the effect of #2?

      #3 – I did end up having to edit some of the names referenced by assembly parts. ug_edit_part_names got a lot of use (more on that another time).

      I have not seen the space issue, I take it you mean there’s a space in the part name column in the spreadsheet. Did you treat family members as lost when importing? I did. I wonder if that made a difference?

      I did have to put some special rules in the ACL for the migrator user ID.

  • https://twitter.com/uk_dave David Merritt

    Great post covering all the problems with the CAD files as one
    gets ready to migrate data into PLM. 
    Although you title this as NX data into Teamcenter your points are appropriate
    for just about any CAD system migrating into any PLM system.  Can’t wait to see Part 2.

    • http://plmdojo.com Scott Pigman

      Thank you, David. Appreciate the feedback. I figure that most of these issues are pretty general, but I’ve grown leery of making broad statements like that. Whenever I do I usually learn afterwards about an exception.

  • Sunil

    I suppose, all the file naming related issues can be handled by checking the file names while mapping the file name between the souce and destination system . Corrupt dataset related issues can be be handled by utilites like dataset_cleanup, purge_volume and review_volume utilities .

  • Garrett Koch

    Here at Navistar, I believe they have just about every scenario of Teamcenter noncompliance going on simultaneously from ignorance of the users due to lack of training to data coming and going via import/export commands as well as physical media trading. They xfer data amongst sister companies and partnerships and customers and vendors – all at various levels of membership including 2-tier, 4-tier, domestic and offshore, military (ITAR) and commercial, and even  managing Ideas, Pro-e, NX6, and NX7 data in a mix of Tc databases. Here are some of the biggies:

    1) misuse of JT files as a new “lightweight translation medium
    2) misuse of Tc item types – how many are really necessary?
    3) an attempt to accommodate their alledged “need” for their traditional use of the Ideas model file
    4) multiple Tc and CAD migration projects going on simultaneously
    5) cursing their sins of the past as they proliferate even more sins due to the priority of meeting deadlines
    6) not being completely committed to the migration by not having upgraded hardware/software available to the users as soon as they receive their migration training
    7) criticially underestimating the enormity and complexity of their data migration project and the amount of resources required to accomplish it
    8) not having an easy to use yet comprehensive method of tracking the completion of the migration through the various stages (using a single Excel file)
    9) not committing to the project and yanking assigned migrator resources onto other production tasks, creating even hotter migration issues
    10) improperly preparing the Ideas data before migration causing them to deal with massive amounts of unneccessary and redundant data all the way through the process

    That makes for a tidy little top ten list but there are more issues.

    - Garrett

    • http://plmdojo.com Scott Pigman

      Garrett, great input, I really appreciate it. some reactions:

      #1: I’d like to hear some examples

      #2: aahhhhh… I have to admit that I’ve sinned in this regard — and I caused myself headaches during the migration because of it. Someday I’m going to write something on this topic.

      3, 4, 6, 7, 9, 10: Am I correct to understand that you’re primarily migrating I-DEAS data, that you’re using the standard tools from SPLM to do that, and you’ve distributed the task amongst your user community? I-DEAS is something I don’t know very much about; I gather that the I-DEAS keeps data within its own PDM system, correct?

      5: let me guess, they discover they need something migrated at 5 PM on Friday — for a job that has to go out that same day.

  • Satishdane3

    scott,
     nice sort out of issues while migration.

    there are more issues like missing of NX datasets and , latest revisions as well.
    so latest Bom view revision is also missing.
    for e.g rev A is having NX data and BVR , but for same item no data is attached or BVR.
    in this case how to fix.
    whether just copying wil solve this issue?or using something like deep copy rules.
    hope u  throw some light on this

    • Satishdane3

      i mean latest revision

    • http://plmdojo.com Scott Pigman

      Hi, thanks for the comment. Problems with datasets and BVRs are problems with data in Teamcenter; I was focusing on the problems you’ll find with the native data outside of Teamcenter — the raw, native files on the operating system hard disk — that you need to migrate in.

      Now I’m not GTAC and I don’t want to be, but one thing I’ve encountered is that if you clone data in as simply a file instead of as an assembly then you don’t get a BVR generated. In that case you can open the NX file, with write privileges so you might need to be a DBA user with bypass, and save the file and it will generate the BVR. There are some NX customer defaults that need to need to be set correctly first — don’t update structure on load, or something similar. Basically what you don’t want is NX updating it’s own internal assembly structure to match the (non-existent) BVR in TC when you load it. Instead you want to update TC when you save the NX part.

  • Stalekar_2000

    1. Same file  used as attachment to 2 similar but slightly differing part.
    2. Files names other than part names..

  • http://www.facebook.com/people/Stephen-Samuel/1816312230 Stephen Samuel

    The only thing that feels better than making a really cool tutorial, design or article, is sharing it with others that will really benefit by it. Please visit the NXTutorials.com website for more cool tutorials.

  • Pingback: 8 Questions to ask Before Starting a TC CAD Migration | The PLM Dojo

  • Pingback: Migrating data into Teamcenter, Part 2: Taking Inventory | The PLM Dojo

Optimization WordPress Plugins & Solutions by W3 EDGE