My only concern would be that we want to make sure the failure mode is powered off so if the micro hangs or something we want the motors to stop and not pull itself apart.
Edit: It looks like they don’t offer current readback though. I was thinking it would be nice to be able to monitor the motor’s current.
Yeah you are right. I am working on testing the motors to get some better specs on them. The website for them doesnt have many details. So far I know we will need to parallel at least two drivers per motor
I looked at the specs on the L298. They are terrible (entirely because they are based on old bipolar technology). The datasheet says they have a voltage drop of up to 4.9 volts at 2A, which is HUGE. If you are feeding the board with 12V 2A the motors only receive 7.1V at 2A, which is why they are stalling. They also generate 20x more heat than the TLE5206 at these conditions. They would need a decent sized heatsink and preferably a fan.
The TLE5206 on the other hand is probably overkill. Under the same conditions of 12V 2A at the board, they are delivering 11.5V and 2A. They don’t need heat sinks in these conditions.
The specs of the motor drivers seem to keep increasing in each generation of the electronics. If transistors are cheap, then there is no reason not to. However, I would like to evaluate how big we actually need, otherwise we might be excluding some good solutions.
That’s an extremely good point that all of these SPI or I2C PWM generators would need to address.
I imagine we could include some sort of watchdog timer triggered by the SPI bus. If the timer elapses it could trigger the sleep pin on the drivers. This would actually be relatively simple to implement with a 555 timer.
The LED driver chip I was using supposedly had the feature that it would shut off in the event of a loss of communication, but in my experience it wasn’t reliable and I found cases where it would default to running the motors during boot up or firmware flashing so an external solution would be a great idea.
Why not use the watchdog on the micro? When the watchdog is triggered, the micro resets. Micro I/Os go to Hi-Z, micro I/O connected to nSLEEP is pulled down by pull-down resistor in the driver chip. Motor driver outputs go Hi-Z. Motor stops. Output shaft stops (and stays in position due to worm drive gearbox).
I could be sold on that being safe enough. Some of the pins have strange behavior when new firmware is being flashed or during boot up, but as long as we choose wisely I think it should work.
If you go that route why not a separate 8 inexpensive microcontroller dedicated to motor safety?
WDTs are a good option, but they don’t cover power blip at startup issues, for example, or software bugs that turn them off.
Having two separate ESP32 controller development efforts this early seems like unnecessary duplication. Pretty hard atm to beat Bart’s wonder board’s price and firmware development is the 900 pound gorilla. Perhaps consider saving hardware optimization until after the firmware is sorted out. The early adopters can pay the modest extra premium, the rest can wait for phase 2. Just the opinion of a swamprat shop sharing moose.
Esp32 supports canbus, why not put a chip on each motor and have each motor run its own encoder taking movement targets from the central esp32? The motors could be steppers or servos… It shouldn’t matter to the control chip, only to the motor chip. Just a thought, but not a simple or easy implementation.
Alright, I have been testing the X/Y axis motors. I tried my best, but I don’t have dedicated meters for some of these items. The uncertainty is a rough estimate of how close I got to the real value. Measuring the resistance was really difficult at such low values.
Parameter
Value
Units
Uncertainty
Inductance
2.76
uH
± 10%
DC Resistance
1.2
Ohm
± 50%
No Load Current
0.272
A
± 2%
Current at 20lb Tension
0.820
A
± 7%
Extrapolating motor current, I expect we need about 1.7A steady state to achieve 50 lb of chain tension. Add in some headroom for acceleration and I suspect we need over 2A for significant amounts of time.
The point of all of this was to determine if the DRV89XX will work. The deal breaker will be the inrush current which spikes on each PWM cycle. If the spikes are anything like theory says, then the DRV89XX will shut off from the overcurrent protection and be mostly unusable.
I think I will have to look for a different driver that can handle these large spikes.
Yep, I’ve looked through all motor drivers with built-in PWM driver chips but none are acceptable, so its going to be TLE9201 (or the non-automotive version, IFX9201) with a LED PWM chip.
I’m looking for an alternative the the TLC59711 that has push-pull outputs instead of open-drain. Also maybe control over PWM frequency.
I can use dedicated hardware PWM ICs
For $3.03 (or $1.46 @ qty 2000) I can get the TLC59711
For $3.50 (or $1.69 @ qty 2000) I can get the TLC5947
— OR —
I can throw a microcontroller at the problem. It would be reprogrammable in the future. Then I get the push-pull outputs I want, SPI communication, and it can act as the watchdog.
For $0.72 (or $0.28 @ qty 2500) I can have an STM8S003F3, which is about the cheapest but requires some learning.
For $1.34 (or $1.18 @ qty 2000) I can have an ATmega328P. Same Arduino goodness we all know and love.
Seems like a fairly one-sided tradeoff.
EDIT: PlatformIO doesnt have the STM8S003 in it, so its not worth the bother to go with that chip. Looks like we are going to have an ATmega328P on board.
Based on my read of the documentation this doesn’t serve as the sender. you would still need a makerverse or a webcontrol program. The ESP32 functions as the gcode receiver just like the due or the mega so it woul only effectively be swapping out the wire for the esp32, not hosting the webserver to accept a gcode file? It was my understanding that the esp32 move for maslow would be for a complete controller so you generage gcode, upload it to the ESP32 with the web interface and then interact with the esp32 to run the cut and control the settings so it is all on board… no more raspberry pi or resident tethered program required.
It would be awesome it someone could design a PID controller with motor driver all in the size of a stepper driver form factor and accept steps/dir as the input. I’ve yet to see one but suspect it might (big might) be possible.
