Maintaining Rev History in Drawings

[SAP010101]

Using Windchill 10.0 and Creo Elements/wf5.

Would like to keep revision history in drawings which would include letter/number followed by a brief description of change. Current models have a parameter for REV and REV_DESCRIPTION. Looking for what others are doing and what is consensus on best practice/prodedure for having rev table in drawing automatically update with new rev and description and also keep previous rev and descriptions?

Thanks.

[TomU]

It's easy enough to display the current version (revision level and iteration) on a drawing. Typically you wouldn't have these values directly display in the history table because they will automatically change as the version of the model or drawing changes. We display the "live" version in the titleblock on the drawing, but everything in the history table is "dead" text. We don't want that changing automatically. I know of no way to get the history table to update automatically - primarily because there is no way to break the link between the previous "live data" when the new live data propogates through.

[dhermosillo]

This has always been an issue in every company I've worked for, and I've seen it done several different ways.

Since you want to use your user defined parameters, for each successive revision, you can make a new row, enter the live parameter callout in the cells of the new row, and then re-enter the previous row's information as dead text.

At my current employer, we use a workflow utility to capture comments, signatures, etc., so we just put the workflow number (which is also a user defined parameter in the model) in the rev description and omit the history altogether. If anyone wants to find the rev history of a drawing, they go to the workflow utility and search on the drawing number.

[GregoryPERASSO]

If using Windchill and WTpart and may be Change Management,

I think the best way is to do a "cultural change". And try to think "WTPart" , and not "Drawing"

These informations are all in PDMLink

Remove history, BOM , etc ... from CADDrawings ... and use a "dynamic" print function to print a Doc (PDF ?), which is a concatanate/watermarking of the Drawing + WTPart attribute + Change attribute (or at least revision history).

No need to modfiy and refresh drawings when just modifying or replace a small part in a multilevel BOM ...

You can then imagine different printing format depending on use case :

a simplified print without history for external purchase

a full print for internal use and review

an eletronic print for display on shopfloor ...

[SAP010101]

Thanks to everyone who responded but especially to Greg. I would like very much to have a 5 minute conversation with you but in the meantime I'll say your answer sounds like the best solution. At the risk of sounding like an idiot I'll just state what I think would work best for us and if this is what you're doing now and/or can be done "fairly" out of the box.

So essentially as you've suggested we blow out the bom and rev history stuff out of drawings and let WC, in this case WTpart within WC, do the work and push the info inputed within WC down to the final drawing by way of a superimposed image on a blank designated spot on the pro/e drawing where the bom and/or rev history block used to be??? If that's the case sounds awesome!

Furthermore, we could magically have multiple pdf drawings, ones with this info, and others without, etc...???

Maybe superimposing wasn't what you were suggesting and instead attaching this info a secondary sheet in the pdf or something? Like I said, would like very much to have a 5 minute (okay, who am i kidding, a 5 hour conversation with you)... 🙂 Thanks.

[GregoryPERASSO]

Hello Andy,

no problem to discuss on that topic

"push the info inputed within WC down to the final drawing by way of a superimposed image on a blank designated spot on the pro/e drawing where the bom and/or rev history block used to be??? If that's the case sounds awesome!"

It is exactly what I propose ... but unfortunately , not yet Out of the Box.

PTC works on some enhancements for CreOView and watermarking.... to be able to dynamically load in CreoView some custom attributes (today when opening a drawing, even if linked to a WTPart, we have only draw attributes .. not wtpart, change , etc ...)

And I suggest you to vote for my idea:

http://communities.ptc.com/ideas/1065

Today , you've got some solutions :

-the basic one, just print the info page of the WTPart, the BOM report, and the associated Drawing.

-there's a custom hook that permit to add in ProE file some attributes (for example WTpart number, Change Notice number , etc ...) as System parameter (like REV and REV_DESCRIPTION) . But in that case , it's more a workaround, as it is not dynamic. because stored in the proe file as parameter.

-a more user friendly way is to build a cognos report, based on the BOM report, and add some change Info and the pdf file of the converted (by the worker) drawing

-today , we use a custom function (based on Itext, a free java library that permit to build PDF files). We take the pdf converted by the ProE worker, and then add superimposing attributes (wtpart number, version , lifecycle states, etc ...). Superimposing is more complicated than just adding a secondary sheet, as you have to define the block size (for example by drawing format, etc ...) but nothing impossible and easy to define if your drawings are normalized ...

