Published drawings using the wrong version of the model

[STEVEG]

I have a little bone to pick with publishing in PDMLink.

It turns out that every once in a while we come across a drawing that was not published correctly.  One of my users came across a previous version that had a wrong published view.  I did some investigation and this is what happened.

There is a drawing and part model with revisions from 1 to 7.  This user was looking at rev 1 because they were looking at the history of the part.  Rev 1 of the drawing has iterations 1-4.  Rev 1 of the model has 1-2.

.drw version 1.3 was checked in with .prt 1.2.
Then the .drw was checked in one more time alone and created 1.4.

As I mentioned already there were subsequent revisions done to these files and several were all done prior to us migrating from Intralink to PDMLink.  Once we migrated we obviously published all our files.

Here is the problem.
Because the .drw version 1.4 was checked in without its model it wouldn't pull up the latest iteration of revision 1 of the model.
When that happens Creo pulls out the latest VERSION of the model...meaning, the .drw version 1.4 was published with the .prt version 7.2.

To verify this I tested it.
I started a new workspace.
I added ONLY the .drw version 1.4 to it.
I opened the drawing in Creo.
The .prt version 7.2 was added to the workspace.

This is not good and sort of disturbs me.  I contacted PTC about this and eventually they basically said that's the way it works.  (Intended Functionality)

I am torn on how to feel about this.  On one hand I understand why it did what it did but on the other hand my thought is why the software isn't written such that when the drawing is checked in that PDMLink/Intralink should use the same revision and the latest iteraion of that revision as its reference model.

As a sort of solution I created a Baseline feature of .drw 1.4 and .prt 1.2.  Then I manually sent to the publisher the baseline to be published.  I don't like this solution but it's the only way I can think of to get the drawing published with the correct version of the model.

Does anyone know if there is a setting for this?

[TomU]

There is a logical flaw in your test.  Creo is usually configured to pull the latest automatically into the workspace if it's not already there.  Putting just the drawing in your workspace and then opening it is no different than having nothing in your workspace and then open the part (on the fly).  Unless you change how the system is configured, or manually add a different version, you are automatically going to get the latest.

On the other hand, the publisher is most likely NOT configured this way.  Usually the cad workers are configured to publish the "As Stored" config spec.  This means whatever model was in the workspace when the drawing was saved is the version that will be used when the drawing is published.  Yes, you still have a problem if the user checked in the model and drawing and then later saved and checked in the model a couple of more times (but still at the same revision.)  When publishing the drawing will still be looking at the earlier version of the model, not the latest iteration at that revision.  It would be really nice if the cad worker could use an "as matured" or "as stored revision" config spec instead.

[STEVEG]

But there is no As Stored version of that specific version of the model and drawing.  That's why I had to create the Baseline and publish that.

[BenLoosli]

You are right, your exact drawing/part latest revision being saved do not exist. It has caught us here before, too.

Your users need to be sure that when they release a drawing it is referencing the latest model. There can be code written in to the promotion request to verify that the latest drawing is referencing the latest model.

As Tom said, by default, Creo opens the latest version of anything unless you specify something else. Add to workspace is configured, at least here, to add the As-saved models of a drawing.

Neither option would have caught your situation or mine, hence the need for customizing the promotion request code to always utilize the latest model when a drawing is being promoted. This also requires the users to initiate the promotion request against the drawing, so it can pick up the latest model. Assembly drawings have an added complexity due to components being revised at different times plus the form/fit/function rule to determine revision or new part number.

[STEVEG]

I assume that code could also be written for change management CN's?

[dschenken]

"why the software isn't written such that when the drawing is checked in that PDMLink/Intralink should use the same revision and the latest iteraion of that revision as its reference model."

I expect it's because that would result in someone else coming up with the opposite problem and wondering why it can't it do the thing it does now. It is not always possible to have a single software to answer deal with a disconnect that humans force on it.

For example: 123,456. Is this one hundred thousand and some as it would be portrayed in the US or a bit over one hundred as parts of Europe would recognize it?

Still, heck yes, it's annoying when there is a mismatch between what one expects and what one gets with operations that would seem to be parallel, but are not.

[STEVEG]

That's a good point but then give us an option to set.

[RandyJones]

Steve Galayda wrote:

That's a good point but then give us an option to set.

Check out this property: publish.configspec.default.useasstoredifavailable

WVS Config Spec.

[STEVEG]

That is the As Stored option and this specific version of the drawing has nothing stored with it.

[TomU]

From a database perspective I'm struggling with this.  I'm almost positive the as-stored information is created in the associated table every time something is checked in.  The only way I can imagine this happening is if you physically deleted everything else from your workspace prior to checking in (and even that will throw an error.)  Are you saying that when you try to add this drawing to a workspace that the "as-stored" option is not even listed?  If yes, any idea what is causing this condition?

[STEVEG]

The As Stored is there.  What I am saying is from a search results window I check the box for the drawing only.  Then I select Add to Workspace.

I go to the Advanced tab and there is a drawing, a part model and a drawing format listed.

When I change it to As Stored the only thing listed is that drawing.  No drawing format and no model.

[TomU]

I'm still trying to figure out how to create this condition...

If you create a new tab in Windchill, turn on the relationship report, and then set the dependents to "As-Stored", does it also just display only the drawing?

[STEVEG]

Yes.  Only the drawing.  These files were imported from Intralink so it could be related to that.

[TomU]

Ah, that makes sense then.  Windchill legitimately has no idea what version of the dependent is required.  Does checking or not checking this box have any impact on what gets added to the workspace?  (I'm assuming dependents is set to 'required'.)

Yes, it would be nice if the revisions could automatically align on the fly when adding to the workspace but I imagine there are plenty of companies that don't require the revisions of their models and drawings to be kept in sync, in which case this wouldn't work.

[STEVEG]

Checking that box brings back the model and drawing format but the model is the latest version which is 7.2.

"Windchill legitimately has no idea what version of the dependent is required."

That's what I thought and why I mentioned I am torn on how to feel about it but it's frustrating trying to explain something like this to a casual PDMLink user.  And it's even more frustrating just no finding this out thinking how wide-spread this could be.

[TomU]

It seems like your data wasn't properly migrated from Intralink.  I just took a look at some of our old drawings and the as-stored relationships are correct.  We migrated from Intralink to Windchill back in 2011 and from what I can tell, all of these relationships were preserved.