APPLICATION DE SUPERVISION D’ÉQUIPEMENTS

Introduction

Notre projet consistait en la gestion de tout les équipements de la salle contrôlable en Modbus. Dans le cadre des études et réalisations des semestres 3 et 4, nous avons eu l’occasion de développer une application de test et de contrôle de l’ensemble des équipements présents dans la salle B018 (salle de Réseaux), par le biais du protocole Modbus/TCP avec une visualisation VNC. Pour mener à bien ce projet nous avons eu recours au logiciel Automation Studio qui nous a permis d’effectuer les différents essais et applications.

Comme le montre ce schéma, on va se servir d’une interface qui apparaîtra sur le PC, cependant tout le programme sera exécuté dans l’automate à l’adresse 200.200.200.175 qui, lui, contrôlera les équipements et nous permettra d’avoir une visualisation sous VNC (l’automate est serveur VNC, le PC, lui, est client VNC). La liste des équipements est la suivante, accompagnés de leur adresse IP dans la salle.

Intitulé : Modules : @IP :
Colonne Lumineuse MOXA .252 :2
Lampes Fluocompactes WAGO .215
Portique 206 WAGO .214/.219
RECDIGIT WAGO .210 :6
JANITZA JANITZA .251
WAGO 352 WAGO .179/.189/.199
BC0087 B&R .243/.244/.245
CIE-H10 SOLLAE .240
WAGO 841 WAGO .216/.217/.218
WAGO 315 WAGO .210 :9
CPU CP3586 .176
Modélisation du réseaux Modbus

Fonctionnement Modbus

Généralités

Le Client, par l’intermédiaire d’une trame requête, va envoyer des informations aux serveurs, dans notre cas, nos équipements. Les serveurs, à leur tour, vont répondre par le biais d’une trame réponse pour envoyer les informations demandées ou les actions demandées.

Avec Automation Studio, pour gérer la communication Modbus, nous allons créer les équipements et leurs attribuer une adresse IP. Au niveau de la configuration, nous allons créer des blocs qui seront composés d’un ou plusieurs « channels ». Ainsi, ces « channels » apparaîtront dans la gestion des entrées et sorties et auront donc une variable associée.

Modes de fonctionnement

Les échanges entre l’automate Client et les équipements serveur peuvent se faire de plusieurs façon, suivant le mode sélectionné lors de la configuration. Cyclique, Non-Cyclique ou bien Send Once.

Mode cyclique :

En mode cyclique, la communication est toujours active et va renvoyer constamment la valeur. On peut ici voir lorsque la valeur est a 1 on envoie 1.

Mode non-cyclique :

En mode non-cyclique, il y aura une valeur (ici, le bouton) qui va décider d’activer ou non la communication. Lorsqu’elle est active, elle fonctionne comme en mode cyclique. Lorsqu’elle est désactivée, la communication s’arrête et la valeur va se figer. La LED va donc rester allumer jusqu’à l’ordre d’arrêt.

Mode Send Once :

En mode « SendOnce », grâce au petit bout de programme (ci-dessus), nous n’occuperons la communication que lors de l’envoi (ou de la réception). En effet, quand « SendOnce » passe à 1, nous envoyons nos valeurs. Dans notre cas, vu qu’on veut envoyer la valeur de notre bouton, nous allons attendre un front sur celui-ci. Quand un front sera détecté, nous allons faire passer « SendOnce » à 1, ce qui permettra d’envoyer la valeur que le bouton aura pris. « SendOnce » ne repassera pas à 0 automatiquement, c’est pourquoi, on attend l’acquittement, qui passe à 1 seulement si les valeurs sont bien reçues par l’équipement. Une fois l’acquittement reçu, on remettra « SendOnce » à 0. Quant à l’acquittement, il repassera automatiquement à 0.

Visualisation

Nous pouvons voir ci-dessus, le menu général de notre tableau de bord. Un simple clic sur n’importe quel équipement vous amènera à une page détaillée. Nous avons disposé des témoins lumineux sur chaque équipement afin de vérifier l’état de celui-ci, repérés par leur adresse IP. Nous avons aussi regroupé les appareils similaires entre eux par souci d’ergonomie.

Par exemple lorsqu’on cliquera sur « Colonne Led » on aura la page ci-dessous (à gauche) qui permet de contrôler les trois lumières, une lumière par bouton. Et si l’on clique sur « Wago 841 » on aura la page ci-dessous (à droite) qui permet de contrôler 3 Wago différent et donc de contrôler leur sorties ainsi que de visualiser leurs entrées.

