Re: SLO-SYN 12.7 Amp motors

Matt Shaver wrote:

> 3. Darrell also said, "I think the main thing in using these drivers is
> getting the timing correct in EMC." This is something I have yet to be able
> to do, and is a problem that Fred has been working on for some time now.
> Without going into all the details the problem is that there is a some jitter
> in the step output of the EMC. Generating the step pulses stresses the real
> time part of the software considerably and much work has been going on to
> reduce the jitter.

This is a real problem, and not easy to solve with a scheduler that either
emits or doesn't emit a step pulse on a fixed interval. Let's build an example.
Let's say you need to output 999 steps/sec to achieve the desired feed rate
on that axis. let's say that you have the processor interrupted 1000 times
per second to see whether to output a pulse then. Well, you output a
pulse every interval for 500 intervals, skip one interval, and then output
499 more pulses at every interval. That omitted step makes the whole
mechanism clunk. This specific example might not make the steppers
lose sync, but there are an infinite number of other combinations like this,
and some of them most certainly will excite resonances that can cause
lost steps.

The only way I know to solve this problem is to have hardware that can
schedule step pulses at some rate determined by a divide-by-N counter,
or to have a mechanism that can schedule pulses at an arbitrary time
between compute intervals. The latter mechanism sounds kind of
interesting, and could probably be implemented with a programmable
gate-array chip. It would be a sort of 'time interpolator'.

> Ahha (and Flashcut also) uses external hardware to avoid
> this problem, but I am reluctant to adopt that approach until the "software
> only" approach has been thoroughly developed. Other "software only" solutions
> avoid the problem by going into a tight loop in their program with only
> periodic polling of the keyboard buffer to check user input. This option is
> unavailable to us as we want to multiprocess and keep Xwindows alive, etc.
> The problem comes in when you try to control a large machine (like a
> Bridgeport) at high speeds (60+ inches/minute or thereabouts). Since the
> torque output of stepper motors drops with speed, any timing variations in
> the step rate (at high speed) can lead into resonance problems or stalling.
> Fred has made some good progress lately and will have an improved version of
> the stepper software available in the near future.

Well, that's just another argument for servos!

Jon