Version actuelle datée du 11 mai 2020 à 21:38

Présentation générale

Description

Notre projet consiste à réaliser un simulateur configurable de processus physiques destiné à la conception et au développement de systèmes automatisés.

Cette application devra avoir une interface facile d'utilisation donnant la possibilité d'interagir sur la simulation physique via des boutons, et lisible afin d'avoir une vue sur les états des objets et des capteurs que comportent leur système.

Ce projet s'inspire des besoins de développement des outils de production tels qu'ils sont vus dans le concept d'industrie 4.0.

Objectifs

Cette application doit ainsi simuler le comportement dynamique des objets d'une scène, et permettre de les visualiser dans un environnement éventuellement en 3D.

L'application contiendra un simulateur de processus physiques autonome dont les paramètres pourront être initialisés par l'utilisateur.

Par ailleurs, dans un but de conception d'un contrôle commande, le simulateur doit pouvoir également communiquer avec d'autres applications, dont le système de contrôle commande, et échanger des informations liées à l'instrumentation, c'est-à-dire à l'état des capteurs et aux ordres donnés aux actionneurs.

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent

RoboDK est notre premier concurrent. Cet entreprise propose une logiciel de simulation de robots industriel exactement comme notre projet.

Points forts :

• Grande bibliothèque de robot industriels intégrée
• Calibration de robot existants
• Export des programmes compatibles avec les principaux microcontrolleurs de robots
• Optimisation automatique
• Compatible Linux/Android/MacOS/Windows

Points faibles :

• Prix (2995€/an)

Nous voulons proposer un logiciel plus spécialisé mais gratuit.

Analyse du second concurrent

DELMIA Robotics est notre second concurrent. Ce logiciel fait partie du portofolio 3DSEXPERIENCE a coté de logiciel comme CATIA ou Solidworks.

Ses points fort sont :

• Prédiction et detection des erreurs
• Gestion centralisé de tous les robots d'une chaîne de production
• Planning du coût de la chaine de production, prenant en compte beaucoup de paramètres
• Société mère reconnue : Dassault-Systèmes.

Point faibles :

• Prix (non affiché, se négocie au cas par cas)
• Difficulté de prise en main
• Est optimal au sein d'une suite d'outils également onéreux
• Non disponible sous Linux

Le logiciel crée lors de ce projet se veut plus simple et léger et sera disponible sous Linux.

Scénario d'usage du produit ou du concept envisagé

L'utilisateur peut être un technicien, un ingénieur ou un étudiant.

Il utilisera les bibliothèques d'objets afin de créer un système permettant de réaliser les tâches qu'il souhaite accomplir.

L'utilisateur utilisera le logiciel pour simuler un système physique et l'étudier, il aura le choix entre paramètrer les capteurs du système qui agiront sur des actionneurs, ou lancer la simulation en mode libre afin d'avoir un système modulable en temps réel via les boutons de l'interface utilisateur qui agiront sur les actionneurs.

Il peut ensuite, après l'avoir simulé avec notre logiciel, décider de le réaliser ou non.

Exemple de scénario d'usage :

Une entreprise souhaîte créer un réseau de tapis roulants automatiques afin d'amener une caisse d'une postion de départ jusqu'à un endroit de stockage prévu à cet effet. Il va utiliser notre application afin de créer son système qui est une chaîne de tapis roulants qui comporte par exemple un tapis où l'on dépose les caisses et plusieurs zone de destination. L'utilisateur placera des capteurs aux bords des tapis roulants qui capteront si une caisse arrive, un autre capteur détectera sur la caisse la destination affichée. En fonction de ce que le capteur lit, la caisse va par exemple être ammenée sur un tapis roulant qui tourne à gauche au lieu d'aller sur celui qui tourne à droite. L'utilisateur pourra lui-même placer les capteurs et les programmer afin d'activer certains mécanismes (par exemple le plateau rotatif qui choisi la direction de la caisse) via des actionneurs, il créera donc des liens entre capteurs et actionneurs en choisissant un certain délais d'attente entre la détection et l'activation du mécanisme.

