Messages

1301

Video P*r*o*b*i*n*g / Re: Photos of webcam scanner. ( no laughing.. :) )

« on: April 12, 2008, 09:09:06 AM »

Hi:

 Glad to hear your starting to get results. It really is a bit of an Art more than a science as yet.
Just a note on MachCloud, the meshing is really pretty touchy about point cloud density, finding tangental
vectors for point cloud points is a difficult statistical issue, but I dont think restarting the program is whats making it
work for you, Ive done hundreds of meshes, and I find its the decimation of the cloud thats really the trigger as
well as the ball size used. Ball meshing is basically placing a ball of a set diamter on the point cloud at an arbitray spot, then
rolling it over the point cloud and creating mesh lines whnever the ball hits two other points. Its analogous to rolling a ball
bearing over the surface with some conditions as to the angle of the lines created in reference to other mesh lines in the local
area. Its very complex really though it sounds easy, so point cloud conditions are important.
  Id simply remesh with variosu parameters, and decimate when necessary, decimation tries to erase points that are
non-respresntative of the local areas they reside in as well as averaging the tangental vectors of the neighbours. So its a bit
of an Art more than a science.

  Good luck,
Art

1302

Video P*r*o*b*i*n*g / Re: Photos of webcam scanner. ( no laughing.. :) )

« on: April 10, 2008, 10:20:58 PM »

Hi:

 >> Im working in LazyTurn, and once I get toolpaths, Ill redo the data aquisition plugin for probing, needs work depending on camera I think, but heres some explanations.. ( Your photos dont look too bad, do they mesh alright if you select a ball mesh in MachCloud?

 The first camera I tried was a nice Logitech.  I think it cost me around $60.  With the default settings that the fancy schmancy driver software uses (i.e. auto exposure/ auto white balance, color correction, anti flicker, etc) I could not get a square wave to save my life.  After monkey-ing around with manual settings for about an hour I finally managed to get something that resembled a square wave.

 >>The square wave is seen becuase the Y of the line changes in the image, so if you turn off the lights in the room it can really help, flourecents give a infra red out as well, so they can mess up line discrimination. Just a suggestion..

Scans with this Logitech camera didn’t yield any encouraging results.  Until, I changed the “Ignore less than parameter” to -100 (as Art had suggested to ‘aolshove’ in the alpha release of point generator thread).  While I was able to FINALLY get data into the computer and view it in Mach Cloud-(WHOOOOO HOOOOO!!!))  , I had points on the Zero plane.  I agree with Art, those points are annoying.

>> Thats what ignore does, it ignore any Y less than the set amount. so play with that to get rid of the zero plane points..

So, I got another myself another Webcam-  Cheap P.O.S. $15 version (I think they had it at Big Lots-LOL).  Without any fancy settings software, the camera worked great right out of the box.  Scans were the same with the lights on or off.  This was a HUGE step forward.  So, I would have to say that the type of camera and driver software that you use seems to play a large (if not huge) role in the acquisition of data. It would be cool if the Logitech (or any camera) settings utility actually had some psychedelic color/intensity/saturations effects filter knobs that would allow you to tweak up the laser/square wave gain but alas, this is but a dream (for now).

>> Definitiely, my camera isnt great, but its not bad at doign organic 3d shapes like my hand..

So, with the camera out of the way (for a moment), there are those mysterious  settings on the Plug-in.  Just what does all of that stuff do?  Cube size is obvious. My cube is 1.5” so I set it for 1.50.   But what is Cam FOV.  OK, I know it stands for Field of view but, expressed in what units? Inches/Degrees.  Is the field horizontal, vertical or diagonal?  I have tried messing around with it (FOV), to get it to change the height value to equal the distance from the camera to the TOP of the cube.  Is that right?  Or, is  it to the bottom of the cube otherwise known as the table surface/zero point?   Hmmmmm,   which is it?

