Managing purchased parts (that have the same p/n) that are represented differently in assemblies

[apekim]

Im curious to understand how others are managing parts, particularly those that are purchased which may be shown in different orientations in many assemblies.

A good example are items that have retaining lanyards, like those quick-release pins. In each assembly that it is used, the lanyard may be bent a different way with the mtg tab oriented in any direction. The part number of this item must be the same in every assembly it is used.

In the past, many organizations that used Pro/E elected to use the item part number as the file name of the CAD object (in Pro/E, it is called the "name" of the item). So if a user wanted to create the same object but in a different configuration, they would have to name it something different so that it was unique in the CAD database, but still call out the correct part number in the parts list.

I know that several CAD tool vendors (Siemens is one of them) have been exploring the use of composite unique identifiers whereas it takes two fields of data instead of one to make a part unique in the database:
Example, P/N: 12345-1.prt Composite-Field:1, the next part would become P/N:12345-1.prt Composite-Field:2


I thought about doing something similar in Pro/E which could have the same functional result:
To use consecutive generic numbers for the file name, and then have a separate "part number" parameter that would be used to populate the parts list (instead of usign the file name):
Example, Pro/E Name: 11111.prt P/N Parameter: 12345-1, the next part would be: Pro/E Name: 11112.prt P/N Parameter: 12345-1 In this case, the Pro/E Name would be just for uniqueness only and not appear on any parts list. The P/N Parameter would contain the data that gets placed on the parts list.

Its difficult to implement a system like this when you are unsure of what is coming down the road in the future for data management functionality.

Thanks,
Mike

 

[dgallup]

Flexibility is one way to do this. I have springs that are modeled in their free state but become different lengths when installed in assemblies. You can have any part dimension be flexible or multiple dimensions. Here is a pair of good videos on making flexible hoses:

Part 1

https://www.youtube.com/watch?v=w3sy8NiEpgs

Part 2

https://www.youtube.com/watch?v=IaxFUwNWayo

I've met Leo Green who made these and he knows how to rock Pro/E.

----------------------------------------

The Help for this program was created in Windows Help format, which depends on a feature that isn't included in this version of Windows.

 

[apekim]

Thanks for the reply Dgallup.
But this is a very different scenario whereas just chnaging a dimension will not result in the appropriate configuration of the part. Think of a lanyard that can have an infinite path (it can be bent any which way) as long as the swept path defines a constant length...lets say an 8 inch lanyard. The tab on the end of the lanmyard could be in any orientation as long as the hole in which the lanyard is attached is no further than 8 inches away form the opposite end of the lanyard which is attached to the part (pin).

Mike

 

[looslib]

What we did with flexible hose assemblies was create multiple part files with a base number.

Base file of the straight part: 87654321.prt
As modeled part in assy1, config1: 87654321-65498732-1.prt
As modeled part in assy2, config1: 87654321-98745632-1.prt
As modeled part in assy2, config2: 87654321-98745632-2.prt

All the parts are identified by the bae part number.
All where used locations are identified by the assembly number in the file name.
All different configurations in an assembly are identified by the -# suffix for each assembly.

You could multiple uses of a part with the same assembly each having a unigue routing onfiguration. This numbering scheme addresses them all.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[apekim]

Ben,
Thanks for the reply. That's an interesting way to do it.
I have a few questions that hopefully you can answer:

1) What do you do when the manufacturers part number is somewhat long and you cannot fit the dash and the assembly part number as a suffix in that field?
2) Does the file name as shown automatically populate to a parts list? If so how does the rest of your orgainzation handle this....do they just not pay attention to the dash and all charaters following it?

Mike

 

[3DDave]

This sort of thing is managed by creating a part number parameter, allowing the use of otherwise excluded characters. Any number of parts can have the same part number.

 

[apekim]

3DDave, Thanks. Yes that what i mentioned in my intial posting, but i havent seen or heard from many folks at all that have considered this.

 

[3DDave]

You need to look at PTCUser and PTCCommunity for related discussions.

Using parameters is a really old technique. And one that can have problems of its own. Like people making a copy of a part and failing to change the related parameter. Or a user being unable to find a file for a part listed in a parts list because the name is unrelated to the parameter.

The other possibility is to have extended names and create repeat region relations to 'fix' the names, but it requires more effort to extract and manage the desired name, an effort that will be different in each place the name is used.

I don't see a way for PTC to follow Siemens example. It's effectively worse than the longer file name discussion. A lot of incompatibility with existing data and no clear path to manage the data outside of the tool. How does one export a compound file name?

 

[robertib]

We have been using the parameter route for a number of years now, and haven't had a problem.

What we do is have a relation model_name=rel_model_name in our standard templates - this allows us to keep the parameter the same as the filename. We then suppress the parameter in the components that use different model names to the filename, and we have set up a BOM format that calls out the parameter.

 

[apekim]

3DDave, At a past job where i was the admin for all PTC products i had created a repeat region relation to correct how Military part numbers were identified. PTC's naming convention did not allow a slash "/"...but they did allow an underscore "_". So we used an underscore in place of the slash in the file name. The repeat region parts list would change all underscores to slashes...thus correcting the problem.