Réponse à la question difficile

Problématique: Définir les champs d'applications de notre projet et le logiciel utilisé.

Utilisation de Godot pour la partie animation. Envoie d'ordre à partir d'un terminal par voie TCP/IP vers Godot

Bibliographie et webographie

Etude des concurrents :

RoboDK : https://robodk.com/index

Delmia Robotics : https://www.visiativ-industry.fr/delmia-robotics/

Préparation du projet

Cahier des charges du groupe

• Etudier les solution logiciels possible (Avantages, inconvénients)

Cahier des charges

• La création de l'interface utilisateur comprenant :
  • la scène permettant de visualiser la simulation
  • un contrôleur du système via des boutons

• La modélisation du système :
  • modélisation de différents types de capteurs
  • fonctionnalités propres aux objets ajoutés par l'utilisateur (temps de marche, vitesse de déplacement...)

• La création du système communiquant avec d'autres applications et d'échange d'informations liées à l'instrumentation :
  • création de commandes pour agir sur le système
  • implémentation de l'utilisation d'un automate

Choix techniques : logiciel

Pour concevoir notre application nous utilisons le moteur de jeu Godot.

Les raison sont les suivantes :

• Optimisation , logiciel écrit en C++
• facilité d'installation
• prise en main rapide
• interfaçage du langage d'edition Godot script avec C++ possible si nécessaire

site : https://godotengine.org/

Exemple de communication interprocessus (ajout de B. Conrard)

Les codes suivants forment un exemple de communication entre 2 applications, ici en python 2.7, au travers d'une communication TCP/IP.

• Fichier:Code comm python BC.zip

Liste des tâches à effectuer

Nous nous organisons avec un Trello :

Lien : https://trello.com/b/8wZ9xndy

Répartition du travail

Equipe 1 : Simulation

Alex Lagneau

Quentin Normand

Clément Hue

Equipe 2 : Communication

Corto Callerisa

Sébastien Dardenne

Réalisation du Projet

Projet S6

Le projet se divise en 2 parties, la première étant de mettre en place les objectifs du sujet, l'étude des différents logiciel de simulation et la recherche des méthodes de communication existante. La seconde partie est la modélisation du système sous Godot et la mise en place de la communication.

Semaine 1

Découverte du projet, présentation par M. Conrard de systèmes existant dans Polytech et précision sur la finalité du projet.

Nous avons notamment découvert un logiciel correspondant à l'application de notre projet; celui-ci permet de simuler différents systèmes tout en ayant la vision de l'état de tous les capteurs et de donner libre cours à l'utilisateur de modifier et manipuler ces systèmes. Cette démonstration nous permet de mieux cerner notre projet et nous allons nous appuyer sur les fonctionnalités de cette application pour construire notre projet.

De plus, nous avons découvert dans la salle C006 des systèmes réels comme l'ascenseur et un train miniature reliés à des commandes. Nous pensons donc créer ces systèmes dans notre logiciel pour, après les avoir simulés, pouvoir les appliquer sur ces systèmes réels.

Semaine 2

Recherche des logiciels concurrents déjà existants et développement des objectifs.

Semaine 3

Présentation orale, nouvelle problèmatique : Définir les champs d'applications de notre projet et le logiciel utilisé.

Semaine 4

Mise en place du cahier des charges divisé en 3 parties : Modélisation/Simulation, Réseau et Commande. Première étude sur le choix du logiciel à utiliser pour notre système (UnrealEngine, Unity, Godot) ainsi que pour les différentes méthodes de communication.

Lien vers la justification des choix du moteur graphique :[1]

Semaine 5

Présentation par M. Conrard d'un exemple de communication sur un système de train en 2D. Choix du logiciel Godot pour la simulation, tests d'applications déjà existante.

Semaine 6

Prise en main de Godot à l'aide du tutoriel, Prise de RDV avec M. Conrard pour l'organisation des tâches. Étude de l'exemple du TCP/IP fourni. Découpage des tâches dans l'optique SMART avec le site trello.com

