Arduino Forum

International => Français => Topic started by: Super_Cinci on Oct 22, 2013, 11:09 pm

Title: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 22, 2013, 11:09 pm
Salut la communauté!

Alors j'ai fait une petit électronique simple, on rentre avec deux fils et on sort sur les 4 bobines du moteur pas à pas. en fait, j'ai fait un simple démultiplexeur 2 => 4.

Mais voilà, histoire de, j'ai mi ce code là :

Code: [Select]

void loop(){
  PORTD += 0x04; // interface connectée sur D3 et D4, on fait tourner la séquence { 00, 01, 10, 11}
  delay(analogRead(A0);    // potar sur A0 pour la vitesse
}


ça marche, mais pas moyen d'aller vite, le moteur déraille tout de suite!

Alors j'ai regardé avec mon oscillo, ben franchement, le signal gigote dans tous les sens (entre le delay et l'analogRead...), donc normal que le moteur ne suive pas.

j'ai ressorti un vieux montage à base de CMOS, un oscillateur, compteur, démultiplexeur, et là, le moteur répond impec (tant qu'on lui laisse le temps d'accélérer bien sur!)

Quelqu'un a un bout de code à base de vraies interruptions qui marche bien pour faire aller le moteur super vite? Sinon, je le ferai, mais bon, autant travailler ensemble ;)

j'ai ouvert la lib stepper, bouh que c'est laid! que des int 16 bits, des digitalWrite()... Bref, tout ce qu'il faut pour faire une catastrophe!
Title: Re: [Moteurs PAP] un code qui marche?
Post by: 3Sigma on Oct 23, 2013, 12:11 am
J'ai ça (voir code dans fichier attaché) qui fonctionne nickel avec ce moteur (http://www.pololu.com/catalog/product/1200 (http://www.pololu.com/catalog/product/1200)) et ce driver (http://www.pololu.com/catalog/product/2128 (http://www.pololu.com/catalog/product/2128)).

Je ne suis pas sûr que ça corresponde vraiment à ce que tu veux mais si ça peut te donner des idées, ça sera déjà pas mal.
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 23, 2013, 09:25 am
Salut et merci,

Il y aurait de l'idée, mais l'utilisation de la fonction tone() ne me convient pas trop. D'accord, ça permet certainement de générer une belle horloge pour le driver, mais avec ça, tu ne contrôles pas du tout le nombre de pas. Mon idée est de pouvoir "dire" faire x pas en avant ou en arrière, et que tout ça passe bien sûr par une phase d'accélération et décélération, avec toutes les contraintes de fonctionnement (vitesse max, conditions de charge...).

J'ai commencé à plancher sur l'utilisation d'un timer qui génère une horloge de fonctionnement, et quelques contrôles autour, mais j'imagine que quelqu'un a déjà planché sur le truc, je ne voudrais pas réinventer l'eau chaude, simplement adapter sa température...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: fdufnews on Oct 23, 2013, 11:00 am
Faudrait regarder dans les codes des CNC ou des imprimantes 3D.
Il y en a plusieurs qui utilisent des cartes arduino
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 23, 2013, 11:21 am
De tous les projets de CNC que j'ai pu voir, les déplacements sont extrêmement lents, et je ne pense pas que ce soit dû aux "vitesses de coupe", mais plutôt de la difficulté de faire tourner deux moteurs PAP en même temps, et surtout synchros dans le cas de diagonales.

Je n'en ai encore vu aucun proposant des déplacements "rapides", les vitesses des moteurs semblent fixes. Le plus dur étant la gestion de l'accélération (surtout de plusieurs moteurs qui ne tournent pas à la même vitesse mais doivent être synchros) qui permettrait de gagner énormément. Je pense que tout est faisable avec un petit AVR, mais va falloir lui rentrer profondément dedans pour arriver à ce que j'en attends.

