Revising an instance without having to revise all the other instance in the family table

[Sam-Ravikumar]

Most of our parts are in family tables. We are in the process of implementing Windchill and we use Creo 3.0.

Is there a way to revise an instance without having to revise all the instances in the family table?

After setting the action to "Revise", make changes and while checking in, all the other instances have to be in work to be able to check in this particular instance.

Currently we are asked the following process to work around it. Is there a better way to do this?

Initially the parts are in the released state.

1. Set the action to “Revise” by selecting the Instance and related Generic Part. Make sure to collect all the WT parts related to the instance and the generic part. Make sure you are not selecting all the other instances.

2. Check out the Instance and related Generic Part and drawings.

3. Make changes

4. Ask Admin to set other instances of that generic part to “In Work”. The revised instance and the generic part cannot be checked in until all the other instances are in work.

5. Engineer Checks In the revised parts and drawings.

6. Engineer submits changed parts for promotion request

7. Admin sets unchanged parts (other instances) to Released.

[Robert-Altman]

We are currently using a similar process so I will be looking for others to reply.

The only thing we do different is that during the Promotion request the users are including the ones that were not revised but set back to "In Work"

This way Admin does not have to manual set them back to "Released" and they are captured in the history of the change. 

[STEVEG]

We basically do the same thing.  It's getting to be a little too much at times especially when some users don't understand what they actually need to do.

Our process is:

1. The user will ask the admin to demote the files first that won't change.

2. The user revises the objects that are changing and makes the changes.

3. The user checks all related files in.

4. The user adds all the instances to the change notice which will promote all objects to the correct state.  The user also adds a note to the Comments box of the change notice for the objects that did not change.  Something to the effect of "No change" and some other comment.

[BenLoosli]

You are asking for troubles if you revise only a few of your instances in a family table.

A family table may consist of hundreds of instances driven from a single generic, but if you export it, you get 1 file. There is no instance file created, only the generic. 

I limit family tables to hardware items or pipe tubes cut to a length. The hardware items rarely get changed because we built a wide range originally. Tubing and such, we will add a new length and always regen the entire table.

What sort of changes are you making that can be made to only selected instances of a family table? To me, that destroys the concept of family tables. You may be better off using a UDF or just a custom template or just doing a Save As to get a similar part design with a mod.

[STEVEG]

We have been doing this for many years now and it's worked just fine but you do have to be careful.

One of the things we do is if we are introducing a new part number to the table then we don't revise the existing numbers.

[STEVEG]

The other thing is we don't have any tables with hundreds of instances.  The most any table might have is 30 but the vast majority is anywhere from 2 instances to about 10.

[Sam-Ravikumar]

Steve and Ben,

Thank you for your reply.

We use family table to control diameters, thickness, fastener locations, switch on and off certain features etc.

We also use merge option to import a Semi finished part to create a finished part. Semi finished part has all the milling features, so its already been machined and we import that to create a finished part by adding certain final operations.

Usually we don't have more than 10 instances in the family table. There are scenarios where we might have to edit just one instance and we do that by changing the parameters in the family table of the generic part. But other instances are untouched, so in that scenario i guess we have to follow this process. And as you said when we add new instances, which we do often, we don't want to revise other instances.

Based on the replies I have received here, it seems like there isn't a better way.

[MikeLockwood]

At times, using inheritance can be a better approach than instances of a family table. 

[TomU]

I don't remember who said it, but someone (on this community) made the following statement:

"Only use family tables where there is a single drawing for the entire family and revision tracking by instance is not required."

---

If you follow that approach, then it won't hurt anything to revise and re-release all of the instances together since revisions at the instance level won't matter.

We have our share of family tables as well (that don't follow that statement) and generally I tell the users that if Creo sees a need to regenerate all the instances then they just need to revise and change all of them.  I'm not going to play games where I set certain instances back to 'In Work' just to keep the revision letter from getting bumped.  If nothing else, it helps discourage the users from making these kinds of family tables in the future.

[STEVEG]

The reason we do it is because we have revised a number in the past without any actual change.  When we did that it gave some of our vendors the opening to re-quote the cost of the part which often included a price increase.  Whereas if we kept it at the same revision then they couldn't re-quote it of the increase opportunity.

I don't work in the area that controls our vendors so I can't tell you if we kept them or moved on to others.