Bill of materials showing wrong part name?

Guys, I was stumped by this one, and you may find it interesting in case you ever come across the same problem.

I have a cable assembly drawing with a bom, which has a repeat region. One of the columns is '&asm.mbr.name'. Two of the parts (wire crimps) are showing the name before they were renamed, not the current name. I've tried updating the table, updating the sheets, placing a new table, but each time it shows the old name.

My workspaces are synchronised with commonspance, my workspaces and commonspace both show the new name, but the bom still shows the old name.

The model tree shows the new name, yet the bom shows the old name.

Then the solution finally clicked.

I also have a wiring list on the drawing. This shows the values '&harn.run.cond.from.term.name' and '&harn.run.cond.to.term.name' which also showed the old model name. This gave me a clue as to what was going wrong. I realised there is a terminal table, and the terminal name in the table showed the old model name. This explains why the wiring list showed the terminals with the old name.

The assy bom must have been making the parameter '&asm.mbr.name' equal to the terminal name in the terminal table, even though the part had been renamed in Intralink!

Dave

Reply to
dakeb
Loading thread data ...

I don't really understand how Intralink handles renaming. Go take a look at your .proi folder. Does the termainl part file have the new name or the old? I've found that the old name is still used. (That's a good reason to use Backup or Export instead of grabbing files right from .proi.)

Somehow, Pro/E knows what the new name is from Intralink and thus can hide the old name from you. Maybe this failed in your case? I'm just guessing.

- Wallace

Reply to
Wallace White

Reply to
Mark

David Janes

Reply to
David Janes

The .proi gets cleaned out when you delete the workspace, but the next time you check something out, the "old name" will still be used for the parts in the .proi directory. I've talked to PTC about this, this is an "intended design". I don't know how you would get around it, unless you went back to renameing with everything in session and creating "new" parts in Intralink. You would still have a problem if the parts were used any other assembly, which would still be pointing to the "old name".

Mark

Reply to
Mark

: > David Janes : >

: : The .proi gets cleaned out when you delete the workspace, but the next time : you check something out, the "old name" will still be used for the parts in : the .proi directory. I've talked to PTC about this, this is an "intended : design". I don't know how you would get around it, unless you went back to : renameing with everything in session and creating "new" parts in Intralink. : You would still have a problem if the parts were used any other assembly, : which would still be pointing to the "old name". : This is the reason that I have always been skeptical of the widespread practice of using file names for part names. Who actually cares what the file name is. Make it

32 numbers and digits, from a random number generator. Make the part name a parameter in Pro/e that can be changed without problem and immediately updates in any assembly or drawing or BOM where it is referenced. And, causes no enormous difficulties in the pdm system, in the case of parameters, the pdm system is completely passive, just stores, doesn't get involved. All of this trouble seems to have been caused by the 'easy' way offered by the repeat region paramter, asm.mbr.name. Use asm.mbr.param.prt_nm or whatever your parameter name is and don't take the 'easy way out', which turns out to be not easy, just careless.

David Janes

Reply to
David Janes

What your proposing seems to be the easy or careless way out. I think PTC took the easy way out by not renaming actual file names in IL.

David Janes wrote:

Reply to
Boltman

Be nice to hear your thoughts on the *wisdom* of something which causes endless problems, reported frequently here and on other support sites.

: I think PTC took the easy way out by not renaming actual file names in IL.

The directory of file names is a system database. Oracle runs the database of references within Pro/e. Why go outside Oracle and mess with the system, given the unpredicatable and unintented consequences. (OK, pick up some completely harmless stuff like the current date and time.) They system itself, however, when you get to that level, can assign parameters, variables and input to a file that neither Pro/e nor IL have any control over.

You've got a powerful database and parameter management tool in Oracle; manage attribute stuff from within it (or get screwed MS-royally).

David Janes

Reply to
David Janes

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.