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

    How will Duet Software Framework Differ from Octoprint? Plugins

    Scheduled Pinned Locked Moved
    General Discussion
    11
    16
    1.5k
    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.
    • rkrammesundefined
      rkrammes
      last edited by rkrammes

      Seems like they are basically building from the best aspects of Klipper and Octoprint. I was kinda hoping someone might figure out an easy way to port Octoprint plugins since they have such a large collection of apparently useful resources. I don't know if they would feel like that is an encroachment.

      dragonnundefined 1 Reply Last reply Reply Quote 1
      • dragonnundefined
        dragonn @rkrammes
        last edited by

        @rkrammes said in How will Duet Software Framework Differ from Octoprint? Plugins:

        Seems like they are basically building from the best aspects of Klipper and Octoprint. I was kinda hoping someone might figure out an easy way to port Octoprint plugins since they have such a large collection of apparently useful resources. I don't know if they would feel like that is an encroachment.

        I don't think this is gonna happen any time. Octoprint is written in Python and DSF in C#. And octoprint architecture is flawed, it often struggles to keep up with sending g-code to the printer when you print something really complex. So I don't like it and dislike the idea mixing anything from Octoprint into DSF

        garyd9undefined 1 Reply Last reply Reply Quote 0
        • T3P3Tonyundefined
          T3P3Tony administrators
          last edited by

          We will provide an interface (or actually 2) that you can use the write plugins for DSF. The exact design of some elements of this are still under development but it exists as a C# capability already (see codeconsole and codelogger examples, along with @wilriker's cancel part of print example). The development to-do is extend it to work for C++ and Python. In addition we intend to specify how to make a back end plugin that requires a visual elements work with DWC.

          At that point there will be a very powerful framework for extension of functionality.

          While Octoprint plugins will not be directly supported there are many plugins with useful features what might make sense to be ported to DSF. How much of the code can be reused will depend entirely in the plugin.

          www.duet3d.com

          1 Reply Last reply Reply Quote 1
          • garyd9undefined
            garyd9 @dragonn
            last edited by

            @dragonn said in How will Duet Software Framework Differ from Octoprint? Plugins:

            I don't think this is gonna happen any time. Octoprint is written in Python and DSF in C#. And octoprint architecture is flawed, it often struggles to keep up with sending g-code to the printer when you print something really complex. So I don't like it and dislike the idea mixing anything from Octoprint into DSF

            Taking each of your points in turn...

            Python vs C#: both are essentially scripting languages that are dependent on runtime bindings. While C# is preprocessed to IL, it's still basically a scripted (in a manner very similar to java.) It should be a fairly easy task to port the DSF to python, java, or anything else.

            Octoprint being flawed: For what it's designed as, it's actually pretty good. Part of that design is that it works with many different printers, and doesn't do anything specific to single printers (without using plugins.) Do you also consider most (all?) mainstream slicer programs flawed because they're limited to the least common denominator supported? For example, I don't think any mainstream slicers support arc movements that the duet supports. Does that suggest that they're flawed?

            As for octoprint being slow, how much of that is an issue with octoprint vs the serial interface being used to communicate? If someone took octoprint and modified to communicate over a 24 pin high speed interface (that a Pi uses to talk to the duet3), would it still "struggle to keep up with sending g-code..."?

            Of course, DSF is (or will be) a specialized interface for a single type of control board. In your opinion, does that limitation make it flawed? Regardless, being that it's a specialized application for a single control board, it should be better than a generic approach, but until it's more mature, we don't know. It will certainly be better than octoprint in doing things that octoprint doesn't support... but that doesn't make it better overall.

            Personally, I'd love to see a duet specific branch of octoprint. That would allow the duet folks to concentrate on developing duet specific features while giving many features of octoprint that we've never had before such as much better webcam support (including automatic timelapse), the ability to display printing and non-printing moves in the web interface in near real time, etc.

            "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

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

              There is or will be a facility for DSF to accept input from external GCode streams, such as Octoprint. So it will be possible to run Octoprint + DSF on the Pi, if Octoprint is modified to send GCode via DSF instead of via USB. Gina has said that a rewrite of the Octoprint comms layer is in the pipeline, and that would make it easier to do. But you won't get the real-time status of the Duet reported in Octoprint (same as you can't over USB), unless Octoprint is extended to retrieve it from DSF.

              Some of the most useful Octoprint plugins are already implemented in RRF+DWC, for example bed map visualisation.

              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
              • dragonnundefined
                dragonn @garyd9
                last edited by

                @garyd9 said in How will Duet Software Framework Differ from Octoprint? Plugins:

                As for octoprint being slow, how much of that is an issue with octoprint vs the serial interface being used to communicate? If someone took octoprint and modified to communicate over a 24 pin high speed interface (that a Pi uses to talk to the duet3), would it still "struggle to keep up with sending g-code..."?

                This isn't a serial port issue because octoprint also have problems to keep up sending g-code too Klipper with uses a virtual serial port (a socket file). The problem with octoprint is that everything is handled in one thread/process, I even experience one-two seconds stalls of the printer when loading the web interface from a slow network interface (means when the web interface takes many seconds to load).

                1 Reply Last reply Reply Quote 0
                • DocTruckerundefined
                  DocTrucker
                  last edited by

                  It is suprising what Python is capable of, especially when reading and kicking out text files. There is also a huge difference between an optimised python program and a bad one.

                  Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                  dragonnundefined 1 Reply Last reply Reply Quote 1
                  • dragonnundefined
                    dragonn @DocTrucker
                    last edited by

                    @DocTrucker yeah, I don't blame Python for octoprint problems. Maybe it lacks true threads supports but this can be easy overcome with multiprocessing module.

                    1 Reply Last reply Reply Quote 0
                    • EasyTargetundefined
                      EasyTarget
                      last edited by

                      Meanwhile; TL:DR.

                      For a year and a half I'm running two separate Octoprint instances on a Pi3B+ (with GPIO power), controlling two printers via SerialUSB, one Marlin, one Duet, both at 250K baud. For routine printing I flavor Octoprint over DWC, mostly due to it's job logging and timelapse capabilities.

                      Octoprint does use multiple threads, I see them forking all the time intop, Where I also see that all four cores are lightly loaded and spreading the load, both octoprint instances use 10% total cpu or so when printing, 2/3% cpu otherwise.. Loading the page, reloading quickly, being online on both my phone and the laptop. all of this has been done without affecting ongoing prints. Even if you mash the reload button this will slow down the http responses but not the printing.

                      As far as I can tell I've never had a comms issue that lacked a 'my own damn fault' explanation (eg I knocked the cable out, or rebooted the whole Pi by accident). This system also has Ethernet and runs the printroom WiFi.

                      I'm sure Octoprint was easier to bog down on older boards with fewer cores and lower memory, but the Pi3 is old-hat by now, using earlier PI's is a choice, not an obligation.

                      As for running two instances, the hardware is up to the job and I've got the required unix sysadmin/devops skills to do this successfully; I run a default minimal Raspian install with full separation of the Octoprint processes to separate user accounts, etc. It's very unsupported (*), but I know I'm not alone in making it work, and work well. The biggest issue is the potential to get the streams crossed (connect to the wrong printer). I really should write up how I do it and post somewhere.

                      (*) If you really want to wind the resident trolls on the OctoPrint forum up, go there and ask how to do this. They sternly disapprove, I occasionally go there and read the latest questions on it for a laugh.

                      Disaster? The original Printeye is dying with RRF 3.5 (M208 depreciated).
                      PrintPy2024 to the rescue!
                      MicroPython based; with simple wiring and and no custom PCB.

                      1 Reply Last reply Reply Quote 0
                      • Nuramoriundefined
                        Nuramori
                        last edited by

                        The one thing that I used quite often and rely on for several reasons was the gviewer in octoprint. I have seen the fork of the viewer that has been done by someone who's name I can't remember at the moment, but it's not the same tool as in octoprint. It may seem to get relegated as a nonsense or convenience tool at times on the forum here, but the combination of slider to view future layer pathing, and also (near) real time indication of what the print head is doing and intended to do has saved my prints and lowered my blood pressure more often than not. Even if a DWC plugin that would mimic that as close as possible would be fantastic - the code is open, and iirc in python. If there's a plug-in API, I would even try and migrate that somehow. Personally I'd love to see it as part of DWC.

                        EasyTargetundefined 1 Reply Last reply Reply Quote 2
                        • EasyTargetundefined
                          EasyTarget @Nuramori
                          last edited by

                          @Nuramori I've always loved the gcode viewer too, it's hypnotic, I'd been mentally putting it in the same box as this.
                          Lately I've found a real practical use for it, I've been making objects where I want to do (manual) filament changes at the correct moment. The gcode viewer is perfect for judging that.

                          Disaster? The original Printeye is dying with RRF 3.5 (M208 depreciated).
                          PrintPy2024 to the rescue!
                          MicroPython based; with simple wiring and and no custom PCB.

                          1 Reply Last reply Reply Quote 1
                          • T3P3Tonyundefined
                            T3P3Tony administrators
                            last edited by

                            @Sindarius has done an implementation of the gcode viewer.

                            I agree that having a layer by layer real time view would be awesome!

                            www.duet3d.com

                            Sindariusundefined 1 Reply Last reply Reply Quote 0
                            • DocTruckerundefined
                              DocTrucker
                              last edited by DocTrucker

                              I did a layer by layer preview for the MCP/MTT/Renishaw SLM machines in python back in 2010 ish. It made a 2D preview JPG image, nothing fancy. I'll dig it out and try to adapt it for gcode.

                              What would I be working from? A file and bite numbers or line numbers for layer start and stop?

                              Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                              1 Reply Last reply Reply Quote 0
                              • Sindariusundefined
                                Sindarius @T3P3Tony
                                last edited by

                                @T3P3Tony

                                I could absolutely have the layer slider automatically move based on the current printing layer height. It'd probably take a little more thought but I could have it track to the current line if I spent some time on it. The initial purpose of the work I did was to be able to quickly and easily visualize how multi-material prints would look based off set colors. But there is no reason I can't make it do more 🙂

                                a8cc375d-9ed7-46ce-be70-98a7b162f06b-image.png

                                804bf489-95d0-4894-92b0-32ec5dbc6c31-image.png

                                For larger files it does switch to a line render mode just because WebGL starts to choke after so many polygons.

                                cd15f43a-1ce7-48a0-9bc5-61c7e0eb9f0e-image.png

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