Solari-home
solaire thermique & économie d'énergie
Le Millenium est tout à fait à même de piloter un système comme un portail motorisé.
Nous allons voir comment piloter un portail coulissant.
Nous allons aborder la programmation par étape, en allant vers un programme de plus en plus complet mais un peu plus complexe à chaque étape.
Important : Cette page a avant tout un but didactique. Même si le programme final est à même de piloter un portail motorisé, je ne prétends pas être un professionnel ni dans ce domaine ni dans la programmation des Millenium et les divers programmes ne doivent pas être pris tels quels et utilisés en réel directement.
Des vérifications et des tests poussés doivent être effectués auparavant afin d'assurer la sécurité dans tous les cas possibles.
Notre portail est un portail coulissant. Il est normalement fermé sauf quand son ouverture est demandée par une commande à distance.
Le portail est entrainé via une crémaillère et un réducteur mécanique par un moteur électrique. Ce moteur permet d'ouvrir ou bien de fermer le portail en inversant son sens de rotation. Le moteur est commandé par deux relais, un pour chaque sens.
Le portail est muni de deux contacts de fin de course, l'un indique si le portail est complètement ouvert, l'autre si le portail est complètement fermé.
Un gyrophare orange est aussi commandable et doit être activé à chaque déplacement du portail.
Enfin, un dispositif permet de détecter le passage ou la présence d'un objet entre la portée du portail. Cette détection servira à assurer la sécurité lors du déplacement du portail.
Nous aurons donc 4 entrées pour l'automate :
Et 3 sorties :
A noter : pour ceux qui ne sont pas familiers avec le terme TOR, cela veut dire que l'entrée ou la sortie ne peut avoir que deux états : ouvert ou fermé, allumé ou éteint, actif ou inactif, etc. comme un interrupteur.
Ce programme permet d'ouvrir le portail avec la télécommande. Puis le portail se referme après une temporisation.
La télécommande et les deux contacts de fin de course sont des entrées du Millenium. Les sorties commandent les deux sens de rotation du moteur.
Pour la programmation, nous utilisons les blocs FSC du Millenium.
Ce mode de programmation fait l'objet d'une normalisation internationale (IEC 61131-3) et est donc commun à plusieurs automates. Ce mode reprend en grande partie le formalisme Grafcet (voir http://fr.wikipedia.org/wiki/Grafcet).
Dans ce mode de programmation, le programme décrit le système sous forme des états qu'il peut prendre. En principe, un seul état est actif à la fois. Les enchainements entre états sont également décrits ainsi que les conditions qui permettent de passer d'un état à un autre (les transitions) et les activations faites quand chaque état est actif.
Chaque état défini comme une boite avec :
Notre exemple simple permettra de comprendre plus vite que des explications formelles.
La boite double en haut du programme (nommée "état initial") est le 1er état activé quand le programme est lancé. On voit qu'aucune liaison n'est connectée à droite ce qui signifie qu'il n'y a aucune commande à activer lorsque le programme est dans cet état (en clair dans cet état, le programme ne fait rien).
La barre horizontale sous la boite est la transition, c'est à dire la condition à satisfaire pour passer à l'état suivant. Pour sortir de cet état initial, il faut que la télécommande soit activée (le "bip").
Cette boite décrit donc l'état initial du portail. Il est fermé, rien ne se passe, et le système reste dans cet état jusqu'à ce que la télécommande soit activée.
Dans le programme, les liens gris indiquent les passages possibles entre états. Les petites flèches bleues donnent la direction du passage.
Les flèches noires transmettent les états des entrées et des sorties entre les différents blocs.
L'état suivant (nommé "ouverture") est donc activé lorsque la télécommande est activée. La commande du moteur pour ouvrir le portail est lancée, donc le portail s'ouvre. La transition vers l'état suivant indique que l'entrée "portail ouvert" doit être active, ce qui signifie que le portail est complétement ouvert.
Cet état est celui pendant lequel le portail s'ouvre, jusqu'à ce qu'il soit complétement ouvert.
Lorsque c'est le cas, le programme va dans l'état suivant (nommé "ouvert, tempo fermeture"). Cet état n'active rien (aucune connexion à droite), donc la sortie "ouverture portail" qui commandait le moteur se désactive : le moteur s'arrête. Le programme reste dans cet état jusqu'à ce que la sortie de la temporisation soit active. Cette temporisation A-C permet de retarder l'activation d'un signal. Dans notre cas, la sortie de la temporisation s'active un temps donné après que le l'entrée "portail ouvert" soit devenue active.
Dans cet état, le programme arrête le moteur et attend un temps donné. Une fois le temps écoulé, le programme passe à l'état suivant. Cet état permet de gérer l'attente du portail ouvert avant de se fermer automatiquement.
Le paramétrage du bloc de temporisation :
La temporisation est réglée à 10 secondes. C'est trop court pour un portail réel, mais pour tester le programme dans le simulateur Crouzet, attendre 10 secondes, c'est déjà bien assez long.
Il faudra donc que les valeurs des temporisations soient facilement réglables.
Dans le dernier état (nommé "fermeture"), le programme commande le moteur du portail dans le sens fermeture. Le programme reste dans cet état tant que l'entrée "portail fermé" n'est pas active. Lorsque c'est le cas, le programme va arrêter le moteur et retourner dans l'état initial.
En résumé, le comportement du portail avec ce programme est le suivant :
Nous voyons qu'avec seulement 5 blocs, nous avons déjà un programme de base qui fonctionne.
Les régles de sécurité rendent obligatoire la signalisation des mouvements du portail par un dispositif lumineux. Les mêmes règles stipulent que le dispositif lumineux doit être activé quelques secondes avant le mouvement.
Nous allons modifier le programme précédent pour utiliser le gyrophare orange pour satisafire ces règles.
Les états n'ont pas changé : nous avons juste ajouté une logique permettant l'activation d'une sortie gyrophare en coordination avec les sorties moteur.
Quand une commande moteur est activée, la sortie gyrophare est activée tout de suite, et l'activation de la sortie moteur est retardée de quelques secondes par une temporisation A-C : le gyrophare s'allume donc avant que le portail ne bouge dans un sens ou dans l'autre.
Le bloc OR permet une activation de la sortie gyrophare par plusieurs sorties (une sortie de bloc peut activer plusieurs entrées de blocs, mais l'inverse n'est pas possible).
En clair, la sortie gyrophare est activée quand on est dans l'état "ouverture" OU l'état "fermeture". Dès que le programme quitte ces deux états, le gyrophare s'éteint.
Notre programme précédent fait son travail correctement. Le portail s'ouvre à la demande et se ferme tout seul après quelques instants. Mais que se passe t-il si un obstacle reste dans l'ouverture ?
Nos programmes jusque là n'utilisent pas la détection de passage et ignorent donc si quelque chose empêche la fermeture du portail. Si une voiture reste bloquée dans le passage du portail, les dégats peuvent être considérables.
Que doit-on faire si on détecte un obstacle ?
Nous décidons du comportement suivant.
Quand le portail est immobile (fermé ou ouvert), il ne se passe rien : il n'y a pas de danger.
Mais si le portail bouge, pour s'ouvrir ou bien se fermer, il s'arrête immédiatement, attend que l'obstacle disparaisse, attend quelques secondes, puis s'ouvre complètement.
Il reprend ensuite le cycle normal : temporisation et fermeture.
C'est un peu arbitraire mais ça fonctionne bien dans la plupart des cas.
Beaucoup de portails ou de portes de garage automatiques fonctionnent de la sorte.
Programmer d'autres comportements est bien sûr possible, sans plus de complexité. A vous d'adapter.
Voilà le programme précédent, modifié pour la prise en compte de la détection de passage :
Les états "ouverture" et "fermeture" ont maintenant deux transitions vers deux états différents.
Une des transitions est la même que dans les programmes précédents et correspond au cas normal : le portail s'ouvre ou se ferme complètement sans qu'un passage soit détecté.
La nouvelle transition correspond à la détection d'un passage. Elle met immédiatement le programme dans le nouvel état "passage détecté".
Le programme ne sort de cet état qu'après un temps donné après la fin de détection de passage. En effet, cet état arme une temporisation. Mais cette temporisation est remise à zéro en permanence tant que la détection de passage est active.
Quand l'entrée "passage" est désactivée, la temporisation s'écoule. Quand elle est terminée, elle active la transition de l'état, et le programme va dans l'état "état ouverture". Le portail s'ouvre alors ou finit de s'ouvrir.
Les ajouts ayant pour but la sécurité, il est important de bien tester tous les cas possibles : passage détecté dans tous les états, passage court ou obstacle permanent, etc.
En utilisant le mode "Simulation" du logiciel du Millenium, vous pouvez vérifier le comportement du programme en cas de détection de passage dans tous les états.
Il est également important de vérifier le comportement si un obstacle reste bloqué indéfiniment.
A noter 1 : pour rendre le programme plus lisible, l'entrée "passage" utilise le câblage "texte" : la liaison n'est plus représentée par une flèche mais porte un nom textuel qui est porté par ses extrémités.
<à reprendre : il faut étudier la simultanéité des conditions dans les divergences, car si les 2 conditions sont vraies ensemble, les 2 états suivants sont activés en même temps>
Que se passe t-il si une panne d'alimentation se produit ?
Par défaut, le programme va redémarrer dans l'état initial lorsque l'alimentation va revenir.
Comme dans cet état, nous ne commanons rien, le portail ne bouge pas.
C'est satisfaisant si l'état avant la panne était l'état initial, mais que se passe t-il si le portail était dans un autre état ?
Puisque le programme reste dans l'état intial tant que la commande n'est pas activée, le portail ne bougera pas. S'il est ouvert ou partiellement ouvert, il restera dans cet état.
Le seul moyen pour le refermer est alors d'activer la télécommande, le portail va alors dérouler le cycle entier d'ouverture complète, attente puis fermeture.
Comme ce n'est pas satisfaisant, nous allons modifier le programme afin que le portail et le programme se resynchronisent seuls au démarrage.
La modification concerne l'état initial : il donne immédiatement le contrôle à un état à deux transitions "test état portail" :
Encore un fois, ce comportement est un choix.
On peut vouloir par exemple que le portail soit fermé tout de suite sans repasser par le cycle complet d'ouverture. Dans ce cas, la transition "portail non fermé" de l'état "test état portail" doit aller vers l'état "état ouvert, tempo" ou même "état fermeture".
A noter : la prise en compte du redémarrage après une panne d'alimentation peut être un peu plus complexe à prendre en compte. Il est volontairement simplifié ici par but didactique.