Put your PDMLink system on a diet

[AntonioVillanue]

http://sites.google.com/site/newvillagepdm/useful-sql-scripts/unused-family-tables

Without proper maintenance, you PDM system can become a little shop of horrors. Feed me, feed me, feed me!  It should be the job of the system admin to make sure that items are purged and unrelated files cleared from the vaults.  By what about the librarian's role?  Are you using all the models that are in the system? What about large family table libraries of common hardware?

I noticed a while back the following behavior, workspace operation times seemed to be affected by the use of large family tables.  To test I created a 16 part assembly, one with no family tables, one with small family tables, and the third with very large family tables. You can see the affect below. Note the log scale. Remember, there are less than 20 objects in the workspace for all of these.  Slowness was on the server side.

So, how well am I using these family tables? Am I carrying instances that I never have used? I wrote this SQL query to answer that:

http://sites.google.com/site/newvillagepdm/useful-sql-scripts/library-part-stats---percent-used

It shows the generics from a library, number of instances and the percent used by cad assemblies. I got a chart like this from that data:

Ok, we are using very little of these families. Time to chuck them.  There is a TPI in the knowledge base about removing family table instances from PDMLink.  This needed to be modified since it was not practical for removing large numbers of instances, but it is possible.  You'll need another query which, for a given generic number, lists what has been used by other assemblies. This is what you need to keep at a minimum:

http://sites.google.com/site/newvillagepdm/useful-sql-scripts/instances-used

And while you are at it, you might as well dump any families that show no usage at all. To find those, you this query:

http://sites.google.com/site/newvillagepdm/useful-sql-scripts/unused-family-tables

The results of all this was surprising and immediate. For assemblies that made use family tables that were reduced, we saw workspace times drop as the number of instances dropped.  The object count represents the object count if you included all instances option when adding assembly to a workspace (so we can get a relative comparison).

Finally, the macro effect. I am logging workspace operation information to a database using a utility that runs on Wildfire startup Wildfire Event Extractor. Below is a chart from that data showing add times vs. affected objects for the event. Note again, the log-log scale.  The chart shows recent events have shifted down and to the left indicating overall system performance gains.

[dschenken]

The answer is for PTC to fix Windchill to properly handle family tables, not to require users to have workarounds.

Has this experiment been re-run for Creo X and Windchill XX?

[AntonioVillanue]

I have been using Creo 2 for a while with Windchill 9.1.  It worked for that. I have not tested it with 10.2 but I suspect that not much has changed. Yes, they could improve things but I believe the data model is correct.  The independent pieces could be improved to work better (workspaces, FT, deletion and purging).  "Working to spec" is not an acceptable answer. I suspect that this is a rare enough occurrence to not warrant resources.

[BenLoosli]

While I can see merit in the statistics about family table size, I disagree with the 'solution'.

We are building family tables of all available hardware options for common hardware items. We want ourt usres to be able to pull any part into an assembly without creating a new one. I have many familt tables of screws that go from #0 to 1-1/2 in diameter and 1/8 to 6 inches in length. It takes a while to build these tables, but it allows us to have them available at anytime. Will we use all of these instances, I doubt it. My guess is that we may only use 5% of the almost 10,000 instances I have built so far.

If there is a problem with the way Windchill handles family tables in a workspace for retrieval, or removal, then PTC needs to look at their programmers to find the solution. The use of family tables is important for consistency in part naming and minimizing all of the one-off parts being created. I spent 4 months last year cleaning up part description parameters on individual parts that we would not put in family tables at this time. That may change if I can justify the time spent to do the work. For now we use family tables for off-the-shelf hardwrae items: screws, bolts, washers, nuts, rivets, etc.

[AntonioVillanue]

I agree on you points about the benefits of family tables. Yes. I would say that through the releases, speed of workspace operations has improved dramatically, orders of magnitude.  I will rerun my experiment in 10.2 and post the results.  I can say that from a programmer point of view, any loop that touches a data set involving 1000+ entries is going to slow things down. Imagine if their operation is O(n^3)!. I just wasn't willing to wait for PTC to get around to fixing the issue.

Another thing we noticed if you had to carry all sizes, engineers will pick, well, all sizes. This means higher part costs carrying inventory only used once. This can vary with industry but we are not talking about 0.05 fasteners in High Rel space flight. Then there is the touch labor. Our other goal was to move toward fewers sizes and more standard part reuse.  

Again, agree on points. Lets see what new data says.

[HamsterNL]

Interesting.

We are in the process of moving from WildFire 4.0 and Intralink 9.0 to Creo 4.0 and Windchill. Currently, we have created our own fasteners library, where all fasteners are in an Interchange Assembly. This allows the engineers (and our automation) to swap any bolt/nut/washer/plug for any bolt/nut/washer/plug (yes, you read that right).

We have added parameters to indicate which fasteners are preferred, so our mapkeys can automaticly show the users a filtered list of fasteners they may use.

Our library is relatively small, so that's the upside for us 🙂