Not much to report at present, real life has been getting in the way again. But the stepper drivers I ordered from China have finally turned up, and I had a chance last night to play with them.
So against all the advice found online, I ordered some TB6600 based drivers from eBay. At the price (£11 per axis) I figured it was worth a punt, as even if they're pap I can sell them back on eBay and at least recoup the cost…
First thing to note is that these PCBs appear to have a different layout compared to the ones I've seen discussed on CNC forums. I hoped that it was a newer, better design. The other boards I've seen have all the inputs and outputs along one edge of the board, these ones have the step input control on one side, and motor and power supply on the other.
They're supplied with 4 brass stand-offs, and a heatsink on the TB6600 chip. Immediately I noticed a problem here: the heatsinks are mounted on the *bottom* of the chips. I know I only scraped through my Thermodynamics class last semester, but I'm pretty sure having the heatsink on top of the chip would be a squillion times better. I plan on replacing the heatsinks with something bigger anyway, either with directly mounted fans or in an air cooled box with the other electronics.I suppose I could even leave the underside coolers on and just add a better cooler to the top side.
Surprisingly for boards from China, these things also came with a data-sheet of sorts, detailing the various limits for inputs/outputs, wiring examples and DIP switch settings. Foolishly, I believed the datasheet and wasted 30 or 40 minutes trying to get the board to respond: the Enable PIN has to be pulled LOW to enable the board, not HIGH as stated on the sheet!
I hooked up the board to one of my steppers, a 30V, 3.5A bench supply and an ARM mbed micocontroller to provide the clicks. My code for the mbed was very rudimentary, all it does is send the ENABLE pin LOW (haha, eventually), Direction pin HIGH and provide a pulse to the step pin every 0.4 Seconds. I thought it best to keep it simple to start with (code used is at end of post).
I grounded all the -ve pins on the input side together and to the mbed, as shown in the data sheet diagram. The input side is opto-isolated so the inputs must be grounded separately to the motor supply.
Plugged everything in, checked all the connections, turned it on and… nothing. Well, almost nothing. The motor is trying to step, but is just wiggling back and forward. I know the motors work (see previous posts for test), and the TB6600 board is responding to the pulse (the LED on the TB6600 board flashes for each STEP command it receives), but I just can't get the thing to move. I tried a whole bunch of different timings for the stepping, including a 50% duty cycle between STEP and NOSTEP, but nothing worked. The closest I got to making it work was manually touching the STEP wire to a 3.3V source. If I 'vibrated' the wire just right off the 3.3V output pin on the mbed I could more or less get the drive to rotate.
I'm a bit stumped now, one of my lecturers and a few other students helped out probing the thing with a scope, and even triggering the scope from the step pulse, but we couldn't really make head-nor-tail of the output. The coils were definitely bouncing between 0v and +10v (the bench supply was set to 10v at that point), but not actually rotating.
Also tried one of the other boards and one of the other motors, all with the same result.
So what am I doing wrong? Is it a grounding issue? I've had odd behavior with steppers before when there was a grounding issue between the driver and the MCU, but that didn't seem to solve the issue this time. Any advice gratefully received!
Video of the motor failing to rotate:
Code used on the mbed:
#include "mbed.h"
Serial pc(USBTX, USBRX);
// used to communicate with a terminal on a PC – not actually implemented here so can be removed
// Planned to have RPM and direction selectable via terminal, but sadly never got that far!
DigitalOut Enable(p5);
DigitalOut Direction(p6);
DigitalOut Step(p7);
DigitalOut LED(LED1);
int main() {
LED = 0;
Enable = 0;
Direction = 1;
while(1) {
Step = 0; // Set the STEP pin LOW i.e. no step
wait(0.3); // wait for 0.3 seconds
Step = 1; // Set the STEP pin HIGH i.e. make it step
wait(0.1); // wait for 0.1 seconds. Combined wait time gives one step every 0.4 seconds, ie 150 RPM
LED = !LED; //Blink one of the mbed onboard LEDs to use as a visual cue for when stepping should occur
}
}
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Having a heatsink on the top of the chip only would be worse. The supplied heatsink was installed where the chip was designed to have it, namely on its thermal contact surface. On that side of the chip, there is a direct metal path from the semiconductor die that generates heat to the outside of the package, which is in contact with the heatsink. If you put a heatsink on the other side, the heat will have to go through the plastic, which has greater thermal resistance. That means that at any given power level, the die will be hotter, because the heat has a harder time escaping. Wherever you install a heatsink, you must also use thermal paste or a thermal pad to ensure good thermal contact—the surfaces are micro-rough and will not contact each other well enough to transfer heat well without it.
Heat does not rise. Hot parts of fluids rise when there is a temperature gradient in the fluid: https://en.wikipedia.org/wiki/Convection. Turning the whole board, with supplied heatsink only, upside down might help a tiny bit, by providing a better path for convection of the surrounding air past the heatsink. It would definitely not help due to the heatsink being above the chip. If you put forced air (e.g. a fan) on it, convection becomes insignificant, so orientation should not matter in that case.
With or without forced air, a heatsink will only be very helpful if it's on the side of the chip the supplied heatsink was installed on, and is installed using thermal paste or a thermal pad.
Are you sure? yes | no
sort of.
I had another play with them on Tuesday, this time driving the input signal with a signal generator.
I got them spinning at around 300Hz up to about 1.1kHz. I suspect that the decay time on the chip has been set so that the driver is almost constantly in current reduction mode. There's a good discussion on this that Kert linked to in another comment on here.
Need to have another sit down with the scope and the tb6600hg datasheet and see what's going on, but hopefully shorting out pin 3 and 4 on the board will fix it.
Are you sure? yes | no
Hi, have you solved the issue? I would love to hear the answer
Are you sure? yes | no