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

JenniferPierron · ‎Oct 10, 2014

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
    - 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
    - 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

GregoryPERASSO · ‎Oct 10, 2014

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

BenPerry · ‎Oct 13, 2014

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?)

GregoryPERASSO · ‎Nov 03, 2014

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

Marco_Tosin · ‎Nov 04, 2014

Gregory,

I agree with your last comment.

Marco

JenniferPierron · ‎Oct 14, 2015

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.

ericstarkman · ‎Oct 18, 2015

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.

BjoernRueegg · ‎Oct 19, 2015

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

ericstarkman · ‎Oct 19, 2015

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.

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

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