Semaine 7

Essai d'utilisation du script donné par M.Conrard

Justification du choix de méthode de communication parmi TCP/IP, pipes, mémoire partagé.

Nous avons choisi de partir sur un des projets présenté dans la salle C006 par Mr Conrard, l'ascenseur. Cela nous permettra de tester l'utilisation d'un automate.

Lien vers la justification des choix du système de communication: [2]

Semaine 8

Simulation

Création d'une caméra pour se déplacer dans l'espace godot :

Communication

creation d'une "proof of concept" communication UDP entre deux programmes godot. La communication se fait en un seul sens.

Voici le serveur.

Et le client :

Cela fonctionne mais le client n'envoi qu'un seul message.

Semaine 9

Simulation

Cette semaine nous avons modélisé la cage d'ascenseur directement dans l'interface de Godot. Il a des portes coulissantes qui pourront être activées par l'appui d'un futur bouton et elles s'ouvriront automatiquement quand l'ascenseur arrivera à son étage de destination.

Modélisation de l'ascenseur et des portes :

Création du script qui permet l'ouverture des portes de l'ascenseur :

Commande

Création des scripts Python pour se connecter au godot :

Semaine 10

Simulation

Cette semaine nous ajoutons des boutons et les capteurs. Les capteurs utilisent l'objet RayCast de Godot qui permet de regarder dans une direction les objets qui sont présents. Le bouton a été plus compliqué à implémenter car il n'y a pas d'objet bouton existant dans Godot, nous avons pris un script sur un forum que nous avons adapté à notre utilisation. La fonction permettant d'activer un bouton se trouve dans le script relié à la caméra et utilise un RayCast pour détecter au clic si un bouton est présent dans la vue de l'utilisateur.

Modélisation des boutons et des capteurs :

Permet l'appel de l'ascenseur à un étage.

Détecte la présence de l'ascenseur pour connaître sa position.

Script du bouton permettant l'appel de l’ascenseur :

Commande

Modification du programme pour envoyer l'etat sur un autre serveur UDP.

Voici le code python :

Semaine 11

Simulation

Nous avons créé une scène globale comportant 6 niveaux pour l'ascenseur et un bouton à chaque palier. A chaque étage nous avons mis 2 capteurs car il faut détecter la position de l'ascenseur quand il est en train de monter ou de descendre. Les capteurs ne réagissent que quand un objet arrive devant lui mais pas quand un objet quitte son champ de vision, c'est pour cela qu'il faut un capteur en haut et un capteur en bas de l'étage.

Assemblage des différents objets afin de créer une scène globale :

Ajout du script des fonctions permettant le déplacement de l'ascenseur :

Commande

Implémentation d'un terminal pour l'envoi des commandes.

Semaine 12

Simulation

Ajout du boitier intérieur :

Vidéo de présentation

Média:vidéopresentation.mp4

Rapport du projet

Fichier:CR Projet IMA3 p8 v1.pdf

Code du projet

Fichier:IMA3 P8 Ascenseur.zip

Remarque de la présentation

• Pas de code dans les diapositives.
• Diapo trop sombre.
• Intro/Conclusion : Ne pas mettre que le titre.
• Rapide/Lent : Mettre un ordre de grandeur, chiffrer l'objectif opérationnel.
• Répartir des diapositives en fonction de la charge de travail effectuée.
• L'oral doit être lié à la diapositive, rester dans le sujet.
• Pas de répétition, diviser la soutenance en partie bien définie.
• Mettre des mots-clés sous les images des diapositives.

Projet S7

Semaine 1

Recherche des points d'amélioration de notre projet suite aux remarques de la soutenance. Prise de rendez-vous avec M. Conrad pour clarifier les objectifs du semestre.

Le projet se découpe en 2 parties (simulation et communication). Et le but du projet et de reproduire les différentes maquettes de TP sous le logiciel GODOT afin de pouvoir remplacer les maquettes physiques si nécessaire.

