Check In wt.part with CAD association does not publish a new representation?

[ScottMorris]

Anyone using publish.copyrepresentationsforward.part.restrict=false in their wvs.properties file?

The default value for this property is to be the same as publish.copyrepresentationsforward.restrict, which is how it is set in my system.

When wt.parts with CAD associations are iterated in the commonspace, a new representation is not created upon check in. This leaves many wt.parts w/o a representation due to the attribute, structure, replacement or link changes in Windchill that are not associated with the CAD application.

I could schedule a publish job for the various containers, but I am curious if anyone is using this setting and having success with it? It sounds like the right solution, but I am always hesitant to change a property w/o testing and some confirmation from others. Sometimes there is a hidden downside...

More details can be found in PTC CS Article CS61223

[jbailey]

By using this - are you trying to keep old representations from copying to a new iteration? 

[ScottMorris]

yes, for a number of reasons, the business does not want to change the default behavior of not copying forward representations. however, this creates an issue where BOM structures and attributes that are changed on wt.parts will not get published on check in.

here is a good example. if an item needs an attribute change, this can be done to the wt.part in common space. check in updates the value and everyone is happy. well, except for the folks creating and receiving a windchill package with this item. now that there is no representation associated with the item, no representation will be included in the package contents.

if we are creating a "quote" package, i like to exclude the source MCAD and inform the recipients how to use Creo View Express to view the 3D models and assemblies. whenever a wt.part is changed in commonspace, it loses its representation on check in and subsequently takes another representation out of the package.

this can be managed for a handful of updates to wt.parts, but we have wt.parts being updated in common space frequently.

[HelesicPetr]

Hi @ScottMorris 

I usually advice to set the general property to false to avoid the copy forward to next iteration because there was time gap when the visualization was out of date and wvs que was too busy and took 15 minutes to process the actual visualization for example.

In that situation if someone opened old visualization then he could do a mistake in a planning and manufacturing. 

This property has been introduced several years ago and when I test it it worked perfectly. 

No one has complained that modified WTPart was missing the visualization and CAD document has always up-to date visualization. 

PetrH

[Hemant_Chaugule · Accepted solution]

Hello @ScottMorris ,

My local Windchill is configured to copy forward the representations from previous revision. For that I have set below properties values:

publish.copyrepresentationsforward=true 

publish.copyrepresentationsforward.part.restrict=true 

publish.copyrepresentationsforward.restrict=true 

publish.documents.copyrepresentationsforward=true

publish.documents.copyrepresentationsforward.restrict=true 

however  you can follow to the information guide, for more information: https://support.ptc.com/help/wnc/r12.1.1.0/en/index.html#page/Windchill_Help_Center/WVSPrintManagement/WVSVisualizationCopyForwardProperties.html

Thanks,

Hemant