Designing "The Ultimate MPG"

[Eurisko]

Manual pulse generators are great (compared to jog buttons) but they have their limitations.

You can select only ONE axis at a time.
There are 3 choices (x1 x10 x50) how far each click of the dial will move that axis.
Boring. And not very useful.

I've compiled a short list of features that I'd like to see.

Linear and circular interpolation (using the handwheel !)
Storing / recalling / executing waypoints in 3 dimensional space
Setting multiple "interference zones" or soft limits .
MDI commands

These features could be implemented using just a microcontroller.
No computer would be needed for manual control.

Just thinking out loud. Would be fun to do.

A word of warning:
Manual operation of a CNC machine may pose the risk of serious injury or death.

Use common sense. Wear safety glasses and hearing protection. Avoid loose fitting clothing.
Don't flick aluminum chips off of a cutter with your finger while it's spinning at 10,000 rpm.
Don't stick your face closer to the spindle so you can see what's happening.
Don't spin the handwheel really fast and drive the spindle into your table.
Don't use one hand to hold the workpiece while the other hand is using the handwheel.

I will not be held responsible for any injuries that you sustain after you build your own "Ultimate MPG".

[Al_The_Man]

IMO PWG's are not intended to be used for machining, I have a mill that I can select 3 simultaneous axis moves, but I would never use it for machining.
The MDI mode is probably more useful for this as feed-rate etc cannot be controlled with the normal PWG.
Al.

[kvcummins]

You missed one: The ability to replay a stored set of operations (not just waypoints). My thought being to use EMC2 or whatever to generate a list of step/direction pulses that could be replayed by a controller. With 16Gb CF cards, you could get a fair number of pulses stored (1 byte per clock tick should do it for a 3-axis system). Simply replaying the pulses at a fixed frequency would emulate the pulses generated by the CNC software. I kind of like the idea of taking a CF card to my shop (heh, like I have a shop), plugging it in, and watching chips fly. No need to worry about a computer in a harsh environment, no need to fret over the realtime capabilities of my computer, etc., etc.

Sounds like a fun project, but I think I should get my router built first...

[Eurisko]

Al,
I understand your reservations. But there are times when total manual control is needed. I've had to do some manual touch-ups on fixturing, simply because it was faster than writing a program to do the same thing.

Ken,
I had the same idea, but with an SD card for storage. The problem is that if you simply record a series of pulses from a PC, you will also record the lags and delays caused by task switching, processing, etc.

What we need is a gcode compiler which is able to store the real-time pulse data.

[analogman]

Originally Posted by Eurisko Al, The problem is that if you simply record a series of pulses from a PC, you will also record the lags and delays caused by task switching, processing, etc.

But does it really matter? If it worked for the first real cut, what difference would it make if you recorded and played it back?

[Eurisko]

Originally Posted by analogman But does it really matter? If it worked for the first real cut, what difference would it make if you recorded and played it back?

Pausing in the middle of a cut can cause poor finish, chattering, etc.
If the original pulse train does it, the recorded version will, too.

We need to take the controller delays out of the equation.

[kvcummins]

Originally Posted by Eurisko Pausing in the middle of a cut can cause poor finish, chattering, etc. If the original pulse train does it, the recorded version will, too. We need to take the controller delays out of the equation.

Ummm... Toss the delays out the window. If you can get your software to calculate pulses based on a consistient frequency, you can have the controller play them back at whatever frequency you choose. All you record is the step/direction for each axis for each clock pulse. That's it. Then play them all back at the correct frequency.

A g-code interpreter would be cool, but the products I've seen that do that are thousands, if not tens of thousands of dollars... That's a *lot* of computing power and code interpretation.

[Eurisko]

Time to work out some details.

I've been studying my "Theory and Problems of Computer Graphics" book.

What does that have to do with "The Ultimate MPG", you ask ?

The algorithms used in scan converting lines and circles for raster displays were developed for early computer systems. Systems without floating point co-processors. These algorithms are perfect for an 8 bit microcontroller.

We can treat each step of a stepper motor as a pixel which must be plotted.
There is no floating point math involved. Using only integer addition, subtraction, and bit shifting, we can determine where the next "pixel" will be.

The only caveat is that each axis have the same resolution, or integer multiples of that resolution. Trying to interpolate a circle with a metric 'X' axis and an SAE 'Y' axis would not be a good idea.

Anyway, the math is trivial. Interpolating an arc at 100 ipm or more is doable.

[lerman]

Originally Posted by kvcummins Stuff deleted... A g-code interpreter would be cool, but the products I've seen that do that are thousands, if not tens of thousands of dollars... That's a *lot* of computing power and code interpretation.

EMC is free and will run on a $100 used computer. It has a gcode interpreter, of course.

Ken

[Eurisko]

Originally Posted by lerman EMC is free and will run on a $100 used computer. It has a gcode interpreter, of course. Ken

Okay, free is good. EMC it is!


I've been searching online for a very small (cellphone size) alpha-numeric keypad for data entry that will interface to a microcontroller.

No luck. Any suggestions?