Module Janitza

Le module Janitza est un appareil de mesures intégré dans le réseau électrique de la salle de classe. Il est capable de mesurer des dizaines de grandeurs physiques. Nous l’avons configuré pour en transmettre 22 sur notre visualisation. Celle-ci affiche ces grandeurs selon deux modes de fonctionnement :

Le mode de visualisation en « temps réel », où l’évolution sur les graphiques se fait en continu par rapport aux mesures. Cela est réalisé grâce à la lecture des ports du Janitza associé à chaque grandeur physique.

Le mode de visualisation « historique », où les graphiques sont figés, représentant une évolution ayant eu lieu dans le passé. Ce mode de visualisation est plus pratique pour étudier ces mesures, et est permis grâce à la lecture d’un tableau préalablement rempli et donc les valeurs ont été stockées sans avoir été écrasées.

Nous avons configuré cet appareil de telle sorte à ce qu’il puisse nous communiquer :
La fréquence du réseau
Les intensités des courants sur chacune des trois phases
Les tensions entre chacune des phases et entre chacune de ces phases avec le neutre
Les puissances réelles, actives, réactives et le cos φ sur chacune des phases

Ainsi, il convenait de pouvoir visualiser toutes ces mesures grâce à notre application VNC. Voici un extrait de notre visualisation en temps réel :

Comme l’indique l’échelle à l’horizontale, les mesures en continu s’étalent sur 5 minutes avant de progresser en écrasant les mesures les plus anciennes : le fonctionnement est dit « dynamique »

Ci-dessous, vous pouvez vous apercevoir que les valeurs relevées sur les graphiques (partie de droite) correspondent, en temps réel, avec celle qu’indique le module Janitza via ses ports, chacun associés à une grandeur physique (partie de gauche – visualisation en mode monitoring du mapping du Janitza).

Ensuite, la visualisation « historique » consiste en la lecture de tables, une pour chaque grandeur physique, servant de lieu de stockage aux variables.

Ainsi, sur le graphique suivant vous pouvons observer un graphique en cours de remplissage :

Graphique affichant la lecture du tableau en cours de remplissage
Voici la table associée au fréquence, en cours de remplissage, comme en atteste les cases encore vide au moment de la capture, à partir de la 17ème case. Ainsi, le graphique plus haut se rempli au rythme de celui-ci et arrêtera de progresser au même moment

Module NetIO4ALL

Un autre appareil était directement lié au module Janitza, il s’agit de la multiprise NetIO4All. Cette multiprise est commandable à distance, et permets d’appliquer des charges supplémentaires sur le réseau. Grâce à cet appareil on a pu effectuer des tests en envoyant des charges sur le réseau et en observer l’impact sur les mesures du Janitza, vérifiant que l’on pouvait observer les modifications sur nos graphiques.

A gauche, la page d’accueil de la commande de l’appareil sur l’application VNC. A droite, une photographie de l’appareil.

Il convenait de configurer quatre commandes sur chacun des quatre Channels (les quatre prises) du module :
Une commande ON/OFF classique
Une commande ON DELAY, lançant le système pour un temps bien précis
Une commande OFF DELAY, eteignant le système pour un temps bien précis
Une commande TOGGLE, lançant le système lorsqu’il est éteint et l’éteignant lorsqu’il est en fonctionnement
De plus, pour les deux modes DELAY, nous devons pouvoir choisir le délai grâce à une fenêtre d’écriture numérique et un bouton UPDATE pour valider notre choix.

Ensuite, nous avons trois fenêtres d’affichage en temps réel pour les valeurs suivante : le courant, la puissance et l’énergie générés par la prise commandée.

Conclusion

Cette application répond maintenant au cahier des charges lié au projet. Elle permettra de rapidement voir l’état des équipements en ModbusTCP, et ainsi les nouveaux étudiant pourront rapidement voir les équipements Modbus de la salle, ainsi que ce que l’on peut faire avec ce protocole. En effet pour expliquer quelque chose comme un protocole c’est beaucoup plus agréable d’avoir un exemple, de plus il est possible d’observer les trames sous Wireshark. Cependant, pour éviter d’avoir trop de problème, l’automate n’accepte qu’un seul client VNC à la fois.

