Duet 3 first-generation prototype giveaway

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.

nophead

@dc42 No it doesn't because motion planning does not depend on real time input, so it can be done in advance. I process all of the gcode on my PC, or an RPI, before the printer starts moving. and then send trapezoids to my firmware using Ethernet.

Do you know that the Glowforge laser cutter does all its motion planning in the cloud and sends stepper motor waveforms for the whole job over http? Crazy, but it works.

DocTrucker

@nophead What are the best reads for the various approaches to motion planning or is it all very scattered?

nophead

@doctrucker I don't know. I don't read many books. I did spend 30 years writing real time embedded software though before giving it up to make 3D printers and then retiring.

zapta

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

No it doesn't because motion planning does not depend on real time input,

How do you handle motion related configurations that are done at the printer's level? E.g. from config.gcode? Do you feed them to the off line planner?

DocTrucker

@nophead it was a genuine question following your name drop on the 'Bresenham loop', which I will look up. My question wasn't intended to put you on the defensive. Likewise most of my tricks have been learnt on the fly rather than a single source but it was worth asking.

dc42

How does offline planning handle changes in extrusion factor? Or changes in speed factor without violating acceleration and jerk limits? Or pause and resume? Not to mention other dynamic changes that are useful when tuning the printer, such as changes to pressure advance, jerk, acceleration etc.

DocTrucker

@dc42 we prepared a buffer of slices and if the user made changes these were applied a few slices ahead of the systems current position in order to avoid any stutters.

Edit: We also weren't processing right down to step sequences, just doing any coding that required a measure of look ahead or geometric correction. Essentially we cleaned the slice data and simplified it.