Re: ServoToGo supports 1 microSecond granularity

[Jon Elson <jmelson-at-artsci.wustl.edu>]

Doug Fortune wrote:

> In a discussion the previous week, the subject of
> timer granularity came up, and the possible requirement
> for additional timer hardware, whereupon Jon suggested
> a separate timer for each channel (among other improvements).
>
> As you know, ServoToGo lists on their website the interrupt
> timer on their S2G card is programmable  in 25
> microsecond increments .  For the heck of it, I inquired if
> that resolution could be increased, and the answer is YES:
>
> from Don McLane <dmclane-at-ieee.org> ServoToGo Inc
> "Actually, we can support micro-second resolution.  Our timer consists of
> two counters in series.

Well, this really doesn't solve the problem.  There are all sorts of
problems here, having to do with updating the timer too close
to when it expires, did you get there in time, or did it cause a
step pulse before you reset it.  So, it is not easily fixed with
just a counter timer to interrupt the PC, or generate the step
pulses by itself.  What I'm proposing is a completely independent
state machine, which is given a digital code that determines the step
rate for each axis.  Whenever the count expires, a new rate is
picked up for the next cycle.  Here, the only trick is to make the
maximum delay not too long.  The state machine puts out step
pulses completely on its own, and a counter keeps count of
current position.  That way, there are no nasty timing races that
could lose or add steps, which the simple counter-timer chip
would be likely to do.  There may be a way to build this using
some of the later counter-timer chips, but it really has no
application to the STG card.  I don't know why you'd want to
pay $888 for the STG card (and maybe extra for a special
version of it) to not use much of the circuitry.

The final reason, of course, is you need 2, 3 or 4 of these
counter-timers, with all the appropriate circuitry to control
step and direction signals.  The Servo-to-Go card doesn't
have all that.  But, if it was done using interrupts, you wouldn't
get really good results because several channels could
interrupt fairly close in time to each other, and the CPU
would not be able to handle all of them in a timely manner,
so the timing of the later channels would have to be delayed.

Jon