PTC's Intralink program used file tables and indexing which essentially renamed your part file to a plain numeric filename in the database upon checkin. The user never realized this unless you viewed the file path data to the vault in the tool. The file name that you assigned o the part"56-3554567.prt" would appear something like this: "13567.prt" in the Intalink vault. This allowed the tool to quickly search the database. When you searched for your file name "56-3554567.prt" you were actually searching through a table of metedata in Intralink...and not raw files located in a directory structure (which is very slow). I am not sure if PTC's PDM-Link still uses this method (i would like to know).

As far as exporting a compound filename, why would it be different than any other export? If exporting files for a fab shop, you could just rename the file after exporting to the real Part Number.

Robertib, Can you provide an example?

Thanks,
Mike

 

[looslib]

For a long part number that would put you over the 31 PTC character limit, you can use a company part number for that part with proper notion that it is a putchased part of #xxxxxxyyyyzzzzz.

We used relations to extract the partnumber for the assembly BOM. Model_name = extract(rel_model_name,1,8) in the component file 87654321-54658952-1 would give us 87654321 for use in the BOM. If multiple uses in the assembly, they would show the total quantity.



"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[dgallup]

Thanks for the reply Dgallup.
But this is a very different scenario whereas just chnaging a dimension will not result in the appropriate configuration of the part. Think of a lanyard that can have an infinite path (it can be bent any which way) as long as the swept path defines a constant length...lets say an 8 inch lanyard. The tab on the end of the lanmyard could be in any orientation as long as the hole in which the lanyard is attached is no further than 8 inches away form the opposite end of the lanyard which is attached to the part (pin).

Mike

If you looked at those videos, the flexible hoses do indeed change their bends to match the installations just like your lanyards. You can also use the Routed Systems module to run wires/hoses/etc through assemblies, all with ONE part number. You are taking a file naming or parameters approach when there existing modeling approaches that will do what you need.

----------------------------------------

The Help for this program was created in Windows Help format, which depends on a feature that isn't included in this version of Windows.

 

[looslib]

Flexible routed things can be treated differently than rigid routed things. A hose or lanyard (flexible) can be done at the assembly level with RSD without using multiple part numbers for each routing. A formed tube (rigid) could be done, but since these are usually constructed off-site (purchased) to the final form, a unique part number may be justified.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[apekim]

So the flexible parts can be routed (represented differently) in an assembly wihout checking the part out?

 

[3DDave]

"PTC's Intralink program used file tables and indexing which essentially renamed your part file to a plain numeric filename in the database upon checkin. The user never realized this unless you viewed the file path data to the vault in the tool. The file name that you assigned o the part"56-3554567.prt" would appear something like this: "13567.prt" in the Intalink vault."

For anyone who is following along, this is -not- the conversion I was referring to. If a part is called XYZ.prt, but the parameter is MS12580-120, then it is difficult to find the part XYZ.prt by searching for MS12580-120 unless the parameter is declared and indexed in the database.

If the name conversion is done on the fly in the repeat region there is no match in Intralink to search for -and- any change to the convention of "_" == "/", such as adding a new exception, may require changing existing repeat region relations to reflect the new interpretation, which a parameter won't require and can result in easily missed errors. Extracting a BOM from Intralink won't have the same contents as the on-drawing repeat region.

The file name mapping mentioned above is internal to the operation of Intralink, and has nothing to do with the user view. In most cases the Intralink stored name is the original file name of the part. Intralink maintains a table relating the current name to the file name and dynamically applies the current name when the part and using references are opened in Pro/E. PDMLink does a similar thing for Pro/E and Creo. This way if a name is changed it doesn't require a change to all the related files controlled by the database. This is similar to late-binding in code compilation.

Renaming one file is not a general solution. What happens to an export of a TDP with 10,000+ files? How are those files mapped back when they are re-imported from a 3rd party? Hand-waving explanation isn't a solution.

 

[robertib]

Here's an example of our BOM format. To use it, you just need to add bom_format to your config file and point to the location.

Regarding the model name itself, we use o-rings, but in rectangular grooves, so to ensure that we convert from length/width/radius to diameter, we use relations to convert the total internal size of the oring from a perimeter (circumference) to a diameter, and use that in the model name.

Here is the relation we use - we then convert from decimal to integer parameters (for both the integer part & the decimal part of the id), and put them together in a string.

perimeter=(oring_length-(oring_radius*2))*2+(oring_width-(oring_radius*2))*2+2*pi*oring_radius
id=perimeter/pi
id_integer=itos(floor(id))
id_decimal=itos(floor((id-floor(id))*100))
if (string_length(id_decimal) == 1)
id_decimal="0"+id_decimal
endif
csa_integer=itos(floor(cross_section))
csa_decimal=itos(floor((cross_section-floor(cross_section))*100))
if (string_length(csa_decimal) == 0)
csa_decimal="00"
endif
if (string_length(csa_decimal) == 1)
csa_decimal="0"+csa_decimal
endif

model_name="O"+csa_integer+"."+csa_decimal+"x"+id_integer+"."+id_decimal+"F7"