cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Enhancements to Revise Part and CAD Documents - 1. Revise Part Only

JenniferPierron
14-Alexandrite

Enhancements to Revise Part and CAD Documents - 1. Revise Part Only

All.

I am looking at how to better handle relationships between Part and CAD Documents when you Revise.

In this discussion, I would like to propose an enhancement to this use case:

Set Up:

  • You have your CAD Documents related to a Part using some kind of build rule: Owner, Contributing Image, Image or Contributing Content.
  • You have a use case to Revise the Part and 0 to (N-1) of the build associated CAD Documents
    • e.g.
      • You have multiple CAD Documents describing the Part (e.g. model, drawing, manufacturing); but you only want to revise one of the deliverables (e.g. manufacturing model)
      • You have made a change to info on the Part not communicated to CAD (e.g. Option choices, Attributes like Cost/material). These types of changes may require the Part to be Revised before check out/in; but since the information is not set in the CAD Document, you do not revise it.
      • You add/remove/change other related documents (e.g. specification, marketing info) and these changes may require the Part to be Revised before iterating it with new content.

  • In all of these circumstances, you end up having a single CAD Document version that has a build type of association to two Part Revisions:
    • e.g.
      • USE CASE 1 - Revise Part and Drawing
            • You revise the Part and its drawing:
              • BOLT A.10 (Design)
                • bolt.prt A.10 Owner
                • bolt.drw A.15 Content
              • Revise
                • BOLT A (Design) --> B (Design)
                • bolt.drw A --> B
          • RESULT
          • BOLT A.10 (Design)
            • bolt.prt A.10 Owner
            • bolt.drw A.15 Content
          • BOLT B.1 (Design)
            • bolt.prt A.10 Owner
            • bolt.drw B.1 Content
        • If this is still early enough such that you can check out/in bolt.prt without revising, then the system will try to iterate and build BOTH BOLT A.10 and BOLT B.1


      • USE CASE 2 - Multiple CAD Files:
        • You have a flexible component, spring.prt with different CAD representations: spring_ext.prt and spring_collapsed.prt
        • All are related to same WTpart:
          SPRING A.1 (Design)
          • spring.prt A.1 Owner
          • spring_ext.prt A.1 Image
          • spring_colllapsed.prt A.1 Image
        • You now decide you need to revise the spring; but your process does not require the flexible components to be revised as well:
          • Revise
            • SPRING A (Design) --> B (Design)
            • spring.prt A --> B
          • RESULT:
          • SPRING A.1 (Design)

            • spring.prt A.1 Owner
            • spring_ext.prt A.1 Image
            • spring_colllapsed.prt A.1 Image
          • SPRING B.1 (Design)
            • spring.prt B.1 Owner
            • spring_ext.prt A.1 Image
            • spring_colllapsed.prt A.1 Image
        • Now a user opens spring_ext.prt in Creo, which has inheritance feature. If s/he checks it out/in, then the system will try to build both SPRING A.1 and SPRING B.1
      • USE CASE 3 - Multiple Files CAD and Not CAD
        • In the system, the user has:
        • (Part) WIDGET A.10 (Design)
          • (CAD Doc) widget.prt A.10 Owner
          • (CAD Doc) widget.drw A.8 Content
          • (Doc) Widget Spec A.6 Describes
        • Now a PDM user needs to:
          • Revise WIDGET
          • Revise the Mfg Spec with new plan and price
          • Add a test plan
        • User revises:
          • WIDGET A (Design) --> B (Design)
          • (doc) Widget Spec A --> B
        • User then checks out B.1 (Design) and adds new doc, widget test plan A.1
      • RESULT:
      • (Part) WIDGET A.10 (Design)
        • (CAD Doc) widget.prt A.10 Owner
        • (CAD Doc) widget.drw A.8 Content
        • (Doc) Widget Spec A.6 Describes
      • (Part) WIDGET B.1 (Design)
        • (CAD Doc) widget.prt A.10 Owner
        • (CAD Doc) widget.drw A.8 Content
        • (Doc) Widget Spec B.1 Describes
        • (Doc) widget test plan A.1 Describes
      • If widget.prt is checked out/in it will try to build WIDGET A (Design) as well as B(Design)

PROPOSAL:

Change the system to only build the LATEST Part revision.

