Motor Shield Limitations? Overheating?

Yes! Thanks for letting me know that is unclear. I will add a picture with the heatsinks to the page

1 Like

Just an update on this.

I am relatively confident that I damaged one of the motor controllers on the v1.1 heat shield. I don’t think this happened in normal use, but instead I suspect it happened when I tried to increase the controller frequency.

I think I have seen the issue for quite some time, but it was very apparent when I was testing different PID values, one of the motors acted extremely differently than the other. Annoyingly the problem in my case manifested itself as an oscillation in the movement which could easily be confused for other errors.

I suspect that the motor controller somehow became more sluggish. That the PWM output from the arduino was slower to cause a voltage change on the motor side. If I was a more advanced electrician I could probably confirm this, but I don’t even own an oscilloscope.

Just a data point for people to consider in the future.


The motor shield was designed to be running at the edge of it’s capabilities to
keep the price down.

I think it would be a good idea for future versions to have a little more
headroom. too many people have been damaging their shields


I’ve run into this too.
I’ve been looking at a different driver chip, the TLE5206, which offers over-temperature protection and a thru-hole package that accommodates bigger heat sinks.
The software will need to change, though. The present approach is to set the direction with two output signals and the speed with a third PWM signal. The TLE5206 wants two PWM signals and chooses direction based on which one is active and the state of the other one.


I’m working on a case with an active cooling tower for each chip.

I need to wait for the fans to come back in stock. Please let me know if these are of interest to you.

Thank you


those 3d printed cooling towers are cool. can you share stl please?
I know I am replying 8 months late! sorry.

What type of printer are you using?

I didn’t put the files out because it is a very difficult design to print. I’d say 1 out of 10 prints might be successful.

I’ve PM’d you on this also.

Thank you

cr-10, now that I look at the design yes it does look hard to make without supports

Maybe I will split it in two and just glue the two halves together.

Hello. Since my board with tle5206 seems dead I am fiddling with some spare hbriges I have. My hbridge like tle5206 have two pins per motor, but with tle5206 settings in motor.cpp is not working. On my hbridge first pin chooses direction LOW/HIGH and second pin is used as PWM. I tried so many combinations but non of them is working. At best I had Left motor spining both directions and Right motor only one in test motor encoder but that was succesful 1 of 3 tests and with changed pin1<->pin2. Can somebody point me in a right direction?

I would just buy a new board or buy the exact same chip from digikey, they are only about $10.

Yeah that is the easies solution, but this month I am on tight budget, and I have some spare ones. I am not good at coding so I thought somebody can help me out. I tried to change some values at motor.cpp.
else { // TLE5206
if (forward) {
if (speed > 0) {
if (usePin2) {
digitalWrite(_pin1 , HIGH );
analogWrite(_pin2 , speed); // invert drive signals - don’t alter speed
else {
analogWrite(_pin1 , speed);
digitalWrite(_pin2 , HIGH );
else { // speed = 0 so put on the brakes
digitalWrite(_pin1 , LOW );
digitalWrite(_pin2 , LOW );
else { // reverse
if (usePin2) {
analogWrite(_pin2 , speed); // invert drive signals - don’t alter speed
digitalWrite(_pin1 , LOW );
} else {
analogWrite(_pin1 , 255 - speed);
digitalWrite(_pin2 , HIGH );
This is the code I have for now. With these setting L motor spins CW and R CCW, so I get 2 PASS on test.
First pin - 0 for CW 1 for CCW, and PWM on second pin. Also I am wondering of this “speed” how it is translated. In code I have (-255, 255) so for -255 is 0v and for 255 is 5v? In original code I saw that if there is LOW in digitalWrite in analogWrite there is 255-speed. So if I get full reverse speed from software there is abs(speed) and then 255 - 255 means 0 on PWM pin, how can I fight with this?

The current boards use chips that have one pin to enable one direction, a
different pin for the other direction, and a third pin for PWM, so that’s what
the software is setup to drive.

David Lang

This is only true if the firmware determines that the board is v1.1 or v1.2 - the stock ones that use the L298 H-bridge chip.

If the firmware determines that the board is v1.3 (TLE5206 chip) it uses the two control pins for both direction and PWM. The firmware makes this determination by looking at the states of some of the pins in the 36-pin XIO connector (see System.cpp::getPCBVersion() and System.cpp::setupAxes()).

If the H-bridge chip has only two control pins, then the TLE5206 logic should work for it if the gpio pin definitions made in getPCBVersion() and setupAxes() are set up properly for the board as wired.

1 Like

Thank you for input. Seems like the TLE5206 logic is not working, or I am missing something crucial.

When GC starts up, it triggers the firmware to try to determine which kind of board is being used. A message prints in GC to show what it found. If you don’t see this message:

PCB v1.3 TLE5206  Detected

then the routines I described for the TLE5206 board won’t be used but the three-pin controls for the stock Maslow board will be used instead.

1 Like

I have this message while booting, but i cant setup it to spin both directions.

On the TLE5206, direction is chosen by which of the two control pins is high, and either pin can be pulsed for speed. The chip you are using always uses the same one for direction, the other for speed. (What chip is this? I’m interested to learn more about it.) You’ve found the right part of the firmware to change to make your chip work, you’re almost done!