PTC Threaded Fasteners BOM Callout

[ptc-2151062]

For those of you familiar with the PTC standard fastener library:

How do you work with the inch fasteners such as bolts and nuts considering there is no thread data in the family tables?

Typically we like to define the thread pitch (UNF or UNC) for our bolts and nuts in the BOM table callout, but since a typical PTC fastener library bolt only has the nominal diameter and length available as a parameter, I would have to manually add thread pitch to the BOM entry. In other words, I'd like to display something like nominal_dia, thread_pitch and length (such as SHCS 1/4-20, 1" Length) in my BOM tables.

I understand I probably need to add thread pitch data in each library part generic, but perhaps there is a clever way to let me choose UNC or UNF thread as one of the familiy table parameters, such that when you select UNF and a 1/4" diameter bolt, the callout will automatically display 1/4"-28.

What's the easiest way to do this while minimizing required end user input?

Thanks,

Andri

WF 5

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.

[BrianMartin]

Hi Andri...

Yes, there's a clever way you can do this. As with many things in Pro/E, you CAN do it... the problem is that you really shouldn't do it. The procedure is clumsy and adds unnecessary complexity to the models. Also... those generic Pro/E library parts are horrifyingly, embarrassingly BAD. Most companies make their own from scratch or heavily modify the library.

You'll need to edit each generic, as you mentioned. The most straightforward way to get what you want is to just manually enter the necessary data into the family table. Add the necessary parameters and fill them in. You can use EXCEL to edit your tables if this helps. Sometimes Excel's copy/paste functions are easier to use. Sometimes you can even use some of Excel's features to help you fill out all of that repetitive text.

This is the most efficient way to tackle the problem.

However, since you asked, there is another way. I don't recommend it... but it will do what you've asked. You can write a relation in your generic models that sets a variable and then uses that variable to control the part description.

Let's say you already have these variables:

THREAD_TYPE which will be set to UNC or UNF

SIZE which will be set to the bolt nominal size (for example: #4, #6, #8, #10, 1/4", 3/16", etc)

LENGTH which will be the bolt length

PITCH which will be the thread pitch

DESCRIPTION which will be the descriptive string used in your BOM

You'd only need to pick THREAD_TYPE, SIZE, and LENGTH (probably table driven) to set the other two variables if you used a relation.

You can write a relation that says:

if &THREAD_TYPE == "UNC"

if &SIZE == "#4" then

PITCH = "40"

endif

if &SIZE == "#6" | &SIZE =="#8" then

PITCH = "32"

endif

if &SIZE == "#10" then

PITCH = "24"

endif

if &SIZE == "1/4" then

PITCH = "20"

endif

endif

if &THREAD_TYPE == "UNF"

if &SIZE == "#4" then

PITCH = "48"

endif

if &SIZE == "#6" then

PITCH = "40"

endif

if &SIZE =="#8" then

PITCH = "36"

endif

if &SIZE =="#10" then

PITCH = "32"

endif

if &SIZE == "1/4" then

PITCH = "28"

endif

endif

DESCRIPTION = "BOLT, &SIZE-&PITCH&THREAD_TYPE, &LENGTH LG."

This would give you output like:

"BOLT, 1/4-28UNF, 1.50 LG."

or

"BOLT, #10-24UNC, .75 LG."

Again, though... I wouldn't advise it. The relation is long and ugly and it just causes a mess. The simple solution is often the best... and manually hacking it might be the better way to go. Still, I hate when someone asks a question and people don't bother to answer if they don't agree with the approach.

Take care...

- Brian

[ptc-2151062]

Brian,

I appreciate your very thorough response!

While I agree that the PTC library is lacking in many ways, we are trying to make use of it as best we can (perhaps for the worse).

The idea of using relations to properly callout the thread pitch (depending on thread series) is one I had thought of before, and should theoretically work. However, there is a complication with this idea.

Let's assume you configure a generic bolt using the above scheme (which in my case means adding two parameters, THREAD_TYPE and PITCH). Let's also say I have an assembly which requires four 1/4"-20 bolts, 1" long. Now I insert into the assembly the bolt instance that is the required 1/4" Dia and 1" in length. To get the correct 1/4"-20 callout, I would need to set the THREAD_TYPE parameter in the part instance to UNC (which then sets the PITCH parameter to 20 because of the relation), and save the instance.

Here is the problem: That particular instance is now set to UNC, and will always be a coarse thread unless I change the THREAD_TYPE parameter to UNF, and save the instance. This means two instances, one with UNC and one with UNF thread, cannot exist simultaneously in an assembly or BOM callout on a drawing.

The only way I see around this it to create two bolt generics (each with their own family tables), and permanently set one to UNF and the other to UNC. This will double the amount of nuts and bolts in our library, and is far from an ideal scenario.

That's the problem in a nutshell.... maybe I'm missing the point here.

Thanks again for your input,

Andri

[Kevin]

One I can think of that might work for what you are trying to do is adding flexibility which would allow you to have the same part but different values. Can't say it works for sure. It may not even be a good idea to work with.

[Kevin]

I tried a flexible part and it worked locally. I don't know how it will behave in a PDM system.

[BrianMartin]

Hi Kevin & Andri...

The flexible option will work perfectly fine in the PDM system... a single part will be maintained that can handle both UNC and UNF in this case.

In versions of Pro/E before Wildfire 5 (Creo Elements Pro/5.0), there were problems showing BOM balloons belonging to flexible components. This is reportedly resolved in WF5 although I have not verified this personally.

To address Andri's response... I was assuming you would control the THREAD_TYPE parameter through the family table. I assumed the UNC/UNF decision would be made through the table. I haven't looked at the PTC libraries in some time. I wasn't aware they weren't broken down this way.

Many times companies nest their family tables so users can easily make hardware selections. For example, first the user will decide between UNC or UNF thread type. Once this choice is made, perhaps material type is the next level of selection. Once the material has been selected, the user might finally choose a nominal size (#6, #8, 1/4, etc). Finally, the user would pick the length. Setting the tables up in this manner requires a bit of work. I'm not sure how the PTC libraries are organized. Attempting to create nested tables from the library files might be difficult.

The only other way to achieve the UNC/UNF separation would be to have two different generics (as you already mentioned).

I'm not sure where to go next with this... any ideas?

Thanks!

-Brian

[ptc-2151062]

Brian and Kevin,

using the "flexible" component option (with a flexible parameter) seems to work fine in a PDM environment - we are on ProductPoint 1.1, and I'm using Creo 1.0 Parametric. The BOM callout also seems fine.

This approach may in fact be easiest for me to implement considering we have dozens of fasteners that require thread data added to them. While it requires several mouse clicks to change a part instance into a flexible component, add the correct parameter and change its value, it's pretty straight forward.

I'm thinking that we'll set the thread "default" to UNC, that way we only need to do the above steps if a UNF thread is required.

This also allows me to conclude that the PTC fastener library is not ideal in terms of configurability, and why most companies either buy or make their own custom fastener libraries. If I had more time, I'd do a custom library using the nested tables that Brian mentioned.

Again thank you both for your input - I had never used "flexible" components before, so this shall be another tool I will explore for future endeavors.

Andri

[BrianMartin]

Excellent...

Good to hear you've got a solution that works!