Re: Black Box Goals

Hi,

Sorry for this long post. Alan e-mailed me a question on how the
thing is supposed to work. The answer seemed general enough to be of
use to others interested in this subject. Here goes:

You ask an interesting question which I will try to answer. The
answer has two parts: (1) A novel method of generating pulse
frequencies and (2) digitally integration (calculus) of velocity with
time to calculate position. I will handle each seperately, then bring
them together at the end. I will also describe breifly in (3) how a
practical axis move is made.

(1) You are probably familiar with the usual method of generating
frequencies; load a value into a counter, have it count down to zero,
output a pulse, re-load the value an so on. As an example, say you
load a down-counter (decimal) with "9" and clock it at 1 MHz. The
counter would count down 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, output a pulse
on the "0" count, re-load with "9", count down again, and so on. The
frequency would be 10 counts at 1 uS each for a frequency of 100 kHz.

The next higher frequency at your disposal would be to load the
counter with "8". This would result in a period of 9 uS (8, 7, 6, 5,
4, 3, 2, 1, 0) and a frequency of 111 kHz. Your frequency would have
increased 11 kHz.

Now let's look at the top end. The highest frequency would be to load
the counter with "0". You would then have a frequency of 1 MHz (an
output pulse for every clock cycle). Now how about the next highest
frequency, which would be to load the counter with a "1". The
sequence now would be 1, 0, 1,0 etc. The period of course be 2 uS for
a frequency of 500 kHz. That is a frequency change of 500 kHz.

So what is wrong with this picture? Well, at the low end, an
increment of period broduces an 11 kHz change while at the high end
the same increment of change results in a 500 kHz change! This is non-
linear (1/X) and terrible!


Now let's try it a different way.

Let's take an adder (single digit, decimal). It has two inputs (A)
and (B) , and two outputs, (A+B) and carry. Take the output (A+B) to
the input of a clocked storage element that stores the (A+B) output
on every clock pulse (still 1 uS). The output of the storage element
feeds back to the adder's (B) input. Now let's see what happens on
each clock pulse if the (A) input is "1" and the storage element
initially outs a "0". NC will mean "no carry" while the output pulse
will occur on "carry", or C.

1+0=1 NC, 1+1=2 NC, ... 8+1=9 NC, 9+1=0 and a C, 1+0=1 NC, 1+1=2 NC,
etc.

There will be a "C" every tenth clock pulse for a frequency of 100
kHz.

Now make the value on (A) equal to 2 (next highest frequency) and see
what happens.

2+0=2 NC, 2+2=4 NC, 4+2=6 NC, 6+2=8 NC, 8+2=0 C, 0+2=2 NC, etc.

There will be a "carry" every 5 clock cycles for a frequency of 200
kHz, or a 100 kHz change. Now how about what happens at the high
frequency end? The biggest number we have available is "9", so let's
use it.

9+0=9 NC, 9+9=8 C, .... 9+2=1 C, 9+1=0 C, 9+0=9 NC, 9+9=8 C, etc.

What we have now is 9 output pulses for every clock cycles for a
frequency of 9/10 of 1 MHz, or 900 kHz.

If we replace (A) with "8", we will get 8 "carrys" for every 10 clock
cycles for a frequency of 800 kHz. Well, this is much better; we have
an increment of frequency change produce an equal change (100 kHz) in
frequency. Now the relationship between frequency command ( A input)
and frequency is linear, i.e. the change in frequency per command
increment is independent of frequency range.

There is a little problem though. Look at th 900 kHz example above.
There is a 2:1 change in period every 9th ouput pulse, because there
is a "missing " pulse every 10th clock cycle. This is not good.

Here's what can be done about it. We will utilize some natural
advantages at our disposal. The adder/storage circuit is implemented
in hardware, which means rather than using 1 MHz clock mentioned in
the examples, say we use a more practical value of 25MHz. The
hardware can easily handle that (74HC series logic tops out at 80 to
100 MHz).

The maximum pulse rate then would be 25 MHz and would have to be
divided down to a usable value. The pulse period is 40 nS and 80 nS
for the "missing" pulse period before division. If the divider is set
to 1,000 then the the pulse frequency would be 250 kHz with 40 nS of
phase "jitter" (80 nS - 40 nS) contributed by the "missing pulse"
period.

This now is a pretty pure frequency spectrally, having less than 1%
variation in period pulse-to-pulse (40 nS / 4 uS). It would be less
then 0.1% at 25 kHz and so on. This is very good.

Obviously the adder/storage element is not a single decimal digit, it
is actually a 16-bit binary one. This provides 65,536 (2 to the 16th
power) evenly spaced frequencies. The divider is tapped, making the
frequencies suitable for full-step, half-step, 10 microstep and 125
microstep drives.

(2) Motion Control requires moving a known distance at a known speed.
We have a method of generating known speeds (step pulse frequencies)
but how do we know the distance moved?

The obvious method would be to count the step pulses to a "position"
counter. At 25 MHz this would require a hardware counter and a means
for the computer to read its contents. All this is unnecessary if a
different approach is taken.

