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.
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.
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, potentially up to thousands of times per second. Non-directional formats rely on the direction being provided in the g-code, with the binary data only providing 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, planning, and g-code subsystems.
Compression can also be employed in the page formats, allowing for a higher step rate that could normally not be achieved with "per-bit" step accuracy. The segment-based compression still provides total geometric accuracy, but breaks the motion into tiny line segments for the sake of page size. The compressed segment value is then used in a lookup table to produce the actual steps the device will take over the segment timeframe. This type of compression shares some characteristics with the traditional method of using Bresenham lines with step-rate modulation for acceleration, in that motion accuracy may be sacrificed for slow axis movements. The main difference is that the compressed direct stepping data offers a hard guarantee on how much accuracy is sacrificed, while maintaining a constantly high step-rate that can satisfy both fast and slow axis motion at the same time.
Using an 8 step compression at 60k steps/s will result in motion accuracy tolerance within 133 μs. Compressed formats also work well when micro-stepping is used as they generally fit the compressed segments within 8 steps or less, as the physical accuracy is generally at the whim of the micro-stepping characteristics.
The naming scheme for the formats follow this general pattern: SP_<axes>_<compression ratio><'D' if directional>_<number of segments>
Here is an example of 3 general purpose formats provided with Marlin that share the same total page size:
- SP_4x4D_128 - 4 axes, 4x compression, direction is binary encoded, 128 segments, 1024 steps and 256 bytes per page.
- SP_4x2_256 - 4 axes, 2x compression, no binary direction, 256 segments, 1024 steps and 256 bytes per page.
- SP_4x1_512 - 4 axes, no compression, no binary direction, 512 segments, 512 steps and 256 bytes per page.
SP_4x4D_128 is a good format for movements which may be very quick and change direction often (multiple times per 1024 steps). SP_4x2_256 is a good general purpose format that seems optimal for 3d printing. SP_4x1_512 may not be able to reach the same step rate as the other two, but provides absolute motion accuracy.
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.
- 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
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):
XXXXYYYY ZZZZEEEE XXXXYYYY ZZZZEEEE