sorry sent before finished , i agree with all of the other statements though
On Wed, Jun 12, 2013 at 8:52 AM, jeremy youngs <[email protected]> wrote: > ted said > > 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]. > > > not exactly just compare it to an iges file that will never change . or > other parametric solid > > > On Wed, Jun 12, 2013 at 8:44 AM, Ted Hyde <[email protected]> wrote: > >> 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 >> > > > > -- > We conclude that the Second Amendment protects an individual right to keep > and bear arms. That right existed prior to the formation of the new > government under the Constitution and was premised on the private use of > arms for activities such as hunting and self-defense, the latter being > understood as resistance to either private lawlessness or the depredations > of a tyrannical government." - U.S. Court of Appeals, D.C. Circuit, March > 9, 2007 > > > > jeremy youngs > -- We conclude that the Second Amendment protects an individual right to keep and bear arms. That right existed prior to the formation of the new government under the Constitution and was premised on the private use of arms for activities such as hunting and self-defense, the latter being understood as resistance to either private lawlessness or the depredations of a tyrannical government." - U.S. Court of Appeals, D.C. Circuit, March 9, 2007 jeremy youngs ------------------------------------------------------------------------------ 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
