Duet 3 - goodbye, SBC
-
After a few months playing with the Duet3 and SBC combination, I've decided to revert the duet3 back to standalone. The decision was made last night when my Raspberry Pi4 locked up. (It might have been a kernel panic. I don't know. The Pi was completely unresponsive until I disconnected power and reconnected to let it reboot.) This happened mid-print.
In the course of the last few months, I found that using the duet3 in SBC mode isn't limiting as I expected. While RRF 3.2.2 is slightly ahead of DSF in development, everything I needed worked properly or could be made to work with slight changes. Specifically, the PanelDue works fine when the Duet is in SBC mode, and any conditional g-code parsing issues I had with DSF were easily worked around. In other words, I found running with DSF to be stable and working.
However, there's no getting around the fact that the SBC is a multi-faceted additional point of failure. Not only can the Pi hardware can fail, but there's also the SPI ribbon cable, the additional power supply for the Pi, the OS running on the Pi, and the DSF software suite (This is in addition to all the things that can fail on a standalone Duet3 installation.)
At the current time, and for my particular installation, the only added value that the SBC offered to me was faster gcode upload speeds and an ethernet bridge. It also offered the ability to tinker that I never got around to taking advantage of. Even if I used a small touch screen with DWC on the SBC, I still think things would be more stable with the duet3 in standalone and the Pi running independently.
Perhaps one day RRF/DSFwill offer some advantage over standalone that will cause me to re-evaluate.
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
You lasted longer than I did.
I checked it out for a day or two and thought it could be good in the future and went back to what I know - standalone.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
+1.
Simple is good.
-
@fcwilt said in Duet 3 - goodbye, SBC:
You lasted longer than I did.
I checked it out for a day or two and thought it could be good in the future and went back to what I know - standalone.
Frederick
..and you got further than me. I only got as far as bolting an RPi onto my printer - I never did try it out because stand alone did/does everything I need. Maybe one day someone will come up with a use for the SBC, but that day isn't here yet (at least, not for me).
-
I was perplexed when Duet 3 was announced. SBC? Why? Unless we're doing the Klipper thing, I see no reason.
*not actually a robot
-
Now i use both . On the same printer.
Standalone with the house Wifi . and SBC when i take it to work with the Work Wifi . I have set both up the same config on the same sd card . I just sway card from duet to SBC when i need to.
-
@bot said in Duet 3 - goodbye, SBC:
I was perplexed when Duet 3 was announced. SBC? Why? Unless we're doing the Klipper thing, I see no reason.
I don't know for sure - IIRC it was "customer driven". That is to say, when they did a poll of what features users would like to see, a significant number of respondents said something along the lines of a separating out the web\user interface and leaving the Duet board just to take care of everything else. Maybe I misunderstood, but I was initially under the impression that an SBC would be essential. That's why I bought one. But in the event, it transpired that it would be optional and that the main board had an Ethernet connector and the ability to use the PanelDue. I can't say if that was a change of tack or if I just misunderstood the initial intent.
-
There is a lot of demand for the kinds of plugins and functionality that people are used to getting with octoprint. The SBC allows for fully persistent plugins to satisfy that.
Some people are unhappy with the limits of the PanelDue. With the SBC you are able to use larger HDMI touch screen for the full DWC interface.
You could even do your slicing on the SBC if you wish.
It allows for a wider range of USB cameras to be connected to the Pi and used with DWC.
It also allows for faster upload speeds of sliced gcode files which is important for some people with 100+Mb files.
It allows for more networking flexibility. Wifi, ethernet, bridging, routing, etc.
Eventually concurrent gcode streams and processing, etc.
But Rome wasn't built in a day. So at the moment it's more potential than actual.
But it is optional. No one is forced to use it. Eventually there will be compelling features that draw people to it. At least that's the goal.
-
I use an SBC with an E3D toolchanger. Comes in handy when doing tool offset calibration with TAMV. I can see where most users wouldn't need it, though.
-
@Phaedrux said in Duet 3 - goodbye, SBC:
There is a lot of demand for the kinds of plugins and functionality that people are used to getting with octoprint. The SBC allows for fully persistent plugins to satisfy that.
I'm sure it will.... eventually. In my evaluation of using the SBC, I was impressed with the potential ability to tinker, but then I wasn't sure what to do with that potential. I can already do timelapse with standalone.
I think the biggest potential of the SBC setup is the ability to intercept gcodes and do something different. However, again, I'm not sure what to do with it. Perhaps I'm just not creative enough.
Some people are unhappy with the limits of the PanelDue. With the SBC you are able to use larger HDMI touch screen for the full DWC interface.
This doesn't require that your Duet is wired directly to a SBC. I still have my Pi sitting next to my printer. It's attached to a monitor/keyboard/mouse. It still shows DWC. Chromium still eventually goes to 100% CPU usage after a few days. (I think that's an issue with Chromium, not an issue with DWC.)
It allows for a wider range of USB cameras to be connected to the Pi and used with DWC.
I can already do that. My timelapse script (running on a Pi using a PiCam) uses telnet to watch what the duet is doing and reacts accordingly. A simple "layer change" script in Cura generates a "M118 P4 S"LAYER CHANGE"" and a python script reacts by taking a snapshot. (Thanks, @resam)
It also allows for faster upload speeds of sliced gcode files which is important for some people with 100+Mb files.
This was something I really appreciated. However, the additional possible points of failure aren't worth the extra upload speed. The one time my Pi locked up cost me more time than all the faster uploads ever saved me.
It allows for more networking flexibility. Wifi, ethernet, bridging, routing, etc.
I can get all that using the Pi to bridge ethernet to wifi. The same Pi that's doing the webcam and DWC. Unlike a SBC config, however, if the Pi locks up, my print job doesn't die with it. (Actually, the printer is completely usable via the PanelDue as long as any print jobs have already been uploaded.)
Eventually concurrent gcode streams and processing, etc.
...
But it is optional. No one is forced to use it. Eventually there will be compelling features that draw people to it. At least that's the goal.Perhaps I'll re-evaluate when the SBC starts being used for more than a glorified I/O device for the duet board. I completely agree that there's a LOT of potential. Today, that potential is untapped, and I wasn't able to think of something to do with it.
By the way, one of the reasons I wasn't fond of OctoPi was that if the Pi died, so did the print job.
I hope my original message wasn't misunderstood. I wasn't (and still am not) bashing the SBC config at all. I was trying to explain that it seems to have feature parity with standalone, and does have some benefits, but that the risks outweigh the current benefits for me.
-
@bot said in Duet 3 - goodbye, SBC:
I was perplexed when Duet 3 was announced. SBC? Why? Unless we're doing the Klipper thing, I see no reason.
That's also what I had hoped the SBC would be used for when the Duet3 was announced. Not to duplicate klipper, but to offload some of the "print job" processing to the SBC. Offloading work from the duet processor would allow more axes, more heaters, etc.
Even just simulating print jobs on the SBC would be useful. (As long as it's not slower than the duet board itself running the simulations.)
-
I use stand alone, no touch screen, trough ethernet. Work like a charm..
After struggling with sbc for months I find stand alone much faster and also I can and supervise all of my machines from different web browser pages.
I just added a monitor to my computer and split the screen in 6.
Using remote desktop I can access all of them from anywhere and anything including my cellphone.. cant complain.
