Why use a Raspberry Pi with a Duet 3?

oozeBot

@bearer no go on that one.. One note, it is doing some sort of UNIX based mod to commands. M28 /test.gcode results in a file named "t e s t . g c o d e". I think that is related to the issue with switching directories.

A Former User

mkay, the linux side of sd things does a lot of strange tings, as its not a sd card but just a folder on the pi's filesystem, which amongst other things is now case sensitive.

you may also find the above behavior to change, as it may be unintended..

oozeBot

@bearer Scratch it all- SD Card 0 and SD Card 1 are both the SD card in the RPI. In the GUI under Jobs, I can switch between them..

Sorry about that - I was confused when it reported that SD0 was ~4GB which is the size card I put in the Duet.

A Former User

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

@smece Adding Octoprint is compelling for sure - I honestly didn't know if it was possible while using the same RPI as a host for the duet framework..

I think you missed my point

I do not think one should use octoprint with duet3!!! I think one should develop similar plugins for the Duet3 platform, and that's only possible with SBC on the Duet3, not really something you should have in firmware

I use octoprint with duet2eth and is really not very "duet style work" so I shoot print to duet trough "duet system", and use "duet system" for everything just like octoprint does not exist, and octoprint there just "monitors" the print and allows me to use the two important plugins for me... I'm not "printing from octoprint", so for e.g. octolapse plugin is not something I could use (not that I normally use it anyhow)

I was using octoprint plugins as example what could exist on duet3+rpi, not as idea to use octoprint with duet

oozeBot

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

A Former User

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

gtj0

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

zapta

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

dc42

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

oozeBot

@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

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>