Replacing parts (like hardware) non-windchill

[banderson-2]

So here is the issue that I would like to solve. Our company has done a very poor job of managing hardware and other parts that are candidates for family tables. Basically they haven't managed it, so it's a free for all which is causing problems. The specific issue that I would like to tackle is multiple copies of the same part number in a family table. To set up an example:

Say we have a 1/2" bolt of various lengths the generic in bolt_12, with part numbers 1234 and 4321 in the family table. We will keep it simple, but realize that the actual part has 20 or 30 parts in it. (we'll call this one part A)

that part is saved in the hardware folder like it should be.

somehow that part got a copy of it saved in the upper level CAD drive. (we'll call this part X becuase it's bad) Both locations are in the search paths on the config files for various reasons. Since there was little foresight into setting up part numbers for hardware, part numbers are created whenever a new length is needed. They have no order, it's just a pull the next number out of the list. So after the generic got copied, now new part numbers are created in the family table, BUT only on one of the copies because no one realized or understood the ramifications, or cared that there was two copies. So now part X has 1234, 4321, and 9999. Meanwhile part A has 123, 4321, and 8888

Now we have the issue that we have the same bolt called out in many (who knows how many) different models.

I actually have no idea how this even works at all. But we are managing for now, partially by ignoring the problem.

My question is, how can I (or is it possible to) reconcile the two models? It will be nearly impossible to go through every model and replace all of the parts manually. Some models are not needed and it would be a waste of time (but I can't define that with the information that I have) and I would surely miss some anyways. The system is "working" right now, however I believe it is setting up little booby traps that may go off at any time.

I can go into part A and create all of the parts that were only in part X, but...

Can I set references in a part so that if the model was created using part X but only finds the number in part A, it can know what it needs to constrain to so it doesn't blow up the model?

Thanks for any help, and as always, if you need more clarification feel free to ask.

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.

[TomD.inPDX]

This is not an unusual situation. I have seen this in mid-sized organizations where new or contract people had something to prove, only to make a huge mess.

In your case, it is a slow process unless you dedicate resources for resolution.

I am going to assume you have some kind of bill of material system and a engineering change system.

If the bill of material is electronic and a where used is possible, you are a mile ahead.

My recommendation:

Find the duplicity in all part numbers.

Keep the list with the engineering change group, or the people responsible for implementing the engineering change orders.

Part of the ECO process is to scrub the list. Force a replace on any offending components during the implementation of the change order.

Eventually, you will clean up the parts needed.

If you want to make sure people don't use the parts, you need a way to make these obsolete. If no one checks an existing database to make sure a part is current, move the parts to an obsolete folder (also in the search path) and make a duplicate of that part number and append "_obs" to the name.

I have worked with non-intelligent 5-digit part numbers in the past. But we never used family tables. I still have mixed emotions about using them but that shouldn't be a real issue. I understand their usefulness. I find it best to have a dedicated "librarian" for this kind of file management.

The fact that you have specific hardware folders is troubling. This attempts to add intelligence to a non-intelligent system. This is where family tables get messy... managing the files. In the system I am familiar with, each 5 digit number has a 2-digit folder... "50" which maintained all "50xxx" part numbers. And "51" for all "51xxx" numbers, etc. When working in an assembly, you could back up the entire assembly in any folder (typically it's source folder) and not worry about duplication because every week, the folders would be scrubbed with a batch file where all the non-appropriate file names were removed. It worked wonders for having a dynamic server based development environment without any kind of PDM.

There is a lot that can be done in OS level routines to manage your server status. Managing duplicity is an age-old quest. The simple method is a weekly audit with a simple routine of a sorted list of everything in the database where duplicity is easily seen. A recursive algorithm can even highlight the duplications. Something a high school intern can come up with in a matter of days. The point being, if you do not dedicate some resources to this now, it will only get worse. You have to have a solid design environment if you ever hope for it to be sustainable.

My work is with many clients and I am a sole contributor to my database. Even so, I have trouble maintaining a coherent methodology due to the variables thrown at me by clients. It has taken at least a year to get consistent about adding new projects.

[Dale_Rosema]

I, too, for the last two years have been cleaning up very messy files and I agree with Antonius that adding the necessary part instances to the family table and then going into the bad part and putting Obsolete use model "A-4321" in the description so that it forces a model update the next time the assembly needs to be changed, fixed, or upgraded.

(Single man operation - non windchill)

Thanks, Dale

[banderson-2]

Sounds like a lot of work, which is what I thought it would be. Unfortunately, the mentality that got us where we are is still alive and well, so anything that takes work like that to be coordinated through all of the engineers will not be sustained. The only way to make this work here is for an easy fix that only one person has to do any work. Too bad really.

[TomD.inPDX]

Policy and enforcement is the only method to maintain a clean database.

Without accountability, there really is little hope.

When purchasing is buying 3 part numbers and they all end up being the same part from the OEM, but you loose your economy of scale, then some bean counter -might- back you on forcing change.

Again, I've seen it, been there, done that. In the end, enforcement was basically a hodgepodge of different job functions having an oversight voice. The engineer would have to correct the oversight and that is what finally got some level of due diligence in searching for exiting parts as a normal course of action.

And we all know how painful it is just to change out one bolt... times about 20 in a full drawing package to have one be a -little- more careful.

[Dale_Rosema]

Depending upon the number of "bad parts", the good part can be updates and the bad one labeled.

Just a quick thing to test.

Or...

Add a test instance to the good part and delete it from the bad part and see if it makes the switch and finds the good part.

It may help that way in that you could have some fix a part here and there periodically until it is cleaned up.

[dschenken]

Doomed as doomed can be? Not entirely, but it's going to take work.

The main problem is that, for instances, the names of the generics are part of the description that is recorded in the assembly. PTC has a backup that if it can't find the generic, then it looks for a standalone version of the component name.

I'm 95% sure: If <Generic>:<Specific> isn't found, the software will look for a standalone <Specific>. If it can't find a standalone <Specific> it will use the <Generic>.

What it can't do is look into alternate generic models to see if they happen to have a specific that matches.

The real way to fix this is to look at each generic and determine which one is the favorite.

In all the others, rename the related instance to a unique name. Create interchange assemblies amongst the unique names with the desired instance.

Open the using assemblies - they won't find the instance they are looking for and should substitute the related generic. Then replace the related generic with the uniquely named instance. From this you can use the interchange assembly to replace the unique named part with the correctly named part.

The process can be better managed if instance accelerator files are created - look for name.idx. These list the names of the instances in family tables; they may depend on having used the Verify command on the tables. You can use them to see all the instances without needing to weed through the files themselves.

I wish I could recommend an inexpensive PDM system to help keep this straight. The problem you have now was the same one that caused me to recommended my company get the original Intralink. My specific recommendation was that Intralink would be painful to use, but not having it (as you see up close) is more painful.

An appreciation for CAD/CAE as the same process as software development is the best paradigm. Imagine the main programs are supported by libraries, but each library has a different function with the same name. Not many software developers would stand for that circumstance. Instead they mostly use source control systems to prevent overlaps between libraries.