Why use a Raspberry Pi with a Duet 3?

A Former User

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 execute macro1.gcode stored on the SD card in the Raspberry Pi?

oozeBot

@bearer I'll test this when I run home for lunch today and report back..

dc42

@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.

spllg

@dc42 >it's because ..< - is this the reason for cancel.g not being called when a print is cancelled?

A Former User

@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 execute M1 instead of using the paneldue?

dc42

@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 execute M1 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.

oozeBot

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..

dc42

@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.

spllg

@dc42 i canceled it by hitting cancel on the web interface of dwc (havn't got a dwc).

Danal

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>

Phaedrux

@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?

Danal

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

gtj0

@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.

oozeBot

@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?

Phaedrux

I ordered this screen. Seems similar to the one Danal posted, and was reasonably priced in Canada.

https://www.amazon.ca/gp/product/B07ZH6L9L4/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

garyd9

@Phaedrux said in Why use a Raspberry Pi with a Duet 3?:

I ordered this screen. Seems similar to the one Danal posted, and was reasonably priced in Canada.

https://www.amazon.ca/gp/product/B07ZH6L9L4/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

Pretty far off topic, but I followed that link and immediately started laughing. Considering it's showing a 7 inch diagonal screen, how tiny is the hand in the picture?

71x3wBxH-pL.SL1500.jpg

Phaedrux

@garyd9 I know, right?!

dc42

@gfisher said in Why use a Raspberry Pi with a Duet 3?:

@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..

If this is important, I think the real answer is to implement a call from RRF to the Pi to get the list of files in a folder, so that RRF can implement M20. I don't think it should be hard. If M36 was implemented in the same way then it would also be possible to start print jobs from PanelDue.

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?

Have you tried resetting the PanelDue?

oozeBot

@dc42 said in Why use a Raspberry Pi with a Duet 3?:

If this is important, I think the real answer is to implement a call from RRF to the Pi to get the list of files in a folder, so that RRF can implement M20. I don't think it should be hard. If M36 was implemented in the same way then it would also be possible to start print jobs from PanelDue.

I agree - everything else is just a hack. We are in the process of evaluating the integration of the Duet 3 / PanelDue into our next generation of printers. This has been a stumbling block and was the reason for my original question. I would like to move forward with the RPi+Duet3 combo, but need some level of assurance that the the PanelDue will be able to become fully functional as it is with your other products.

Do you want me to submit this as an enhancement request in some way? For clarity, after your explanation, yes - I'd like to see both M20 and M36 implemented.

Thank you for your consideration..

chrishamm

M20 and M36 are already implemented in DSF (including emulation support). So what I'd like to do in the future is to move the whole SBC interface in the firmware to a separate task and to send all but a few certain codes (like M112/M999) from RRF to DSF for further processing. So when you execute a code from serial USB or PanelDue, DSF would process it in the first place and return a proper response where applicable.

@spllg cancel.g isn't processed yet because that macro file is optional and followed by a request to stop.g. So currently stop.g overrides the first macro request. I'll fix this bug in the firmware soon - probably when the Linux interface has been moved to its own task.