Je vais quand même retourner faire un tour sur gogol...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: fdufnews on Oct 23, 2013, 11:29 am
Google et le forum sont tes amis:
2 ème résultat en faisant une recherche sous google avec les mots clés "arduino stepper motor library"
Peut être intéressant http://forum.arduino.cc/index.php/topic,22400.0.html (http://forum.arduino.cc/index.php/topic,22400.0.html)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 23, 2013, 11:37 am
Bah GRBL niveau optimisation y'a pas mieux ... mais je comprend pas vraiment ton problème de vitesse : un moteur pas à pas, d'une manière générale il est difficile de dépasser 10 000 pas/s, et encore tu n'as plus qu'1/4 du couple ... et 10khz c'est tenable, même avec des digitalWrite()
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 23, 2013, 04:21 pm
et 10khz c'est tenable, même avec des digitalWrite()
pas tant que ça... car un digitalWrite() avec du delay(), ça sort tout sauf une fréquence assez stable pour un PAP. arrivé à une certaine vitesse, un petit écart de tempo dans un cycle représente une accélération qui souvent peut être fatale (perte de pas, voire décrochage complet du moteur).

J'ai regardé GRBL, en effet, il semblerait que ça soit pas mal, à regarder de près. (mais c'est lourd!)

Sinon, pour la lib de mikem, il faut lancer le plus souvent possible stepper.run(), sinon, le moteur ne tourne pas. Et de cette manière, on a toutes les chances de taper à côté et encore une fois, perdre toute la stabilité. C'est surtout ça que je recherche : la stabilité. GRBL se base sur une interruption timer, donc devrait être stable.
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 24, 2013, 11:53 am
Bon... par rapport à ce que j'essaie de faire, GRBL va être trop long à nettoyer...

j'ai donc fait quelques calculs savants, en fonction des différents moteurs que j'ai sous la main et de leurs réducteurs associés...

comme ils viennent tous d'imprimantes et scanners, ils offrent des déplacements de courroie équivalents à des résolutions de 600 ou 1200DPI. J'ai regardé ce qu'un timer 8bits pouvait m'offrir en terme de vitesse de la courroie / fréquence de pas.

ma formule donne V(mm/s) = F(Hz) x 25,4 / R. (R = résolution en DPI ou en pas par pouce).

Je vous cache pas que derrière, il y a peut-être une éventuelle idée de CNC... j'ai déjà réussi à adapter l'algorithme de Bresenham pour faire un déplacement en ligne droite en 3D (du point (X1, Y1, Z1) au point (X2, Y2, Z2) ) avec accélération et décélération, à partir d'une interruption timer. Sur papier, car je n'ai rien monté en mécanique pour l'instant...

Mais voilà, je bute (plus pour très longtemps) sur l'accélération, car je voudrais dans un premier temps qu'elle soit constante et c'est pas évident, car la config du timer se fait en secondes² alors que l'accélération est en 1/s². je peux passer par tableau, mais il va me falloir plusieurs tableaux... ou utiliser un timer dédié qui génère l'accélération, mais là encore, ça me fera deux timers par moteur, on va vite être limité.

