Duet 3 Mainboard 6HC - initial production run.

Mabover

@T3P3Tony
CanOpen support would be great as that is what the industrial servo and stepper drives normally support
See https://www.can-cia.org/canopen/ for more info

Mabover

@t3p3tony
I also see mention on the about wiki page that the ethernet port may possibly support EtherCAT in the future, is that EtherCAT slave or master function. Master support would be totally amazing to have as you could integrate EtherCAT servo/stepper drives (depending on what protocol is used, CanOpen over EtherCAT is the most common). Slave support would also be very interesting as it would allow for a low cost EtherCAT multichannel stepper drive with I/O which could easily be used with Linuxcnc.

dc42

CanOpen and EtherCat are both possibilities for the future.

CanOpen has far too little bandwidth to use for 3D printing, so we are not using it for communication between the main board and the expansion board. Instead we are using the faster Can-FD hardware specification and a protocol loosely based on UAVCan. But the main board supports a second CAN bus that could be used to control slower devices using CanOpen.

We hope to provide EtherCat master support sometime in the future. EtherCat slave devices require a royalty payment, but master devices do not.

gtj0

Damn. I just bought groceries. I guess I'll have to wait until next month to order.

gtj0

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

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