Part Name, Part Description, Both? 1

[natepiercy]

Looking for some general weigh-in regarding what constitutes a part "name" vs what constitutes a part "description". Someone recently told me that separating Name and Description is going the way of the dodo because "everything is in a [PDM system] now, so you can just search for it". I'm not sure if I believe that, but if it's really the way everyone else is going, we should probably be condensing to a single-descriptor nomenclature as well.

Previously, I would use the Name field to describe in a word what the part is as a noun - like if you were to say to your buddy "hey, hand me that X" (bolt, nut, plate, weldment, assembly, tube, angle, shaft, cap, etc). Description (to me) was where you could add a little more detail or adjectives about some identifying feature or the use of the part (1/2"-13 X 2", 1/2"-13 serrated flange, formed, main frame, light mount, miter cut, machined, main input, hub cover, etc). The reason this is becoming an issue (and I'm wondering if we should go to single descriptor) is that we're having trouble keeping the "name" field straight. One person (read: I) might say "this is a weldment for the rear cylinder mount, so I'm calling it 'Name: Weldment | Description: Rear Cylinder Mount'" while another might say "that's a mount for the cylinder that gets welded up, so I'm calling it 'Name: Cylinder Mount | Description: Welded' ... or should I call it 'Name: Mount | Description: Welded Cylinder'?". You can imagine the ensuing chaos.

Anyone have experience with this struggle?

 

[drawoh]

natepiercy,

In larger production organizations, everybody uses part numbers. These are reliably unique. Descriptions are not bothered with.

I would think that a part name and a part description would be one and the same thing. Don't name your part "Francine". Conceivably, someone could set up a database with the fields NAME and DESCRIPTION. There would be some logic and company policy behind this which your company ought to be able to explain to you. I have had experience with a database with the fields DESCRIPTION, and LONG DESCRIPTION. I recall that the actual description of the part went into the LONG DESCRIPTION field, and the part numbers went into DESCRIPTION.

--
JHG

 

[SwinnyGG]

In our data control system, both 'name' and 'description' are fields that exist.

For something generic which we buy in, the 'name' field gets populated with the part type. 'Description' is populated with a formulaic.... description.... that makes the part easy to identify.

For example, for this part:

https://www.mcmaster.com/#92290a622/=1c95uhb

My PDM system shows:

Name: SHCS

Description: M12 x 1.75 SHCS SS316 L40

For something I design, the name is what I'd call the part. Description is filled with part features that make it searcable.

For example, if I design a bracket for a Mako G-192 camera:

Name: Mako G-192 Mounting Bracket

Description: Steel Weldment Allied Vision Mako G-192 Camera Mounting Bracket

 

[CheckerHater]

ASME Y14.100 may provide some interesting reading.
See "Drafting titles" paragraph and associated Non-mandatory appendix.

"For every expert there is an equal and opposite expert"
Arthur C. Clarke Profiles of the future

 

[MikeHalloran]

everything is in a [PDM system] now, so you can just search for it

I have personal experience with a corporation wide computer system that could find parts by a generic description, and show you our internal part number, and could not then find that same part, starting with that internal part number.

That system was derived/cobbled/hacked/roached from a POS system purchased in 1972, running on modern hardware but insulated by multiple layers of simulation so it would not have to be re-written. The code had been patched so many times by so many people of different skillsets that no one knew how it worked. ... but the longtime users knew how it behaved, and would scream at the slightest change in its behavior/UI, so it will probably never be really fixed.

I don't think that's atypical of the IT shops you might be working with; their code is screwed up, the underlying database is screwed up, no one really understands it all, and no one will dare to try improvements, or even admit that improvements are possible or necessary, that last being a career decision within most any IT shop.

;----

I did start with a point.
I long ago came to like the military standards for titling objects and drawings thereof. E.g. Noun, adjective, adjective, adjective, etc., all ordered in a fairly rigid taxonomy.

The employer mentioned above bought a lot of stuff from outside, and it was entered into 'the computer' by clerks with imperfect discipline and faint understanding of what they were buying and selling. That was partly responsible for the chaos.








Mike Halloran
Pembroke Pines, FL, USA

 

[drawoh]

MikeHalloran,

My bad experience with PDM was that some people decided we needed PDM, so they installed PDM and they operated it. There was no attempt to understand how people were going to interact with the PDM to get work done, or otherwise to build a user interface. There was no attempt to impose naming conventions, or even to give each document for a given part the same name. There was a pile of other stuff wrong, and it was a disfunctional mess.

Where I am now, there are very strict naming conventions, and everybody seems to follow them. The only problem I am having is that they like the word "bracket". One of my personal DFMA rules is that any part called a bracket probably can eliminated from your design.

Regardless, in both places, if production discusses a part, they use the part number, only.

--
JHG

 

[FACS]

This isn't at all a decision based on the responses you are going to get in here.

It depends on so many other factors.

All this needs to tie into the ERP/MRP system. The interface, information and data needs to be worked out with the IT department that understands these systems. I have been involved with two PDM installations, and the different between the two is staggering. One used CADlink and the other exports XML straight from CAD.

The very first step is to meet with your VAR, ERP/MRP experts, and have a healthy discussion on the desired goals. This is not an engineering decision, it is a company decision. You can not go backward and fix it later so it is better to have too much data than not enough.

We have a full time person that does nothing but defines names and descriptions. The ERP system is fully dependent on this.

 

[MintJulep]

thread1103-398527

 

[SwinnyGG]

All this needs to tie into the ERP/MRP system. The interface, information and data needs to be worked out with the IT department that understands these systems.

I would agree that this is key. Doing things ad hoc or being out on an island is a recipe for future disaster.

 

[CWB1]

It depends entirely on how your system is set up. At my various employers we've always had both, however with integrated PLM systems we've always had to fill out enough other fields (material, part weight, etc) for other departments' use that the description field is redundant/optional/unused for most parts.

 

[3DDave]

This is usually a result of wanting to drive the company without looking at the drawing. Over on the PTC Community there have been requests to increase filename length limits and it's always the same bad reason - so they can completely specify a part without having to provide a drawing. So you have people wanting part names like:

.250-28UNC-2A_.625_HEX_HD_X.375THK_1.25_+.030_-.015LONG_.500_COMPLETE_THREAD_2_MAX_INCOMPLETE THREAD START_.030_LEAD_CHAMFER_.015_MAX_FILET_316_STAINLESS_STEEL_PASSIVATED_100_PER_BOX_SAMPLE_RATE_5_
PER_10000_VISUAL_1_PER_10000_DDIMENSIONAL_2_PER_LOT_TENSILE.prt

 

[dgallup]

It's still absurd to be restricted to 31 characters without spaces in this day and age. We are not running on Unix any more.

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

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]

