How will Duet Software Framework Differ from Octoprint? Plugins
-
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.