Bref, pour rester à 1 timer par moteur (pour gérer au besoin des déplacements indépendants), avec une accélération moyenne de 10mm.s-2 et rester dans des calculs 8 bits, j'obtiens de vitesse comprise entre 3 et 41mm.s-1 (donc normalement, j'atteins la vitesse max en 3 secondes)... Mais il y a un mais, car les changements de vitesses se font par paliers, et pas sûr que la moteur accepte le dernier palier (de 919Hz à 976Hz d'un coup, comme ça!) va falloir tester! Et bien sûr, en charge, car l'inertie d'une charge joue beaucoup sur la capacité à accélérer!

je vous tiens au courant...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: vince3838 on Oct 24, 2013, 01:58 pm
Salut,

J'ai bidouillé un code pour gérer 3 moteurs pour un robot "delta" avec une rampe linéaire pour éviter de sauter des pas au démarrage en charge, ça marche très bien chez moi, j'ai utilisé  l'algorithme de Bresenham.

voila un bout de code:

Code: [Select]

  if(val[0]-prev[0]>0){digitalWrite(3,HIGH);}else{digitalWrite(3,LOW);} //determination du sens
     if(val[1]-prev[1]>0){digitalWrite(6,HIGH);}else{digitalWrite(6,LOW);}
     if(val[2]-prev[2]>0){digitalWrite(9,HIGH);}else{digitalWrite(9,LOW);}

     for(int i=0;i<3;i++){d[i] = val[i] - prev[i];}  //calcul de la course a parcourir   

     long m= max(max(abs(d[0]),abs(d[1])),abs(d[2])); // identifier distance maxi pour denominateur:

     for(int i=0;i<3;i++){r[i]=(float)abs(d[i]) / (float) m;a[i]=0;} // debut de calcul des ratios, le plus grand sera égal à 1
     
      float v=m*1/Rampe;     // defini la plage d'acceleration et de deceleration (10% de la course en acceleration et 10% en deceleration, 80% en vitesse max);
      float w=m-v;
     
     
     for(float n=0;n<m;n++){ //debut boucle de mouvement
       float CoefSpeed=1.00; // par defaut coef de vitesse au max(ni acceleration ni deceleration)
         if (n<v){CoefSpeed=map(CoefSpeed,n,v,1.70,1.00);}
         if (n>w){CoefSpeed=map(CoefSpeed,n,w,1.00,1.70);}

     
        for(int i=0;i<3;i++){a[i]=a[i]+r[i];} // on incrémente:
   
    //si erreur >=1 on fait une step, puis on decremente l'erreur
    //les stepX... juste pour info du nombre réel de steps effectué
    if(a[0]>=1.00){a[0]--;reel[0]++;digitalWrite(2, HIGH);delayMicroseconds(delayUs);digitalWrite(2, LOW);}
    if(a[1]>=1.00){a[1]--;reel[1]++;digitalWrite(5, HIGH);delayMicroseconds(delayUs);digitalWrite(5, LOW);}
    if(a[2]>=1.00){a[2]--;reel[2]++;digitalWrite(8, HIGH);delayMicroseconds(delayUs);digitalWrite(8, LOW);}   
    delayMicroseconds(Speed*CoefSpeed);

} //vitesse globale des moteurs à définir suivant installation
 
  while(1){
   
    boolean rattrapageOK = true;
  if(reel[0] < abs(d[0])){reel[0]++;digitalWrite(2, HIGH);delayMicroseconds(delayUs);digitalWrite(2, LOW);rattrapageOK = false;}
  if(reel[1] < abs(d[1])){reel[1]++;digitalWrite(5, HIGH);delayMicroseconds(delayUs);digitalWrite(5, LOW);rattrapageOK = false;}
  if(reel[2] < abs(d[2])){reel[2]++;digitalWrite(8, HIGH);delayMicroseconds(delayUs);digitalWrite(8, LOW);rattrapageOK = false;}
  delayMicroseconds(Speed);
  if(rattrapageOK = true){break;}
  }
 
    // RAZ DELTA CAR MOUVEMENT EFFECTUE
    for(int i=0;i<3;i++){prev[i] = val[i];prevt[i] = t[i];reel[i]=0;}
} // if error ==0
  return(error);
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 24, 2013, 02:58 pm
Je vois, mais tu utilises des digitalWrite() et delay(), et ces fonctions ne sont pas assez temporellement stables pour envoyer du boudin dans un PAP. En plus, les calculs sur float ne prennent jamais deux fois le même temps d'exécution. Je cherche à pondre des fréquences de ouf (quelques KHz). mais si à un moment, sur un régime établi, un pas décide de mettre du temps à venir, alors ça équivaudrait à ralentir le moteur. On s'en fout un peu, car on les compte, les pas, donc on sait où on est. sauf que si le moteur n'arrive pas à ralentir assez, ça peut suffire à ce qu'il soit quand même trop loin du pas suivant, et donc il déraille.

L'exemple d'un défilé militaire : tant que tout le monde marche au pas, ok, ça pète! Mais si un fantassin met le pied à côté, c'est tous les autres derrière qui vont le suivre, et là, un 14 juillet sur les champs, ça va pas être dans le goût du chef, blâme général.

Ou encore le coup de l'escalier, si tu rates une marche, tu as toutes les chances de rater toutes les autres et ça fait mal. (amuse-toi à changer la hauteur d'une seule marche de 2cm, plus personne n'arrivera à monter ou descendre l'escalier sans se casser lag.).

sur des fréquences jusqu'à 100Hz, bah... ça le fait, les temps sont assez long pour que le courant dans les bobines prenne le dessus. mais si on va vite, le courant reste faible, donc il n'y a plus cet effet bourrin qui force le pas...

