Re: EMC Following Error
Posted by
bsptrades
on 2002-09-15 00:41:02 UTC
--- In CAD_CAM_EDM_DRO@y..., "cadcamcenter" <cadcamcenter@y...> wrote:
relieve the motion processor from spending much of its time twiddling
bits on a slow legacy parallel port. The parallel port control is
nice because it is simple and available. Many of the folks here seem
to be advanced beyond the simple and looking for impossible base
resolutions and near light speed at the same time. Even with great
improvements in processing the basic system design for the parallel
port access will limit bit rates.
This is where a velocity based system such as a true servo system
works best like Mr. Elsons for EMC or several of the other hardware
assisted solutions.
http://www.pico-systems.com/univstep.html
Take 2 examples with a .2 lead screw geared 2:1 and running a G201
for example. This setup will take 20,000 micro steps per inch. To get
180 Inch per minute rapids you would need to output 60,000 pulses per
second.
For step pule generation this means for every second I have to
service 60,000 interrupts. Each one I stop, respond to the interrupt,
save context, flush the pipeline, branch to service, set the bits,
wait for pulse width, clear the bits etc.. And during all this I
expect to read a 100,000-line file, service the mouse and display
full color graphics and compute constant velocity contours with
offsets and tool compensation.
In a velocity based system I set the loop interval to reasonable
value say 1000 per second. Now rather than waste all my effort
bouncing bits I just output target velocity profiles. When moving at
mach 1 I don't really need the several micron following error and
when it slows down for detail work the update interval is fast enough
to create precision. In this system the overhead is far less and more
consistent.
You can do a rate multiplier but to work well the system has to have
a good phase lock and knowledge of what max rate is. Then you take
the ratty pulse train, buffer it, smooth it back out while filling in
the intermediate holes. What you have done is take a velocity
profile, integrate it into steps, send it out as pulses,
differentiate it back to velocity, and send a new pulse train out
with smaller steps.
The real solution is to adapt the driver software for closed loop
velocity control vs. open loop position for the demanding
applications. This is what Jon has done with his board.
To buffer the step pulses the minimum I would guess is to slow the
step software to a reliable maximum where it outputs good steady
pulse trains. The buffer then reads step pulses and delays them until
the next pulse or a time out to compute the intended rate. To
preserve the sync you should clock all the streams the same as well
as buffer the direction lines. Or simply buy a G210..
The problem being any rate multiplier will lower your resolution. If
you need both the fine resolution and speed you can't get there so
you are back to the velocity approach. If you just need the micro
step smoothness then a multiplying driver is the answer.
Brian
BSP
> --- In CAD_CAM_EDM_DRO@y..., "William Scalione" <wscalione@n...>incorporated
>
> Is it possible to have an external step-multiplier? Say,
> into something similar to a parallel port buffer, etc.? Then onecan
> use for either G201 or G320, or any other drives?The key to achieving higher speeds and smooth operation is to
>
> Peter
relieve the motion processor from spending much of its time twiddling
bits on a slow legacy parallel port. The parallel port control is
nice because it is simple and available. Many of the folks here seem
to be advanced beyond the simple and looking for impossible base
resolutions and near light speed at the same time. Even with great
improvements in processing the basic system design for the parallel
port access will limit bit rates.
This is where a velocity based system such as a true servo system
works best like Mr. Elsons for EMC or several of the other hardware
assisted solutions.
http://www.pico-systems.com/univstep.html
Take 2 examples with a .2 lead screw geared 2:1 and running a G201
for example. This setup will take 20,000 micro steps per inch. To get
180 Inch per minute rapids you would need to output 60,000 pulses per
second.
For step pule generation this means for every second I have to
service 60,000 interrupts. Each one I stop, respond to the interrupt,
save context, flush the pipeline, branch to service, set the bits,
wait for pulse width, clear the bits etc.. And during all this I
expect to read a 100,000-line file, service the mouse and display
full color graphics and compute constant velocity contours with
offsets and tool compensation.
In a velocity based system I set the loop interval to reasonable
value say 1000 per second. Now rather than waste all my effort
bouncing bits I just output target velocity profiles. When moving at
mach 1 I don't really need the several micron following error and
when it slows down for detail work the update interval is fast enough
to create precision. In this system the overhead is far less and more
consistent.
You can do a rate multiplier but to work well the system has to have
a good phase lock and knowledge of what max rate is. Then you take
the ratty pulse train, buffer it, smooth it back out while filling in
the intermediate holes. What you have done is take a velocity
profile, integrate it into steps, send it out as pulses,
differentiate it back to velocity, and send a new pulse train out
with smaller steps.
The real solution is to adapt the driver software for closed loop
velocity control vs. open loop position for the demanding
applications. This is what Jon has done with his board.
To buffer the step pulses the minimum I would guess is to slow the
step software to a reliable maximum where it outputs good steady
pulse trains. The buffer then reads step pulses and delays them until
the next pulse or a time out to compute the intended rate. To
preserve the sync you should clock all the streams the same as well
as buffer the direction lines. Or simply buy a G210..
The problem being any rate multiplier will lower your resolution. If
you need both the fine resolution and speed you can't get there so
you are back to the velocity approach. If you just need the micro
step smoothness then a multiplying driver is the answer.
Brian
BSP
Discussion Thread
David Micklethwaite
2002-09-14 16:49:45 UTC
EMC Following Error
William Scalione
2002-09-14 17:44:19 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
Tim Goldstein
2002-09-14 19:34:33 UTC
RE: [CAD_CAM_EDM_DRO] EMC Following Error
cadcamcenter
2002-09-14 20:21:52 UTC
Re: EMC Following Error
cadcamcenter
2002-09-14 20:32:09 UTC
Re: EMC Following Error
Jon Elson
2002-09-14 22:28:02 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
bsptrades
2002-09-15 00:41:02 UTC
Re: EMC Following Error
David Micklethwaite
2002-09-15 04:16:26 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
David Micklethwaite
2002-09-15 04:16:29 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
David Micklethwaite
2002-09-15 04:16:31 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC Following Error
wanliker@a...
2002-09-15 09:13:04 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
William Scalione
2002-09-15 13:25:48 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
Ray Henry
2002-09-15 17:05:18 UTC
Re: RE: EMC Following Error
Jon Elson
2002-09-15 22:08:56 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error
David Micklethwaite
2002-09-16 04:17:01 UTC
Re: [CAD_CAM_EDM_DRO] EMC Following Error