In regards to a depth sensor, there's a good change Aram is referring to a Kinect or the Asus Xtion (Pro Live). There's been plenty of hacker-friendly attempts for "point-n-shoot" capture solutions using these over the years, adding to the laser-line, and distributed-light methods. The Xtion unit retails sub-$250, so it's an expensive experiment, but a contender for entry-level scanning - but it's only part of the hardware side. The DAVID project uses just laser and distributed light methods (at current, IIRC), so not a compatible software piece. There are retail packages that speak with a Kinect or Xtion, my favorite low-cost at the moment is Manctl's "Skanect", but I also like the free Faro (tickler), "Scenect". There are of course others. Most are Win32 or Win64 offerings only. OpenCV is often used as a framework for open-source attempts, so not all hope is lost if someone wants to try....
In a commercial environment, I do create and provide "difference scans" of parts in some cases as required by a client, but it's pretty rare. A big thing to note about volumetric scanning versus probing is that scanning gets you a profile, and it takes a lot of time; probing gets you parametric data and can be extremely fast. To implement an in-process scanning technique effectively, I would have to do it in between machining operations - not just at the end, as one part feature may be dependent upon the next, such as a helical thread inside a drilled then bored hole) - and although most faults like that would cause tool damage, I wouldn't want to write part programs so that each individual feature is a separate operation (that's what automation is supposed to make easier!) - thus the logic decision as to how to "fix" the problem won't exist. Even if it did, one would have to scan a "known-good-master" at each step of the production for the test scan to reference against. If you want accuracy, measuring scale on a single volumetric scan is near impossible. You need to have many angles and views stitched together to see past obstructions. Any imperfection in the part, including unintended, is recorded [perfectly]. Furthermore, the scanner is unable to understand chips, swarf or coolant sitting on the part - it will look like a fault in the part and raise an alarm. Get coolant on the lens and your scanning is of no value. Probing, on the other hand, can be more easily automated, and directed towards achieving the stated goal - whether or not a particular feature is within tolerance. I use both laser and depth-based scanning plus probing for a variety of tasks, but only probing on my machines. I would liken volumetric scanning versus probing to the earlier implementation of a webcam (camview by pavel et al, for example, which I really do applaud) for tool-length-setting (and more) versus a touch probe. Although I'm enamored with having a non-contact tool setter, a camera is much less tolerant of mistakes or changes in the environment than a touch probe. When you just want to get parts out, the touch probe "JustWorks". That's not to say that having a volumetric scanner as a tool in a machine isn't a possibility or a value, but the historical intent for LCNC not to require a "64bit 8-core watercooled machine with Cray loadbalancing (sic)" makes it a difficult challenge to have it integrated with LCNC. My preference would be to have it on a separate machine as a standalone application, but load the sensor as a tool when needed. The benefit is the automation of the motion of the camera (instead of human hand) which in that aspect, would return a much more accurate result. Since the software has to "chew" on the scanning result, it would actually be dangerous to have this type of interruption (and I guarantee it would be an interruption) to the safety of the LCNC realtime loop. Ted. ------------------------------------------------------------------------------ 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
