Driver linéaire de moteur (PWM -> DC)

[Seb.26]

Bonjour,

voilà un bon moment que je galère pour piloter mon moteur 12v DC (2A max).

J'ai fait des tests en utilisant une carte IBT-4 ( https://www.amazon.fr/KNOSSOS-Driver.../dp/B07MBNYMDH )

Et ça marche pas mal sauf que j'ai énormément de parasites sur les signaux de l'encodeur du moteur, tellement que mon CPU voit des impulsions qui n'existent pas.

Pourtant, quand j'utilise mon alim de labo pour faire varier la tension, je n'ai aucun parasites.

Donc ma question à 1kg de cacahuètes : est-ce qu'il existe des driver "linéaires" pour moteur, c'est a dire qui ne sortent pas un PWM, mais une tension fixe ... comme le fait mon alim de labo !

Dans l'idéal, je voudrais piloter la vitesse via un PWM (un seul sens de marche).

Merci.
-----

[penthode]

hello

un régulateur linéaire existe , mais c'est une cause de pertes par échauffement

une régulation PWM pour moteur se doit de respecter des règles :

filtre sur l'alim moteur
alimentation soignée de l'électronique de commande !

quid de ton système ? schéma ? photo ?

[Seb.26]

Hello,

je vais vous documenter un peu tout ça ... je reviens !!

[AstroFOX]

Bonjour,

Comme le dit Penthode, un filtre sur l'alimentation moteur, voire câble blindé pour la partie encodeur si il y a une longueur de câble conséquente, ferrites au niveau de la réception... Il y a quelques temps j'avais mis en œuvre un banc avec 18 moteurs + encodeurs (Maxon ou Faulaber, je sais plus).

Drivers L6205, grosse capa chimique (1 mF) + filtre Pi (Capa, inductance, capa) sur l'alimentation de puissance du L6205 (il me semble qu'il y a 2 voies, avec possibilité de les mettre en // mais c'est à vérifier) + Filtre mode commun entre le driver et le moteur, pour cette partie j'avoue que je ne suis pas certain que ce soit la meilleure façon de faire, c'était mon projet de stage quand j'étais encore un enfant
Bien séparer la partie puissance de la partie signaux.

Attention aussi à la fréquence de PWM : si la fréquence est trop basse, ça peut saccader et être difficile à asservir pour un rapport cyclique faible (ça dépend de l'inertie de la charge). Si la fréquence est trop haute, ça siffle et le moteur ne démarrera pas avant un certain seuil (rapport cyclique 10 à 15% par exemple). C'est expérimental, il faut trouver le bon compromis en fonction du moteur et de la charge.

[A voir en vidéo sur Futura]

[Seb.26]

un peu plus d'info ...

Le CPU est un ATMEGA328pb
Le driver est un IBT-4
L'encodeur sort 500 pulses/tour, est alimenté en 5v.

Tout passe dans le même câble (5x0.34)

• Moteur -
• Moteur +
• Encodeur +5v
• Encodeur GND
• Encodeur signal

Au niveau du moteur, j'ai une SS56 de roue libre.

1) avec alim labo :

20220711_AlimLabo_OK.png
échelle H = 50uS/div
échelle V = 5v/div
Ch haut (jaune) = signal encodeur, sonde au niveau du uCPU
Ch bas (violet) = alimentation moteur, sonde au niveau du moteur

Et les traces de mon uCPU sont OK :

P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=111;RPM=1332/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=110;RPM=1320/500;PWM=0
P=111;RPM=1332/500;PWM=0

P = nombres d'impulsions détectées en 10ms
RPM = vitesse calculée / vitesse de consigne
PWM = commande de sortie ( figé à 0% pour ce test, le moteur est alimenté par ailleurs )

Une impulsion faisant environ 2 div (50% haut, 50% bas), donc 100uS, donc environ 100 impulsions pour 10ms ... le uCPU donne 110/111 ... c'est ok !

2) PWM fixe à 255 (=25%) et la carte IBT-4 :

20220711_PWM_25%_KO.png

