On Monday 29 January 2007 16:23, [EMAIL PROTECTED] wrote:
>"Michael Dubno" <[EMAIL PROTECTED]> wrote:
>> To be honest, I am trying to make an automated pumpkin carving
>> machine. The mechanism would be a custom built rotary stage and a
>> horizontal arm mounted on a vertical post. (Custom built because I
>> don't want pumpkin goo all over my metal mills).
>
>This thread is a good example of a general principle that applies to
>mailing lists:
>
>Rrovide as much information as you can when you ask a question.
>
>Your original question was very general, and you got limited replies.
>The general problem is a very difficult one. But when you posted the
>specifics, replies started popping up, because the specific application
>is more likely to get people thinking about specific solutions.
>
>> Obviously all pumpkins come in different
>> shapes and sizes and they also have ridges. I would like to use
>> existing software to convert images and patterns into g-code. A small
>> program to post process the g-code before it is run would be easy for
>> me to write. The idea of a cutting tool who's depth is controllable
>> being held in place by a spring loaded "follower" or "leader" might
>> work out as well. I suppose the resolution of the pattern might make a
>> difference. I think the way to look at the problem is 2 1/2 axis or 3
>> axis. Treat rotation as x, the vertical axis as y and the cutter as z.
>> Thanks for all of the suggestions, they are quite helpful.
>
>Seems to me that there are two general approaches. One is to map the
>shape of the pumpkin first, before cutting anything, and then
> pre-process the g-code to adapt to the shape. Then you do the cutting,
> using very conventional techniques, but running your processed g-code
> instead of the original g-code.
>
>The other approach is to use the original simple g-code that describes
>the deaign as it would be if the pumpkin was a perfect sphere or
> cylinder of a known size, but modifying the Z axis as you cut, using
> information obtained "on the fly" from some sensor.
>
>Measuring while you cut can save time, since you skip the initial scan,
>however it places more demands on your surface sensor. The sensor needs
>to avoid being tricked by flying pumpkin splut from the cutter, and it
> is also vulnerable to "falling into" previously cut areas. In
> additionm, it won't be able to measure on the cutter axis, it will have
> to be offset from the cutter centerline (or maybe even surround the
> cutter).
>
>Pre-scanning the pumpkin shape solves many of those problems, at the
>expense of extra time. In theory, you could use a touch sensor and
>EMC's probing functions, but the "touch, back off, move, touch,
>repeat" process would be very slow. A sensor that actually measures
>distance would be much better. You could make something with a spring
>loaded arm and a potentiometer, or you could use an optical distance
>sensor like this one ($12.50, 4-30cm):
>http://www.acroname.com/robotics/parts/R146-GP2D120.html
This looks very neat at first glance John, but one specification of
interest seems to be missing entirely.
What is the beam divergence over that range, since its near infrared at
850nm, most of us can't see it. I wonder if its output is strong enough
that we could visualize it with one of those IR detector cards the tv
service techs use to verify that an IR tv remote is actually outputting a
signal?
What I'm asking is how, out in the shop, would you confirm that the
detection beam is actually co-located with the axis of the tool.
>At first, I was thinking in terms of doing the scan as an X/Y grid, and
>using the Z measurements to build a "digital pumpkin" model. Then you
>would use that model to generate the final g-code. But that is more
>complicated than neccessary. You only need to measure where you are
>going to cut, so the scan should follow the same X/Y coordinates as the
>final cutting pass, with a Z value that keeps you from hitting the
>pumpkin.
This I think would need to have this sensor mounted in place of the bit
and facing straight down in order to remove the parallax errors of a side
mounted sensor. Here is where the tv tech handy little pocket card might
come in handy, by hand rotating the spindle to verify it's properly
aligned with the bit axis. If the orange spot moves, adjust it till it
doesn't.
>Once you are thinking in terms of following the desired X/Y path and
>recording Z, then you really don't need to generate the modified
>g-code at all. Just record the commanded X and Y coordinates at the
>same time as the measured Z coordinate, and play them back later to
>do the actual cutting.
>
>Conveniently, we already have HAL components that can do the recording
>and playback, called sampler and streamer respectively.
>
>To elaborate:
>
>During the scan, the HAL configuration would send the X and Y commands
>from EMC to both the motors (stepper or servo, doesn't matter) and to
>a "sampler" block for recording. The Z value from EMC would not go to
>a motor. It would be fed back to EMC to avoid following errors, and
>it would also go to the sampler block. And finally, the distance output
>from the sensor would be sent to the sampler as well. The result would
>be a file containing four numbers per line: commanded X, Y, and Z, and
>the measured Z distance to the pumpkin skin. Each line represents one
>sample, and the sampling rate can be a hundred to a thousand times per
>second.
>
>That file would then be piped through a simple program that adds the
>last two columns together, and outputs a new line containing X, Y, and
>Z values that take into account the shape of the raw pumpkin. The
>program could also do any conditioning of the sensor output - for
>example, I think the output of the Sharp distance sensor that I
>mentioned earlier is nonlinear, or the inverse of distance, or both.
Nothing that couldn't be handled with the equ of a screw error lookup
table, preferably generated from the surface of the pumpkin itself, a
basicly one time exercise. Is there not a command in the gcode to switch
in such a custom tool offset table?
>For the actual cutting phase, the processed file would be fed into a
>HAL streamer component, which would make the samples available on HAL
>pins in real time. From those pins, you would direct the signals to
>the motors. EMC proper wouldn't even be involved in this phase, the
>machine is strictly playing back a pre-planned series of motions.
>
>This particular configuration would NOT resemble a conventional
>machine control, in fact the second phase wouldn't even have a
>GUI. (Well, thats not true - I'd use pyvcp to provide a start
>and stop button at least....) Even the first phase doesn't really
>need a GUI - all you really want to do us load the poor pumpkin,
>hit a button and stand back. Jeff's jdi.py ("just do it") script
>would be a good "GUI" for that stage
>(see http://sourceforge.net/mailarchive/message.php?msg_id=37810808),
>and the entire process could be done with a bash script:
>
>1) set up the initial (sampler) EMC+HAL config
>2) use jdi to run the desired g-code and record the path
>3) invoke the program that reads the original path
> and makes the new one
>4) set up the second (streamer) HAL config
>5) pipe the modified path into the streamer
>
>If you are interested in this approach I'd be glad to go into
>more detail, either on list or off. I really enjoy the idea of
>using HAL for unconventional things. (Sometimes to the annoyance
>of more EMC centered members of the community, so maybe off list
>would be better ;-)
No John, I find this is very interesting. After all, this is the 'users'
list, not the devel list.
>Regards,
>
>John Kasunich
With my caveats about parallax considered, this is a very ingenious way to
solve this problem. I didn't get, from the pdf link above, that it was
hugely nonlinear, but I also wasn't reading the fine print around the
edges of the graphs either so that is probably my fault.
>------------------------------------------------------------------------
>- Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys - and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD
>EV _______________________________________________
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