il faut que je teste mon code pour voir jusqu'où peut aller un PAP. je prends pour exemple une bécane que j'ai chez moi (une découpeuse de vinyl de 2m de long, une CNC de rêve), sa résolution est de 1016 DPI (400 ppcm), et quand tu vois le cutter parcourir les 2m (80000pas) en 4 secondes (20KHz?), on se dit que les PAP, bien réglés, ça fait des malheurs (vu le prix de la machine, elle ne rate jamais un pas)! d'ailleurs, les CNC homemade, ça tourne pas bien vite, et j'imagine que justement, c'est une question de stabilité des pas qui fait qu'on ne peut pas aller plus vite...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 24, 2013, 03:55 pm
delay() est basé sur un timer, donc parfaitement temporellement stable. Si tu passes par des manipulations de port directe alors il n'y a aucune raison que ta fréquence fasse du boudin
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 24, 2013, 04:48 pm
Code: [Select]

unsigned long micros() {
unsigned long m;
uint8_t oldSREG = SREG, t;

cli();
m = timer0_overflow_count;
t = TCNT0;
if ((TIFR0 & _BV(TOV0)) && (t < 255)) m++;
SREG = oldSREG;

return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
}

void delay(unsigned long ms)
{
uint16_t start = (uint16_t)micros();

  while (ms > 0) {
if (((uint16_t)micros() - start) >= 1000) {
ms--;
start += 1000;
}
}
}
On est quand même dans l'approximatif, là, non? Quand je parle de stabilité, c'est que sur plusieurs appels, la fonction produit exactement le même temps. là, c'est loin d'être le cas.
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 24, 2013, 07:03 pm
Je vois pas l'approximation :o

micros() est incrémenté par l'overflow du timer, je vois pas ce qu'il y a de hasardeux !

Et puis il faut avoir le sens des réalités : à 10 khz ça fait des périodes de 100 µs, même à 5% d'erreur c'est pas ça qui fera décroché ton PAP ... digitalWrite(), lui, est hasardeux (je suis tombé sur un topic d'un mec qui avait testé, en moyenne c'est 5-7µs, mais des fois ça tape sans raison à 17-18).

Après en gestion multi moteurs ça devient particulièrement pertinent d'utiliser les timers car en delay() c'est ingérable

Title: Re: [Moteurs PAP] un code qui marche?
Post by: 3Sigma on Oct 24, 2013, 07:41 pm
Une solution peut être d'utiliser digitalWriteFast. Explications et code ici:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1267553811/0 (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1267553811/0)
http://code.google.com/p/digitalwritefast/ (http://code.google.com/p/digitalwritefast/)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 24, 2013, 08:15 pm
oui ou encore mieux la manipulation des port directement ;)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 24, 2013, 09:21 pm
C'est exactement là-dessus que je travaille (enfin, pour l'instant, c'est une calvitie grandissante).

je définis une table de 8 pas (0001, 0011, 0010, 0110, 0100, 1100, 1000, 1001), et là-dessus, j'ai une int timer qui agit comme suit :

Code: [Select]

ISR(TIMER1_COMPA_vect){
  motor_step++;
  motor_step &= 0x07;
  PORTX &= 0xF0;
  PORTX |= table_step[motor_step];
}
Je ne pense pas qu'on puisse faire plus optimal. digitalWriteFast() m'oblige à faire pas mal de tests pour savoir sur quelle pin je mets false ou true. Et j'ai pour principe qu'un projet est dès le début bien pensé, donc le câblage ne changera jamais (il faut rêver dans la vie).

le truc, c'est que j'ai pas encore testé... et que je n'ai trouvé aucun code de ce genre déjà fait. (je ne vous ai pas mis les phases accélération, c'est juste pour poser les bases...)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 25, 2013, 08:20 am
Je comprend pas cette ligne :
PORTX &= 0xF0;

D'une part, tu écrit sur tes sorties un état intermédiaire non voulu (toutes tes sorties passe à zéro). Ensuite, au pire pour corriger ça, il suffit de faire :

  PORTX &= 0xF0 | table_step[motor_step];

Mais la solution optimale c'est tout simplement :

PORTX &= table_step[motor_step];

Avec table_step[] directement rempli avec les bons bytes. Genre :

byte table_step[]={0b11110011,0b11110110,0b11111100,0b11111001};
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 25, 2013, 12:56 pm
Quote

Mais la solution optimale c'est tout simplement :

PORTX &= table_step[motor_step];
mais non...
exemple : étata initial de PORTX : xxxx0011
on devrait donc passer à l'état suivant (table[step] = 11110110 ), donc faire PORTX = xxxx0011 & 11110110 = xxxx0010 on en a raté un.

Dans un souci de rapidité, je suis obligé de le faire en deux coups.