>>FOV is the degrees of the FOV in the X dimension, typically abotu 45 - 70 degrees depending on the camera.. The software tries to figure it out , but thats where work is needed, false readings are common in calibration. Keep calibration till the angle is about 50-70 degrees for a logitec. Yes, you can futz till the heght is rigth as well. I need to figure a more clever way to do all that.

On the subject of alignment and such.  I was wondering where the best place for my Z axis/camera angle?  High Z hovering directly above my subject matter or Lower and angled  45 Deg downward.  Another Hmmmmm?  Have not yet been able to experiment with this yet as my current spring clamp/electrical tape camera set up doesn’t give a lot of pan/tilt flexibility in this area  .  I’m gonna work on that and get back to ya.  Perhaps others can offer some insight here?

>>My Z is about 2-3" above the item, straigth down, laser about 45 degrees into the bottom 1/4 of the feild..

I set my feed rate @ 75 (IPM).  Default comes up @ 500.  That seemed kind of high to me but then I though maybe that’s how Art had it set for his machine running in MM.  After a few scans I started playing with feed rate and it doesn’t seem to change things that much- either how fast the machine scans- nor the quality of the scans.  It does effect how fast the machine Re-Zeros itself after the scan is finished though.  Not really sure about the feed rate will help/hurt.  Does a slower feed rate yield better results (i.e. smoother scans) or just take more time?  Yet another Hmmmmm. 

>> Feedrate wont matter much since its doing lots of small moves, never has time to get to full speed .. so ignore feedrate, I use metric, so 500 is default.

I stepped the Y at .039 (Inches).  Default I think = 1 (again probably 1mm-but that’s on that ‘crazy’ other measurement system so I use 'our' systems convenient   # .04”.  Starting out small I’ve been scanning a 4” to 10” area.  The scans usually take about 15-30 seconds to complete.  At first I scanned only in Y then I tried scanning in both Y AND X but when I open the clouds in MachCloud, I get a message that says, “Use left/right arrows to register the striped cloud, press enter when done”.  I press the arrow keys but nothing happens, the mouse doesn’t seem to do anything- so, what’s a guy to do?  I press ‘Enter’ (sometimes multiple times and more points keep appearing.  The cloud is there but I’m left wondering if I missed something or is that feature just not enabled yet? 

>> Yup, again metric, use about .05 for a stepover..  Just scan in Y for now, the X scan get striped, so MAchCloud uses a manual registration, again I need to clean that up..unless you know it, striping is not intuitive..

I have tried scanning a bunch of different things and had varied results.  Some things that I thought looked great during the scan, don’t generate a good point cloud at all.  Others that I thought wouldn’t scan well, actually produce some good results.  It’s kinda weird and I wish I could figure it all out  .

>> It IS hit and miss somewhat , its all tuned to my camera, so hard to duplicate what I do.. I use a logictec fusion.

I played around with the “Ignore” setting a little but I don’t really understand what it is that I am ignoring.  Is this telling the computer if something is lower than this value then it won’t record it?  For example, if I had a 2” cube on my table and said Ignore 1.0 then would I get a scan of just the top 1” of my cube?  I’m not clear on this one- anyone have the answer on how this works?

>>Zero Pkane is the ignore, it means ignore any lines less than.. ********* mm's.. ( again, your shoudl be set to inches equivalent..)

Here are 3 scans that I did only in the Y axis.  Sorry it's nothing too exciting, I'll try to find some more interesting subject matter.   I would rate the scans “OK” but I think that they are no where near the resolution that Art was able to get on the scans of his hands. 

>>Not bad really, getting close, they shouild mesh..

1. The trpzd woodblock was 1st.  Not too shabby but the points are all really close to each other almost forming a line.  When I try to mesh/surface the surface is wavy and smooth and flat like the original block.  Is this the scan or something you tweak in Rhino?

>> Use Ball mesh with a ball about 5mm or inch equivalent..

2. Since the Vacuum nozzle was black, I thought might not scan well.  I was happily surprised to bring up the point cloud.  It seems to lack Z depth, as if something got cutoff/pruned down there.  Maybe this is another setting/camera angle/height thing?  Any advice on this anyone?

>> Thats not too bad, but its only seeing from on top, so side data is missing, its what the X scan is supposed to fill in..

 I suppose spending a little time using the touch probe method of digitizing would be enlightening and also provide some basis of speed/quality comparison.  The MACH3/laser webcam digitizing concept is so promising!  I hope that its development matures rapidly as I think MANY would benefit from integrating this process.

>>Wont be real quick , its all R&D, but Ill see what I can do.

I feel I am close but it seems my lack of experience is keeping me from crossing that frontier into the land of clear scans.  Arrrg-I love this plugin! I hate this plugin! Maybe some of  the dudes who have some more experience, knowledge or even luck would chime it would help me to lose the “hate” part.   I have more questions and comments but I think this is a good place to stop for now. 

>>Me too, I hate it and love it. Hopefully, it will show more promise in future..

Thanks
Art

1303

Video P*r*o*b*i*n*g / Re: Photos of webcam scanner. ( no laughing.. :) )