Any thoughts?

Anyone have a use case where building ONLY latest Part revision would NOT be good?

Thanks

Jennifer

8 REPLIES 8

Hello Jennifer

Sounds a great idea.

We've got the 3 kind of cases

+ some multi owner cases where some of the WTparts are in OBSOLETE (ie no modify Access rules) and others INWORK.

For example when manufacturing some new coloured or material WTPart, but stop others ....

Will be great if being able to configure this behaviour by a preference :

- LATEST yes or no

- may be also a list of authorized lifeCycle states for build action (or based on ACL ?)

- and nice to have ... provide a supported API/hook to be able to implement our own custom behaviour for filtering WTpart to build

I'm thinking also about WTpart managed with effectivities. We are starting to looking at this to be align with our ERP. in this case, we can have 2 or more revisons of the same WTpart .

one LATEST IN WORK but all other previous revisions "released for Production" . with just different dated effectivities ....

But not sure that's a valid use case .. as in most of cases , effectevities will handle structure/BOM change (so at least a revise of the CADDoc with the WTPart)

Regards

Jennifer,

This is quite a complex posting. After reading through, I like where it is going. Your proposal is if a certain version of a CAD file is associated to multiple versions of WTPart, then only build the latest version of the WTPart - don't build all versions of the WTPart. Yeah, certainly. That old A.10 WIDGET is old news.

I agree with Gregory Perasso. It would be very nice to make this a preference if possible. It probably doesn't need to resolve down to container level, but at least down to organization level. Maybe that is the core question: The change will be made...but does it need to be controlled by a preference for companies that don't want this functionality...or just force it?

My vote is preference-controlled function, default setting=No. This can be turned on to give the desired functionality in the supplied use-cases. (Or maybe in digging further, it is okay to set to Yes as default value?)

Hello Jennifer,

I post this question here. But may be I should create a distinct new idea

is there any plan to create a "minor build" action. By minor, I mean any actions persisted and saved in CAD file, that need a checkout/in of the CADDocument but does not change any Design Informations on WTpart side (ie attributes, structure... .viz )

In another word, having the ability to do a "light build" to remove the clock out of date status on the WTpart, without needing to Build it . Notably when WTpart is in a "stable Released lifecycle state"

For all cases where CAD engineers need to change something in 3D CAD for helping downstream usage:

-add some planes, axis, for CAM purposes ...

- create some exploded states for custome services ...

- cosmetic reasons

-minor fix in orthograph or grammar in annotations / parameters ...

-etc ....

regards

Gregory

Gregory,

I agree with your last comment.

Marco

Marco

All,

From our 11.0 documentation:

CAD Data Management: CAD Documents Revise Only the Latest Version of Associated Windchill Parts
Product: PTC Windchill PDMLink
Release: 11.0 F000
Benefit
When a Windchill part is associated to a CAD document with an owner, contributing image, image, or contributing content link, the CAD document now uses a build process that updates only the latest part version. This enables you to revise a Windchill part without having to artificially revise its associated CAD document to prevent a build error on the next checkin of the CAD document.
Additional Details
This behavior is consistent and supported across all actions that spawn a build process. Legacy data is supported without the need to upgrade.

Sounds good.  For what it's worth, SRAM's custom AutoAssociatePartFinderCreator (findSRAMPart), once it finds the candidate WTPart, checks to see if that WTPart has an Owner link to a previous revision of 'this' EPMDocument.  If so, it removes the EPMBuildRule link from the target WTPart to the previous revision of 'this' EPMDocument. 

Hi Eric,

if you say your custom auto associate part finder removes the EPMBuildRule Link from the target Part, don't you also "destroy" the history?

Björn

Good point Björn Rüegg‌‌ and thanks for the reply -- We can't actually delete the EPMBuildHistory -- if we try to .delete it, we get:

wt.util.WTException: The BuildHistory association is completely managed by the build and can not be created, updated, or deleted by hand

        at wt.build.StandardBuildService.vetoBuildHistoryAction(StandardBuildService.java:2983)

...because StandardBuildService traps and vetoes the PRE_DELETE.  We didn't try brute-forcing to get around that.

So we wind up with the old build rule deleted, but the history remaining.  So far hasn't caused any problems - let us know if you can think of any possible concerns.

Top Tags