Re: [CAD_CAM_EDM_DRO] Re: Lost Steps, freqmod, pulse generators, etc.

> 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