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?

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?

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.

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?

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.

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.

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

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?

Nice, your a savior

It was the old hightmap, I removed it and X/Y axis is running normal. I also moved the G29 S1 to the homeall.g and homez.g .

Thanks very much everyone for your awesome assistance.

I don't think I could express my appreciation enough for all the help. Thank you for the suggestions.

I am running a 20mm cube test and thought I would let it complete, its inside the 75 x 75 coords so it prints. When I ran the test and aborted it earlier I seen another problem with some issue of the feeder was having trouble pushing filament, I found a burr in the new hot end I installed (heat break).

I will do that test shortly, the heightmap is actually there and it is from the removed inductive probe so it is very wrong.