Why use a Raspberry Pi with a Duet 3?
-
@smece Yep, totally went over my head! lol. I would only be interested in Octoprint for some of the ancillary plug-ins like you mentioned. I do love the telegram bot..
-
@gfisher yeah, telegram bot is my main monitoring solution for many things, including 3d printing .. now I'm sure when duet3 becomes common the plugins will start to come, just like they did for octoprint..
-
@Phaedrux said in Why use a Raspberry Pi with a Duet 3?:
@gfisher said in Why use a Raspberry Pi with a Duet 3?:
Plus I can fully utilize my PanelDue.
This is actually proving to be a sticking point for me as well. A HDMI touchscreen with fill DWC is honestly more than I need or want for at the printer controls. I've gotten used to the PanelDue layout and have a lot of macros that are suited for the screen. For this reason I'm thinking of running standalone for the time being.
Eventually the SBC will have some plugins and features that might change that however.
I should have a version of DueUI for the SBC/DSF ready for testing on Monday if you're interested. It's been working great on my HDMI touchscreen.
-
Is there a plan to have a Duet3 with Wifi?
Also, does the ethernet connection provide significantly faster file transfer than the wifi of the Duet2? (my duet2 wifi file transfer is slow in general).
-
@zapta said in Why use a Raspberry Pi with a Duet 3?:
Is there a plan to have a Duet3 with Wifi?
We don't plan to do a WiFi version of the existing Duet 3. We plan to refresh the Duet 2 range later this year, but we haven't decided what to call it yet.
Also, does the ethernet connection provide significantly faster file transfer than the wifi of the Duet2? (my duet2 wifi file transfer is slow in general).
In my office, with good WiFi signal strength, I get around 800kbytes/sec to both Duet WiFi and Duet Ethernet, if CRC checking is disabled.
-
@dc42 so what is keeping the PanelDue from reading the list of macros and jobs on the RPi’s SD card? If I modify HomeX on the RPi to play a sound and then press HomeX on the PanelDue, it plays that sound- meaning it is calling the copy on the RPi.. the same should be possible for macros and jobs.
If this could be accomplished, I think the PaenlDue would become much more useful for the new generation of Duet 3.. please consider looking into this.
Thank you, Gabe
-
Hmm. Another idea, if you put on the PanelDue SD card macros that only contain one line ala
M98 Pmacro1.gcode
I'm guessing the Duet would executemacro1.gcode
stored on the SD card in the Raspberry Pi? -
@bearer I'll test this when I run home for lunch today and report back..
-
@gfisher said in Why use a Raspberry Pi with a Duet 3?:
@dc42 so what is keeping the PanelDue from reading the list of macros and jobs on the RPi’s SD card? If I modify HomeX on the RPi to play a sound and then press HomeX on the PanelDue, it plays that sound- meaning it is calling the copy on the RPi.. the same should be possible for macros and jobs.
If this could be accomplished, I think the PaenlDue would become much more useful for the new generation of Duet 3.. please consider looking into this.
It's because currently, when RRF receives file-related commands (e.g. M20), it has no way of getting the required information from the Pi, only from the local SD card.
-
@dc42 >it's because ..< - is this the reason for cancel.g not being called when a print is cancelled?
-
@spllg said in Why use a Raspberry Pi with a Duet 3?:
@dc42 >it's because ..< - is this the reason for cancel.g not being called when a print is cancelled?
is
cancel.g
run if you executeM1
instead of using the paneldue? -
@bearer said in Why use a Raspberry Pi with a Duet 3?:
@spllg said in Why use a Raspberry Pi with a Duet 3?:
@dc42 >it's because ..< - is this the reason for cancel.g not being called when a print is cancelled?
is
cancel.g
run if you executeM1
instead of using the paneldue?cancel.g is run if you pause a print (M25) and then send M0 to cancel it. If you cancel it from PanelDue, the RPi doesn't know to run cancel.g from the RPi SD image. My guess is that will will try to run cancel.g from the SD card.
-
I created a macro on the Duet SD card containing the single command: "M98 Ptest.gcode". Then, from the GUI running on my RPi, I created a macro named test.gcode that played a tune. Running the macro from the PanelDue successfully called the macro on the RPi! To verify, I modified the macro on the RPi and ran again - it picked up the changes. This is much cleaner, but still not entirely optimal..
-
@gfisher said in Why use a Raspberry Pi with a Duet 3?:
I created a macro on the Duet SD card containing the single command: "M98 Ptest.gcode". Then, from the GUI running on my RPi, I created a macro named test.gcode that played a tune. Running the macro from the PanelDue successfully called the macro on the RPi! To verify, I modified the macro on the RPi and ran again - it picked up the changes. This is much cleaner, but still not entirely optimal..
M98 is one of a few file-related commands that RRF redirects to the Pi.
-
@dc42 i canceled it by hitting cancel on the web interface of dwc (havn't got a dwc).
-
<Editorial comment>
In my opinion/perception, this entire discussion on the Panel plugged into the Duet is an example of where the future lies: With the Pi. The "stack" of DuetSoftwareFramework and RRF clearly connects the Panel "downstream" of "where it should be" in the natural flow of the future architecture. Thus all the oddities in dealing with things that should originate on the DSF.
The hours that DC42 (and others at Duet/Escher) spend "back porting" ways to make the Panel work better with a 3+Pi are taken from a fixed pool that could be advancing features, or bug fixing, or making the Pi/Touchscreen combo work better (arguably, this is mostly Chris). You get the concept.
Upward/backward compatibility is good, when balanced against the advancement of a system. Clearly, I am an "only forward" kinda guy. I'd much rather see Panel have published limitations, and stop right there. Your opinion may be very different...
</Editorial comment>
-
@gtj0 said in Why use a Raspberry Pi with a Duet 3?:
I should have a version of DueUI for the SBC/DSF ready for testing on Monday if you're interested. It's been working great on my HDMI touchscreen.
I still haven't picked up an HDMI touch screen. Any recommendations?
-
This one "just works". Plugs into USB and HDMI on the pi. No Pi changes needed. There are no doubt others...
https://www.amazon.com/gp/product/B07TXFPHM2
With default DWC, the buttons are pretty small. The following can be adjusted for your preference:
sudo vi /usr/bin/launch-dwc
--force-device-scale-factor=3 at the end of the line that launches chrome (only line in the file, other than header).I settled on 3. You can use fractions to your taste, like 2.5
-
@Phaedrux said in Why use a Raspberry Pi with a Duet 3?:
@gtj0 said in Why use a Raspberry Pi with a Duet 3?:
I should have a version of DueUI for the SBC/DSF ready for testing on Monday if you're interested. It's been working great on my HDMI touchscreen.
I still haven't picked up an HDMI touch screen. Any recommendations?
These are the ones I use not just on the SBC but anywhere i need a small monitor.
https://www.amazon.com/gp/product/B07TXP4CSY/
Excellent picture quality and the touchscreen is spot on.
It's native 1920x1080 but on the SBC I run it as 1280x720. -
@dc42 @bearer I did some more experimenting with placing macros onto the Duet's SD card. It turns out that all that is needed is an empty file that is named exactly as the macro in the RPI's macro folder.. when selecting the macros from the PanelDue, it is directly calling the copy on the RPI.
I recognize the Duet would have no way of getting the required info from the RPi, but would the RPi have knowledge of the Duet's SD card? If so, I'd think it would be trivial to sideload a copy (or null file) to the Duet's SD card..
One other observation is that something I've done has made the macros stop showing up on the right hand side of the Control tab of the PanelDue - they are only accessible from the Macro tab. Any thoughts?