cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X

hardware library question

homerosaldana
5-Regular Member

hardware library question

I'm about to start creating a hardware library and any input is appreciated. Just so you know we have a numbering/ordering system that is customer/project based in which all parts are assigned a project specific number including hardware. With this system the hardware will be duplicated for each project.

Assuming we all agree that a highly detailed (threads) screw is not desirable, how much detail is enough. Are you using tables? pro-program? Is there any benefit or pitfall to creating a detailed screw, exporting as a parasolid and importing? Is anyone using vendor models (mcmaster)?

Pending feedback, my initial approach is to not use family tables, create a base model that others are duplicated from.

-hs

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.
23 REPLIES 23

If you?re going to be duplicating for every job, I would strongly advise you
not to use family tables for your hardware. Sure it?s more work to set up
each individual part, but I think you?ll have fewer headaches in the long
run if you use separate parts. To make it easier to swap out sizes (as in,
?oh, crap, I assembled a 1 inch long bolt & I need a 1 ½ inch?) you may wish
to set up interchange groups, but we don?t use those much here, so I don?t
know how they?ll behave upon duplication. (as an aside, are you using a PDM
system?)



As far as how much data is enough, I would say a simple revolve or
hex-shaped extrude for the head & a cylinder for the shaft are usually
enough, especially if the product they?re assembled into is very large.



--



Lyle Beidler
MGS Inc
178 Muddy Creek Church Rd
Denver PA 17517
717-336-7528
Fax 717-336-0514
<">mailto:-> -
<">http://www.mgsincorporated.com>

A few thoughts;

- I've used McMaster downloads and they're bloated. They show thread
detail and bog down repaints, pans & rotates.

- You might consider using inheritance features rather than family
tables. This keeps them tied to a 'generic' but allows variation
between the 'instances'. Also, although there is an external reference,
changing the 'instance' doesn't tag the 'generic' (and therefore all
other instances) as modified.

- Take a look at this old tip from the now defunct Pro/E FAQ:

www.design-central.com
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

PTC has a library you can use. You can access it through the
"connections" tab in the model tree - then catalogs - then pro/library
(upper right hand corner).



Otherwise, here is the link:

The PTC supplied library hasn't been updated that I know of in the 14
years I've used Pro/E. They were mediocre (and inconsistent) models for
Rev. 16 and haven't improved with age. They are also nested family
tables.

Doug Schaefer
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

I agree that the pro-e libraries are very old and clunky.



You may want to re-think the 'family table' paradigm for common items.
With more content being delivered from sources like McMaster-Carr,
Carr-Lane, etc... I am finding it easier to have separate models for
each item. Swapping out the items is taken care of by using Interchange
groups. It is very easy to add models to an interchange group and
designate 'like features'.



As a side benefit, doing it this way encourages reuse of existing items,
and I would bet is cleaner and less hassle to update / manage in
Windchill / Interlink as well.



As a side note, springs, threads, and similar helical features used to
really bog down Pro-E, but since about WF2 or so I haven't seen such a
problem. (Maybe the computers are just faster now)



As a draftsman, the schematic representation of bolts, springs, etc...
are much cleaner on drawings than the 'true' representation.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

What ever you do, before you begin to "populate" the sizes, make SURE
you have EVERYTHING you want in there... Don't forget parameters for
filling in your BOM tables, and especially don't forget your LAYERS!
I'm sort of assuming you would say, model a screw and then copy the
model numerous times, changing the length each time... Last thing you
want is to create 100's of models and THEN realize you forgot to put in
something...

(I've often thought there was a "business opportunity" in this...
create a set of hardware models and figure out how to run Pro/BATCH on
it so you could "customize" it to the exact customer specification! )


Thanks...

Paul Korenkiewicz
FEV, Inc.
4554 Glenmeade
Auburn Hills, MI., 48326

Why would you not use Famaily Tables? Is there a problem with them?

Would you mind elaborating on the troubles of nested Family tables in
PDMLINK?

I can't comment on nested tables in particular, but here is the general
issue with family tables and any PDM system.

Because the parts don't exist in their own file, changing any one
instance really is changing the generic. And, since changing the
generic is really changing all the instances, if you want to change 1
screw in a family table of 100's of screws of various sizes and lengths,
you need to check out ALL of them and then check them ALL back in when
you are done.

Will it work? Probably, but it's painful.

Doug Schaefer
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

Doug, and All



I disagree.

The benefit of having all the like fasteners in one unified table far
outweighs the occasion when one must change an instance.

Instead of searching for the one screw you need, you just check out the FT -
which later on in the design will already be there anyway.



For all the hassle they can be when changing PDM systems, they SAVE TIME.





The procedure for change is easy - only two extra steps - big deal?!

Check them all out, change their status, make the change, verify them all,
and check them back in.



