.BGCODE support

PCR

As Prusa is switching to a new gcode Format will this be included too for rrf?
https://github.com/prusa3d/libbgcode/blob/main/doc/specifications.md

dc42

@PCR we'll need to look at whether the advantages of .bgcode format outweigh the disadvantages, and whether this format takes off in the industry.

The primary advantage of the .bgcode format is faster upload speeds over slow Ethernet or WiFi connections. The network speeds supported by some of the Prusa printers that support networking are a fraction of the speeds that Duets support (see https://forum.prusa3d.com/forum/english-forum-original-prusa-i3-mk4-hardware-firmware-and-software-help/wifi-vs-ethernet-speeds/), so it's not surprising that Prusa wanted to use a compressed format.

As for the disadvantages:

One of the three compression options is Deflate. This requires around 50kB of RAM, which IMO is a waste of a precious resource on a microcontroller. We definitely wont be able to support this compression option on Duet 2, and likely not on Duet 3 Mini either. The other two compression options don't need as much RAM.
The fast pause functionality supported by Duets requires the input stream to be rewound when resuming after a pause. It's not possible to rewind a compressed file. So if we perform decompression on-the-fly while printing then we would need to keep maybe 50-100 lines of GCode in buffer memory, further increasing the pressure on RAM.
We're planning to introduce a facility to single-step through GCode, which would likewise require a memory buffer.
It's often convenient to open a GCode text file in an editor, to check what tool it selects, what temperatures it sets, etc.

All in all, it looks to me that .bgcode format addresses an issue that is unique to Prusa printers. Nevertheless, an increase in file upload speed would be welcomed by some. One option we may look at is to accept .bgcode format for file uploads, but decompress .bgcode files as they are received and store them on the SD card in regular text format.

PCR

@dc42 thank you for the deep explanation. That really sounds like a prusa issue. The good thing is that the prusa slicer can now output G2/G3 arcs. This already often reduce Filesize drastically.

Save RAM for features and not for compression

dc42

@KenW said in .BGCODE support:

Pretty sure you are aware there were other ways Prussa could have solved it.

The Prusa WiFi module is connected to their board via a serial link. This greatly limits the possible upload speed. Whereas Duets have always used a high speed (26.7MHz or faster) SPI bus between the WiFi module and the MCU on the Duet, ever since the first Duet WiFi was released many years ago.

o_lampe

@PCR said in .BGCODE support:

The good thing is that the prusa slicer can now output G2/G3 arcs.

I'm using ArcWelder for many years now as a postprocessor in PrusaSlicer and it has the effect of reducing SD-card traffic without eating MCU RAM.

I don't know the Prusa Ecosystem well, but bgcode might be ment for "on-the-fly" printing, where the slicer sends data directly to the printer? ( like some laser controllers do)

PCR

@o_lampe
https://forum.duet3d.com/topic/20381/using-arcwelder-with-prusaslicer-g2-g3?_=1697971416627

T3P3Tony

while we get faster speeds with stand alone. For really large print files e.g. multiple day long prints having a faster upload would be nice. The other thing that the Prusa team advertised in that blog post is starting the print before the whole file was received. That made a bigger practical difference in time saved than the gcode compression. but ti has a host of other interesting risks.

gloomyandy

This may be of interest to anyone looking at this in more detail as it allows examination of bgcode files.

https://github.com/ellensp/bgcodewalk/blob/main/README.md

The example given seems to show Heatshrink compression being used along with Meatpack, both of which I think are designed to use a relatively small amount of memory to decode.