Ce projet se sera révélé très intéressant car il nous aura permis d’encore plus explorer les réseaux d’automates industriels. En effet, les TP ont été beaucoup moins poussés que le projet que nous avons fait. De plus, nous avions, lors du semestre 2, pu installer et configurer des automates. Ces deux projets, en plus des cours, nous donnent un véritable bagage pour le domaine de l’automatisme industriel.

Pour finir, nous tenons à remercier, bien évidemment, M.MERCKLE pour sa présence et, surtout, sa disponibilité nous permettant de parfois trouver des solutions à nos problèmes grâce à ses connaissances qui étaient plus étendues sur le sujet.


PILOTAGE SYNCHRONISÉ DE MOTEURS ASYNCHRONES

Synthèse du projet de pilotage synchronisé de moteurs asynchrones

Sommaire

  1. Introduction
  2. Cahier des charges
    1. Bête a corne
    2. Diagramme pieuvre et Tableau des fonctions
  3. Étude de l’installation
    1. Ancienne installation
    2. Installation actuelle
  4. Développement du pilotage synchronisé
    1. Moteur asynchrone
    2. Moteur Pas à Pas
    3. Servomoteurs
  5. Conclusion
  6. Annexe

1.Introduction

Dans le cadre de notre projet d’étude et réalisation, nous avons réalisé un projet permettant la commande synchronisé de deux moteurs asynchrones. Ce projet à été fait durant le Semestre 3 et 4. Nous avons eu pour objectif d’élaborer un banc d’expérimentation et de démonstration du contrôle de mouvement synchronisé basé sur deux moteurs asynchrones. Lors de ce projet nous avons 2 grandes parties qui ce sont dégagées. Nous avions une première partie sur l’étude et la réalisation de l’installation. Celle-ci consistait à étudier l’ancienne installation ayant seulement un moteur asynchrone, puis dans un second temps réaliser l’installation complète ayant deux moteurs asynchrones. La seconde partie concerne le développement des commandes pour les moteurs asynchrones. Pour cela nous avons tous d’abord étudié et développé des commandes de base sur différents types de moteurs. Puis dans un second temps nous avons développé les commandes et la visualisation des moteurs asynchrones avec leurs colonnes lumineuses.

Récapitulatif de l’ensemble de l’installation avant/après

Cahier des charges

Bête a corne

Ce projet doit permettre la synchronisation du mouvement de deux moteurs asynchrones grâce au contrôles de commandes

Diagramme pieuvre et Tableau des fonctions

FP1: Contrôle de mouvement synchronisé des moteurs : Pouvoir contrôlé la synchronisation des moteurs

FP2: Opérateurs : Permettre une utilisation facile des commande

FC1: Alimentation 230V triphasé : Alimenter l’installation en 230V triphasé

FC2: Ethernet Powerlink : Communiqué grâce à Ethernet

FC3: Normes : Respecter les normes de protection et de sécurité

FC4: Visualisation des commandes : Avoir une visualisation complète et fonctionnelle

Étude de l’installation

Ancienne installation

Dans un premier temps nous avons étudié l’ancienne installation. Cela avait pour but de comprendre le fonctionnement de l’installation ainsi que de connaître les principaux composants de celle-ci. Par la suite nous avons fait un croquis de l’installation pour avoir un schéma propre et compréhensible.

schéma de l’ancienne installation

A la suite de ce schéma nous avons réalisé plusieurs autres schémas allant de la partie alimentation à la partie commande du moteur. Lors de l’étude de la partie alimentation, nous nous sommes aperçus que certains équipements étant assez anciens ont dû être changés. L’installation est alimentée par un transformateur triphasé produisant du 230V. Le moteur asynchrone est câblé en couplage triangle. Pour la partie commande, nous avons remarqué que la boitier de marche/arrêt est alimenté par une phase du 230V triphasé.

Schéma de l’intérieur du boitier Marche/Arrêt

Sur le schéma ci-dessus nous avons le boitier Marche/Arrêt ainsi que son équipement de sécurité qui sont représenté. Nous pouvons voir que KM1 et KM2 permettent la connexion des différentes phases pour alimenter le variateur du moteur asynchrone. Nous pouvons voir que le contacteur permet de faire la connexion entre la partie puissance et la partie commande de l’ensemble variateur/moteur.

Installation actuelle

Après avoir étudié l’ancienne installation, nous avons conçus le schéma de la nouvelle installation. Celle-ci ressemble à l’ancienne installation avec quelques modifications.

