Re: [CAD_CAM_EDM_DRO] DeskNC Windows version

Art Fenerty wrote:

> I must check this out further. 30000 steps/second from linux? Anyone
> know how the linux knows to interrupt itseld 30000 times a
> second. I don't see how its possible. I can't think of any way to
> instruct a motherboard

to tell

> linux to interrupt at that rate, no matter how fast the processor.

Art (& everybody else),

There's been a lot of stuff written about this, and rather than rewrite
it all from scratch, let me excerpt a bunch of stuff from my extensive
archives ;). But first, I think the two most promising ways of
controlling steppers from a PC are:

1. External Hardware!

2.
a. Use channel 0 of the 8254 to generate periodic interrupts as fast
as your PC can stand while still servicing the GUI.

b. Determine how many counts of the Pentium time stamp counter elapse
between interrupts (call this number X).

c. Schedule the next required step pulse in time units based on the
Pentium time stamp counter.

d. Divide the number of time stamp counter units by X, call the
dividend Y and the remainder Z.

e. The interrupt service routine simply decrements Y, and returns if
it's not zero yet. This will be a very short, fast piece of code.

f. When Y=0 the ISR enters a tight loop watching for the time stamp
counter to equal its starting value + (X*Y) + Z at which time it issues
the pulse.

This approach should give results that have the granularity of the TSC
with most of the CPU time left free to service the GUI because the ISR
is doing the course timing.

Art: Is this how your .vxd works?

Below are the excerpts I've found on this topic. Readers with less than
an obsessive interest in PC generated timing can stop reading here,
zealots may continue at will ;)

Matt

***********************************************************************
From ????@???? 1 Jan 1965 00:00:00
From: "Matt Shaver" <mshaver@...>
To: <CAD_CAM_EDM_DRO@onelist.com>
Subject: Re: [CAD_CAM_EDM_DRO] SLO-SYN 12.7 Amp motors
Date: Mon, 10 Jan 2000 20:53:53 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

>> 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

Subject:
Re: Kulago/Mauch DRO ISA quadrature feedback kit
From:
"Matt Shaver" <mshaver@...>
Date:
Mon, 12 Jun 2000 04:01:31 -0400
To:
<emc@...>

> From: Doug Fortune <pentam@...>
> Ok, I know there is a limit to how fast you can step a stepper (in rpm).

It's more a problem of the granularity of the frequency control during
accel/decel. The way the real time system works is that there's an 8254
counter/timer chip inside every PC that can (is) programmed to generate an
interrupt every so often. It's fed by a nearly 1.2MHz clock, and you can
set
it to interrupt the CPU at any multiple of those clock pulses by
programming
a register in the 8254 that counts down to 0, generates an interrupt, and
then self reloads your value into the countdown register again. The
value we
program into that register we call PERIOD and the lower it is, the more
frequent the interrupts. The maximum speed that the PC can process the
interrupts (before another one occurs) is determined by:

1. How fast the computer is.
2. How much the computer has to do for each interrupt.

In our case we have to calculate whether it's time to toggle the step
signal
(among other things). Let's say you're running along with a stepper pulse
stream that looks like this:

111111111100000000001111111111000000000011111111110000000000
i.e. the step signal is high for 10 PERIODS (1), and low for 10 PERIODS
(0).

If you want to speed up a little, your next step would be this:

111111111100000000011111111110000000001111111111000000000
i.e. the step signal is high for 10 PERIODS (1), and low for 9 PERIODS (0).

A little faster still? OK:

111111111000000000111111111000000000111111111000000000
i.e. the step signal is high for 9 PERIODS (1), and low for 9 PERIODS (0).

The first step was from a frequency of 20 PERIODs to 19 PERIODs which is
about a 5.3% increase. The next step from 19 to 18 results in a 5.6%
increase, not bad eh? How about this one:

1110011100111001110011100
i.e. high 3, low 2

to

11001100110011001100
i.e. high 2, low 2

