family tables and windchill modifying/checking them in/out

[didriek]

When I work on a family table generic or instance I notice that windchill doesn't automatically check out en modify ALL instances and the generic?

What results in conflics when I want to check back in....

Are there settings you can configure that:

no mather what you do to a falily thable, ALL gets checket out and ALL gets 'modified' so I don't have troubles with instances that are not checket out and not displayed as 'modified'

I don't even understand why he doesn't check out all and modify all if it's needed to check back in???

It give's me extra work figuring out the conflicts while he knows all relations...

Thanks in advance,

Didriek

[GregoryPERASSO]

There's some preference to control checkin under Site/WorkGroupManager Client/Indenendently modify instances

But if you're in Creo / proE, by default .

If you change something in the generic that will impact all the instances (geometry, add a column in FT ...), when saving the generic, all the instances will be proposed for checkout

if you change something only in one line in the family table (ie modify a particular instance), when saving the generic, it will checkout the corrssponding instance. No need to checkout all the instances ...

You should not have conflict or missing "non checkout" instances ....

[didriek]

We have been working on a large assy full with family tables.

Now, I verified, regenerated a lot to reduce all the conflicts when opening the top assy...

What resulted in a huge modified workspace, but when I try to check in now I get the following conflicts for a part or 30 instances:

All checked out family table member have to be checked in together.....

And I recognize a lot of sheetmetal 'flat states' .... do I really have to open them one by one and make sure I modify them and check them out or are there some options to avoid this or do this quick?

Add to workspace does check them all out, but some of them are not modified and windchill wants them to be modified before checking in. However, since windchill knows the generic/instance relations I expected winchill to set them all to modified when working in the table... but as I have unmodified flatstated I don't understand, especially using a mapkey; verify-regenerate-save-close

Busy 2 hours now trying to check in these ***ing tables

[GregoryPERASSO]

If it can help, in the checkin windows, you can force checkin for parts that are check outed , even if they are not modified. ... So you're able to checkin all the FT, but you will have iterations on "non realy modified" parts ...

Or you can sort, or filter in a custom view, your workspace, display only checkout and non modified parts instances. And then undo checkout of these instances. You will then be able to checkin your FT, as only the generic and only the modified instances remains checkout

anyway, I prefer adding to workspace without checking out. and then let ProE propose the part to check out on the fly when I modify it.

regards

[egifford]

Greg,

Can you verify your Windchill settings that are permitting you to operate in the manner you are? What version of Windchill are you on?

Checking the site level preference you mention in your earlier post, the description states "for non-Creo FTs". I changed it as an experiment and Windchill PDMLink connected to Pro/E exhibited no change in behavior for what Larsen is describing.

We occasionally run into the situation Larsen describes when a workspace contains several assemblies or drawings that use various instances of the same family tabled part. The user goes to modify one of those instance parts or add an instance - apply check-outs etc. accordingly, make the modifications, verify, save. Go to check-in and it fails because there are instances of that generic part in the workspace that are not modified - therefore not eligible for check-in. If there are no dependencies within the workspace to the non-modified instances, they can be removed from the workspace and the check-in will work. However, the dependencies to the unmodified instances will keep this from working. In our testing, cancelling the check-out on the non-modified instances (or not checking out in the first place) either fails or does nothing to change the failed check-in behavior. One of our six groups has a heavily family tabled tooling component structure and frequently runs into this. Only solutions are to do something that triggers the generic to be seen as modified (add a meaningless parameter, regen & verify, save, take it back out then re-save) so everything gets verified and saves as modified, but that is klunky. For that one product - not site or org level - I'd rather find a switch that allows check-in of non-modified object or some way to get just the modified generic and new / modified instances to check-in.

Larsen - when you have a family table and add instances or modify an instancewithout doing anything that would change the definition of the other instances (add columns, change something in the generic...) the other instances don't get re-verified or saved as modified because they have not changed.

Erik

(WC 10 M030, Pro/E WF4 M220)

[GregoryPERASSO]

Erik,

we are in WC 10M030 with wildfire 5 M130.

By default, you should be able to modify the generic and some particular instances ... without checkouting all the FT ...

No particular preferences to set.

It Does not work ? if you try to use the "force checkout for non modify" button , in the banner of the Checkin wizard ?

We are also facing some strange behaviour with FT, notably on "old migrated" ones ...

coming from intralink, then pdmlink 9 ...

There's som healing scripts to run during migrator. And some issues on units when PTC introduce unit management between windchill and Creo (lot of cases with FT, when FT parameters are also designated ...)

May be , if you have lot of assemblies in your workspace, using different instances, it is conflict between intances versions and the neutral data of the FT. Are you using AsStored baseline to retrieve assemblies ?

regards

Gregory

[egifford]

Gregory,

Thanks for the pointer. I just tested what you outlined with a new model and it indeed behaved as you described. I’m thinking the issue we’re having (mere presence of unmodified & not checked out instances in the workspace blocks checking-in of the associated modified generic that has an added instance or other modified instances ) may be isolated to FT data from before we went to Windchill, which in our case is nearly everything.

On the second tab of the check-in dialog I tried the “undo checkout unmodified objects” and it did remove the checkout on a checked-out but unmodified instance, permitting the generic and new / modified instance to check-in. I’m guessing that is the option you are referring to. We generally only apply the check-out to files we intend to modify so wouldn’t normally need this option, but it’s good to know what it can do for us.

Healing scripts were run as part of our migration from Intralink 3.4. I’ll have to do some more testing to compare behavior of old data vs. new data as I suspect that’s where the difference in check-in behavior is rooted.

Thanks.

Erik

[didriek]

I need to read and verify all you have been posting... thanks for the info and insights!

What I did to be able to check in and update again is opening all the instances that gave coflics in Creo.

I opend the generic, modified it someway (surpressing a base feature for example) so Creo asked to check all out, veryfied all and that way I ended up with all instances and all genericas as 'checked out' AND 'modified' so I was able to check in...

Time consuming, but at that moment the only way...

Now I'll read your insights and see if this can be avoided or done differently...

(working in Creo 2 M040)