daveykbelgium
Mechanical
- Mar 12, 2005
- 73
We are using Wildfire 2.0 (M130) and Intralink 3.3 (M022)
We use sophisticated top-down design methodologies, but are having problems with Intralink submissions.
In a simplistic overview, we have sub-assemblies, sub-modules and the master assembly.
Sub-assemblies make sub-modules, and sub-modules make the master assembly.
Each sub-assembly has its own specific sub-assembly skeleton and sub-assembly layout. We could have chosen one layout for the entire product, but with many sub-assemblies and sub-modules, we feared that at the beginning of the project, many designers would be fighting to change the one and only layout and submit it back to the database. Thus we opted for one layout per sub-assembly.
Sub-modules always have their own specific sub-module skeleton, and each is built up from copy geometry features from contributing sub-assembly skeletons. Sub-modules don’t have their own layout, but refer to a master layout. This declaration is only made to access a declared co-ordinate system for auto assembly functionality. I could have created a sub-module layout but didn’t, and wonder now whether this was a mistake?
Using copy geometry means that sub-assembly detail is abbreviated in the sub-module skeleton.
There is a master skeleton, and this is made using copy geometry features from the sub-module skeletons. The master skeleton declares the master layout.
As the system architect, it is common for me to work in a Pro/INTRALINK workspace where more than one sub-assembly and/or sub-module are being modified.
My problem;
I want to make a discreet and well documented submission of one sub-module into the database. However, because the sub-module has a dependency to the master layout, and this has a dependency to the master assembly, every modified file in the workspace wants to be submitted back into the database.
Reading about Intralink 3.3, we think that this is a bug.
Does anybody have similar experiences with layouts and skeletons, circular dependencies, work-arounds, or alternative methodologies?
Does anybody have detailed explanations about circular dependencies?
Thanks in advance
Dave
Meerkat Design
We use sophisticated top-down design methodologies, but are having problems with Intralink submissions.
In a simplistic overview, we have sub-assemblies, sub-modules and the master assembly.
Sub-assemblies make sub-modules, and sub-modules make the master assembly.
Each sub-assembly has its own specific sub-assembly skeleton and sub-assembly layout. We could have chosen one layout for the entire product, but with many sub-assemblies and sub-modules, we feared that at the beginning of the project, many designers would be fighting to change the one and only layout and submit it back to the database. Thus we opted for one layout per sub-assembly.
Sub-modules always have their own specific sub-module skeleton, and each is built up from copy geometry features from contributing sub-assembly skeletons. Sub-modules don’t have their own layout, but refer to a master layout. This declaration is only made to access a declared co-ordinate system for auto assembly functionality. I could have created a sub-module layout but didn’t, and wonder now whether this was a mistake?
Using copy geometry means that sub-assembly detail is abbreviated in the sub-module skeleton.
There is a master skeleton, and this is made using copy geometry features from the sub-module skeletons. The master skeleton declares the master layout.
As the system architect, it is common for me to work in a Pro/INTRALINK workspace where more than one sub-assembly and/or sub-module are being modified.
My problem;
I want to make a discreet and well documented submission of one sub-module into the database. However, because the sub-module has a dependency to the master layout, and this has a dependency to the master assembly, every modified file in the workspace wants to be submitted back into the database.
Reading about Intralink 3.3, we think that this is a bug.
Does anybody have similar experiences with layouts and skeletons, circular dependencies, work-arounds, or alternative methodologies?
Does anybody have detailed explanations about circular dependencies?
Thanks in advance
Dave
Meerkat Design