Skip to main content
D
17-Peridot
Dobi17-Peridot
17-Peridot
September 23, 2023
Solved

Best practice for Supersedes and Publish to CAD

  • September 23, 2023
  • 2 replies
  • 1943 views

I'm embarking on a "remove duplicates" effort in our environment and am doing some tests to finalize how best to approach it. 

 

The obvious "Replace with New" and "Replace with Existing" WTParts seem to be the way to go. 

Looks like "Supersede" and adding effectivity impacts WTPart for any downstream efforts - like eBOM/mBOM converstion and flagging components. 

 

I'm struggling with understanding what or how "Publish to CAD" is supposed to do. Best I'm able to get it to work when I replace a WTpart in a structure is to have it replace the part in my CAD assembly and then remove everything else in that assembly. That seems the opposite of the desired behavior. Am I missing something? 

 

Is there a feature in "Supersede" that will replace or disallow use of a superseded component or is the best it offers a flag? 

Best answer by Dobi

This was an educational journey for sure. 

 

tldr:

"Publish to CAD" on replace does in fact work... sort of. But:

  • The failures in Creo were replicated by PTC Tech Support and confirmed as a result of having "regenerate_read_only_objects no" set in the config.pro
  • In NX, it works great but the replaced part remains in the model-tree as suppressed and the user needs to take more firm action to delete desired

 

longer version:

I had a few calls with PTC Tech support and recorded videos of creating a dummy assembly with a few components and then checking it in. When I would in the WTPart structure go to replace a compoment with a different one and sync/update eveyrthing in my workspace, the behavior was:

  • on first open, I get the view changes screen. This shows correct things to be replaced
  • I select ok and the model ONLY displays the new incoming part

Turns out that in my config.pro I have "regenerate_read_only_objects" set to no. So:

  • with that set to no
    • I had to close the assembly after the initial "view changes" and do so without saving.
    • then re-open the assembly
    • on the second open, the correct changes are displayed
    • check out the assembly, save and everything is fine
  • with that set to yes
    • The assembly updates on first go but... now I'm torn about this Dobi_0-1696607881113.png

       

    • Hopefully the "lock-on-add" and permissions are sufficient to keep unintended changes at bay
    • it's either this or open each assembly twice to get the changes to go through. 

In NX - since the config.pro doesn't matter for it - replace and publish to CAD works as expected. A replaced component is suppressed in the assembly and the new incoming component is added at the bottom. I did have some struggles with different association types (owner vs. image for multi-CAD) and still have to try replacing a Creo file with NX in a structure ... 

 

Supersedes seemingly is only good as a flag and tracking of a change, but the change still has to happen on each individual BOM and CAD... so looks like this will be a long-term exercise. 

2 replies

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
September 25, 2023

I have not used Publish to CAD, more information can be found here:

https://support.ptc.com/help/wnc/r12.0.2.0/en/#page/Windchill_Help_Center%2FTDDPublishToCAD.html

From I high level, it tries to publish BOM changes to the associated CAD assemblies. So if you are replacing a part on a BOM, it will find the related CAD associated to that Part object and swap it out. I believe this is part of Top Down Design and predicated on some fancy assembly definitions that you may not be using. If you were doing heavy options and variants, this is kind of a must. 

 

There is no feature I know that prevents use of a superseded component to be used. In our business, its not a clear line. This is more of a referential pointer for users to indicate a part was replaced by another and to go there. You would need a business rule or customization if you want to block use as a hard error or condition of release. For example, say a component is obsoleted by the OEM but we have a ton in stock. You might be ok using it for now but want to steer new design to another component. What might have been a hard rule now has an external, time dependence and is a bit fuzzy. I would view these features as tool and design your business process around them.

D
17-Peridot
Dobi17-PeridotAuthor
17-Peridot
September 25, 2023

Thank you for the pointer! 

My experience (on Windchill 12.0.2.8 and trying this out with a Creo assembly in my dev environment) doesn't seem to match the instructions. If I replace a part in a WTPart BOM and publish to CAD, it replaces the part I wanted yes... but it also removes everything else - which I don't want. I doubt that's intended functionality. Added complexity then will come up since we use Creo and NX and the latter isn't on the "publish to CAD will work" list.

 

Perhaps this requires a literal reading of what it's doing: publishing things that have a build-status of "To Be Built"? In which case, the entirety of the assembly would have to have the status toggled to replace a single part? Doesn't make sense. 

 

In that instance, a replace operation at the eBOM level has to be followed by a manual CAD replace operation? 

 

As for supersession, it sounds like with it just being a flag best I can do is have a "superseded" or "obsolete" state that restricts the usage of the part and as I go through my cleanup effort the parts that are processed are set to an unusable state. Does it do anything for mBOMs? In my sample assembly when I superseeded a part, there wasn't a trigger at the mBOM level either. 

 

In either case, i'm not seeing a way of just replacing/swapping duplicate components without needing to go into individual CAD models. And supersession is starting to look more like just an icon flag with little behind it. 

 

 

    D
    17-Peridot
    Dobi17-PeridotAuthorAnswer
    17-Peridot
    October 6, 2023

    This was an educational journey for sure. 

     

    tldr:

    "Publish to CAD" on replace does in fact work... sort of. But:

    • The failures in Creo were replicated by PTC Tech Support and confirmed as a result of having "regenerate_read_only_objects no" set in the config.pro
    • In NX, it works great but the replaced part remains in the model-tree as suppressed and the user needs to take more firm action to delete desired

     

    longer version:

    I had a few calls with PTC Tech support and recorded videos of creating a dummy assembly with a few components and then checking it in. When I would in the WTPart structure go to replace a compoment with a different one and sync/update eveyrthing in my workspace, the behavior was:

    • on first open, I get the view changes screen. This shows correct things to be replaced
    • I select ok and the model ONLY displays the new incoming part

    Turns out that in my config.pro I have "regenerate_read_only_objects" set to no. So:

    • with that set to no
      • I had to close the assembly after the initial "view changes" and do so without saving.
      • then re-open the assembly
      • on the second open, the correct changes are displayed
      • check out the assembly, save and everything is fine
    • with that set to yes
      • The assembly updates on first go but... now I'm torn about this Dobi_0-1696607881113.png

         

      • Hopefully the "lock-on-add" and permissions are sufficient to keep unintended changes at bay
      • it's either this or open each assembly twice to get the changes to go through. 

    In NX - since the config.pro doesn't matter for it - replace and publish to CAD works as expected. A replaced component is suppressed in the assembly and the new incoming component is added at the bottom. I did have some struggles with different association types (owner vs. image for multi-CAD) and still have to try replacing a Creo file with NX in a structure ... 

     

    Supersedes seemingly is only good as a flag and tracking of a change, but the change still has to happen on each individual BOM and CAD... so looks like this will be a long-term exercise. 

    Terms & ConditionsCookie settingsAccessibility statement