P=316;RPM=3792/500;PWM=255
P=319;RPM=3828/500;PWM=255
P=322;RPM=3864/500;PWM=255
P=324;RPM=3888/500;PWM=255
P=320;RPM=3840/500;PWM=255
P=319;RPM=3828/500;PWM=255
P=326;RPM=3912/500;PWM=255
P=319;RPM=3828/500;PWM=255
P=321;RPM=3852/500;PWM=255
P=319;RPM=3828/500;PWM=255
P=326;RPM=3912/500;PWM=255
P=321;RPM=3852/500;PWM=255
P=325;RPM=3900/500;PWM=255
P=319;RPM=3828/500;PWM=255
P=321;RPM=3852/500;PWM=255
P=327;RPM=3924/500;PWM=255
P=324;RPM=3888/500;PWM=255
P=320;RPM=3840/500;PWM=255
P=319;RPM=3828/500;PWM=255
P=324;RPM=3888/500;PWM=255
P=321;RPM=3852/500;PWM=255
P=325;RPM=3900/500;PWM=255

Une impulsion fait toujours environ 2 div, on devrait donc toujours trouver environ 100 impulsions pour 10ms ... on est à 300 !!!

De plus, même avec un PWM figé à 25%, le nombre d'impulsions du codeur varie beaucoup.

2) PWM fixe à 50 (=5%) et la carte IBT-4 :


20220711_PWM_5%_1_KO.png

P=203;RPM=2436/500;PWM=50
P=207;RPM=2484/500;PWM=50
P=209;RPM=2508/500;PWM=50
P=208;RPM=2496/500;PWM=50
P=212;RPM=2544/500;PWM=50
P=212;RPM=2544/500;PWM=50
P=211;RPM=2532/500;PWM=50
P=208;RPM=2496/500;PWM=50
P=199;RPM=2388/500;PWM=50
P=204;RPM=2448/500;PWM=50
P=208;RPM=2496/500;PWM=50
P=208;RPM=2496/500;PWM=50
P=204;RPM=2448/500;PWM=50
P=206;RPM=2472/500;PWM=50
P=205;RPM=2460/500;PWM=50
P=210;RPM=2520/500;PWM=50

Mon impulsion fait environ 5 div, donc 250uS, donc 20 impulsions pour 10ms ... le CPU en voit > 200 ...

[AstroFOX]

Alors, dans un premier temps il faudrait apporter un filtrage "en l'air" voir si ça améliore les choses : grosse capa entre l'alimentation et le driver, enrouler le câble du moteur/encodeur plusieurs spires autour d'une ferrite torique.

Est-ce que l'ATmega est assez rapide (du point de vue structure interne + firmware) pour encaisser les 500 impulsions/tour? A régime maximum, il serait intéressant de vérifier avec un tachymètre la vitesse réelle du moteur et comparer au nombre d'impulsions mesurées par le micro

[penthode]

le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma

[Seb.26]

Donc la question : comment supprimer ces saletés sur le signal de l'encodeur ?

Un filtre sur le signal pour supprimer les pics tout en laissant passer les vrais pulses ?

Ci-dessous avec un PWM fixe à 970 ( =95% )



On voit qu'une impulsion dure environ 10uS ... il faudrait un genre de filtre passe bas à 40kHz, non ?

[Seb.26]

Alors, dans un premier temps il faudrait apporter un filtrage "en l'air" voir si ça améliore les choses : grosse capa entre l'alimentation et le driver, enrouler le câble du moteur/encodeur plusieurs spires autour d'une ferrite torique.

OK, je vais essayer ça ... par grosse capa, tu entends quoi ? ... genre 1000uF ? ... plus ?
Pour la ferrite, je vais trouver ça ... plutôt coté moteur, au milieu, coté driver ?

Est-ce que l'ATmega est assez rapide (du point de vue structure interne + firmware) pour encaisser les 500 impulsions/tour? A régime maximum, il serait intéressant de vérifier avec un tachymètre la vitesse réelle du moteur et comparer au nombre d'impulsions mesurées par le micro[/QUOTE]

Oui, tout est fait en hard par les timers, j'ai testé en 24v, soit environ 10000 RPM = 83333 impulsions par seconde sur un uCPU @ 20MHz = aucun souci.

[Seb.26]

le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma le schéma

Le schéma de câblage ? ...



Cote uCPU :
> le signal de l'encodeur entre sur T1 et sur T4 (PD5 + PE1), avec une pullup de 3.3kR (demandé dans la datasheet de l'encodeur)
> le PWM sort sur OC3B (PD2)

[Seb.26]

J'ai oublié la diode SS56 sur le câblage, elle est sur le moteur, avec 10cm de fil ...

[Seb.26]

On dirait que c'est sur le passage ON->OFF du PWM que l'on trouve les parasites ... ma diode n'est pas assez rapide ? ...