« on: April 10, 2008, 01:57:41 PM »

Hi:
 Are you scanning in the Y dimension only? Send me a point cloud if you like , Ill see if I can see what the trouble may be..

Art

1304

Mach SDK plugin questions and answers. / Re: Plugin development in VS2005, VS2008

« on: April 09, 2008, 09:38:15 PM »

Hi Ed:

  Good Idea. I did similarly with some other code I used. The plugin loader
is pretty simple. It sends a pointer to the functions back to MAch3 so it
calls the DoButton() and the GetLED() etc... as pointers to the plugins
functions. All other calles are simply the pointers your playing with. Since
I didnt know what var's woudl be used, using Com' etc was really hard to
arrange without making every function exported.. Your right, I hadnt planned
on making it open, it just hit me one day so I di dit, unfortunately, this
makes it a bad usage of pointers. Hard to switch over though. Brian will
send you any code you think will help, but I suspect the loader isnt much
good to you, it only exports pointers from the plugin, which should be all
OK in any language, its just the classes that are an issue, and various
plugins use variosu variables , so its really hard to set them all to com.
Id suggest just finding the difference in size and using a subtraction from
the var names maybe.. gotta think about that one.. The original problem was
dll's wernt designed to callback to the originating code base, only to have
routines to BE called..
  Thanks for the investigations..


Thanks,
Art

1305

Mach SDK plugin questions and answers. / Re: Plugin development in VS2005, VS2008

« on: April 09, 2008, 02:53:44 PM »

Ed:

  Interesting. I did know that it was an issue with the trajectory class's pointers getting corrupted, but I didnt know that CWnd changed size between versions. I wonder if theres a constant to tell windows a version of class. Good Job though, those changes would make things much easier for aspiring plugin authors. Let me know how you make out and Ill update the release resources to reflect it. Ill try to get some tie this week to see if there is soem arcane compiler switch that will take care of it. OR if perhaps an easier solution exists. Seems to be it should be safe to take a class pointer using a CWnd class, seems an awful big hole to leave between versions..

Thanks
Art

1306

LazyTurn / Re: LazyTurn

« on: March 22, 2008, 02:31:59 PM »

>>Mach should manage the G41 and G42 by itself in my modest opinion

  The problem with g41 and g42 is they dont take the holder into account, nor the tool geometry really, they refer only
to the actual tip radius compensation, which makes them good on some things, not so good on others. Collision detection
is not possibel with g41/g42, since nothing is known about the tool other than the tip radius.. its more powerfull to create the
path precompensated, which si why most use precompensated code, not G41/G42 when they have a choice. End cut angles, side cut angles, back angles.. none of them make a difference in G41/G42 so the cut is actually much harder to do using comp in a controller , than from cam.
  The proof of that is simple, G41/G42 has been in turn for 3 years, no reports of problems, even though I know they exist. This means
