Quantcast
Channel: PTC Community: Message List
Viewing all articles
Browse latest Browse all 12262

Re: Sheet metal fiasco..

$
0
0

Why dosen't the family table also update?  And insists on pointing to the old part?  I woudl think that if I rename a part, the included instance would also get renamed..

It can't.  It's like if you rename a spreadsheet in Excel, the contents of the sheet don't change.

 

Any place using the instance has a reference built in, like Instance_name->Generic_name, so it knows where to look for the Instance. It can't search all the parts on the off chance that one has a matching instance in it, so it depends on the Generic_name to find it. It also can't depend on the Generic not getting the instance deleted, so if it doesn't find a file that matches Instance_name, and it doesn't find Instance_name->Generic_name, it falls back to Generic_name.

 

I also note that between steps 3 and 4 there wasn't Verify family table.

 

Verify is somewhat critical for this reason - When you edit the family table and change the name, you are effectively deleting the old part entirely and creating a brand new part. PTC doesn't track based on the entry number in the table, only by name. Manually change the name in the table, and it's a new part. Verify replaces a number of things which were deleted when the old part was deleted. It doesn't fix the drawing, but it is needed on the way to do so.

 

The better approach is to Rename in session: the part, the instance, and the drawing, and then fix the Common name. This way all the relationships between the generic, the instance, and the drawing are in place and only the Common name parameter needs (not really, it could stay the same, depending on down-stream use) to be changed. Verify is still a good idea, but since nothing is deleted, it isn't as big a problem.


Viewing all articles
Browse latest Browse all 12262

Trending Articles