Simulation : Alex LAGNEAU et Quentin NORMAND

Communication : Corto CALLERISA et Sébastien DARDENNE

Simulation

Les objectifs de ce semestre sont de créer une application pour que l'utilisateur puisse créer un projet de simulation avec des objets (capteurs, chassis, actionneurs...). Nous aurons donc une application contenant des scènes en 2D et une scène en 3D dans laquelle on peut voir et ajouter les objets du projet. On devra aussi modifier notre scène de simulation que nous avons présentée à notre soutenance pour que nous puissions voir en temps réel les états des capteurs et actionneurs.

Étude de la portabilité d'éléments entre projets sur GoDot pour pouvoir les réutiliser.

Communication

Afin de remplacer la maquette physique facilement/rapidement par la simulation GODOT, notre objectif est de connecter les automates programmables existant à la simulation.

Semaine 2

Simulation

Nous avons choisis d'utiliser un système de bibliothèque en Godot que nous devrons remplir avec les objets que nous créons. Cette bibliothèque sera ensuite disponible dans l'interface utilisateur pour qu'il puisse "drag and drop" ces objets directement dans son projet.

Communication

Les automates Schneider communiquent à l'aide d'un module USB-4750 d'Advantech. Nous avons commencé par étudier ce module et ses caractéristiques (DataSheet [3]).

Néanmoins, les informations n'étaient pas suffisante pour utiliser le module, nous avons alors étudié le kit de développement fourni par Advantech afin de tester la communication avec le module.

Semaine 3

Simulation

Afin de lier et d'utiliser de manière graphique et efficace notre bibliothèque d'objet, nous avons du implémenter notre interface 3D déjà existante dans une scène en 2D. La scène en 2D permet de sélectionner nos objets, il s'agira d'un menu permettant de faire du glisser-déposer. Ça a été compliqué à implémenter, notamment pour gérer les actions de la souris et les mouvements de rotation de la scène 3D.

Communication

Installation et teste de l'ensemble du SDK. Après avoir configuré le module nous testons particulièrement les entrés/sorties digitales. Voici à quoi ressemble la fenètre : .

Un problème surgit alors, car après un test complet, un seul interrupteur physique communique avec le logiciel.

Nous étudions alors les différents exemple de code fournis afin de déterminer comment intégrer le sdk à notre application.

Semaine 4

Simulation

Mise en place du 'Drag and Drop' sous Godot. Pour l'instant, nous faisons en sorte de déplacer des objets en 2D par dessus de la zone en 3D pour avoir une visualisation rapide de l'endroit où on place l'objet; cependant cette manière d'utilisation est peut intuitive pour le placement dans la zone 3D.

Communication

Nous avons finalement choisi de partir de l'exemple de reception de status d'interrupteurs tout ou rien en C++, car cela permettra de l'ajouter directement à notre application Godot en tant que libraire externe.

Voici un extrait de l'exemple modifié pour communiquer avec l'automate. La ligne 48 défini le chemin du profil crée.

Le programme de teste affiche chaque seconde l'état du seul interrupteur communiquant. Nous constatons que la communication s'effectue mais avec un certains taux d'erreur que nous n'avons jusqu'alors pas réussi à expliquer.

On constate le changement de status de l'interrupteur connecté au port 1

L'objectif du semestre prochain est de résoudres ces problèmes et d'intégrer complêtement le module à la simulation godot afin de fournir un seul executable dans un but de simplicitée.

Objectif

Reproduire un système sous Godot (Exemple : maquette des trains en C008, Cuve) en modifiant la commande actuelle par l'automate de la maquette.

Documents Rendus

Projet S8

Semaine 1

Simulation

Restructuration des éléments de la fenêtre pour améliorer les interactions entre les objets de la scène.

Ajout de la toolbar en haut de la fenêtre qui permettra d'enregistrer des fichiers, des projets, de charger des projets, lancer la simulation,...

Communication

