Modélisations de solutions séquentielles destinées à piloter une chaîne d'énergie publié le 20/07/2020

La simulation d'un système réel ne s'arrête pas à la chaîne d'énergie. Pour l'animer, il convient de créer des stimuli adaptés et, si cela ne suffit pas, de réaliser des systèmes séquentiels chargés de commander la chaîne d'énergie

4- Création d’un séquenceur réagissant sur fronts, sous forme de composant SinusPhy ou de script Python

Modélisation, simulation et analyse de fonctionnement d’un séquenceur commandé sur fronts :

  • Soit le nouveau cahier des charges : « Démarrer le moteur dans le sens horaire par un appui sur le bouton Avant ou dans le sens anti-horaire par un appui sur le bouton Arrière. A tout moment, le moteur peut être arrêté par appui sur le bouton Raz (ou tout autre événement lié à l’état de la machine...). Le moteur ne peut changer de sens que s’il a été auparavant arrêté. Le temps d’appui sur Avant et sur Arrière ne devra pas intervenir ; seul le moment où on commence à appuyer sur ces boutons devra être pris en compte. »
  • Une détection des fronts est nécessaire mais pour la comprendre, nous allons modéliser, dans un premier temps, ce nouveau séquenceur sans prendre en compte les fronts puis nous allons ajouter la détection des fronts sur Avant et sur Arrière.
  • Afin de visualiser facilement la différence, les stimuli seront les mêmes.
  • Un exemple d’évolution de ce séquenceur sera proposé par l’ajout d’une sortie permettant de commander le moteur sans à-coups.

Note : Compte tenu de l’utilisation de l’effet mémoire (réalisé soit par un composant soit un script) et afin de toujours démarrer dans les mêmes conditions, il conviendra de toujours fermer la boite de dialogue de simulation afin de forcer la réinitialisation des états pour une nouvelle simulation.

Description des stimuli communs :

  • Signal Avant : impulsion n°1 de 1 s à 1.5 s et impulsion n°2 de 6.5 s à 7 s
  • Signal Arriere : impulsion n°1 de 4.75 s à 5.5 s et impulsion n°2 de 7.5 s à 9.5 s
  • Signal Raz : impulsion n°1 de 2.5 s à 2.6 s, impulsion n°2 de 5 s à 5.1 s et impulsion n°3 de 8 s à 8.1 s

Première solution : Réalisation, à l’aide d’un composant Sinusphy, du séquenceur sans la prise en compte des fronts :
Schéma épuré utilisant les 3 stimuli :

schemamarchesenssansfronts

Propriétés du composant :

  • Le choix a été fait, ici, d’utiliser, comme variables intermédiaires, deux entrées internes Mav_ et Mar_ (entrées volontairement invisibles) afin d’obtenir les deux effets mémoire.
  • Equation de Mav_ : Mav_=if(Raz_,0,if(Av_&& (Mar_<1),1,Mav_))
    => Si Raz est à 1, alors Mav_ est à 0, sinon : si ordre Avant et pas marche arrière, alors Mav_ = 1 sinon Mav_ ne change pas (noter le choix du test Mar_ < 1. On aurait pu choisir : Mar_ < 0.5)
  • Equation de Mar_ : Mar_=if(Raz_,0,if(Ar_&&(round(Mav_)==0),1,Mar_))
    => Si Raz est à 1, alors Mar_ est à 0, sinon : si ordre Arrière et pas marche avant, alors Mar_ = 1 sinon Mar_ ne change pas (noter le choix d’une autre forme de test équivalente à Mar_ < 1 mais plus technique : round(Mav_)==0 car la valeur initiale de Mav_ n’est pas un entier et la comparaison à l’entier 0 ne fonctionnera pas)
    proprietesprototypecomposantsequenceursansfrontsannote

Chronogrammes :
On remarque également l’existence du problème (qui se reproduit ici aux environs 5 s et 8 s), lié à la durée des signaux. Et ce problème engendre ensuite, vers 6.5 s, l’impossibilité de prendre en compte la commande de marche avant.