le premier (PORTX &= 0xF0) met mes 4 bits de sortie (0 à 3) à 0,
le second (PORTX |= table[step]) met les sorties à 1 selon le masque contenu dans table[step].

un &= ne peut que mettre des bits à 0, |= ne peut que mettre des bits à 1. on ne peut pas faire autrement que d'utiliser les deux. La première opération ne devrait durer que 3 cycles d'horloge, soit 190ns. Je ne pense pas qu'une transition à 0 si courte passe à travers le driver du moteur, et encore moins influer sur le courant dans les bobines...

PORTX = PORTX & 0x0F | table[step]; serait peut-être mieux, si le compilateur décide de passer par une variable intermédiaire, en décomposant l'opération par :

Code: [Select]

byte temp = PORTX;
temp &= 0xF0;
temp |= table[step];
PORTX = temp;


Du moment que ça prend toujours le même temps d'exécution! :)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 25, 2013, 01:58 pm
Autant pour moi c'est un ou exclusif qu'il faut, et en plus tu n'as plus besoin que d'une valeur : 0101

A supposer état initial xxxx0011

1) xxxx0011 ^=00000101 ==> xxxx0110
2) xxxx0110^= 00000101<<1 ==> xxxx0110^= 00001010 ==> xxxx1100
3)  xxxx1100 ^=00000101 ==> xxxx1001
4) xxxx1001^= 00000101<<1 ==> xxxx1001^= 00001010 ==> xxxx0011




à travers le driver du moteur, et encore moins influer sur le courant dans les bobines...



Le problème c'est la coupure de courant et donc la décharge des bobines ...


Code: [Select]

byte temp = PORTX;
temp &= 0xF0;
temp |= table[step];
PORTX = temp;


Du moment que ça prend toujours le même temps d'exécution! :)


Oué mais plus de passage à zéro ;)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 26, 2013, 08:03 am
OK, d'ac. ça ne marche par contre que pour 4 pas... mais bon...

mes premiers tests pas très concluants : pas d'accélération, mon moteur est resté à 30Hz, fréquence minimale dans mon code.

je reprends tout à Z.
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 26, 2013, 11:45 am
Bon, phase d'accélération réussie... en alimentant un PAP 24V en 12V et sans trop réfléchir au courant (bien sous-alimenté quoi!)(1), j'arrive sans souci à le faire monter à 6KHz à vide en demi-pas. Ca représente quand même une vitesse de courroie de 25,4 cm/s (10 pouces par seconde) pour une résolution est de 600DPI.

Sur un système à tige fileteé de 6mm directement sur le moteur, on aurait un déplacement de 1,5cm/s pour une résolution de 4000 ppcm (10 160 DPI).
Sur un système à tige fileteé de 8mm directement sur le moteur, on aurait un déplacement de 1,875cm/s pour une résolution de 3200 ppcm (8 128 DPI).

Pour mes tests, j'augmente la fréquence de 100Hz tous les 8 demi-pas, en partant de 30Hz. la vitesse max est donc atteinte au bout d'environ 500 pas (2 cm). peut-être un peu violent quand même...

Là où je suis content, c'est que le calcul de l'accélération et décélération se fait tout seul en fonction du nombre de pas à faire, et que si on demande 100 pas par exemple, l'accélération et décélération sont ajustées. j'appelle juste une fonction moteur_avance(int nombre_de_pas), la fonction déclenche un timer et rend la main tout de suite, ce qui permettrait de déclencher un autre moteur pendant que le premier fait son petit tour... le timer, lui, compte les pas et s'arrête quand il a atteint nombre_de_pas.

Tout se fait à partir de seulement deux données : le nombre de pas au bout duquel on augmente / diminue la fréquence (ici : 8 ), et la fréquence max (6000Hz). j'y suis presque...

désolé, je réfléchis un peu à voix haute... c'est une façon de garder des traces...

------------------------
(1) : en fait, le moteur est donné pour 3,9V / 1,41A, mais il est derrière un SLA7033M, driver qui régule le courant par PWM. D'origine, ce montage était alimenté en 24V dans un photocopieur et servait à faire avancer les originaux sur la vitre du scanner. Je n'ai rien mesuré, juste fait tourné la bestiole... J'imagine qu'alimenté en 24V, le moteur aurait plus de pêche (montée plus rapide du courant dans les bobines)
Title: Re: [Moteurs PAP] un code qui marche? et avec un capteur fourche?
Post by: Super_Cinci on Oct 29, 2013, 12:27 am
j'ai décidé de faire réfléchir mes outils à ma place.

