Of course the geometry (I mean the geometry of last time shot of part/body history) must be loeaded into the assembly.realthunder wrote: ↑Fri Jan 11, 2019 9:20 am Okay, Catia can create a constraint on a part in a separate file without loading it, so how does Catia assembly knows about the Parts geometry? Does It store the part's geometry inside the assembly? That's very unlikely. The fact that there is no UI showing the Part is loaded, does not mean the application did not read the file.
Otherwise you wouldn't see anything in the geometrical display window of the assembly module.
To me it doesn't make much sense to use a past historical feature of a body as a constraining element. Anyway, if you want to use in the assembly constraint of Catia a scketch which belonges to a body and was "absorbed" in pad feature, you may create a new set (a generic container) and put into it a copy of the sketch. Each body/geometrical set has a separate history. So, if you leave the geoemtrical set as it is at this point, the sketch inside of it will be visible in the assembly and usable for an assembly coonstraint.realthunder wrote: ↑Fri Jan 11, 2019 9:20 am Remember that A3 allows you to use any feature as constraining element, even historical feature in a body, a sketch, or datum.
Regarding a datum element of course it may be usefull as a constraining element but it can be used also in Catia (assuming that is present in the last time shot).
I have understood very well this point. May be some time I have misspelled storage of links (which is always done in the assembly) with storage of referred elements (and here there is a big difference between ASM3 and all/most others CAD/assemblies).realthunder wrote: ↑Fri Jan 11, 2019 9:20 am Besides, please remember that A3 does not only store link information inside a Part, the assembly constraint contain links too, and it is stored with the assembly.
In fact I think that your idea of storing elements in part works makes sense to me, but only for what are normally known as "published features" or we may also call them as "explitely declared interfaces". Other elements (we make call them implicit interfaces) which, are cretaed by the assembly when you make a constraint that is referring to a real geoemtry, are better stored in the assembly. Here I am endorsing a proposal made by saso in a previous post.
Another possibility could be, as I proposed in a previous post, to store the "implicit interfaces" in a separate file/database which is associated with the part (and used by it only in read mode) and contains several sub-sections. Each sub section would would contain the elements created by an assembly and would belong to it. In that way the part would have the chance to know if one of its geometrical entity is used (referred to) in an assembly and the user who opens that part would be warned if he try to delete that geometry. But olnly the assembly that created the element should be allowed to delete it. The reference files (the sections owned by it) should be loaded in into an assembly when it is opened. The assembly would than have the chance to add or remove elements into that file.
But I am not sure if this additional complexity (with respect to the simpler configuration propesed by saso) is worthwhile to implement. The only additional benefit would be an alert that prevents you to delete a geoemetry inside of a part file (a geometry that you forgot to have used somwhere for an assemby constraint).