Expansion Connection Options
-
To continue from a thread on the reprap forums. What sort of connections for external drivers would be useful?
I have half a mind to make a "universal" break out board for the expansion header with spaces for IDC headers, pololu style drivers etc.
Thoughts?
I can see two distinct requirements:
1. Pololu-style drivers - although now that we are using the TMC2660 drivers, I expect there will be much less demand for this.
2. 5V signal outputs for connecting to external stepper drivers to drive more powerful motors. So 3V->5V level shifters on at least the STEP, DIR and ENABLE signals.
Agreed, I don't really see much need for the Pololu style drivers with 5 of the TMC drivers already on the board and the forthcoming expansion board for extra extruders (ala the Duex4).
-
please make the breakout board connectable via standard 40 pin ribbon cable rather than or as well as plug in directly to the 40 pin header.
I play a lot in my other hobby with expansion boards and being able to separately mount them eliminates the strain on the direct connection and provides options in placement/location within signalling limits of course.Otherwise this is a great idea especially for multi axis CNC..
Yeah I would stick to the ribbon cable as we use on the Duex4, although its a 50 pin ribbon cable.
-
I don't know how many are "left" but having some GPIO pins available on the breakout would be good as well.
This is growing from a breakout board to something a lot more expensive! Actually the good thing about having such a capable processor is the number of peripherals and spare pins which allows for the large expansion header. For reference this is the pin out of the expansion connector:
N.B. minor changes may happen to this pinout between the beta and the production boards - not manufacture anything base don this information without checking!As you can see by default most of the connectivity is allocated to a further 5 stepper and heater channels. So without any firmware editing you are able to remap X,Y,Z, onto three of those channels and connect larger drivers.
It would require firmware changes to totally re purpose them however that's the beauty of open source firmware!
-
I don't know how many are "left" but having some GPIO pins available on the breakout would be good as well.
This is growing from a breakout board to something a lot more expensive! Actually the good thing about having such a capable processor is the number of peripherals and spare pins which allows for the large expansion header. For reference this is the pin out of the expansion connector:
…
It would require firmware changes to totally re purpose them however that's the beauty of open source firmware!Ok, I admit, it was a bit of a pie in the sky wishlist.
You are right about the beauty of open source firmware. Almost anything is possible.Having said that, I can foresee folks wanting to use the DuetWiFi for CNC control. For lower powered stepper requirements, the TMC drivers on board will probably do the trick.
-
The "simple" expansion breakout board could be just that, a breakout board for external steppers, with GPIO pins also separated into groups with 5V/SIG/GND headers with 5V tolerance and possibly and opto-isolation. Maybe add some ADC inputs if they are available as well?
-
The "full CNC expansion board" might have all the bells and whistles I suggested in my post above (and more).
-
Then, there's the new Duex4 replacement board.
It would be cool (and potentially safer) to have some sort of indicator/jumper on the breakout boards that identify to the main processor and firmware which board is connected to the big 50 pin header. Maybe even some sort of interlock that doesn't fire up the pins on the breakout board until the processor and firmware are up and running and "happy" and furthermore "aware" of which board is connected.
Thanks to the folks at T3P3 and dc42 for developing this new DuetWiFi board and the firmware! I'm really looking forward to using it to replace my RAMBO board on my Rostock Max V2.
-
-
It would be cool (and potentially safer) to have some sort of indicator/jumper on the breakout boards that identify to the main processor and firmware which board is connected to the big 50 pin header. Maybe even some sort of interlock that doesn't fire up the pins on the breakout board until the processor and firmware are up and running and "happy" and furthermore "aware" of which board is connected.
I am in favour of that. It would allow the firmware to auto-configure at least partially to suit the type of expansion board.
-
It would be cool (and potentially safer) to have some sort of indicator/jumper on the breakout boards that identify to the main processor and firmware which board is connected to the big 50 pin header. Maybe even some sort of interlock that doesn't fire up the pins on the breakout board until the processor and firmware are up and running and "happy" and furthermore "aware" of which board is connected.
I am in favour of that. It would allow the firmware to auto-configure at least partially to suit the type of expansion board.
You could use 2 or 3 of the pins shorted high or low in a bit-wise combination to identify the extension board. Of course that ties up 2 or 3 GPIO pins but it might be worth it. Or put a tiny EEPROM on the extension board that communicates via SPI/i2c to identify itself to the firmware. I'm sure there are other ways to do it too.
-
Yes great idea - start attempting on SPI as the Duex5 will answer on SPI, thenif that does not work try i2c with many options to give a good response. if neither work then assume a "dumb" board and send step/dir/enable "blind".
Tony
-
I guess the only other consideration is whether the things someone might drive with the outputs on the expansion board are active low or active high. I assume most will be active low so there are pull-up resistors within the Cortex M4 that keep things "off" upon startup. Not having looked at external drivers like the Geckos, I hope they would be active low as well.
-
I propose using an 8-bit I2C I/O expander on all the official Duet WiFi expansion boards. This avoids the need to tie up any of the expansion bus signals. Some of the 8 pins to be inputs tied to Vcc or ground to identify the board type. Other pins could be connected to a DIP switch to tell the firmware to behave in a certain way. Any left over can be additional general I/O. And if there is no I2C response at the expected address, default to step/dir/enable as Tony suggests.
-
I like the I2C I/O expander idea. That takes care of things nicely and is probably a cheap add-on.
We actually just used one of those on a project at work. We ran into some issues with hot plugging between boards and probable ESD damage to the chip. Since these expansion boards won't really be meant for hot plugging, that shouldn't be an issue. We were able to "fry" the chip when we did some +/- 4kV safety testing on some connected LEDs on a membrane user interface. Again, probably not an issue on this type of board. Not sure how sensitive the rest of the stuff on the Duet Wifi board is, but I assume you've already dealt with this to some degree. Just wanted to raise a flag because we were recently "burned" by an I2C I/O expander.
