Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Posted by
Jon Elson
on 2000-08-30 13:17:03 UTC
Ron Ginger wrote:
bit, too.)
That is all it needs. The decoupling of the velocity output from the
computer
needs a position counter to be added, but I am already working on that.
parallel
port. There would be 3 addresses per counter x 4 channels, so that
would
come out to be 12 bytes to load. Those could be sent with a burst of
DataStrobes in less than 24 uS using the EPP protocol. I've done
stuff like this for the quad DAC board, it is just a couple of lines of
code
in Turbo Pascal (my language of choice for this sort of stuff).
Of course, I'll be writing a driver (real time module) for EMC under
RT-Linux.
done, and
the biggest hurdle was getting the fast EPP transfer modes to work, by
far.
But, now I know how to do that! The emcoder counter is a pretty complex
device, about 4 pages of VERY tight schematics on one chip. It will
probably need a little tinkering to get it to run just right. Anyway,
the
program for the FPGA is written and compiled, and the board is etched
and drilled.
So, it will take a couple of weeks to get it fully operational. Then, I
have taken
on a project to make the 'wonderboard', a parallel-port opto-isolated
input and
power output board. That will take a couple of weeks. Then, I can
look into the timing generator. Since I'm going to have boards made for
the
encoder counter, I can probably hack one of those to convert it to a
timing generator prototype board. (Actually, it might be possible to
just
put a different program in the chip, leave out the differential
converters
and use the board as is!)
Jon
> Ah well, we dont disagree that a dedicated box of electronics shouldNo, it is essentially only told velocity and direction (and an on/off
> do
> the hard real time stuff. If its a microprocessor or a gate array, the
>
> effect is a special box of hardware.
>
> I assume your box needs to be told how many steps to move, and how
> fast
> to make them. How do you handle the acceleration, let the PC program
> it
> in a series of short moves until it reaches speed?
bit, too.)
That is all it needs. The decoupling of the velocity output from the
computer
needs a position counter to be added, but I am already working on that.
> If your box has a nice clean interfce so I can poke values to it by aWell, you could generally do that. It will use the EPP signals on the
> simple driver, or even the BASIC equivalents of PEEK and POKE, then it
>
> shuold satisfy my needs jsut fine.
parallel
port. There would be 3 addresses per counter x 4 channels, so that
would
come out to be 12 bytes to load. Those could be sent with a burst of
DataStrobes in less than 24 uS using the EPP protocol. I've done
stuff like this for the quad DAC board, it is just a couple of lines of
code
in Turbo Pascal (my language of choice for this sort of stuff).
Of course, I'll be writing a driver (real time module) for EMC under
RT-Linux.
> I am very anxious to hear the specs of your box and know when it willI have to build and test the encoder counter board, next. The DAC is
> be
> real.
done, and
the biggest hurdle was getting the fast EPP transfer modes to work, by
far.
But, now I know how to do that! The emcoder counter is a pretty complex
device, about 4 pages of VERY tight schematics on one chip. It will
probably need a little tinkering to get it to run just right. Anyway,
the
program for the FPGA is written and compiled, and the board is etched
and drilled.
So, it will take a couple of weeks to get it fully operational. Then, I
have taken
on a project to make the 'wonderboard', a parallel-port opto-isolated
input and
power output board. That will take a couple of weeks. Then, I can
look into the timing generator. Since I'm going to have boards made for
the
encoder counter, I can probably hack one of those to convert it to a
timing generator prototype board. (Actually, it might be possible to
just
put a different program in the chip, leave out the differential
converters
and use the board as is!)
Jon
Discussion Thread
wanliker@a...
2000-08-29 13:53:51 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-29 16:02:05 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jeff Barlow
2000-08-29 17:00:15 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
dave engvall
2000-08-29 18:01:28 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
dave engvall
2000-08-29 18:04:35 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jeff Barlow
2000-08-29 18:22:38 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Art Fenerty
2000-08-29 18:22:55 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-29 22:38:06 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-29 22:59:34 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Ron Ginger
2000-08-30 06:45:19 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
dave engvall
2000-08-30 07:22:01 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Tim Goldstein
2000-08-30 08:53:10 UTC
RE: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Alan Marconett KM6VV
2000-08-30 10:49:52 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jeff Barlow
2000-08-30 11:45:52 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-30 12:50:42 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-30 13:17:03 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-30 13:27:27 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Carlos Guillermo
2000-08-30 21:19:10 UTC
RE: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!
Jon Elson
2000-08-31 13:41:53 UTC
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!