"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 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. 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. 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 ;-) Regards, John Kasunich ------------------------------------------------------------------------- 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
