Commuter plusieurs signaux AC avec une commande

[Hug1]

Par curiosité, qu'est-ce qui peut nécessiter une telle précision temporelle pour des moteurs ?

Bonjour,

Le système est très exigeant et complexe mécaniquement ; cette désynchronisation entraîne des vibrations qui perturbent le fonctionnement de l'ensemble. Plutôt que de revoir l'ensemble mécanique (d'étudier la résonance, la répartition des masses, des points d'équilibre,....), cette synchronisation résout ce problème.

Cela serait trop complexe de l'expliquer ici, mais la précision temporelle est justifiée par l'architecture mécanique qui est également très précise.
-----

[jiherve]

re
mis à part ton système de commutateurs (attention aux transitions et Triac à proscrire ) je ne vois guère que l'utilisation des commandes STEP et DIR qui permette de synchroniser les pas.
ces commandes sont facile à générer de façon rigoureusement synchrone.
JR

[bobflux]

Cela serait trop complexe de l'expliquer ici, mais la précision temporelle est justifiée par l'architecture mécanique qui est également très précise.

OK

Actuellement tes deux drivers ont chacun leur horloge. Donc leurs fréquences de PWM ne sont pas identiques, et il doit donc y avoir une vibration mécanique correspondant au battement (la différence entre les deux fréquences PWM).

Si tu les alimentes tous les deux avec la même horloge, ce problème serait éliminé car leurs PWM seront dérivés de la même fréquence d'horloge, mais il restera probablement une différence de phase entre les deux PWM. Si les deux circuits s'initialisent à la mise sous tension, l'un peut être plus lent que l'autre et donc avoir un décalage de phase. Peut-être possible de l'annuler par un reset manuel des deux drivers en même temps, il faudrait vérifier.

Il est possible que tes problèmes de vibrations soient liés à ça : que le fait de démarrer les drivers en même temps les synchronise, par exemple. Il faudrait vérifier.

Si mon intuition est correcte et que cette histoire de fréquence PWM ou phase différente entre les deux drivers est un problème, alors utiliser STEP/DIR ne le résoudra pas. Si le problème ne vient que du SPI, alors oui.

Normalement, ce que jherve proposait dans la page d'avant devrait fonctionner, c'est le cas "Daisy Chain" dans ce document :

MCU OUT -> IN_driver2_OUT -> IN_driver1_OUT -> MCU IN

Baisser /SS, pousser les 2 trames dans le SPI, la première trame passe à travers driver2 et est reçue par driver1, la seconde trame est reçue par driver2... puis remonter /SS pour que les deux drivers prennent les trames et s'activent au même instant. Donc un seul appel SPI arduino, mais avec les 2 trames dedans.

C'est comme ça qu'on synchronise des DAC SPI par exemple.

Si tu dis que ça ne marche pas, il doit y avoir un problème ailleurs. Est-ce que tu peux mettre un schéma ?

Je me demande si ça n'irait pas plus vite de prendre un micro avec une tonne de PWM (style STM32) et faire le stepping en logiciel...

[jiherve]

re
avec STEP et DIR c'est forcement synchrone car STEP induit l'avance d'un pas , inconvénient les consommations s’additionnent. Pour une CNC que j'ai bricolée je pilotais en déphasé les moteurs X et Y pour lisser les appels de courant.
JR

[Hug1]

Bonjour,

Normalement, ce que jherve proposait dans la page d'avant devrait fonctionner, c'est le cas "Daisy Chain" dans ce document :

MCU OUT -> IN_driver2_OUT -> IN_driver1_OUT -> MCU IN

En appliquant le "Daisy Chain", le premier driver à qui j'envoie mes trames, ne va pas traiter la commande avant le second ? Dans tous les cas un driver reçoit l'information avant l'autre ici ?

Si les deux circuits s'initialisent à la mise sous tension, l'un peut être plus lent que l'autre et donc avoir un décalage de phase. Peut-être possible de l'annuler par un reset manuel des deux drivers en même temps, il faudrait vérifier.

