Hello!
I've been working for some time on my
APrinter firmware, for those who haven't noticed it yet. This post is about the latest addition, which is support for a custom packed binary encoding of g-code. The current situation is:
- The encoding format is
documented.
- There's a
python script which does the packing.
- The APrinter firmware
includes support for printing packed gcode from SD card. The actual decoding code is
here. This class implements the same external interface as GcodeParser so switching from plain text to binary needs little more than to specify "BinaryGcodeParser" in place of "GcodeParser" in the configuration.
It works very smoothly. On gcode produced by Cura I see a good 50% reduction in side. Concerning firmware performance, I measure 15% less time spent in main loop processing with AVR based boards (APrinter also supports RAMPS-FD/Ardiono Due which is an ARM). This measurement was done using
M916/917 which my firmware optionally implements for measuring time spent in main loop handlers.
Please comment on the protocol. I consider it pretty general - it should be able to pack most that reprap firmwares understand. Some details:
- Each packet encodes a command and a list of parameters. The command type is basically a letter and number between 0 and 2047. Each parameter is a letter and its data value, which can be one of the supported data types (uint32, uint64, float, double, void).
- The protocol is able to encode some predefined commands using a shorter form with a 1-byte header, instead of a 3-byte header which includes the full command letter and number. Currently these are G0, G1 and G92.
- Strings are not supported at this time but the protocol can easily be extended. This lack is really due to my firmware not implementing any gcode with string parameters.
- Checksums are not supported. However note that plain gcodes on SD card also don't have checksums.
I've come across bobc's
bobc's packed gcode proposal which tried to acomplish the same goal. However I believe that is not implemented anywhere, and also less space efficient as it stands. For example cosider encpding "G1 E10810.1 F1000", without the error checking.
- Packed Binary GCode: (code_type for G) (byte parameter for 1) (code_type for E) (float parameter) (code_type for F) (float parameter) (eoc) (eol).
This comes out to 1+1+1+4+1+4+1+1=14 bytes.
- APrinter's packed gcode: (1 byte Header using short command encoding) (IndexElem for E) (IndexElem for F) (float parameter) (float parameter)
This comes out to 1+1+1+4+4=11 bytes.
In the future I plan to design a serial protocol based on this packed gcode format, but this is pretty far away I think. For now, it would be nice if this, or something similar, was standardized and implemented in some common firmwares.
Edited 1 time(s). Last edit at 01/05/2014 10:28AM by ambrop7.
