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.

Creating, Storing & sharing Drawings

khimani_mohiki
14-Alexandrite

Creating, Storing & sharing Drawings

Currently we publish our Creo drawings in HPGL and create a content association with the WTPart, users outside of Engineering are encouraged to work "Part Centric" and go to the WTPart primarly and find the drawing from there, however many still search directly for the .drw file, to add to that we also store drawing from suppliers as PDFs in a WTDocument. So there is a lot of confusion amongst different user groups around the business about how to find drawings. Getting drawing out to suppliers is also problematic, some departments will open the drawing in Creo View and save out as PDF with terrible quality.

 

To improve access for everyone I was looking at Post-publishing the pdfs into a WTDocument which is much easier to find from the WTPart through Describing documents. I have this working but the WTDoc has a different version to the Part and the Creo Drawing, which will lead to massive confusion, I cant find a solution to keep the versions aligned, honestly I dont see the point of the WTDocuments created by Post publishing if the versions dont line up with the WTPart, its very hard to explain it to a non-Engineer who just needs to get the data down to send to the suppliers.

 

So what I want to find out is how is everyone else storing their drawings to provide easy access for users outside of Engineering?

1 ACCEPTED SOLUTION

Accepted Solutions

Khimani, 

 

I did not use post-publishing. 

I wrote all the code myself using Windchill and Java APIs.  In the use case I described everything was done using Expression robots in a workflow.  The code was in a custom Java file.  The Expression robot just pointed to the method in the class.

 

I'm not sure how you are working but the bottom line is the code can be run from a workflow or the afterloadermethod.  Either way should work fine.

 

In the use case I described we had a well defined process that the users were suppose to follow.  It became clear early on that it was going to make life easier for everyone (especially me) to automate the whole the thing.  The automation in this workflow went well beyond what I described.  It cleaned up WTPart associations, it revised objects too if necessary.  When done the WTPart's number and revision always match the associated WTDoc's  and EPMDoc's  number and revision.  And no iteration of a given WTPart was associated to anything other than a matching revision of WTDoc and EPMDoc.

 

David

View solution in original post

12 REPLIES 12

Change your output from HPGL to PDF. Then the users can pull up the PDF in CreoView, save as to disk and send it your suppliers or whomever. The PDF will be tied to the Drawing file as content, so it will still be easy to find in a Windchill search.

jvonzastrow1
14-Alexandrite
(To:BenLoosli)

That would also be my recommendation

I would also advise to have a look at Thingworx Navigate, which is much better interface for users who just need to find a drawing.

That is also an option, buthow does ThingWorx know which drawing to show for a Part, in some cases we have only calulated association between WT and Drawing? This is why I was hoping we could move entirely towards WTDocuments for drawing storage

Calculated association is the default setting for drawings in relation to wtparts. Using Navigate app View drawing will give you the associated drawings.

jvonzastrow1_0-1618318018267.png

 
 

 

We have tried that method, we want to keep HPGL as the default representation so we can mark up and review the drawing within Engineering whilst providing non-engineers with a PDF

With Creo View 7.1 you can do markup of pdf See solution 3 here

https://www.ptc.com/en/support/article/CS151418

 

TomU
23-Emerald IV
(To:jvonzastrow1)

Not unless you pay extra for it.

We have default to HPGL but publish PDF as secondary file type. Right now its available as part of the PVZ but can be pushed to secondary content of the CAD objects. This makes it easier to access as opposed to buried on the representation table.  Pros/Cons to both but this was a simple visualization configuration to implement.

Even though you have your recipe file configured to publish drawings as HPGL can't you also configure publishing rule to create PDF as Additional File?

Once the PDF is created as an Additional File you can run custom Java code pointed to by wvs.properties option publish.afterloadermethod. The code would get the PDF from the file vault and add it as content to whatever Windchill object you want as long as that object is a Content Holder (WTPart, WTDocument, whatever).

 

So, publish drawing; afterloadermethod runs and adds the newly published Additional Files PDF as content (Primary, Secondary, whatever) to the desired Content Holder.

This would get the job done for sure.  I've done something like this in the past.

 

We published drawing as HPGL, after publishing we got the HPGL file from the Windchill Vault, ran it through a third party tool to create a Tiff file (tiff was the company's standard) and then created a WTDocument at the same version as the WTPart and EPMDocument, linked the WTDoc to the Part and added the tiff as the primary content to the WTDoc.  This was all done automatically in a workflow.

khimani_mohiki
14-Alexandrite
(To:d_graham)

Hi Graham, yes we have pdfs published as additional files at the moment. I have experimented with post-publishing into a WTDocument but I coudnt find what I need to do to get the version of the Post-published WTDoc to match the WTPart or EPDDoc.

 

Are you using post-publishing to create the WTDoc, or another method to create and associate your WTDoc before the afterloader copies the additional files over? What you describes sounds exactly like what Im after as a method to put all Drawings as PDFs in a WTDoc at the same version as the EPMDoc. Im just not sure what tricks I need to employ to get it all working.

Khimani, 

 

I did not use post-publishing. 

I wrote all the code myself using Windchill and Java APIs.  In the use case I described everything was done using Expression robots in a workflow.  The code was in a custom Java file.  The Expression robot just pointed to the method in the class.

 

I'm not sure how you are working but the bottom line is the code can be run from a workflow or the afterloadermethod.  Either way should work fine.

 

In the use case I described we had a well defined process that the users were suppose to follow.  It became clear early on that it was going to make life easier for everyone (especially me) to automate the whole the thing.  The automation in this workflow went well beyond what I described.  It cleaned up WTPart associations, it revised objects too if necessary.  When done the WTPart's number and revision always match the associated WTDoc's  and EPMDoc's  number and revision.  And no iteration of a given WTPart was associated to anything other than a matching revision of WTDoc and EPMDoc.

 

David

khimani_mohiki
14-Alexandrite
(To:d_graham)

Thanks for your insight David, that sounds like the solution we need. I think I had been lead down the wrong path with post-publishing

Top Tags