Lineariser la sortie Triac en mode découpe Sinus

[Lolo69]

Merci Laurent53 pour cette optimisation.

[59jag]

Par curiosité j'ai tracé les courbes du polynôme de Lolo et de x - sin(x) afin de comparer.
Voici le résultat obtenu.



Attached FilesThumbnail(s)
   

oui mais moi c etait pour x varie entre  0 et 2*PI essaye la meme chose avec la correction que j ai dit au premier poste    avec cette fonction ->   x + 16*sin(2*PI* x/100)    

ca c est la theorie sinon le code est simple pas de sinus a calculer ou calcul complexe  juste 2 a 3 lignes de codes pour la correction PID

[Lolo69]

Ta théorie ne tient pas debout. Au lieu de palabrer sors nous les lignes de codes pour linéariser ça sera plus utile
Le code est si facile ça devrait aller vite, je ne comprends pas pourquoi André ne l a pas déjà fait


   
On est encore très loin.

[59jag]

Ta théorie ne tient pas debout. Au lieu de palabrer sors nous les lignes de codes pour linéariser ça sera plus utile
Le code est si facile ça devrait aller vite, je ne comprends pas pourquoi André ne l a pas déjà fait



On est encore très loin.

c est pas ma théorie .c est juste des maths j ai pas sorti cette equation comme ca .
j ai juste simplifier 100/2*pi  qui vaut 15.9.....  a 16 car le pid   c est en nombre entier.
pour le code  dans 16*sin(2*PI* x/100)    on a 4 symetries faut juste faire un tableau de 25 int8 avec les valeurs de correction . et additionner ou soustraire la valeur du tableau au pid.

[Lolo69]

Ton approche est très intéressante car digne d un programmeur hors pair qui maîtrise la discretisation 
 j y avait pensé, mais je ne trouve pas ça « élégant » ça veut dire faire des interpolations linéaires entre 2 points avec des cassures aux jointures.
En terme de précision ok ça passe  , en temps processeur c est pas mieux et il faut encore remplir des tables et donc un peu de RAM.  J ai horreur de ça ;-)
Ça veut dire aussi linearisation après être passé en Int là aussi ça crée des pulses sur le PID ( donc du filtrage donc du retard de phase) et perte de continuité dans la commande. La méthode polynôme permet indirectement de passer à une régulation derrière la virgule … pour une ouverture calculée et affichée à 5 le polynôme est capable d ajuster le retard entre 4,5 et 5,49 réel

Chacun son point de vue je trouve plus simple de rajouter une ligne pour un polynôme

J ai hâte de pouvoir comparer le résultat des 2 approches, en attendant bon routage à tous.

PS: J'ai remis à jour la modif de code dans les pages précédentes pour prendre en compte les remarques eclairées de Mike et Laurent53, merci à eux

[F6AAM]

Bravo Lolo69 et Mike pour cette linéarisation de la courbe puissance triac = f (pourcentage).

La méthode employée (polynôme) est certainement la plus rapide.

Cela va améliorer le comportement de la boucle d'asservissement qui devient linéaire, ce qui n'était pas le cas avec la découpe sinus par le triac.

De plus il devient plus agréable de constater la linéarité entre le pourcentage et la puissance comme cela est le cas dans les modes demi-sinus, multi-sinus et train de sinus.

[59jag]

 ça veut dire faire des interpolations linéaires entre 2 points avec des cassures aux jointures.
En terme de précision ok ça passe  , en temps processeur c est pas mieux et il faut encore remplir des tables et donc un peu de RAM.  J ai horreur de ça ;-)
Ça veut dire aussi linearisation après être passé en Int là aussi ça crée des pulses sur le PID ( donc du filtrage donc du retard de phase) et perte de continuité dans la commande. 

j ai pas tous compris. je fait pas t  interpolations ???
pour ce qui est de remplir la table c est une fois au démarrage de l Esp comme on fait pour le mode Multi-sinus qui rempli  2 tableaux de 100 int8  , que l on peux utiliser 1 seul suffit donc aucune memoire supplémentaire supplémentaire.

pour ce qui est de la vitesse juste lire la correction dans tableau ca prend c est 2 cyles horloges,  pour ton polynôme pas compté mais chatgpt dit 80 a 100 cyles faudra vérifié en reel le temps.

Par contre, c'est Retard[i]  qui est un int — c'est l'arrondi de RetardF :
Retard[i] = round(RetardF[i]);
Et c'est cet entier Retard[i] qui pilote le timer du triac dans onTimer() :
Donc la précision du calcul en float est perdue à la conversion en entier. Le PID travaille finement en interne (les décimales permettent une accumulation progressive de l'intégrale), mais la commande réelle du triac n'a que 100 pas de résolution.

oui le test tranchera

[Lolo69]

Et non dommage que tu sois aussi obstiné ça te rend aveugle .


Réfléchis un peu à la précison et tu réviseras ce que c est qu un regulateur PID et que justement c est l accumulation interne qui déstabilise toutes la boucle . La commande ayant effectivement que 100 pas il ne faut pas les gaspiller avant …



Bref j’ attend ton code avec impatience pour comparer les courbes mais je suis serein , meme si je m’en fout je connais déjà le résultat.
En attendant mon esp32 passe 56 cycles pour calculer le polynôme avec des cycles max sur les 2 cœurs à 50ms.
Admettons 100 cycles ça fait jamais que 400nanoS sur des cycles PID à 200ms ça laisse de la marge
Tes tableaux lisent des indexes en float ?