What software to run on a SBC "Rpi" for the upcoming Duet-3
-
I would expect it to be as simple as installing an Octopi image on an RPi to get Octoprint running. No sense in making it more difficult than it needs to be (unless you're a linux elitist I guess?)
-
@calvinx said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@gtj0
I hope you are correct......At the very least I know they'll be a simple sd card image that runs Fedora and the DSF. I know because I just built one Building for other distros will be easy as the DSF (at least in its current form) requires almost nothing in the way of special software requirements.
@phaedrux said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
I would expect it to be as simple as installing an Octopi image on an RPi to get Octoprint running. No sense in making it more difficult than it needs to be (unless you're a linux elitist I guess?)
Exactly. If you want to do "special" things you can but if not, it should be dead simple for anyone who knows what an SD card is to get working.
-
@calvinx
Ahh, the good old 6 Ps.
Just for info, my printer will be on the Duet stand at the TCT show at the NEC in Birmingham from 24th September. Sporting a Duet 3 main board and 3 expansion boards. To be viewed by hundreds if not thousand of visitors.
As of this moment in time, I do not have one item of Duet Gen 3 hardware apart from an RPi 4 which I've bought myself and which I have not the faintest idea of how it works.
All I have to do between when I receive the boards and then, is make and fit the cases/mounts, wire up 13 steppers, (7 axes and 6 extruders) plus heaters, fans etc to "show standard", and get to grips with the new configuration and firmware and the RPi. Oh and I'll be on holiday (in Cyprus funnily enough) from 10th to 19th Sept. So no pressure.
But since my daughter moved out to Australia a few years ago, I've adopted the "ozzy outlook" so all I can say is "she'll be right mate"
-
@deckingman said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@calvinx
Ahh, the good old 6 Ps.
Just for info, my printer will be on the Duet stand at the TCT show at the NEC in Birmingham from 24th September. Sporting a Duet 3 main board and 3 expansion boards. To be viewed by hundreds if not thousand of visitors.
As of this moment in time, I do not have one item of Duet Gen 3 hardware apart from an RPi 4 which I've bought myself and which I have not the faintest idea of how it works.
All I have to do between when I receive the boards and then, is make and fit the cases/mounts, wire up 13 steppers, (7 axes and 6 extruders) plus heaters, fans etc to "show standard", and get to grips with the new configuration and firmware and the RPi. Oh and I'll be on holiday (in Cyprus funnily enough) from 10th to 19th Sept. So no pressure.
But since my daughter moved out to Australia a few years ago, I've adopted the "ozzy outlook" so all I can say is "she'll be right mate"
Ian
I am in the same boat mate I should be able to place my order for a 3 at the end of the week already got the pi4 and like you aint got much of a clue with it do need to get the DSF on it mind at the mo I have managed to get Noobs up and working and on the network with the capability to remote into it with VNC and SSH. Just need some easy to follow guide to install the DSF onto it (a guide that assumes absolutely no linux knowledge lol).
Looking forward to seeing you at TCT again this year!!
Doug
-
@dougal1957 said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
got the pi4
i thought only the 3b+ was supported at this stage.
-
@veti said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@dougal1957 said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
got the pi4
i thought only the 3b+ was supported at this stage.
Yes officially it is the 3B+ at this stage. But @wilriker has been using a 4 and I bought one too. BUT, the official support is for a 3B+ and that is what the Duet guys are using.
-
Officially it's the 3B+ that we support, however when we launch the Duet 3 next month, I expect we will have an official SD card image for the 4 as well.
-
I have been using DSF with both a Raspberry Pi 3B (no Plus) and a Raspberry Pi 4B without any issues. Therefore the requirement from the initial "only 3B+" was lowered to "3B or newer". Also when it comes to Raspberry Pis (so far) they have a one-image-fits-them-all strategy, i.e. you can use the one and the same SD card for all RPi generations even down to RPi 1 (though probably anything slower than the 3B will not be really usable for DSF, my guess).
-
@calvinx said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
You are completely missing the point which is Not about any particular distro at all the main point being to highlight that ease of installation is so important and in this instance to highlight how difficult ArchLinuxARM have purposefully made installation due to elitism to the point that they are no longer welcome by the ArchLinux dev team.
I cannot understand what you mean by purposefully complicating the installation. It is around 10 steps with most of them being copy and paste. Can you please elaborate on what you mean here exactly? I don't want to be offensive I am just curious.
And the basic guide for ArchLInuxARM actually misses/glosses over a small but significant step (it was this small step that was tripping me up) and one that took me a while to work out what was happening.
Would you tell me/us which small but significant step you mean?
-
Those 10 steps will be reduced further as dc42 is talking about official images. (and if you don't want to use the officially supported SBC and image, 10 easy and well documented steps is hardly excessive)
I wonder if they'll base it on the full Raspbian with x windows and the full monthy, or the lighter Raspbian Strech for headless operation?
-
@bearer Of course. The average Duet 3 user should not be bothered with having to install an Arch Linux ARM from scratch. This is something for enthusiasts who want to select their own distro. It should boil down to burning an image to a SD card.
-
Hehe, yeah, its not like you have to build your own m68k from 7400 chips and run lfs on it; but I'm sure you could if so inclined. Challenge accepted wilriker? I would of course try it over the weekend, but busy cutting down lumber, milling logs and carving a paddle instead.
-
@bearer LFS is actually something I wanted to try for a long time. But not too keen on building the hardware from scratch as well.
-
@wilriker said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@calvinx said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
You are completely missing the point which is Not about any particular distro at all the main point being to highlight that ease of installation is so important and in this instance to highlight how difficult ArchLinuxARM have purposefully made installation due to elitism to the point that they are no longer welcome by the ArchLinux dev team.
I cannot understand what you mean by purposefully complicating the installation. It is around 10 steps with most of them being copy and paste. Can you please elaborate on what you mean here exactly? I don't want to be offensive I am just curious.
And the basic guide for ArchLInuxARM actually misses/glosses over a small but significant step (it was this small step that was tripping me up) and one that took me a while to work out what was happening.
Would you tell me/us which small but significant step you mean?
Point 1.
It "could" have been nice and easy for the ArchLinuxARM Dev team to not be assholes and provide an .img file written in such a way that it was easy for people to create a working SD card on a windows based machine using win32diskimager and such like, but they PUPOSEFULLY refused to do that because in their words they wanted the distro to be used by competent Linux users, and it was at that point that ArchLinux kicked the ArchLinuxARM team out the door...
Point 2.
I missed (or misread) a step in the partition section. The written explanation on this is somewhat ambiguous to me at least, after I read (and re-read) I worked it out, I thought it was just me, but I asked another engineering colleague here at work to have a read and he looked at it and his feeling was that the Author of the "guide" might have been forgetting that not everyone might be as up-to-date with a Linux file system structure as the Author was.And this fits in with How ArchLinuxARM have been proven to operate they have openly said they only want competent Linux users to use the software, so what better a way to test the user’s ability than to supply basic installation info.
And this is all now past, & not much further input it required.
Bottom line is that it’s a provable FACT that ArchLinuxARM ARE 100% purposefully attempting to make life difficult for what they see as Non-competent Linux users, That statement by an ArchLinuxARM Dev is in the public domain and that by its very definition is snobbish and elitist, and again it’s a provable FACT that ArchLinux doesn’t agree with the ArchLinuxARM stance to the point that ArchLinux have distanced themselves from ArchLinuxARM's modus operandi and that ArchLinuxARM are no longer welcome or recognised by ArchLinux.
-
@wilriker said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@bearer Of course. The average Duet 3 user should not be bothered with having to install an Arch Linux ARM from scratch. This is something for enthusiasts who want to select their own distro. It should boil down to burning an image to a SD card.
Nail on the head, exactly what i have been saying.
-
@calvinx said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@wilriker said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
@calvinx said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
You are completely missing the point which is Not about any particular distro at all the main point being to highlight that ease of installation is so important and in this instance to highlight how difficult ArchLinuxARM have purposefully made installation due to elitism to the point that they are no longer welcome by the ArchLinux dev team.
I cannot understand what you mean by purposefully complicating the installation. It is around 10 steps with most of them being copy and paste. Can you please elaborate on what you mean here exactly? I don't want to be offensive I am just curious.
And the basic guide for ArchLInuxARM actually misses/glosses over a small but significant step (it was this small step that was tripping me up) and one that took me a while to work out what was happening.
Would you tell me/us which small but significant step you mean?
Point 1.
It "could" have been nice and easy for the ArchLinuxARM Dev team to not be assholes and provide an .img file written in such a way that it was easy for people to create an image on a windows based machine using win32diskimager and such like, but they PUPOSEFULLY refused to do that because in their words they wanted the distro to be used by competent Linux users, and it was at that point that ArchLinux kicked the ArchLinuxARM team out the door...The reason behind not providing a disk image IMHO is not to make it purposefully complex but to cater to the fact that SBCs usually work on microSD cards and cannot boot from USB sticks out-of-the-box. This makes an installation procedure comparable to the one of desktop Arch Linux (where they use a live-CD/USB for installation) close to impossible. Also even if there were a SD card image it would have to include a partition resize-operation on/after the first boot. I think this is what Raspbian does to circumvent not knowing the size of the microSD card in advance. Also doing it this way leaves the user a chance to select their own partitioning scheme.
But yes, I can see that this makes setup of the SD card from a non-Linux system a lot more complicated.
Point 2.
I missed (or misread) a step in the partition section. The written explanation on this is somewhat ambiguous to me at least, after I read (and re-read) I worked it out, I thought it was just me, but I asked another engineering colleague here at work to have a read and he l looked at it and his feeling was that the Author of the "guide" might have been forgetting that not everyone might be as up-to-date with a Linux file system structure as the Author was.I can only say that
fdisk
is something I really rarely use and I always have to consult documentation or a guide. Following the exact steps on the ALARM installation page has led to three successful installations for me so far. And I just follow them dumb, typing what it says.In then end ALARM is just a means to an end for me. I want to run Arch Linux on an ARM based device without having to recompile all of the packages myself. That's what ALARM does for me. Once it's installed there is hardly any difference from Arch Linux anymore. I personally never came across the elitist statements you mentioned - that doesn't mean they exist and also I despite such behavior because no one of us is better than another.
-
@calvinx said in What software to run on a SBC "Rpi" for the upcoming Duet-3:
And you might call it jumping the gun, I call it being prepared for any eventuality.
Prepared would have lead you to know that dc42 posted a link to the setup guide they send out with their prototypes and it clearly states raspbian, as have been the topic of more than on thread lately. I seem to recall the same link posted more than once in the last few weeks as well.
-
@bearer
Never saw it...
I followed the information at : https://forum.duet3d.com/topic/11540/duet-3-mainboard-6hc-initial-production-run/71
But I must thank you for bringing this to my attention, as this only confirms what I have been saying and highlights even more so the possible problems that might be encountered in the future.
Trying to be prepared led me to following the information provided by the vendor, and as you have quite rightly pointed out there is more than one set of instructions and/or information which is scattered all over the place only further highlights and provides credence to my statement that people are going to have issues.
This shows the importance of proper document control and how confusion can occur when documentation on the same subject is scattered all over the place instead of in one simple single point.
-
@calvinx What you leave out of the equation all of the time are also various statements about the documentation not being ready yet and that they will have it once the product is available.
-
Please show me where I said contrary to that? You can’t because I didn’t...
And that is not the point the point is (which from my rabbit hole point of view) This actually all came about because of a statement YOU made which led me down this particular avenue for my own interest.
One that led me to conclude:
That unless a fully compiled SD card image is available there could be issues, unless the image has everything already set up to allow the user avoid having to use the terminal then I stand by the assertion that there is going to be issues.
For example, take a look at the following link:
Now looking at that from a non-Linux users point of view the amount of input via the terminal is daunting for some imagine what it’s going to be like for those who even struggle with windows!!
You are preaching to the converted here, no one want to see the DUET-3 be a success more than I, but I want to play devil’s advocate here, unless it’s almost plug and play there is going to be a huge amount of problems.
And if the off the cuff comment you made about arch Linux is anything to go by It managed to lead me down this particular rabbit hole, what’s to say it couldn’t have lead someone else down that rabbit hole too. We all need to take ownership of our actions.
So if I can highlight my experience and a possible issue and that makes sure that it’s been noted so that action can be take so problems can be avoided then that’s really good and if it means that the Duet team takes a look at and decides "we need to get this area right first time with minimal input from the user" then that’s a good thing too.
If a one stop SD image is made available then Excellent, just be prepared for the unexpected.