Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    .BGCODE support

    Scheduled Pinned Locked Moved
    Duet Hardware and wiring
    6
    8
    893
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • PCRundefined
      PCR
      last edited by

      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

      dc42undefined 1 Reply Last reply Reply Quote 0
      • dc42undefined
        dc42 administrators @PCR
        last edited by 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.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        PCRundefined 1 Reply Last reply Reply Quote 1
        • PCRundefined
          PCR @dc42
          last edited by

          @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 🙂

          o_lampeundefined 1 Reply Last reply Reply Quote 0
          • dc42undefined
            dc42 administrators
            last edited by

            @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.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            1 Reply Last reply Reply Quote 1
            • o_lampeundefined
              o_lampe @PCR
              last edited by 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)

              PCRundefined T3P3Tonyundefined 2 Replies Last reply Reply Quote 1
              • PCRundefined
                PCR @o_lampe
                last edited by

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

                1 Reply Last reply Reply Quote 1
                • deckingmanundefined deckingman referenced this topic
                • T3P3Tonyundefined
                  T3P3Tony administrators @o_lampe
                  last edited by

                  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.

                  www.duet3d.com

                  1 Reply Last reply Reply Quote 1
                  • gloomyandyundefined
                    gloomyandy
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 1
                    • First post
                      Last post
                    Unless otherwise noted, all forum content is licensed under CC-BY-SA