Problème pour utiliser l'horloge externe du PCA9685

[hinano70]

Voici un programme de principe qui devrait fonctionner, je ne l'ai pas testé, et un schéma (j'espère ne rien avoir oublié) du circuit. J'utilise un Méga2560.

Code: [Sélectionner]

#include <Wire.h>
#include <Adafruit_PWMServoDriver.h>

Adafruit_PWMServoDriver pwm1 = Adafruit_PWMServoDriver( 0x40 );// cantons alim 12V
Adafruit_PWMServoDriver pwm2 = Adafruit_PWMServoDriver( 0x41 );// cantons alim 12V

byte vitesse = 80;
byte pin0Driver1 = 0;  // pin0 du pwm1 : PCA9685 N°1
byte pin0Driver2 = 0;  // pin0 du pwm2 : PCA9685 N°2

void setup() {
pwm1.begin();
pwm1.setPWMFreq(60);
pwm2.begin();
pwm2.setPWMFreq(60);

pwm1.setPWM(pin0Driver1, 0, 20*vitesse);
pwm2.setPWM(pin0Driver2, 0, 20*vitesse);

//on peut aussi utiliser 2 pins de chaque PCA9685 pour pouvoir inverser le sens de circulation
}

void loop() {
}
Si on utilise le même PCA9685 pour alimenter les 2 cantons, pas de problème, si on en utilise 2, c'est là que le passage d'un canton à l'autre ne se fait pas correctement.
A essayer : différentes vitesse (0 à 200) et des fréquences différentes.

[simontpellier]

- Les 0V des ponts H et de l'Arduino sont ils reliés ?

- peux tu tester ce branchement qui est plus orthodoxe même si on peut en effet envoyer la PWM sur les gachettes :

"Les pins IN 1 e IN 2 nous servent à contrôler le sens de rotation du moteur 1, et les pins IN 3 et IN 4, celui du moteur 2. Ces pins fonctionnent:

    IN 1 -> HIGH; IN 2 -> LOW: le moteur tourne dans un sens.
    IN 1 -> LOW; IN 2 -> HIGH: le moteur tourne dans le sens inverse.

Et c’est pareil pour les pins IN 3 et IN 4 du moteur 2.

Pour contrôler la vitesse de rotation des moteurs on doit retirer les cavaliers des pins ENA et ENB. On les connecte à deux sorties PWM de la plaque Arduino de façon qu’on puisse envoyer une valeur entre 0 et 255 pour gérer cette vitesse des moteurs. Avec les cavaliers installés, les moteurs tourneront toujours à la même vitesse."

[hinano70]

Oui, tous les 0V sont reliés ensemble.
La solution que j'ai trouvée pour les ponts en H me paraissait plus intéressante car elle me fait gagner un fil (2 au lieu de 3 pour les cantons à double sens), mais je vais tester...

[hinano70]

J'ai déconnecté 2 cantons pour les connecter comme indique Simontpellier pour tester. Pas de tension ! Est-ce parce que tous les autres cantons sont encore commandés par les In1 et In2 ? Si il faut que je déconnecte tout pour essayer, ça va être galère ! Et je ne pense pas que ça règle le problème de désynchronisation des horloges. J'avais regardé à l'oscillo les signaux envoyés aux rails, ils étaient très propres en commandant sur IN1 et In2..

[simontpellier]

Bonjour,

non bien sûr le branchement "orthodoxe" ne resynchronisera pas les horloges mais le problème décrit N'EST PAS un problème de désynchronisme.

A nouveau, deux PVM désynchronisées, dont les créneaux sont donc décalés, ne pourront que s'ajouter à raison de ce décalage. Jamais se soustraire !! Les à coups et ralentissements rapportés sentent très fort le couac électrique. Le dernier test va aussi dans ce sens

Bon courage

[simontpellier]

héhé  ! peut-être une solution là  ?

https://www.pjrc.com/teensy/td_libs_ShiftPWM.html

- des PWM à volonté et synchronisées de fait !
- mais avec tout de même une limite, par le taux de rafraîchissement, inversement proportionnel au nombre de PWM ;
- un investissement à prévoir car une teensy c'est pas le même prix qu'une Arduino. Mais comme ça pédale beaucoup beaucoup plus vite, le taux de rafraîchissement ne devrait pas être un problème et il devrait même y avoir de la marge.

A bon entendeur

[trimarco232]

(...)
A nouveau, deux PVM désynchronisées, dont les créneaux sont donc décalés, ne pourront que s'ajouter à raison de ce décalage. Jamais se soustraire !!