Maintenant, je teste mon code avec ça :

(http://pop.studio.free.fr/imgtmp/131029_2.jpg)

En gros, un moteur pas-à-pas qui entraîne un charriot sur sa courroie. résolution : un pas = 600DPI, 1/2 pas = 1200 DPI, ça me convient.

Là, ça marche impec, accélération, décélération, marche, arrêt... Bon, j'ai pas non plus envie de tout casser (j'ai mis le charriot à la verticale, 3Kg dessus, le moteur le monte à 30Hz sans rien dire (en même temps, un moteur PAP, ça dit rien ou ça fait rien.)

Derrière, y'a ça :

(http://pop.studio.free.fr/imgtmp/131029_3.jpg)

rien de méchant, j'ai du bol, la platine en alu possède des glissières à écrous de 7mm partout, donc pratique! Pratique, oui, car du coup, j'ai mis un système de fin de course réglable (les flèches rouges), les deux extrémités coulissent, et (la flèche verte) un simple capteur fourche les vois, ou pas... un seul capteur est suffisant si on sait dans quel sens va le moteur. Je suis content, car c'est vraiment facile de déplacer les cales, j'espère pouvoir faire pareil avec les autres moteurs (le CNC prend vie je crois...)

(http://pop.studio.free.fr/imgtmp/131029_5.jpg)

les cales dans la fourche (désolé, c'est au mm, c'est bien caché!)

(http://pop.studio.free.fr/imgtmp/131029_6.jpg)

le capteur (collecteur ouvert) sort sur une entrée PCINT de mon nono. ben là, c'est le fourbi, car dès fois nono voit, des fois nono voit pas. j'ai mis des leds en témoin, mesuré le capteur (il sort 0,10V à vide, et 4,96V sur une fin de course, donc bon). L'interruption PCINT est bien lancée, mais la pin du capteur n'est pas toujours reconnue, du coup, dans un test où le charriot doit faires des AR entre les deux FDC, il va souvent plus loin, sans s'arrêter... (je fais pourtant attention au sens du moteur pour savoir de quel côté on est arrivé au bout!)

Un coup, mon charriot va faire 13 AR super, puis le 14ième, hop, il part dans le moteur! mais maintenant, le capteur n'est même plus reconnu, ça part dans les choux tout de suite!

BREF : quelqu'un a déjà essayé de jouer avec des capteurs fourche d'imprimante? (le mien est un shark S51, un grand classique). peut-être ai-je basoin d'un "debounce"?)

A par àa, j'ai joué avec ma lime (ben oui, j'ai pas de tour) et mes filières, j'ai réduit une tige filetée de 8 :

(http://pop.studio.free.fr/imgtmp/131029_0.jpg)

alors diamètre 8 parce que j'ai surtout des roulements de 8mm, et que niveau résolution finale, 12700 sonne mieux que 15875 DPI, et 6mm car la roue dentée qui va bien est en 6mm, avec un méplat bien sûr...

(http://pop.studio.free.fr/imgtmp/131029_1.jpg)

souis fier de moi là... mais bon, si j'arrive pas à gérer mes capteurs...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 29, 2013, 08:21 am
Comme ça c'est un peu à diagnostiquer, une fourche IR logiquement ça pose pas vraiment de problème ... Tu l'as branchée comment ?
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 29, 2013, 10:35 am
J'ai simplifié un peu mon interruption PCINT, car dans le principe, elle est appelée à chaque fois qu'il se passe quelque chose sur un capteur (il n'y en a qu'un pour l'instant, mais je risque d'en mettre 8 ). Donc je dois détecter les changements pour ne pas me prendre les pieds dans le tapis.

J'arrive donc maintenant à calibrer le déplacement à la mise en route.

Code: [Select]

  // calibration :
  if (x_capt) {  // le capteur est sur une fin de course
    pap_x_step(1200, true);  // avancer de 1 pouce
    wait_x;               // attendre que le moteur ait fini son déplacement
    if (x_capt) {  // on y est toujours? c'est qu'on doit être en butée haute
      pap_x_step(-2400, true);  // reculer de 2 pouces
      wait_x;              // attendre que le moteur ait fini son déplacement
    }
  }
      // on est en dehors des fin de courses
  pap_x_go(false, true);  // reculer à fond
  while (!x_BOT){}     // on attend le capteur de butée basse
  pap_x_stop;            // on est arrivé en buttée basse.
  x_abs = 0;               // position absolue = 0
  x_min = 0;              // position mini autorisée
 
  pap_x_go(true, true);  // on recherche la buttée haute, lancer le moteur en avant
  while (!x_TOP){}     // on attend le capteur de butée haute
  pap_x_stop;            // on est arrivé en buttée haute
  x_max = x_abs;      // position maxi autorisée
 
  pap_x_send(0, true);  // retour à l'origine
  wait_x;                        // attendre que le moteur ait fini son déplacement

Voilà, maintenant, on a défini la zone entre les deux butées : [x_min à x_max]. x_abs est la position absolue du charriot (par rapport à x_min) et est mise à jour pour chaque déplacement moteur..

mes fonctions implémentées sont :

pap_x_go(boolean sens, boolean acceleration) : lance le moteur en avant (sens = true) ou en arrière (sens = false). si acceleration = true, alors le moteur accélèrera jusqu'à sa vitesse max, sinon, il restera à vitesse min (30Hz par défaut). le moteur ne s'arrêtera jamais tout seul, il faut faire un pap_x_stop pour l'arrêter. (ne tient pas compte des capteurs)

pap_x_step(int n, boolean acceleration) : fait avancer le moteur de n pas. si acceleration = true, le moteur accélèrera au démarrage et décélèrera pour s'arrêter au bon endroit...

pap_x_send(int absolu, boolean acceleration) : envoie le moteur à une position absolue (en gros, fait pap_x_step(absolu - x_abs, acceleration); ).

Ces trois fonctions démarrent le timer du moteur, ce qui fait qu'une fois appelées, on peut faire autre chose pendant que le moteur fait son train-train (d'où la fonction wait_x par exemple, qui attend simplement que le moteur soit arrêté).

Côté capteurs, je crois qu'en fait, l'arrivée de ma plaque d'epoxy dans la fourche ne provoque pas une coupure franche du signal. du coup, il se peut que l'interruption soit appelée, mais qu'entre temps, le capteur ait encore changé, et du coup, la lecture de la in correspondante ne renvoie pas ce qu'il faut. je devrais peut-être essayer dans un premier temps avec un shmidt direct au cul du capteur.

le capteur est branché comme suit :

led alimentée à 20mA par une résistance de 220ohms (donnée à 50mA max)
phototransistor émetteur à la masse, et collecteur direct sur pin nono avec pull-up du nono.
le tout avec des fils de 50cm en l'air (mais ça ne joue pas trop.
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 29, 2013, 10:56 am
A voir avec une R de pull up plus faible sinon (typiquement 4.7k)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: 68tjs on Oct 29, 2013, 11:14 am

A voir avec une R de pull up plus faible sinon (typiquement 4.7k)

+1
A trop faible courant de collecteur la bande passante d'un transistor, donc son temps de réponse, n'est jamais terrible.
C'est la bonne solution que de diminuer sa résistance de charge de collecteur.
C'est aussi une bonne assurance pour ne pas être gêné par les courants de fuites qui fluctuent avec la température.
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 29, 2013, 12:20 pm
J'avais mis une résistance de 4,7k, au début en plus de la pull-up, mais je ne saturais plus le transistor (j'avais 0,6V, soit environ 9,4mA). les capteurs fourche n'ont pas un gros coëf de transfert... (rectif : j'ai 16,4mA dans la led, je devrais peut-être augmenter le courant à 30mA (rappel : 50 max)? ) un transfert IC / IF = 0,57, pas terrible...

(http://pop.studio.free.fr/imgtmp/131029_7.jpg)

Avec des petites leds qui m'indiquent ce que mon interruption détecte, je visualise un peux mieux ce qu'il se passe. en fait, comme il n'y a qu'un seul capteur, c'est le sens du moteur au moment de l'interruption qui détermine si c'est la butée haute ou basse (et aussi l'état de la pin à ce moment). ce qu'il se passe :

Le moteur descend, le capteur passe sur la butée basse, interruption -> stop moteur.
le moteur remonte, mais on est encore sur la butée, en quittant la butée, le capteur sautille un peu jusqu'à complètement quitter l butée, il y a donc des fronts montants, comme si on arrivait sur une butée -> le moteur monte, donc c'est pris pour une butée haute.

voilà : comment se retrouver avec une zone de 10 points...

Mon capteur fourche a une fourche de 3mm, ce qui est assez grand pour de l'opto, mais avec une plaque de 1,6mm qui passe dedans, il faut au moins ça. Mais ma plaque n'est pas très jolie sur les bords, donc en passant, elle ne coupe pas le faisceau d'un coup, mais plus ou moins, jusqu'à ce qu'elle occulte complètement. d'où mon idée de trigger matériel, mais aussi soft. dans mon programme de calibration, j'ai résolu le problème ainsi :

1 - trouver la butée basse, (dès le premier cri du capteur, on sait qu'on y est!)
2 - désactiver le capteur,
3 - remonter un peu (1 pouce),
4 - réactiver le capteur.

Là, on est bien sorti de la zone de turbullences. Si mon programme est bon, normalement, les capteurs ne devraient servir qu'au calibrage, et les moteurs par la suite ne devraient pas s'en approcher, sauf en cas de perte de pas.

Mais je me demande si rien qu'au niveau soft, je ne perds pas un pas à chaque mouvement... faut que je regarde ça de plus près...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 29, 2013, 01:50 pm
Dans la plupart des firmwares CNC le déclenchement d'une butée implique forcément une intervention humaine (ce qui est logique : butée = pièce foirée). Après je sais pas à quoi tu destines ton plateau
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 29, 2013, 02:09 pm

Dans la plupart des firmwares CNC le déclenchement d'une butée implique forcément une intervention humaine (ce qui est logique : butée = pièce foirée). Après je sais pas à quoi tu destines ton plateau
C'est pour ça que je ne me formalise pas trop au final. on pourrait même mettre des fin de course en // sur une seule entrée, car comme tu le dis, si on arrive en butée, c'est qu'il y a eu une couille quelque part, le soft doit normalement gérer les débordements.

Pour l'instant, le système que j'ai monté ressemble fort à un axe Y de CNC, on imaginerait donc le plateau comme support de l'axe Z (la tige filetée que j'ai préparée).
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 29, 2013, 08:19 pm
juste une question...

les moteurs PAP, ce sont des bobines. on les commande avec des "open-drain" ou encore source-commune. mais sur les circuits que j'ai récupérés, il n'y a pas de diodes de roue-libre.

A partir d'une alim de 24V, comme chaque pas est fait d'une PWM (SLA7033M), j'imagine (pas regardé) que ça doit piquer quand le courant est coupé. le driver est donné pour VDSmax = 100V, j'ai essayé des diode de roue libre sur l'alim, mais le moteur aime moins.

J'ai des super moteurs, mais ils demandent pas mal de tension (77ohms) donc certainement 48V, je risque de dépasser les 100V, non?
Title: Re: [Moteurs PAP] un code qui marche?
Post by: B@tto on Oct 29, 2013, 08:38 pm
C'est l'inductance de tes moteurs qui va générer des surtensions. Donc la tension, l'ampérage, la résistance des bobines ne sont en soit pas des indications. Et  la surtension générée est également dépendante de la vitesse de coupure.

Le SLA7033M est un pont en H de mosfet, ces derniers n'ont pas besoin de diode de roue libre, ils sont passant en sens inverse ;)
Title: Re: [Moteurs PAP] un code qui marche?
Post by: Super_Cinci on Oct 29, 2013, 09:38 pm
non non, le 7033 est bien un driver pour unipolaire (sortie sur 4 mosfets). j'ai eu un doute, car j'ai aussi un 6024, mais ce dernier est un réseau de darlington pour moteurs triphasé.

en même temps, le 7033 est donné pour 46V max en alim, sûrement qu'il y a un rapport avec les 100V...
Title: Re: [Moteurs PAP] un code qui marche?
Post by: alain19691969 on Nov 02, 2015, 07:02 pm
c'est un très bon programme pour commander les moteurs pap ça marche très bien  
mais j'ai un problème concernant la commande en rampe
merci
Title: Re: [Moteurs PAP] un code qui marche?
Post by: alain19691969 on Nov 02, 2015, 07:29 pm
j'ai besoin d'un programme complet pour commander un robot delta a base des moteurs pas a pas
j'utilise arduino uno et une carte tb6065 .le code de vince3838 ca marche tres bien mais j'ai un problème
avec la commande en utilisant une rampe lineaire