Problème tension en sortie de pont

Bonjour les amis,

Je reviens faire vous car vous m’avez sorti pas mal de fois du pétrin et j’ai une nouvelle problématique à vous soumettre :

Je vous joins le schéma bien sur.

J’ai donc un Arduino Nano qui commande un composant fort intéressant mais qui me pose quelques problèmes.

Il s’agit d’un DRV8432. La doc du pont est visible à cette adresse : http://www.ti.com/lit/ds/symlink/drv8432.pdf

Dans mon cas, il permet de commander deux moteurs 12V 3A nominal.

Les 4 PWM générée par l’Arduino commande la tension en sortie du pont.

A vide, j’ai bien une variation cohérente avec le rapport cyclique imposé. Au voltmètre, je vois ma tension variée de 0V à 10V (ouais y a la tension de déchet du composant que je n’avais pas anticipé)

En charge, je n’ai plus rien… 0V…

J’ai alors regardé les info d’erreur qui sont remonté sur les pins 11 et 12 de l’arduino mais pas de problème j’ai du 5V sur les deux ce qui signifie que le composant fonctionne dans les conditions normales.

J’ai ensuite diminué la valeur de la résistance d’ajustage de courant de sortie, sur le schéma c’est R7. Mais rien n’y a fait.

Je me demande donc si je suis bien dans le bon mode de fonctionnement, c’est à dire M1=0, M2=0 et M3=0.

Je suis vraiment à cours d’inspiration… si quelqu’un à une idée.

Merci.

Yep!

Perso, à regarder ton shema, je m'interroge déjà sur l'interêt des diodes sur les lignes pwm ainsi que de la tension de 3.3 volts. J'ai l'impression que tu fonctionnes à l'envers. Lorsque la pinoche de l'arduino passe à 1dans un cycle, le courant est bloqué alors que le driver attend une tension, etc...

Ne peux-tu pas piloter directement les pwm du driver avec ton arduino comme le montre le datasheet ???

@+

Zoroastre.

L'intérêt de ces diodes est primordial. Elles permettent d'assurer une compatibilité statique entre le microcontrôleur, ici l'arduino nano, et le pont en H car en sortie de l'arduino on a 0V où 5V alors que le pont en H n'accepte que du 0V 3V3... c'est écrit dans la datasheet dans les tableaux sous les dénominations Voh Vol.

Le problème n'est pas là.

Bonjour,

La Nano ne fournit du 3.3V que si elle est alimentée par l'USB : (doc hardware arduino)

"The FTDI FT232RL chip on the Nano is only powered if the board is being powered over USB. As a result, when running on external (non-USB) power, the 3.3V output (which is supplied by the FTDI chip) is not available ......"

Donc sur les lignes de sorties D5 à D10 le tirage à 3.3V ne marche pas si l'alim est externe à l'usb.

Je suis vraiment étonné de ce que tu dis car à l'oscillo, je vois bien que ma PWM change de niveau 5V à 3V3

De plus j'ai vérifié, et j'ai bien du 3V3 sur la pin correspondante...

En effet, je viens de vérifier avec ma Nano Version 3.0, le 3.3v est actif avec alim externe. Bonne surprise :grin: La doc arduino n'est pas à jour. Elle concerne la version 2.3.

Le FT232RL peut fournir le 3.3V jusqu'à 50mA d'après FDICHIP.

D'accord, merci d'avoir vérifié.

C'est la raison pour laquelle j'avais répondu à zoroastre que le problème que je rencontrais ne vient pas de là.

Sinon, j'ai réussi à faire tourner mon moteur... mais c'est très bizarre :

  • J'arrive à le faire tourner quand j'actionne la commande ; le moteur tourne mais avec des a coups (cela du à une tension PWM bruité et pas très belle que j'ai osbervé au scope)
  • Dès que je relâche la commande et que je la ré-actionne plus rien... je perds la tension... vraiment bizarre...

Je ne sais pas trop quoi faire.

Je n'ai jamais encore regardé les sorties PWM à l'oscilloscope mais es-tu certain qu'elles sont bien phasées l'une par rapport à l'autre pour chacune des paires (A & B, C & D)? C'est la condition indispensable au bon fonctionnement du pont.

Personnellement je tenterais plutôt de faire fonctionner le circuit en mode4 qui lui justement ne demande qu'un PWM par moteur et gère tout seul les deux demis-ponts.

Yep!

cela du à une tension PWM bruité et pas très belle que j'ai osbervé au scope

Le datasheet semble trés précis sur la manière de câbler et créer le circuit (sans compter une bonne paire de révision), tu nous as fournis que le shématic, cependant, il y a peut être des choses à revoir du côté des découplages et filtrages des alimentations (ou des signaux).

Bon en même temps je dis çà même si je pense que tu es plus calé dans le domaine apparement ;)