Je devrais le voir à l'oscilloscope ça non ? Quand j'observais la même phase pour mes deux moteurs je ne voyais pas de différence particulière



Voici le montage que j'avais réalisé, à noter que j'ai aussi décâblé le MISO par la suite pour être certain qu'aucun ne répondent sur le bus SPI.
J'ai aussi soudé les deux CS ensemble pour un essai par la suite, sans succès.

Je vais introduire un oscillateur externe pour faire mes essais, si cela ne marche pas j'introduirai le "Daisy Chain" comme vous l'avez suggéré, même si je reste perplexe.

Je me demande si ça n'irait pas plus vite de prendre un micro avec une tonne de PWM (style STM32) et faire le stepping en logiciel

On pourrait surement le faire, mais c'est toujours plus simple d'avoir un bus SPI ou UART même.

Merci pour vos conseils, je vais essayer tout ça

[bobflux]

En appliquant le "Daisy Chain", le premier driver à qui j'envoie mes trames, ne va pas traiter la commande avant le second ? Dans tous les cas un driver reçoit l'information avant l'autre ici ?

Non, le principe du SPI est que chaque driver contient un registre à décalage (FIFO).

À chaque impulsion sur SCK, il décale le registre d'un bit, donc il rentre un bit depuis SDI dans le registre et sort le bit le plus ancien sur SDO.

Tant que /CS ne remonte pas, le driver ne regarde pas le contenu de ce registre à décalage : ça ne servirait à rien car tant que /CS est bas, tous les bits ne sont pas arrivés.

Donc les commandes pour le driver 1 vont traverser le registre du driver 2 (à la queue leu leu) jusqu'à ce que les deux registres des deux drivers contiennent les deux commandes.

Quand /CS remonte sur les deux drivers, ils traitent la commande dans leur registre, en même temps. La même ligne /CS est connectée aux deux.

Côté micro, le process est: baisser /CS, envoyer les 2 trames sans remonter /CS entre les deux, et remonter /CS à la fin. Donc si tu utilises une librarie qui gère le /CS, il faut lui faire faire un transfert de 80 bits (2 commandes de 40 bits).


C'est le truc habituel et standard normalement ça doit fonctionner

[Hug1]

Tant que /CS ne remonte pas, le driver ne regarde pas le contenu de ce registre à décalage : ça ne servirait à rien car tant que /CS est bas, tous les bits ne sont pas arrivés.

Incroyable, c'est vrai que dit comme ça, ça correspond parfaitement à mon besoin .

Côté micro, le process est: baisser /CS, envoyer les 2 trames sans remonter /CS entre les deux, et remonter /CS à la fin. Donc si tu utilises une librarie qui gère le /CS, il faut lui faire faire un transfert de 80 bits (2 commandes de 40 bits).

D'accord je vais essayer cela

[jiherve]

bonjour
réponse déjà donnée au #15,#26,#28 !
JR

[Hug1]

Bonjour,

J'ai reproduit cette configuration de daisy chain (avec uniquement deux drivers [slave]) :
arduino-spi-tutorial-daisy-chain-config-1006x1024.png

