Stepper Chunks

From RepRap
Revision as of 21:04, 10 July 2017 by Colinrgodsey (talk | contribs) (Formats: describe precision loss of format)
Jump to: navigation, search

Direct stepper chunk support is a feature that allows device firmware to process stepper movement buffers (chunks) directly from a host device. This is done with a binary protocol that allows the host to buffer chunks to the device, and trigger them using the trigger command. This allows the firmware to free up processing cycles that can be used to achieve higher step rates, while allowing more advanced processing to be done on the external device.

The general flow involves the external host software taking on the role of "g-code consumer" and acts as a man-in-the-middle between the g-code source and the target device.


Formats

CH-4x4-128

This is the first proposed general format. It encodes 4 motors each with a 4-bit/8-step segment that produces 4x128 segments, a total chunk size of 256 bytes, spanning 1024 ticks total. This format is ideal for 8-bit processors as it requires very little unpacking and most iterators and indexes can be used as 8-bit values. Each 4-bit segment value is the movement change (in steps) + 7, over 8 ticks. So a segment value of 8 would be a movement of +1 steps over 8 ticks, a value of 10 would be a movement of +3 steps over 8 ticks, etc.

The 8-step segment resolution could suffer from some precision loss on non-linear moves, but only at high speeds that would already suffer precision loss due to jerk. The overall effect is that you have more precision at slower speeds for non-linear moves. At 30k tick/s rate, you would achieve full accuracy at speeds of 3.8k step/s or less on any axis for non-linear moves. For an axis with 80 step/mm, this would be about 50 mm/s. As long as jerk does not exceed this value, it will have no noticeable visual impact.

Bit format (2 bytes per segment):

|----segment----|
XXXXYYYY ZZZZEEEE XXXXYYYY ZZZZEEEE

Segment/Wave Table

Any formats that include segments larger than 1 step generally requires a wave table to produce the actual step sequence for each segment. Other methods can be used, like Bresenham lines, but low-bit chunk formats work just fine with a simple segment sequence lookup table.

Example table for CH-4x4-128:

uint8_t segment_moves[16][8] = {

 { 1, 1, 1, 1, 1, 1, 1, 0 }, //  0 = -7
 { 1, 1, 1, 0, 1, 1, 1, 0 }, //  1 = -6
 { 0, 1, 1, 0, 1, 0, 1, 1 }, //  2 = -5
 { 0, 1, 0, 1, 0, 1, 0, 1 }, //  3 = -4
 { 0, 1, 0, 0, 1, 0, 0, 1 }, //  4 = -3
 { 0, 0, 1, 0, 0, 0, 1, 0 }, //  5 = -2
 { 0, 0, 0, 0, 1, 0, 0, 0 }, //  6 = -1
 { 0, 0, 0, 0, 0, 0, 0, 0 }, //  7 =  0
 { 0, 0, 0, 0, 1, 0, 0, 0 }, //  8 =  1
 { 0, 0, 1, 0, 0, 0, 1, 0 }, //  9 =  2
 { 0, 1, 0, 0, 1, 0, 0, 1 }, // 10 =  3
 { 0, 1, 0, 1, 0, 1, 0, 1 }, // 11 =  4
 { 0, 1, 1, 0, 1, 0, 1, 1 }, // 12 =  5
 { 1, 1, 1, 0, 1, 1, 1, 0 }, // 13 =  6
 { 1, 1, 1, 1, 1, 1, 1, 0 }, // 14 =  7
 { 0 }

};

External Links

Current proposal for Marlin

Step Daemon