≡ Menu

You mean there’s more than one way to store Drawings in Teamcenter???

Share the knowledge

If you’re using Teamcenter to store your CAD models and drawings (and most Teamcenter customers are, I believe) then one of the first issues to tackle is, how do you store those drawings? There are a few different ways I’ve seen: embedded in the CAD model dataset itself, stored as an additional dataset under the same item revision as the CAD model, and stored as a separate item from the model item. Today I’ll run through some of the issues related to each of these approaches.

Things to Consider

This is surely not an exhaustive list, but here are some things to consider when deciding how to store your drawings in relation to your models.

  1. Parallel work effortCan one person work on the model while another is working on the drawing, or can only one be worked on at a time? Being able to work on both concurrently is usually seen as a benefit.
  2. Separate review processesDo you want to have one workflow for reviewing the drawing and another for reviewing the model, or will you always review both together?
  3. Revision independenceDo you want to be able to revise the drawing and model independently, or will revisions always be synchronized? Some companies always revise the drawing if the part changes, and revise the part if the drawing changes. Others do not synchronize revisions. For example, changing a note on the drawing may not require an update to the part, while changes to the part that do not affect the drawing, such as changes to layer assignments or reference sets, do not require a drawing update.
  4. Mono-detail or Multi-detail?Many companies only detail one part number per drawing. Others, particularly in the Aerospace industry, detail multiple part numbers per drawing. Typically the Drawing carries a core defining document number and each detail part defined by the drawing has a part number that contains the core document number and as suffix, such as -101, -102, etc. Which model applies for you?
  5. Your CAD software and its integration to TeamcenterDifferent CAD packages and their Teamcenter integrations may force you into one model over another. My personal hands-on experience is almost entirely with NX. I believe that most everything I say here, except when noted otherwise, is applicable to other CAD systems but simply put, I do not know what I don’t know. If anyone knows of a case where a particular CAD integration requires one configuration over one of the others, I’d love to hear about it.

How to Store Drawings (Pick One)

Here are some of the ways I’ve seen for storing models and drawings in Teamcenter:

Drawing Embedded In the Model

Okay, I haven’t actually seen anyone do this in Teamcenter, but it used to be the standard way that drawings were stored in Unigraphics files.

Single CAD file containing both model and drawing data

The old-fashioned way: Everything in one file

For those of you who use other CAD systems and aren’t familiar with Unigraphics/NX, here’s a little background to put this in context — and for those of you who only know UG/NX, it’s helpful to understand where your non-NX colleagues are coming from so you may want to pay attention too. Unlike many (most? all?) other 3D Mechanical CAD applications NX only has one standard file type that it uses for piece parts, assemblies, drawings, library templates, and probably a couple other types of files I’m forgetting. All those file types are stored with the same .prt file extension. Autodesk Inventor, Solidworks, Pro-Engineer, etc. all have different file types (i.e., extensions) for these different types of files; they simply won’t let you put a drawing inside of a model file, or vice-versa. It’s just not how they work. However, for NX it used to be that the only way to store a drawing of a CAD model was inside the CAD model itself so that the model and drawing would be bundled together. Like I said, I haven’t personally seen this done in Teamcenter, but it’s possible, particularly when you’re working with old legacy data that’s been migrated into Teamcenter.

A single dataset containing both the model and drawing und er a single Item Revision

Storing an embedded drawing model in Teamcenter under a single revision

Pros

  1. If you’re working with Legacy CAD data that was done this way, you may have to use this approach. I’d spend some time looking for tools to separate the data into two files though.
  2. I’m thinking… Gimme a minute…

Cons

    1. You cannot work on the model and drawing at the same time because they’re both in the same file.

 

    1. You cannot review the model and drawing in different workflows because they’re both in the same file

 

    1. You cannot have independent revisions of the model and drawing because… oh, heck. You get the picture by now.

 

  1. You can’t have multi-detail drawings. I think you know why.

Introducing the Master Model Concept

CAD model and drawing splt into two files

The Basic Master Model

Eventually Unigraphics began supporting assemblies and someone figured out the “Master-Model” concept for models and drawings. The concept is pretty simple: the model and drawing are two separate files and the drawing is an assembly which contains the model as its component.

Except for the fact that the drawing is also technically an assembly, this is pretty similar to how other CAD tools work that have separate extensions for models and drawings. the Master Model technique is pretty much the standard way or relating NX CAD drawings to NX CAD models. The question then is, how to store both the model and drawing files in Teamcenter?

Master-Model using Manifestations

Model and Drawing stored in separate datasets under a single revision

Storing the Model in Drawing in two datasets under one item revision

The default approach Teamcenter uses is to put both datasets under the same item revision. The model is stored in a UGMASTER dataset and associated with the revision with a Specification relationship and the drawing is stored in a UGPART dataset that’s related to the revision with a Manifestation relationship. Other CAD tools will use their own dataset types and possibly their own relationship types, but otherwise it should be the basically the same sort of setup.

Pros

    1. Supports concurrent work on both the model and drawing.

 

    1. It is possible to support separate workflows for the drawing and model (more on this in the under Cons)

 

  1. The part and drawing are bundled together under a single item revision so it’s easy to find them.Oh wait, I guess that’s true of the previous all-in-one model solution too. I should go update section. Wait. No. No, on second thought I won’t do that. I don’t want to say anything else positive about that last setup.

 

Cons

    1. It is harder to set up separate workflows for the drawing and model. Usually a workflow takes an Item Revision as a target and then processes a review process for relevant attached datasets. You’d either have to set up workflows that take one dataset or the other as a target, or that take an item rev and then pick up only the model or only the drawing dataset. Then you have to figure out how and when the revision itself is released. I’m not saying it can’t be done, but I think it’d be pretty convoluted.

 

    1. You can’t have revision independence since both datasets are under the same revision.

 

    1. Multi-detail drawings are probably possible to support, but it’d be an awkward setup. You’d have to figure out which model’s item revision contains the drawing, or have the same drawing dataset referenced by multiple item revisions, each one of which contains a different model dataset which is detailed by the drawing. Again, I’m not saying it can’t be done, but I suspect it wouldn’t be a very elegant solution. (Feel free to prove me wrong—I’d love to see a clean way of making it work this way).

 

Master-Model using separate Items

Drawing and model in two datasets, each under its own Item Revision

Splitting the Model and Drawing into two separate Items

The last approach I’ve seen is to have one Item for the model and another Item, usually of a different “Item Type” (to use the old, but convenient, terminology) for the Drawing. As before, the Master-model concept is used.

Pros

Overall, this is the most flexible, although for some it may be too flexible.

    1. The model and drawing can be worked on concurrently.

 

    1. Setting up separate workflows for the model and drawing is very easy to do, and if you don’t care for that then it’s also pretty simple to set up a single workflow for reviewing both at the same time.

 

    1. Revision Independence. Since the model and part are now under separate items, it’s trivial to revise them independently; just revise one, but not the other.

 

  1. Multi-detail drawings are easy to support. Simply create separate items for each part model and then create a single drawing item that details all of them.

Cons

    1. Un-synchronized revisions. If you don’t want revision independence you need to need to set up processes and safeguards to ensure that revisions are synchronized.

 

    1. Globally unique Item ID restriction. Usually companies expect to store mono-detail drawings under the same drawing number as the part which they detail. Unfortunately, Teamcenter cannot currently support that. As of version 8, Teamcenter requires globally unique Item IDs regardless of item type. That means that you can’t create a Model item, 123455, and also create a Drawing item, 123456, to detail that part. Siemens claims that Teamcenter 9 will introduce multi-key item IDs, in other words in Teamcenter 9 you will be able to use the same Item ID for two different items, so long as they are actually different Item Types. At least, that’s what they’ve claimed. Until then the normal solution is to prefix or suffix the drawing with something to distinguish it from the model item. For example, the Model could be 123456 and the drawing of that model could be DRW-123456.

 

  1. It’s harder to find everything. If a user does an Item query on “123456”, he’d only find the Part item, 123456. In order to get both the part and the drawing he would have to search for “*123456″. It might take awhile for users to get used to this.

 

One more wrinkle: Separate Drawings and Documents?

Finally, one last consideration. In a previous post I discussed how you might use separate Part and Design items to differentiate between your PDM and PLM requirements. Similarly, you might use separate Document and Drawing items as well. But that subject is probably best left for another day.

Conclusions and Questions

Hopefully I’ve given you some things to think about — or helped you to understand why things are done the way they’re done where you work (or how you might change things).

