x86_64 Builds about duetsoftwareframework HOT 6 CLOSED

We won't offload functionality that would be useful in standalone mode to the SBC because that would complicate the code structure. Code parsing is already performed on the SBC so that the MCU on the Duet doesn't have to do that.

from duetsoftwareframework.

Okay, i compiled it and running now on an Ubuntu 21.04 LXC container.
I must say, kudos, the build process (3.3-dev branch) didn't throwed any errors and it works perfectly, not what im usually running into.

But still an x86_64 repository, would be amazing for people that don't want or can't compile it :-)

However, Thanks!

from duetsoftwareframework.

Hey, great to hear it worked well for you! We considered x86 builds but I am not aware of base boards with SPI and GPIO that would actually support DSF. Would you mind letting us know what board you use?

from duetsoftwareframework.

there are boards like the odyssey x86j4105, that can do this.
But sadly i have an odroid h2, that doesn't have spi and i missed that completely 🙈

So you are completely right, there is no need for x86 builds.
Sorry for making the noise, i think this thread can be closed then 🙈

But i have another question, actually i thinked initially that this framework could go into the klipper direction and tbh, it would be amazing to have an framework that can use the processing power of a stronger sbc that can control the mcu. Updates and all that stuff could be realized simply in the gui, like in fluidd for example.
Are you going into that direction?

And any chance that this framework could support in future a connection over serial/canbus or sth like that? That would allow to use all the other mcu's out there. I mean i know, this step would probably hurt the duet board sales, but on the other side make the duet software much more popular.

i think to be honest, people are more free or have less problems to buy a licence for a good software and that would help you too, instead of exchanging their boards. Look at unraid for example, their concept is great.

Dunno if this belongs even here, but yeah, my honest opinion, it could be a win win for everyone.

Cheers ✌️

from duetsoftwareframework.

There is barely anyone out there using DSF on x86_64. If there is reasonable demand we'll provide prebuilt packages but for now we've decided to omit it.

Can you explain what you mean by going into the Klipper direction? We've got first builds with input shaping working and plugins have been supported v3.3.0, although there is still some work left to be done.

DSF is open-source so anyone can go ahead and add support for other connection interfaces, but that is no priority for us at this point. We may consider CAN (e.g. from Raspi + Seeed CAN shield) at some point but that's merely an idea rather than a fixed idea.

from duetsoftwareframework.

There is barely anyone out there using DSF on x86_64. If there is reasonable demand we'll provide prebuilt packages but for now we've decided to omit it.

Can you explain what you mean by going into the Klipper direction? We've got first builds with input shaping working and plugins have been supported v3.3.0, although there is still some work left to be done.

DSF is open-source so anyone can go ahead and add support for other connection interfaces, but that is no priority for us at this point. We may consider CAN (e.g. from Raspi + Seeed CAN shield) at some point but that's merely an idea rather than a fixed idea.

Hi, going into the klipper direction, simply means to extend more pieces of the software to the sbc. So the mcu has less todo itself.
You are already going into this direction with dsf, that's great already.
Thanks 👍

from duetsoftwareframework.