Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X
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:
SPRING A.1 (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
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
All,
From our 11.0 documentation:
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.