DWC + Octoprint on RPi + Duet3?
-
Is anyone running Octoprint and DWC simultaneously from an RPi connected to a Duet3?
I’m hoping to upgrade my CoreXY with a third Z axis for bed leveling, and so either need to add a Duex or to update my board to a Duet3. I currently have a dedicated Pi running Octoprint hooked up to my Duet2, and like running most “production” prints from there. But I can’t beat DWC for printer setup and tuning.
Would it be possible to run the Octoprint server alongside DWC on the Pi and get the best of both worlds? Anyone doing this?
-
@whopping-pochard said in DWC + Octoprint on RPi + Duet3?:
and get the best of both worlds?
Problem is you're not getting the best of the Duet when introducing Octoprint.
You might be able to shorehorn Octoprint to work with CodeConsole and socat, but you'd probaly be better of working towards getting the functions you miss from Octoprint working in DWC and DSF.
-
Octoprint feeds a printer through USB from Octoprint's SD card. This bypasses Duet's facilities entirely. Much better to use DWC to upload the job to Duet's SD card, print, etc, etc.
-
Exactly why I’d like to run both simultaneously.
-
Well, you seem determined
At the same time, I think you have the answer to your original question as phrased: Generally people don't run octoprint with Duet, so the chances of finding a D3+Pi person doing it are very small.
Your second question was: Will it work? I don't see anything that would stop it. Connecting a USB from the Pi to the Duet is sometimes done for BOSSAC from the Pi, and it works. So, very high odds it will physically function. Also, a Pi4 runs a few percent CPU and Memory when printing, so there is plenty of "room" for Oct.
-
What might be interesting would be to run octopi on a Pi4 that's also running DSF.
Doesn't DSF have a "console" like mechanism for communication? If so, it might be possible to redirect octpi's USB communication to DSF instead. That would give you the advantages of OctoPi, and the advantage of DSF's much faster SPI communication with the Duet3 board.
Everyone talks about the "disadvantages" of using OctoPrint/Pi, but other than the "slow" USB connection used by OctoPi, what other disadvantages are there when compared to today's stable DSF?
-
@garyd9 said in DWC + Octoprint on RPi + Duet3?:
What might be interesting would be to run octopi on a Pi4 that's also running DSF.
This is exactly what OP asked.
Doesn't DSF have a "console" like mechanism for communication? If so, it might be possible to redirect octpi's USB communication to DSF instead. That would give you the advantages of OctoPi, and the advantage of DSF's much faster SPI communication with the Duet3 board.
It is a command line program, not a "console". It might be possible to stitch the two together, but it is going to take some code beyond what exists today.
Everyone talks about the "disadvantages" of using OctoPrint/Pi, but other than the "slow" USB connection used by OctoPi, what other disadvantages are there when compared to today's stable DSF?
Duet doesn't "know" it is printing. It cannot "look ahead" in the Gcode stream. It cannot scan the file for max z or layers. You can't trigger a "pause" with any of the various forms of Duet pause facility. If you pause via Oct, no macros on the Duet are triggered. Remote monitors intended for the Duet don't work. Triggers of any sort are going to be somewhat questionable. Some will work, some will not.
Shall I go on? The disadvantages really are encapsulated in the statement "Octoprint feeding the USB 'bypasses' Duet's value". Which may be OK, if you don't need or want any of that Duet stuff.
However... I have to question why then run a Duet at all? If someone is really determined to run Octoprint, and therefore have Oct be the "intelligent" layer and the board be "dumb", why not run a much cheaper board? It makes very little sense to me to purchase the best board/system on the market, and then bypass it.
Somewhat like buying a very capable vehicle, and then towing it everywhere.
Delta / Kossel printer fanatic
-
I think what you really want is for DSF and DWC to mature to the point where the plugins available match what Octoprint has.
-
@Phaedrux said in DWC + Octoprint on RPi + Duet3?:
I think what you really want is for DSF and DWC to mature to the point where the plugins available match what Octoprint has.
Yes that is definitely what I want!
@Danal said in DWC + Octoprint on RPi + Duet3?:
However... I have to question why then run a Duet at all? If someone is really determined to run Octoprint, and therefore have Oct be the "intelligent" layer and the board be "dumb", why not run a much cheaper board? It makes very little sense to me to purchase the best board/system on the market, and then bypass it.
That's a great question! A lot of it comes down to the fact that I'm still relatively new to Duet, and so may not have internalized some of the advantages you may be relying on on a more daily basis. (Running the same machine via both interfaces gives me a great opportunity for real-world A:B comparisons on this front.)
Much of what I currently love about the duet has to do with configurability via filesystem. For a home-built printer, where I'm continuously trying out new tweaks and swapping in new parts, there's just no comparison. It's an amazing platform for learning the hardware without being bogged down in firmware recompilation. (Preaching to the converted here, obviously.)
But I also am doing more and more printing for work, and there some aspects of the OctoPrint plugin ecosystem really shine. Filament usage tracking, job databasing and automated timelapse uploading... For 'production' jobs, during periods when I'm not in the middle of tweaking my hardware, it's pretty nice to have access to lots of those kinds of tools without having to write them myself. Instead I can spend my time on things I enjoy more, like ill-advised machine upgrades.
Not to mention sharing some commonality with my non-currently-Duet-driven machines. (Of course if I end up going the Duet3 instead of Duex route, that number might decrement by one...)Running OctoPrint alongside DSF/DWC means that I will only "bypass" Duet-specific functionalities on occasions when I don't particularly need them. Given how I'm interfacing with the hobby at this point in time, I still see a lot of theoretical advantages to having both running!
So it sounds like no one here has done it yet. If I give it a whirl I will be sure to report back with my experiences!
-
@Danal said in DWC + Octoprint on RPi + Duet3?:
Shall I go on? The disadvantages really are encapsulated in the statement "Octoprint feeding the USB 'bypasses' Duet's value". Which may be OK, if you don't need or want any of that Duet stuff.
Perhaps for some, the contents of the capsulation are implied. For anyone else, an enumeration of the contents is required. Your statement disregards that many people are unaware of, or haven't really considered, what might be lost in in sending discrete gcode commands instead of printing full files.
In fact, it would be perfectly reasonable for people to see some of the information on DSF and come to the conclusion that it runs the duet h/w in the exact same manner as OctoPi might, the only exceptions being that DSF has the advantage of a much faster communication channel and some "inside knowledge" of how RRF3 works.
Even your examples don't really fill in that gap. For example, if using a duet3 with DSF and printing a gcode file, does RRF running on the duet3 h/w know it's printing a file, or does DSF know it's printing a file and the duet3 h/w is just processing the gcode commands? Afterall, when you use gcode to query the status of the printer, the duet3 board isn't responding: DSF is.
When using DSF, does the duet h/w look ahead into the gcode file, or is it really DSF looking ahead? If the latter, how would that be different from OctoPi looking ahead?
No, the duet itself might not trigger a macro on pause, but does it trigger a macro when DSF is in control, or does DSF trigger the macro? Why couldn't octopi see that pause and also trigger a macro?
The same or a similar question could be applied to each one of your examples.
The point of my arguments isn't to argue, but try and get you to see a different perspective. Duet3D might see DSF as an integral part of RRF, but some other people see "OctoPi lite" that just happens to have a faster comm channel.
Somewhat like buying a very capable vehicle, and then towing it everywhere.
That depends on if you bought the car for driving or for it's awesome entertainment system.
For driving, the standalone duet3 board is the best option. Current stable DSF downgrades that functionality somewhat and doesn't seem to offer anything extra in terms of entertainment. (In fairness, the unstable branch of DSF brings things closer to parity with the standalone duet3.) -
@garyd9 said in DWC + Octoprint on RPi + Duet3?:
The general answer to all of your detailed questions is: When fed by USB, the Duet doesn't "know" it is printing a file. This is easily verified by the printer status. This undoes quite a number of things.You also discussed RRF v DSF quite a bit. They are very intimately related by a software/hardware protocol (SPI) that makes most of those questions non-sequiturs. Whereas Octoprint and Duet are separated by a text protocol riding a serial connection, and it is clear therefore that things like capturing the XYZ of the printer at the instant a trigger occurs is simply not possible. (For Oct or any other USB feeder.)
Somewhat like buying a very capable vehicle, and then towing it everywhere.
That depends on if you bought the car for driving or for it's awesome entertainment system.
Excellent metaphor, fully supports the paragraph just before the quoted sentance: Why not buy a sound system? Much cheaper.
For driving, the standalone duet3 board is the best option. Current stable DSF downgrades that functionality somewhat and doesn't seem to offer anything extra in terms of entertainment. (In fairness, the unstable branch of DSF brings things closer to parity with the standalone duet3.)
Stable v Unstable seems a bit off topic to Octoprint usage... but.. Absolutely Agreed! Given how new 3.x is, I would either run 2.x or unstable 3. I would not consider stable 3 as being of much merit, at this time.
-
And, having said ALL of that... I do believe I understand (but do not share) the perspective from the people who do want to run Oct.
Which why, way up at the top of this discussion, I was the first person to start describing (helping) how to do that.
