Duet 3 Mainboard 6HC - initial production run.

A Former User

Is the DSF tied to Rpi implementations or can we use any SBC that has an SPI bus interface?

Its no longer tied to wiringpi library for SPI at least. I suspect official support will be limited, initially at least, but you'll have a fighting chance at least

gtj0

@bearer said in Duet 3 Mainboard 6HC - initial production run.:

Is the DSF tied to Rpi implementations or can we use any SBC that has an SPI bus interface?

Its no longer tied to wiringpi library for SPI at least. I suspect official support will be limited, initially at least, but you'll have a fighting chance at least

Not having official support doesn't worry me

A Former User

@T3P3Tony

Purchased, im happy to be an early adopter to support the amazing work you guys do.

looking forward to getting this thing in my hands.

Regards

dc42

@gtj0 said in Duet 3 Mainboard 6HC - initial production run.:

@dc42 Is the DSF tied to Rpi implementations or can we use any SBC that has an SPI bus interface? For instance, I have a half dozen quad core Wandboards with SPI interfaces.

Oh and maybe this is a question for @chrishamm but what made you guys go with C# and .NET for the DSF?

It's not tied to RPi, but if you use a different SBC then you will need to port Duet Software Framework to it, and that SBC has better have a good SPI and GPIO driver unless you can write them yourself.

If the SD card socket is fitted to the Duet 3 then it will be possible to run it in standalone mode (i.e. without the RPi or other SBC) by using the Ethernet interface; but if you do that, you will miss out on a lot of features.

Using C# and .NET was chrishamm's choice. But in my experience, it is way more productive than programming in C++, when you have the computing power to absorb the additional overhead. Having memory management makes coding much simpler, and the run-time checking of pointers, array bounds etc. speed up fault detection hugely. A few days ago I spent three hours tracking down a null pointer dereference in RRF3 on Duet 3. That would have been pinpointed instantly had I been able to use .NET instead of C++.

gtj0

@dc42

The Freescale iMX6 platform is well supported in Linux. I wrote some of the device tree and driver stuff for it.

Not criticizing the choice of C#, just curious. I haven't done any C# development in about 10 years so I'll have to see what .NET dev tools are like for Linux these days. Hopefully there's an Eclipse plugin.

A Former User

Hi Guys

Brain is wandering here. With this new equipment and its expansion capabilities.

Do you think one Duet-3 with expansion boards could be configured to control for example three identical printers, X3 Y axis drivers, X3 Y axis drivers X3 Z axis drivers and X3 extruder drivers all running at the same time (properly calibrated of course) im thinking print farm applications where numerous printers of the exact same make, model etc are all printing the same g-code at the same time.

Thoughts.

JoergS5

@calvinx IMHO it should be possible to augment IDEX printers to have three extruders.

T3P3Tony

@calvinx yes. Map the drivers to the axis and off you go. However if one printer fails you either need to pause all 3 or wait to the end of the tandem print to sort it.

A Former User

@t3p3tony

Understood.

My next question is just looking for a little clarification on wiring between the Duet-3 and a Rasberry Pi3B+

The Engineer in me likes to be well prepared sorry..

The Wiring Diagram for the Duet-3 shows the pinouts for the SBC 26 pin connector as shown in my render below, my question is, are the pins i have question marked not used ? as they are not mentioned in the wiring diagram.

alt text

dc42

That's correct, those pins are not connected on the Duet.

A Former User

@dc42

David Thank you for the faster than light response.

this will allow me to make up a cable etc.

dc42

We intend to supply a 26 to 40 pin cable with the Duet 3 main board, however if you wish to connect to other pins of the RPi then you will need to use a splitter board or a custom cable.

Mabover

@dc42 David this is very exciting news, I am looking forward to the possibilities for the future.
I am curious in the what way canopen was not fast enough as it is commonly used in multi axis coordinated motion control applications in Industrial automation.