Bonjour,
à condition toutefois, comme évoqué par JPM06, que les drivers ne soient pas commandés en low side pendant les crénaux bas du pwm ; cela expliquerait le broutage, et risque par ailleurs de détruire les composants, et les moteurs des locomotives
-> il convient par conséquent de bien maîtriser le principe de commande des drivers

[trimarco232]

héhé  ! peut-être une solution là  ?
https://www.pjrc.com/teensy/td_libs_ShiftPWM.html
- des PWM à volonté et synchronisées de fait !
- mais avec tout de même une limite, par le taux de rafraîchissement, inversement proportionnel au nombre de PWM ;
- un investissement à prévoir car une teensy c'est pas le même prix qu'une Arduino. Mais comme ça pédale beaucoup beaucoup plus vite, le taux de rafraîchissement ne devrait pas être un problème et il devrait même y avoir de la marge.
A bon entendeur

petit calcul sans prétention
on part sur :
40 sections, soyons fous, ce qui fait 5 registres du type 74hc595
une fréquence pwm de 20 kHz, pour sortir du spectre audible
128 crans de vitesse, valeur bien admise en MF

les régistres doivent être rafraîchis à une fréquence de 128x 20 000 = 2.56 mHz
pour chacune des 40 sections il faut 3 signaux provenant du contrôleur : 1 signal data, et 2 signaux d'horloge ; je vous fais grâce du latch à la fin, cela fait 120 signaux
pour respecter les délais, ces 120 signaux doivent être envoyés à la fréquence de 2.56 mHz, ce qui représente, pour les signaux, une fréquence de 300 mHz
autant dire tout de suite que ça craint à tous les niveaux
- le contrôleur ne peut sans doute pas faire pédaler ses sorties à cette vitesse, même s'il utilise un périphérique spécialisé
- les registres, même en technologie 74vhc, ne suivront pas
- le signal d'horloge, même à faible distance, ne sera pas assez raide (dans la loupe des timings) pour garantir un décalage sans perte de bit

à vos méditations, et à votre disposition pour eb discuter




on va faire un petit calcul

[simontpellier]

ah oui c'est intéressant, j'ai médité ! Et le calcul est imparable.

Mais deux questions sur les données de départ du calcul :
- 128 * 20 000 : je n'ai pas regardé la librairie mais si pour faire du 50%, par exemple, elle envoie 64 bits à 1 puis 64 bits à 0 par période! est-ce que ça ne serait pas franchement bestial... à moins que ça soit la seule solution ?? (personnellement je pratique les 74HC595 pour allumer/éteindre des led, avec un 1 ou un zéro... juste quant-il faut...)

- 128 * 20 000 : les 20kHz m'interrogent beaucoup et depuis longtemps, cad un peu plus d'un an que je découvre tout ça. Parce que mon (petit) réseau tourne avec un code dans lequel j'ai copié/collé : pwm.setPWMFreq(60) (Hz) (gamme de fréquence qu'utilise également Hinano ce qui fait que j'ai moins peur de la question vraiment trop stupide !)


Le post précédent également... m'ouvre des horizons insoupçonnés : la piqure de rappel du post de JPM06 me fait entrevoir le pb de la phase de non alimentation. Jamais rencontré dans aucun tuto web.
... comment fait-on pour "bien maîtriser le principe de commande des drivers" ?






 

[trimarco232]

concernant les messages à envoyer pour rafraîchir les rapports cycliques :
en effet, si pour un canal tu fais du 50% (valeur 64/128), tu envoies un 0 à 0 µs, puis un 1 à 25 µs, c'est assez cool
le souci, c'est si tu dois envoyer 65 sur le canal suivant, il va te faloir enchaîner en 1/(128*20000) Hz, et là ça coince, parce qu'on ne dispose que de 390ns pour renseigner les 40 cases du régistre à décalage, car l'inconvénient de ces registres est justement qu'il faut tout renvoyer à chaque fois

concernant les 60 Hz : c'est quelque chose de subjectif, cela fonctionne très bien ainsi, mais le bruit peut gêner, d'où l'idée de le déplacer à une fréquence non audible - sans doute que 10 000 Hz ça le fait aussi - ; si on peut se contenter des 60 Hz, le montage devient jouable

concernant les drivers, le risque c'est quand la locomotive est en train de passer d'une section vers une autre, et qu'un des drivers tire vers le 12v et l'autre vers le 0v : on a un court-circuit dans la locomotive ! il ne faut donc pas que le 2ème driver tire vers 0v quand son pwm est à 0, mais qu'il laisse sa sortie en l'air
il faut donc s'assurer dans la commande (le raccordement à l'arduino) du driver, que le niveau bas du pwm correpond à une sortie haute impédance et pas au forçage à 0v de la sortie ; consulter pour cela la documentation du driver, ou dis-moi quels sont tes driver, et je te dirai comment les raccorder

