Duet 3 first-generation prototype giveaway

[dc42]

We have a small number (probably 2) first-generation Duet 3 prototype main boards (as demonstrated at TCT last year) that we no longer have a use for. We propose to give them away (we may charge for carriage). Before you get too excited, please note that I will not be maintaining firmware to support them, so you will have to maintain the firmware going forwards.

The brief specification is:

• Six TMC5161 drivers, probably good to around 4A peak stepper motor current with fan cooling. The TMC5161 chips are engineering samples and we know that Trinamic has changed the design since then, so may not be as reliable as production chips, therefore you should not rely on all 6 continuing to work.
• Both WiFi (with separate antenna) and Ethernet. The WiFi works. The Ethernet probably works - I haven't tested it since implementing the firmware fix that got Ethernet working on the second generation prototype. Some of the boards will probably need a simple hardware mod to get Ethernet working.
• One high current output (bed heater).
• Three medium-current VIN-voltage outputs (intended for other heaters).
• Six low current VIN or external voltage outputs, of which 3 intended for 4-wire fans, 3 intended for 2-wire fans
• Nine low voltage I/O connectors for endstops, filament monitors, Z probes etc.
• PanelDue connector
• SPI daughter board connector, for our standard PT100 and thermocouple daughter boards
• SD card socket
• CAN connector, compatible with Duet 3 expansion boards
• 4-pin Raspberry Pi connector
• DotStar LED strip connector

The main difference from the later prototypes is that this board was designed to be capable of running standalone, without an attached Raspberry Pi or similar single-board computer. It has a 4-pin Raspberry Pi connector, but it hasn't been tested and the current firmware for this board doesn't support it.

We will consider giving these boards to forum members who satisfy the following criteria:

• You are an established user of Duets, comfortable with using bleeding-edge firmware;
• You are comfortable with building RepRapFirmware from your own github fork. I currently have a build of RRF 3 for these boards, but I haven't tested it for a while.
• Enough firmware experience that you can make changes and debug problems.
• Ability to make minor hardware modifications to the board.
• A compelling application for this board that makes it more suitable than a Duet 2.
• A willingness to buy a production Duet 3 board in the long term, to replace this board if/when it fails or when you get fed up with maintaining a special firmware build for it.

We will provide you with the schematic of the board under Non Disclosure Agreement. The NDA will expire when we release Duet 3.

If you are interested, please send me a short PM me explaining why we should give you one of these boards. I do not promise to reply to each PM, in case there are a lot of them! We will decide who gets these boards around one week from now and I will announce the lucky winners here.

[minim]

Nice gesture

[BLV]

@dc42
Nice, I Would like to test it too on my BLV mgn Cube project and adapt it to the project
I tried to send you p.m but you are on DND mode ..

[dc42]

I'm online now.

[BLV]

@dc42
And again offline
from some reasone, I can't send you a p.m

[A Former User]

I can only imagine the Duet guys need some time off with seemingly working around the clock all week. Surely it can wait til Monday, got a whole week before they decide.

[dc42]

@BLV, would you like to post your case for receiving a board here instead? It looks like whenever I don't access the forum for several minutes, it marks me as offline.

[DocTrucker]

I've been trying to set up a SAME70 XPLD board to work with a RADDs board but think maintaining a firmware binary of the Duet 3 firmware would just be a case of keeping the a pins file set up for this board is that fair @dc42?

Alas I don't think my machines really warrant a duet 3 yet! The on paper idex core xy would do but expect the duet 3s to be a few minor revisions in by the time I'm ready!

[nophead]

What is the timescale for production Duet 3's? I am designing a machine that has some CAN peripherals but I won't finish it anytime soon.

I like the idea of a small firmware that just does the realtime stuff and the rest on an SBC in Python. That is how my early machines work, including HydraRaptor and the very first Mendel90.

[DocTrucker]

@nophead said in Duet 3 first-generation prototype giveaway:

I like the idea of a small firmware that just does the realtime stuff and the rest on an SBC in Python. That is how my early machines work, including HydraRaptor and the very first Mendel90.

No real detailed research went it to using python over anything else but it's how I set up the metal sintering (edit: melting) machines for MCP/MTT/Renishaw. Hardcore realtime stuff for the lasers through the API/application for the scanners and less time dependant stuff through the PLC controllers.

No complaints about the python though and it can be really powerful on the text file manipulation. Finally dusting off my coding hat with trying to sort out the python side of the Ciclops scanner and attempting to get RepRapFirmware on a dev board. Anyhow I digress.

Still need to read through that monster background reading file that is on the reprap site.

[Cata]

@dc42 said in Duet 3 first-generation prototype giveaway:

this board was designed to be capable of running standalone, without an attached Raspberry Pi

[Slidex]

Good luck to the guys that get these boards, just been setting up my Wifi 2, awesome board, great job

[fma]

@nophead said in Duet 3 first-generation prototype giveaway:

I like the idea of a small firmware that just does the realtime stuff and the rest on an SBC in Python. That is how my early machines work, including HydraRaptor and the very first Mendel90.

It's the Replicape approach.

[dc42]

@fma said in Duet 3 first-generation prototype giveaway:

@nophead said in Duet 3 first-generation prototype giveaway:

I like the idea of a small firmware that just does the realtime stuff and the rest on an SBC in Python. That is how my early machines work, including HydraRaptor and the very first Mendel90.

It's the Replicape approach.

Speaking as an experienced real time systems engineer, IMO it's a very bad idea to have the motion planning written in an interpreted language, running on a processor running a non-realtime operating system, that is also doing many other tasks.

The Duet 3 approach is to do just the initial GCode parsing on the single board computer, send them to the Duet 3 main board over a dedicated bus (not a shared USB), do the motion planning on the Duet 3 main board running under RTOS, and do the step generation on the main board and the expansion boards.

[fma]

You are right. I owned a Replicape, and was not really satisfied. That's why I switched to the Duet

On the other hand, if we drop Python, using C under linux is a good way to go, and works fine: LinxCNC is a good example. It needs a (almost) RT kernel, though.

[nophead]

@dc42 The motion planning does not need to be realtime, only the actually stepping of the motors. As long as the data is produced fast enough to keep a buffer full it works. I sent trapezoids to my real time code encoded as a list of step durations during the ramps, the constant speed step duration and the total number of steps. My reatime code just did the Bresenham loop. Never had to change in more than 10 years and only needs a tiny 16 bit micro.

[DocTrucker]

The speed difference between good and bad python scripts is also stunning.

[nophead]

Yes but it doesn't need to be fast because 3D printers are very slow. Even a slicer written in Python runs many times faster than the printer that prints the result.

[DocTrucker]

@nophead yes. I took slice data for 50 mircron layers for the laser machines and in most cases break the vectors down into a sequence of points around 50 microns apart while the system was inerting and while another process was running the laser/galvo control card. It did fall over with lots of little sections from time to time.

I wanted to look at setting a a parameter file for build on these systems and slice individual layers direct from STL on the fly for similar reasons to what you state. Nothing ground breaking but would tidy uo a lot of things like parameter change on the fly and killing parts that are failing.

Edit: This parsing on the fly could also work to get rid of a lot of timy vectors that some of our slicers make, which can cause issues.

[dc42]

Exactly so. Just because the average speed of the slicer is faster than the printer, that doesn't mean that you don't need real-time performance for the critical parts - in particular, curved perimeters. A perimeter printed at 80mm/sec with a resolution of 0.2mm equates to 400 segments per second. Doing the motion planning for that demands real-time performance.