From integral calculus (or high-school physics) we know that distance
is the first integral of velocity with time. For integration of
velocity with time to be succesful we must know the velocity and the
time perfectly, otherwise even the most miniscule error in either
will produce an unacceptable error in position. This not difficult to
do if we take advantage of a trick.

The 25 MHz timebase generates the step pulses (velocity). We will use
the same timebase to generate time periods as well by dividing it by
a fixed amount.

Let's say we divide the 25 MHz by 25,000. This will result in a 1
millisecond period. Let's also command a 1 kHz step pulse frequency.
From this we can assume the distance taken every 1 millisecond time
will be 1 step (1 millisecond times 1 kHz = 1). All we have to do now
is to sum the velocity to a position register every 1 millisecond
time tick to know our position!

What would happen if the timebase changed? Let's say our 25 MHz
oscillator dropped to 12.5 MHz for some reason. The 1 millisecond
time tick would now strech out to 2 milliseconds and our step pulse
frequency would drop to 500 Hz as a result. The distance moved per
time tick would remain unchanged (2 milliseconds times 500 Hz = 1).
It balances out perfectly.


(3) Let's now see how a practical move might be made. For this we
need some parameters on which to base our move. They are:

ACC Rate of acceleration. It is a fixed value. Let's it is "2"
VEL The commanded velocity. This number changes as things move along.
It is "0" initially.
MAX The target velocity. This may be the feed-rate. It is fixed
value. Let's say it is "10"
DN The distance of the move. This value will change from the
initial value. Make it "120"
UP The distance moved. The initial value is "0". It will change as
things move along.

Here's how it works:

1. Add ACC to VEL
2. Is VEL bigger than MAX ?
3. Make VEL = to MAX if yes to question in step 2
4. Subtract VEL from DN
5. Is VEL = to MAX ?
6. Add VEL to UP if no to question in step 5
7. Is UP bigger than DN ?
8. Go to step 1 if no to question in step 7
9. Subtract ACC from VEL
10. Is VEL zero?
11. Go to step 9 if no to question in step 10
12. Done

Here is what VEL, DN and UP would look like on each time tick.

TIME VEL DN UP

0 0 120 0 Ready to move
1 2 118 2 VEL becomes VEL + ACC, accelerating
2 4 114 6 VEL becomes VEL + ACC, accelerating
3 6 108 12 VEL becomes VEL + ACC, accelerating
4 8 100 20 VEL becomes VEL + ACC, accelerating
5 10 90 30 VEL = MAX, end acceleration
6 10 80 30 Run at a constant speed (MAX)
7 10 70 30 Run at a constant speed (MAX)
8 10 60 30 Run at a constant speed (MAX)
9 10 50 30 Run at a constant speed (MAX)
10 10 40 30 Run at a constant speed (MAX)
11 10 30 30 Run at a constant speed (MAX)
12 10 20 30 UP > DN, begin deceleration
13 8 12 30 VEL becomes VEL - ACC, decelerating
14 6 6 30 VEL becomes VEL - ACC, decelerating
15 4 2 30 VEL becomes VEL - ACC, decelerating
16 2 0 30 VEL becomes VEL - ACC, decelerating
17 0 0 30 Done, move finished, axis stopped


The move took 17 time "ticks" to move the required 120 steps. It
accelerated to the programmed velocity of 10, decelerated and came to
a stop at the 120th step pulse.

The algorithm listed above is obviousy more complicated than that.
There are other decisions it has to make for things work out, just
change the value of DN to 123 to see why. These other decisions are
not shown because it would confuse the understanding of the
underlying principal of how a move is made.

If DN, ACC, VEL, etc is treated as a vector, then the output velocity
must be multiplied by SIN and COS for that vector's angle before
they are output to the individual X, Y axies step pulse generator
cards. For linear interpolation moves SIN and COS multipliers are
constant and may be pre-calculated.

If it is a circular interpolation move, then SIN and COS are
variables and must be calculated on every time tick. The algorithm
then generates 1,000 polygon sides per second. This means if you are
moving at 1" per second around a 1" circumfrence (0.159" radius
circle), then the resulting path will be a 1,000 sided polygon. If
the radius were 1.59" and the speed were 0.1" per second, then
the "circle" would have 100,000 sides and so on.

The other thing to note is the algorithm relies on simple add,
subtract and branch instructions that execute very rapidly. A usable
version takes about 400 clock cycles to execute, which takes only 16
uS for a 25 MHz clock rate. From that you can see many axis can be
serviced within a 1,000 uS time tick as an interrupt service routine.

Circular interpolation places the greatest computational burden on
the microprocessor because a SIN and COS pair has to be calculated
on each interrupt cycle. This takes about 2,000 clock cycles, so
let's say the entire algorithm takes 4,000 clock cycles per axies-
pair as a very conservative time estimate. The execution time would
then be 160 uS. Running circular interpolation simultaneously on 6
axies (???) would take 480 uS, which means the interrupt service
would at most occupy 50% of the processor's time. That leaves plenty
of time for the background program to communicate with a PC, massage
data, feed the velocity manager and perhaps even brew a cup of coffee
in its spare time.

Mariss