Am 15.12.2010 09:38, schrieb Viesturs Lācis: > 2010/12/15 dambacher-retrofit.de <[email protected]>: >> >> So basically what I suggest is having a hal pin "motion.collision-distance" >> and >> some ini variables like [traj]collision_warning and [traj]collision_threshold >> acting like calculated soft limits. >> >> How do you think about this? >> > > Well, I have few considerations. For better understanding I will use > an example of Ulf's bending machine with 2 catches. The collision > distance will be the distance between two points, supposedly, two > center-points of each catch. Those catches are not spherical, so to > have this feature be very nice, the minimum distance between those > centers just before collision should vary, depending on the direction, > how they approach each other - if they are moving sideways (along X > axis) or back/forth (along Y axis) or up/down (along Z axis), the > collision distance will differ. It gets even more complicated, if > catches are moving in a plane, along 2 axis simultaneously. And the > best thing is, when catches are moving in different planes - movement > direction for one is in horizontal (XY plane), for another - in some > vertical direction. > Well, personally I cannot really think of a way, how to do such a > calculations dynamically, when machine is moving.
Well you can start with simple calculation rules like (catch1x - catch2x) - WITH_OF_CATCHES <0 (catch1y+w)<0 (catch2y+w)<0 You build min of them and feed that to motion.collision-distance Or for a 3axis-mill it would be calculating the hight between tool tip and table top. Yes, 6axis get more complicated, but it's basically getting the distance of a point above a plane. > That would require > defining the dimensions of each catch and some new module, which could > simulate the shape of each catch and check, how far from collision are > they. So I suspect that getting such a concept programmed in a code is > even more of a nightmare. No, I did exactly that some years ago, implemented in pascal, geomeety looking a bit like in vismat. If I remember correctly, the calculation is based on checking "viewports", e.g. you look from above, if two 2d objects intersect each other, then from left and then from back. If they do not intersect in at least one view, they dont collide. Unfortunately the code is turbo pascal and I'm not allowed to contribute it. > > I think that it would be a wonderful feature to have, thus allowing > building plasma/laser/waterjet cutting machines with several cutting > heads and having a possibility control each of them separately. I > think that it would also allow for double-spindle milling router, > which could do roughing with one head on one end of material and > finishing passes on the other end of material with the second spindle > (yes, i have yet ignored a necessity to generate such a g-code, but I > am hoping, that, if there were a demand for such a g-code generating > capability, it would meet some supply). the problem is that the emc code base is too fixed on 6 axis milling with 3 supports. Hal could do more, but can you run two instances of emc/axis side by side? /ulf -- --------------------------------------- Ulf Dambacher [email protected] --------------------------------------- ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