This is an increase in frequency of _25%_! Remember, there are _NO
INTERMEDIATE FREQUENCIES_ that you can achieve! Why does this matter?
Because
as RPMs rise in a stepper motor, available torque falls. At a speed of 5
PERIODs there might not be enough torque to make the 25% leap to 4 PERIODs
and the motor will stall. The same motor/driver combination may be
capable of
much higher speeds, but you don't have sufficiently close grained
control of
the step frequency to accelerate the motor to it's maximum RPM.

I used that spreadsheet and plugged in a PERIOD of 10, and out came the
following frequencies (in Hz):

Delay
Step Freq
0
119,319

1
59,660

2
39,774

3
29,831

4
23,865

5
19,887

6
17,046

7
14,916

8
13,259

9
11,933

10
10,848


To relate this to a real world example, the last stepper machine I built
was
unable the transition reliably from 3617 Hz to 3741 Hz even though I know
that the motors and drives should have worked fine up to around 10000 Hz.

The only ways I know of to get around this problem (other than using
servos!)
are:

1. Forget the interrupt idea and use a software timing loop. Much better
control of the step frequency is possible if moves are mostly planned
out in
advance and a short loop (maybe written in assembly) simply clocks out the
pulses. The major problem is that while a move is happening, nothing else
(like the user interface) can be serviced. You might lengthen your software
loop slightly to check for keypresses that signal "abort move, return to
user
control", but not much else. This (I believe) is the Indexer LPT method.

2. Use special hardware to either increase the granularity of interrupt
scheduling (this may be the Ahha method, I haven't reverse engineered their
stuff), or to implement a programmable frequency generator controlled by
the
PC (the Flashcut method). The only drawbacks to these methods are (at the
present time), cost and having to live with proprietary systems. Of
these two
methods, I like the programmable frequency generator best.

May the torque be with you,

Matt

Subject:
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps, freqmod, pulse generators, etc.
From:
"Matt Shaver" <mshaver@...>
Date:
Tue, 29 Aug 2000 19:49:52 -0400
To:
<CAD_CAM_EDM_DRO@egroups.com>

> From: Alan Marconett KM6VV <KM6VV@...>
> I'd like to know more about the "freqmod module"...

There was quite a discussion of how best to implement a step pulse
generator
back on 1/10/00 in a thread called, "SLO-SYN 12.7 Amp motors". Here are
some
excerpts to bring you up to speed:

<Begin Excerpt>

> 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.

From: "Matt Shaver" <mshaver@...>

> > 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?
<End Excerpt>

Freqmod is the software module that resulted from Idea #2 above. It
improved
things dramatically, but it still isn't good enough. The basic problem is
that we'll never get the pulse timing resolution fine enough using the
timer
tick interrupt in the PC. Programs that do well at pulse generation sit
in a
tight code loop polling one of the counters in the 8254 (or maybe the RTC
chip) to know when it's time to toggle the step signals. The down side to
this is that the user interface is frozen while this is going on. There
might
be time to occasionally peek at the keyboard buffer to check for an "abort"
keypress, but there won't be time for real time position display updates
(these will have to wait until the end of each block).

> hear more about what Jon Elson is doing on the Parallel port

See Jon's post about what he has in mind.

> As I understand, there was a previous project to do an
> interface, with optical isolation, buffering, etc., and that may have
> lead to what Jon is working on now?

The Wonderboard project was aimed at simplifying the wiring for CNCPRO
based
systems. I don't know what's happening with it.

