Re: SLO-SYN 12.7 Amp motors

> > From: Jon Elson [SMTP:jmelson@...]
> > 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.

> From: "Harrison, Doug" <dharrison@...>
> The operative word here is interrupt. Software that relies on the
> PC's interrupt system is doomed to a bumpy ride. The closest thing to true
> timing control (short of a dedicated board with its own clock and profiler)
> would be had by addressing the clock chip directly with an assembler
> routine.

RTlinux uses channel 0 of the 8254 Counter/Timer chip to generate interrupts
at the correct times to ensure that real time tasks are serviced punctually.
The scheduler is the piece of software that controls this operation. The
scheduler has two modes, "one shot", and "pure periodic". In all past
versions of the EMC, Fred has used "one shot" mode to schedule the stepper
control task that generates the step pulses. The downfall of this is that for
every run of the stepper task, the 8354 is reprogrammed. The trouble comes
from the fact that the 8254 is on the ISA bus side of the PC architecture,
and therefore the reprogramming time is lengthy as it's limited by the ISA
bus clock speed. The recent work Fred has been doing has two goals:

1. Switch all real time tasks to "pure periodic" mode and make the slower
task (servo task/trajectory task) periods multiples of the fastest task
(stepper task) period. This will eliminate reprogramming the 8254 after
initialization which will save a great deal of wasted overhead. His initial
tests have shown substantial improvements in both minimum achievable task
period and jitter reduction.

2. Convert the stepper task to "velocity mode", rather than "position mode".
Presently, the servo task runs every few milliseconds (determined by the .ini
file variable) and the stepper task runs at a rate determined by the
combination of MAX_VELOCITY and the lowest value of INPUT_SCALE. The actual
formula is:

2(MAX_VELOCITY x INPUT_SCALE) or for my system, 2(1.25 x 4000)=10kHz

Every time the stepper task runs it writes either a one or a zero to the
output pins on the parallel port, so the highest step rate is 5kHz (for me).
The servo task figures that once it has issued the command to the stepper
task to move to a new position that it has been done by the next time the
servo task runs. The result is exactly the problem that Jon described in his
post (see above). The first version of the stepper task simply output all the
pulses for each axis as soon as possible and then went idle for the remainder
of the servo task period, like this:

_-_-_-_-_-_-_-___________-_-_-_-_-_-_-___________


Later versions incorporated sophisticated algorithms Fred came up with to
distribute the occasional errors in pulse period, but there are still
harmonics in the output step frequency. The next versions will have the servo
task commanding the stepper task to output pulses at a certain _rate_. The
stepper task will keep track of the pulse count and the servo task will be
able to read back the position from the stepper task and control the step
rate. Savvy readers will exclaim at this point, "Hey! That's just how a servo
system works!". This also has the side effect of making stepper systems with
encoder feedback possible with minimal software changes (after all, WHERE the
position feedback comes from doesn't matter much at that point). Fred is
somewhat reluctant to adopt this idea as it brings with it some addition
complication and uncertainty. What is a good value for the P gain in a system
like this? As soon as you move to a system that is partially driven by error
values, the whole weight of PID comes crashing down on you with perhaps
unpredictable results. Nevertheless, it's a worthwhile experiment.

>.I believe this is how Doug Yeager's program works. It works well
> too. I ran three axis' simultaneous last night at 15,000 steps/sec and it
> didn't even flinch. This is with a 486.

Of all the commercial "software only" programs, I've heard the most positive
comments about Yeager Automation. I was wondering: Does the user interface
keep updating and respond to keypresses (like feedrate override requests)
while cutting?

> At least one large CNC control builder has solved the PC profiler
> vs. PC windows interface conflict by going to twin (not parallel)
> processors. One (running under DOS) runs the machine while the other

(under

> W95) provides the cute and fuzzy windows graphical interface we all want.
> When you consider how cheap motherboards are, and how powerful the PC is
> when you leave the video out, this seems like a good approach.

Another advantage of multiprocessor motherboards is that you can use the APIC
timer to generate interrupts with timing granularity equal to the CPU clock
frequency (the 8254 is clocked at approximately 1.8MHz). The big advantage of
this is that the APIC timer is internal to the Pentium CPU, not way out in
the boondocks on the ISA bus. The APIC timer is available if you have a
multiprocessor motherboard even if only one CPU is installed (uniprocessor
boards disable it).

Matt