Why use a Raspberry Pi with a Duet 3?

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.

oozeBot

@chrishamm

Thank you for looking into this. I understand the Duet 3 is quite new - I was just afraid to move forward with the Duet3+RPi combo if the PanelDue would have limitations. I feel the functionality provided by the PanelDue is the correct amount for direct control at the printer (with the addition of macros and jobs, etc). The web interface can be used standalone for the rest.. I did not want to go down the road of adding a monitor to the RPi as that adds complexity we do not want to support.

If you need/want anyone to help you beta test any changes around this, please let me know.

zapta

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

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.

I am getting about 250KiB/s. Doesn't help if I move the computer and printer near the wifi router. This is with default settings. I am not familiar with the CRC settings and its implication on data integrity. Will search for it.

Waiting a few more seconds should not be a problem except that Prusa Slicer times out on larger files so I need to transfer them 'manually' via DWC.

garyd9

@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 just would like to add my positive vote for this. It would give much more flexibility in setting up duet 3 boards.

While it's possible to run both HDMI and USB cables to a small screen, the simple fact is that the wiring for the PanelDue is much smaller. There's also the fact that the PanelDue UI is a mature, well designed, simple small screen touch interface that's proven.

spllg

@garyd9 apparently one of these tiny chinese hands which are capable of handling smallest screws at hidden places.

garyd9

Perhaps I'm over-simplifying, but...

Is it correct that the PanelDue just uses serial communication with the duet board? Is it also correct that the PanelDue just uses gcode commands and responses to display data and take actions (in a manner very similar to how DWC works)?

If so, would it be possible to just connect the PanelDue directly to the SBC and add serial code support to the daemon on the SBC?