testcomposantsequenceursansfrontsannote

 

Deuxième solution : Réalisation, à l’aide d’un composant Sinusphy, du séquenceur avec la prise en compte des fronts :
C’est le même schéma épuré utilisant les 3 stimuli. Quelques aménagements seront faits en interne pour tenir compte des fronts :

schemamarchesensavecfronts

Nouvelles propriétés du composant :

  • Le choix a été fait, ici, d’ajouter, comme variables supplémentaires, deux entrées internes AvP_ et ArP_ (entrées volontairement invisibles) afin d’obtenir les deux effets mémoire supplémentaires pour détecter des variations que l’on appellera des fronts montants (la nouvelle valeur de l’entrée devant être plus grande (1) que son ancienne valeur (0)).
  • Equation de AvP_ : AvP_=if(Av_,1,0)
    => Il peut sembler étrange que AvP_=if(Av_,1,0) soit si différente de AvP_=Av_. Ceci est lié au mode de calcul ACAUSAL qui recherche un équilibre et, par conséquent, ne fait pas de différence entre : AvP_=Av_, Av_=AvP_ ou encore 0=AvP_-Av_... alors que l’utilisation d’un test force la copie de Av_ vers AvP et mémorise ainsi Av_.
  • Equation de ArP_ : ArP_=if(Ar_,1,0)
    => Même remarque liée au mode de calcul ACAUSAL
    -* Modification des équations de Mar_ et Mav_ : ...if(Av_&&... a été remplacé par if((Av_>AvP_)&&... et ...if(Ar_&&... a été remplacé par if((Ar_>ArP_)&&...
    => Ce n’est plus sur l’état 1 mais sur le passage logique de 0 à 1 (que l’on appellera front montant), que le test est validé.
    proprietesprototypecomposantsequenceuravecfrontsannote

Variante de cette deuxième solution : Réalisation, à l’aide d’un script Python, du séquenceur avec la prise en compte des fronts :
C’est le même schéma épuré utilisant les 3 stimuli et un composant Script :

schemamarchesensavecfrontsscriptpython

Propriétés du composant script :
On notera la même organisation que pour l’exemple précédent simulant une mémoire RS.

⚠ Il convient de respecter l’écriture des noms (différenciation entre MAJUSCULES et minuscules) et le nombre d’entrées et de sorties. Par exemple, si on ajoute, ici, une sortie Alpha, celle-ci doit être gérée dans le script sous peine de blocage et la réciproque est vraie.

proprietescomposantscriptsequenceursavecfrontsannote

Script associé :
Ce script reprend la structure vue avec la mémoire RS.
Noter :

  • La première ligne de la fonction loop : def loop (Avant, Arriere, Raz, Marche, Sens) :
  • La gestion des fronts montants obtenue par les 2 syntaxes : if av > avp... et if ar > arp... associées aux 2 lignes situées en fin de script avp = av et arp = ar qui recopient les valeurs actuelles des entrées afin de pouvoir comparer au prochain pas.
    scriptsequenceurdeuxsensavecfronts

Chronogrammes identiques obtenus avec le composant Sinusphy ou le script Python :
On vérifie que le problème, lié à la durée des appuis, a bien disparu, que la commande de marche avant est bien prise en compte à l’instant 6.5 s et que la marche arrière est logiquement ignorée vers 7.5 s.

testcomposantouscriptssequenceuravecfronts

Dernière variante de cette solution : La puissance d’un script Python permet logiquement d’ajouter des fonctionnalités :

Pour l’exemple, nous allons ajouter une sortie Alpha qui va pouvoir commander la chaîne d’énergie (variateur -> moteur->...) de manière progressive. Nous allons utiliser le terme de rampes d’accélération et de décélération.
La sortie Alpha pourra varier entre 0 et 1 et correspondra à un rapport cyclique variant entre 0% et 100% qui sera relié à un variateur de vitesse (un hacheur par exemple).
Il sera possible de modifier, dans le script, les valeurs alphaMax et duree afin d’obtenir l’effet voulu.

Schéma légèrement modifié pour sortir et afficher indépendamment la valeur Alpha qui sera le seul signal non binaire.

schemamarchesensavecfrontsetrampesscriptpythonannote

Pour le script correspondant, on notera l’utilisation de :

  • La fonction timer() disponible dans la bibliothèque sinusphy pour Python. Elle permet de connaître le temps depuis le début de la simulation et de ne pas dépendre du pas de calcul.
  • Les fonctions min et max de Python permettant de limiter la variable alpha à l’intervalle autorisé [0, 1].
  • La variable alphap permettant de mémoriser la valeur maximale atteinte par alpha.

Le script s’étoffe peu à peu tout en gardant la même structure et une logique séquentielle très lisible.

scriptsequenceurdeuxsensavecfrontsetrampes

La variable alpha évolue ainsi :

  • Première accélération jusqu’à alphaMax fixé à 0.9 (soit 90%)
  • Décélération jusqu’à arrêter le moteur (0%)
  • Seconde accélération jusqu’à environ 70% du fait d’une durée trop courte...
    testcomposantouscriptssequenceuravecfrontsetalpha

En conclusion, pour l’instant, avec les différentes solutions proposées :

  • Il est possible de commander une chaîne d’énergie (nous avons vu différentes façons de créer des stimuli avec des curseurs, des fichiers .crb définissant des courbes particulières, des composants basiques existants, ou des modifications de composants existant et, enfin, de créations de composants spécifiques).
  • Il est également possible de commander une chaîne d’énergie et de changer de mode de fonctionnement en fonction de l’état du système (pour cela, il faut commencer par modéliser le capteur adapté et, ensuite, modéliser un séquenceur avec une entrée spécifique pour récupérer l’état de ce capteur).

Voici, comme exemple de création d’un simple capteur à sortie TOR : un capteur fin de course :
De part sa technologie (mécanique, optique ou magnétique) et son emplacement, il détermine une position limite et le signale par un changement d’état logique.
Le modèle de ce capteur fin de course doit commencer par déduire la position actuelle du système (que ce soit un angle de rotation ou un déplacement linéaire) des évolutions de la vitesse correspondante (on fait appel à la fonction integrale), puis il doit comparer cette position à une valeur limite (dans le modèle, cela peut être une constante ou une entrée dont la valeur est modifiable via un curseur) pour donner un résultat binaire compatible avec les exemples de séquenceurs précédents (ci-dessous, 2 versions, l’une avec un test, l’autre avec Heaviside. Toutes deux renvoient, ici, un niveau 1 si la limite est atteinte)

proprietescapteurfindecourse1
proprietescapteurfindecourse2

 

Par contre, nous n’avons pas encore abordé les techniques pour moduler la commande de la chaîne d’énergie afin de maintenir, par exemple, la vitesse du moteur, quelque soit la charge. Ceci sera développé dans le prochain article. On parlera alors de système bouclé. Les notions de consigne, de chaîne directe, de chaîne de retour, d’asservissement, de précision, de stabilité et de correcteur PID seront abordées.

Les modélisations des composants complémentaires pourront être complètement faites sous forme de simples composants Sinusphy. Par exemple, le correcteur PID, chargé d’assurer la précision et la stabilité, pourra être réalisé par un composant Sinusphy paramétrable par des constantes ou par des entrées gérées par des curseurs.

Dans la réalité, les correcteurs PID sont gérés, le plus souvent, numériquement. Nous verrons comment le construire par quelques lignes dans un script Python afin d’approcher les solutions réelles où le microcontrôleur fait les acquisitions des grandeurs analogiques via des CAN et crée le signal de commande PWM. On parlera alors d’asservissement numérique. De nouvelles notions seront abordées, comme la discrétisation en amplitude, la période et la fréquence d’échantillonnage qui interviennent dans la précision et la stabilité.
Le script python, mis au point à l’aide de Sinusphy, peut alors être implanté dans le microcontrôleur en s’assurant que la période d’échantillonnage soit suffisamment petite et, surtout, constante.