Prise de rendez-vous avec Mr Conrard pour avoir plus de renseignements sur le fonctionnement de l'automate. Suite à cela, nous avons utilisé le logiciel Unity Pro communiquant avec l'automate pour constater les changements d'états en utilisant le logiciel DAQNavi fourni par Advantech, la société conceptrice du boitier USB-4750. La communication entre l'automate et DAQNavi est fonctionnelle.

L'interface ci-dessus permet de forcer les états de l'automate. Cette fois nous constatons le fonctionnement et l'utilité de chaque interrupteur contrairement à la semaine 3 du S7.

De plus suite au remarques de notre soutenance nous avons bien déterminé le rôle du boitier par rapport à la simulation : Le boitier permet de faire le lien entre les E/S 24v de l'automate et le PC en USB dans le but de simuler un processus physique du point de vue de l'automate. Dans ce cas le processsus simulé est le programme de Pick'n'Place.

Ce programme est une implémentation professionelle de ce que notre projet vise à faire vis à vis des machines physique de la salle : Ascenseur, Station de perçage.. Pour notre projet nous utiliseront le SDK proposé par Advantech comme moyen de communication avec l'automate.

Semaine 2

Simulation

Travail sur l'arborescence des objets. Création de fonctions pour ajouter des noms dans l'arborescence, savoir quel nom est sélectionné et pouvoir retrouver un objet dans l'arborescence a partir d'un string qui contient le chemin de l'objet dans l'arborescence.

Communication

Nous ré-essayons les exemples de programme fournis dans la documentation du boitier pour communiquer : StaticDI.cpp et StaticDO.cpp. StaticDI.cpp permet de lire les entrés digitales de l'automate tandis que StaticDO permet de controller les sorties. Cependant les valeurs obtenus de sont pas cohérentes avec les valeurs de l'automate.

Nous cherchons une autre façon pour communiquer avec le boitier afin d'avoir une base de laquelle partir.

Semaine 3

Simulation

Modification légère des fonctions créées la semaine dernière. Ecriture des fonctions dans le script de l'application permettant d'ajouter des objets à la fois dans le noeud des objets du système 3D et dans l'arborescence créée la semaine dernière grâce à l'appel des fonctions de l'arborescence.

Communication

Suite à nos recherches nous retenons l'implémentation python suivante : https://github.com/pohmelie/python-advantech-DAQNavi-bdaqctrl. C'est un driver python encapsulant le driver Advantech bdaqctrl.h avec deux implémentation. La première utilise le logiciel Swig pour interfacer le C++ avec python tandis que la seconde utilise la bibliothèque C Foreign Function Interface for Python (CFFI). Nous choisissons cette dernière car l'ajout d'un autre language étranger (SWIG) rajouterai une couche de complexité lors de l'intégration à Godot.

Semaine 4

Simulation

On continue à écrire les fonctions permettant d'ajouter des objets au système et création d'un menu popup pour sélectionner dans la bibliothèque l'objet à ajouter.

Communication

Nous avons donc créer une version du code C en enlevant une directive include afin de l'importer dans la bibliothèque CFFI du script python. Néanmoins au lancement du script, une erreur apparait en nous disant qu'il est impossible d’accéder au boitier USB-4750. Nous essayons alors d'installer les sources du SDK pour linux mais les drivers ne sont pas compatibles sous Manjaro.

Semaine 5

Simulation

Mise en place d'un menu pour sauvegarder les modifications apportées au projet dans l'application. On peut créer des fichier, les ouvrir, lire les informations enregistrées mais l'arbre d'objet n'est pas encore sauvegardé.

Communication

Pour pouvoir installer les drivers, nous décidons d'installer Ubuntu sur un ordinateur portable. Suite à cette installation, nous lançons alors l'installation des drivers du boitier depuis les paquets officiels. Après l'installation, on constate que le driver de l'USB-4750 n'est pas disponible. Nous décidons donc de revenir en arrière en prenant un rendez-vous avec Mr Conrard.

Semaine 6

Simulation

