RE: [CAD_CAM_EDM_DRO] Re: Windows timing subroutines, how do they work?

Certainly not Bluetooth; you wouldn't like the results of a wireless phone,
wireless network burst, or leaky microwave oven to ruin your day.

On the other; you're putting too much on hardware. Why should it do the
G-Code and interpolation?

What one could postulate is three (3 axes) SX type processors (an obscene
rate of 70 MHz each) that are processing buffered list of rates per NN
milliseconds time interval. Each processor is synchronized to each other
only by an interrupt that reads the next periods rate from another processor
with perhaps a larger internal buffer.

What this all boils down to is the computer sends a list of rates for 1
second (or other such configurable period) to a 4th processor (controller)
which generates the interval timer interrupt to the others, who then read
how many steps they're to perform in the next interval (time-distance).

Encoder reading can be done directly by each processor or offloaded onto an
encoder chip (us-digital LS7166).

All interpretation, interpolation, ramp up, ramp down, and synchronization
are handled by the computer abstractly and NOT in realtime, well almost
realtime a second or so. Any E-Stop or fault detection can be handled
instantly without buffered delay.

What I just described is call "Streaming data mode" that is found on some
industrial indexers/controllers.

A previous poster wanted an open standard pulse generator; well we all know
that will never happen. Can you imagine the time-nuts committee heads
getting there bureaucratic hands on this one!

BTW, who says it has to be someone else's standard?

Jack
-----Original Message-----
From: CAD_CAM_EDM_DRO@yahoogroups.com
[mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of ibewgypsie
Sent: Monday, July 25, 2005 11:20 PM
To: CAD_CAM_EDM_DRO@yahoogroups.com
Subject: [CAD_CAM_EDM_DRO] Re: Windows timing subroutines, how do they work?

What is probably needed? One Timing generator running at a obscene
speed, smaller processors that get a bluetooth into buffer dump for
distance or usb, or? Each processor handles one axis, reading the
encoder to adjust it's own loop-feedback, running pulse ratio per main
engine. All interpolated, All with a error out line back to main
source to err-out. Each axis dedicated to itself. Then here-we-go..
Look ahead software that processes speed changes per gcode line and
pid's it all to that frequency to make desired end of line directional
changes without losing it's interpolation between axis. Ramp up, Ramp
down each line is not a good way to machine, but the only thing I have
saw on my machine.

Will it happen, probably not.