≡ Menu

How to Automate NX Migrations with Autotranslate

Share the knowledge

If you’re going to migrate very much NX CAD data into Teamcenter, even if you’re going to do it manually[1] by using NX’x File → Import Assembly into Teamcenter… there’s one customization you should very seriously consider: a custom Autotranslate function.

A custom Autotranslate will give you the the ability to automate how native file names are translated into Teamcenter IDs, alleviating the need to have users manually enter them in. It can be used whether you’re importing data using NX’s dialogs or their command line utility, or if you’re developing your own program to handle the migration for you.

Autotranslate

In the import dialog, one of the options you may select for setting the item IDs is Autotranslate. The autotranslate option looks at the file names being imported and converts them into the Item ID and revision ID to be used in Teamcenter. NX comes with a default implementation of autotranslate; if memory serves it takes anything up to the last _ character to be the item ID and anything after it to be the revision ID. If that works for you then you can stop reading now and go find something else to do. The rest of you, stick around.

BYOA (Bring Your Own Autotranslator)

The interesting thing is that you have the ability to supply your own autotranslate function custom written for your own data. This opens all sorts of possibilities. The first is being able to handle different revision identification schemes besides the default. But you’re not limited to just that. You can transform improperly named file into correctly identified items, perhaps by removing extra prefixes or suffixes, converting underscores to dashes (or vice versa), or removing illegal characters. You could also consult a renaming table that maps native file names to item IDs (x:foobarmounting_plate.prt = 1234567/A). What you do with it is up to you.

Writing your own Autotranslator

[box type=”note”]Just to make sure we’re all on the same page: although we mainly discuss Teamcenter here, the code shown is NX Open C, not Teamcenter ITK. Autotranslate is a function of NX, not Teamcenter[/box]The basic template for your autotranslate function is something like this:

extern "C" DllExport // export for unit tests
int plmdojo_autotranslate( const char input[MAX_FSPEC_SIZE + 1],
                           char output[MAX_FSPEC_SIZE + 1])
{
	if ( input[0] == '@')
	{
	   // export
	   return tc_to_native(input, output);
	}
	else
	{
	   // import
	   return native_to_tc(input, output);
	}
}

Input and Output

Although we’re primarily focusing on using autotranslate for importing data into Teamcenter, it can also be used to export data out of Teamcenter. You have to check your input to understand which direction the autotranslate is being used. The native OS side will be a file name, with or without the full path. The Teamcenter side will be in the CLI (command line interface) form used by several command line utilities: @DB/item_id/revision_id. So for imports the input parameter will be a file name and the output will be a CLI string. For exports it will be the other way around, input will be in CLI form and output will be a file path, hence the if(input[0] == '@') test to determine which applies.

Registering a custom Autotranslate Function

You instruct NX to use your autotranslate function instead of the default with the UF_UGMGR_set_clone_auto_trans() function. Loading a DLL at NX start up that contains this function would do the trick:

extern "C" DllExport 
void ufsta( char *param, int *returnCode, int rlen )
{
    UF_initialize();
    UF_UGMGR_set_clone_auto_trans(plmdojo_autotranslate);
    UF_terminate();
}

Search the NX documentation for Automatic Loading At NX Start-up for information on loading shared libraries at start up.

Testing and Refining

You’ll note that I declared my custom autotranslate function as extern "C" DLLExport. This is so I can call it directly from another program so I am able to unit test it outside of NX. I strongly encourage unit testing your function. Every time you find something you need to correct, add a new unit test for it and re-run the entire suite of tests every time you update your autotranslator.

Additionally, I suggest you get a file listing of every file you might possibly import and write a program to call your autotranslator on every one of them and then write the results to a CSV file that you can open in Excel. You’ll learn a lot about your data and what special cases you need to check for in autotranslate. You may not be able to write a function that handles 100% of the file names perfectly (there’s always that one screwball file), but if you can write one in a reasonable amount of time that handles 80%–95% of your data, then it’s definitely worthwhile.

Personally, I write my these sorts of programs in Python, but that’s a topic for another day…


