Additional external drivers (12-13?)
-
The end stop pins correspond with E3,E4,E5 end stops which I am using – I see there CS pins on the DueX5 --
If I'm reading the pinouts right, the temp daughter board on the Duet corresponds to CS0(56) ,CS2(50),CS3(51) ,CS4(52)
and the temp daughter board on Duex5 has CS5(24),CS6(97),CS7(98),CS8(99) -- the 97-99 pins appear to be shared with end stops? -
If you have a DueX2 or DueX5 fitted then endstop E3 to E7 are routed through the I2C interface instead, and the expansion connector pins labelled E3 to E7 are used for CS pins and one other function.
-
I decided to give this a go, and I defined everything in the Ping_DuetNG.h and Platform.h -- I am testing just #12 and when I tell C axis to move -- I see the stepper get enabled, but it doesn't move. I tried different combination of CS pins, but none of them cause the stepper to move -- I haven't checked the step signal with the scope, but I'm wondering if I'm missing something simple.
-
In addition to setting up the extra pins in Pins_DuetNG.h, there are three functions at the very end of Platform.h that need to be updated to allow fast stepping. It's easiest and fastest if the additional step pins are on Port D like the rest of them.
-
yes, that worked -- to keep things simpler i'm just going to use port D and C - the thermocouple port on DueX5 CS pins go to Port E -- so 14 independent (technically I have 16, but there are 2 which run parallel of the LCD port as each of my Y axis uses 2 steppers) -- wohoo! --- Quad independent extruder printer with quad lead screw compensation.
wonder how much of a penalty applying the map to 2 ports vs 1 is... I doubt with the size of my machine I'll ever reach those ludicrous speeds.
-
@kazolar pics? Sounds awesome!
-
@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'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.
-
@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.
-
@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.
-
We're working on the next generation Duet and that one should support 20+ stepper drivers.
-
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. -
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?
-
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
-
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.
-
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