Du côté de l'application je me suis penché sur le déplacement des objets dans le système. A la fin de la séance on peut maintenant positionner l'objet en rentrant les coordonnées à la main dans l'onglet propriétés (en bas à droite) et modifier sa rotation. J'ai commencé à gérer le déplacement des objets par la souris, pour cela j'ai créer des objets qui ont la forme d'une flèche sur lesquels nous détectons le clic de la souris. Dans la suite nous devrons essayer de lier cet objet "flèche" qui permettra de faire un déplacement rectiligne de l'objet selon la direction de la flèche.

Communication

Nous décidons donc de refaire une installation des logiciels DAQNavi et avec l'aide de Mr Conrard, nous réessayons les scripts C++ Digital Input et Digital Output. Nous constatons que le profil était mal configuré et après reconfiguration la communication est fonctionnelle.

Période Coronavirus

Simulation

Les objectifs et points à finaliser pour finir le projet :

• déplacement des objets avec la souris
• sauvegarde et chargement des systèmes créés
• ajouter la personnalisation des capteurs

25/03

Le déplacement avec la souris avance doucement mais sûrement, encore beaucoup de bugs à fixer mais on peut déjà faire des déplacements qui restent néanmoins limités...

26/03

Nous pouvons maintenant déplacer les objets avec la souris et le clavier (en rentrant les coordonnées) de façon correct; des améliorations sont possibles mais afin de remplir les objectifs je me penche maintenant sur la sauvegarde et le chargement de systèmes.

31/03

Pour sauvegarder les objets dans un fichier, il faut que chaque objet possède une fonction "save" renvoyant un dictionnaire avec ses attributs et donc il faut aussi qu'ils aient tous un script associé. Pour généraliser ce système de sauvegarde, j'ai créé des classes suivant la hiérarchie suivante :

• Une classe mère "GlobalObject" contenant les variables globales à tous les objets et la fonction save renvoyant un dictionnaire avec les attributs que tous les objets contiendront. On peut aussi associer un script à cette classe qui contiendra les fonctions de comportement de l'objet.
• Une classe "Capteur" qui hérite des attributs et des fonctions de la classe GlobalObject. Elle contient en plus des attributs spécifiques au capteur et on réécrit la méthode "save" qui appelle la méthode" de la classe GlobalObject et y ajoute ses attributs spécifiques.
• Une classe "Actionneur" qui, comme la classe capteur, hérite de la classe GlobalObject en y ajoutant ses attributs et en réécrivant la méthode "save".

Ces classes seront surement modifiées dans le futur pour rajouter des attributs ou des méthodes qui sont communs à tous les objets capteurs ou actionneur. Comme dit précédemment, on pourra associer à chaque object - que ce soit un capteur, un actionneur ou un objet quelconque - un script décrivant un comportement particulier comme par exemple celui de l'ascenseur qui ouvrait et fermait ses portes lors d'un appel de celui-ci.

02/04 & 03/04

On peut maintenant sauvegarder et charger différents projets !

J'ai remarqué qu'il y avait encore quelques bugs sur la sélection et le déplacement des objets avec la souris, je vais donc essayer de fixer les problèmes rencontrés.

Avril

On peut désormais ouvrir l'interface simulation! On sauvegarde l'état d'un projet dans un fichier texte qui s'ouvre dans une nouvelle fenêtre. Dans cette fenêtre de simulation il n'est alors plus possible de modifier le projet, mais on peut par exemple mettre en marche l'ascenseur et récupérer l'état des capteurs et des actionneurs.

Communication

Nous continuons d'intégrer les scripts de communication avec la partie simulation en tant que module externe Godot. Mais avec le confinement nous ne pouvons pas tester directement avec l'automate. Après discutions avec les encadrants nous allons essayer de simuler l'automate par un programme python.

Le développement à faire est le suivant :

• Intégration des codes drivers de l'automate en C++ à Godot, avoir une compilation valide - Valide 12/04
• Développement d'une interface communicante avec l'automate virtuel. - Valide 21/04
• Développement de l'automate virtuel. - Valide 27/04
• Intégration finale de l'automate dans la simulation Godot - Valide 02/05

