j' essaie de faire fonctionner le code suivant avec le driver tb6600 mais le moteur ne s'inverse pas lors de la 2ieme partie du code.
le driver est ok, testé avec plusieurs, alimenté en 12v
les paires a+a- b+b- bien identifiées.
Tout est câblé sur un arduino mega, je n' arrive pas à déterminer l' origine de mon problème, tout conseil est bienvenu.
merci d' avance
// defines pins numbers
const int stepPin = 5;
const int dirPin = 2;
const int enPin = 8;
void setup() {
// Sets the two pins as Outputs
pinMode(stepPin,OUTPUT);
pinMode(dirPin,OUTPUT);
pinMode(enPin,OUTPUT);
digitalWrite(enPin,LOW);
}
void loop() {
digitalWrite(dirPin,HIGH); // Enables the motor to move in a particular direction
// Makes 200 pulses for making one full cycle rotation
for(int x = 0; x < 800; x++) {
digitalWrite(stepPin,HIGH);
delayMicroseconds(500);
digitalWrite(stepPin,LOW);
delayMicroseconds(500);
}
delay(1000); // One second delay
digitalWrite(dirPin,LOW); //Changes the rotations direction
// Makes 400 pulses for making two full cycle rotation
for(int x = 0; x < 800; x++) {
digitalWrite(stepPin,HIGH);
delayMicroseconds(500);
digitalWrite(stepPin,LOW);
delayMicroseconds(500);
}
delay(1000);
}
It may be that the driver is not recognising the direction signal, possibly because it isn't properly connected. For example, the screw in the terminal block may be clamping on the sleeve of the wire rather than the wire itself. Will the motor reverse if you physically connect the dir pin to the opposite polarity?
C'est simple :
Pour les sous-fora qui sont dans la partie "International" on utilise la langue locale.
A l'intérieur du sous forum "Français" on utilise le français.
A l'intérieur du sous forum "Allemand" on utilise l'allemand.
etc.....
Pour tous les autres sous fora qui ne sont pas dans la partie "International" on utilise l'anglais.
Merci d' avoir déplacé le sujet au bon endroit.
J' avais vu le message sur le problème similaire et essayé les solutions proposées sans résultats.
J' ai vérifié les borniers ainsi que l' inversion de polarité du dir
Pour y voir quelque chose à la vitesse simple mortel, il est utile de faire plutôt 1micropas/s
Cela permet de voir si l'avance est régulière.
Il faut donc remplacer les delaymicroseconds(500) par delay(500).
A 1000 pas/s des résonances peuvent faire tourner le moteur en sens inverse de la commande.
Précise éventuellement le nombre de pas partout programmés avec les switchs du TB6600
Il n'est pas nécessaire de faire du carré, 500/500 microSecondes, c'est le driver qui s'occupe de la mise en forme des impulsions pour le moteur. Une impulsion de 10 microSecondes est suffisanrte.
C'est essayé avec un Nema17 et un driver A4988.
C'est vrai, mais il n'est pas nécessaire non plus de faire des impulsions de 10microsecondes... Sauf si on se pose ma question de pourquoi 10 et pas 5.
Si c'est pour vouloir absolument des impulsions, autant supprimer le delayMicrosecond(10).
Moi, je ne vois pas d'intérêt sauf pour supprimer le delayMicroseconds de ne pas faire 50/50.
Mais le problème ne vient pas de là. Je ne vois pas dans le code le pourquoi. Et imposer un autre programme résoud la question "comment faire"mais enterre sans réponse le "pourquoi il tourne toujours dans le même sens". Pédagogiquement, on apprend plus en corrigeant ses erreurs qu'en utilisant le programme d'un autre.
Oui, c'est une autre façon de voire les choses, c'est comme en programmation, il y a autant d'aidants que de façons d'aider, si l'un ou l'autre avait LA VERITE ça se saurait.
Olivier, c'est ce qui est écrit, ou que l'on peut déduire de la datasheet.
Enfin pas tout à fait :
La datasheet de l'A4988 indique 10 µs de durée d'impulsion minimale.
La datashet du TB6600 indique une fréquence max de commande de 200 kHz.
Soit une période de 5 µs, soit selon l'interprétation que je fais de leur graphique de signaux, une durée minimale d'impulsion de 2,5 µs avec une horloge à 200 kHz et rapport cyclique = 50/50.
@jpbricole n'est pas souvent d'accord avec moi et là, je suis d'accord avec lui : il est inutile de faire durer la commande de pas plus que nécessaire et plus que de raison.
Selon comment le programme est architecturé, cela peut provoquer des ralentissements.
100 % d'accord avec toi et en plus cela permet d'être autonome.
Et que le temps minimum pour l'état haut est de 1µs pas 10! Heureusement d'ailleurs avec 10µs d'état haut et 10µs d'état bas, cela me limiterait à 50000 micros pas/s soit seulement 15tr/s en 16 micros pas.
Comme digitalWrite dure plus de 6µs avec une Mega, on peut parfaitement écrire
Maintenant je ne sais pas d'ou vient cette idée qu'il faut une impulsion. Tout ce que je peux déduire du chronogramme, c'est qu'ils mettent un signal carré 50%/50% et que le changement de pas devrait se faire sur le front montant. Je ne vois pas en quoi
Maintenant dans les drivers du type TB6600, il y a deux façons de brancher Step:
− on met PUL- à GND et on met le signal sur PUL+
− on fait l'inverse.
Dans un des deux cas cela inverse l'info STEP. En cherchant absolument à mettre une impulsion positive courte sur la sortie STEP, on risque d'avoir une impulsion négative courte sue l'entrée du composant.
Autant donner le rapport à 50% sans avoir à chercher si on est avec une commande inversée ou non si c'est possible. Je me souviens que la plupart des montages utilisent justement l'entrée inversée. Le montage du post #1 ne doit pas inverser mais est moins commun je crois.
Enfin, j'ai vu passer un driver qui avait besoin d'au moins 30µs mais je n'ai plus la référence. Pour avoir un programme qui fonctionne avec tous les drivers, il faut garantir un état haut et un état bas d'au moins 30µs...
Tout à fait, mais avec autre chose que digitalWrite() mode arduino il est préférable de vérifier.
digitalWrite() prends en viron 60 cycles horloge.
digitalWriteFast() ne prend que 2 cycles horloge.
Si on utilise aussi autre chose qu'avr il faut aussi vérifier.
C'est là qu'un analyseur logique à 8 € rend bien des services.
J'ai lu trop vite, merci de la rectification. Je constate qu'avec mes 2,5 µs au lieu de 2,2 µs je ne me suis pas mis le doigts dans l'œil jusqu'à coude
J'en conclu que 2,2 µs est le vrai temps minimal et que pour les 200 kHz le fabricant à pris une marge de sécurité.
Je n'ai pas la même perception.
Dans un circuit logique, il existe un paramètre que je nomme en français "Temps minimal que doit durer une commande pour qu'elle pour qu'elle soit prise en compte".
Ce paramètre n'est quantifié que pour les CI où sa connaissance est obligatoire, néanmoins il existe dans tous les étages électroniques.
Le temps de propagation dans une porte élémentaire est loin d'être nul.
D'après ce que je connais j'en conclu :
qu'il faut que le niveau "1" dure au minimum 2,2 µs pour qu'il soit pris en compte.
qu'il faut que le niveau "0" dure au minimum 2,2 µs pour qu'il soit pris en compte.
Pour que le circuit intégré puisse prendre en compte le prochain niveau "1" il faut qu'il ait pris en compte le précédent niveau "0".
et là, je suis d'accord avec lui : il est inutile de faire durer la commande de pas plus que nécessaire et plus que de raison.