In my previous company, drawings have no more table. only the "geometrical drawing part", and a link to the wtpart ... all the other informations were printed dynamically on demand. It was realy the WTpart that is the "REFERENCE"

Next step is no more drawings 🙂 full 3D definition with FTA ..... but at least for internal use.... in a "no drawing" PLM context/company ... still need to be able to visualize FTA annotations ... notably for exchange with sub contractors, or a shop floor, that do not necessary have an access to internal PLM and Viz or same CAD tool ... for that PTC and other PLM vendors really need to understand that there will always have the need to print some "paper" , or freely vizualize 3D FTA model : free Product View express can't viz the FTA annotation ... so I can't deliver a 3D model with a viewer ...

just my thought

[SAP010101]

Hi Greg,

Again, thanks for helping me understand this issue. Please allow me to rant for a moment then I'll get back to the meat of the issue. I find it ironic/tragic/ridiculous that a product which has been out as long as it has, which costs as much as it does, as many companies which are using it.... that it still takes a rocket scientist to make the product do pretty much anything which is fundamental/common to all companies. It is crazy there isn't out of the box functionality or an intuitive GUI when obviously there are thousands of companies out there that have had to pay 100's of thousands of dollars in employee or consultant fees to get what they need out of WC. The biggest irony of all to me is WC one main purpose is "collaboration", you would think PTC would have "collaborated" with their customers or the customers would have done it themselves in an effort to take what's been done 1000's of times over at great costs and time spent to help their customers get out of box functionality....? Do you get what I'm saying?.... I digress.

Is there somewhere I can go to see examples of what you're talking about?... like "-the basic one, just print the info page of the WTPart, the BOM report, and the associated Drawing." with regards to this are you saying these would be separate documents? If so I can't see anyone going for that... would need to be attached somehow.

We're in the process of doing a large pre-update process to all pro/e files prior to migrating/importing everything into WC. Using a combination of Model Checker and custom scripts to do things like add missing parameters, designate parameters, relations, etc. I need to get a good understanding of how things will work down the road now since we're getting ready to update all of our files before going into WC. What I need to know is...

1. Should I create and designate parameters for all things related to the release procedure like REV, REV_DESCRIPTION, APPROVED_BY, APPROVED_DATE, DRAWN_BY,.... etc.? Once we get to the point where we setup the workflows in WC won't the "robots" set these parameter values which in turn update the pro/e drawings?

2. Similar to question 1… what about ECN stuff… will we need parameters in the pro/e files in order to display information related to ECN in the final prints or will we be able to somehow superimpose/attach this info into the generated pdf/dwg file? Sorry, I’m still not quite sure I get what you’re saying is doable in terms of easy to haven’t seen this done yet kind of thing.

I think the easy way for me to understand this again would be to “see” actual examples of finished implementations and what is involved in making it happen.

FYI... your vote link didn't work.

Thanks again for your help.

[dhermosillo]

Here's Gregory's link:

http://communities.ptc.com/ideas/1065

There's a bug that PTC can't seem to fix (how surprizing).

After pasting a link, you have to select it and unlink it or else the communities code will automatically double the link text.

[SAP010101]

Yep, found it already but thank you. Still hoping I hear back from him cause I'm still lost on how to accomplish the best approach method of handling rev history and avoiding redundant inputing of this info.

[GregoryPERASSO]

Hello Andy,

"Do you get what I'm saying?...."

Yes , totally. I've been working with Windchill and PTC since 1999 ... for different company/industry ... and this topic is recurent ... Notably from PTC which is now a major actor of the dynamic publishing since Arbortext buying ...

hard to explain to customers because of cultural change ... from CAD centric to part centric point of view. And not easy to illustrate cause not implemented OOTB...

" If so I can't see anyone going for that... would need to be attached somehow."

my example is extrem ... as you say it need to be attached ... 3 peace of paper with a paper clip ....

but basically.. it's what we do with a customization. to get a single PDF file of 3 pages ... that we can give to a subcontractor , linked to the Purchase order sent by the ERP ....

regarding your particular questions:

1. Should I create and designate parameters for all things related to the release procedure like REV, REV_DESCRIPTION, APPROVED_BY, APPROVED_DATE, DRAWN_BY,.... etc.?

No, cause most of these informations are automatically updated in proE file as "System parameters". Even if you migrate your proE files without these parameter inside. A download in the workspace will update the proE file. And normallly, a Creo View conversion by a worker will also publish with these parameters updated.

