We have a weird problem that appeared from no where. We are using an arduino UNO with a driver TB6560 and a stepper motor NEMA 23. We're working on a prototype that consists of a plat-form that moves in one direction but both way (left and right). Everything worked fine until the plat-form began to move very slowly in one direction. We used an other driver (TB6600) and still the problem persisted. So 3 origins possible : the code, the arduino or the stepper motor.
It isn't the code. We're go trough every loop that we need (tested with the serial monitor). Have a look at it if you want.
/* Sets the translation to the left */
void translationLeft(long* ptrDistance) {
digitalWrite(directionPin, LOW);
digitalWrite(stepPin, HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin, LOW);
delayMicroseconds(ritardo);
--(*(ptrDistance));
}
/* Sets the translation to the right */
void translationRight(long* ptrDistance) {
digitalWrite(directionPin, HIGH);
digitalWrite(stepPin, HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin, LOW);
delayMicroseconds(ritardo);
++(*(ptrDistance));
}
// defines pins numbers
const int stepPin = 5;
const int dirPin = 3;
const int ritardo = 50; // Minimum = 50
void setup() {
// Sets the two pins as Outputs
pinMode(stepPin,OUTPUT);
pinMode(dirPin,OUTPUT);
void loop() {
if (Serial.available() > 0) {
// read the incoming integer
inputCode = Serial.parseInt();
}
switch (inputCode) {
case 0 :
translationLeft(ptrDistance);
break;
case 1 :
translationRight(ptrDistance);
break;
...}
...}
It isn't the arduino, we switched pins and still got the same issue.
It is the stepper motor. We In fact, we just disassembled the stepper motor and we found out that the later goes slower in one direction than an other.
Have you ever had that problem ? If yes, is there a way to repair it (although I hardly think so) ? Is there a code of conduct to prevent that from happening again ? We were not that rough with it in our opinion.
c_anuta:
we found out that the later goes slower in one direction than an other.
There is something seriously wrong with the language here.
"later" is not the correct word but I can't think what it should be.
Also, I can't imagine what you could have discovered by dismantling the motor. AFAIK there is not much that can go wrong with a stepper motor other than the smoke escaping.
We have a weird problem that appeared from no where. We are using an arduino UNO with a driver TB6560 and a stepper motor NEMA 23. We're working on a prototype that consists of a plat-form that moves in one direction but both way (left and right). Everything worked fine until the plat-form began to move very slowly in one direction. We used an other driver (TB6600) and still the problem persisted. So 3 origins possible : the code, the arduino or the stepper motor.
At least 7 origins possible: code, arduino, motor, motor driver, connections between arduino and motor driver, connections between motor driver and driver, power supplies.
It isn't the code. We're go trough every loop that we need (tested with the serial monitor). Have a look at it if you want.
We always want to see the code! And the circuit diagram. And full details of all the hardware (links to datasheets ideally).
It isn't the arduino, we switched pins and still got the same issue.
It is the stepper motor. In fact, we just disassembled the stepper motor and we found out that the later goes slower in one direction than an other.
That is technically impossible, as the size of a step is the same whichever direction you go.
Which motor are you talking about?
Did you test the windings with a meter?
Have you ever had that problem ? If yes, is there a way to repair it (although I hardly think so) ? Is there a code of conduct to prevent that from happening again ? We were not that rough with it in our opinion.
Sounds like wrongly connected windings to me, or a blown drive due to intermittent connections. You must never
rewire a stepper while the driver is powered up, that usually fries the driver immediately - and by the same token
the wiring to the motor must be rock solid - no breadboarding for that, screw terminals, decent connectors or
solder joints are required.
Robin2:
There is something seriously wrong with the language here.
"later" is not the correct word but I can't think what it should be.
I meant "latter". I didn't think a missing "t" would be that serious.
We have news concerning the problem. For a weird reason, we used a very simple piece of code to test (shown below) and it worked :
// defines pins numbers
const int stepPin = 5;
const int dirPin = 3;
const int enPin = 8;
const int ritardo = 50; // Minimum = 50
void setup() {
// Sets the two pins as Outputs
pinMode(stepPin,OUTPUT);
pinMode(dirPin,OUTPUT);
pinMode(enPin,OUTPUT);
digitalWrite(enPin,LOW);
}
void loop() {
digitalWrite(dirPin,LOW); // Enables the motor to move in a particular direction
// Makes 200 pulses for making one full cycle rotation
for(int x = 0; x < 8000; x++) {
digitalWrite(stepPin,HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin,LOW);
delayMicroseconds(ritardo);
}
delay(3000); // One second delay
digitalWrite(dirPin,LOW); //Changes the rotations direction
// Makes 400 pulses for making two full cycle rotation
for(int x = 0; x < 8000; x++) {
digitalWrite(stepPin,HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin,LOW);
delayMicroseconds(ritardo);
}
delay(3000);
}
It is basically the same piece of code (with digitalWrite + delayMicroseconds) but the only difference is the "enpin" that we added (if someone could explain the purpose of that pin, that would be great). So we did the same in our code but we still have the same problem.
So we really are confused because as I saied, our problem came suddenly with the same code (shown in the first post) we used for weeks.
MarkT:
At least 7 origins possible: code, arduino, motor, motor driver, connections between arduino and motor driver, connections between motor driver and driver, power supplies.We always want to see the code! And the circuit diagram. And full details of all the hardware (links to datasheets ideally).That is technically impossible, as the size of a step is the same whichever direction you go.
Which motor are you talking about?
Did you test the windings with a meter?Sounds like wrongly connected windings to me, or a blown drive due to intermittent connections. You must never
rewire a stepper while the driver is powered up, that usually fries the driver immediately - and by the same token
the wiring to the motor must be rock solid - no breadboarding for that, screw terminals, decent connectors or
solder joints are required.
The problem doesn't come from the wires. We've dismantle the prototype (and wire/rewire the components many times) and we still have the issue.
The precise model of the NEMA 23 is NAME23-22-02SD-AMT112S.
Yes, we tested the windings and it's fine (we did the test with the LEDs and with a multimeter (the device that measures the tension in case I don't express myself correctly), it produces the expected 5V).
So before the enable pin was floating? That would easily explain random behaviour, except for the fact that LOW for the TB6600 enable is motor off... Did you leave other inputs floating too? Floating inputs are a recipe for strange random pattern-sensitive problems.
The TB6600 inputs have built-in weak pull-downs, but this is often not enough if the signal is brought out on the pcb along side other signals as capacitive coupling can easily overcome a 100k weak pull down.
If you'd posted the circuit in the first place this sort of thing would be quick to spot...
c_anuta:
Sorry, I forgot to post the code. It's done now.
Please don't make changes to older Posts (other than to correct typos) as it makes the flow of the discussion almost impossible to follow. Put new material in a new Reply.
I meant "latter". I didn't think a missing "t" would be that serious.
Even with the extra T it does not make sense.
we just disassembled the stepper motor and we found out that the latter goes slower in one direction than an other
Update : for no reason, the stepper motor works normally now with the basic piece of code we used (shown in the first post) and the same material. I have no idea whats going on and I'm quiet afraid since I would like to reproduce this problem.
To resume, we used this piece of code :
/* Sets the translation to the left */
void translationLeft(long* ptrDistance) {
digitalWrite(directionPin, LOW);
digitalWrite(stepPin, HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin, LOW);
delayMicroseconds(ritardo);
--(*(ptrDistance));
}
/* Sets the translation to the right */
void translationRight(long* ptrDistance) {
digitalWrite(directionPin, HIGH);
digitalWrite(stepPin, HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin, LOW);
delayMicroseconds(ritardo);
++(*(ptrDistance));
}
// defines pins numbers
const int stepPin = 5;
const int dirPin = 3;
const int ritardo = 50; // Minimum = 50
void setup() {
// Sets the two pins as Outputs
pinMode(stepPin,OUTPUT);
pinMode(dirPin,OUTPUT);
void loop() {
if (Serial.available() > 0) {
// read the incoming integer
inputCode = Serial.parseInt();
}
switch (inputCode) {
case 0 :
translationLeft(ptrDistance);
break;
case 1 :
translationRight(ptrDistance);
break;
...}
...}
And it suddenly didn't work in one direction.
Then we used this instead :
// defines pins numbers
const int stepPin = 5;
const int dirPin = 3;
const int ritardo = 50; // Minimum = 50
void setup() {
// Sets the two pins as Outputs
pinMode(stepPin,OUTPUT);
pinMode(dirPin,OUTPUT);
}
void loop() {
digitalWrite(dirPin,LOW); // Enables the motor to move in a particular direction
// Makes 200 pulses for making one full cycle rotation
for(int x = 0; x < 8000; x++) {
digitalWrite(stepPin,HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin,LOW);
delayMicroseconds(ritardo);
}
delay(3000); // One second delay
digitalWrite(dirPin,LOW); //Changes the rotations direction
// Makes 400 pulses for making two full cycle rotation
for(int x = 0; x < 8000; x++) {
digitalWrite(stepPin,HIGH);
delayMicroseconds(ritardo);
digitalWrite(stepPin,LOW);
delayMicroseconds(ritardo);
}
delay(3000);
}
and it worked (both directions). Then we tried again with the first piece of code and it worked back again.
c_anuta:
and it worked (both directions). Then we tried again with the first piece of code and it worked back again.
I would look for a loose connection.
You should also be VERY CAREFUL to ensure that the wires between the motor and the driver cannot come loose even for an instant while the driver is powered as the driver is likely to be fried.