Direct Stepping

From RepRap
Revision as of 13:42, 8 May 2020 by Colinrgodsey (talk | contribs) (G6 Code)
Jump to: navigation, search
Stop hand.svg.png Warning
Work in progress!

Direct Stepping allows a host device to issue direct stepper movements that are defined in a binary format that is written ahead of time by the host device to a page in the device RAM. 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.

Page Management

The transfer of the binary data from host to device could be done several different ways, and falls under the general category of "page management". The reference implementation (for 8-bit AVR devices) for Marlin includes a binary protocol that can run parallel to the g-code stream over the single USB UART. This allows the host to buffer these pages as fast as possible without having to wait on g-codes that may be stuck pending due to g-code or planning buffers being filled.

Page management can be done several other ways depending on the device, given that the only requirement is that binary data can be reliably buffered in the devices RAM.

Formats

There are several formats that be used for the pages, with the option of creating more as desired for certain devices. The formats are largely broken into two categories: directional and non-directional. Directional formats encode the axes direction in the binary data and can be used to facilitate very quick direction changes, up to hundreds or thousands of changes per second. Non-directional formats rely on the direction being provided in the g-code, with the binary data only provided the steps. Non-directional formats introduce more non-determinism when it comes to performance, as each direction change needs to be done with the g-code, and can place more strain on the page management subsystem.

G6 Code

Once a page is written to the device, it can be triggered using the G6 g-code which references the page index that should be used for that move. Depending on the page format, direction arguments may need to be provided in the G6 code.

Arguments:

I - Page index

S - Number of steps to take. Defaults to max steps for the page format.

R - Step rate per second. Last value is cached for future invocations.

X, Y, Z, E - Direction: 1 for positive, 0 for negative. Last value is cached for future invocations. Not used for directional formats.

Serial Page Manager Protocol

Formats (Old)

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