Skip to main content
M
MIchael_Ohlrich1-Visitor
1-Visitor
July 27, 2012
Question

Family table settings?

  • July 27, 2012
  • 4 replies
  • 2492 views
Hello everyone,

I have an interesting / terrible issue we stumbled across today. It seems that something has changed in how Windchill or maybe CREO handles family tables.

We have recently (May) upgraded from WC9.0 & WF4 to WC10.0 & CREO 1.0. We have many family table common components like washers, screws, etc.

Today - I had a designer adding a washer to the family table and he complained that he couldn't do it with out checking out the WHOLE family table. This is an issue because some of the washers are released for production which means that they would have to be revised for no reason before they could be checked out. I figured that he was doing something wrong but, it turned out actually he was following our documented procedure. There is a "new" window that pops up now when you are adding an instance to the generic.

[cid:image002.jpg@01CD6BFF.B87106E0]

I did a sanity check and we are not able to even update a current instance without checking out the whole family table either.

Does anybody know if this is new intended functionality?
If so is it driven from WC or CREO?
And how can we go back to SN(not)AFU, config setting maybe? (I could not find one)

Any help would be much appreciated...

Michael Ohlrich - Design Engineer/CAD Admin
mohlrich@benchmade.com<">mailto:mohlrich@benchmade.com>
(503) 655-6004 ext 122
[cid:image003.jpg@01CD6BFF.B87106E0]
Benchmade Knife Company
300 Beavercreek Road
Oregon City, OR 97045
www.benchmade.com<">http://www.benchmade.com>

CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients. If you are not the intended recipient, (or authorized to receive for the recipient) you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please destroy all copies of this communication and any attachments and contact the sender by reply e-mail or telephone (503) 655-6004).


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

4 replies

B
23-Emerald III
BenLoosli23-Emerald III
23-Emerald III
July 30, 2012
I think PTC is just now enforcing what they have been saying all along.
The whole should always be checked out and back in to be sure that all the instances are in sync with the generic.
If you don't do it then you get instance 345.C loading generic 12345.F when 12345.H is the latest generic.
Now when you go to add 789.A instance, it isn't in the family table because you don't have the latest generic loaded.
It is a 2-way relationship that MUST be maintained at all levels across all instances.

Thank you,

Ben H. Loosli
USEC, INC.
P
ptc-19327451-Visitor
1-Visitor
July 30, 2012
I think this type of problem is an issue in most (if not all) PDM
systems out there.



I would argue that the instances should act as standalone parts with
respect to dimension changes, but adding a feature to an instance also
adds a feature to the generic and should cause a mass update of the
generic and all of the family table parts (bummer).



I wonder how this is different than Interchange groups. Adding an
instance to an interchange group should cause an update of the
interchange group, but should not cause an update of all of the members
of the group. Adding a feature to a member of an interchange group
should not cause a mass-update of the group. Changing the interchange
group properties should not cause a mass update of all of the members of
the group.



With supplier downloaded parts on the rise, maybe it's time to get rid
of family tables for common parts, hardware, etc... and go with
Interchange groups.



Just my $.02, since I don't use I-link or W-chill, and don't see
implementing this in the near future.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317
K
kimndave91-Visitor
1-Visitor
July 30, 2012
One of the problems with supplier part models is they usually don't
carry characteristics beyond the geometry.

A supplier part casn be repeatedly downloaded and saved with program
specific prefixes, or changed file name to match their final component
name (washer_thk anyone?). Traceability is polluted and
interchangeability becomes a matter of guessing if a part already exists
or, more often, taking the time to create or download yet another part
to fill a need that could have been filled instantaneously.

An irritation is suppliers who hyper-detail or super-mark the parts. A
part with a few dozen nominal surfaces will get a trademark tattoo that
carries a few hundred extra surfaces where a datum curve would do the
same. When the part represents an actuate-able assembly, there is no
option to change it.

Users don't often realize that saving a few minutes to model a part by
downloading one costs tens of times that for all the users who get to
handle the bloated, inflexible result. Perhaps that's because there is
no way to efficiently trace the cost paid by the community for the
efficiency of the individual?

As an aside - PTC - consider software profiling. Showing the details of
how modeling techniques affect performance would greatly help the users
in the trenches.

Dave S.


P
ptc-19327451-Visitor
1-Visitor
July 30, 2012
I agree that the customer parts are average at best and are hardly ever
used 'as-is'.

We usually import a customer model, from a .STEP file, evaluate the
model for features, de-feature the model of 'real' threads knurling,
etc..., add parameters, csys, planes, material definition and save under
our p/n system.



Some vendors offer pro-e models, but we have had issues where the model
comes in as a dumb solid, and when we 'edit' the import feature (to fill
holes, etc...) the entire feature disappears and the model is prone to
crash.



If the model is an assembly (of a pump, fixture, etc...) we will
'shrinkwrap' this model to eliminate internal features, and add axes,
csys, planes as needed to use for mating/alignment.



FYI,

I always thought it was a bit over the top, but lately I am rethinking
the possibility of never using a 'customer' model directly stored under
the vendor name, p/n, etc... and always creating a unique p/n in our own
system. The vendor part (even bolts, washers, nuts, ...) would have an
associated drawing that is the complete specification for the unique
part including vendor(s), stock number(s), etc. This collects all of
the spec / purchasing info in one place, creates unique models that are
rev controlled, and keeps one consistent item numbering system across
the board. In this case you would have to use Interchange groups to be
able to substitute hardware parts in assemblies. It makes a lot of part
and drawing files but should be the most compatible way of getting
vendor parts rev controlled in PDM.



Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317
Terms & ConditionsCookie settingsAccessibility statement