noone uses them even if available. Everyone I have done support for uses percompensated code.. its always easier to do so..
( Personally, I find G41/G42 near useless in a controller for lathes..)

Art

1307

LazyTurn / Re: LazyTurn

« on: March 18, 2008, 11:16:20 PM »

Yes, thats what Id use rigth and left for. The only important thing is it matches the actual tools boundries as close as you can manage.

( G41/G42 are implemented, but very hard to use and untested for a long time. LazyTrun will put out precompensated code.

Art

1308

LazyTurn / Re: LazyTurn

« on: March 16, 2008, 07:30:04 PM »

Rich:


  Exactly.., in your case youd make a small button tip with a holder of very small width. It isnt that the end tool has to look
exactly like the actual tool, it just has to reflect the actual cutting limitations you need, since you know that inherantly
the tool you use will not colide with the end balls, youd just use the afore mentioned tool description, and all shoudl be well.

  On the other hand, if you were roughing, you may want to describe a wider holder so that the ball ends will collide, and thus wont be cut
during the roughing operation, thus leaving the ball ends to be cut by your small holder tool description. You get the idea fine I think..

 ( All this is in theory of course, you just never know where we'll actually end up after all things are considered.

Art

1309

LazyTurn / Re: LazyTurn

« on: March 16, 2008, 04:45:56 PM »

Hi.

One important thing that must not be left behind is the tool radius compensation. Nobody wants a cam software that will not reproduce the final object different from the drawing.
For what I read, I think that lazyturn will "translate" a dxf file or another input file into a gcode program. It will select tools, manage toolpaths etc, and mach3 will process the gcode file generated by it.


Now a question:

The toolpath generated by the lazyturn will be the exact piece and mach3 will manage the tool radius compensation

OR

Lazyturn will create a toolpath that already includes the tooltip radius compensation ?


My suggestion is that mach3 compensates the tool radius. In this way a user is free to use its cam software. For example I made a program to do just that, translate a dxf into gcode, but the final object differs because of the radius of the tools. I must draw it already thinking on the tool and make some calculations that is difficult and easy to make mistakes.
Also, I think that this feature already should be functional in mach before more work is pointed to a "turn utility", since it is a "must" on a turn controller.

Thanks for reading.

  There already is G41/G42 in Mach3Turn, but unless one understand all the tip directions, tip radius, X and Z offsets very well, ( and is brave) I woudlnt use it. Its a tough thing to use. SO LazyTurn will  take the tool into account and generate code for that tool, with radius precompensated so the output code will produce exaclty what it says it will. It IS rare though for many turning jobs
to produce exactly what the drawing shows, due to tool geometry not matching the drawing even if compensated. LazyTurn will show, after each tools path is generated, what parts did NOT cut, its up tothe user then to select another tool that is capable of cutting the remaining stock, or accept the differences from original drawing. At least thats how I envision it working at this point.. Im leading up to a simulation/generation facility that shows what didnt cut very prominantly and allows you to recut just that portion with a new tool.

  To clarify what Im aiming for, as its different from LazyCams process, in LazyTurn, I want a user to import a profile, set a stock radius, as it does now. Then select from a group of buttons what to do. If you select facing, then you select a tool, tip direction will automatically be assumed by the fact your facing. The toolpath will be generated and youll be shown it cut that face. In bright red, will be areas that differ fromt he loaded profile to the cut result. You can then accept that or just select another facing operation, and a new tool, and cut from that last cut just removing material that the new tool can cut. ( though in facing I dunno why you would..).  You are then left with a profile, and stock showing the face now mathes the profile loaded. Youd then select roughing, select a tool, and hit generate, the tool will show you the cut, and the resultant profile will show in red what doesnt match your profile. You then could , for example, select finish, select a tool, and youll see the finsih tool remove all it can, again leaving behind a red profile of what doesnt match. Youll continue this type of sequencing until your stock looks like your profile. There may be differences you wish to recut with variosu tools, or you may decide thats good enough. The Gocde will then be generated from all the created paths as one Gcode file. This will include Facing, Boring, roughing and finishing passes in the order that best makes sense to you.

   In other words, on load you are shown a stock, and a profile. Its your job through selecting various operations and tools, to whittle the stock down to your profile. Each time you cut a stage, the stock will turn opaque, show the tool whittle it down, then the stock will turn semi transparent again, in bright red, so you can see where the stock is larger than the profile. The stock will never be smaller than the profile. . Its my hope that this is more intuitive than before, and will allow for more sequences to be done until your stock/profile match is as good as it gets with your tools.

Art

1310

LazyTurn / Re: LazyTurn

« on: March 16, 2008, 03:57:47 PM »

Graham:

  Ahh, I think I see what you mean. My thought on the grooving tool is to still set a tip radius, this sets the internal 0 point of the tip, so the X and Z offsets are implied by that. In your example tool
then, if one specifed a tip radius appropriately, then the X and Z offset are implicit. So if you zeroed to the back edge of the tool, with no X,Z offsets setup , your actually changing the
side tolerances as well as the tip end. Though in your case that may not suffice. Ill look at that for you when I do a grooving tool sequence. We may have to have a dual offset, but as it stands ,( at least in my head) I think a general tool tip radius even for a groving tool should create the right offsets. ( Though zeroing may require a knowledge about if your zeroing to the left or right of the tool. ). But that I
expect may be true of any tool since tip radial center is the important setting for the tool. Not a problem in generation of code as direction is considered in terms of the cut, but zeroing will be the important
function in that regard. But Im not sure I see a differecne between the grovving tool or any other tip in that regard.

  I may be missing soemthing though, but Im sure it will become clear when you tell me I *********ed up on the generation for the actual code. , thats the point at which we'll find that problem. But for
actual code generation, motion direction will account for the path, zeroing I suspect is the problem in terms of setup.. On the other hand, if we just leave offsets to zero, and use a tip radius as the complete
setup in MAch3 for that tool. ( taking wear registers into account) , then really no offset should be necessary... hmm, gotta think about that one for MDI usage, my though was to eliminate the G41/G42 requirment by using tip center as the Gcode output default, thus making the output precompensated as to offsets other than tip radius.. Im still comig to grips with that internally though, so I guess
all I can promise is Ill fix that up as I screw it up.

 I can say that I had considered the zeroing to be semi automatic, since the code will assume the tip radius , then in MAch3, no offsets or G41/G42 shoudl have to be selected, when you zero to the X front of the stock, the zero will be assumed to be off by the tip radius in the X dimension, the Z dimension will have to be zeroed to the outside when a program is to be started, the asumption being that you have zeroed to the face and are now offset by tip radius in the Z ++ direction. The programs Gcode from LazyTurn will assume that when generating the code. Though perhaps a switch will be necessary to dictate to the Gcode poster that the true zero should be considered to be left or right. ( though the tool setup should be able to tell that in left or right sided tools.). Center tools woudl be the unknown
element. Youll notice a checkbox for "Use tip center", that will descriminate between using Mach3's offset registers with compensation, or just to create the code as precompensated using the tip radius as that compensation from tip center.

  As I say though, Im sure Ill see a dozen conflicts in there as I start to do all that..  so we'll discuss that in depth as I start to generate code. Ill be sure to structure it to give us some flexability there as I
know that my sad lack of turning experience will screw up my head in offset terms a bit as I go. We'll see how automatic I can make that.. but since Im generating the code, I shoudl be able to make automatic assumptions based on the direction of travel that a cut will do as you swap a tool on a zeroed system and continue the job using the original zero point from another tool.. So in the end, for myself
anyway, Id liek to get away from using offsets all together, and just use tip radius as the effective factor.

 By the way, there was a bug in the original release that made button tools not work, no tip was shown, that last download though shoudl show a button tip as a typical button tool, ( just a round disk with tip center at center of the button..

Art