But if your drawing table use today your own parameter (for exemple use PTC_WM_REVISION instead of REV) ... you will have to update them to use Windchill system parameter , instead your historic parameter ...(carrefull ! by default only contains system parameter of the CAD Document. not WTpart or ECN. cf your question 2)

system parameter automatically updated :

2. Similar to question 1… what about ECN stuff…

Nothing Out of the box by default. But you can activate the specific class (and customise it depending your need). Describe in the PTC Document "using Creo with Windchill" in the chapter "Customizing the parameters in the Donload Service"

These class can may be customised to workaround your case 1. And download the Windchill version in a parameter named like your old one , used in your old drawings. So don't need to retrofit all your old drawings ... . Just change your drawing templates to use new Windchill system parameters ....

This class permit to add in proE file any "custom system parameter" . no need to desigante or create it. Windchill manage them as OOTB system parameter.

But this solution persist some som infos in the proe file. It is not the same strategy as a real dynamic publishing with superimposing attributes

regards

Gregory

[SAP010101]

Hey Greg,

Hopefully at some point my questions will become smaller than my answers. I think the easiest way to communicate is through examples and as much detail as can be provided. Currently WC is being used as a glorified storage area, beyond that not much has been setup. There are a few parameters mapped like BOM_DESCRIPTION, MATERIAL, etc… meaning designated in Pro/E and WC is setup to look for these so we see them and can edit values either in Pro/E or WC (2way communication). All drawing title blocks have parameters from models which include “who did what and when”, the company uses 4 names/dates, i.e. DRAWN_BY, MOD_BY, CHK_BY, APPR_BY and dates for each… so 8 string parameters total dealing with release procedures… well if you include REV and REV_DESC would make 10 total. We haven’t setup our workflows in WC yet but will involve these 10 pieces of info. We are in the process of updating all of our models via script prior to putting everything into WC.

Q1. Will WC create system parameters for all 10 pieces of info so they can be used in the drawing format? Ex. PTC_WM_CHK_BY, PTC_WM_MOD_BY, PTC_WM_MOD_DATE.

Q2. Didn’t understand what you said here, please clarify.. “...(carrefull ! by default only contains system parameter of the CAD Document. not WTpart or ECN. cf your question 2)”

Q3. If we wanted to avoid replacing drawing formats on all drawing put into WC to use system parameters couldn’t we just setup the workflow to automatically (via robots I believe is what they call it) to assign values to our 10 pieces of info as the document passes through the workflow? If so then we would need to have all 10 pieces of info designated in models correct?

Q4. If we removed rev history info and boms from our drawings we would obviously need a way of either showing or attaching this info to the drawing somehow. Could you please send me or show me an example of this?

Thanks again.

[GregoryPERASSO]

"Q1. Will WC create system parameters for all 10 pieces of info so they can be used in the drawing format? Ex. PTC_WM_CHK_BY, PTC_WM_MOD_BY, PTC_WM_MOD_DATE. "

Sytem parameters are default attributes. They commonly content Revison, dates, lifecycle state ... It seems that your APPR and CHK attributes need to be added.

solution 1:You can do that by creating classic IBA attributes in WC, designated it in ProE, and manage these attributes as you want (may be automatically in a workflow process for check and approval ...)

solution 2: You can also do that by customizing the download service(as describe in my previous reply) to get these attributes as System attribute. The difference is that you will not need to retrofit all your CAD datas to add these designated parameters in proE file ...

"Q2. Didn’t understand what you said here, please clarify.. “...(carrefull ! by default only contains system parameter of the CAD Document. not WTpart or ECN. cf your question 2)”"

Even If you link a drawing or a 3D model to a WTPart, and even if you manage them by Change management, there will have no WTPart or ECN attributes published as parameter in ProE. Need also to customize download service for that.

An other point in CreoView about attributes and watermarking. And assume you have linked your 3D model with owner link, and the drawing as content link to the WTpart

A 3D model opened from a WTpart info page will load WTpart attributes + CAD attributes. So you will be able to use them in watermarking

But not for the drawing. There's only Drawing attributes .. so no ability to watermark on drawing the WTpart number, State, etc ...

And no ECN attributes in CreoView ...

"Q3. If we wanted to avoid replacing drawing formats on all drawing put into WC to use system parameters couldn’t we just setup the workflow to automatically (via robots I believe is what they call it) to assign values to our 10 pieces of info as the document passes through the workflow? If so then we would need to have all 10 pieces of info designated in models correct?"

cf answeer of Q1

Yes if you use classic IBA and designated mapping

