Additional external drivers (12-13?)

kuhnikuehnast

@dc42 said in Additional external drivers (12-13?):

If you really need to control all the stepper motors independently, then you will either need to hack the firmware to re-purpose some pins, or wait for the next generation Duet.

When will there be a release? Is there anything on the horizon?

kazolar

I've decided to CNC a PCB for all the external stepper drivers. I got the parts for the 2 additional Z axis lead screws today, the new beefier 3/8" tooling mic6 plate is scheduled to arrive next week, I've had to also re-order a new silicone heating pad -- going up to 1200w now. So I've created a good bit of work for myself -- in what was already a well functioning machine.

dc42

@kuhnikuehnast said in Additional external drivers (12-13?):

@dc42 said in Additional external drivers (12-13?):

If you really need to control all the stepper motors independently, then you will either need to hack the firmware to re-purpose some pins, or wait for the next generation Duet.

When will there be a release? Is there anything on the horizon?

I don't intend to include this in the standard release, because the signals that @kazolar has repurposed normally have different functions, and the changed to the step pulse generator functions will have a small negative effect on maximum step rates. Very few users need to drive more than 12 stepper motors independently.

kazolar

@dc42 I agree, this is very much a hack -- I've disabled the thermocouple ports -- and altered the step functions. I appreciate the help, and I'm pretty sure I'm on the bleeding edge of what is remotely possible on any controller.

dc42

We're working on the next generation Duet and that one should support 20+ stepper drivers.

kazolar

That will be more than welcome -- any time-table?
I've taken my circuit to expand the duet and duex5 to the 16 steppers and decided to make it proper -- I needed to have the 2 Y axis steppers in sync -- otherwise the Y axis gantries don't stay parallel, so I made a circuit to skip step pulses when the specific end stop is triggered (and the stepper is moving toward the end stop) -- logic gates -- and the end stop signal going to the duet is a logic and of the 2 end stops -- so duet keeps sending step pulses until both end end stops trigger -- and instead of having 1 stepper bang into the end stop -- even when triggered, it stops receiving step pulses when the end stop is triggered -- it makes more sense on a circuit diagram.. so I ended up taking this combo logic gate circuit and a few other bits and put together a board with 4 end stop inputs, 2 end stop outputs, and 6 stepper driver outputs -- and 3 of those 10 pin headers -- so I can make a clean connection to the duet expansion pin sets -- LCD-CON, and the 2 CS pin headers (on duet and duex5) -- I was planning to mill out the board myself, but I ended up making it to complicated, so I am having it made by jlcpcb. I am going to have 5 of them though -- so ... not sure if anyone will want to use something like this.

kazolar

David, can you help, think I'm doing something wrong with the platform.h code. I got it working independently, but then it's weird, when everything is homed, stepper 10 and stepper 13 want to move together for some reason. I'm using CS4 as the step pin for stepper 13 and CS3 as step pin for stepper 12, no issues that I can with stepper 12, but I think I have something wrong with the step code. Is cs4 overlapping with something in the c bank with the d bank?

kazolar

Looks like cs3 and cs4 are conflicting with step pins for drive 10 and 11. Cs2 appears to work, but cs0 doesn't - it appears cs0 is needed for SD card access. So after a lot of digging I figured that z probe mod pin (34) works as a step pin, since I'm using a bl touch I am not using that pin for anything. So looks like the 14 stepper plan will work, just not using the pins I envisioned

dc42

CS3 and CS4 are PC19 and PC20. The existing step pins are PD0,1,2,3,4,5,6,7,18,19,20,27. So the bit numbers for both port C pins you have chosen clash with the bit numbers for port D pins. I suggest you shift the two port C bits left two positions to avoid the clash. See the code for Duet085 or RADDS to see how this can be done.

kazolar

I was shifting 1 position, wasn't enough, and then I ended up changing the bitmap type to uint64_t -- and shift all the way 32 bits -- that way there is no way to create a clash -- I assumed that's what was happening -- I was just trying to find a way out of having to hunt down everywhere the bitmap is used -- but it wasn't that hard. This works fine now. 14 drivers -- all setup