Since I am a beginner in ProE I may ask some foolish questions, please bear with me.
I have made a simple assy and the drawings of the assy as well as the parts. For a similar assy i need to copy the assy with drawings and same parts with minor changes.
To be more specific, I need to create new product with new names for the assy/parts/drawings by duplicating the existing without redesigning it from scratch also the drawings.
I have tried it by adding the config option rename_drawings_with_object < both> & all the concerned parts/drawings in the session and following problems faced.
Within the drawing only the generic model is changed and the flat state is having the old instance name as in the parent part, any option to change instance name?
2.The assy is copied and one of the parts are given a new names. But the flat state is not there in the copied part and the drawing uses the parent parts flat instance.
3.While saving a part/assy., the new parts/sub assy/drawings are also copied to the destination of new file. This disturbs the directory structure and the traceability as well. Any suggestions other than using different working directories for each projects?
I would prefer to use different folders for Assembly/Parts /Drawings and different names to all the components and drawings.
Since I am a beginner in ProE I may ask some foolish questions, please bear with me.
I have made a simple assy and the drawings of the assy as well as the parts. For a similar assy i need to copy the assy with drawings and same parts with minor changes.
To be more specific, I need to create new product with new names for the assy/parts/drawings by duplicating the existing without redesigning it from scratch also the drawings.
I have tried it by adding the config option rename_drawings_with_object < both> & all the concerned parts/drawings in the session and following problems faced.
Within the drawing only the generic model is changed and the flat state is having the old instance name as in the parent part, any option to change instance name?
Open the gneric and rename the instances. This doesn't sound like much of a problem. Outside of Intralink or PDM-Link, this isn't possible as part of the simple 'Save a Copy' way of saving/renaming a bunch of assemblies, parts and drawings.
2.The assy is copied and one of the parts are given a new names. But the flat state is not there in the copied part and the drawing uses the parent parts flat instance.
Ditto above.
"3.While saving a part/assy., the new parts/sub assy/drawings are also copied to the destination of new file. This disturbs the directory structure and the traceability as well. Any suggestions other than using different working directories for each projects?"
Can't 'Save a Copy' move these new files to any directory you select/create for the purpose of holding them? Maybe I'm not understanding the problem/question properly. Or what you mean by 'disturbs the directory structure and the traceability as well'. You don't have to set a new working directory or save to the current working directory to do a 'Save a Copy'. The problem will be, in the long run, that you will have some common parts, shared by several different configurations of the same part. While PDM/PLM solutions like Intralink and Windchill PDM-Link are meant to keep track of the location of assembly components, no matter how many directories they are scattered over, native Pro/e has only one trick up it's sleeve for finding such scattered parts (otherwise, yes, they must all be contained in the working directory). The trick it has is an option called SEARCH_PATH where you specify all the directories your components could be stored in with their full path names. The downside of this is that it can tremendously slow down the opening of large assemblies as it searches each directory in the path for each and every component (or at least until it finds it). The more paths it has to check, the slower it gets. It's a good solution for relatively small assemblies with relatively simple product structures and relatively few storage locations. In the end, though, you may have to turn to a program that records location as metadata through some kind of relational database.
problem. Outside of Intralink or PDM-Link, this isn't possible as part of the simple 'Save a Copy' way of saving/renaming a bunch of assemblies, parts and drawings.
for the purpose of holding them? Maybe I'm not understanding the problem/question properly. Or what you mean by 'disturbs the directory structure and the traceability as well'. You don't have to set a new working directory or save to the current working directory to do a 'Save a Copy'. The problem will be, in the long run, that you will have some common parts, shared by several different configurations of the same part. While PDM/PLM solutions like Intralink and Windchill PDM-Link are meant to keep track of the location of assembly components, no matter how many directories they are scattered over, native Pro/e has only one trick up it's sleeve for finding such scattered parts (otherwise, yes, they must all be contained in the working directory). The trick it has is an option called SEARCH_PATH where you specify all the directories your components could be stored in with their full path names. The downside of this is that it can tremendously slow down the opening of large assemblies as it searches each directory in the path for each and every component (or at least until it finds it). The more paths it has to check, the slower it gets. It's a good solution for relatively small assemblies with relatively simple product structures and relatively few storage locations. In the end, though, you may have to turn to a program that records location as metadata through some kind of relational database.
Thanks for the reply,
problem. Outside of Intralink or PDM-Link, this isn't possible as part of the simple 'Save a Copy' way of saving/renaming a bunch of assemblies, parts and drawings.
This can only change the name of the instance in the part. Since the drawing uses the flat state of the parent part if I modify the new part the drawing will not get updated.
We are currently working in Autocad and have a very fine system of saving different parts and assy drawings in different folders with respect to the type/usage of the part. I was trying to keep the same directory structure in ProE also and as you said, i had already put the concerned path in search path.
The explanation is clear to me. I was thinking to avoid PDM since we are in the beginning stage of implementing ProE and the management has to decide on purchasing PDM. As expert users of ProE and data management solutions are you suggesting me to get PDM to sole my issues?
My major issue is as I explained earlier, I need to create new product with new names for the assy/parts/drawings by duplicating the existing without redesigning it from scratch.
This can only change the name of the instance in the part. Since the drawing uses the flat state of the parent part if I modify the new part the drawing will not get updated.
We are currently working in Autocad and have a very fine system of saving different parts and assy drawings in different folders with respect to the type/usage of the part. I was trying to keep the same directory structure in ProE also and as you said, i had already put the concerned path in search path.
The explanation is clear to me. I was thinking to avoid PDM since we are in the beginning stage of implementing ProE and the management has to decide on purchasing PDM. As expert users of ProE and data management solutions are you suggesting me to get PDM to sole my issues?
My major issue is as I explained earlier, I need to create new product with new names for the assy/parts/drawings by duplicating the existing without redesigning it from scratch.
Thanks
Vinu
Honestly, I haven't done anything in Pro/e, as far as file management, product stucture, drawing trees, etc., outside of a PDM/PLM/MRP system, ever. That's just the way places are set up, especially the one that have multiple facilities, outsourcing, multiple product groups who need common access to common files and local customization. It's just that I haven't done or experienced what you're talking about with a PDM system. And, from what you've said, it sounds like you're doing everything correctly. And, I see no reason you shouldn't be able to duplicate your existing directory structure with Pro/e. Are you getting any error messages? As to a new flat state name registering in the drawing, drawings are funny. Some things are associative, some not. Generally, they're controlled within the drawing. You can't change the part for a view except in a limited number of ways, controlled by the drawing with drawing models>add model or delete model or replace (which should be possible with a family table instance). And you can't delete a model with a view still using it. None of this is automatic with adding or "renaming" instances. I'm not sure if this particular thing is easier with a PDM system but lots of things are. It wouldn't hurt to get PTC's pitch on the benefits and present them with various problems with migrating data and see get their approach.
a problem. Outside of Intralink or PDM-Link, this isn't possible as part of the simple 'Save a Copy' way of saving/renaming a bunch of assemblies, parts and drawings.
select/create for the purpose of holding them? Maybe I'm not understanding the problem/question properly. Or what you mean by 'disturbs the directory structure and the traceability as well'. You don't have to set a new working directory or save to the current working directory to do a 'Save a Copy'. The problem will be, in the long run, that you will have some common parts, shared by several different configurations of the same part. While PDM/PLM solutions like Intralink and Windchill PDM-Link are meant to keep track of the location of assembly components, no matter how many directories they are scattered over, native Pro/e has only one trick up it's sleeve for finding such scattered parts (otherwise, yes, they must all be contained in the working directory). The trick it has is an option called SEARCH_PATH where you specify all the directories your components could be stored in with their full path names. The downside of this is that it can tremendously slow down the opening of large assemblies as it searches each directory in the path for each and every component (or at least until it finds it). The more paths it has to check, the slower it gets. It's a good solution for relatively small assemblies with relatively simple product structures and relatively few storage locations. In the end, though, you may have to turn to a program that records location as metadata through some kind of relational database.
a problem. Outside of Intralink or PDM-Link, this isn't possible as part of the simple 'Save a Copy' way of saving/renaming a bunch of assemblies, parts and drawings.
stucture, drawing trees, etc., outside of a PDM/PLM/MRP system, ever. That's just the way places are set up, especially the one that have multiple facilities, outsourcing, multiple product groups who need common access to common files and local customization. It's just that I haven't done or experienced what you're talking about with a PDM system. And, from what you've said, it sounds like you're doing everything correctly. And, I see no reason you shouldn't be able to duplicate your existing directory structure with Pro/e. Are you getting any error messages? As to a new flat state name registering in the drawing, drawings are funny. Some things are associative, some not. Generally, they're controlled within the drawing. You can't change the part for a view except in a limited number of ways, controlled by the drawing with drawing models>add model or delete model or replace (which should be possible with a family table instance). And you can't delete a model with a view still using it. None of this is automatic with adding or "renaming" instances. I'm not sure if this particular thing is easier with a PDM system but lots of things are. It wouldn't hurt to get PTC's pitch on the benefits and present them with various problems with migrating data and see get their approach.
Dear Mr. David
There are two cases;
While duplicating a part using 'save a copy' things seems to be ok after changing the instance name in the family table manually in the newly copied part and by replacing the instance in the drawing.
In case of an assy. case is different. After copying to a new name, since there are no flat states available in the renamed part, even after creating one with the same name as in the parent part, it is not possible to replace it in the drawing. More over the drawing fails to open and asks for the parent parts instance if both are in different folders.
I have tried my best to find a solution for the above said issue but couldn't sort it out, anyways I'll get back to you once I get a perfect solution.
While duplicating a part using 'save a copy' things seems to be ok after changing the instance name in the family table manually in the newly copied part and by replacing the instance in the drawing.
In case of an assy. case is different. After copying to a new name, since there are no flat states available in the renamed part, even after creating one with the same name as in the parent part, it is not possible to replace it in the drawing. More over the drawing fails to open and asks for the parent parts instance if both are in different folders.
I have tried my best to find a solution for the above said issue but couldn't sort it out, anyways I'll get back to you once I get a perfect solution.
Thanks & best Regards,
Vinu
The chief problem is that, in creating a new assembly and creating new "parts", you don't actually create new generics. With 'Save a Copy', there's no opportunity to change the name of the generic (which remains hidden, the obscure container). What you might try doing is to do a save as on the generic, do a Replace and pick, not 'Family Table' but 'By Layout' and pick the new generic which ought to bring up the instance selection dialogue. Creating newly named instances ought to help with distinguishing the families from one another. Baby is easily confused enough as it is without adding the challenge of same named instances in different family table parts. Pro/e'd have conniptions. It's too easy to get it riled up anyway without goin' out of your way to aggrevate it. Be very cautious and conservative with family talbes and family table parts!
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.