Anthony R. Benitez

Senior Mechanical Designer

Drafting Supervisor

Applied Research Laboratories

The University of Texas at Austin

We do it all the time in 3.x without any problemss. Is it a pain in PDMLink 9.1 (we'll be going there soon)?

Stefan

Stefan,

We use 9.1 and haven't seen any issues with the time it takes to check out, modify, or check in. Verifying the tables depends on the number of instances, of course. The main thing to remember is to always work on the generic if modifications need to take place.

We had some issues with some ancient legacy data developing a 'family table neutral data' error. PTC was able to send us a healing script, but it was mildly disruptive in the few days it took to sort the problem out. This happened on a nested family table though I'm not sure that has anything to do with it.

cfly
4-Participant
(To:homerosaldana)

Also, if you're only modifying one instance, you have only to check out that
instance and the generic - the only thing it changes in the generic is the
family table within it, and only for that one instance. The other instances
are left intact. You may get a warning about other instances not being
checked out, but since they won't change, it's not an issue.



efefefefefefef

Applied Research Labs

University of Texas at Austin

Carol Fly

Mechanical Designer

(512) 835-3397

Fax (512) 835-3259

efefefefefefef

_____

The issue with large family tables, as pertains to the original query in
this thread, was that he needs to be able to duplicate them over & over, for
each individual order, so, if I understand the original query correctly,
that a ¼-20 x 1 pan head Phillips in this particular order will have a
different part number than the ¼-20 x 1 pan head Phillips that was used in
that other order last week. If you?re duplicating them that often in a PDM
system, family tables get very cumbersome.

For example - if you have 300 fasteners in your nested table, and you?re
only using one for this order, do you

a) duplicate the entire table for this order, so that you have 299 unneeded
fasteners floating around ? or ?

b) duplicate just this one screw and add it to your family table, so that
today you have 300 screws, tomorrow, 301, and 2 years from now, 4560 ?



--



Lyle Beidler
MGS Inc
178 Muddy Creek Church Rd
Denver PA 17517
717-336-7528
Fax 717-336-0514
<">mailto:-> -
<">http://www.mgsincorporated.com>

Lyle and All



It's not an issue of quantity.

Either way you go - you're going to end up with a truckload of fasteners -
more so if you handle them with FT's.



However - I can recreate a new series of Part Numbers in a FT in less than
an hour using Excel.

I can also keep my different series contained in the FT's for that
particular deliverable.



I don't think the issue has anything to do with a legacy data - I'd commit
this crazy project to disc and forget it.

(whoever heard of renumbering the same fasteners alternately for each
delivery?)

The issue to me is how fast I can have fasteners with the correct part
numbers at my disposal.

I can do it with FT's a lot faster





Anthony R. Benitez

Senior Mechanical Designer

Drafting Supervisor

Applied Research Laboratories

The University of Texas at Austin

Just to shed some light on the original post:
This is a unique situation. Normally I would advocate the use of the family tables.
Since we have to deliver a tech data package to our customer with unique customer/project numbers, a family table adds complexity to renaming. It's faster to rename one screw than an entire table and our customer would be more appreciative of us spending their money on design than on renaming parts. In some rare cases the customer have shared their library and then it's a non-issue. Also, when using individual files, and you realize that you need a longer screw, you can just modify it in the design because it's not being used anywhere else or have any legacy data to deal with.

-hs

I'd approach this in a different way. I see no benefit in duplicating hardware over and over again & again. and then having to store and maintain it for ever ...
I would tackle the different P/N's in the Assembly Drawing BOM's

If you just need the Billl of Material on assembly drawing to display a different P/N for each customer.
I would look at Table Repeat Region Relations. See TPI 7106974

this TPI covers changing the QTY for a P/N but you can just as easily add a Prefix to a set of P/N's so lets say all your washers start with something like 9825xxx , screws 9826xxxx, nuts 9827xxxxx etc...you can set up a relation to prefix all the 9825, 9826, 9827 numbers used in an assembly for a client A with ABC and for client X you just modify the relation to prefix XYZ

Using a method like this you have just 1 Hardware Library to maintain.

Dave McClinton

MCAD System Administrator

McKesson Automation

724 741 7760

david.mcclinton@mckesson.com

My 2 cents:



There have been past problems with nested family tables so avoid those.



These would involve subfolders inside your family table... keep it
simple.