Schéma de la nouvelle installation

L’installation permettra de piloter deux moteurs asynchrones avec deux variateurs. Pour cela nous avons juste à réalisé l’installation en double comme sur le schéma ci-dessus. Les boitiers de Marche/Arrêt ne seront plus alimentés par une phase du 230V triphasé mais ils seront alimentés en 24V. Pour cela nous devons intégrer un transformateur 230/24V. Celui-ci permet d’avoir 230V au primaire et 24V au secondaire. Nous avons rajouté deux disjoncteurs, le premier en amont et le second en aval du transformateur.Cela permet la protection des boitier Marche/Arrêt. Le reste de l’installation reste en 230V triphasé. Son fonctionnement reste similaire à l’ancienne installation. Les deux nouveaux ensembles variateurs/moteurs sont installés sur une même grille, pour avoir les deux ensembles côte à côte.

Développement du pilotage synchronisé

Moteur asynchrone

Nous avons commencé à étudié le pilotage du moteur asynchrone grâce à un ancien projet d’étudiants. Cela nous a permis de prendre en main le logiciel Automation Studio. Par la suite nous avons étudié les commandes existantes permettant de contrôler le moteur en créant une configuration permettant de relier la partie matérielle a la partie logicielle comme on peut le voir dans l’image suivante.

Pour pouvoir interagir avec le moteur, nous avons testé toutes les commandes étant déjà en place sur l’interface Homme-Machine. Nous pouvions par exemple démarrer,arrêter où choisir la vitesse de rotation du moteur. Par la suite nous avons améliorer le programme ainsi que l’interface. Nous avons ajouté et vérifié si toutes les variables étaient correctes et nous les avons fait apparaître sur l’interface.

Visualitation IHM

Ci-dessus nous avons l’interface Homme-Machine du moteur asynchrone. Pour pouvoir démarrer le moteur nous devons suivre quelques étapes. Tous d’abord la variable « MpAxisBasic » doit être activé. Elle permet de contrôlé l’axe du moteur et à été ajouté par nos soins pour pouvoir choisir le type d’axe que nous voulons pour plus tard. Puis la variable « Power » doit être activé ainsi que la variable « Home ». La variable « Power » met le moteur en marche et la variable « Home » met le moteur en position initial. Puis nous mettons en marche la variable « Move Velocity » qui va faire tourner le moteur si une valeur est donnée. Nous avons un graphique qui trace l’évolution de la vitesse du moteur en fonction du temps. Par la suite nous avons rajouté 2 nouvelles variables une pour la décélération et une pour l’accélération. Nous pouvions donc entrer une valeur dans ces deux variables et voir que le graphique changeait selon les valeurs rentrées. Pour arrêter le moteur nous avions la variable « Stop » et si un problème survenait nous avons la variable « ErrorReset » qui permettait de remettre à zéro toutes les variables pour pouvoir redémarrer le moteur.

Moteur Pas à Pas

Après avoir étudié le moteur asynchrone, nous nous sommes intéressés aux moteurs Pas à Pas. Nous nous sommes aidés de l’interface faite précédemment pour cette partie. Dans cette partie nous devions créer et utilisé une visualisation comportant 2 couplages. Nous aurions le choix entre un couplage linéaire et un couplage CAM entre les deux moteurs. Nous avons réutilisé le programme et les blocs utilisé dans la partie précédente pour vérifier le bon fonctionnement des moteurs. Pour la suite de cette partie nous avons créer 2 blocs permettant de contrôler un moteur chacun et un troisième bloc pour gérer le couplage entre les deux moteurs.

2 blocs MpAxis_0 et MpAxis_1 pour la commandes de 2 axes et un bloc MpAxisCouplig pour le couplage entre les 2 axes

Le premier bloc nommé « MpAxisBasic_0 » permet de contrôle l’axe d’un des deux moteurs, celui-ci servira d’axe maître. Les 3 variables les plus importantes de ce bloc sont encadrer en rouge. La première variable « gMpLinkAxe2 » permet de gérer la mise en route du moteur maître. La seconde variable « AxisPar2 » quand à elle permet de gérer les réglages du moteur (sens de rotation,vitesse de rotation…). Puis la dernière variable « gAxis03 » permet l’identification de notre axe maître par rapport à l’axe esclave. Nous avons un second bloc similaire appelé « MpAxisBasic_1 » qui permet de contrôler le second moteur.