@+

Zoroastre.

J'ai codé de la manière suivante : la première PWM commande le demi pont, il commande donc le sens de rotation du moteur gauche alors que le deuxième PWM commande en sens inverse. Cela marche de la même manière pour le moteur droit.

Je pense que cela était la meilleure manière de coder, car a vide, c'est-à-dire sans rien de brancher un extrémités de mes sorties moteurs un et moteur deux. La variation de tension se faisait correctement. Je visualisez donc bien une tension négative quand les PWM un et trois était activées, et une tension positive quand les PWM 2 et 4 était activées.

Ton inspiration est bonne zoroastre, je pense que je vais découpler tout ce beau bordel je vous tiendrais au courant des résultat ! Merci de votre aide c'est très réconfortant !

salut

quelqu'un de bien qui a un oscillo ! :D regardes ton +bat à l'oscillo au demarrage du ou des moteurs, voir s'il ne chute pas trop ! il y a une sécu si l'alim descend à 9,8 volts.

bon courage

Chabot380

C’est vrai que c’est une bonne idée, je n’y avais pas pensé du tout. Ca me permettra de voir si il s’agit bien d’un couplage.

Tu l’as vu où l’info sur la sécurité à 9.8V ?

J'ai codé de la manière suivante : la première PWM commande le demi pont, il commande donc le sens de rotation du moteur gauche alors que le deuxième PWM commande en sens inverse. Cela marche de la même manière pour le moteur droit.

D'accord mais cela ne prouve pas que les signaux générés à destination des deux demi-ponts commutent bien au même moment. Il n'y a aucune information dans les docs arduino qui indique comment se présentent les sorties PWM l'une par rapport à l'autre dans le temps. S'ils sont décalés, par exemple, il va y avoir un temps mort. A vide ce genre de problème n'a pas de conséquence puisqu'on ne consomme pas de courant.

Oui j'y avais pensé.

En effet, j'avais déjà vu des composant qui ne géré pas les temps mort et ça avait l'air assez complexe à résoudre.

Il faudrait que j'arrive à être sûr que les PWM soient cadencées sur le même timers, nan ?

Ce que je sais c'est que j'ai mes PWM A et B qui sont à une fréquence de 490Hz environ et les PWM C et D qui elles sont à 970Hz.

J'avais espoir que le pont de commande gère les temps morts... dans le cas contraire, je ne sais pas trop quoi faire...

J’avais espoir que le pont de commande gère les temps morts… dans le cas contraire, je ne sais pas trop quoi faire…

Je n’ai lu la doc de ton composant qu’en diagonale hier mais il me semble que le mode 4 comme je l’ai proposé dans mon précédent post devrait résoudre ton problème puisqu’il ne nécessite qu’un PWM et qu’il fabrique le signal complémentaire en interne pour attaquer le second demi-pont. Peut être qu’il y a des inconvénients à utiliser ce mode mais ma lecture rapide ne m’a pas permis de les voir.

Ce mode avait aussi retenu mon attention, mais je m'étais demandé comment faire tourner les moteurs dans les deux sens :

  • Sens des aiguilles d'une montre (moteur 1 et 2) : PWM_A et PWM_C de 0 à 255
  • Sens contraire : ......

Je sais pas...

PWM < 50% moteur tourne dans un sens
PWM à 50% moteur arrêté
PWM > 50% moteur tourne dans le sens inverse

Ha d’accord genre un peu comme un servomoteur…

En tout cas, j’ai quelques nouvelles… maintenant que j’ai branché deux moteurs, ça fonctionne à peu près avec des à coups.

J’ai donc pris quelques images de signaux :

  • La variation de la tension d’alimentation (2 images - DS0017 et DS0018)
  • La tension aux bornes du moteur (1 image - DS0020)

Ils ne sont vraiment pas beau mais j’ai mon idée sur comment contrecarré tous ces parasites.

Mais j’attend vos remarques et suggestions car je pense que vous avez très envie de voir ces beaux (ou pas) signaux…

Le grande question étant est-ce que la variation de la tension visible sur les deux premières images est responsable du signal bruité (qui me cause ces à coups)…

DS0017.BMP (13.1 KB)

DS0018.BMP (13.2 KB)

DS0020.BMP (18.6 KB)