> Any thought to the PCI bus addressing? Has anyone used it with a
> home-brew interface? Looks like PCI bus cards want to put things on new
> addresses (PCI). And my new development system (the one stays stays
> clean in the office) is PCI card only! :>(

PCI bus was considered, and for the reason you mention; there are many PCI
only systems. There are three problems:

1. The user has to open the box. Then there's the problem of getting all
the
wiring out of the PC. This leads to using ribbon cable and a set of
ribbon to
screw terminal translator boards that cost $75/each (you need 2 of these
for
the STG card).

2. Using PCI (in small volumes) usually means using an interface chip from
PLX, which adds about $40 to the board right off the bat, and that's
just to
get ISA out of PCI (more or less).

3. Then there's the biggie; Intel and other PC makers are looking
forward to
a slotless world. Horrifying? Yes! But the same situation exists now with
laptops. Considering the lifespan of laser printers (I've had my LJ4L for
years now), I'm hoping that parallel ports will be around for a while.

Matt

Subject:
Re: Stepper driving
From:
"Matt Shaver" <mshaver@...>
Date:
Wed, 27 Sep 2000 02:26:12 -0400
To:
"dave engvall" <dengvall@...>

> 1. what keeps one from running steppers like servos....ie
> drive them with a V/F off the ± 10 v. using glass encoders
> or encoders on the ball screws?

Nothing. In fact, that's how the freqmod software module in the EMC works,
except that we usually take the feedback from an internal software counter
that stores the sum of the pulses that have been fed out to the stepper
drives. Freqmod sends a command down to the real time process that
generates
the step pulses to output the desired frequency. The real time process
accumulates the pulse count which can be read by freqmod as the
position. We
can also take the feedback from encoders or scales as you proposed.

The one problem is this: In a servo system when an axis is lagging in
position, the servo loop increases the output drive which (in the end)
increases the motor current and (hopefully) the speed. If you apply the
same
idea to the system described above, a lagging axis would be commanded to
increase the step pulse rate. This is all fine and good except that if the
motor has stalled, increasing the step rate won't make it start up again.
What you would really want to do is decelerate all the axes as quickly as
possible to minimize the position errors and try to restart the stalled
axis.
The algorithms for doing this haven't been invented yet (although Tim
Goldstein has some good ideas on this).

> 2. if raw cpu speed is a problem split the tasks

It's not really that, it's that the basic unit of time available to
meter the
step pulse period is about .84uS. This means that all the step pulse
periods
will be some multiple of this time. In fact, the EMC can generate very high
step pulse rates, for example 3 times that time period would yield a pulse
frequency of 397kHz, but 4 times .84uS yields 298kHz, and there's no
frequencies in between. These steps in frequency are too large and you
reach
a point while accelerating where you can't make the next jump in speed and
the motor stalls. Even doubling the CPU speed wouldn't help because the
basic
unit of time is set by the 8254's channel 0 clock rate which is
unchangeable
in a PC.

By the way, this isn't an ignorant question at all, I puzzled over this for
months! For a graphic representation see:

http://users.erols.com/mshaver/stepfreq.xls

Matt



Subject:
Re: [CAD_CAM_EDM_DRO] Re: Re: Black box
From:
"Matt Shaver" <mshaver@...>
Date:
Sat, 14 Oct 2000 01:11:38 -0400
To:
<CAD_CAM_EDM_DRO@egroups.com>

> From: ballendo@...
> P.S. If you're planning to issue steps from a "timebase" of 8192hz, I
> think you're going to follow the same rocky path that EMC(steppers)
> followed. See Matt Shavers recent post(referring to this in earlier
> posts)
>
> If you're going to use one channel of the 8254, or the pentium Rdstc
> (undocumented, HaH!)instruction, you'll still be dealing with base 2
> type granularity problems, but that is what CNCpro and EMC are using
> (8254), so it DOES work.
>
> The rdstc (read time stamp counter) is a Pentium specific(uP
> internal) that increments at the clock frequency! Not all pentiums
> have it accessible, but it may be worth a look.

1. If you read a high speed counter (or sit in a timing loop), you've
stopped
servicing the GUI.

2. If you use a periodic interrupt from the 8254 as your timebase, the
granularity problem limits you to a low step rate,

3. If you try to speed up the periodic interrupts to cure the granularity
problem, you become interrupt bound and you either lock up, or the GUI
becomes unacceptably sluggish.

4. If you try to implement a scheduler that, reprograms the 8254 for each
successive interrupt, the granularity problem is solved, but you'll
discover
that since the 8254 is out on the ISA bus, each reprogramming cycle takes
10uS or more (sometimes a lot more if a DMA operation is going on over the
ISA bus), and then you run into problems with jitter in the step pulse
output.

5. One promising avenue that's not yet been fully investigated is:

http://vincent.oberle.com/apic_timer-index.html

I don't know how hard it would be to use this idea under Windows 9x, but it
might be worth looking at.

