Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Pulling an item out of a family table 1

Status
Not open for further replies.

qnen

Mechanical
Oct 24, 2008
42
Wildfire 5.0 with Windchill 9.1 M020.
I would like to pull an item out of a family table and make it a stand alone part. Unfortunately the part is used in several different assemblies, all of which have been checked in and promoted to a RELEASED state.

My question is "Has anyone been able to pull a part out of a family table and make it a stand alone part?"
"Is this doable in Creo 2 or Windchill 10.x?"

Thanks


Michael Kuehnen, Kansas City
 
Replies continue below

Recommended for you

There is a config option which will ensure that it works outside windchill, may not be safe to use inside windchill. I would make your released assemblies into baselines (which will store the iteration as well as revision) to ensure that you can get back to where you are now.

try_noninst_on_fail YES
 
Why do you feel the need to remove the instance from the family table?
Did you set up the family table originally so you know its history?

Any assembly that uses the instance will still use the instance when retrieved unless you revise all Where Used assemblies.
Any new assemblies made from these old assemblies will use the instance, unless updated. You can NOT depend on your designers to make the substitution at a later point in time. Been there, had that problem.

I would recommend a new part number for the item you want to remove. I would hope it has some change to its form that is driving this request. Do not delete the instance from the FT.

You need to load the generic and the instance into a Pro/E session and then do a save as to the instance. Being in PDMLink, it will require a new part number as the existing number is in use by the FT instance/generic.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli
 
Thanks for the feedback. This is what I kind of expected to hear.

The background of the family table is this. About 15 years ago, we used family tables for a lot of our common parts like timing sprockets. We modeled one generic and build into it the features and intelligence to morph into XL, L, H, HTD, Polychain, w/wo hubs, flanges, etc. That FT now has about 100 instances in it. We were also a little lazy in that if the part was older (>15years) and had been represented by an ACAD drawing, we left the drawing alone and just used the Pro/E model as more of a place holder in our assemblies.

About 2 years ago, we started down the Windchill / PDM road. We also started a push to make our Pro/E data more accurate and if a part is in Pro/E, the drawing should be as well. Unfortunately due to staffing, this is done when the engineers have free time to do it. What we are finding is that as we try to create a drawing of a sprocket, there is always some parameter we didn't orignally put in the table that should be in order to track the information correctly with the part. Adding something to the generic table requires checking all the instances out. Some instances are in the RELEASED state (pretty much read only) and some are in a HOLD state, etc....... Pretty much a huge PIA to make all things editable, make the additions, and get the instances back to where they came from. (Other processes depend on accurate states of parts).

The feeling here is that with PDM, family tables are not well suited for large collections of similar parts (except maybe hardware) and everyone wants to get some parts out of tables and make them standalone. I was hoping someone had found a way of doing that, but my experiments were leading me to the conclusion that it was damn tricky and not worth the work.

thanks again


Michael Kuehnen, Kansas City
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor