IMA4 2017/2018 P64
Présentation générale
Description
La conception de systèmes de contrôle/commande (robot, automate, machine outil...) s'appuie généralement sur une mise au point des développements à l'aide de simulations.
Dans ce cadre, le projet proposé consiste à développer la simulation d'un ascenseur en vue de sa commande par un automate réel. Le choix du langage est à déterminer au cours du projet. Cette simulation doit intégrer la prise en compte des appels paliers et cabine et la simulation des mouvements de l'ascenseur.
Objectifs
La finalité de ce projet sera de réaliser la commande d'un ascenseur, simuler sur un pc, à l'aide d'un API connecté grâce à un réseau Modbus. On pourra observé les différents états de l'ascenseur.
Préparation du projet
Cahier des charges
Choix techniques : matériel et logiciel
Pour réaliser ce projet, j'ai besoin de 2 ordinateurs , d'un module réseau Modbus avec connexion ethernet et série. ( présent dans la salle C001 )
Sur les pc , le logiciel Labview de version récente est nécessaire.
Un automate de commande sera par la suite nécessaire. ( présent dans la salle C006 )
Liste des tâches à effectuer
Calendrier prévisionnel
Réalisation du Projet
Feuille d'heures
| Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Analyse du projet | 1 | |||||||||||
| Réalisation du cahier des charges | 4 | 2 | ||||||||||
| Gestion modbus | 3 | 5 | ||||||||||
| Apprentissage du logiciel Labview | 3 | |||||||||||
| Réalisation de la partie Simulateur d'ascenseur | 5 | |||||||||||
| Réalisation du réseau Modbus sur Labview ( en mode Maître puis esclave ) | 2 | 3 | 11 | 3 | ||||||||
| Programmation de l'automate | 7 | 4 | 7 | |||||||||
| Finalisation Labview | 11 | |||||||||||
| Rédaction wiki | 3 |
Prologue
Semaine 1
La première parti de ce projet sera de comprendre le fonctionnement du protocole Modbus. J'ai donc commencé par la réalisation du tp de RLI effecuté en Ima 4. Ce tp étant nouveau, je n'ai pas eu l'occasion de le réaliser l'année dernière. J'ai pour l'instant pu lire la documentation technique fournie et faire la première partie du tp concernant la communication entre 2 pc avec la configuration série - modbus et ethernet - modbus.
Semaine 2
Une fois la communication entre les 2 ordinateurs effectuée grâce au réseau Modbus, la tâche suivante est donc de comprendre comment fonctionne réellement cette communication.
Tout d'abord la partie ethernet Modbus.
Je commence donc avec la modification d'une sortie digital. On doit suivre la trame suivante pour envoyer un ordre.
| Byte | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | Byte 8 | Byte 9 | Byte 10 | Byte 11 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Signification | Transaction identifier 1/2 | Transaction identifier 2/2 | Protocol Identifier 1/2 | Protocol Identifier 2/2 | Longueur de trame 1/2 | Longueur de trame 2/2 ( ici 6 ) | Identifiant | Fonction Modbus ( ici 5 ) | Adresse de sortie 1/2 | Adresse de sortie 2/2 | ON / OFF |
On va maintenant voir la lecture depuis le port Ethernet.
| Byte | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | Byte 8 | Byte 9 | Byte 10 | Byte 11 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Signification | Transaction identifier 1/2 | Transaction identifier 2/2 | Protocol Identifier 1/2 | Protocol Identifier 2/2 | Longueur de trame 1/2 | Longueur de trame 2/2 ( ici 6 ) | Identifiant | Fonction Modbus ( ici 1 ) | Adresse de début 1/2 | Adresse de début2/2 | Nombre d'octet à lire 1/2 | Nombre d'octet à lire 2/2 |
Ensuite la partie Série - Modbus. Cette partie ci fonctionne à peu de chose prêt à la précédente, mais il y a ici présence d'un CRC ( contrôle de redondance cyclique ) à chaque trame transmise. Un programme pré-existant permet de calculer le CRC lorsqu'on lui fournit tout le début de la trame. J'ai donc pu tester les messages envoyés avec le CRC calculé précédemment et vérifier la fonctionnalité de mes commandes.
Si l'on veut envoyer un ordre , on doit suivre ce modèle de trame :
| Byte | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 |
|---|---|---|---|---|---|---|---|---|
| Signinication | Adresse esclave | Code de fonction | Adresse de sortie 1/2 | Adresse de sortie 2/2 | Donnée d'envoie 1/2 | Donnée d'envoie 2/2 | CRC Low | CRC High |
Semaine 3
J'ai donc maintenant pu passer au contrôle d'une système ( ici gestion de remplissage de bouteille depuis une cuve ) à l'aide de la connexion Modbus sur une version de Labview antérieur. La simulation du remplissage et les liaisons Modbus étant déjà réaliser, j'ai pu comprendre comment était gérer la connexion entre les deux pc avec lecture et écriture sur les variables du simulateur.
J'ai donc réaliser l'automatisation de celui ci pour comprendre la logique Labview. L'étape suivante étant d'installer la nouvelle version Labview sur laquelle je dois travailler et réaliser la partie simulation d'ascenseur pour ensuite passer à la réalisation de la partie réseau.
Semaine 4
L'installation du logiciel LabView 2013 étant réalisé, il est maintenant question de prendre en main le logiciel pour permettre de réaliser la simulation de l'ascenseur. N'ayant utiliser ce logiciel que de façon utilisateur et non concepteur, tout reste à apprendre dans ce domaine.
Pour apprendre à utiliser le logiciel, je me suis servis de programme déjà réalisé. Celà m'a permet de comprendre le fonctionnement du logiciel et apprendre différentes structures. Une fois cette première étape réalisé, je me suis donc mis au travail concernant la partie simulateur d'ascenseur.
J'ai donc commencé de manière assez simple, contrôler l'ascenseur tout d'abord sans Modbus, en utilisant des entrées tout ou rien directement dans le programme de simulation. Cette première partie est essentiellement visuelle puisqu'il s'agit de voir à l'écran l'ascenseur monter et descendre et les portes s'ouvrir et se fermer. J'ai aussi ajouter les capteurs de position d'étage et de porte ouverte et fermée. Les capteurs sont en fait des comparaisons avec soit la position d'un objet, soit la valeur de celui ci ( sur une scrollbar par exemple pour les portes ).
Une fois cette partie réalisé, il a donc été question de contrôler de manière très sommaire l'ascenseur en réseau. L'automate que nous allons utiliser par la suite sera connecté par liaison série. Il est donc nécessaire de gérer la partie réseau Modbus série sur Labview.
Il n'est pas encore question de réaliser le programme de contrôle de l'ascenseur, seulement de tester l'envoie d'ordre et la lecture des réponses. Pour cette partie la, je suis actuellement bloqué sur l'utilisation de la librairie Modbus de Labview.
Semaine 5
Je suis actuellement toujours bloqué sur la liaison série. Le programme de communication avec le boitier WAGO est réalisé mais une erreur dû, il me semble, au driver,bloque directement mon programme dès l'initialisation de la liaison sur Labview. Même lors de la réalisation du programme le plus basique l'erreur apparait ( le programme tourne mais il ne peut rien envoyer , celà est observable sur les sorties d'erreurs ). Je cherche actuellement des solutions sur le site de National Instrument pour pouvoir avancer au plus vite.
Après des heures de recherches et avec consultations d'un des tuteurs, j'ai désinstaller la version Labview 2003 présent sur les pc. J'ai alors pu installer le nouveau driver VISA compatible avec la version Labview 2013.
J'ai donc pu tester le programme réaliser précédemment. La lecture et l'écriture sur la liaison série est bien réalisé. Une fois cette partie testé, le programme étant réaliser en tant que maitre sur le réseau et non esclave, il me reste à le modifier. Cependant cette démarche était nécessaire pour pour s'assurer du bon fonctionnement de la lecture et de l'écriture.
Semaine 6
J'ai pu commencer à travailler sur la programmation de l'automate Schneider. J'utilise le logiciel de programmation Unity pro. Un module de réseau Modbus est présent sur l'automate. l'automate est relié à l'ordinateur grâce à une liaison série. Ayant un programme sur Labview prévu pour fonctionner en temps que maître sur le réseau, j'ai commencer par mettre l'automate en tant qu'esclave pour comprendre rapidement comment accéder au variable présente sur l'automate depuis Labview. Avec cette manipulation j'ai pu découvrir comment était gérer les variables et quelles sont les trames Modbus à envoyer pour lire ou écrire sur les variables de l'automate. Il y a donc 256 variables possibles. L'écriture des trames est assez facile à réaliser quand on a bien compris comment elles sont formées.
La suite du travaille est de passer l'automate en mode maître et la partie Labview en tant qu'esclave. J'ai déjà pu regarder sur internet comment gérer la partie automate. Le site internet de Schneider donne pas mal d'explication sur ceci.
J'ai donc commencé par réaliser la partie sur Labview. J'ai pu ré-utiliser le travaille déjà effectué sur le programme esclave puisque l'écriture et la lecture des trâmes se fait de la même manière. J'utilise pour l'instant un compteur sur le buffer du port série permettant d'enclencher la lecture sur le port série. Une fois le programme réalisé, je ne peux pour l'instant pas la tester puisqu'il me faut l'automate en mode maître pour tester.
Je suis ensuite passé sur la programmation de l'automate. Après quelques recherches sur internet, j'ai pu trouver quelques pistes pour réaliser le programme. J'ai donc pu commencer la programmation.
Semaine 7
Ayant pu finir la programmation de l'automate, simplement pour tester le mode maître sur celui ci, c'est à dire envoyer une requête de lecture de variable ( READ_VAR ). J'ai rencontré pas mal de problème tout d'abord dû à une erreur de frappe dans une toute petite partie du programme. Une fois la fonction READ_VAR réalisé, j'ai pu la testé à l'aide de mon programme Labview. J'ai pu mettre des sondes sur la liaison série et observer les messages obtenues. J'ai alors pu identifier quelle requête est émise par la fonction dans Unity pro. Une fois identifiée, j'ai alors pu réaliser la réponse depuis Labview et donc envoyer le message depuis celui ci. On peut alors lire sur Unity pro dans un mot mémoire la réponse du simulateur. On peut donc, grâce à cette requête, lire l'état des capteurs de l'ascenseur, c'est à dire, les capteurs de présences, les capteurs de portes et les boutons poussoirs.
Un fois la partie lecture de variable effectuée sur l'automate, il faut ensuite passer à l'écriture. Le fonctionnement est le même avec une fonction WRITE_VAR directement dans unity pro. La partie dans l'automate est quasiment similaire à quelques ajustements près. Cependant, lorsque j'ai observé la trame sur Labview j'ai pu remarquer que la longueur de la trame n'est pas la même que précédemment. J'ai donc du mettre en oeuvre une solution permettant d'attendre que la trame soit complètement arrivée pour lire la requête uniquement dans le cas d'une requête d'écriture. Une fois le programme réalisé, j'ai donc testé cette partie et j'ai pu faire bouger l'ascenseur sur Labview en le commandant depuis l'automate.
L'étape d'après étant de mettre ces deux parties en commun pour réaliser un programme de lecture / écriture des variables.
Semaine 8
J'ai donc pu réunir la fonction d'écriture et de lecture dans un seul programme. Une fois cette tâche réussit, j'ai pu compléter la partie Labview pour être sur de disposer de toutes les variables nécessaires à la commande de l'ascenseur.
Une fois ce travail fait, j'ai pu grâce à la requête de lecture depuis l'automate, avoir la connaissance de chaque variable. En effet, la fonction de lecture d'automate remplie un mot mémoire d'une certaine valeur. Ce mot mémoire faisant 16 bits, j'ai donc utilisé un convertisseur pour transformer ce mot mémoire en un tableau de 16 bits bien distinct. En activant chaque variable une par une depuis Labview, j'ai pu les identifier. Pour l'écriture cela avait été géré précédemment.
Ayant à disposition toutes les variables, j'ai donc pu réaliser le grafcet de contrôle pour le simulateur. Ce grafcet contrôle l'ascenseur avec comme mode la priorité descendante. Ce grafcet a la possibilité d'enclencher un autre grafcet, celui ci responsable de l'ouverture des portes. Il admet une temporisation de 2 secondes pour pouvoir simuler la descente les personnes.
Il arrive que la détection d'une étage de face trop tardivement et que l'ascenseur s'arrête juste après un capteur d'étage. Ce cas a été pris en charge et replace l'ascenseur dans un état normal.
Figure 2 : Partie Réseau unity pro
Figure 3 : Gestion porte unity pro
Figure 4 : Programme principale unity pro
On peut ici observer sur la 1ère image le grafcet assez basique pour l'écriture / lecture des variables du simulateur. Ce programme tourne en continu et ne fait appelle à aucun autre programme. Il permet donc d'avoir en continu les variables du simulateur et d'envoyer les ordres aussi en continu.
Les outils présents dans Unity pro ont été conçus de façon que lorsqu'on envoie une trame de lecture ou d'écriture, il détecte lui même la réponse.
Sur la deuxième image, on peut voir le programme de gestion des portes. Il est déclenché par le grafcet principal.
La 3ème image représente donc le grafcet principal. Ce grafcet utilise les variables acquises par le 1er grafcet et fait donc la gestion de l'ascenseur en temps réel. On peut voir la gestion soit de la monter, soit de la descente en fonction des variables, l'activation du grafcet de gestion de portes puis la partie au cas ou un problème est détecté suite à un arrêt tardif.
On peut voir sur cette image l'interface labview lorsque le programme est en marche. 7 boutons TOR sont accessibles pour simuler les différents appels possibles. On peut aussi observer les capteurs de position, l'état des portes et les ordres .
J'ai donc pu contrôler l'ascenseur à l'aide de l'automate, le simulateur répond à l'automate à chaque requête.
Une erreur de transmission apparaît de temps en temps sur Labview. Il me semble que ce problème vient de l'ordinateur. Lorsque l'ordinateur se met à bugger un petit peu, le programme Labview devient plus lent et il y a accumulation de données sur le port série. Je ne suis pas totalement sûr mais lorsque je fais tourner un logiciel en tâche de fond assez puissant, cette erreur devient récurrente alors que le programme peut tourner 10 minutes sans problème le reste du temps.
Après vérifications de mon Labview, je me suis rendu compte que je gérais la partie boutons dans le simulateur et non dans l'automate. J'ai tout d'abord essayer de gérer les boutons en tant qu'entrés et sorties en même temps mais cela était impossible. J'ai donc opté sur la solution d'ajouter des voyants pour les boutons. Ceux ci sont gérer uniquement depuis l'automate. Les boutons présents dans le simulateur on était modifié pour être non plus des boutons TOR , mais des boutons poussoirs comme ceux présent dans les ascenseurs.
J'ai donc refait l'interface Labview pour y faire apparaitre tout les boutons
Dans unity pro, j'ai aussi ajouté un grafcet pour gérer ces boutons. Il détecte une impulsion sur les boutons d'appels et set un boolean à 1 à ce moment la. Il est reset lorsque le capteur de cet étage est à 1 et que les portes sont ouvertes.
Les programmes sont donc maintenant opérationnel. L'automate contrôle totalement le simulateur.