Matt



Subject:
Re: Kulago/Mauch DRO ISA quadrature feedback kit
From:
"Matt Shaver" <mshaver@...>
Date:
Mon, 12 Jun 2000 04:01:31 -0400
To:
<emc@...>

> From: Doug Fortune <pentam@...> Ok, I know there is a limit to
> how fast you can step a stepper (in rpm).

It's more a problem of the granularity of the frequency control during
accel/decel. The way the real time system works is that there's an 8254
counter/timer chip inside every PC that can (is) programmed to generate an
interrupt every so often. It's fed by a nearly 1.2MHz clock, and you can
set
it to interrupt the CPU at any multiple of those clock pulses by
programming
a register in the 8254 that counts down to 0, generates an interrupt, and
then self reloads your value into the countdown register again. The
value we
program into that register we call PERIOD and the lower it is, the more
frequent the interrupts. The maximum speed that the PC can process the
interrupts (before another one occurs) is determined by:

1. How fast the computer is.
2. How much the computer has to do for each interrupt.

In our case we have to calculate whether it's time to toggle the step
signal
(among other things). Let's say you're running along with a stepper pulse
stream that looks like this:

111111111100000000001111111111000000000011111111110000000000
i.e. the step signal is high for 10 PERIODS (1), and low for 10 PERIODS
(0).

If you want to speed up a little, your next step would be this:

111111111100000000011111111110000000001111111111000000000
i.e. the step signal is high for 10 PERIODS (1), and low for 9 PERIODS (0).

A little faster still? OK:

111111111000000000111111111000000000111111111000000000
i.e. the step signal is high for 9 PERIODS (1), and low for 9 PERIODS (0).

The first step was from a frequency of 20 PERIODs to 19 PERIODs which is
about a 5.3% increase. The next step from 19 to 18 results in a 5.6%
increase, not bad eh? How about this one:

1110011100111001110011100
i.e. high 3, low 2

to

11001100110011001100
i.e. high 2, low 2

This is an increase in frequency of _25%_! Remember, there are _NO
INTERMEDIATE FREQUENCIES_ that you can achieve! Why does this matter?
Because
as RPMs rise in a stepper motor, available torque falls. At a speed of 5
PERIODs there might not be enough torque to make the 25% leap to 4 PERIODs
and the motor will stall. The same motor/driver combination may be
capable of
much higher speeds, but you don't have sufficiently close grained
control of
the step frequency to accelerate the motor to it's maximum RPM.

I used that spreadsheet and plugged in a PERIOD of 10, and out came the
following frequencies (in Hz):

Delay
Step Freq
0
119,319

1
59,660

2
39,774

3
29,831

4
23,865

5
19,887

6
17,046

7
14,916

8
13,259

9
11,933

10
10,848


To relate this to a real world example, the last stepper machine I built
was
unable the transition reliably from 3617 Hz to 3741 Hz even though I know
that the motors and drives should have worked fine up to around 10000 Hz.

The only ways I know of to get around this problem (other than using
servos!)
are:

1. Forget the interrupt idea and use a software timing loop. Much better
control of the step frequency is possible if moves are mostly planned
out in
advance and a short loop (maybe written in assembly) simply clocks out the
pulses. The major problem is that while a move is happening, nothing else
(like the user interface) can be serviced. You might lengthen your software
loop slightly to check for keypresses that signal "abort move, return to
user
control", but not much else. This (I believe) is the Indexer LPT method.

2. Use special hardware to either increase the granularity of interrupt
scheduling (this may be the Ahha method, I haven't reverse engineered their
stuff), or to implement a programmable frequency generator controlled by
the
PC (the Flashcut method). The only drawbacks to these methods are (at the
present time), cost and having to live with proprietary systems. Of
these two
methods, I like the programmable frequency generator best.

May the torque be with you,

Matt

Subject:
Re: [CAD_CAM_EDM_DRO] Re: Lost Steps, freqmod, pulse generators, etc.
From:
"Matt Shaver" <mshaver@...>
Date:
Tue, 29 Aug 2000 19:49:52 -0400
To:
<CAD_CAM_EDM_DRO@egroups.com>