Hopefully Creo5 will fix that problem! ☺
I just tried a 60 character filename in Creo4 and it does not even show up in the File Open dialog box. The PTC programmers must be dropping long filenames when they search the disk folder and build the dialog.
Maybe now that PTC has dropped support for anything but Windows for the Creo OS, they can start using MFC calls to things like File Open dialogs instead of coding their own.


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

Ben Loosli

 

[3DDave]

It's not a Unix limitation. Never was. It's internal data structure that probably goes into thousands of routines. People will complain the model tree doesn't have word wrap when the lengths go up. Eventually the length can be large enough that the file content can be 0 with the entire model encoded in the name.

I think the DoD has a 24 character limit for all part numbers. I know it's noticeably less than 31.

 

[CWB1]

So if folks are trying to spec the entire part via the model name, does that mean they're also creating a model for every material and surface treatment of COTS parts? Seems silly to me. I've worked several places now that got away from having prints for COTS parts but again, its driven by data entry into PLM.

 

[dgallup]

The no spaces in a file name was a Unix limitation, the file name length was not. I name drawings by part number only as the file name is used to fill in the part number in the drawing format. For the models, I like to have the part name and the part number in the file names. The 31 character length limitation mainly comes in with family table instances where I like to have the generic part/assy name plus additional differentiators such as the operation sequence for manufacturing drawings. I have no interest in what they what they do with Creo, I quit upgrading when they introduced the hideous ribbon interface.

Back to the OP's question, we have 3 lines available in the TITLE field of our title blocks. Generally the first line is the part name and the last line is what product group it's used in and the middle line is optional description. Like all systems this can get messy when some one reuses a part for another product.

We very rarely use any off the shelf parts and even if we do there is no attempt to fully describe it by a name or number. There is always a model and a drawing. And no, we don't use any PLM shocking as that may seem.

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

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.

 

[drawoh]

dgallup,

There is no problem sticking spaces in UNIX/Linux filenames. It is awkward to manage from the command line or from scripts.

--
JHG

 

[dgallup]

Thirty years ago when I started using Pro/E the versions of Unix we were using did not support spaces in file names. Never used Linux, I think PTC only supported it for about 1 release.

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

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.

 

[drawoh]

dgallup,

I don't know about ancient UNIXes. It is possible that the application did not handle filenames with spaces, even though UNIX could.

--
JHG

 

[dgallup]

Did some digging and you are correct. Spaces were allowed just highly disapproved of because they made workable shell scripts much more difficult to write. Here is the best answer I found:

Spaces, and indeed every character except / and NUL, are allowed in filenames. The recommendation to not use spaces in filenames comes from the danger that they might be misinterpreted by software that poorly supports them. Arguably, such software is buggy. But also arguably, programming languages like shell scripting make it all too easy to write software that breaks when presented with filenames with spaces in them, and these bugs tend to slip through because shell scripts are not often tested by their developers using filenames with spaces in them.



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

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.