Dual or multiple Duet 2 / Duex boards communicating

Jabbery

Hello,

We are working on a prototype that has a need for a lot of stepper motors / heaters and end stops. I'm sure there are many with that need. We have been looking into the source code to see what could be possible and may have found a way but it could be a large can of worms for us to add due to not being intimately involved in the code.

The thought of course is use one duet2 as master (with or without a duex) and multiple duet2 as slaves. The duet2 slaves would simply receive gcode commands from the master on non timing critical functions. For example Z home or any Z move since Z moves are always (??) command and wait for completion and not timing critical like X/Y/feeders.

There are a fair number of not as critical functions like heaters, fans etc that would be under full control at the slave board and not really require high speed monitoring by the master since the slave has it under control.

On items like the Z axis completely moving to a slave since I think it is non timing critical a series of verification commands would ensure movement and error handling like get position, cmd move, wait for complete, as position, verify it moved then continue tools for next layer. Z hop could send Z move during retract and not wait until after retract due to the communication delay to not hugely effect time.

The commands could be handled over ethernet by the slaves via http cgi scripts, or telnet, http has a bit easier report handling but of course a bit more overhead.

The master duet could handle all the configuration with device configuration adding slave address/user/password and would simply if there is addressing pass through the command to the slave when called.

Of course anything on ethernet can be a mess with external forces that could be overcome with a smart switch and placing the master and slaves on a vlan, even a passthrough or proxy host could be added for outside access.

Has this been tried?

elmoret

How many stepper motors are you looking to control?

Jabbery

in our prototype/proof of concept 15 each with its own home switch, this would have 6 heaters. 3 steppers are X/Y

in our full build it would be 28 steppers with homing and 18 heaters. 3-7 steppers are x/y, 14-16 heaters

elmoret

Duet + Duex5 + 2 external stepper drivers can do 12 steppers

IMO, if you need more than that, you need either a really convincing case, or a different design approach.

Jabbery

Since we are building a prototype and proof of concept I'm not thinking there is any remotely convincing case other than is other people looking for similar needs to drive the case.

An option I did not mention is to turn all duet/duex into slaves and drive them with gcode only via a custom middle man. A concept like octoprint but build to deal with command parsing to different slaves. That is fairly easy I think but does require more expense since another processor board is needed with a couple of ethernet ports to isolate the slaves.

I have not seen any data on how to connect the "extra" 2 stepper external drivers. Although 4 external drivers likely cost as much or more than another duet that has 5 drivers on it.

dc42

What you need is Duet 3. Is this a one-off machine, or something you plan to manufacture? What is your time scale for building the prototype?

Connecting two DuetX5s to a Duet would be possible, but you would have to be quite creative in how you connect the second one to the Duet. It would also need minor firmware modifications. How much experience of electronics and firmware does your team have?

Jabbery

Hello dc42,

Thanks for the response.

The prototype build is underway and once complete assuming we can work out all the hurdles we will start manufacturing it in a few different models. We have been working on the prototype for a number of months and feel we can get it to operational in 30-60 days.

Firmware updates are something we can normally handle the concern is not ability it is duration to take everything apart, learn it well to be able to modify it properly without messing up other modules. The possibility of course is with some direction and information of the area that is "safe" to modify without messing up other modules. Electronics talent is a bit weak not non existent just weak. We planned to leverage duet hardware since it was already developed and has the best possibility to handle our needs. You got my interest on a second duex 5, this would get phase 1 completed with what sounds like less effort.

I have been reading what I could find on the duet 3, sounds like it is a ways out yet with testing can bus and its different versions to get effective control speeds in the communications. Part of my thoughts was on how the duet 3 code was written to handle movement of data to slave boards and was a possibility that part of the needs were there already with a different interface that would need to be changed.

dc42

The Duet 3 prototypes already handle multiple slave boards, so 15 stepper drivers in total would be no problem (6 on the main board + 3 expansion boards with 3 drivers each). The use of CAN for expansion is completely transparent to the user. However, we have only a few prototype expansion boards at present, and it's likely to be a few weeks before we manufacture another batch of prototype or pre-production boards.

We demonstrated controlling 6 motors locally and 6 over the CAN bus last September at the TCT show. See https://www.youtube.com/watch?v=LaNYeQiZK9M. The motor movements in that video were commanded by ordinary GCode commands.

To connect 2 DueX5 boards to a Duet, you could construct an interface board with three 50-way and one 10-way ribbon cable headers. Then the Duet CONN_LCD and expansion connectors would be connected to this interface board, and the two DueX5 wold also connect to it. Once of the DueX5 would be connected straight through to the Duet expansion bus (so alternatively, you could use one ribbon cable with 3 connectors on it to connect the Duet, interface board and one DueX5 together, and only have two 50-way connectors on the interface board). The other DueX would take some of its signals from the expansion bus and some from CONN_LCD.

You would need to find 9 free microcontroller pins to drive the Step, Dir and CS signals for the last 3 drivers on the DueX. If you are not using temperature daughter boards on either of the DueX, then you can start with the 4 CS signals. If you don't need the two endstop connections on CONN_LCD, that gives you 2 more. But you still need to find another 3 from somewhere.

I could give you help in adapting the firmware, but you would need to integrate future changes into it yourself.

dc42

PS - I just saw that you need a lot of endstop switches. That makes it harder to do using Duet 2 even with just 15 stepper drivers. The full version with 28 drivers definitely needs Duet 3.

We need some beta testers that use a lot of stepper drivers, so we might be able to spare you a Duet 3 prototype; however the next run of expansion boards will take a few weeks to do.

Jabbery

Yes I was just reading your previous post thinking we have an endstop for each stepper. We could on some of steppers use stall detection but I'm not sure we could take that to production.

I don't think a few weeks would hurt to wait, currently we have a stack of raspberry pi's/odroids etc handling a few steppers/end stops manually controlled with buttons for testing.

When do you expect the duet 3 goes into full production? Or more important when do you expect it to be available to go into a production device?

dc42

We expect Duet 3 production to start in late Q2 or Q3 this year. We have second-generation prototype Duet 3 main boards already, and we expect the production boards to be almost identical to them.

Jabbery

That falls in line with our schedule. Do you have a list of supported items for the main board and available prototype slave boards? Depending on what is currently supported in prototype we may have to adjust our prototype to fit and that should be learned sooner rather than later if possible.

Also is there any current weaknesses in functionality compared to the Deut 2 functionality.

dc42

Duet 3 will offer a lot more functionality than Duet 2, although it may take a few months before all of it is implemented in the firmware.

The prototype main board have 6 stepper drivers, 4 thermistor inputs, 10 heater and fan outputs (6 low current, 3 medium current, 1 high current), 9 I/O connectors that can be used to connect endstops, Z probes, filament monitors etc., 1 servo output and one LED strip output. The prototype expansion boards have 3 stepper drivers, 9 heater and fan outputs (6 low current and 3 medium current), and 6 I/O connectors. Both boards also accept up to 2 of our PT100 and thermocouple daughter boards. Multiple expansion boards can be connected to one main board.

Jabbery

Wow sounds nice.

You mentioned 10 heater and fan outputs on the main board, is that 10 heater and 10 fan or 10 total for heaters and fans?

dc42

10 in total.

Jabbery

After a couple of very long days I'm not sure what I was thinking asking that question.

How do you suggest we proceed with the duet 3 prototype?

dc42

@jabbery, I'll respond by email.