> From: Alan Marconett KM6VV <KM6VV@...> I'd like to know more
> about the "freqmod module"...

There was quite a discussion of how best to implement a step pulse
generator
back on 1/10/00 in a thread called, "SLO-SYN 12.7 Amp motors". Here are
some
excerpts to bring you up to speed:

<Begin Excerpt>

> 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.

From: "Matt Shaver" <mshaver@...>

>> 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?
<End Excerpt>

Freqmod is the software module that resulted from Idea #2 above. It
improved
things dramatically, but it still isn't good enough. The basic problem is
that we'll never get the pulse timing resolution fine enough using the
timer
tick interrupt in the PC. Programs that do well at pulse generation sit
in a
tight code loop polling one of the counters in the 8254 (or maybe the RTC
chip) to know when it's time to toggle the step signals. The down side to
this is that the user interface is frozen while this is going on. There
might
be time to occasionally peek at the keyboard buffer to check for an "abort"
keypress, but there won't be time for real time position display updates
(these will have to wait until the end of each block).

> hear more about what Jon Elson is doing on the Parallel port

See Jon's post about what he has in mind.

> As I understand, there was a previous project to do an
> interface, with optical isolation, buffering, etc., and that may have
> lead to what Jon is working on now?

The Wonderboard project was aimed at simplifying the wiring for CNCPRO
based
systems. I don't know what's happening with it.

> Any thought to the PCI bus addressing? Has anyone used it with a
> home-brew interface? Looks like PCI bus cards want to put things on new
> addresses (PCI). And my new development system (the one stays stays
> clean in the office) is PCI card only! :>(

PCI bus was considered, and for the reason you mention; there are many PCI
only systems. There are three problems:

1. The user has to open the box. Then there's the problem of getting all
the
wiring out of the PC. This leads to using ribbon cable and a set of
ribbon to
screw terminal translator boards that cost $75/each (you need 2 of these
for
the STG card).

2. Using PCI (in small volumes) usually means using an interface chip from
PLX, which adds about $40 to the board right off the bat, and that's
just to
get ISA out of PCI (more or less).

3. Then there's the biggie; Intel and other PC makers are looking
forward to
a slotless world. Horrifying? Yes! But the same situation exists now with
laptops. Considering the lifespan of laser printers (I've had my LJ4L for
years now), I'm hoping that parallel ports will be around for a while.

Matt

Subject:
Re: Stepper driving
From:
"Matt Shaver" <mshaver@...>
Date:
Wed, 27 Sep 2000 02:26:12 -0400
To:
"dave engvall" <dengvall@...>

> 1. what keeps one from running steppers like servos....ie
> drive them with a V/F off the ± 10 v. using glass encoders
> or encoders on the ball screws?

Nothing. In fact, that's how the freqmod software module in the EMC works,
except that we usually take the feedback from an internal software counter
that stores the sum of the pulses that have been fed out to the stepper
drives. Freqmod sends a command down to the real time process that
generates
the step pulses to output the desired frequency. The real time process
accumulates the pulse count which can be read by freqmod as the
position. We
can also take the feedback from encoders or scales as you proposed.

The one problem is this: In a servo system when an axis is lagging in
position, the servo loop increases the output drive which (in the end)
increases the motor current and (hopefully) the speed. If you apply the
same
idea to the system described above, a lagging axis would be commanded to
increase the step pulse rate. This is all fine and good except that if the
motor has stalled, increasing the step rate won't make it start up again.
What you would really want to do is decelerate all the axes as quickly as
possible to minimize the position errors and try to restart the stalled
axis.
The algorithms for doing this haven't been invented yet (although Tim
Goldstein has some good ideas on this).

> 2. if raw cpu speed is a problem split the tasks

It's not really that, it's that the basic unit of time available to
meter the
step pulse period is about .84uS. This means that all the step pulse
periods
will be some multiple of this time. In fact, the EMC can generate very high
step pulse rates, for example 3 times that time period would yield a pulse
frequency of 397kHz, but 4 times .84uS yields 298kHz, and there's no
frequencies in between. These steps in frequency are too large and you
reach
a point while accelerating where you can't make the next jump in speed and
the motor stalls. Even doubling the CPU speed wouldn't help because the
basic
unit of time is set by the 8254's channel 0 clock rate which is
unchangeable
in a PC.

