My point about scanning multiple "known good masters" was that Aram's stated intent was to correct machining [on the fly] - an Iges (or any other neutral format) from a modeler would [typically] give you the intended finished part, not something partially complete. I'm following this up more as an intellectual exercise, as the future certainly holds options similar to this, and actually, I like where the discussion is heading.
It's tough to define the logic on what a machine needs to "fix" in the middle of the process, if all it has it the final part. For example, if you have a part that requires a drilled hole, counterbore, and edge chamfer, all of which you generate with standard tooling (not a single form tool), you have for example, three operations (more if you spot drill and ream of course). Assuming part lineup and planar corrections are all taken care of, if you directly compare your finished Iges against the first two major operations, the comparison will fail. The computer will say the hole is smaller than it needs to be and throw up a red flag. If instead of drilling, you decide to helically-bore the original hole and the counterbore, the automatic logic may actually direct the machine to re-bore the first hole to the wrong size (larger counterbore) all the way through and destroy the part. Thus, if you're going to do interim comparisons, you need to have interim masters, or at the very least, enough intelligence and command in the comparison program to limit the areas to be scanned versus the areas to be ignored - in 3d space, of course. I consider myself a comfortable coder, but even I wouldn't want the task of that - I'd rather have a series of "golden samples" each stage along the way just to do direct comparisons to. I do use Iges files (either customer provided or in-house generated) in Rhino3D against an optical scan to show simple difference models (no special FEA or the like) - I simply make the bodies different colors and let the renderer figure it out - it's the pretty picture of red and green that the client likes to see. From a measurable aspect, I dig out my Faro arm too - before you say, "true, he has all the toys" - this one I built from found digitizing arm parts (read: dumpster and ebay), hacked it together and built my own system. I didn't have the 20K to drop on one of these wonderful units. (And I really like the idea of working on my own gear.) Although I machine and design as an occupation, its the CAD that really pays the bills so I have the opportunity to CNC as a hobby. The toys, both commercial and "hobby-fied", try to support the occupation as best it can. Btw - EMC/LCNC was a big help in getting that arm going - it taught me about [serial] forward kinematics and how easy it is to lose your mind trying to figure out a little grid of numbers 4x4! I eventually moved the system over to Unity3d (game engine, not the Ubuntu gui) where I can run capture on my phone or tablet, then export that as an intelligent point cloud to Rhino for building. Which is where this conversation goes next. We had a lot of discussion a number of years ago with folks trying to build their own digitizing arms - you really need a stable structure and preferably 6 degrees of freedom, (thus 6 encoders) - but after that, the kins can be done in many possible ways. Some of us even tried doing it by straight math in a PIC or Arduino, (insane asylum, please!) although I got really lucky with Unity3d: build a model of the arm, drop it in properly parented, feed in the encoder angles via a serial port, write a lot of script, route a lot of PCBs, and eventually, watch the arm move around in virtual space. A few years ago, I would have lost my mind, though today it's become a lot more readily available to "us unwashed masses". I have an affinity to (no, actually I LOVE) the arm concept because I get to choose what gets scanned and how it gets scanned. That's what I consider the most important item in making a point cloud (or any data) useable. The human element lets us draw the line the way we see it or need it, the machine gets the hard data. If I want to know parametrics of a round hole, I don't scan the entire circle, I hit a button that I use as a macro that I touch three points on that circle, which results in a center and a radius. Math can be awesome. Rhino and many other 3d modelers have varied tools for creating drapes and such from a cloud of points, but all will have limited results if its just a rectangular cloud. The modelers all know what to do with a center and a radius, however. And let's face it - as machinists we're really interested in the center of a hole and it's diameter - not that it has 412 verts with one reversed normal..... We can see automation added to this by looking at a current CMM; instead of having to manually run the probe around with a joystick, you can now teach (by manually running the probe around with a joystick), or by script/conversational, program the machine for repetitious tasks. Even macros or sub-programs within a semi-auto task. (We can even, if we choose, make a probing program in g-code for probing in LCNC, so not too unrealistic right now). The best I've seen so far (but not yet in LCNC) imports a 3d model of your finished part, or if in-process, a partially finished part, and generates a probing boundary plus specific parametric checks (like diameter and depth of a hole), based on a combination of the raw part outline and user input. That's where I consider the logic to be in the right place - I don't think it's necessary to take the human all the way out of the equation, sometimes the grey matter still exceeds the silicon. Ted. >> On 12 June 2013 13:52, jeremy youngs <[email protected]> wrote: >> >>> not exactly just compare it to an iges file that will never change . or >>> other parametric solid >> Going from a point-cloud to a parametric solid is not even slightly easy. >> However, in this case I guess that you could create a virtual >> point-cloud from the IGES file for point-by-point comparison. >> >> ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
