Byte-compiled GCode

Unsure as to whether this already exists, but felt it might be worthwhile implementing if it doesn't. While GCode is simple, the files get pretty large pretty quickly for more complex prints. Given it's structure, it'd be pretty easy to create a binary version of it, with some structure like

+====================+================================+====================+=====================+===================================+
|       Byte 1       |             Byte 2             |       Byte 3       |       Byte 4        | Byte 5 - (Instruction Length - 4) |
+====================+================================+====================+=====================+===================================+
| Instruction Length | Instruction Category (M, G, T) | Instruction Number | Number of Arguments | Arguments                         |
+--------------------+--------------------------------+--------------------+---------------------+-----------------------------------+

The only issue I could see is instructions with multiple options for arguments, like the controlled arc move (G2-3) instructions.
I figured it might be advantageous to printers using less powerful hardware, perhaps removing the textual GCode parsing for bytecode parsing, which should be less expensive.
I'd be eager to work with others to figure out a specification and create an implementation for it

see Packed_Binary_GCode --> [reprap.org]

the problem is no one seems to want to implement it.

Edited 1 time(s). Last edit at 02/12/2019 07:51PM by Dust.

Yeah, I've since looked at that. That makes things easier if there are already specifications for it. I think if I created a reference implementation and documentation it'd be easier to implement, just a drop in library or something. And some command line tools for working with the files

I have an implementation written in both C and python, but I've been too lazy to release in any meaningful way. It works great, you can get approximately 50% reduction in size, but ultimately you're left with around 12 bytes per G1 instruction, which is unavoidable. You can look at a version of it here.

There are several hurdles, most of which can be overcome, but kind of limit usability.
1. No slicer produces binary-encoded g-code, so you'd have to write a plugin for each (I have a cura one already)
2. You need a method for sending binary data to the firmware, typical firmwares like Marlin stream files to SD as ASCII (I think Marlin added a more efficient streaming command recently, I also implemented a janky version myself)
3. You need support for each g-code streaming application to support the new binary g-code upload format. I've implemented plugins for pronterface and octoprint which work for me, but it's less than ideal because the whole UI freezes while it runs my upload script. IMO this is the hardest piece as not all applications support plugins and you need low-level access to the serial driver

Edited 1 time(s). Last edit at 02/17/2019 11:38AM by kulivontot.

Why bother, it would make much more sense to lift 3D printer electronics out of the stone age. 8-bit processor based electronics is long obsolete, because far more powerful and cheaper 32-bit processors have been available for many years, with proper flow-controlled USB interfaces and network support - instead of the appalling USB-to-serial interface with no device-level flow control used by atmega2560-based boards. Modern low-cost 32-bit processors have no problem with the existing GCode format.

Edited 2 time(s). Last edit at 02/17/2019 06:30PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Because high speed data transmission even over usb and SDIO is non-trivial to achieve. Click "upload to sd" on octoprint and you'll find that some printers will take 10's of minutes to upload a 3 megabyte file.

Quote
kulivontot
Because high speed data transmission even over usb and SDIO is non-trivial to achieve. Click "upload to sd" on octoprint and you'll find that some printers will take 10's of minutes to upload a 3 megahbyte file.

That's down to the lack of a native USB port on 8-bit controllers, the use of SPI to interface to the SD card instead of SDIO on all 8-bit and many 32-bit controllers, and insufficient RAM in the processor to write large enough blocks to the SD card. Low cost 32-bit processors such as the ATSAM4S8C (used in the Duet Maestro) have native USB, SDIO, DMA and 128kb RAM. Microchip Direct charges $3.52 for the ATSAM4S8C and $9.16 for the Atmega2560, 1000-off prices. Using 8-bit main processors to control 3D was crazy back in 2015, let alone 2019.

FWIW uploading a 3Mb file to the SD card on the Duet Maestro takes 4 seconds. This is over Ethernet, because I don't use USB - why would I when the network connection provides so much more control.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

#DC42
The individual prices of the board components is irreverent to the user.

duets Maestro board 115USD (ish)
single board ramps comptable $21.00USD

until you can compete with the board price your talking threw your arse when it comes to pricing.

and as always please stop hijacking threads to push your products!

Quote
Dust
#DC42
The individual prices of the board components is irreverent to the user.

duets Maestro board 115USD (ish)
single board ramps comptable $21.00USD

until you can compete with the board price your talking threw your arse when it comes to pricing.

and as always please stop hijacking threads to push your products!

And why can't he promote his products ? Besides, he is right and his products are good.
I am using RRF on a cheap 32bits MKS SBASE 1.3 (48USD) plus TFT32 that in fact is not really necessary.
I learned about RRF from this "hijacking" and sdavi LPC port

For a near professional machine, the Duet ranks far above any 8bits and the price difference is minimal as one has to consider the whole machine cost.

Plenty of people here promote their "designs" many lame if not pure garbage. Yes they are free, just that you waste your time and money if you venture making them. So what is preferable ?

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

So back to the original discussion, this is a relevant problem for every other board not running RRF connected over USB. I too am experienced and annoyed by poorly implemented hardware, but there's more than one solution to the problem here. I'm new here, so I don't know the rules, if discussion of boards/ firmwares other than Duet/RRF is forbidden we can take this to the Marlin forum.

Anyway, to code the instructions in binary form was the way to do when computer had limited resources and has been done.
And it is true it makes more sense, for the CPU !
Besides, imagine a punched tape with Gcode.

Now, it is not necessary anymore, and Gcode has the advantages of being easy to read by a human and eventually modify, correct. Try that in binary !
Good luck to come up with a standard that all will agree and implement. Not an amateur job.

Eventually ZIP the Gcode files

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
Eventually ZIP the Gcode files

I implemented this too, but the extraction time was about 10x the transfer time on a 48mhz cortex M0