Stepper Chunks

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


Contents

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 use segments larger than 1 step may use a segment lookup 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 }

};

Protocol

The chunk transmission protocol is a simple data transfer process that returns with an index if the data was stored successfully. Sequential chunks can be gathered into a full range of data that can be triggered for execution.

To transfer a chunk, the device must be sent ['!'][CHUNK_SIZE bytes][checksum]. The device should be able to store this data very quickly and directly.

During data transfer, the device will either respond with "!ok <idx>", "!fail" or "!busy". If the device is busy, the transfer must be attempted again.

To trigger the stepper chunks, the device must be sent [TRIGGER_CODE?][idx][n] where idx is the first chunk index, and n specifies the number of sequential chunks to trigger.

External Links

Current proposal for Marlin

Step Daemon