(Don't put pan head screws and hex head screws in the same table)



As far as cabling is concerned, family tables are mandatory.



I can't tell you how many times my p-clamps have changed sizes.



Do you want to reroute your cable everytime your p-clamp changes size,



Or would you rather just do a family table instance swap and be done
with it.



You are abusing your cablers if you don't. At least as far as cable
supports go...



You can't pay them enough to waste that kind of time.



Also, where assemblies are concerned... managing your effectivities
using a



Single tabulated assembly is priceless. Especially because you can
manage your



Assemblies using Excel... Makes the managers feel important to be able
to



Configure your top assembly model...



Thanks much,



Frederick Burke

________________________________

Sorry to have hijacked this post it was not my intention, but we just switched to PDMLink from Product Point and had a nightmare with Family Tables.All of our screws, nuts, Bolts, Washers Etc.. are Family tables, and a lot of them are nested. We just got finished loading them all up, and are moving to load are Products.I was concerned that we were going to have problmes, but I think we will be ok

Thanks all

The problem was with Product Point. It can not purge Family Tables, and
there is no workspace. So every time you press the save button you get a
new iteration, and you can never purge it. Also all data is stored in
the database not a vault, so it was very slow to load.



On Fri, Oct 1, 2010 at 3:05 PM, Mueller, Stefan <-<br/>> wrote:

> Keith,
>
>
>
> What was the nightmare?
>
>
>
> Stefan
>
>
>
> *From:* keith schmitt [

The way we use ProductPoint there is a sort of workspace. We set the server
status for "Synchronize Manually" and every time we hit "Save" it stores to
the local cache. Then we can select "Synchronize Now" and the latest saved
version goes to the server. We may save 10 times for every one that we
synchronize to the server.



There is also a Purge function in ProductPoint and I use it frequently.
After I "Release" and object, I select Version History for the object and
then select "Delete Minor Versions". It deletes all of the "unreleased"
versions. It works well.



Regards,

Kelly Bryant

Teknovation, Inc.

kelly.bryant@teknovation.net

601.450.0078


Let me tell you our problems with family tables + PDMLink.



Some people say you can checkout only one instance and the generic, and send
it back to PDMLink. We don?t do that because the instance is then linked to
an old iteration of the generic and that can give problems.



So when we modify 1 instance we verify and modify every instance. First
problem is that means lots of instances get out of date for a lot of people.



To illustrate the second problem I have to explain how we deal with states
Released and Design in my company:



Final, usable objects are in state Released.

Objects being changed are in state Design.

If you want to modify a Released object you create a new revision in state
Design, then check out to the Workspace (you only can checkout objects in
state Design here, unless you are an administrator)

When you have finished the modification you check in, create a Promotion
Request with the objects you want to take to Released and these objects
change to state ?Under Review? until an Approver accepts the change. Then
they go to state ?Released? and we are in step 1.



When we have to add/modify an instance of a family table sometimes we have
to create a new revision only for one instance. Then the user has to ask the
administrator (that?s me) to set the state of the rest of the family table
manually to Design, so they can check out things.

When they make changes and get their objects promoted to Released the
administrator always has to set the state of the instances that are still in
Design to Released because they were not added to the Promotion Request.



As a side note, sometimes the users create by mistake a new revision of
instances they shouldn?t have. Undoing this mistake is difficult, especially
if the user has used the new revisions in other assemblies, because PDMLink
won?t allow you to delete things.



Third problem: if you want to delete an instance from a family table because
you decide it shouldn?t be used anymore. If you delete it the previous
iteration of the instance is still in the database, linked to the previous
iteration of the generic. If it is ever needed in a Workspace it will bring
the corresponding iteration of the generic (which may be outdated for the
rest of the instances). If, to make things worse, you also need an instance
that was later added to the generic in that Workspace, PDMlink won?t be able
to bring both iterations of the generic to the Workspace.



It?s not so difficult to do this. Imagine you have created an instance in
the family table and you gave it a temporary name. You checkin, then decide
the definitive name. If you open the family table and overwrite the name of
the instance you are deleting and creating a new instance at the same time
(I have seen this happen). The good way of doing this is renaming in the
server, and then synchronizing.



All these examples are not from my imagination. They have happened in our
company and they will happen again for sure.



To summarize, this week a user asked me how to do one retaining ring he
needed. When I told him, ?Just do a normal part, don?t add it to any family
table? his face lit up and said ?Good, then I have no more questions?.



Regards



Daniel Garcia


Try renaming them to "do_not_use..." or "Obsolete..." One could also
add the first solid feature to the table and just say "no" in the
unwanted instance to discourage casual use as well.

Dave S.
>
> Third problem: if you want to delete an instance from a family table
> because you decide it shouldn't be used anymore. If you delete it the
> previous iteration of the instance is still in the database, linked to
> the previous iteration of the generic. If it is ever needed in a
> Workspace it will bring the corresponding iteration of the generic
> (which may be outdated for the rest of the instances). If, to make
> things worse, you also need an instance that was later added to the
> generic in that Workspace, PDMlink won't be able to bring both
> iterations of the generic to the Workspace.
>
>
> ------------------------------------------------------------------------

Announcements
NEW Creo+ Topics: Real-time Collaboration


Top Tags