Je dois faire une commande chez Farnell, ça vaut le coup que je prenne des "STTH3R02" pour tester ?
( STMICROELECTRONICS : STTH3R02 = Diode Fast / U, 200 V, 3 A, Une, 1 V, 16 ns, 75 A )

[AstroFOX]

OK, je vais essayer ça ... par grosse capa, tu entends quoi ? ... genre 1000uF ? ... plus ?

Ce que tu as sous la main pour les tests, 1000 uF c'est costaud, donc si avec ça les perturbations sont toujours là (ce que je redoute vu le câblage) tu peux être certain que ça vient d'autre part.

Pour la ferrite, je vais trouver ça ... plutôt coté moteur, au milieu, coté driver ?

Dans un cas réel, c'est à dire fabrication d'un PCB dédié, le filtre serait plutôt côté driver. Je ne suis pas un expert en CEM, d'instinct je dirais qu'il faut mettre la ferrite au plus près de la source de perturbation, mais pour un moteur déporté commandé en hacheur, je ne saurais pas dire si la source de bruit majeure est le moteur ou le découpage (sortie du driver).

Avec une ferrite sur câble, rien ne t'empêche de faire le test d'abord côté driver, puis côté moteur, tu peux même essayer de torsader les câbles du moteur sans ferrite et comparer les résultats

Il serait peut-être bien de réduire la longueur des câbles de la diode de roue libre aussi

Est-ce que l'ATmega est assez rapide (du point de vue structure interne + firmware) pour encaisser les 500 impulsions/tour? A régime maximum, il serait intéressant de vérifier avec un tachymètre la vitesse réelle du moteur et comparer au nombre d'impulsions mesurées par le micro

Oui, tout est fait en hard par les timers, j'ai testé en 24v, soit environ 10000 RPM = 83333 impulsions par seconde sur un uCPU @ 20MHz = aucun souci.

En effet ça passe, je pensais qu'il travaillait plus bas en fréquence

[Antoane]

Bonjour,

https://forums.futura-sciences.com/e...ml#post6967910 => cf post 6. Dans ton cas c'est critique, la diode doit être proche du transistor et découpage et du condensateur de filtrage. La capacité de ce dernier n'est pas critique (> 10 nF), son ESL l'est.

Filtrer la sortie PWM n'est pas une obligation, d'aucun dirait que c'est un pis-allé, mais si necessaire, il faut un filtre LC dont la fréquence de coupure est ~une décade sous la fréquence de découpage. Ce filtre LC doit être au plus près du demi-pont. On transforme alors le PWM en convertisseur buck.
Il faut, comme déjà dit, un bon filtrage de l'alim du demi pont :
- découplage HF à faible ESL
- filtrage DC assurant que le courant délivré par l'alimentation 230V est bien continu (ESL moins critique).
Il faudrait, au moins dans un premier temps, séparer les cablages de puissance et du codeur.
Un bon filtrage (capa de découplage, éventuellement résistance ou ferrite bead série) de l'alim du codeur semble nécessaire.
Y a-t-il un condensateur directement en parallèle du moteur, ou en sortie du demi-pont ? Il ne faut pas.
Les temps-morts sont-ils bien gérés ?

Un schéma (avec tous les composants), plutôt que le synoptique donné plus haut, serait utile. Des photos supplémentaires du systeme aideraient.

[bobflux]

Tout passe dans le même câble (5x0.34)

• Moteur -
• Moteur +
• Encodeur +5v
• Encodeur GND
• Encodeur signal

Mets un câble torsadé pour le moteur.

Pour l'encodeur, un câble blindé... Si t'en as pas sous la main avec 2 conducteurs, tu peux toujours mettre deux câble blindés dont un pour l'alim... des coax de télé, n'importe quoi sauf les fils à l'air dans la même gaine...

[jiherve]

bonsoir
il faudrait surtout eviter de tout balader dans le même câble, c'est tout de même basique!
JR

[Seb.26]

bonsoir
il faudrait surtout eviter de tout balader dans le même câble, c'est tout de même basique!
JR

Maintenant que vous le dites, ça semble en effet évident ...

Je vais chercher un nouveau câble ...

[Seb.26]

Pour ceux qui voulaient le schéma ...



Pas grand chose à voir de plus.

[AstroFOX]

Je vais chercher un nouveau câble ...

