Skip to main content
H
homerosaldana1-Visitor
1-Visitor
October 1, 2010
Question

hardware library question

  • October 1, 2010
  • 23 replies
  • 3391 views
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

L
lylebeidler1-Visitor
1-Visitor
October 1, 2010
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>
D
dgschaefer21-Topaz II
21-Topaz II
October 1, 2010
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
J
Jim.Tierney1-Visitor
1-Visitor
October 1, 2010
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:

D
dgschaefer21-Topaz II
21-Topaz II
October 1, 2010
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
P
ptc-19327451-Visitor
1-Visitor
October 1, 2010
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
P
PAULKORENKIEWIC1-Visitor
1-Visitor
October 1, 2010
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

K
keithschm1-Visitor
1-Visitor
October 1, 2010
Why would you not use Famaily Tables? Is there a problem with them?
K
keithschm1-Visitor
1-Visitor
October 1, 2010
Would you mind elaborating on the troubles of nested Family tables in
PDMLINK?

D
dgschaefer21-Topaz II
21-Topaz II
October 1, 2010
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
B
bbenitez1-Visitor
1-Visitor
October 1, 2010
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

Show more replies
Terms & ConditionsCookie settingsAccessibility statement