[Request] Add bgcode (Binary G-code) support

[NewsGuyTor]

Is your feature request related to a problem? Please describe.

PrusaSlicer 2.7.0 will introduce a new upgraded version of gcode, which is compressed in binary.

Read more about it here
https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.7.0-alpha1

Describe the solution you'd like

Binary G-code should be implemented by the time the final PrusaSlicer 2.7 is released, in order to insure compatibility with the improved format.

Describe alternatives you've considered

No response

Additional context

No response

[jneilliii]

It seems to me that the only thing OctoPrint could do here is accept the file format and convert it to regular gcode on upload because I assume there is no way to send binary data over serial connection, which expects plain text? If that is the case, then seems more appropriate as a plugin that implements preprocessor and extension_tree hooks.

[jedashford]

Default export is now bgcode for all of us using 2.7.0, which will be rolled out soon to all users. This means by default, anyone that uses prusa slicer, just wont work out of the box with octoprint and will require custom presets :(

[jneilliii]

That's not how the release notes read.

Exporting binary G-code can be enabled in Print Settings->Output options->Export as binary G-code. An option to convert ASCII G-code to binary (or the opposite) has been added into File menu.

Maybe it's defaulting it for those 3 specific models?

[RobeeeJay]

I think it defaults to gcode, but the extension is bgcode which Octoprint doesn't accept. To fix this remove the b from the "Output filename format" field in "Output options" under the "Print settings" tab

[AJErazzor]

I think it defaults to gcode, but the extension is bgcode which Octoprint doesn't accept. To fix this remove the b from the "Output filename format" field in "Output options" under the "Print settings" tab

Does this still send as bgcode by just removing the b?

Would be great to get support for this I have found all my profiles are bgcode by default too (granted only for Mini that can support it, not the MK3s)

[RobeeeJay]

No, this is literally just the filename. Binary gcode is only enabled if "Export as binary G-code" is enabled below it. The alpha has a bug where it has the output filename extension as bgcode even when it's not turned on, so you have to manually remove it otherwise Octoprint refuses the upload.

[AJErazzor]

Ok I do t see this - I turn off the option it changes the output file name correctly On 1 Nov 2023, at 7:31 pm, RobeeeJay ***@***.***> wrote: No, this is literally just the filename. Binary gcode is only enabled if "Export as binary G-code" is enabled below it. The alpha has a bug where it has the output filename extension as bgcode even when it's not turned on, so you have to manually remove it otherwise Octoprint refuses the upload. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[RobeeeJay]

You are right, it does toggle correctly, but the default presets with binary unchecked are wrong.

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/prusaslicer-new-bgcode-format-binary-g-code/55105/2

[foosel]

Just to quote myself from the above thread:

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.

[thijstriemstra]

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.

Well said. I'm not happy with this decision either, it sounds like a hack they made in order to make their (older) printers relevant again.

[AJErazzor]

I would have thought anything to reduce time is a good thing I have a wifi based pi running octo that takes a good while to get from slicer to octoprint - if this was a smaller file it’s a win.  I don’t think octoprint necessarily needs to do anything but receive the file and then decompress and send as normal g ode.  Prusa have done something on their NEW and RELEVANT printers that starts streaming the geode without needing the whole file - I think that’s pretty cool and gets the plastic on the sheet quickerOn 21 Nov 2023, at 2:04 am, Thijs Triemstra ***@***.***> wrote: 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. Well said. I'm not happy with this decision either, it sounds like a hack they made in order to make their (older) printers relevant again. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[foosel]

I have a wifi based pi running octo that takes a good while to get from slicer to octoprint

That sounds rather like network issues tbh. And uploading bgcode wouldn't make things faster here either as your (big) gcode file would then first have to be reverted to a usable gcode, which at least on a Pi I'll expect will take longer than what the reduction of size saves on time on regular network throughput.

Or, to give an example, imagine having to first pull down your tent before you can build it up again 10m away, instead of being able to just carry it over built up as it is. Because that's pretty much what's going to have to happen here - your slicer first converts your big gcode file into something smaller, then you send it over the network, then OctoPrint has to unpack it again (on a less powerful machine) before it can actually stream it to your printer and print it.

As I said, no advantage to be seen here. There would be an advantage if the file could be printed as is, but as I said, that is not the case here, at least not currently.

[AJErazzor]

That sounds rather like network issues tbh. And uploading bgcode wouldn't make things faster here either as your (big) gcode file would then first have to be reverted to a usable gcode, which at least on a Pi I'll expect will take longer than what the reduction of size saves on time on regular network throughput.

No its just a low powered old pi and the only one on wifi - other ethernet based ones or on more high performing devices its all good. Thanks for taking the time to look at this - I am only a weekend coder and havent the slightest idea on how much time it would take to decompress a file format. Your expertise on these sorts of things I would be certain you know of the limitations and performance hits.

Perhaps it could be something an add on contributor might take on one day. Its no big deal to untick the box to not send as bgcode, I just thought it might be quicker, or help those with buddy board based prusas who dont know about this option which is ticked by default and the error message the slicer gives you is not really something that a novice would know where to go to untick.

Thanks again for all you do.

[jneilliii]

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.

https://github.com/jneilliii/OctoPrint-BGCode

[RobeeeJay]

Oh cool, I was looking at doing this as well but am also trying to work out a sensible way to download and build the binary, so got a little blocked. I really wish the PrusaSlicer team had this as a Printer setting and not a Print setting, because it means having to create a custom print profile for every single layer height/quality combo for every single nozzle, or manually toggle it all the time. :(

[foosel]

I also wish they had published their python bindings on pypi, because for now this is going to be a packaging nightmare :/

[jneilliii]

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.

https://github.com/jneilliii/OctoPrint-BGCode/archive/refs/heads/master.zip

[RobeeeJay]

Only tried an upload but it works for me! Thank you for solving this. I know it's a problem that Prusa made all on their own, which is annoying since they have added some very nice improvements to Octoprint support in the very same firmware, but it's great to not have to make so many presets now :)

[jneilliii]

So far there are potential issues with the following plugins based on issue reports to the bgcode plugin. I want to reiterate what I'm telling users over there, I can't control what's in the file after it's been converted, all the content of the file is being extracted using their tool so if there is information missing from it people need to take that up with PrusaResearch and not me.

• SlicerEstimator: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 1: invalid start byte
• DisplayLayerProgress: Layer indicator not found in file

[thijstriemstra]

they have added some very nice improvements to Octoprint support in the very same firmware

like what? any examples/link to documentation?

[jneilliii]

Only thing I've seen is release notes.

https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag/v5.1.0

[AJErazzor]

I saw a link to the specification here - it sure if you have already found this?
https://github.com/prusa3d/libbgcode/blob/main/doc/specifications.md

[thijstriemstra]

Only thing I've seen is release notes.

yea and only thing it mentions is "we’re introducing improved Octoprint support" which seems minimal or they would've been more elaborate about these changes. sigh prusa.

[RobeeeJay]

Previously, once Octoprint connected to my Mini, I got the Octoprint logo and locked out of most of the features. I would have to disconnect to do things like change filament, and then go to the Octoprint UI to reconnect. Now it stays permanently connected and only shows the Octoprint logo and lockout when it's actually printing, once it's been idle for a little while it reverts back to the normal menu (until you trigger another print). Seems a small thing but it's a major usability improvement.

[thijstriemstra]

ah, i noticed this as well, quite nice. if you upgrade a octoprint plugin, reboot octoprint and start a print, prusa mini doesn't notice though and it'll crash with a bluescreen. oh well.

[rtyr]

https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.7.1

[ChrisHeerschap]

Thanks to @jneilliii for the bgcode plugin which got us through these harrowing days with a minimum of fuss, but man I'm glad they walked that one back.

If it wasn't clear, 2.7.1 removes binary gcode from print settings, moves it to the printer settings (which makes way more sense) and defaults it to off. 🥳 🎉

[RobeeeJay]

Yeah we really appreciate the stop gap plugin! I'm so glad Prusa realised this should sit in printer settings and moved it there so quickly.

[thijstriemstra]

If it wasn't clear, 2.7.1 removes binary gcode from print settings, moves it to the printer settings (which makes way more sense) and defaults it to off