OctoPrint has no way of being able to covert these currently, but the upload anything plugin could be installed to allow you to upload files I think. Only upload to SD would make sense though.
As far as I understand from the spec, 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.
A plugin could do this on upload.
Unless firmware out there (and from more than one printer manufacturer) adds support for actually streaming prints in this format to the printer, with a well defined transmission protocol, it won't be possible to directly print these files without prior conversion. And I'm frankly also not sure they even can be uploaded to the printer's SD. This is first and foremost a file format created by a single vendor, AFAIK to solve a transfer speed issue on their AFAIK proprietary wifi solution, and I don't see anything at all it brings to the table for the regular OctoPrint workflow.
Thank you very much for the information and clarification. In my opinion, it does not make sense to put too much work into this for the foreseeable future, as the file format is proprietary and doesn’t bring anything new to the table (except for the smaller file size for transfer).
The MeatPack compression technique does have OctoPrint support. The compression isn't as dramatic as Prusa's bgcode but it can help in some situations.
If streaming of the new bgcode is not possible (or if other plugins want to manipulate the gcode for example), it might be possible to upload the bgcode to octoprint and octoprint streams it as normal gcode to the printer. If the specification is not enough to code it into octoprint, a plugin using the bgcode binary would do the trick i think.
Edit: Yes this message is more or less redundant, I know. I just did not want to past a link without saying something.
PrusaSlicer 2.7.0 and configuration bundle 1.11.5 was released today. All of the Print Settings profiles tied to the MK4 and MK4IS printers now default to binary gcode output! Even when a "physical printer" has been defined as an Octoprint interface, PrusaSlicer profiles still default to binary gcode. (For reasons I cannot comprehend, the binary option is tied to "Print Settings" rather than "Printer Settings" in PrusaSlicer).
As unsuspecting Octoprint users begin upgrading to PrusaSlicer 2.7.0 and config 1.11.5, they will suddenly all be sending proprietary binary gcode to Octoprint. I predict a lot of questions / help requests incoming soon.
well, I attempted to build it just now to no avail. If the build procedure doesn't work out of the box it's going to be difficult to come up with the plugin to handle the conversion (the whole point of me attempting to build in the first place) until it's available as a binary download or available via apt install in raspbian OS. The plan was to support thumbnail extraction and binary to ascii conversion on upload of bgcode. Looking at the specification though, it seems there are going to be various parameters in question (ie thumbnail format has 3 options) so what controls that when generating the file from slicer? Just seems like the "specification" is not well thought out yet.
Initial Proof of Concept up and functional in my dev environment. 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.
Until you figure out how to do the library build automagically, you might need to add some additional instructions to the Prerequisites section so the library (and the Python bindings?) get put in the right place (i.e. where you expect it to be).
Yeah, I'm still not sure the exact process yet and have only been able to do it on windows machine, so want to go through the steps in pi os first before making those instructions. On windows it's been a bit tricky making sure you have visual studio with c++ stuff, cmake, git, etc. I've seen where someone is proposing adding it to debian apt list, which would be a welcome addition. Would be even better if it was available via pypi.
So I have been able to fork their 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.
As mentioned in the other thread on this topic -- I tested this addon and it works great (thanks @jneilliii). It's a good, transparent workaround for Prusa's (bad, in my opinion) rollout of binary gcode. Don't get me wrong, the binary gcode is fine -- but should have been optional and not impact users outside of Prusa's proprietary Link/Connect infrastructure.
That said, I hate that we have to have a plugin to do this redundant "convert it back" process. There is an alternate solution: Setting the PrusaSlicer defaults back to text gcode.
First, a clarification, the problem is not in PrusaSlicer itself. It actually defaults to "text" gcode. Rather, the problem is in the "Prusa Configuration Bundle" that defines print settings for Prusa printers within PrusaSlicer. Prusa has set Binary Gcode as the default for all their printers that now (with latest firmware) support it: MINI, MK4, and XL.
Now, this solution is not something everyone will want to do. It requires editing files Prusa doesn't intend for users to edit. And it will get overwritten each time Prusa releases a new configuration bundle so it will have to be done again and again -- until and unless Prusa eventually allows setting the binary gcode option in "Printer Settings" instead of "Print Settings". (I wrote a script that makes the changes, so I will be able to easily update future configuration bundles).
With those caveats, and for those who would rather make PrusaSlicer keep emitting TEXT gcode (and perhaps Octoprint-style object labels), here's what I did:
Open PrusaSlicer and make a configuration snapshot, so changes can be easily reverted if anything goes wrong.
Locate the Prusa configuration bundle. On Windows, the file is "%appdata%\PrusaSlicer\vendor\PrusaResearch.ini"
Open that file in a plain text editor like Notepad++.
Search for all "gcode_binary = 1" and replace with "gcode_binary = 0"
Search for all ".bgcode" and change to ".gcode"
Search for "gcode_label_objects = firmware" and replace with "gcode_label_objects = octoprint"
Save the file.
That will change all the "Print Settings, Output Options" defaults back to what they were before the latest release: Gcode will default to Text format with a .gcode extension, and object labels will be in Octoprint-style format -- as they were before the release of PrusaSlicer 2.7.0 and Configuration Bundle 1.11.5.