By the way, this isn't an ignorant question at all, I puzzled over this for
months! For a graphic representation see:

http://users.erols.com/mshaver/stepfreq.xls

Matt



Subject:
Re: [CAD_CAM_EDM_DRO] Re: Re: Black box
From:
"Matt Shaver" <mshaver@...>
Date:
Sat, 14 Oct 2000 01:11:38 -0400
To:
<CAD_CAM_EDM_DRO@egroups.com>

> From: ballendo@...
> P.S. If you're planning to issue steps from a "timebase" of 8192hz, I
> think you're going to follow the same rocky path that EMC(steppers)
> followed. See Matt Shavers recent post(referring to this in earlier
> posts)
>
> If you're going to use one channel of the 8254, or the pentium Rdstc
> (undocumented, HaH!)instruction, you'll still be dealing with base 2
> type granularity problems, but that is what CNCpro and EMC are using
> (8254), so it DOES work.
>
> The rdstc (read time stamp counter) is a Pentium specific(uP
> internal) that increments at the clock frequency! Not all pentiums
> have it accessible, but it may be worth a look.

1. If you read a high speed counter (or sit in a timing loop), you've
stopped
servicing the GUI.

2. If you use a periodic interrupt from the 8254 as your timebase, the
granularity problem limits you to a low step rate,

3. If you try to speed up the periodic interrupts to cure the granularity
problem, you become interrupt bound and you either lock up, or the GUI
becomes unacceptably sluggish.

4. If you try to implement a scheduler that, reprograms the 8254 for each
successive interrupt, the granularity problem is solved, but you'll
discover
that since the 8254 is out on the ISA bus, each reprogramming cycle takes
10uS or more (sometimes a lot more if a DMA operation is going on over the
ISA bus), and then you run into problems with jitter in the step pulse
output.

5. One promising avenue that's not yet been fully investigated is:

http://vincent.oberle.com/apic_timer-index.html

I don't know how hard it would be to use this idea under Windows 9x, but it
might be worth looking at.

Matt

> > 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?
<End Excerpt>

Freqmod is the software module that resulted from Idea #2 above. It
improved
things dramatically, but it still isn't good enough. The basic problem is
that we'll never get the pulse timing resolution fine enough using the
timer
tick interrupt in the PC. Programs that do well at pulse generation sit
in a
tight code loop polling one of the counters in the 8254 (or maybe the RTC
chip) to know when it's time to toggle the step signals. The down side to
this is that the user interface is frozen while this is going on. There
might
be time to occasionally peek at the keyboard buffer to check for an "abort"
keypress, but there won't be time for real time position display updates
(these will have to wait until the end of each block).

> hear more about what Jon Elson is doing on the Parallel port

See Jon's post about what he has in mind.

> As I understand, there was a previous project to do an interface,
> with optical isolation, buffering, etc., and that may have lead to
> what Jon is working on now?

The Wonderboard project was aimed at simplifying the wiring for CNCPRO
based
systems. I don't know what's happening with it.

> Any thought to the PCI bus addressing? Has anyone used it with a

home-brew

> interface? Looks like PCI bus cards want to put things on new

addresses