No if you customise download service. Add your 10 attributes in the download service, and they will be automatically be added as system parameters (even if not created/designated in "old migrated" proe datas), on each download/update in a Workspace, or during the worker publication process (impoirtant, notably if you modify theses attributes in a validation workflow. Your CAD doc will may be locked, so no checkin for republish ... just republish at the end of workflow and your drawing will be updated with correct parameters).

"Q4. If we removed rev history info and boms from our drawings we would obviously need a way of either showing or attaching this info to the drawing somehow. Could you please send me or show me an example of this?"

Because of confidentiality, need to build a fake. But we just create a PDF file of 2 pages, containing on the 1st page, the WTPart and BOM info, (part number, quantities, designation, material, etc ...) , and ECNs info and on 2nd page, the drawing ... (with the same technic , can imagine superimpose these info on one page , directly above the drawing ...but in our case, drawing formats were not retrofit so not necesseray always same size and place ... 2 pages are easy to manage. ...)

We can gerenerate this on demand by a custom action in the menu of the WTPart . But you can imagine generate this PDF at the end of your validation workflow, and attach it as secondary representation of your WTpart....

[SAP010101]

Greg,

Thanks for the detailed explanation. Regarding whether to use the classic IBA method or download service method... either way I would need to create a "hook" or "robot" (unclear on the terminology) to essentially assign values to parameters whether a basic param in Pro/E or a new system parameter when a file is pushed through the workflow. Example, when a drawing is approved for release the person approving would need to have his signature automatically assigned to the APPROVED_BY param or system param maybe called PTC_WM_APPR_BY. Can you either give me an example of what the java code looks like and where it goes or an example of such?

Thanks.

[GregoryPERASSO]

Andy,

We do exactly the thing you describe in one of our workflow. Get the user how validate a worflow "signature" task

In your workflow signature task, in the transition tab, "terminate" transition , you can add java code to get the user how execute the task, then get the drawing, and update its parameter IBA

may be this code will not compile as is ... a best practice is to use an extrenal class and call it in the workflow. Not to use too much java code directly in the robots ....

// get the user how perform the workflow task

WfAssignedActivity activity= (wt.workflow.work.WfAssignedActivity)self.getObject();

java.util.Enumeration allassig2 = activity.getAssignments();

while (allassig2.hasMoreElements())
{
Object a2= allassig2.nextElement();
java.util.Enumeration balots = ((wt.workflow.work.WfAssignment)a2).getBallots();
while (balots .hasMoreElements())
{
Object bal= balots .nextElement();

// here is the user how perform the task
wt.org.WTPrincipalReference user_ref= ((WfBallot)bal).getVoter();

}
}

//get the CAD drawing , here in my case I'm in a Change Activity workflow. But if your workflow is directly on the lifecycle of xour CADDoc , it is easyiest. The CADDoc will the the primaryBusinessObject variable of the workflow

wt.fc.QueryResult changeables = wt.change2.ChangeHelper2.service.getChangeablesAfter((wt.change2.WTChangeActivity2)primaryBusinessObject,true);
while (changeables.hasMoreElements())
{
wt.change2.Changeable2 cb = (wt.change2.Changeable2)changeables.nextElement();
if (cb instanceof wt.epm.EPMDocument)
{

if (((wt.epm.EPMDocument)cb).getDocType().equals(wt.epm.EPMDocumentType.toEPMDocumentType("CADDRAWING")))
{
String fullname = user_ref.getPrincipal().getFullName();

// update the IBA "APPROVED_BY"

LWCNormalizedObject obj=

null;try {

Locale locale = SessionHelper.getLocale();

obj =

new LWCNormalizedObject((Persistable) cb, null, locale, new UpdateOperationIdentifier());

}

catch (WTException e) {

e.printStackTrace();

}

obj.load("APPROVED_BY");

obj.set("APPROVED_BY", fullname);

obj.apply();

PersistenceServerHelper.

manager.update((Persistable) cb);

// after updating the IBA, may be you have to republish the drawing in worker with the new value for the APPROVER.

If your worker is configured to publish on a lifecyle state change , and there's a SetState "RELEASED" robot after that in your workflow, no need to do that ...

}

}
}

[bwudtke]

Hi Gregory,

I like the idea of using the watermark functionality from Creo view to pull in a attribute from windchill for the revision change.  What would be the best attribute for creo view to look at and where would you put that information?  In the change task?  I would assume there would be multiple attributes here that would simply be "=" to the revision attribute.  Also can get funky depending on the amount of information on revision, how does it know what to do with the text if it would have to wrap?