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

 

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

 

: When you rename something in Intralink, the name of the file doesn't change.
: Anytime you look in your .proi directory, you will still see the old name.
: This is so Intralink doesn't have to open all the asemmblies using this part
: and renaming them there. This "feature" has caused me several headaches,
: like when the .proi becomes corrupt and you need soemhow get to the models
: you modifed and didn't check back into commonspace....
:
When does .proi get 'cleaned out'? when you check everything back in? Is there
some way to 'refresh' or sync it?

David Janes

 

: : > : > : When you rename something in Intralink, the name of the file doesn't
: change.
: > : Anytime you look in your .proi directory, you will still see the old
: name.
: > : This is so Intralink doesn't have to open all the asemmblies using this
: part
: > : and renaming them there. This "feature" has caused me several
: headaches,
: > : like when the .proi becomes corrupt and you need soemhow get to the
: models
: > : you modifed and didn't check back into commonspace....
: > :
: > When does .proi get 'cleaned out'? when you check everything back in? Is
: there
: > some way to 'refresh' or sync it?
: >
: > 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

 

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.

 

: What your proposing seems to be the easy or careless way out.

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