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.
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)
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.
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.
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.
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.
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.
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.