Duet 3 Mainboard 6HC - initial production run.

A Former User

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

deckingman

@t3p3tony

Tony, there is a bit of a conflict in the documentation https://duet3d.dozuki.com/Wiki/Duet_3_Mainboard_6HC_Hardware_Overview.

The picture of the boards has a graphic with the words "6x stepper drivers rated to 4A peak". But under "Features" the words say "Six high-current advanced TMC5160 stepper drivers: SPI controlled will all the latest Trinamic features. Maximum motor current 6.3A peak per phase (4.45A RMS)."

As DC ran the thermal tests on an expansion board at 6.3A, I'm assuming the "4A" in the graphic is incorrect.

Phaedrux

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

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

You may want to take a look at Mono for .NET. Microsoft has been putting a lot of effort into bridging the Linux gap in the last few years.

gtj0

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

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

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

You may want to take a look at Mono for .NET. Microsoft has been putting a lot of effort into bridging the Linux gap in the last few years.

Yeah, I've used Mono for running .NET assemblies for quite a while. The Microsoft .NET Core for Linux is also working fine. I just can't stand Visual Studio. Actually, the Acute plugin for Eclipse is at least workable for editing C# and I just built the DSF for both arm and x86_64 so maybe it won't be that bad. I might not even need to modify it for the Wandboard, just set the device paths in the config.json file. We'll see.

wilriker

@gtj0 There is also MonoDevelop as an IDE. And the apps are actually based on .NET Core and as such do not need Mono (if anyone needs more recent packages of .NET Core on Arch Linux I have them in my Dropbox ).

EDIT: one of these days I need to look into finding a good Language Server for C# and then I can develop in neovim.

A Former User

@t3p3tony

I think a connector/plug pack should be included as a mimimum, if not included in the duet 3 anyone who has experienced what is included after purchasing earlier iterations of the duet ecosystem is going to feel mighty cheated to have to go source connectors and plugs themselves after shelling out for the duet 3 and an sbc

dc42

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

@gtj0 There is also MonoDevelop as an IDE. And the apps are actually based on .NET Core and as such do not need Mono (if anyone needs more recent packages of .NET Core on Arch Linux I have them in my Dropbox ).

EDIT: one of these days I need to look into finding a good Language Server for C# and then I can develop in neovim.

Don't forget that .NET supports other languages apart from C#, in particular F#.

wilriker

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

Don't forget that .NET supports other languages apart from C#, in particular F#.

Then there is J# and VisualBasic... Wasn't there also a Q#? Way too many Sharpies. If I have the choice I'll stay with my beloved Go, though.

EDIT: it seems neither J# nor Q# (actually for quantum computing) are supported by .NET.

gtj0

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

@gtj0 There is also MonoDevelop as an IDE. And the apps are actually based on .NET Core and as such do not need Mono (if anyone needs more recent packages of .NET Core on Arch Linux I have them in my Dropbox ).

EDIT: one of these days I need to look into finding a good Language Server for C# and then I can develop in neovim.

MonoDevelop doesn't support .NET Core projects using .csproj project files. It complains about the project file not having a ProjectGuid.

BTW, I have a Wandboard loaded with Fedora 30 and SPI support running the DSF. No changes to the DSF needed but then I don't have a Duet3 board to test with

T3P3Tony

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

@t3p3tony

Tony, there is a bit of a conflict in the documentation https://duet3d.dozuki.com/Wiki/Duet_3_Mainboard_6HC_Hardware_Overview.

The picture of the boards has a graphic with the words "6x stepper drivers rated to 4A peak". But under "Features" the words say "Six high-current advanced TMC5160 stepper drivers: SPI controlled will all the latest Trinamic features. Maximum motor current 6.3A peak per phase (4.45A RMS)."

As DC ran the thermal tests on an expansion board at 6.3A, I'm assuming the "4A" in the graphic is incorrect.

Thanks Ian - its fixed now

T3P3Tony

@calvinx Thats the plan - just see if we can get them sorted in time for this initial batch.