If you do bring canopen support into the firmware are you thinking of only supporting the newer canopen fd standard or will you be supporting the original canopen standard. I hope the original standard is supported as there tends to be a fair amount of used hardware on ebay that supports plain canopen

dc42

@mabover said in Duet 3 Mainboard 6HC - initial production run.:

I am curious in the what way canopen was not fast enough as it is commonly used in multi axis coordinated motion control applications in Industrial automation.

It's because the number of movements per second can be so high in 3D printers. Consider a curve that has been segmented into 0.2mm segments in the STL and is being printed at 100mm/sec. That's 500 moves/second. Each move may involve coordinated motion of 8 or more stepper motors, using today's technology.

If you do bring canopen support into the firmware are you thinking of only supporting the newer canopen fd standard or will you be supporting the original canopen standard. I hope the original standard is supported as there tends to be a fair amount of used hardware on ebay that supports plain canopen

The plan is to use CAN-FD on one of the buses for Duet3 hardware, and in future to support CanOpen (not FD) on the other one. Canopen-FD is very recent - I don't believe it existed when I started designing the protocols around this time last year, although it was talked about as a future development.

A Former User

@dc42 said in Duet 3 Mainboard 6HC - initial production run.:

We intend to supply a 26 to 40 pin cable with the Duet 3 main board.

Excellent news.

Might I suggest a "what's in the box" list on the page that the Duet-3 is for sale on, it might help people plan.

My next question is about the control software, is the raspberry pi going to be running raspbian with a version of the DWC or whats the plan and where can obtain the required software ?

regards

deckingman

@calvinx This probably won't help much but it might......

I've bought an RP1 4 on the recommendation of user @wilriker . Personally, I haven't got clue - never used an SBC of any sort - no idea about Linux. But to get me up and running for the TCT show, @wilriker is holding my hand. He has put together an iso disk image thingy that I've somehow managed to put on an sd card and he can hack into it remotely and do his stuff.

Anyway, I know that he uses Arch Linux rather than Rasperian. I also know that he is only using 9 pins to connect his RPi to the Duet. I think he only uses 2 gnd pins.

T3P3Tony

@calvinx

Might I suggest a "what's in the box" list on the page that the Duet-3 is for sale on, it might help people plan.

We have not decided all.of what's in the box yet but will do over the next few weeks. A connector pack is also being considered as the motor and medium current heaters (extruders) use JST VH connectors not Molex KK

My next question is about the control software, is the raspberry pi going to be running raspbian with a version of the DWC or whats the plan and where can obtain the required software ?

Raspian is our reference OS but @wilriker has been working with Arch Linux.

There is a new suite of software that runs on the Linux SBC called DuetSoftwareFramework that I hope @chrishamm will be able to write more about in the documentation soon. It will be installed using "apt" on top of an out the box Raspian image.

DuetSoftwareFramework has a number of programs. DuetControlServer is the core, it handles the SPI link to the Duet and pipes the gcodes and maintains an object model of the state of the printer. DuetWebServer uses the DuetControlServer API to provide DWC as we are used to using it. The design has the capability for DuetControlServer to have plugins to process the gcode and access the object model so in the future people can write plugins to do things like cancel part of the print job for example.

wilriker

And just for the sake of completeness: on Arch Linux I maintain AUR packages for DuetSoftwareFramework so installation there is also very easy.

If the kernel on an arbitrary SBC is >=4.8 then "porting" DSF is merely a question of changing the config file for DuetControlServer since @chrishamm is using /dev/gpiochip for communication.

A Former User

@wilriker

What in your opinion makes Arch Linux a better proposal than Raspbian ?

wilriker

@calvinx I'd say mainly personal preference. I run Arch Linux on all of my machines. I like the concept of a rolling release and having the latest version of all packages. On RPi 3B(+) there is even an aarch64 image which let's the ARM A53 use its full potential (unfortunately there is no upstream kernel support for RPi 4B yet so this still has to wait).