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

Show previous replies
K
kbryant1-Visitor
1-Visitor
October 1, 2010
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


D
daniel.garcia1-Visitor
1-Visitor
October 2, 2010
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


K
kimndave91-Visitor
1-Visitor
October 2, 2010
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.
>
>
> ------------------------------------------------------------------------

Terms & ConditionsCookie settingsAccessibility statement