Skip to main content
D
DonSenchuk12-Amethyst
12-Amethyst
July 21, 2016
Solved

Add to workspace fails with strange override situation

  • July 21, 2016
  • 10 replies
  • 8090 views

I have a group of users that attempt to open an assembly and they get an 'Add to workspace failed".

For the failures, the event manager says a family table member would become incompatible but also give an override option that strikes me as a little strange. That override option is to override the latest version (C.0) with the oldest version (1.2).

The difference between the two is that the older version has a few instances that we broke out of the family table a couple of years ago (due to those instances not being a COTS number). I've done this dozens of times to dozens of different family tables and have never seen this cause a problem.

I've verified that the Add to Workspace Required Dependents settings are identical (Latest, Working) I've followed that up with changing this on both accounts, same error (Latest, Production Released)

I've started taking more drastic measures, such as removing what I thought were the offending components from the assembly, but it gives the same error for that pin (ms16562) even though it's not in the model tree anywhere.

The problem account can search, find and open the latest generic of that pin. He can search-find-open the components that were once in the family table but are now broken out. He just can't open an assembly that's using them even when I can.

Hopefully some suggestions steer me onto the right path. Dealing with Tech Support on ITAR matters is always a last resort.

Best answer by DonSenchuk

Hi Roy.

Turn out that the dozens of time I've done it before was because I did it correctly. This means saving the instance as it's own stand-alone part and checking it back in to Commonspace.

This time, it was someone else that just removed that instance and did NOT make it a standalone part. There were some lifecycle differences at different versions which meant Prod. Eng. was able to open the files just fine but downstream users were unable to open it at all.

While I could have just set the deleted instance to a released state, that would mean the downstream users would be unable to use the latest version.

My solution was to open the old version in a workspace, back it up to a local folder, break out the instance, rename the old instance in Windchill, upload the broken out instance from my local drive, check it in, rev it and manually set it to released. This creates a situation where that pin is not part of the family table any more but it was the quickest way to resolve it without holding up production any more than the issue already had done.

10 replies

T
TomU23-Emerald IV
23-Emerald IV
July 21, 2016

Just for fun, could you temporarily rename his cache folder and try again with a new cache and a new workspace?  The fact that he can't open it but you can seems to indicate a permissions issue (unlikely in this case) or a workspace or cache related issue (more likely).

D
DonSenchuk12-AmethystAuthor
12-Amethyst
July 21, 2016

I tried two workspaces but I didn't delete his cache. Will get on that as soon as he's back from lunch.

D
DonSenchuk12-AmethystAuthor
12-Amethyst
July 21, 2016

Thanks for all the help everyone.

It was a conflict with a part that was in the family table of MS16562 but was called something totally different than 'Roll Pin'. When I went through the structure tab of the assembly I just looked for Roll Pin assuming that they would all be named the same thing. While the assembly is not huge, it's also wasn't small enough for me to go piece by piece making sure each individual component wasn't from the old revision of that family table.

R
RoyCrerar1-Visitor
1-Visitor
August 3, 2016

Hi Don,

In my opinion you have been very lucky that you have not encountered this error before. Windchill has never liked removal of instances from family tables (this is a very common issue). Don't do it ever.

What has happened is the current release of the generic is in the workspace but the user has then asked for an instance that it no longer contains. Creo calls in the instance from the old file because it knew it was in an older version. The exact mechanics behind this i'm a little rusty on.

The fact you have been able to do this dozens of times before is probably because the files have not been reused since and you are getting away with it.

How do you resolve this? I'd be tempted to add the instance back into the family table temporarily to get the assembly to open. I would then suggest saving it out as a separate new file with new name and replacing that in the model. Remove the temp instance from the FT using undo checkout.

Hope that this makes sense to you.

D
DonSenchuk12-AmethystAuthorAnswer
12-Amethyst
August 4, 2016

Hi Roy.

Turn out that the dozens of time I've done it before was because I did it correctly. This means saving the instance as it's own stand-alone part and checking it back in to Commonspace.

This time, it was someone else that just removed that instance and did NOT make it a standalone part. There were some lifecycle differences at different versions which meant Prod. Eng. was able to open the files just fine but downstream users were unable to open it at all.

While I could have just set the deleted instance to a released state, that would mean the downstream users would be unable to use the latest version.

My solution was to open the old version in a workspace, back it up to a local folder, break out the instance, rename the old instance in Windchill, upload the broken out instance from my local drive, check it in, rev it and manually set it to released. This creates a situation where that pin is not part of the family table any more but it was the quickest way to resolve it without holding up production any more than the issue already had done.

    Terms & ConditionsAccessibility statement