Are there any other ways to relate drawings and models which I have missed? What other issues are there to consider? Let me know, I still have a lot to learn myself.

  • http://www.plmconsult.nl Menk Slot

    Scott,

    A real good story.

    Other PLM Systems use this splitted data model (Object for Item and separate objects for drawing/models) and there is always a big problem.

    Most Companies want the Metadata on Item and Drawing be the same and they want the opportunity to change the metadata on both objects. This means you need to keep them in sync every time. End-users have problems to understand the difference between Item and Documents and you have to release them separately.
    For me there is only 1 reason to have this splitted data model and that is the possibility to have separated revisions. If you make an administrative mistake in the drawing that has no effect on the Item you can revise and change the drawing without revising the Item (with all the consequences)
    But users sometimes use this leak for making other changes in the drawing.
    For me there is only one good Data model for Items and Drawing and that is the Master-Model as TC is using. But I think that TC is standard using the specification relation between Item Rev and NX Dataset. In a project I‘m working on at this time we use for the CAM specification the TC Manifestation relation. That gives the possibility to release the Drawing and the CAM Dataset in different Workflows.
    Regards,

    Menk Slot
    http://www.plmconsult.nl

    • Scott

      Thank you, Menk, for your comments. That’s a good point about synchronizing metadata, I should have had it on my list of considerations. The thought that immediately comes to my mind is that there should never be double entry of data, even when the model and drawing are split. I’m wondering if compound properties on one object could traverse the parent/child relationship between the two and retrieve and display the attribute from the other. Runtime properties certainly could, although that gets you into ITK coding. My general, unscientific, thought about the ability of users to understand the difference between item (I take it you mean the item for the CAD model) and the document is that (a) The users I’ve worked with certainly had no problem with that, and (b) in general a simple solution that is extremely easy for the users to use and understand might work 90% of the time, but then there’s the 10% of cases for which it completely falls apart. In our case where I work the driving factor for the split data model isn’t separate revisioning, it’s that we use multi-detail drawings. Each part is a separate item in TC and then there’s one drawing for all of them. Separate workflows is a secondary benefit.

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

         Remember that OOTB there is no protection for a Manifestation!
        One can do all sorts of things with objects related as Manifestations as this relation was expressly designed to allow the addition of objects (Typically CAM datasets) to already released Item revisions.

        So, take an Item Rev… add a Spec dataset to it and also add a Manifestaion one.
        Run all thru a release procedure with the appropriate handlers that pick up both a Spec and Man.

        Now go and cut the Manifestation form the Item Rev… Viola!  No more dataset found under the rev.  No way to track the relation other than thru the workflow target list :(

        There are tricks that can be played but short of custom code, not so much.

        This is also true with the Part Family Folder.  Have some fun with that one too!

        • SK

          Hello! Could you please help me in the below issue.
          I am trying to open dwg from teamcenter, but couldn’t open it since the dataset object has not been configured yet. So I have set up everything in BMIDE. However, I am stuck for the past couple of days figuring out what could be the Shell/Symbol for the Autocad(opening .dwg file in teamcenter)
          Could you please help me in this issue

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

       Menk makes a really good point!
      When the drawing/cad data/parts list are all rolled into a single revision then a simple change to any of these sends an ambiguous message to downstream users.
      If I’m a NC programmer who consumes your Revision and now a rev is changed, does that change my process planning?  My toolpaths?  Very confusing.

      I’m a fan of separate items for Part, Design, Drawing and PartsList.

      • http://plmdojo.com/ Scott Pigman

        I’m a fan of separate items for Part, Design, Drawing and PartsList.

        Drawing is a tricky term. To me it means the CAD file that contains the drawing definition. But the OOTB Drawing item in TC 8 is intended for 2D graphics. There are non-obvious ways they reveal that — like you can’t right-click on a Drawing rev and send it to the Structure Manager. 

        Now PartsList is not something I had considered to make a separate item in TC before. Would that have its own BVR that’s mapped to the CAD-BOM?

      • http://plmdojo.com/ Scott Pigman

        When the drawing/cad data/parts list are all rolled into a single revision then a simple change to any of these sends an ambiguous message to downstream users.

        So how about having separate revs for everything, but requiring that the drawing and all design revs have to be revised together, regardless of what changed, so that no one gets confused which design revs go with the current drawing?

        (I’m venting, not suggesting)

    • http://plmdojo.com/ Scott Pigman

      Most Companies want the Metadata on Item and Drawing be the same and they want the opportunity to change the metadata on both objects. This means you need to keep them in sync every time.

      Thinking in terms of relational databases, the standard way to have two tables share common metadata is by capturing that data in a third table. Translating the data model to TC might mean a form (regular form, not a master form) object that’s related to both the item and the drawing. Now how you go about designing the release process is another topic that will require some additional thought.

  • PB

    Hi Scott,
    Another interesting post from you :)

    I think you have covered all the options of Item/Part and Drawing relationships.

    In your option of having separate Items for model and drawing, any thoughts on the relationship. Will it be at Item level (Imprecise) or revision level (Precise). 
    Consider Item Revision (Model) related to specific Drawing Revision, both revisions are not released and frozen.

    Now for doing any change to drawing where the Model Item Revision need not change, user have to manually update the relationship.
    Your comments please.

    Thanks,
    PB

    • http://plmdojo.com Scott Pigman

      Thanks again for reading and participating. It’s very much appreciated.

      Well, at my job we use precise.
      If we used imprecise the models used to generate the drawing could change every time you open the drawing. Did you put that hole there before or after that mount moved? Sometimes people want to do some forensic investigation; Imprecise structures make that much more difficult.

      As for drawing changes that don’t require model changes: revise the drawing, have the drawing point to the existing model revision (which NX will do automatically anyways if you save-as in NX). Both the old and new revisions of the drawing would refer to the same revision of the model. There isn’t a need to manually update any relationships.

      Oh, and I’m sure that there’s some option I missed… I just don’t know what it is yet.

  • Livi810

     

    I have to import the native NX data to the Teamcenter8. Native Nx data
    is having drawing with some reference part in drawing and may
    be or may not be in the model or assembly .

    To Seprate out the model(Ugmaster) & drawing (Ugpart):

    In NX7.5 I tried with the “File->Export->Part->drawing selection(say Sheet 1)->Specify Part (say exported_assembly.prt). OK.

    Afterword I used Ug_import utilty to import the the assembly into the Teamcenter with syntax below:
    Ug_import -part=loacation_pathexported_assembly.prt -id=assembly -rev=1 -name=assembly -type=man -assoc_file=yes -assoc_root_dir=”location_path”

    I am able to import the  separate dataset as  model(ugmaster ) and drawing(ugpart) without breaking their associativity below ItemRevision . but the distortion in the (Ugpart) drawing occured,

    I dont know how and why this happened

    please guide me or suggest me how to achieve this

    Regards,

    LIVI

    • http://plmdojo.com/ Scott Pigman

      Could you explain what you mean by “distortion”?

      • Livi810

        Hi Scott,

        Thank you for your response..

        Lets take an example which will explain the scenario clearly. Suppose  I am having an X.prt assembly of Nut,bolt, and washer embedded with drawing. In drawing of this assembly I have 3 orthographic view and one  say TFR-ISO view (inserted as base view) of any model in the assembly say washer, now if  export this drawing as per the procedure above. and import it to the teamcenter to get the separate datasets ugmaster(for model) and Ugpart(drawing) as per the procedure above
        No doubt I get the structure of Item having ugmaster and ugpart in TC8.3 but when I open the ugpart in NXmnager the view get distorted means the base view (inserted as base view) gets replaced with whole assembly. drawing mixes up.

        I don’t I understand where am I making mistake? please review my import procedure,  Is it right?.
        or
        Could you please guide me what procedure should I apply for importing the drawing and model as different dataset under master model concept.

        Thanks & Regards,

        Livi

        • http://plmdojo.com/ Scott Pigman

          This is something I would have to see myself to have much of a chance of figuring out, and my NX skills are rusty. You’ll probably be better off with GTAC or the PLM World forums.

          My guess is that the original view used view dependent edits to hide the extra components and that got lost when you split the file. I doubt there was anything you could have done differently to prevent this. You’ll probably have to re-hide the extra components. I believe that I used to use the Assembly Explosion (Exploded Assembly?) tools for that.

          • livi

            Thank you scott,
            I got the solution, the views are not distorted when I have imported the drawing in the teamcenter without opening it in the native NX..Earlier I was opening the drawing in Native NX after splitting as per above process that’s why it was distorting.

            thanks

            Livi

          • http://plmdojo.com/ Scott Pigman

            glad to hear you got it sorted out.

          • Siva

            Hello Scott! Could you please help me in the below issue.
            I am trying to open dwg from teamcenter, but couldn’t open it since the dataset object has not been configured yet. So I have set up everything in BMIDE. However, I am stuck for the past couple of days figuring out what could be the Shell/Symbol for the Autocad(opening .dwg file in teamcenter)
            Could you please help me in this issue

  • Heath

    PMI is the future (MBE) is another way to say it. One file for all the data is the future.

    • Teamcenter Heretic

      I would love to hear your vision of the future… you must be younger than I because I’ll definitely be retired before PMI replaces drawings.

      For most sites with any data delivery requirements at all drawings still rule the roost.
      In fact, many government contracts pay per DRAWING not anything else.

      Just listen to the screaming when the plotter/printer isn’t working 😉

      • http://plmdojo.com/ Scott Pigman

        The interesting thing though is that although the customers demand drawings, more and more the manufactures build from the model and only use the print for checking.

  • Pingback: Three Master Model Concept Misconceptions | The PLM Dojo()

  • jetty ramu

    Hi. the above post was so informative. Now i have a question. At present I am using TCIC 9.0.0(teamcenter integration for catia) and teamcenter 8.3.3 version. when I used to save my catia file in teamcenter, the file is saving. there is no issue in saving. But under catia file, the catia_model_attribute form is missing. I don’t know how to resolve this issue.

    please help me in this

    I am uploading two jpg files.

    1st pic is having that catia_model_attribute form for an item(file name is a2)

    2nd is missing catia_model_attribute form for an item(file name is a1)

  • Jeremie FEBURIE

    Hello All,

    I am facing a situation at a new customer who wants to manage drawings as separate item from model.

    The purpose is to track revisions of drawing independently from model so the “Master-Model using separate Items” should be the best solution.

    Now, I have some questions about title block auto-updates (attribute mapping in fact)

    Because, Drawing dataset is stored in a Drawing Item, I will get the item ID of the drawing Item instead of item Id of Model Item.
    Is there a way to solve this issue ?
    Does the “Part List” solution is the only solution to solve this issue ?

    Is it possible to map attributes from Model Item inside Drawing Title block ?
    I speak about custom attributes that could be mapped between TC and NX.

    If anybody has some answers, it could help me a lot !
    Thanks
    Jérémie

    • Teamcenter Heretic

      There are myriad ways to solve this.

      My first recommendation would be to move to V10.1 where you can make use of the Multi-Field key. This way your part and drawing can share the same item id.
      Second, you can use compound and run-time properties to get the data you need into a TC attribute on the item revision and then can map these attrs to Nx part attributes on your UGMASTER/UGPART dataset(s).

      • Jeremie FEBURIE

        Hi, thanks for your answer.

        Currently, my customer upgrade to TC9.1 (as TC10.1 is still not enougth mature from his point of view)

        I was looking for a OOTB solution and I have a new trail to follow : since NX9, Siemens announces a new relation : “Drawing Of” relation

        This relation could solve all my issues regarding attributes mapping and title block update

        I have to investigate more to see if this new functionality is available within TC9.1.

        • Teamcenter Heretic

          I’m pretty swamped right now, but real quickly… the DrawingOf relation has some very specific behaviors. Notable one of which is that is is for 2D representations only.

          It still suffers from the same issue where it must have a different item id. There is very little info available and I do not know anyone who uses this. Seriously I’m afraid that V10.1 is the only OOTB solution other than the ols school way of creating a different item type, “warting” the name (link “_DWG” and putting thisgs together like we have alwaya done.

        • Teamcenter Heretic

          I did a little more looking at the Drawing Of relation and at this point I really don’t understand the usefulness of it. I can se sort of what it is getting at, but a drawing object has both a Drawing Using and a Drawing Of relation…. so what sense does that make:

          • Jeremie FEBURIE

            Hi,

            I investigated a litle bit more too.

            In fact you don’t use both relations on the same item.

            “Drawing Of” is dedicated to link the “official” drawing of your 3D Model

            To create it with NX :
            – Create a new part
            – select “master” instead of specification
            – select the “Drawing” Item type (otherwise it won’t work)
            – assign ID, Rev and name
            – specify the ID and Rev of your 3D Model in the dedicated “Reference Part” zone on the bottom of the window
            – clic create (or OK)
            Then the Drawing Item is created with the “Drawing Of” relation

            “Drawing Using” is more used when you want to create an alternative drawing (eg : car with doors open, car in situation …)

            To create it with NX :
            – Create a new part
            – select “master” instead of specification
            – select the “Drawing” Item type (otherwise it won’t work)
            – assign ID, Rev and name
            – clic create (or OK)
            – Add a new view in the drafting module

            – select the 3D model from teamcenter (Id and Rev)
            Then the Drawing Item is created with the “Drawing Using” relation

          • Teamcenter Heretic

            Since you are investigating… if you do an Impact Analysis of you model, does the drawing show up?

          • Jeremie FEBURIE

            yes the drawing is displayed in both “where used” and “where referenced” searches in case of “Drawing Of”

            only in “where referenced” search in case of “Drawing Using”

          • http://plmdojo.com/ Scott Pigman

            Very interesting, Jeremie. Thanks for this investigation. I’ve often wondered about those relations myself.

            To summarize, you use “master” instead of the default, “specification”, and for Drawing Of you select the part item for the “Reference Part” zone. Correct?

            Questions that come to my mind:

            1. Do other CAD integrations use these relationships or do they define their own? I believe that IPEM, the Creo/ProE integration, defines its own relationship type to relate .drw items to .prt/.asm items.

            2. Can you configure NX so that the Drawing Item type automatically uses master instead of specification so that users don’t have to manually make the choice each time?

            3. Do drawings created this way still show the part(s) as components in a structure (i.e. BVR)? Lots of non-NX people have looked at me funny when I explained that parts were components of drawings.

            4. What if you have a multi-detail drawing that defines several parts? Can you select all of them in the “Reference Part” zone of the dialog?

            Thanks again!

          • Jeremie FEBURIE

            Here are my answers :
            1. No, only NX integration uses those relationships and “Drawing” Item type. Each CAD integration uses its own relationship management
            2. I don’t know
            3. Yes, in addition of “Drawing Of” relation, the system creates a BOM relation. so Parts are considered as Components of Drawings
            4. For multi-detail drawings, you should use “Drawing Using” relation (in this case, there is no “BOM” relation)
            In this case, you don’t select a reference part, but just add, in the drawing, a view of an external part…
            BR
            Jérémie

          • Teamcenter Heretic

            “…the system creates a BOM relation. so Parts are considered as Components of Drawings…”

            This is the most interesting thing I’ve learned here. That is how they are getting past the Impact analysis question. I guess then I can’t see any reason not to use the new relationship (other than I believe the second mouse does get the cheese).

            Quite honestly, I fond there to be scant information in the Siemens documentation and when I asked PD about this relation there was little feedback on why it was there, its intent and how it plays with the other parts of TC. Personally I wouldn’t use it but that is just based upon the number of times I’ve gotten burned trying to use something that Siemens touted as the “go-forward” methodology.

            So, in the end the Drawing Of relation simply reflects what we have been doing in the past with a BOM for the model which is being detailed. If you place multiple parts in the relation I would assume they are also getting added to the BOM.

          • Jeremie FEBURIE

            The “Drawing Of” relationship allows to insert 3DModel in the drawing title block (attributes mapping)
            You cannot do it with BOM relationship

          • Teamcenter Heretic

            Actually I believe you can 😉
            The mapping into the UGPART Allows you to traverse relationships.

        • Teamcenter Heretic

          If you look at this image you see the two ways I would recommend doing. The one on the top is the “classic” master model concept as touted by Siemens. It has some advantages and disadvantages.
          The bottom part of the image shows a separate part for the drawing. you create the drawing item, assemble into the part for which it is a drawing and then make the drawing in either the UGMASTER, or a UGPART as I have done.

        • Christoph Matthiesen

          Hi Jeremie, some years ago you discussed this topic regarding the “Drawing Of” relationship. You also described how to establish this relationship.
          I tried it in our system (TCUA 10.1.2.3 and NX 8.5) but without success. The relationship is not created.
          Are there any settings/configurations in NX/TC required in order to let the system create this relationship?
          Thanks in advance.

          • Jeremie FEBURIE

            Hello, this function appears only with NX9
            BR

  • Julia

    Hello,
    Could you tell what type of relationship do you recommend to use for link model revison and drawing revison? We use splitting the Model and Drawing into two separate Items. We can’t use only “Drawing Of” relation because we used NX and SolidWorks.

    Thanks
    Julia

Optimization WordPress Plugins & Solutions by W3 EDGE