[1] I hesitate calling any task done with a computer a manual task. Sitting at a desk pushing buttons is not manual labor.

  • Khiste Atul

    Hello scott, thanks for sharing the useful information….I might need your help as I work very closely on Import and export activity….if we create some small program like import_data it will reduce our time consuption for this activities…

  • http://hooverm.pip.verisignlabs.com/ Teamcenter Heretic

     So, sitting here with a nice glass of Rye (aWild Turkey Russell’s Reserve) I was perusing the older posts and came upon this one.  I am amazed that this particular topic doesn’t have some serious comment action!

    The ability to create your own clone translate function obviates much of the need to do scripty stuff with file names.

    Also, your recommendation to write a test harness (python… really?) is a key..  My last test program checked 15K item ids against a set of rules.  Better (and easier/faster) to do this outside Teamcenter than inside 😉  One can even use a random string generator as input.

    Personally, I’m a fan of Finite State Machines for parsing input.  In fact I wrote my first one in 1993 using GRIP.  Imagine that!  Ended up porting the exact FSA to ITK in 2003.

    LEX and YACC use this theory to parse complex grammars and it is very well suited to parsing files into item ids.

    A simple 7 x 6 array can easily represent the states required to parse a file name into item id/rev:

     int fsa[FSA_STATES][FSA_INPUTS] = {  {0,1,1,4,4,4,4}, /* New Id */          
                                            {1,1,1,2,4,4,4}, /* Continue Id */                  
                                            {2,3,3,4,4,4,5}, /* New Rev */          
                                            {3,3,3,4,4,5,5}, /* Continue Rev */   
                                            {4,4,4,4,4,4,4}, /* Invalid */          
                                            {5,5,5,5,5,5,5}  /* OK */       
                                           };

    Lets have some more discussion on this topic.  I love it almost as much as “Save $$, hire an ITK programmer” 😉

    • http://plmdojo.com/ Scott Pigman

      good comments. perhaps I should encourage everyone to pair the dojo with bourbon. 

      I’ve added this post to the “featured” category so it’ll get more front page attention.

      I was thinking earlier that a companion piece about using a cvt callback to set item type is due.

      lex/yacc — been ages since i looked at those. but FSMs are a good idea to consider. I might also look at the boost library’s regular expression engine.

      python… yes. I’ve written entire ITK programs in pure python actually. And not trivial ones. Maybe I’ll get into that more someday if there’s an audience for it besides myself.

  • Niranjan Nyamagoud

    Hello Scott,

    Thank you very much for such a good article. I have been searching this information from last 2 months. I am new to the NX and Teamcenter and our Company  is recently migrated to NX.  I have a few questions regarding  importing files to Teamcenter from native NX.
    Presently we are using master model concept to create model and drawing. 

    Ex: “Test-File.prt ” for model and “Test-File_dwg1.prt ” for drawing.

    Whenever I tried to import parts from native nx to teamcenter, it is creating two different data sets for same part numbers. Its causing delay in our project.

    We usually use two types of part names in NX 7.5

    4012345.prt and  4012345_dwg1.prt  (TC dataset)

    123.456.789.prt and 123.456.789_dwg1.prt  (native nx part name)

    When I  import 123.456.789.prt and 123.456.789_dwg1.prt to Teamcenter both prt and dwg  should be created in single dataset.

    Please give me an sample example how to create autotranslate and use it in start up script.
    Because I am new to this kind of programming, but I want find solutions this kind of problems in future. It will help me lot. Thanks in advance.

                                                                      

    • http://plmdojo.com/ Scott Pigman

      FYI, in general you’re better off asking specific technical questions over on the forums at http://plmworld.org. Your question will be seen by a lot more people than just me. It’s where I turn for help.

      That said, i’ve never seen or heard of anyone putting two NX datafiles inside a single dataset. I don’t know why you’d think you’d want that. It’s a bit of a simplification, but generally speaking each NX file gets its own dataset.

      why do you feel that they should be combined into one dataset?

      • Niranjan Nyamagoud

        Hello Scott, 
        Sorry for confusing. Actually I am talking about Items not dataset. When I import part and dwg two separate files it should create under one Item.

        For example I create 1002575.prt and 1002575_dwg1 using master model concept in native nx. After importing to TC, both part and dwg create under 1002575 Item.  For your info I have attached image.

        • http://plmdojo.com/ Scott Pigman

          Now your question makes more sense. Unfortunately, I haven’t tried to do that myself; we intentionally store drawings as separate items. There are a few reasons to do so, such at the ability to have separate lifecycles for your parts and drawings.

          Regardless, I think that the procedure is to create a sub-directory with the same number as the part and in the same directory as the part and put the drawing files (and anything else) there and then in the import file dialog you specify that as an associated directory. I’m not sure how, or if, you can specify what sort of relationship should be created between the item revision and the associated files.

  • Pingback: Using Python to Unit Test NX Open (or ITK) C Code | The PLM Dojo()

  • Pingback: How to Automate NX Migrations with Part Type Convert | The PLM Dojo()

  • Pingback: Ninja Tricks for Migrating NX CAD Data – The PLM Dojo()

Optimization WordPress Plugins & Solutions by W3 EDGE