Marlin: [FR] Binary g-code

[pablogventura]

I think that binary gcode would be very useful for buffer problems when printing from a host, to increase commands per second. Anybody working on this?

[thinkyhead]

While no one has implemented yet, for example, Bob Cousins' (@bobc) Packed Binary G-code, there is some work being done on a more pre-processed code that would bypass the planner and perform movements directly in terms of the steppers. The PR for "Direct Stepper Chunks" is #7047.

Theoretically, textual G-code may be just as optimal as binary, as there's some trade-off between the flexibility of the code and the extra processing required to parse it. As in, smaller code doesn't necessarily matter when there's typically low latency. That said, a good way to look at it is, the G-code actually doesn't tell the machine what to do. It tells the parser what to do. So the best binary code would be one that directs the parser to do its actions just like G-code directs the printer to do its actions.

A combination of a compact p-code-like "binary" representation of the machine commands, plus a bypass-kinematics-and-planner approach to the processed input could bring some pretty good performance gains.

And then if you add some SPI-driven TMC5130s…

I've just been experimenting with scripts to convert G-code for more direct SCARA control, with proper scaling of the feedrate, and it does improve performance quite a lot when you don't have to do any kinematic maths or line segmentation in the firmware. A pre-processed G-code for Delta should give even better performance gains.

[mamoit]

I'm running into some transfer speed issues while printing from USB, it is likely to be an Octoprint problem too, but in situations like mine support for a compact gcode format would help.

[thinkyhead]

It should also be pointed out that binary codes must either make all numeric values the same number of bytes, or else they must specify the size of each numeric value. As a result binary formats are not necessarily any more compact than the current flexible ASCII format.

If bandwidth is at a premium, run the G-code through a script that removes all trailing zeros after the decimal point for coordinate values, removes the decimal point altogether if there are only trailing zeros, and removes all spaces in-between G-code parameters. (Marlin doesn't care if there are spaces between parameters or not.)

[AnHardt]

The main problem with Octoprint is not the amount of transferred bytes but the latency in the ping pong ("ok") protocoll.
For examples for a 'binary' protocol and how to speed up by using the RX-buffer size see Repetier.

[cfeckhardt]

I just implemented the spec and didn’t have to use EOC for multi-commands/single line. It works great. Only about 40%+ when it is compressed. I don’t compress the comments. I optimize down floats and ints where possible and inflate them back into their proper data size on expansion. So call me the first to declare it has been implemented. Of course I would have to kill you if I told you where I worked. Hee Hee. Just kidding. System IO is the gating item when expanding it back to human readable form. But I can run a 224 Mbyte file in to the binary format in about 2 minutes. It takes longer to give the human back his readable code, if they insist. But we only need to do that for verification. Just keep it in binary the whole time. It is written in Rust 1.41.

[thinkyhead]

Rust? Why not ADA or SCALA?

All kidding aside, good work! G-code is not usually the bottleneck, but when those many small segments arrive it can get ugly. I look forward to seeing the performance comparison graphs!

[cfeckhardt]

Thanks. But it wasn’t about performance improvements. Intellectual Property mostly. It is also munged digitally to keep mods private. Our performance is done by how we store the representation internally. etc...

[thinkyhead]

Going forward we're favoring pre-buffering G-code onto the SD card and then running it from there. And for that it would also help to compress to a smaller binary format. This approach will make it accessible to old AVR boards too.

[ellensp]

//#define BINARY_FILE_TRANSFER now exsists.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.