Duet 3 first-generation prototype giveaway
-
@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
-
@ffnull just curious, what advantage you will have by doing a duet conversion? My 430 is on the way and I happen to have a duet 2 board in hand.