Windchill PDMLink 9.1, M040 and Wildfire 5.0, M050

[danjdial]

Folks,

We are using Windchill 9.1, M040 and we have discovered a troubling situation. Due to some unexplained issues we ran an experiment. The experiment consisted of two engineers, their respective workstations, and Pro/ENGINEER WF5 M050.

Sequence of events:

1. The first engineer created a new part, saved it, checked it into Windchill and erased it from Pro/ENGINEER’s memory, but left it in his workspace.


2. The second engineer checked the new part out made changes to it, saved it, checked it into Windchill then erased it from Pro/ENGINEER without erasing it from his workspace.


3. The first engineer then checked out the same part using the Pro/ENGINEER browser, then opened the part and observed that none of the changes the second engineer made in step 2 existed in the part. He then proceeded to make his own changes to the model, save it, check it in, erase it from memory and still left it in his workspace.


4. The second engineer then used his Pro/ENGINEER browser to check the model out, open the model in Pro/ENGINEER observing that none of the changes the first engineer made in step 3 were in the model, but that the changes he made in step 2 were in the model. He then proceeded to make more changes, save the model, check it in and erase it from memory but did not remove the model from his workspace.


5. The first engineer then checked out the model in the Pro/ENGINEER browser and observed that none of the changes the second engineer made in steps 2 and 4 were in the checked out model, but that the changes he made in step 3 were in the model.

The results in Windchill are:

• Four iterations in Windchill 1.1, 1.2, 1.3, and 1.4


• 1.1 is the model as created


• 1.2 is the model with the changes made by the second engineer in step 2


• 1.3 is the model with only the changes made by the first engineer in step 3, but without the changes the second engineer made in step 2


• 1.4 is the model with all of the changes made by the second engineer and none of the changes made by the first engineer.

Also before all the responses come in, it is impossible when two people are working on different aspects of the same massive assembly, using common parts to assure that each part is removed from the workspace before checking it out and modifying it. Also liberally using the Update command doesn’t seem to eliminate the problem. Finally, the User preference in Windchill, "Windchill Workgroup Manager > Server > Add to Workspace and Check Out > Reuse Content in Target Workspace" is set to "No" both at the site level and both user user levels.

It seems the way Windchill should work is to make sure when one checks out a file that it is truly latest and greatest file automatically. Windchill should know there is a newer iteration in common space and download it to the workspace.

Has anyone else experienced the same thing? If so how do you work around it or fix the problem? Am I missing some other overiding preference?

Sincerely,

Dan J. Dial

314 378 5922

[BenLoosli]

That is the way Windchill works. It is working as designed.

The reason it goes to the local workspace and does NOT do an automated download from the server is to allow you to experiement with different iterations and still share the changes with your workgroup.

The internal web browser would show that you did not have the latest iteration in the workspace and you should have then downloaded them to continue working with the latest changes.

If you are having problems with overriding the workspace iteration with the latest iteration in commonspace, then that may be an issue of configuration or a bug.

[danjdial]

Ben,

Thanks for the input. Personally I would like windchill to have a
preference that causes the automatic download of the latest version of a
file whenever I check a particular file out. Baring that it would be nice
if the "out of date" column was automatically in the default view of the
workspace. As it is thanks to your input I have added the "out of date"
column to the default "All" view of the workspace and will instruct my
users to keep and eye on this column.

Again thanks for the help.

Sincerely,
Dan

[MikeLockwood]

Terminology is critical.

"Check Out" in Windchill is only allowed for the latest iteration.
Having users frequently synchronize their workspaces is also a major element of best practices.

[jfrankovich]

Dan,
Check and make sure that the preference to allow check out of non latest iterations is set to no.
John



Sent from my Palm Pre on AT&T

----------

[danjdial]

Mike,

That is not true. Not only is there a preference that allows one to check
out the non latest iteration, but in the scenario I describe, 1.2 is
checked out when 1.3 is the latest iteration, and 1.3 is checked out when
1.4 is the latest iteration. In my opinion, Windchill should only check
out the latest version, but that is absolutely not the case.

Run the scenario yourself using two different workspaces. You will be able
to check out the not-latest-iteration and overwrite the latest version as
long as the older version remains in any of your workspaces.

Sincerely,
Dan

On Fri, Apr 6, 2012 at 4:55 PM, Lockwood,Mike,IRVINE,R&D <
Mike.Lockwood@alconlabs.com> wrote:

