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.
boeing and lockheed only buy off on the iges files , protocol demands they be checked against the iges file period . not a " good master" the reason being is a good master is simply a part that is "in tolerance " and stackup can burn you. now to the really important thing any documentation on your faro arm build? i would be highly interested in seeing links to this and is it capable of comparing to an iges file? or just a good master? On Thu, Jun 13, 2013 at 10:31 AM, Ted Hyde <laser...@gmail.com> wrote: > 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 <jcyoung...@gmail.com> 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 > Emc-users@lists.sourceforge.net > 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 ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
