Doubling software step rates in emc2 (Update: Now in CVS TRUNK)

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: