Family Member "disowned"

[jelston]

I have a problem with family members. Sometimes if i replace a generic with a family member, save, close, the whole shabang; when i open Pro/E again open the assembly, the whole shabang (i like that word!) neither the generic part nor the family member are recognized. BUT, when i open the erase the memory, open the generic first then open the assembly, all is well. Any ideas?

 

[charleskim]

Did you verify in your family table?

 

[jelston]

I don't remember if i verified this one; what exactly does verifing a family table mean?

 

[jelston]

Well, my problem was a simple enough! I had an old copy with the family table in the working directory I assigned. The new one with the family table is part of my library and the old one was the first thing with that name that it saw, so it snatched it up. Which is another shortcoming of Pro/E that i loathe.

 

[gkbeer]

That's actually the way it is supposed to work.

 

[jelston]

Some company's software identify parts by some other method that doesn't lose a part simply because the name changes.

 

[dr_gallup]

First rule of good file management: NEVER EVER have duplicate filenames.

 

[jelston]

Well, the software completly BLOWS that rule!!!!


See what had happened was...


I made a family table in a .prt.(x+1), well for some reason, Po/e treated this like a different name than .prt.x


Po/e- this was a mistake but I like it now.
Edited by: jelston

 

[mjcole_ptc]

Pro/E opens files from a specific working directory. If you're part isn't in that directory it searches the search paths which can be specified in the config.pro file with the first option below or in a separate search_path_file


search_path
Specifies list of directories to search (in order) for object/file retrieval. These directories, They will be searched in the order listed in the config.pro file.

search_path_file
Specifies path to text file search.pro (a list of directory path names). The directories listed are Pro/ENGINEER's search path. Use full path name to avoid problems.

another option to look at is
disable_search_path_check no

Unlike using UG where you must use either as saved, or from folder or search files when opening Pro/E does all three.

You should also try to disable save_object_in_current and override_store_back_options so you don't have the same file name in all your directories.

Michael

 

[jelston]

You should also try to disable save_object_in_current and override_store_back_options so you don't have the same file name in all your directories.

?????

 

[mjcole_ptc]

Yeah I'll get right on answering your questions if you ask any.

 

[dgs]

One other place Pro|E will look is the parent assy's folder. Also, for us veterans, I think that PTC changed the default search order a few revs ago. It used to be:

1. 
   <LI>Working Dir</LI>
   <LI>Directory of parent assembly or drawing</LI>
   <LI>search paths, in order</LI>

Now, it's:

1. 
   <LI>Directory of parent assembly or drawing</LI>
   <LI>Working Dir</LI>
   <LI>search paths, in order</LI>

This was done, I guess, to conform to something or the other, I dunno. There's a config option (which I cannot find right now)to set it back the way it was.

 

[pjw]

There are definitely bugs with Pro/E and family tables. I'm not arguing with any of the other points but I have regulary seen Pro/E break off family table member to be stanalone during a save. Sometimes, an instance won't be retrieved into an assembly unless the generic and instance of that sub-assembly or part are explicitly opened first. I have also see rpblems where family tables are wiped out (**********) during operations in the workspace.

 

[jelston]

Sometimes, an instance won't be retrieved into an assembly unless the generic and instance of that sub-assembly or part are explicitly opened first.

That's my problem! How the other topics came up I'm not sure.

 

[pjw]

It is a bug. I know this for sure. If you know this you can get round it when you open up your problematic assemblies. Other than reporting it to PTC, there's not a lot you can do. Somehow, the link is becoming broken and the assembly is unable to retrieve what it needs with some part/assembly instances.

 

[jelston]

I figured it out!!!! We are all being PUNK'D. We are all part of this huge a-- joke by Ashton Kutcher and PTC. The real, fully functioning version of Pro/E will be coming out soon.