Skip to main content
K
khimani_mohiki15-Moonstone
15-Moonstone
April 12, 2021
Solved

Creating, Storing & sharing Drawings

  • April 12, 2021
  • 2 replies
  • 5122 views

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?

    Best answer by d_graham

    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

    2 replies

    B
    23-Emerald III
    BenLoosli23-Emerald III
    23-Emerald III
    April 13, 2021

    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.

    J
    jvonzastrow115-Moonstone
    15-Moonstone
    April 13, 2021

    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.

    K
    khimani_mohiki15-MoonstoneAuthor
    15-Moonstone
    April 13, 2021

    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

    D
    18-Opal
    d_graham18-Opal
    18-Opal
    April 14, 2021

    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.

    K
    khimani_mohiki15-MoonstoneAuthor
    15-Moonstone
    April 14, 2021

    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.

    D
    18-Opal
    d_graham18-OpalAnswer
    18-Opal
    April 14, 2021

    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

      Terms & ConditionsCookie settingsAccessibility statement