Coupling multiple Duet 3
-
If you are running everything with one program (gcode file) then I would think one Duet 3 with many drivers (expansion boards) would be the way to go. With the CANBus setup multiple drives shouldn't be an issue.
-
For running a printer farm, a better option may be to use Ethernet to connect all the Duet main boards to the farm controller.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Is it technically possible to connect multiple Duet 3, i.e. is CAN FD capable to join them (I have no knowledge of CAN yet, whether it is a master-slave concept etc.)? Ethernet is an option of course.
-
My post here is all pretty much opinion; only DC42 'owns' the future strategy of Duet.
Technically, the hardware will pass messages bi-directionally. So any scheme of cooperative processing could be built on that.
Several of the use cases you mentioned boil down to 'expansion', where "expand" is defined as gaining driver outputs, or heater, or fan outputs, or sensor inputs, and so on. A Duet 3 "main" board seems to be a very expensive way to "expand". True expansion (3 channel) or tool (1 channel) boards make much more sense.
The other use cases you mentioned boil down to 'cooperative processing' between peer controllers. Again, just my opinion: That strikes me as an extremely complex way to accomplish goals that are easily accomplished, and much better served, with one central controller, with additional channels on expansions if required.
Example: Printing and CNC "at the same time". What you are really talking about is multiple tools working on the object in parallel in real time. That has already been done, in a small way, in Duet/RepRap. Things like a fourth "extruder tower" for Delta printers.
These uses cases share a requirement for coordinated motion; this would be hideously complex for two cooperative controllers. Not sending the signals down a CAN bus... that is easy(ish). Think about the motion planner in the two controllers. How does controller "A" plan a given move to arrive at the completion point on all parts of the move if it has no idea what controller "B"'s planner is calculating? That kind of move really needs to be planned as a whole. Which means there has to be a "master" planner. Which means the other boards might as well be expansions... right back to the "using a main board as an expander" doesn't make sense.
Long post... and just my opinions as an embedded firmware designer, who considers himself to be just a tiny fraction of the people, like DC42, who are masters of the core of these things. They may head in the exact opposite direction from what I'm saying above.
But just as a closing thought, have you looked at the underlying architecture of Klipper? Thinking through how it really works is quite illuminating when thinking about how to allocate hardware resources in a multi-board, modular, environment.
Delta / Kossel printer fanatic
-
@Danal Thank you for your long post of your thoughts. I agree in some of your arguments and will take a close look to Klipper. I already started doing so, following an idea to analyze different firmwares and looking at the algorithms used and how they differentiate. Mainly to learn from the source.
The reason why I asked for assembling multiple Duet 3 and having flexibility of using external drivers in the other thread, and Multi Scara is to have a place to have 3D, CNC, finishing (sandblasting?) and QM (camera controlling the results for correction, with AI NN) station which produces a thing completetly.
I thought, the processing power needed is too high for one 300 MHz MCU. But I agree with you that one powerful processor, in this case some a powerful SBC (more powerful than Raspi) could be better and cheaper approach.
The coordination of the different parts above can be the the-planner-knows-all-and-coordinates approach or an autonomous-actors-avoid-collisions approach. I'll have to think about which one is better. In both cases I see no finished firmware around (especially for the QM ideas), so a lot of work...
The QM idea is to automatically control every layer, stop printing if there is an error, remove the faults with abrasive methods like routing, and then proceed. I am sorry about the countless failed prints due to the few defects somewhere in the print.
One aspect is, when using a powerfull SBC and using only one Duet 3 with multiple expansion board, is it possible for the Duet 3 to support different kinematics at the same time (e.g. Parallel Scara for 3D, Robotics 5 Axis for QM camera and Cartesian for router)?
-
@Danal said in Coupling multiple Duet 3:
My post here is all pretty much opinion; only DC42 'owns' the future strategy of Duet.
a side note. the duet firmware is released as open source. you can create pull requests or fork the firmware.
as you are experienced in embedded software, i am sure any contribution would be appreciated. -
@JoergS5 said in Coupling multiple Duet 3:
@dc42 Is it technically possible to connect multiple Duet 3, i.e. is CAN FD capable to join them (I have no knowledge of CAN yet, whether it is a master-slave concept etc.)? Ethernet is an option of course.
On the Duet3 MB6HC v1.0 it's technically possible to connect multiple main boards together using the secondary CAN bus. The primary CAN bus has on-board termination, so unless you removed the termination resistors, you couldn't connect more than two main boards (one at each end of the chain) using the primary CAN bus.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Thank you, I can plan with this information.
-
@JoergS5 said in Coupling multiple Duet 3:
The QM idea is to automatically control every layer, stop printing if there is an error, remove the faults with abrasive methods like routing, and then proceed
That is "serialized" and certainly won't overload an MCU. I see little difference in accomplishing that via a bunch of channels (main+expansion or tool) vs. multiple peers.
I'm thinking more toward coordinated motion. That's where I'm concerned that a autonomous-actors-avoid-collisions approach doesn't work. Coordinated motion.
-
@Danal I agree with you. With one exception: QM will need more power than the MCU. I think a comparision of the STL model (up to the current printed layer) with the printed result needs some computing power.
-
@JoergS5 Yes but that does not need to happen in real time, just around about the same time.
