Commuter plusieurs signaux AC avec une commande

[Hug1]

Bonjour,

Je vous écris car je me sens limité par mes connaissances actuelles dans la recherche d'une meilleure solution.

Je vous explique : je souhaite mettre en place un aiguillage électronique. À l'aide d'une commande en tension (environ 5V), je veux contrôler le passage ou non de signaux AC.
Les signaux sont de +24/-24V avec des courants importants, environ 700mA. Je précise que je recherche des composants en CMS.


J'ai d'abord pensé à un MUX analogique, pas numérique. Cependant, étant donné les courants et la tension impliqués, il semble introuvable (ou alors je n'ai pas cherché au bon endroit).
Ensuite, j'ai envisagé l'utilisation de relais. Ils sont simples à piloter, mais bruyants, encombrants, et les cycles de commutation sont limités.

J'ai alors pensé aux MOSFETs. Toutefois, en état bloqué, avec le courant inverse (sur la diode), sauf si on opte pour un modèle surdimensionné, ça va pas durer longtemps .

Je suis ensuite tombé sur les triacs, qui me semblent être la meilleure solution. Cependant, la conception s'annonce complexe, en particulier si j'en ai besoin de 8. En tenant compte des chutes de tension et de la gestion thermique potentielle, je ne suis pas sûr de réussir.

Finalement, j'ai exploré les relais statiques (sortie thyristors ou triacs), qui sont en quelque sorte des opto-triacs. Cependant, ils me paraissent encombrants, ne sont pas si courants que ça (ce qui pourrait poser problème pour la continuité du projet) et nécessitent des courants importants (généralement 50 mA pour cette application).

Pour moi, la meilleure solution, si je souhaite éviter les relais, reste les triacs. Cependant, la conception risque d'être complexe. Avez-vous d'autres idées pour résoudre mon problème ?

Je suis convaincu qu'il existe une solution simple, semblable aux relais, mais je ne la vois pas.

Merci d'avance,
-----

[gienas]

Bonjour Hug1 et tout le groupe

Bienvenue sur le forum.

... À l'aide d'une commande en tension (environ 5V), je veux contrôler le passage ou non de signaux AC.
Les signaux sont de +24/-24V avec des courants importants, environ 700mA ... reste les triacs. Cependant, la conception risque d'être complexe ...

Tout n'est pas bien clair et aucune réponse ne peut être assurée.

Tu parles de AC mais tu spécifies des valeurs signées. C'est incompatible.

Triac et SCR ne sont pas vraiment pilotables. Une fois amorcés, ils "ne savent pas" s'arrêter. C'est le courant qui doit s'annuler ou mieux, s'inverser.

Si c'est en alternatif, c'est envisageables, en acceptant de laisser conduire jusqu'à le fin de la demi période en cours.

Il faudrait donc que tu expliques très précisément ce que doit faire cet "interrupteur".

[Hug1]

Merci pour votre réponse.

Veuillez m'excuser pour la confusion : lorsque je mentionnais "AC", je voulais dire que j'ai un courant alternatif. En réalité, les signaux sont des phases moteur, provenant d'un pont en H, avec un courant oscillant.

Pour expliciter davantage le fonctionnement de mon système, je dispose de deux drivers moteurs, chacun équipé de quatre phases moteur. Ces drivers permettent de piloter deux moteurs pas à pas de manière distincte.

Dans le cadre de mes essais, je souhaite pouvoir basculer ou non les phases de mon premier driver afin qu'il pilote les deux moteurs (en adaptant les courants, évidemment).

Pour cela, je pourrai le représenter de la manière suivante :
image_1.PNG

Et à l'inverse, selon une commande, de la manière suivante :
image_2.PNG

Comme il me faut une synchronisation très précise de mes moteurs, cette méthode d'aiguillage semble être la meilleure solution.

Je procède comme suit : je désactive mes drivers, je les configure, je commute mes signaux, puis j'active mes drivers. Si je change de mode, je désactive de nouveau mes drivers, les reconfigure, commute mes signaux, et les réactive.

[niala72bis]

En effet c'est obscur et nécessiterait un synoptique.

Je pense à un fabricant innovant de composants de puissance en cms, Micro Power Systems :

https://www.monolithicpower.com/

Je vous invite à parcourir le site, c'est impressionnant, j'ai déjà utilisé, et je crois avoir un contact

[A voir en vidéo sur Futura]

[lutshur]

Bonjour,
https://toshiba.semicon-storage.com/...odName=TLP3547
https://toshiba.semicon-storage.com/...odName=TLP3547
Sauf si le courant de démarrage des moteurs dépasse 5A, ça devrait convenir. Je n'ai pas lu le datashhet en entier.
Sinon, il faudra passer par des Mosfets externes plus puissants.
https://toshiba.semicon-storage.com/...odName=TLP3547

[Hug1]

Bonjour,

Effectivement, cela semble approprié. Bien que cela puisse revenir un peu cher pour mettre en place cette fonction(et que cela prenne beaucoup de place), l'idée d'utiliser deux Mosfets montés tête-bêche, à la manière d'un triac, pourrait être envisageable. Je vais approfondir cette idée en consultant les fabricants et en examinant les différents liens que chacun a envoyés.

Merci

[jiherve]

bonjour
ne serait il pas possible de piloter les drivers ?
JR

[Hug1]

Bonjour,

Si bien sûr, c'était d'ailleurs ma première piste. Mais après mes essais, j'ai une désynchronisation de l'ordre de plusieurs us, entre mes signaux. (Ce décalage est induit par l'exécution séquentielle des instructions pour piloter les moteurs [tourner moteur 1, tourner moteur 2 pour vulgariser[)

Dans mon application, cela est problématique, le seul "bon résultat" que j'ai obtenus était en soudant les moteurs sur une même sortie du driver. (Et en adaptant les courants)

Cependant j'ai toujours besoin de pouvoir piloter mes deux moteurs distinctement, d'où le fait que je souhaite réaliser cette aiguillage.

J'ai parcouru différentes gammes de driver, mais je crains qu'il n'y ait pas plus efficace que de mettre les deux moteurs sur la même sortie.

Merci encore

[gienas]

... J'ai parcouru différentes gammes de driver, mais je crains qu'il n'y ait pas plus efficace que de mettre les deux moteurs sur la même sortie ...

Tu as éliminé le relais pour des questions d'usure. Je n'ai pas la moindre idée de tes cadences, mais un relais qui ne commute aucune intensité (et donc aucune tension) ne s'use pas. S'il est préparé et commuté hors tension, il n'y a aucune étincelle donc pas d'usure à attendre sur ses contacts.

[jiherve]

re
je ne sais pas quel µC tu utilises mais si les moteurs étaient pilotés en assembleur l’écart ne devrait pas dépasser qqs centaines de ns.
JR

[Hug1]

Pour l'usure des relais, j'ai lu dans les documentations techniques des usures mécaniques et des usures électriques, autour des 500 000 cycles de commutation.

Vu la fréquence de commutation du mouvement que je souhaite faire et la longue longévité que je souhaite, c'est problématique.

Mais c'est aussi une question de bruit et de place. Pour le bruit, il y a les relais statiques, mais ça prend déjà plus de place et c'est moins fréquent que les triacs.

[Hug1]

La communication avec les drivers se fait en SPI (donc on est dans l'ordre de la us) on est limité par la fréquence de la communication.

C'est sûr qu'on parle déjà de délais très faible, mais c'est suffisant pour me poser des problèmes dans l'application.

[jiherve]

re
là je comprends mieux mais alors ne pourrais tu pas commuter les SPI.
Aurais tu la référence de tes drivers?
JR

[Hug1]

Bien sûr, les derniers avec lesquels j'ai fais les essais sont les TMC5072 de chez trinamic.

J'ai essayé d'assembler les deux SPI ensemble (avec d'autres driver les TMC2100), mais les délais que j'obtenais c'était n'importe quoi, j'avais vraiment l'impression qu'il y avait des conflits sur le bus.

Merci

[jiherve]

Re
les TMC5072 peuvent être chainés et les commandes synchronisées par la remontés du CS#, au moins en écriture , pour la lecture c'est moins clair mais si tu ne lis rien c'est sans importance.
les TMC2100 c'est plus simple c'est du discret.
JR

[Hug1]

Le TMC5072, comporte 2 drivers donc j'ai essayé d'utiliser les différentes configurations des registres pour les synchroniser sans succès.

Pour les essais sur le TMC2100, j'ai utilisé en tant que maquette un Arduino Uno. J'ai soudé les CS des deux TMC2100 ensemble pour uniquement écrire. Sauf que lorsque j'envoyais mes données, la synchronisation était catastrophique.
D'après l'analyse que j'ai mené ça provient de la bibliothèque spi.h d'arduino qui attend une réponse sur le MISO pour quitter la fonction.

Je suis parti du principe que ça serait probablement plus simple de faire un système de commutation plutôt que de modifier les bibliothèques spi.

Mais je vais creuser cela demain, merci

[gienas]

Pour l'usure des relais, j'ai lu dans les documentations techniques des usures mécaniques et des usures électriques, autour des 500 000 cycles de commutation.

Vu la fréquence de commutation du mouvement que je souhaite faire et la longue longévité que je souhaite, c'est problématique ...

Je ne suis pas sûr de bien tout comprendre et je n’ai aucune idée de la cadence de tes séquences et commutation n’est pas clair (pour moi).

L’usure des contacts résulte des étincelles qui arrachent de la matière. L’usage normal d’un relais c’est d’établir et de couper une intensité sous une certaine tension ce qui provoque les étincelles mentionnées et l’usure correspondante.

Mon idée c’est de ne jamais commuter d’intensité par les contacts. C’est le driver qui s’en charge et le contact laisse passer s’il est fermé et l’ignore s’il est ouvert. Je prétends que l’usure est nulle dans ces conditions.

J’ose espérer qu’il n’y a pas confusion dans ton esprit entre les commutations des phases du moteur et celles des contacts qui n’ont pas à se faire à cette même cadence.

Le bruit est bien entendu existant mais ce ne doit pas être celui d’une mitraillette. Mais sans valeurs numériques précises et une idée des chronogrammes réels, on parle dans le vide.

[polo974]

Merci pour votre réponse.
...

Je procède comme suit : je désactive mes drivers, je les configure, je commute mes signaux, puis j'active mes drivers. Si je change de mode, je désactive de nouveau mes drivers, les reconfigure, commute mes signaux, et les réactive.

Et pendant que les drivers sont désactivés, les moteurs sont quasi en roue libre... gros risque de perte totale de synchro.

Ne serait-il pas plus simple de mettre un registre de synchronisation entre le micro et les drivers...

[Hug1]

La solution avec des relais (même si l'usure poserait probablement pas de problème, d'après ce que vous me dites), me gêne particulièrement par le bruit.
Certes c'est léger, mais quand on utilise un appareil constamment par exemple, ce bruit est gênant.
C'est la solution la plus simple, mais ça prend de la place en hauteur et ça fait du bruit.

J'y pense aussi mais le temps de commutation des relais sont de plusieurs ms, il y a peut être plus rapide.

Et pendant que les drivers sont désactivés, les moteurs sont quasi en roue libre... gros risque de perte totale de synchro.

Ne serait-il pas plus simple de mettre un registre de synchronisation entre le micro et les drivers...

Effectivement mais je désactiverai mes drivers uniquement lorsque je souhaite piloter mes moteurs indépendamment, donc ils seront à l'arrêt.
Un registre de synchronisation ?

J'ai essayé comme solution d'avoir uniquement un bus SPI avec 1 maître et 2 esclaves et de souder les pins CS ensemble. Pour éviter les perturbations que j'avais obtenus la fois précédente, j'ai mis le pin MISO en l'air. Cependant il y a toujours un décalage de quelques us.

Je pense réellement que la meilleure solution est de mettre mes deux moteurs sur un driver, c'est cette solution qui m'a montré les meilleurs résultats.

Je garde l'idée des triacs, d'après les échanges qu'on a eu sur cette conversation, je crains qu'il n'y ait pas de meilleure solution, en considérant les prix, la taille, le bruit, et la complexité de la conception.

[polo974]

Le registre, c'était au cas où les drivers étaient pilotés par signaux simples: enable, direction, clock.

Ok...

Au fait, il y des contrôleur trionamic ou autres avec mosfet externes. Ça doit être possible de commuter les commandes des mosfets.

[Hug1]

J'ai trouvé le TMC429 qui pourrait être intéressant pour mon application (cf ci-dessous).
TMC.PNG

Il pourrait servir pour piloter plusieurs autres drivers (3 apparemment), et dedans il dispose d'une fonction de synchronisation, selon la référence fournie.
Simultane.PNG

Je vais étudier cela, parce que j'ai du mal à comprendre comment l'utiliser pour l'instant, mais ça semble prometteur.

Merci

[gienas]

Bonjour à tous

La solution avec des relais ...me gêne particulièrement par le bruit.
Certes c'est léger, mais quand on utilise un appareil constamment par exemple, ce bruit est gênant.
C'est la solution la plus simple, mais ça prend de la place en hauteur et ça fait du bruit ...

Je n'ai pas assez d'informations pour condamner cette solution qui paraît pourtant la plus simple à mettre en œuvre et les arguments que tu utilises pour cette condamnation me paraissent démesurés. Un relais ce n'est pas un contacteur. Compte tenu des courants et tensions mis en jeu, le relais peut être très discret, très petit et quasiment silencieux. J'ai demandé des timings pour me rendre compte, mais ils n'arrivent pas. Secret défense?

Pourtant, la solution est tellement simple à essayer, histoire de se faire une opinion, que ce serait dommage de s'en priver. En matière de conception, l'habitude est d'aller jusqu'au bout de toutes les hypothèses avant de les condamner.

... Je garde l'idée des triacs, d'après les échanges qu'on a eu sur cette conversation, je crains qu'il n'y ait pas de meilleure solution, en considérant les prix, la taille, le bruit, et la complexité de la conception.

A nouveau, j'ignore tes véritables besoins, mais je ne crois pas du tout, au contraire, que le triac est la solution. C'est vrai qu'il est bidirectionnel, mais:

1- il n'est pas naturellement conducteur: il doit être déclenché pour conduire quel que soit le quadrant;

2- il ne se bloque pas tout seul: une fois amorcé il le reste. C'est l'inversion du sens du courant qui va le bloquer.

[Hug1]

Bonjour,

Non ce n'est pas secret-défense , on va dire que la commutation est en fin de mouvement donc c'est l'histoire de quelques secondes.
Si on imagine une utilisation 10h par jour, pendant plusieurs années, les petits "clics clics" des relais ce n'est pas l'idéal.
Je ne condamne pas la solution, je sais qu'elle marcherait en maquettage, mais là je me projette sur du long terme.

Je pourrais imager ma solution, par une imprimante 3D, on a besoin d'une synchronisation des axes de temps en temps et dés fois non. Si l'impression tourne en continu, et qu'à chaque étage de filament on entends "clics clics", ça fait pas très "propre".

A nouveau, j'ignore tes véritables besoins, mais je ne crois pas du tout, au contraire, que le triac est la solution. C'est vrai qu'il est bidirectionnel, mais:

1- il n'est pas naturellement conducteur: il doit être déclenché pour conduire quel que soit le quadrant;

2- il ne se bloque pas tout seul: une fois amorcé il le reste. C'est l'inversion du sens du courant qui va le bloquer.

C'est exact, avec un signal de commande (comme celui que j'utiliserais pour le relais), j'amorce 4 triacs pour laisser passer mes signaux (il faut que la commande amorce en continu mes triacs vu que le courant oscille), lorsque j'ai fini mon mouvement, je désactive mon driver et j'amorce mes 4 autres triacs.

Après rien n'est décidé, aujourd'hui j'approfondis la solution du TMC429 qui à l'air intéressant, je garde toujours l'idée des relais ou des triacs de côté, chacun à ses avantages et ses inconvénients.

[bobflux]

Les triacs auront trop de pertes (2V de déchet sur 24V...) et sont trop lents pour le PWM de ton driver, les relais c'est trop steampunk : c'est du continu non isolé, le mieux c'est des MOSFETs.

Mais je ne pense pas que tu aies besoin de ce bazar de commutation.

TMC5072 supporte une horloge SPI de 8MHz, la trame fait 40 bits donc elle prend 5µs à envoyer, le retard maximum entre les deux est donc de 5µs ce qui est négligeable comparé à l'inertie d'un moteur. Donc si tu as un problème, c'est que le retard est beaucoup plus long que 5µs, ce qui est en théorie impossible. Donc d'où vient le retard ?

C'est probablement un problème de soft ; les libraries arduino sont souvent bien pourries. Il faut mesurer à l'oscillo le temps entre la transmission des deux trames vers les deux drivers, et trouver pourquoi il est trop long.

À mon avis tu perds ton temps avec cette histoire de commutation, il faut régler le problème à la source.

Au pire tu peux envoyer les mêmes commandes aux deux drivers avec un mux digital entre le micro et le driver, ça te coûte une puce en 74HC à 50 centimes...

Pour un maximum de flexibilité, j'utiliserais un microcontrôleur doté de deux ports SPI, et je les ferais transmettre en même temps.

[Hug1]

Après vérification le TMC429 n'apporterai rien.

TMC5072 supporte une horloge SPI de 8MHz, la trame fait 40 bits donc elle prend 5µs à envoyer, le retard maximum entre les deux est donc de 5µs ce qui est négligeable comparé à l'inertie d'un moteur. Donc si tu as un problème, c'est que le retard est beaucoup plus long que 5µs, ce qui est en théorie impossible. Donc d'où vient le retard ?

Avec l'arduino, la fréquence du SPI est de 4 MHz, j'ai calculé qu'avec la bibliothèque SPI.h je pourrais pas descendre en-dessous des 40 µs, si je l'optimise je pourrais descendre à 20 µs.

Dans une autre application j'ai réussi à atteindre une synchronisation autour des 3 µs, ce qui n'était toujours pas suffisant.

Je pense reprendre ma solution d'un maître et deux esclaves avec un bus SPI commun (en décâblant le MISO pour être certain de ne pas avoir de perturbation), cependant je vais ajouter une clock externe pour synchroniser les clocks des deux drivers (qui étaient jusqu'à présent en interne).

[jiherve]

bonjour
lisez vous les datasheet?
ces circuits peuvent etre chainés et synchronisés par le CSn!

The node is enabled for an SPI transaction by a low on the chip select input CSN. Bit transfer is
synchronous to the bus clock SCK, with the node latching the data from SDI on the rising edge of
SCK and driving data to SDO following the falling edge. The most significant bit is sent first. A
minimum of 40 SCK clock cycles is required for a bus transaction with the TMC5072.
If more than 40 clocks are driven, the additional bits shifted into SDI are shifted out on SDO after a
40-clock delay through an internal shift register. This can be used for daisy chaining multiple chips.
CSN must be low during the whole bus transaction. When CSN goes high, the contents of the internal
shift register are latched into the internal control register and recognized as a command from the
master to the node. If more than 40 bits are sent, only the last 40 bits received before the rising edge
of CSN are recognized as the command.

JR

[Hug1]

Non seulement j'ai lu la documentation mais j'ai fais l'essai

J'ai câblé les CSN séparément et ensemble.
Et les signaux sont pas synchronisé en sortie. Probablement car les clocks sont en interne, d'où le fait que je vais utiliser une clock commune stable externe.

[jiherve]

bonjour
il faut un seul CSn et un chainage sdi/sdo et émettre un train de 80 bits mais passons, l'usage d'une clock externe ne permettra pas la synchronisation des pas , la question qui me taraude c'est quelle fonction savante utilises tu , STEP & DIR ne suffiraient ils pas?
JR

[Hug1]

Bonjour,

il faut un seul CSn et un chainage sdi/sdo et émettre un train de 80 bits mais passons, l'usage d'une clock externe ne permettra pas la synchronisation des pas , la question qui me taraude c'est quelle fonction savante utilises tu , STEP & DIR ne suffiraient ils pas?

En effet j'y ai pensé également, le problème c'est que cette fonction est doublé donc selon moi c'est plus simple d'avoir un bus SPI qui pilote les 4 drivers soit indépendamment soit en commun que d'utiliser le STEP/DIR.

Sinon j'utilise la liaison SPI pour la configuration des drivers, pour utiliser le StealthChop ou le SpreadCycle. D'après ce que j'ai vu, il serait possible de faire ces configurations avec des pins de registre, notamment sur le TMC2100.

[bobflux]

Si tu utilises step/dir tu perds l'algo de motion control de ces drivers et tu dois le refaire à la main avec ton code.

Dans une autre application j'ai réussi à atteindre une synchronisation autour des 3 µs, ce qui n'était toujours pas suffisant.

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