Les tests à mettre en place sont les suivants:

• Compilation réussie avec intégration du module C++ - Fait
• Communication simulation_automate -> simulation_godot - Fait
• Communication simulation_godot -> simulation_automate - Fait
• Fonctionnement correct de l'automate virtuel sur une simulation d’ascenseur. - Fait

12/04

Intégration dans Godot

Étant sous windows, nous essayons de compiler Godot avec les sources et en utilisant Scons (alternative de cmake mais adapté pour différentes plateformes). La compilation est fonctionnelle après avoir modifié l'installation de visual studio mais lors de l’exécution, nous avons plusieurs erreurs visuelles et plusieurs erreurs dans le terminal. Nous essayons de modifier certains paramètres de la compilation mais cela étant long et sans succès, nous décidons de passer sous Linux.

Ayant les mêmes problèmes sous Linux, nous avons étudié le package Godot 3.2.1 de l'AUR pour extraire la bonne commande du script PKGBUILD. La commande spécifie plusieurs paramètres comme l'OS utilisé, le compilateur utilisé, le son utilisé, le nombre de cœurs utilisés.

21/04

Nous étudions plusieurs modes de communication pour relier la simulation à l’automate. Les méthodes étudiés sont dans l'ordre :

- Ecriture/Lecture dans un fichier texte - Partage de fichier JSON - Pipes nommées - Files de messages - Sockets - ZeroMQ :zeromq.org - Modbus

Finalement nous choississons d'utiliser le protocol MOdbus car il est directement intégré aux automates des salles de TP d’automatique. Ce protocole répond à notre besoin de transmissions de mots binaires.

Nous utilisons les implémentations open-source modbuspp et pyModbusTCP en C++ et Python respectivement.

27/04

Nous avons dans un premier temps cherché une solution utilisant le code grafcet effectué durant nos TP du semestre 7. Mais nous avons effectué des recherches qui nous ont permit de découvrir SimPyLC (https://pypi.org/project/SimPyLC/).

SimPyLC permet de simuler un automate sans boucle, pas de pause, pas de break. Nous avons donc étudié les systèmes déjà simulés comme une led ou un bras de robot.

Après concertation, nous avons trouvé que SimPyLC répondait à nos attentes et avons décidé d'adapter les scripts à l'ascenseur.

Nous avons donc adapté les scripts timing.py et world.py pour créer l'ascenseur dans le simulateur SimPyLC.

L'ascenseur est composée de 2 Class Registers, 10 Class Markers, 5 Class Latch.

Class Register : Permet de stocker un entier. Class Marker : Permet d’ ́evaluer une expression bool ́eenne et de chan-ger la valeur bool ́eenne du marker en fonction de l’expression Class Latch : Bascule permettant de sauvegarder un ́etat entre deuxsweeps. Nous en utilisons pour le d ́eplacement de l’ascenseur

Notre boucle principale est composée de 3 fonctions: La première pour lire la valeur d'un capteur, ensuite on exécute les actionneurs puis on envoie les résultats.

On obtient alors 2 fenêtres représentant l'ascenseur.

C'est fenêtre affiche les états des capteurs (tout ou rien) et des actionneurs.

On voit dans cette fenêtre les changements d'état dans le temps.

02/05

Une fois le simulateur fonctionnel, nous l'avons intégrer dans GoDot. Nous avons donc créer plusieurs fonctions pour traiter les données envoyées et reçues.

Nous avons donc créé un dictionnaire pour récupérer et modifier les états des capteurs/actionneurs.

La première fonction dic_to_int(dic) permet de mettre l'état du capteur sous forme de registre.

La seconde fonction traite les données reçu d'un registre.

Enfin, nous avons la fonction _process(delta) qui mets à jour les valeurs dans la simulation GoDot.

Documents Rendus

Diapo soutenance : Fichier:Soutenance finale projet IMA.pdf

Rapport : Fichier:CR Projet IMA END.pdf

GitHub : https://github.com/Tywacol/SimulPhys