Skip to main content
23-Emerald IV
July 5, 2018
Question

Config Spec Conundrum - How do I publish 'As Released'?

  • July 5, 2018
  • 6 replies
  • 10722 views

I'm running into two fairly significant problems with Windchill and I could really use some help.

  1. Additional files generated during publishing do not always agree with the corresponding models (at the same revision.)
  2. Users outside of engineering are unable to view all of the models in an assembly in Creo View.

Both of these situations are being caused by the publisher using the 'As Stored' config spec when the 'As Stored' version of the model is not the same as the 'As Released' version.  For example:

 

Drawing or Assembly

A.1 - In Work

A.2 - Released

 

Model

A.1 - In Work

A.2 - In Work ('As Stored' when drawing version A.2 was created.)

A.3 - Released

 

A.2 of the drawing/assembly and A.3 of the model are both released together, but when published the older, unreleased version of the model is being used.  For drawings this could mean the wrong geometry is displayed.  For assemblies it means that users outside of engineering can't even see the model since they are not allowed to view 'In Work' objects.  (We use positioning assemblies to dynamically pull the models in during viewing.)

 

In this simple example, switching to 'Latest' would fix the problem but it may cause much bigger problems in the future.  For example, if we add several new revisions to the model and then republish the drawing, the new representation for the old drawing (or assembly) will now show the latest models at revisions that didn't exist when the drawing (or assembly) was originally created. 

 

Drawing or Assembly

A.1 - In Work

A.2 - Released

 

Model

A.1 - In Work

A.2 - In Work ('As Stored' when drawing version A.2 was created.)

A.3 - Released

B.1 - In Work

B.2 - Released

C.2 - In Work

C.2 - Released.

 

Republishing the drawing after C.2 of the model is created means the drawing will now display C.2 instead of A.2 (or in a perfect world, A.3.)  Every time the drawing (or assembly) is republished the contents will change.

 

There seem to be two root issues here - user behavior and system behavior.

  • User Behavior - Is it realistic to expect a user to check out and re-save each drawing and assembly every time any component in the drawing/assembly changes?  Even when the change is just to an attribute?  Without re-saving, the 'As Stored' config spec. is pointing to an older version of the dependent objects.
  • System Behavior - Is there any way to allow the system to publish using an 'As Released' config spec.?  If not, what about publishing with the version references instead of object references?  (Version references always point to the latest iteration of an object at the specified revision.)

 

I've run some database queries and analyzing just drawings alone I have over 17,000 latest, released drawings where the 'As Stored' version of the drawing's model does not match the latest version of the same model.  (Most of these 'As Stored' and 'Latest' models are at the same revision, just not the same iteration.)  I can't imagine the situation with assemblies is any better.

 

Any suggestions?

 

Note - Publishing is automatic, not something users manually do.  Additional files generated during publishing are sent to both internal and external suppliers for manufacturing.  Promotion requests are being used in a limited fashion but the vast majority of the objects currently in the system were released via 'Set State' and we don't use WT Parts.

 

6 replies

23-Emerald III
July 6, 2018

Education on the part of your users that the drawing MUST be the last item saved.

The Model and drawing MUST be at the same version! You do not revise the model without also revising the drawing.

 

Modify the workflow with code that checks the drawing modified date with that of the model. If the model is newer, reject the check-in and do not publish. I know Great Plains Manufacturing has modified their system for this, but the code to do it is proprietary. I would love to have the code if someone develops it and can share it. Maybe PTC needs to modify the base code with a preference setting that requires the drawing to be the latest.

TomU23-Emerald IVAuthor
23-Emerald IV
July 9, 2018

It's not revising that's a problem, we revise both together, rather it's making additional changes to a model after the drawing or assembly has already been checked in.  It might be 10 seconds later, but it's enough to make the 'As Stored' config spec unusable.

 

The thing I'm struggling with is the need to check out and re-save the drawing and all assemblies anytime ANY change is made to a model, even if the change has no impact on the drawing and/or assembly.  For example, simply opening a model, hiding a layer, saving the status, and checking it back in now requires that the drawing and every assembly it's used in (and all of the parent assemblies all the way up the structure) to also be checked out and re-saved.  This seems nuts.  It's the same problem we are trying to avoid by not publishing 'Latest' - the never ending 'rev rolling'.

 

Does your custom code prevent checking in all assemblies if any component in the assembly is newer than the assembly itself, or do you just do this with drawings?

TomU23-Emerald IVAuthor
23-Emerald IV
July 9, 2018

Does your custom code prevent checking in all assemblies if any component in the assembly is newer than the assembly itself, or do you just do this with drawings?


I just realized this question makes no sense.  It should say, "does your custom code prevent checking in a model if any assembly exists anywhere in the database that references that model and isn't also being saved and checked in at the same time?"  That's really what we're talking about.  Never having a model newer than the assembly.  The only way to prevent that is to never allow a model to be checked in without ALL corresponding assemblies and drawings, right?