[simontpellier]

Bonsoir,
... c'est juste, c'est une erreur d'avoir raisonné comme si chaque registre était seul !

J'ai regardé la librairie ShitPVM. Un gros code ! A méditer là aussi. Et capable de s'auto-adapter aux processeurs tant Arduino que Teensy suivant le cas, mais... totalement orienté LEDs et pas utilisable en l'état pour conduire des moteurs. Dommage.
Mais l'idée des registres à décalage demeure et au moins pour l'exercice, peut-être pour un futur usage, je compte m'y coller.

La fréquence...
j'ai écouté un son de 60hz pur... c'est pour moi de l'infra-son à l'extrême limite de l'audible... définitivement, donc question réglée ! (sauf si c'est une fréquence qui devait se révéler incompatible avec le projet d'ajouter une mesure de fcem, en vue d'un asservissement de vitesse)

Et pour ce qui est des drivers, grand merci pour la proposition ! L'audit me sera précieux car à défaut de connaissances théoriques tout repose sur les infos disponibles sur Locoduino et web.
J'utilise des L298N, trois (...6 sections électriques), pilotés sur les pin "enable" par un PCA9685 et sur les gâchettes de polarisation par 2x6 bascules de registres 74HC595, en opposition deux par deux ; la branche "out" est donc toujours forcée à zéro. Aucun problème à ce jour puisque je n'ai pas (encore) dû utiliser plus d'un PCA9685.
Peut-être dire aussi que je n'actualise les pins des drivers que tous les 40millisecondes et que j'ai même testé beaucoup plus long sans rien remarquer en ce qui concerne la fluidité des accélérations/ralentissements.

Merci par avance !

[trimarco232]

Bonsoir,
si tu commandes le L298N par les entrées enable, c'est bon

[trimarco232]

j'ai réfléchi ... ! ... ?

il y a sans doute une solution beaucoup plus simple, tout dépend de la capacité de vos systèmes à la mettre en oeuvre, mais on est quand-même sur le forum locoduino, ça doit être possible !
l'idée, c'est de s'attaquer à la racine du problème, cad. à la transition entre deux pca9685, qui sont on l'a vu, forcément désynchronisés
on va prendre par exemple, pour fixer les idées, 31 sections, donc 2 pca :
- le 1er pca commande les sections 1 à 16, le 2ème pca commande les sections 16 à31
- donc la section 16 peut être, au choix, commandée par le 1er ou par le 2ème pca
- quand le train passe de la section 15 à la section 16, la section 16 est commandée par le 1er pca (pas par le 2ème) : la transition entre la section 15 et la section 16 se fait nickel
- quand le train passe de la section 16 à la section 17, la section 16 est commandée par le 2ème pca (plus par le 1er) : la transition entre la section 16 et la section 17 se fait chrome
- le choix duquel des 2 pca pour la section 16 se fait par un simple "ou câblé", avec 2 diodes et une résistance de pull down de 470R ; la sortie correspondante du pca qui ne commande pas la section 16 est simplement mise à 0%

que vous en pense-t-il ?

[simontpellier]

Bonsoir,

je n'ai pas réfléchi ... ! ... !
A ça en tous cas. Néanmoins l'approche paraît très pragmatique. Et qu'il me semble voir un néanmoins au néanmoins, qui est que la transition n'est jamais ni instantanée ni irréversible...

cependant j'ai réfléchi aux fréquences PWM et là c'est la panade complète!

Mais auparavant : cette idée que tu as suggérée (puis retirée ??) de registres 74HC595 pilotés en SPI rapide. J'ai fait un test, rapide également : 8 bits balayés en boucle, avec un NANO à la manœuvre ça fait pas mieux que 10microsec par bit ! et ça sans aucun code en parallèle sinon un comptage des loop. Un MEGA ferait probablement pas mieux. Et puis... le SPI natif, normalement c'est le bus CAN qui l'utilise ! Mais imaginons, car un "shiftPWM" est quand même une idée intéressante. Sauf que ce petit essai indique que si on pourrait peut-être émuler quelques PWM à 60Hz, une seule à 20kHz ne serait même pas possible ou en tous cas pas sans un processeur 100x plus rapide !

Et j'y arrive : l'ultra-panade PWM !
car entre 60Hz, "ma" fréquence, et les 10kHz, 20Kz du "petit calcul", et pourquoi pas 30kHz tant qu'à y être !! le gap est tellement énooorme que ça interroge. Et donc j'ai interrogé, relu, Locoduino : les timers, les PWM, (et même, sur le site de Jean-Luc survolé des articles sur les pertes Joule quand les PWM ne sont pas au carré). Or c'est précisément 30Kz qui est recommandé !! et on lit aussi que les 480hz des PWM Arduino standards sont "bien trop bas pour la bonne santé de nos moteurs". De quoi paniquer de les faire fonctionner en 60!

