By adding a "reset" function to the parport driver and
modifying the stepgen component, step rates at a given BASE_PERIOD can
be doubled. Update 2: Revision 2 patch is now in CVS TRUNK. Update: Revision 2 patch which mostly improves specification
of pins to reset. Software step generation theory
In emc, all
realtime actions are performed by small snippets of code ("functions")
that are executed frequently (this is called the BASE_PERIOD, and
typical values range from 20 to 50 microseconds) run for a very short
time (e.g., 5 microseconds) and then finish. In the case of step
generation, one function (stepgen.make-pulses) calculates whether its
step output should be TRUE (step) or FALSE (space) during the
next period, and another function (parport.0.write) makes the step or
space signal appear on the parallel port.
When all the functions finish running, then other parts of the
system are free to resume execution. If this was not done, then the
lower-priority realtime tasks (including the trajectory planner) and
userspace tasks (including emc's GUI) would never run.
Under this system, the minimum time for a step is two executions of
stepgen.make-pulses. The first time, stepgen.make-pulses outputs TRUE
and the second time it outputs FALSE.
Detour: Step Waveform Timings
Each stepper driver has different waveform timings. These timings are
characterized by 4 numbers, and two of them are critical to getting the
highest possible step rate. These are called "step length" and "step
space": the time that the step signal must be TRUE and FALSE,
respectively. In the case of the stepper driver I'm using, these times
are 2000ns and 1000ns. Only when the step and space times are small
compared to BASE_PERIOD-jitter can the technique I describe below be
used.
Detour 2: Jitter
Ideally, the functions will start executing at times separated by
exactly BASE_PERIOD. In reality, this deadline will sometimes be missed
(so that the time elapsed from one start to the next is BASE_PERIOD+x).
The next time, the execution could start exactly 2*BASE_PERIOD after the
first. This has the effect of lengthening one interval by x and
shortening another by x. The maximum value of x ever seen
is called the system's jitter.
Stepping with Implicit Clock
New hal_parport parameters
pin-NN-out-reset | TRUE if this pin should be reset
|
---|
reset-time | Minimum time between parport.0.write and parport.0.reset, in ns
|
---|
Instead of indicating a step by TRUE followed by FALSE, indicate a step by TRUE
alone. Now, a step can be issued every BASE_PERIOD. This is actually a very
simple hack in stepgen.c, enabled by setting the stepgen.N.doublefreq
parameter to TRUE.
But the stepper driver hardware is not aware of emc's BASE_PERIOD clock,
or its jitter. So an addition to the parport driver is necessary:
parport.0.reset, along with several related tuning parameters.
parport.0.reset changes the values of certain hardware pins when it
runs, so that when stepgen outputs TRUE on a step pin, the parport's
physical pin is TRUE for a short time and then returns to FALSE, causing
a step to be issued.
The new -out-reset parameters specify each pin that should be reset. If it is
TRUE then the pin is reset to the value given by the corresponding
-invert-mask.
Doing the numbers for the Xylotex stepper driver
In the case of the Xylotex 3-axis stepper driver board, the step pins
are numbers 2, 4 and 6, so these -out-reset parameters will be set to TRUE.
The -out-invert pins remain set to FALSE since the step pulse is active high.
The "minimum STEP pulse width" is 2.0μs, giving reset-time = 2000.
The minimum STEP low time is 1μs. Assuming that the time from
write to reset may be up to 5000 nanoseconds (I'm not
sure how to measure this except with a real scope) and that jitter is
12000 nanoseconds, the minimum BASE_PERIOD is 18000 (5000 + 12000 +
1000), giving a maximum step rate of 55.5kHz. This is a nice increase
over the maximum step rate of 35kHz that is possible with stock
emc and BASE_PERIOD 14000 (12000 + 2000). Or, if the 35kHz step rate
was enough, BASE_PERIOD can be increased to 28000, which will make
the GUI much more responsive.
Files currently attached to this page:
(originally posted on the AXIS blog)