22-Sapphire I
July 6, 2018

As stored is generally the right and only choice that makes sense for publishing. 

Publishing results in a static image that has to synch with the models that the published drawing is displaying / published assembly is displaying.  This is different than a config spec applied dynamically to product structure, for which "latest released" is a valid option to apply.

TomU23-Emerald IVAuthor
23-Emerald IV
July 9, 2018

Publishing results in a static image that has to synch with the models that the published drawing is displaying / published assembly is displaying.


This is okay on the drawing side because the PDF we create of the drawing isn't going to care if some of the models displayed on the drawing are not released.  This doesn't work on the assembly side where we use extended positioning assemblies for all assembly publishing.  Users outside of engineering are only allowed to view released models.  If the 'As Stored' config spec. references non-latest, 'In Work' versions of a model then the full structure doesn't load in Creo View for these users.

 

It would be great if I could publish using 'Latest Iteration at Current Revision' of each dependent model since those are the versions being released.

 

I'm just really surprised other people aren't struggling with this.  Maybe it's more of an issue for us due to heavy use of positioning assemblies...

1-Visitor
November 26, 2018

Hi TomU,

we came across your request here, which very much describes a problem we are currently dealing with, too.

 

I wonder if you found any solution since you posted this question. Or any workaround?

Maybe you are interested in discussing this in more detail.

If so, please let me know.

 

Kind regards,

Benjamin

TomU23-Emerald IVAuthor
23-Emerald IV
November 26, 2018

I don't have a better solution yet.  I keep beating into everyone's heads that anytime they save a part they also need to save the upper level assembly and re-save the related drawing(s).  I have also contracted with a developer to create something similar to the BOM Release Rule for promotion requests.  I'm having him add a check to make sure the objects under promotion are all referencing that latest versions of the objects they are referencing.  Hopefully this will prevent this situation from reoccurring in the future.

15-Moonstone
December 12, 2018

Hi Tom,

Are you trying to publish CAD objects with the following Config spec by default? (see screenshot below) or do you want to publish those CAD objects with 'Latest Iteration at Current Revision' of each dependent model?

 

I once worked with you when creating the publish utilities publishing jobs based on EPMDocument's object identifier(OID) from a CSV in the article CS211115 and just want to help you creating a article with this custom publisher

 

Life Cycle Config spec:LC.jpg

18-Opal
March 8, 2019

Tom,

If this is still an issue I think I have a solution for you.

 

If I understand the problem correctly you want a snapshot of the drawing and the required dependencies in their latest configuration at the moment the drawing is released.

If this describes what you want this is very doable.

 

Have you tried using the APIs to create a ManagedBaseline that consists of the Drawing and all Required dependencies using Latest ConfigSpec. If you create this baseline the moment the drawing is released you'll have your snapshot.

 

When you publish you can reference the Baseline either using the GUI or if need be using the APIs.

 

When you publish using the APIs you pass the ManagedBaseline to the doPublish method by using it to create a BaselineConfigSpec.

 

Hope this help and sorry for the slow reply.  I've been out of the Windchill coding scene for a while but I am back in the game again.  If you know anyone who needs help let me know.

 

David Graham

18-Opal
March 12, 2019

Tom,

 

I've posted a suggestion publishing a baseline.

Since then I thought this a good problem and therefore have written a class that does exactly what you've described and best of all it does not necessarily have to be run at the moment the state is changed to the state in question.  You can run it days, weeks, months, whatever after the state change and it still build the same ConfigSpec you'd get if you ran it at the time the of the promotion.

 

The trick is to build a baseline that consists of all dependencies as they were at the moment the top level object was released.  You can get this time from the top level object's LifeCycleHistory.

 

Next you get a list of dependencies of the top level object at the time in question. The easiest way to do this is to use the CadCollector class.

 

Next get the latest iteration (that is not a working copy) of each dependency as of the time in question. If you want the latest iteration at a specific state as of the time in question that too can easily be tested for.

 

Add those latest iterations to a WTArrayList().

 

Create a WTCollection from the WTArrayList and then add the WTCollection to a ManagedBaseline

 

As for the drawing format, you can code such that the latest non-working copy is added rather than the latest as of the time in question..

 

The baseline is passed to the doPublish() method to be published.  That's it.

 

If you don't want to keep the baseline, as it's only for publishing, you can delete it when done.

In my code I keep it but I give it a description that describes what it is and why it was created.

 

 

18-Opal
April 19, 2020

Tom,

 

This is very doable but not OOTB. It is possible to specify a desired ConfigSpec when publishing.  In your case you want to specify a ConfigSpec based on a the state released.

The actual  publishing can be automated using the doPublish() method and pointing this method to the desired ConfigSpec.

A way to implement this it to fire off the doPublish() method from a workflow Expression robot after the drawing is released.

 

A listener written to listen for drawing's state change to release could also be used to fire off the doPublish() method.