It makes no real difference if you add parent/child relationship on Assembly or on Part(Design) level.realthunder wrote:I used assembly2 alot. I think the biggest problem of assembly2 is a conceptual error. Instead of selecting all those connecting faces, edges in the assembly file, and trying to solve the unsolvable problem of updating those faces and edges after part model changes, one should in fact defining those faces and edges in the part file. The part author knows what faces or edges are supposed to connect to others. And the part author knows when and how to update those geometries manually, when he updates the model. Yes, manually. There is no way to solve this problem automatically. The part file may contain more than one parts of course, and the part author can use special container to mark which geometry can be imported as part, and inside those parts, which faces/edges are connectable. The faces or edges can even be separate copies of the actual geometry (optionally invisible), instead of just text sub element name reference to the model.
I think @realthunder workaround makes a difference for some type of parts. Specially bolds nuts rings etc etc that are parts placed always on the same method.triplus wrote:It makes no real difference if you add parent/child relationship on Assembly or on Part(Design) level.
Hi,yorik wrote:How they do it in digital project. Pretty similar to what we are discussing here...
and so that's exactly the proposal of Realthunderrealthunder wrote:Yes, manually. There is no way to solve this problem automatically. The part file may contain more than one parts of course, and the part author can use special container to mark which geometry can be imported as part, and inside those parts, which faces/edges are connectable.
One more way to do it. Interesting... With that system one can actually use any other file as reference, no need to "mark" the geometry to be importednemesis wrote:Caria behave exactly this way with generating CGR files first when you open an assembly.
Well, it looks like he was not very interested in integrating it. it's a propriatary format.Pauvres_honteux wrote:I'm pretty confident Jürgen started something with that format back in the days.
Uhmm, that could be debateable...nemesis wrote: ... he was not very interested in integrating it.
not sure ... that's the standard example available with all teamcenter versionPauvres_honteux wrote: Uhmm, that could be debateable...
the question is "Is there an opensource lib available to read/writ jt file without licence issue, andjidoeuf wrote:"OPEN CASCADE JT Assistant is intended to be a basis for development of custom applications dealing with JT data format"
JT are now at version 10.2 in teamcenter 11.2 so, jt assistant is already outdated. that's the issue with a non opensource format I guess. But Developers would have a better point of view than me I guess....JT file versions 8.0 - 9.5 are currently supported. Mesh data and assembly structure are visualized. Monolithic and non-monolithic assemblies are supported.