On Wed, Apr 8, 2009 at 12:01 AM, Thomas Paviot <thomas.pav...@free.fr> wrote: > Bryan Bishop a écrit : >> On Tue, Apr 7, 2009 at 6:36 AM, Bryan Cole wrote: >>> I've been working with pythonOCC for a week or two now. Can anyone give >>> me some pointers on how to construct assemblies in OpenCascade. I >>> suspect I need the OCAF framework for this, but I'm not too sure. Will >>> Compound Shapes achieve this? >> >> I'm not aware of any "asssemblies" stuff done with OCC, so I've been >> implementing my own part mating stuff. Does anyone know if this is >> redundant? > > Hi Bryan, > > I'm surprised to see here a discussion related to assemblies and part > mating. As I think that a mating system is relevant for a 2D sketcher, I > don't consider this is an issue for assembly stuff. > > Basically, an assembly is a set of parts that are positioned in a 3D space. > You have then only 2 ways to achive that: > - a relative location of each part in relation with the other parts (1), > - an absolute location in the 3D space (2).
Yes, that's correct. For an assembly format that just represents where everything goes with respect to everything else, an absolute positioning system is completely valid and is the only way to go. I am actually doing something a little bit different than an assembly file format though. What I want to implement is a way to check whether or not two given parts/CAD-parts are 'compatible' with each other. Compatibility and interoperability are very important issues that usually go overlooked. There are two aspects to compatibility: (1) geometric compatibility-- does it fit, does it interfere with other parts (physically), do the tolerances suck, and then there's also (2) is the output interface of one part rated within the range of the input interface of another part? In other words, you don't want to wire up 3000 psi to something that is rated for only 20 psi. So, you can do this with a labeling/tagging schemes on parts, such that the interface face of one part has a list object of 'constraints', and evaluators would check whether or not two lists (representing two interfacing interface faces) "fit" each other; geometrically, you can use a collision detection algorithm. So it's a little more involved than wondering about the positioning of the parts with respect to each other. Also it's hard to avoid having to use a geometric constraints engine *but* I figure that if you need to use geometric constraints, you should do that in a CAD file separately and import that into this assembly software (SKDB)-- although ultimately it would be nice to have a portable constraints satisfaction engine that we could plug into things. The problem is that in the literature, CSPs (constraint satisfaction problems) are known to be NP-hard, and the methods developed for slving them- graphs, algebraic methods, theorem-solving, etc.,- only go so far and don't really guarantee that you're going to be able to solve problems (so ideally we can avoid using a constraints solver without losing functionality). > The assembly mates (parallelism, distance, etc.) are clearly in the first > field. I was really impressed when I discovered very efficient mating > systems in SolidWorks or Catia V5, and really became a mate addict. Then I Yeah, I was also impressed, although I'm equally confused as to how they are implementing it. > realized a few years ago that these systems actually create more problems > than they solve. In a few words: if you work alone on a small project, > assembly mates are practical. If you are a member of a project team in > charge of the design of a car or an aircraft, it becomes impossible to deal > with mating stuff: mates increase complexity of the system (in the sense > that the number of connections in the system increases as well) that make a > big problem not separable in smaller ones (and then conflicting with Right, that's why it needs to be automated to some extent. This is a software problem :-) not a human design problem. > Descartes' method!). On the other hand, if you want to share product > information, you have to store product data with a small granularity in PDM > systems. You have here a strong conflict (complexity/granularity) that can, > as far is I know and from what I've seen, be simply solved by this way: Granularity is a big issue. I agree. How detailed do you make your constraints, for instance? How detailed did the other part make its constraints, and how do you know? > - the assembly is a simple XML file that contain pointers to other CAD files > and an absolute 3x4 position matrix, > - store the CAD files and the XML in your PDM system, > - generate the 'assembly view' on the fly whenever requested. "On the fly" is an ok method to me. > That is, the second solution (absolute positioning) seems to be the more > robust. That's why I think part mating is not an issue anymore: I (and other > people) gave up with that! But what do you think about the features that I listed above that go above and beyond positional issues? > At last, if one really wants to be rigourous, follow the STEP PDM Schema 1.2 > specifications: > http://www.steptools.com/support/stdev_docs/express/pdm/pdmug_release4_3.pdf > . This document is a master piece, in my opinion the best ever written about > assemblies (and a lot more things), that everyone should read once! Awesome. Thank you! - Bryan http://heybryan.org/ 1 512 203 0507 _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
