1-Visitor

Question

hardware library question

Forum|Forum|15 years ago
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.

Data Exchange

Show previous replies

P

ptc-169947

1-Visitor

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

D

dsenchuk

1-Visitor

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.

C

cfly

1-Visitor

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

_____

L

lylebeidler

1-Visitor

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>

B

bbenitez

1-Visitor

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

H

homerosaldana

Author

1-Visitor

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

P

ptc-46674

1-Visitor

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

F

frederick.burke

1-Visitor

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

________________________________

K

keithschm

1-Visitor

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

K

keithschm

1-Visitor

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 [

Show more replies

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded