How will Duet Software Framework Differ from Octoprint? Plugins
-
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.
-
@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."
-
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.
-
@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).
-
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.
-
@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.
-
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 in
top, 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.
-
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.
-
@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. -
@Sindarius has done an implementation of the gcode viewer.
I agree that having a layer by layer real time view would be awesome!
-
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?
-
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
For larger files it does switch to a line render mode just because WebGL starts to choke after so many polygons.
