Duet 3 first-generation prototype giveaway
-
@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.
-
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.
-
@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.
-
The speed difference between good and bad python scripts is also stunning.
-
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.
-
@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.
-
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.
-
@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.
-
@nophead What are the best reads for the various approaches to motion planning or is it all very scattered?
-
@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.
-
@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?
-
@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.
-
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.
-
@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.
-
The discussion about realtime vs non-realtime can be a catch 22, but generally I agree about having only stepper control in real-time. I've got quite a bit of desktop application development experience and I've been learning the RepRapFirmware for around 6 months now as a hobby to do some custom things to my printer. To be entirely honest there's not enough resources on such machines. Even if you do find the resources, you end spending more time and the code ends up hard to read and debug. I'd much prefer non-realtime planning, well, on an actual OS and CPU with RAM, including some actual development tools. Pardon if it's a bit harsh, but debugPrint is not the way of the future. In any case, I really appreciate the amount of features made possible so far.
-
Where can i get it? I have a project for a giant corexy.
-
@zapta said in Duet 3 first-generation prototype giveaway:
@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?
Sorry I missed this question a month ago.
My machine specific configuration is simply expressed in Python files, rather than encoded into dozens of cryptic gcodes. When I process the machine agnostic g-code tool path from the slicer I apply the machine and filament specific speeds, accelerations and temperatures, etc, before sending binary packets to the actual machine.
I never modify anything on the fly though. I have never felt the need. When I start a print job it is usually from another room. I tend to look via camera to see if the first layer looks sane and then I wait for it to finish. I don't interact with my machines other than to clear the bed ready for the next job, or change the filament. I run a separate python script to do the latter.
-
Hello. I am an experienced user of your products. I already have 4 boards on hand and ordered another one with all the additional options. I will be glad to receive a prototype for changing the motherboard in CreatBot F430
-
dc42 said in Duet 3 first-generation prototype giveaway:
We will decide who gets these boards around one week from now and I will announce the lucky winners here.
may be a tad late? 6 Jul 2019
although haven't seen any announcements
-
Nice, I Would like to test it too on my SCARA project and adapt it to the project
