would you suggest staying with the built in motor encoders as a first round?
I would. The ESP Encoders require extra hardware to position them and they need to be linearized
If you make one that supports 5 or 6 motors, Iām in for one. Need something to drive dc motors in a robot arm 
1 Like
probably a good idea, just for cost. Having the option to have RS422 connected
encoders instead of quad encoders is good, but if you require such encoders you
make it so you have to use different motors for the new board, and thatās going
to reduce the number of people who use/test with it.
David Lang
One other option is to look at using a lower-cost version of the Tarocco. Itās probably cost prohibitted as it is, but itās open sourced, and if you could build three cost effectively, it would allow you to use bdringās external stepper motor drivers with one of his esp32 CNC controllers with all the other bells and whistles already there. Assuming the Taracco design is up to the task, then you could just include the kinematics into GRBL rather have to build in the motor control.
1 Like
Yeah pretty much. I didnt know how far bar had gotten yet. Hopefully mine will have fewer (or zero) mod wires 
I also want to have power supplies, and SD card on the board. And maybe that Z-axis stepper driver I mentioned. More of a finished board design than a prototype.
@bar what are those ICs I see on your board? Are they the AMS encoder chips or motor drivers?
I see calibration as being a part of ESPControl (or whatever it ends up being named) which will be running alongside GRBL_ESP32. Anyway, software stuff can get figured out later.
Iāll see how many GPIO are left since that is the major limiting factor on the ESP32. If we can get up to 5 motors, it will future proof the controller against 4-chain setups and allow you to use it for other nefarious robotic purposes 
Yeah, I have already pondered a āthrow more microcontrollers at itā approach like this. Make the DC motor look and act like a stepper. I just donāt think it will be that difficult to get GRBL to use DC closed-loop in a similar fashion.
1 Like
Bar was using an LED driver chip for the current source.
There is a TLC59711 chip and 5 DRV8873ās run the motors.
1 Like
@Orob is correct 
If you want to see a full schematic for that board there is one here:
So I started drawing up a schematic today and was counting out how many pins we have.
There are 25 GPIO pins on the ESP32, 2 of which are the serial (programming) port
Each DC motor driver costs 4 pins and we need 3 at a bare minimum.
This leaves us with 11 pins to choose for everything else.
I want an SD card on there. The highest performance option is the SDMMC ports which costs 6 pins. Otherwise we could just go with SD over SPI which costs 3 pins.
Many users have stuff on the AUX pins, but I dont know if anyone is using more than 3.
My plan is: SDMMC (6 pins), and 5x AUX (5 pins) - should be full compatibility for 2 chain setups with fast SD card
If we needed to do 4 chains, I believe the simplest would be: SPI SD (3 pins), 1 more DC driver (4 pins), Z axis encoder only (2 pins), and an I2C GPIO expander (2 pins) - gives 4 chains, SD, low performance Z axis which is probably okay, and whatever AUX is left. Ideally we would have a third pin on the GPIO expander to signal interrupts, but we dont have any pins left.
Anyone feel strongly that 4 chains is a must at this point? Or should I just go with the first option?
4 chains would be nice, but there is no software to support it yet.
but I think even a low performance SD card will be far faster than we need
whatās the difference in cost?
David Lang
No price difference - it is merely a difference in how you access the same SD card.
The short story is that SDMMC transfers 4 bits per clock while SPI will transfer 1 bit per clock. So, at the same clock rate, SDMMC will transfer 4x the data.
All but the slowest of SD cards would see a performance boost with SDMMC. However, like you said, we should be fine with SPI speeds. The question is, what would you do with the 3 pins that were freed up?
Madgrizzle said he was interested if it had 4 or more motor drivers. This could be a platform for more than just maslow, but If you are looking for a rev 1 to get started to get something in the hands of developers to make something work you could do just 3, but Iād say live it up and go 4. If you go with the LED current driver that Bar was using, it is SPI as well, so you could actually use fewer pins per motor. The slower SD card should be fine, but Iād really like a provision for an LCD or display and even an encoder button wheel for local jog and job selection (think 3D printer HMI).
I donāt think thereās a requirement to support four motors at this time. Two motor setup I would think would be a good start.
Keep in mind that not all of the pins which look available on the ESP32 are actually useful. Hereās a quick guide which someone posted a while back which I thought was helpful:
Whoops I just realized SPI takes 4 pins, so the second option above doesnt quite work. Iām sure we can figure something else out if we want to go with that.
Hey @bar have you gotten any firmware working on your experimental board? Have you seen any issues related to latency of the I2C (which has to be scheduled through the OS, I believe)? That is the biggest reason I am hesitant about the 5 motor solutions that include I2C.
Is there room (pins not board space) for an on-board i2c display? With the current setup having the USB couple the hmi to the machine, that goes away with this approach and so does the text debug stream unless we factor that in somewhereā¦ Serial line or user visual? Iām all for visual indications of what is going on other than just a web page.
Iāve done some bread boarding and prototyping without any issues, but I havenāt used I2C for anything. I used SPI to talk to the encoders without any issues of lag. I also found the connection to be more noise immune than I expected
1 Like
Thanks @bar that makes me a little more comfortable. I also reviewed the ESP32 docs and it looks like you can even take exclusive control of the SPI port if needed (skipping any scheduling). I think this has become a non-issue.
At this point, I definitely need to just ignore any fears and embrace the SPI.
I think this is the plan I will start on this weekend:
5x Motor Encoders - 10 pins
SD over SPI - 4 pins
All Motor Drivers on second SPI - 4 pins
AUX pins - 5 pins
@Orob 5 AUX pins would be exactly enough for an I2C display (2 pins) + encoder (3 pins). You would still be able to connect other stuff to the I2C bus. As a note, the USB serial to the ESP32 will be untouched - it can be debug output or whatever.
Personally I would skip the encoder since those pins would be better used for other things. I find the web interface more useful. However, using an LCD as progress display could be nice.
2 Likes
And I just want to mention that after a lot of searching I think I have found the perfect IC that I plan on using. They are the DRV89XX series motor drivers.
- They have a built-in PWM generator, so I can skip those LED drivers.
- Each chip can control multiple motors - I expect to connect 3 per chip.
- They can be daisy chained without needing a CS pin for each, saving a pin.
- Price is cheaper, considering how many other chips it will replace.
- Overcurrent protection engages at 1.3A per channel but you can parallel two channels for double the output, if needed. I actually think we might be able to avoid paralleling, but I will need to test it out.
1 Like
I donāt think 1.3a per channel will be enough. I think the L298 can do 2a and we moved to the TLE because weād get āsled not keeping upā errors sometimes at the top center with the L298.