> Terminology is critical.****
>
> ** **
>
> "Check Out" in Windchill is only allowed for the latest iteration.
> Having users frequently synchronize their workspaces is also a major
> element of best practices.****
>
> ** **
>
> *From:* Dan Dial [
> workspace. As it is thanks to your input I have added the "out of date"
> column to the default "All" view of the workspace and will instruct my
> users to keep and eye on this column.****
>
> ** **
>
> Again thanks for the help.****
>
> ** **
>
> Sincerely,****
>
> Dan****
>
>

[danjdial]

John,

This is the first thing I checked and if I try to check out the non-latest
from Commonspace it is not allowed, but if an older version (out of date
version) of the file is in an old workspace, I can check that version out
no matter how old it is and check it in over the latest version. To run
the experiment yourself just create two workspaces put the same file in
each workspace then commence to editing them and watch how each workspace
can overwrite the work of the other.

Sincerely,
Dan

[jfrankovich]

Dan,
I've tried to reproduce this but I can't. I am not able to check out a non-latest version in the Commonspace, in the server-side WS, nor in the local ProE WS. But, I am not using the same versions as you. We are running 9.1 M060 and WF4 M210. Perhaps you have found a bug in that combination, but other than that it would seem like a configuration issue.
John

[danjdial]

That is interesting. Would you mind outlining your steps so we can make
sure we are apples to apples? I was able to reproduce the issue just by
myself by creating three works spaces putting the same file in each.
Revising the CAD Documents Attributes in one and checking the file in then
revising the attributes in the second workspace and checking it in and then
finally in the third workspace and checking it in. The result was 1.1 =
original, 1.2 = first checkin, 1.3 equals second checking without 1.2's
changes and 1.4 equals the third check in without 1.2 and 1.3's changes.

[jfrankovich]

Dan,

I followed your sequence of events using two separate user accounts and two separate PCs. Using that procedure, I could not complete step 3 as instructed since I am unable to check out a non-latest version of the file. See below:

John

Sequence of events:

1. The first engineer created a new part, saved it, checked it into Windchill and erased it from Pro/ENGINEER's memory, but left it in his workspace. ENG1: Created a new part in ProE. Saved it. Checked it in to Windchill using ProE WS browser. Erased from ProE memory. (ProE WS shows part at Version 1.0)
2. The second engineer checked the new part out made changes to it, saved it, checked it into Windchill then erased it from Pro/ENGINEER without erasing it from his workspace. ENG2: Added part above to WS using ProE WS browser. (ProE WS shows part at Version 1.0) Checked out part using ProE WS browser. Opened in ProE and changed part. Saved it. Checked it in to Windchill using ProE WS browser. Erased from ProE memory. (ProE WS shows part at Version 1.1)
3. The first engineer then checked out the same part using the Pro/ENGINEER browser, then opened the part and observed that none of the changes the second engineer made in step 2 existed in the part. He then proceeded to make his own changes to the model, save it, check it in, erase it from memory and still left it in his workspace. ENG1: Part is still in ProE WS at Version 1.0 and shows Out of Date icon. Attempted to Check out part from ProE WS browser, but it failed. Attempted to Check out part from separate WS browser, but it failed. Opened in ProE and attempted to modify, but got Conflict dialog prompting for Check out which again failed. Used Update icon in ProE WS to update the out of date file from Version 1.0 to 1.1. Opened in ProE and verified changes. Checked out part from ProE WS browser. Changed part. Saved it. Checked it in to Windchill using ProE WS browser. (ProE WS shows part at Version 1.2)
4. The second engineer then used his Pro/ENGINEER browser to check the model out, open the model in Pro/ENGINEER observing that none of the changes the first engineer made in step 3 were in the model, but that the changes he made in step 2 were in the model. He then proceeded to make more changes, save the model, check it in and erase it from memory but did not remove the model from his workspace.
5. The first engineer then checked out the model in the Pro/ENGINEER browser and observed that none of the changes the second engineer made in steps 2 and 4 were in the checked out model, but that the changes he made in step 3 were in the model.

[danjdial]

Well folks,

Here is the summary.


1. Windchill is not supposed to allow a person to check out the
non-latest version unless you have the "allow non-latest version checkout"
is set to yes.
2. Windchill does allow the scenario I described in 9.1 M040, this was
reproduced by Marc DeBower
3. The bug is resolved in 9.1, M060, as folks using that build do not
reproduce the experiment.

Conclusions, if you are on 9.1, M040, update your version to 9.1, M060.

Thanks to everyone for looking into this, I appreciate it.

Sincerely,
Dan J. Dial