Le second bloc nommé « MpAxisCoupling » permet de contrôlé l’axe et le couplage du moteur esclave. Nous aurons le choix entre le couplage linéaire ou le couplage CAM. Le couplage linéaire ressemble à des roues dentées de son fonctionnement donc nous choisissons la vitesse de multiplication de l’axe esclave par rapport à l’axe maître. Cette axe suis les besoins de l’axe maître mais est plus difficile à mettre en place pour un mouvement balancier. Contrairement au couplage linéaire, le couplage CAM est quand à lui beaucoup plus performant. Ce couplage permet d’utilisé n’importe qu’elle sens de manière précise et efficace. Les 3 variables les plus importantes sont aussi encadrées en rouges. La première variable « gMpLinkAxe1 » permet de gérer la mise en route du moteur esclave. La seconde variable « AxisPar3 » quand à elle permet de gérer les réglages du couplage. Puis la dernière variable « gMpLinkAxe2 » permet la représentation de l’axe maître que l’axe esclave va devoir suivre.

Après avoir crée les différents blocs nous avons introduit les nouvelles variables sur l’interface. Nous avons une partie pour activer et commander l’axe maître. Puis nous avons une seconde partie pour activer l’axe esclave. Pour finir nous avons une partie permettant de voir si les moteurs sont prêt à être couplés puis nous pouvons choisir entre les 2 couplages différents. Nous pouvons donc choisir de contrôler les moteurs de manière séparé ou de manière couplé.

IHM des moteurs Pas à Pas

Pour pouvoir démarrer les moteurs nous devons refaire les mêmes étapes énoncés dans la partie moteur asynchrone. Puis pour choisir le couplage nous avons la variable « GEAR » qui est la variable pour avoir le couplage linéaire et nous avons la variable « CAM » qui est pour la couplage CAM. Nous avons 2 entrée numériques qui sont « NUM » et « DEN » qui permettent de rentrer 2 valeurs une au numérateur et l’autre au dénominateur pour calculé un rapport de transformation. Puis pour prendre en compte les nouveaux réglages fait nous avons la variable « UPDATE ».

Servomoteurs

Nous allons étudié un dernier type de moteurs. Ces moteurs sont des servomoteurs. Un servomoteur est un système produisant un mouvement grâce à une commande externe. Pour cette partie nous allons nous aidés des blocs de la partie précédentes. Nous gardons les mêmes variables, les seuls qui changent sont les variables encadrées en rouge.

Bloc MpAxisBasic_0

Le bloc nommé « MpAxisBasic_0 » permet de contrôlé l’axe maître. Celui-ci sera un axe virtuel contrairement à la partie précédente où nous avons un axe maître réel. La première variable nommée « gAxisBasic » permet de contrôlé les différentes commandes de l’axe. La seconde variable « AxisPar » permet de contrôlé les différents réglages concernant le moteur. Pour la dernière variable « gVAxis01 », celle-ci permet d’identifiée l’axe que nous allons contrôler. Pour cette variable nous allons utilisé l’axe virtuel. Nous avons 2 autres blocs nommé « MpAxisBasic_1 et MpAxisBasic_2 », qui sont similaire au bloc ci-dessus mais permettent de contrôler les axes réels des servomoteur 1 et servomoteur 2.

Bloc MpAxisCoupling_1

Le bloc ci-dessus nommé « MpAxisCoupling_1 » nous permet de faire le couplage entre deux axes. Nous avons la première variable « gAxisBasic_2 » cette variable représente l’axe esclave d’un des moteurs. La second variable « AxisPar4 » celle-ci permet de choisir les réglages de l’axe. La dernière variable « gAxisBasic » représente l’axe maître que va devoir suivre l’axe esclave. Nous avons un second bloc de couplage pour le second servomoteurs ayant les variables différentes mais un fonctionnement similaire.

Pour la partie visualisation nous avons réutilisé IHM de la partie précédente que nous avons amélioré et ajouté les différentes variables nécessaires.

IHM des servomoteurs

Nous avons ajouté une partie maître pour nous permettre d’allumer et de contrôler l’axe virtuel. Le reste des variables restent les mêmes et les étapes pour allumer les moteurs sont identiques à toutes les parties. Nous avons juste à active la partie maître en premier si nous voulons que les moteurs suivent l’axe virtuel.

Conclusion