Voici la fonction qui me permet de déplacer mes moteurs, je fourni ma commande + data dans posA avec sa taille dans size. (j'ai bien vérifié que sa taille est de 5 octets de 8 bits)
Je met dans settingsA les spécifications du SPI, MSBFIRST, la vitesse, etc....

codee.PNG

J'ai aussi une liaison série pour débugger.
Comme on peut le voir, j'envoie deux fois mes données posA avec SPI.transfer en mettant csn à l'état bas avant et à l'état haut après.
(J'ai mis un très grand délai, le temps de passer mon oscilloscope en single, vu que je fais des configurations avant)

Sauf que c'est uniquement le second driver qui fait tourner son moteur... J'essaye d'envoyer posA qu'une fois, résultat : c'est uniquement le premier driver qui fait tourner son moteur.

Lorsque je l'envoi qu'une fois, je vois que le second driver, reçoit aussi des trames.
C'est probablement dû à la bibliothèque SPI qui envoie une réponse du driver 1 sur le MISO du second driver.
Encore mieux, le driver 2 répond aussi sur son MISO pour l'envoyer à l'arduino.

Est-ce que c'est lié au fait que le driver 2 et 1 ont la même connexion pour le SCK ? Où est-ce la bibliothèque d'arduino qu'il faut changer (SPI.h) ?

[jiherve]

bonjour
il faut envoyer 80 bits d'un coup, et éviter les serial print et delais qui ne servent à rien.

S'il y a des configurations de registres avant il faut toujours les faire en 80 bits et comme je l'avais mentionné plus haut en lecture le fonctionnement ne me semble pas clair donc à éviter.
pour la synchronisation du scope je créerais une pin de debug activée comme le CSn mais uniquement au bon moment .
et lire attentivement :https://www.arduino.cc/reference/en/...unication/spi/
il faut spi begin avant spi begintransaction mais peut être est ce fait avant?
JR

[Hug1]

D'accord merci, après quelques corrections du code, j'arrive bien à obtenir le mouvement de mes deux moteurs, cependant j'ai encore un décalage important, quasiment 1 ms.



Alors c'est plus ou moins approximatif avec le placement de mes curseurs, des sondes, du bruit que j'ai, etc....

Cependant, lors du déclenchement, je remarque qu'ils se déclenchent plus ou moins en même temps (en tout cas je n'arrive pas à mesurer le délai).
Je vais regarder mon code, il doit y avoir une coquille.

[jiherve]

re
que représentent ces signaux?
tu as un scope Yoko ce n'est pas courant, ce sont de bon appareils mais trop chers pour un amateur .
JR

[bobflux]

Procédons par élimination...

Essaie voir de zoomer sur le déclenchement, on le voit bien ça fait un décrochement dans le signal... et donc de mesurer si il y a un délai entre les deux canaux.

[Hug1]

Bonjour,

Le déclenchement est de l'ordre de la dizaine de us :

que représentent ces signaux?

J'ai pris deux sondes ampèremétriques, l'un placé sur la phase 1 du moteur 1 et l'autre sur la phase 1 du moteur 2. Cependant, ceux-ci n'ont pas les même rapports (et j'ai pas passé les voies en courant aussi, vu que je m'intéresse seulement au décalage pour l'instant).

[Hug1]

Mes signaux sont plus ou moins synchronisés au départ, puis sont de plus en plus déphasés jusqu'à être en opposition de phase (et se resynchroniser derrière).

Vu que les drivers disposent d'algorithmes comme le StealthChop ou le SpreadCycle, il est possible que la clock interne qui soit différente, introduise un pilotage différent du chopper qui provoque ce décalage.

C'est ce qui me semble le plus probable.

Sinon c'est également possible que la différence physique des moteurs puisse provoquer des comportements différents de ceux-ci, ce qui provoquera ces différences.

[bobflux]

OK donc tu as un décalage tout petit au démarrage, probablement dû à la différence de phase entre les PWM des deux puces dont je parlais avant.

Si tu regardes tout à droite de l'oscillogramme du post 41 tu verras que le décalage de phase entre les deux sinus augmente avec le temps. Là où tu as mesuré, tu trouves 1ms, mais à droite de l'écran du scope c'est carrément décalé d'une demi période.

Autrement dit, il y a un moteur qui tourne plus vite que l'autre, de quelques %. Probablement parce que l'horloge interne d'un des drivers est plus rapide que l'autre.

Dans la datasheet (page 99) il est indiqué que la précision de l'oscillateur interne est de +/-30% ce qui est normal pour un oscillateur RC interne non calibré. Voilà ton problème.

Donc, il faut impérativement que tu alimentes tes deux drivers avec une horloge externe propre, la même horloge pour les deux.

Bon je vois après avoir posté que tu es arrivé à la même conclusion

[polo974]

les TMC5072 sont "intelligents", c'est à dire qu'ils vivent leurs vies dans leur coin, (ils génèrent les rampes d'accel, les ajustent de vitesse selon les limites de courant ou autres, bref, bye-bye, le synchronisme avec les copains). il semble qu'on puisse synchroniser les 2 moteurs d'un même TMC, mais rien n'est prévu pour une sychro inter TMC5072.

pour un contrôle 'pile poil' il faut tout faire à la main (les rampes, tout ça...) et passer en step/dir. mais c'est pas suffisant. il faut soit pouvoir reseter les compteurs internes de (micro)stepping ou gérer ce décalage entre 2 moteurs... (par ex pour le TMC2100, il y a la sortie INDEX qui peut être exploitée)

mais en fait, il faut surtout pouvoir garder un synchronisme mécanique, donc, en plus de la synchronicité du stepping, il faut avoir un zéro (ou autre si encodeur absolu) mécanique initial.

[jiherve]

bonjour,
utiliser une horloge commune aidera mais attention à l'usage éventuel de modes savants offerts par les contrôleurs je ne suis pas sur que bien que déterministe leur timing soit strictement identique d'un contrôleur à l'autre ou même d'une repetition à l'autre sur un même contrôleur.
Grillé mais il y en a donc d'autres qui lisent les DS et comprennent entre les lignes!

mais en fait, il faut surtout pouvoir garder un synchronisme mécanique,

perte de pas interdite, çà c'est imparable sauf codeur absolu sur les deux moteurs.
JR

[bobflux]

utiliser une horloge commune aidera mais attention à l'usage éventuel de modes savants offerts par les contrôleurs je ne suis pas sur que bien que déterministe leur timing soit strictement identique d'un contrôleur à l'autre

Oui je gardais ça pour l'épisode suivant

Ces puces sont remarquablement opaques, quasiment du Apple

Si ça marche avec une horloge commune, ce serait beaucoup plus simple que de refaire les rampes à la main...

[Hug1]

mais en fait, il faut surtout pouvoir garder un synchronisme mécanique, donc, en plus de la synchronicité du stepping, il faut avoir un zéro (ou autre si encodeur absolu) mécanique initial.

Ça c'est faisable, en tout cas pour synchroniser les micro-pas initialement.

Pour un contrôle 'pile poil' il faut tout faire à la main (les rampes, tout ça...) et passer en step/dir. mais c'est pas suffisant. il faut soit pouvoir reseter les compteurs internes de (micro)stepping ou gérer ce décalage entre 2 moteurs.

Gérer le décalage, j'y ai pensé aussi, mais en direct, (recevoir l'info, la traiter, la corriger) ça demande d'avoir une régulation exceptionnelle, si on parle de us, c'est vraiment pas évident. Le problème du step/dir c'est que ça me demanderait des canaux distincts pour les quatre moteurs, là ou pour le SPI un unique bus peut suffire.

J'ai espoir avec cette horloge externe, ça m'étonnerait beaucoup qu'avec la même commande, la même horloge, les mêmes drivers décident d'avoir un pilotage radicalement distinct, mais on sait jamais

[jiherve]

re
non pour contrôler n step/dir cela peut se faire aussi avec un bus série pilotant un 74595, ou un récepteur(expander) i²C.

'ai espoir avec cette horloge externe, ça m'étonnerait beaucoup qu'avec la même commande, la même horloge, les mêmes drivers décident d'avoir un pilotage radicalement distinct, mais on sait jamais

s'il y a du calcul et un soupçon d'asservissement c'est sans espoir.
JR

[bobflux]

s'il y a du calcul et un soupçon d'asservissement c'est sans espoir.

Tant que la détection de calage (stall) ne déclenche pas, je pense que les 2 drivers devraient suivre la même rampe et donc être synchronisés, mais... c'est surtout parce que je suis optimiste !

[jiherve]

re
moi quand c'est flou c'est qu'il peut y avoir un loup donc je repart de zéro et je conçois tout mais c'est sans doute une déformation professionnelle due à mon parcours.
JR