Good evening!
During the past week, we identified problems in Karmen with the new “so-called Prusa standard” introduced in PrusaSlicer 2.7 - binary Gcodes.
What is binary Gcode, and what does it mean for you? It means that if you want to read your Gcode in any text editor, you can’t, as it’s a binary file. Unless you are quite an advanced programmer, you simply can’t read or change anything, like temperatures or add custom filament changes.
Why were binary Gcodes introduced by PrusaSlicer? In the release notes for PrusaSlicer 2.7, it states:
G-code files are easy to read and interpret, but their downside is that the data is not saved efficiently and the file size is often very large. Compression of the file is problematic because the printers usually run on limited hardware and they may not have enough memory and/or CPU power to decompress it.
Full release notes are here: Release PrusaSlicer 2.7.0-alpha1 · prusa3d/PrusaSlicer · GitHub
From my point of view, the above statement is nonsense, and I’ll try to explain why.
Disprove 1: Reduced file size of Gcode
- We have run some basic tests, and basic ZIP compression is more efficient than just a binary-written file.
- Rhetorical question: Do you have problems with Gcode file size? Do you know a 32GB SD card costs $10 or less? That’s space for thousands of Gcodes in “normal” format.
- When you no longer using SD card and you have printer online with Karmen/Klipper/Octoprint, it’s still not a problem, as it’s automatically compressed with HTTP when being sent over the internet.
Disprove 2: Printers can’t decompress files because of limited hardware (CPU/Memory)
- Nearly every new printer is running something like a “Raspberry” computer or equivalent to it. Decompressing a ZIP file will take less than a second for a 10MB file. These computers are really powerful.
- I can understand it for older printers like MK3, etc., but the binary format is not implemented for these in its firmware.
What are my conclusions?
- Prusa has already grown into a large corporate company, and they seem lost, proposing standards that affect a large community of users with no reason.
- They are trying to innovate, but they don’t know how. Then: “Let’s make a new standard for Gcodes!”
- They have a plan (maybe not aware) to throw obstacles in the way of others.
What may be better solution?
Okay, I can hear you: “You are blaming Prusa” - I’m not (hopefully) like that 
. I just think that, maybe in error, they are trying to optimize on the wrong layer.
You probably know what HTML is. It’s HyperText Markup Language. Yes, HTML is a “language,” the same language as “Gcode” instructions. And what is good about HTML? Everyone can easily read it and modify it. It has the same problems as Gcode; if it’s uncompressed, it’s big. But HTML runs over HTTP, which is a protocol that takes care of automatic compression of HTML when it’s transferred between the server and the internet browser.
It’s still non-binary HTML, as nearly 30 years ago when I was creating my first web pages… there was never a need to make a binary version of HTML. And when there was any try to make something binary on the web, it failed sooner or later, like Macromedia Flash by Adobe. All these binary things were replaced by non-binary implementations.
So what? Why am I writing all this? To be honest, I was pissed off a few days ago with these “binary Gcodes” as I don’t understand their existence at all. This writing is for me some kind of therapy while relaxing with a glass of good red wine. 
Have nice days. 
Best regards,
Martin Bilek