> (PCI). And my new development system (the one stays stays clean
> in the office) is PCI card only! :>(

PCI bus was considered, and for the reason you mention; there are many PCI
only systems. There are three problems:

1. The user has to open the box. Then there's the problem of getting all
the
wiring out of the PC. This leads to using ribbon cable and a set of
ribbon to
screw terminal translator boards that cost $75/each (you need 2 of these
for
the STG card).

2. Using PCI (in small volumes) usually means using an interface chip from
PLX, which adds about $40 to the board right off the bat, and that's
just to
get ISA out of PCI (more or less).

3. Then there's the biggie; Intel and other PC makers are looking
forward to
a slotless world. Horrifying? Yes! But the same situation exists now with
laptops. Considering the lifespan of laser printers (I've had my LJ4L for
years now), I'm hoping that parallel ports will be around for a while.

Matt

Subject:
Re: Stepper driving
From:
"Matt Shaver" <mshaver@...>
Date:
Wed, 27 Sep 2000 02:26:12 -0400
To:
"dave engvall" <dengvall@...>

> 1. what keeps one from running steppers like servos....ie drive
> them with a V/F off the ± 10 v. using glass encoders or encoders
> on the ball screws?

Nothing. In fact, that's how the freqmod software module in the EMC works,
except that we usually take the feedback from an internal software counter
that stores the sum of the pulses that have been fed out to the stepper
drives. Freqmod sends a command down to the real time process that
generates
the step pulses to output the desired frequency. The real time process
accumulates the pulse count which can be read by freqmod as the
position. We
can also take the feedback from encoders or scales as you proposed.

The one problem is this: In a servo system when an axis is lagging in
position, the servo loop increases the output drive which (in the end)
increases the motor current and (hopefully) the speed. If you apply the
same
idea to the system described above, a lagging axis would be commanded to
increase the step pulse rate. This is all fine and good except that if the
motor has stalled, increasing the step rate won't make it start up again.
What you would really want to do is decelerate all the axes as quickly as
possible to minimize the position errors and try to restart the stalled
axis.
The algorithms for doing this haven't been invented yet (although Tim
Goldstein has some good ideas on this).

> 2. if raw cpu speed is a problem split the tasks

It's not really that, it's that the basic unit of time available to
meter the
step pulse period is about .84uS. This means that all the step pulse
periods
will be some multiple of this time. In fact, the EMC can generate very high
step pulse rates, for example 3 times that time period would yield a pulse
frequency of 397kHz, but 4 times .84uS yields 298kHz, and there's no
frequencies in between. These steps in frequency are too large and you
reach
a point while accelerating where you can't make the next jump in speed and
the motor stalls. Even doubling the CPU speed wouldn't help because the
basic
unit of time is set by the 8254's channel 0 clock rate which is
unchangeable
in a PC.

By the way, this isn't an ignorant question at all, I puzzled over this for
months! For a graphic representation see:

http://users.erols.com/mshaver/stepfreq.xls

Matt



Subject:
Re: [CAD_CAM_EDM_DRO] Re: Re: Black box
From:
"Matt Shaver" <mshaver@...>
Date:
Sat, 14 Oct 2000 01:11:38 -0400
To:
<CAD_CAM_EDM_DRO@egroups.com>

> From: ballendo@... P.S. If you're planning to issue steps
> from a "timebase" of 8192hz, I think you're going to follow the
> same rocky path that EMC(steppers) followed. See Matt Shavers
> recent post(referring to this in earlier posts) If you're going
> to use one channel of the 8254, or the pentium Rdstc (undocumented,
> HaH!)instruction, you'll still be dealing with base 2 type
> granularity problems, but that is what CNCpro and EMC are using (8254),
> so it DOES work. The rdstc (read time stamp counter) is a
> Pentium specific(uP internal) that increments at the clock
> frequency! Not all pentiums have it accessible, but it may be
> worth a look.

1. If you read a high speed counter (or sit in a timing loop), you've
stopped
servicing the GUI.

2. If you use a periodic interrupt from the 8254 as your timebase, the
granularity problem limits you to a low step rate,

3. If you try to speed up the periodic interrupts to cure the granularity
problem, you become interrupt bound and you either lock up, or the GUI
becomes unacceptably sluggish.

4. If you try to implement a scheduler that, reprograms the 8254 for each
successive interrupt, the granularity problem is solved, but you'll
discover
that since the 8254 is out on the ISA bus, each reprogramming cycle takes
10uS or more (sometimes a lot more if a DMA operation is going on over the
ISA bus), and then you run into problems with jitter in the step pulse
output.

5. One promising avenue that's not yet been fully investigated is:

http://vincent.oberle.com/apic_timer-index.html

I don't know how hard it would be to use this idea under Windows 9x, but it
might be worth looking at.

Matt