Just a quick heads up to all Prusa MINI, MK4 and XL users who are using the latest Prusa Slicer.
The printer settings in the latest Prusa Slicer have been updated and the bgcode file format is now the default export setting - which will probably cause confusion for some users, because OctoPrint doesn't support bgcode.
quick faq:
What is bgcode?
the B in bgcode stands for binary. Regular gcode contains ASCII text (normal readable text), while bgcode contains (mostly) binary data. In addition, the gcode is also compressed, which makes the file size smaller.
Will I miss new features of my printer or Prusa Slicer when I go back to the old format?
not at all. This file format was created because users reported long upload times to PrusaConnect. To solve this issue they decided to create a new file format instead of for example zipping the gcode.
Will OctoPrint support bgcode in the future?
OctoPrint itself - no. We don't see a real benefit from this new format. OctoPrint runs locally and isn't depending on a cloud service so transferring files is a matter of seconds.
Furthermore this is strictly a file format that is supposed to store on the printer and not possible to directly send to the printer. There's simply no transmission protocol defined anywhere. So if OctoPrint were to store this, it would have to be converted back to regular gcode to turn it printable. However, the one and only @jneilliii developed a bgcode support plugin for those of you that want to use bgcode
I have a working proof of concept that will add bgcode support to OctoPrint. You will have to be responsible for getting the binary compiled/built and linked inside OctoPrint's venv until I figure out if it's possible to include it somehow with the plugin install.
So I have been able to fork their libbgcode repo and add it to the requirements of the plugin, so on an OctoPi image it's as simple as installing the plugin and let it build (takes a little while). Copy/Pate this URL into plugin manager > get more > ...from URL and click install.
Thanks to @jneilliii for doing a job that should not need to be done (insert angry words directed at Prusa here).
The lib took nearly 12 minutes to build on my pi4... but it finished, and .bgcode files are now automatically converted to text when sent to Octoprint.
After conversion to text gcode, the file extension is still ".bgcode". Should the plugin change the extension to ".gcode" after conversion?
I also noticed the .bgcode output from PrusaSlicer differs in more ways than just binary encoding. I sliced an object, first output it as text gcode, then output it as binary gcode and converted it to text with their lib. I then compared the content of the two files. The file which was output as binary includes additional standalone comment lines near the top and strips off all appended comments (like those typically added to start/end gcode lines), presumably in a further attempt to reduce file size.
And... Along with output format defaulting to binary, the "object label" default has also been changed. It now defaults to the "Firmware" option, which emits Prusa-specific gcodes to label object start/end instead of the previous "Octoprint" style object labels. I am guessing that will break the current version of the Octoprint "Cancel Object" plugin.
I love my MK4, and really appreciate PrusaSlicer, BUT... I am appalled by Prusa's lack of consideration for backwards compatibility, interoperability, and established standards in this rollout. It could have been done with way less impact to everyone (for example, by placing the binary/text and object_label options in Printer Settings instead of Print Settings).
I didn't feel it necessary to convert the extension, although I did try to. Just doesn't seem that the final path is overwritable using the file preprocessor hook I'm using from OctoPrint's side and doing an actual rename just didn't seem like the additional effort was necessary. Figured better to get the plugin out there for people to be able to use.
The only issue that has been reported is an error from Slicer Estimator plugin and I assume it's some utf-8 formatting problem with the file that's been converted maybe.
That's not True. The Prusa i3 Mk4 with Firmware Version 5.1.0 does receive this file format over network form Prusa Slicer 2.7.0 and it's even possible to start the print right after sending it to the printer.
The Firmware got released on 23rd of october. The Prusa Slicer version 2.7.0 completing this set was released on 23rd of november, so just a day before this article got written.
I'm using Prusa Link, not Prusa Connect, and it still feels slow to upload to the printer. But I'm sure it would be much slower with normal gcode files.
I'm still playing with the thought of connecting the MK4 to an octoprint instance (Prusa allows it, even has a guide for this, just not really detailed....). The features just are a light in the dark, seeing the progress from a far (over discord, slack, teams, OctoEverywhere, etc). But it's just a small part of my overall plans for my (one) printer.
I like the proof of concept of jneilliii, I'm just concerned, that it could take up too much space on the SD-Card of OctoPrint. I think keeping the bgcode and convert it when needed would be better as it allows more saved prints on the SD-Card. But that would be an issue in the far future when you've uploaded several hundreds to thousands to OctoPrint. It's an issues I already saw, as I have several GBs of models lying around. Even had to save the sliced files and clean the SD Card of currently not needed files...
Yes, you could connect an .M2 drive to the new RPi5 (with a pcie adapter), but get your hands on one of those is just a bit hard atm (curses on scalper). But this could help (and add a lot of CPU power to the print server so it even could do several tasks at the same time).
Maybe it was a poor choice of words. It can't be send directly to the printers firmware.
If you know your way around linux you could add a new partition just for the (b)gcodes and use a filesystem that allows file compression.
Even the lowest compression rate of zstd would save you a significant amount of disk space.
let's be clear here. this only effects the SD card that will be in your pi. I personally boot my pi 4 devices off USB thumb drives, so space isn't as much of an issue. You'll also find, since it doesn't appear that you are currently using OctoPrint, that uploading to OctoPrint vs PrusaLink is far superior in speeds. It's the difference between using the processing power/wifi connection of a pi vs a printer motherboard with an esp based wifi connection.
that's what I'm using on the Pi as my USB Thumbs tend to get hot after like 5 minutes of constant use. (Maybe the SanDisk Micro USB-Thumb isn't the best choice for this)
And something noone ever had mentioned: The Prusa doesn't sort files if there are more than 100 models in the same folder (atleast on the Mk3), the Pi shouldn't have a problem with this, but didn't test it.
Sounds like a good idea for purging old models, at least over ssh or automated scripts. I'll take a look on this.
Yes, I'm not using OctoPrint atm, as I had to setup my own image because I wanted to have a screen attached and the available images where headless. Set up the browser to automatically open and open OctoPrint itself - downside of this is, that the update on the most recent OctoPrint doesn't work as it doesn't start up afterwards. So I'm stuck on V1.8.6 as this was the last Version which worked on my setup (didn't check afterwards for any new Update which could work). Also have to take a look onto the Mk4 as there were cases in which OctoPrint didn't work as intended (but as far as I've seen Prusa is working on this issue).
Also I wanted to try the new feature of the Mk4, as it seemed to be a step forward, just the speeds aren't as satisfying as hoped. More on this below:
I'm using on every device in this network ethernet connections. Far more reliable, stable and faster (and don't forget on windows Devices to disconnect WiFi when using the Ethernet-Port, Windows tends to use Wifi even when a faster, more stable Ethernet is available...)
And yes, the speeds of the printer aren't the best (Eth: 250 - 300 kB/s | WiFi: 45 - 100 kB/s)
As a comaparison the speed of the Eth-Port of the RPi 4B of around 1 GB/s (or Wifi with around 100MB/s)...
You're not using OctoPi. That's the main image. In most cases people use another application like OctoDash or OctoScreen to run locally on the pi. Your solution of kiosk mode browser is a viable option as well.
Probably an incompatible version pinned plugin dependency. Don't see any posts from you in the forum seeking help on this though. Alternative would be to create backup, download, reflash whatever image you wanted and then use the octoprint_deploy script to install. Then restore backup on initial setup wizard.
Didn't have an account and did't find time to get my hands on it back then ^^"
But I found some posts, which were about sort of non-compability but they didn't find a solution (as far as I remember). So I decided to hop on the Mk4 Upgrade and test those functions to see if it works out.
PrusaSlicer 2.7.1 was released today. The "binary gcode" choice is no longer in "print settings" -- it has been moved to "printer settings" where it is far easier to manage, AND an override is available in "Preferences, Other" to disable binary gcode entirely. From the release notes:
The option Export as binary G-code was removed from Print Settings. Instead, there is a new option in Printer Settings named Supports binary G-code so it can be set at printer level. There is also a new global switch in Preferences->Other, which controls whether binary G-code will be generated for printers which support it. It is therefore easy to turn the feature on or off without doing any changes in profiles (#11734, #11873).
For those users who never want binary gcode (i.e., you only use Octoprint), the easiest route is the "Preferences, Other" option since it will globally disable binary gcode generation for all printers. One quick change there, and no more binary gcode! For those who sometimes want binary gcode (i.e., sometimes using PrusaLink or PrusaConnect, for example), different printer definitions can be created with/without Bgcode enabled.
The printer-specific setting is now implemented at the logical printer level (the physical printer inherits it). That means it needs to be changed for each logical printer definition you're using (e.g., if you have a MK4 with (2) nozzles sizes and use both Normal and Input Shaper, you need to "save as" (4) new logical printer definitions with Binary Gcode disabled). But this is FAR easier than changing it in all the "print setting" profiles, where it was before.
That would have been better for sure! I think they had some "tunnel vision", and were rushing to deliver binary in order to alleviate some of the painful transfer times via PrusaLink and PrusaConnect. I don't think they fully considered the compatibility issues it would create for those not using "their" infrastructure.
The way they've implemented it in 2.7.1 is good, so I have to credit them for listening to our complaints and reacting fairly quickly with a fix.
However, the one and only @jneilliii developed a bgcode support plugin for those of you that want to use bgcode 