J'utilise souvent les câbles multi-conducteurs de chez Tensility, on les trouve essentiellement chez Digikey (celui-ci à titre d'exemple). Ils en font des blindés et non blindés, mais si possible je pense qu'il vaudrait mieux un câble 2 conducteurs + blindage pour moteur (section de 22 ou 20 AWG devraient suffire), et un câble 4 (ou 5) conducteurs + blindage pour le capteur (il y a possibilité de prendre une section plus petite, mais en dessous de 26 AWG ça fait vraiment petit si il y a besoin de sertir ^^)

[Seb.26]

Hello,
a priori j'ai résolu mon problème ... en filtrant l'entrée du uCPU ... avec un autre CPU.

En gros, j'ai pris une mini carte Arduino avec un 328p@16MHz et 100% du temps CPU passe à filtrer l'entrée pour supprimer les parasites.

Pour le moment ça a l'air de fonctionner.

Je vais regarder pour du câble blindé aussi et changer la diode de roue libre, je vous dirait si ça améliore le signal.

Merci à tous pour vos messages.

[antek]

En gros, j'ai pris une mini carte Arduino avec un 328p@16MHz et 100% du temps CPU passe à filtrer l'entrée pour supprimer les parasites.

On peut aussi filtrer le signal capteur avec un DSP, on gère bien des portes de poulailler avec des Cortex Mx . . .

[Seb.26]

On peut aussi filtrer le signal capteur avec un DSP, on gère bien des portes de poulailler avec des Cortex Mx . . .

... j'avais pas de DSP sous la main, mais effectivement vu la pénurie ça fait un peu riche ... ... mais ça marche !

[AstroFOX]

En gros, j'ai pris une mini carte Arduino avec un 328p@16MHz et 100% du temps CPU passe à filtrer l'entrée pour supprimer les parasites.

Pourquoi pas je ne juge pas Pendant mes études j'ai dû utiliser un PIC18F que j'avasi sous la main pour faire une conversion 3V3 - 5V entre un 68HC11 et un écran LCD 2 lignes 16 caractères (Défi personnel pour un TP en assembleur ) le PIC18F alimenté en 5V faisait juste PORTA = PORTB, ça prenait moins de temps que de passer par le service achat de la fac pour acheter un composant spécialisé ou de faire un level shifter 8 bits avec des transo sur une plaque d'essai ^^

[jiherve]

bonjour
un BP en assembleur c'est quelques lignes exécutées au rythme de la fréquence échantillonnage normalement cela ne bouffe pas 100% du temps cpu sauf filtre très savant, inutile ici.
JR

[Seb.26]

bonjour
un BP en assembleur c'est quelques lignes exécutées au rythme de la fréquence échantillonnage normalement cela ne bouffe pas 100% du temps cpu sauf filtre très savant, inutile ici.
JR

c'est quoi un BP ?

... sinon mon while(1) tourne à la vitesse max puisque c'est comme ça que j'ai la plus haute granularité ... je comprends pas ta remarque ...

[antek]

Bouton-Poussoir ?
On gère le pic indésirable comme dans le cas d'un anti-rebond, mais le terme "fréquence d'échantillonnage" ne convient pas, à moins de considérer les cycles instruction comme une période d'échantillonnage (ce qui n'est pas faux).

Lapsus pour PB comme Passe-Bas ?

[jiherve]

re
oui dyslexie PB , passe bas.
Lorsque l'on veut filtrer il faut fixer une fréquence échantillonnage et c'est celle ci qui défini le temps CPU par la quantité de calculs induite à chaque période, pour une moyenne glissante c'est un calcul d'index, une soustraction, une addition et une division ou décalage si le nombre de plots est une puissance de deux, bien sur il faut faire çà en assembleur.
JR

[Seb.26]

OK.

Perso pour filtrer mes entrées, je fais toujours du << tant que je n'ai pas eu 'n' échantillons différents à la suite, je bouge pas >> (n=6 dans mon cas)

Et effectivement dans le cas présent je ne suis pas temps-réel mais qu'importe !!!

[AstroFOX]

On est d'accord que le MCU pour filtrer c'est juste de manière provisoire?

Vu la nature des signaux et la fréquence en jeu, on peut largement faire quelque chose de propre avec un câblage adapté et les quelques filtres énoncés précédemment

[Seb.26]

On est d'accord que le MCU pour filtrer c'est juste de manière provisoire?

... afin de m'éviter les foudres de tout le monde : << oui, oui, évidement >> ...