J'ai donc tenté de régler plus haut, x2, x4, x8... jusque 1kHz.
Le constat : plus c'était haut et plus les démarrages étaient tardifs et laborieux, et la vitesse max (à cran de PWM identique) basse. A 1000Hz, c'était injouable.

Alors idée aussi sotte que grenue : essayer l'inverse. Moins de 60 Hz !
Et là miracle ... des motrices (Fleischmann), qui démarraient un peu difficilement sur un lancement brusque et saccadé ont accepté de partir sur des ralentis de rêve (comme le faisaient assez bien les minitrix, plus tolérantes), avec plus de couple donc ? au point de pouvoir faire en silence, et attelées, un tour de réseau sans arrêt ni accroc à 7kmh constants (à l'échelle !), c'est bluffant. L'optimum ?  40Hz.

Qui pourrait expliquer tout ça ? Please !!

 

[simontpellier]

Aujourd'hui, essais plus sérieux.
En résumé rapide : avec 5 74HC595 en cascade, soient 40 PWM pilotées, la fréquence d'une PWM ajustable sur 100 crans est de 150Hz.
C'est proportionnel : avec un seul, le MEGA fait 730 loop/s.

Je suis impatient de comparer avec ce que fera la Teensy 3.5 que j'attends.
Mais il semble donc que ça puisse être exploitable si des fréquences dans cette gamme peuvent être acceptables ? (et même ??...) et une solution aux problèmes de désynchronisme.

Voici le code d'essai (si des amateurs ont envie de le booster ?)

Code: [Sélectionner]


/* ARDUINO MEGA */
const int SS_PIN = 53;     // SS(slaveSelect)/slave - pin 14 (DS / Serial Data Input) on the 74hc595
//const int SCK_PIN = 52;    // horloge ... inutile ?
const int MOSI_PIN = 51;   // MOSI (Master Out Slave Inv- The Master line for sending data to the peripherals) - pin 12 (ST_CP / Storage Register Clock Input (latch)) on the 74hc595

const int8_t number_of_74hc595 = 1;
const int8_t numOfRegisterPins = number_of_74hc595 * 8;
boolean pin74hc[numOfRegisterPins] = { 0 };

 // pseudos PWM à simuler - pour chaque PWM, le tableau donne le cran entre 20 et 120
uint8_t PWM[40] = { 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };   

/*---------------------------------------------------------------------------------------------------------------*/
void setup() {
  Serial.begin(115200);

  pinMode(SS_PIN, OUTPUT);
  pinMode(MOSI_PIN, OUTPUT);

  Serial.println("74HC595 test_vitesse");
}

void writeRegisters() {    // attention : spécifique à l'attribution des 3 PINs du SPI
  PORTA &= ~_BV(PB2);       // pin 51
  for (int8_t i((number_of_74hc595)*8-1) ; i>=0 ; i--) {
      if (pin74hc[i]==0) /*=>*/ PORTA &= ~_BV(PB0);   // pin 53
      else /*=>*/ PORTA |= _BV(PB0);
    }
  PORTA |= _BV(PB2);
}

void setRegisterPins() {  //Place les pins du 74HC595 à l'état HAUT ou BAS
  for (uint8_t i(20) ; i<121 ; i++) {
    for(uint8_t engine(0) ; engine<numOfRegisterPins ; engine++) {
      pin74hc[engine]=i<PWM[engine];
    }
  writeRegisters();
  }
}

void loop() {
    setRegisterPins();
    count++;

    if (millis() > 1000) {
      Serial.print(count);Serial.print("Hz");
      Serial.end();
    }
}


Deux images des pulses : A 50Hz, les créneaux sont bien propres, à 700Hz ça reste correct





à comparer avec une sortie d'un PCA9685 ! (à 40Hz. Ça ne ressemble que de loin à une PWM, pourtant ça marche toujours aussi bien)



En conclusion (provisoire), après avoir branché ces signaux sur les boosters, pas de doute ça fonctionne parfaitement. Différents essais dans la fourchette de fréquence permise par le montage, 50Hz / 700Hz, montrent à nouveau que c'est à 50Hz que la conduite est la plus souple et puissante. A noter aussi que la dégradation en augmentant la fréquence est beaucoup moins forte qu'avec les PCA9685, mais il faut se souvenir que ces derniers sont prévus pour commander des servos à 60Hz.