Wiki de Projets IMA - Contributions de l’utilisateur [fr]

API

2014-01-14T10:17:43Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Pc rack

2014-01-14T10:17:28Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Fichier:Choix api.PNG

2014-01-14T10:16:46Z

Sxing :

Choix de l’API/Ordinateur

2014-01-14T10:16:19Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T10:16:02Z

Sxing : /* Instrumentation */

= Introduction =

[[Fichier:Machine_cuisson_extrusion.png]]

== Contexte ==

L’extrusion est une opération unitaire qui consiste à forcer un produit à travers un orifice de petite dimension, appelé filière. La pression mise en œuvre lors de cette opération est générée par une vis ou par deux vis dans le cas de l’extrudeur bivis. Cette transformation, jointe à l’éventuel travail de la matière en amont de la filière (hydratation et/ou précuisson dans le préconditionneur, cisaillement et mélange dans l’extrudeur), permet d’élaborer des produits ayant des structures physiques, des compositions et des propriétés fonctionnelles différentes. Dans le domaine de l’extrusion, et selon les étapes en amont ou en aval de l’opération, plusieurs techniques peuvent être utilisées, à savoir l’extrusion simple – éventuellement avec un post-traitement de formage (injection, soufflage, ..), l’extrusion-réaction, la cuisson-extrusion et la cuisson-extrusion-expansion. Dans l’industrie agroalimentaire, la cuisson-extrusion est la technique la plus utilisée. En effet, elle donne lieu à une multitude d’applications dans des domaines très variés.
Ce procédé est un procédé continu.

Notre projet est en collaboration directe avec l'entreprise SETREM qui propose des machines de cuisson-extrusion. Ces dernières n'étant pas automatisées et dans le but de se mettre à la hauteur sur le marché, la société nous a confié comme projet de réaliser une étude cherchant à proposer des solutions robustes dans le but de superviser le système. A terme, ce projet débouchera sur une proposition de supervision (contrôle-commande) de ce système.

== Objectifs ==

Après une visite de l'entreprise le 26 septembre 2013 à l'entreprise SETREM, basée à Acquigny, nous avons pu, avec l'industriel, discuter des principaux objectifs du projet, comme suit:

Le premier objectif de ce projet est de proposer des solutions pour la réalisation d'un système de supervision d'une machine de cuisson-extrusion (machine servant à fabriquer des produits alimentaires de types snacks apéritif, céréales expansées de petit déjeuner ou spaghetti).

Le deuxième objectif sera de concevoir une interface graphique afin de contrôler/commander la machine. Plus précisément, les phases de mise en marche du système et l'arrêt du système.

== Contraintes ==

Les contraintes du projet seront:

Pour les solutions à proposer, les contraintes seront de rassembler toutes les données nécessaires demandées par l'industrie à savoir: débit de matière, température, contrôle de la vitesse des moteurs, contrôle de l’énergie fournie pour le système mais aussi essayer de connaître le pourcentage de vapeur et d’eau contenu dans le produit afin de connaître le taux d’humidité présente dans la machine. Ces données devront pouvoir être accessibles via une interface graphique ergonomique (tableaux de bord avec historiques) mais aussi permettre l’archivage numérique de ces données pour restitution ultérieure (reproduction des conditions de réglage optimales, aide au diagnostic, traçabilité).

Ensuite, nous devrons choisir le matériel nécessaire à savoir: chercher du matériel robuste car l'environnement est très chaud et humide.

Enfin, le choix de l’ordinateur et de l’automate: il devra être robuste également. Comme solution, nous pensons mettre un ordinateur dans la salle de la machine (il faudra alors installer une cabine ou un système déporté). L’objectif sera de pouvoir contrôler et commander le système autrement qu'en appuyant sur des boutons et pouvoir contrôler le système et envoyer des ordres de n'importe quel endroit.

Dans tous les cas, le système mis en place devra se superposer au système de pilotage manuel actuellement installé et permettre à tout moment un basculement vers celui-ci. Il devra également respecter les protocoles de mise en sécurité de la machine lors des fonctionnements critiques.

== Schéma de principe ==

Ci dessous, le schéma de principe du système qui devra être mis en place:

[[Fichier:Schéma_machine.png]]

= Avancement du projet =

== Instrumentation ==

Nous avons décidé dans un premier temps de nous occuper de la partie instrumentation, à savoir regrouper les informations que SETREM veut récupérer à partir de la machine et de chercher dans un premier temps les capteurs disponible sur le marché. Aussi, certaines données comme l'énergie produite par la machine ainsi que le taux d'humidité présente ne peuvent être directement récoltés à partir de capteurs, nous allons donc chercher à connaitre quels moyens nous pourrons utiliser pour calculer ces données.

Nous avons résumé tout cela sur le schéma suivant:

[[Fichier:schéma_capteur.png]]

Le tableau suivant donne les fonctions de chaque élément du schéma:

[[Fichier:Tableau.jpg]]

'''Capteur de température''': permet de boucler le système de chauffage et d’assurer un bon fonctionnement de processus

'''Capteur de pression''': permet de savoir, à l’endroit où se trouve le capteur, s’il y a une présence de produit, qui sert au démarrage et/ou à l’arrêt. Plusieurs capteurs de pression seront implantés sur la partie “module extrusion”

'''Capteur de pesage''': permet d’assurer la continuité de la production et quantifier la production (débit matière première)

'''Capteur de débit''': va permettre d’obtenir les informations nécessaires afin de connaître le taux d’humidité dans le système

'''Capteur de couple''' (couplemètre) couplé à un capteur de vitesse angulaire: permet de connaître la vitesse du moteur mais aussi le couple, ce qui permettra de connaître la puissance délivré par chaque moteur et donc d’en déduire l’énergie.

[[Capteur température]]

[[Fichier:cap_temperature.PNG]]

[[Choix]]

Nous pensons que les RTD sont les plus judicieux pour cette application, ils sont en effet précis et robuste. Cependant, le temps de réponse étant élevé, on peut se demander s’ils sont vraiment adaptés pour ce type d’application. Cela peut poser des problèmes de régulation. Dans un objectif de contrôle-commande de ce système, il peut donc s’avérer ne pas être très intéressant d’utiliser ces capteurs. Cependant, pour calculer la température directe du produit, ce sont les plus utilisés dans ce domaine, c’est pourquoi nous les utiliseront uniquement pour la température du produit.

Exemple: - PT100 chez Dynisco

Setrem utilise des capteurs de type thermocouple, assez précis (environ 1 degrés près), et avec un temps de réponse très faible, ce qui est intéressant. Aussi, ils sont bons marchés, cependant, ils peuvent s’avérer être fragiles s’ils sont soumis à des conditions et un environnement rude ainsi qu’aux manipulations occasionnées lors du montage/démontage. Nous les utiliserons pour relever la température du fourreau.

Enfin, à la sortie de la filière, il pourra être intéressant d’insérer des capteurs infrarouges, sans contact.

Exemple: Thermo METER micro-epsilon

[[Capteur pression]]

Les pressostats

Dispositif détectant le dépassement d'une valeur prédéterminée, de la pression d'un fluide système de contrôle ou régulation (démarrage d'un compresseur d'air ou d'une pompe si la pression du circuit contrôlé descend en dessous d'une limite déterminée) Enclenchement d’une alarme lorsque la pression dépasse un seuil.

Les capteurs à membrane

Le corps d’épreuve d’un capteur de pression est l’élément assurant la transformation de la pression en déplacement, déformation ou force(membrane)

Capteurs potentiométriques

Le curseur d’un potentiomètre est lié à une membrane. La déformation de la membrane entraîne un déplacement

Capteurs à jauge extensométrique

Les jauges sont des éléments résistifs collés sur le corps d’épreuve assurant la conversion directe d’une déformation de la structure, en variation de résistance électrique

[[Choix]]: - Dynisco MRT460
PT46X4

Ce qui nous intéresse ici est de connaître la présence ou non de produit dans la filière. Nous proposons donc d’insérer plusieurs de ce capteurs le long de la vis, de préférence des capteurs de type TOR (interrupteur par exemple).

Aussi, ils peut être intéressant de connaître la pression en sortie de filière qui nous permettra de réguler le processus. Par exemple, s’il y a trop de pression dans le fourreau, le produit ne donnera pas le forme voulu. On proposera donc de diminuer la vitesse de rotation du moteur afin de faire diminuer cette pression. Pour cela, des capteurs à membrane seront intéressants.

[[Capteur de pesage]]

Il existe différents types de capteur pour le pesage, cependant les trois types pouvant nous intéresser sont:

Modules de pesage: ils offrent des solutions intéressantes pour le pesage et la mesure de niveau dans des applications de procès industriels et de dosage dans l'industrie chimique, pharmaceutique, alimentaire et matériaux de construction.

Capteurs à point d'appui central: Les capteurs à point d'appui central ont été conçus avec des propriétés mécaniques et de mesure excellentes pour être employés dans de très nombreuses applications de pesage. Ces capteurs à point d'appui central sont simples et apportent rapidité et sûreté.

Capteurs de pesage numériques: Les capteurs de pesage pesons numériques, construits sur la base de la technologie des jauges de contrainte, fournissent une nouvelle impulsion dans les secteurs du pesage dynamique, du calibrage, du remplissage et du dosage. Le capteur numérique FIT: Fiabilité, Durabilité, Haute Précision.

[[Choix]]:

Notre choix se porterait sur les “modules de pesage”, utilisés pour le dosage dans l’industrie et notamment dans l’industrie agro-alimentaire.
Exemple: - Z6/AM de 50 kg à 500 kg
- MultiMount SWB505 de 5Kg à 4.4 t

[[Capteur de débit (volumique)]]

Débitmètre mécanique à hélice (ou turbine)

Un dispositif à ailettes ou hélicoïdal est placé dans l'axe de la conduite d'écoulement, ce qui entraine une rotation du rotor avec une vitesse liée à la vitesse du fluide. Il suffit alors de compter le nombre de tours/mn pour avoir la vitesse et par la suite le débit du fluide par exemple avec des dispositif magnétiques qui détectent le passage de la pale de l'hélice.
Pour mesurer la vitesse d'un liquide on choisira plutôt une turbine. Ce système ne fonctionne bien qu'avec des fluides propres et peu visqueux. La précision peut être de l'ordre de 0.2%, en général le comptage limite l'utilisation de ce type de dispositif en raison de sa durée, le dispositif ne peut pas être utilisé de manière fiable pour des variations importantes de la vitesse du fluide.

Débitmètre électromagnétique

Pour un fluide s'écoulant dans une canalisation aux parois amagnétiques, 2 bobines sont placées de part et d'autre de la conduite, on place aussi deux électrodes de prise de signal dans une direction perpendiculaire au champ magnétique. La f.e.m recueillie entre les deux électrodes est directement proportionnelle à la vitesse.
L'avantage de cette méthode est que le capteur ne perturbe pas l'écoulement ce qui revient à dire que la viscosité du fluide n'intervient absolument pas dans le résultat, de même que la densité du fluide qui n'intervient pas non plus, il en va aussi de même pour la température qui peut être relativement élevée (quelques centaines de °C). Cette méthode possède aussi un faible écart de linéarité.
L'inconvénient de cette méthode est qu'elle ne fonctionne que pour des fluides conducteurs.

Débitmètre à effet Dopler

On utilise des impulsions ultrasonores de fréquence F, qui, diffusées par des particules entraînées par un fluide de vitesse subissent une variation de fréquence proportionnelle à la vitesse des particules et donc du fluide. La mesure de cette fréquence permet de connaître la vitesse d'écoulement et donc le débit.
L'effet Dopler exige des fluides chargés en particules. L'étendue de mesure est comprise entre 0 et 15 m/s, avec une précision de l'ordre de 2%.
Les avantages sont principalement qu'il n'y a pas de perte de charge, et que la méthode est insensible à la nature chimique du fluide.
L'inconvénient est que la mesure dépend de la température.

[[Choix]]

Ici, le capteur de débit nous permettra de connaître le débit volumique (volume de vapeur + volume de l’eau). Si nous avons le volume d’eau, nous pouvons ainsi calculer la quantité qui est présente dans le produit. Cette valeur nous permettra de réguler le système. En effet, nous ne pouvons pas dépasser une certaine quantité d’eau dans le produit afin d’éviter qu’il devienne liquide.

Un débitmètre électromagnétique nous permet d’avoir une bonne précision et une grande tolérance par rapport à la température.

Exemple:
- ADMAG AXF chez Yokogawa (débit d’eau)
- DO61W chez Deltatop (débit de vapeur)

[[Couplemètre]]

Le couplemètre va nous permettre d’obtenir des informations quant à l’énergie fournie par le système. En effet, il suffira de faire un essai à vide puis un autre en charge afin de connaître l’énergie et la puissance à fournir pour faire marcher le système. Cette variable étant demandée par SETREM qui voulait recevoir des informations sur cette grandeur.

Couplemètres à contact

Ces capteurs possèdent un système de transmission par contact électrique (balais) limitant leur vitesse de rotation maximale à 2 000 tr/mn. Ils délivrent un signal bas niveau (mV).

Couplemètres sans contact

Les couplemètres sans contact peuvent atteindre des vitesses de 30 000 tr/mn et réduisent la maintenance (absence de balais).
Ils délivrent un signal haut niveau de ±10 V.

[[Choix]]: Notre choix se porterait sur des couplemètres sans contact, qui sont beaucoup plus fiable et précis. Ces couplemètres peuvent fonctionner à des vitesses assez élevées.

Exemple: - DR2315 chez Scaime
remarque: axe claveté diamètre 19 mm
couple nominal: 100Nm
vitesse de rotation <8000 tr/min

- T22 chez HBM
remarque: axe claveté diamètre 19 mm
couple nominal: jusqu’à 1kNm
vitesse de rotation de 9000 tr/min à 16 000tr/min

Capteur de vitesse angulaire

Tacchymètre industriel: on connaîtra la vitesse en tr/min, il suffira de multiplier par 2*ℿ/60
pour connaître la vitesse angulaire en rad/s.

Exemple: - Tachymètre type FUA9192

[[Énergie électrique moteurs]]

Ainsi, en connaissant le couple, nous serons capable de connaître la puissance fournie pour les moteurs pour faire tourner les modules (un essai à vide puis en charge):
P=C*Ω 𝛀
( Ω étant la vitesse de rotation angulaire).
Il suffira ensuite d’intégrer cette puissance dans le temps pour avoir une valeur de l’énergie en fonction du temps.

[[Énergie au niveau de la chaudière]]

Le tableau ce dessous nous permet de calculer l’énergie produite par le chauffage dans les modules “pré-conditionnement” et “extrusion”. Cette énergie correspond à l'énergie dissipée pour les changements d’état de l’eau (gazeux à liquide) et les variations de température. La somme de ces deux valeurs nous permet de connaître l’énergie totale.

[[Fichier:energie_dissipee.PNG]]

Calcul du taux d’humidité

Le taux d’humidité est une valeur difficile à obtenir. Si on connaît le volume de vapeur injecté ainsi que la température de l’eau, on est capable de calculer cette quantité de vapeur apportée (M=*V, est la masse volumique de la vapeur, une constante), la quantité d’eau et d'énergie sous forme de chaleur (Meau=M* K, K est le pourcentage d’eau dans la vapeur, et E=Meau*Kcal/kg). On a vu que la vapeur a aussi une influence sur le pourcentage d’eau dans le produit final. La régulation de la pré-cuisson, la régulation de l’humidité et celle de l’énergie sont couplées. Un régulateur complexe sera mis en place.

[[Fichier:liste_cap.PNG]]

Plusieurs capteurs servant à mesurer une même valeur seront implanter du fait que nous avons besoin de contrôler la grandeur voulue à plusieurs endroits (redondance capteur).

Remarque: On propose d’injecter la vapeur à plusieurs endroits pour assurer une bonne précuission.

Au total, on a 25 paramètres à retenir, on suppose que toutes les valeurs sont prises en compte par l’API. On a donc 25 entrées.

[['''DATA Acquisition:''']]

NI PCI-6514 (32 entrées, 32 sorties à courant injecté)
Un DAQ nous permet de convertir les signaux analogiques en numérique et de faire l'étalonnage.

[[Choix de l’API/Ordinateur]]

Afin de pouvoir contrôler le système et recevoir les informations, il nous faut chercher des appareils robustes pouvant tenir compte des contraintes de notre système.
L’API se chargera de traiter les informations issues des capteurs et l’ordinateur se chargera de recevoir ces informations.

Pour cela, il nous faut savoir combien d’entrées/sorties nous avons besoin. Aussi, chaque automate est compatible avec un certains langage de programmation (Grafcet, Ladder par exemple).

En terme de sécurité alimentaire, la traçabilité est un élément important chez les fabriquants. On doit choisir un dispositif qui contient une mémoire suffisamment grande pour stocker non seulement les données acquises dans le processus mais aussi les configurations du système. Ces configurations nous permettent de contrôler et d’optimiser le processus, surtout au démarrage et à l’arrêt.

[[Fichier:choix_api.PNG]]

[[API]]

Un contrôle à distance

L’API est largement utilisé dans l’industrie, grâce à sa fiabilité et ses performances. Avec l’évolution de la technologie, l’API est équipé de modules de communication. Pour superviser l’installation, l’API va transférer les données via le réseau local (ex: Ethernet). Dans une autre salle, on peux utiliser un PC industriel avec des logiciels professionnels. Un autre avantage est que l’on peut exploiter les informations de manière hiérarchique.

[[Choix]]: M3 XD26 S 24VDC (Crouzet)

[[Pc rack]]

Il nous permet de travailler en local. Il est mieux adapté à l’environnement industriel.

Choix: Tout dépend de l’utilisation, si nous sommes dans un petit atelier avec un processus relativement simple, on va choisir le PC rack qui nous permet de gagner de l’espace et d’avoir une visualisation local.

Si on a un système hiérarchisé (3 niveaux différents par exemple), on va choisir un API . Cette méthode nous permet de réaliser un processus complexe et à distance.

[[Choix]]: Rack PC SIMATIC IPC547E

Fichier:Liste cap.PNG

2014-01-14T10:11:07Z

Sxing :

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T10:10:50Z

Sxing : /* Instrumentation */

Couplemètre

2014-01-14T10:03:19Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T10:01:29Z

Sxing : /* Instrumentation */

Énergie au niveau de la chaudière

2014-01-14T09:59:33Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Énergie électrique moteurs

2014-01-14T09:59:15Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Capteur de pesage

2014-01-14T09:58:48Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Capteur pression

2014-01-14T09:58:04Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Capteur température

2014-01-14T09:56:52Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Capteur de débit (volumique)

2014-01-14T09:55:39Z

Sxing : Page créée avec « '''Texte gras''' »

'''Texte gras'''

Fichier:Energie dissipee.PNG

2014-01-14T09:54:29Z

Sxing :

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T09:53:57Z

Sxing : /* Instrumentation */

= Introduction =

[[Fichier:Machine_cuisson_extrusion.png]]

== Contexte ==

L’extrusion est une opération unitaire qui consiste à forcer un produit à travers un orifice de petite dimension, appelé filière. La pression mise en œuvre lors de cette opération est générée par une vis ou par deux vis dans le cas de l’extrudeur bivis. Cette transformation, jointe à l’éventuel travail de la matière en amont de la filière (hydratation et/ou précuisson dans le préconditionneur, cisaillement et mélange dans l’extrudeur), permet d’élaborer des produits ayant des structures physiques, des compositions et des propriétés fonctionnelles différentes. Dans le domaine de l’extrusion, et selon les étapes en amont ou en aval de l’opération, plusieurs techniques peuvent être utilisées, à savoir l’extrusion simple – éventuellement avec un post-traitement de formage (injection, soufflage, ..), l’extrusion-réaction, la cuisson-extrusion et la cuisson-extrusion-expansion. Dans l’industrie agroalimentaire, la cuisson-extrusion est la technique la plus utilisée. En effet, elle donne lieu à une multitude d’applications dans des domaines très variés.
Ce procédé est un procédé continu.

Notre projet est en collaboration directe avec l'entreprise SETREM qui propose des machines de cuisson-extrusion. Ces dernières n'étant pas automatisées et dans le but de se mettre à la hauteur sur le marché, la société nous a confié comme projet de réaliser une étude cherchant à proposer des solutions robustes dans le but de superviser le système. A terme, ce projet débouchera sur une proposition de supervision (contrôle-commande) de ce système.

== Objectifs ==

Après une visite de l'entreprise le 26 septembre 2013 à l'entreprise SETREM, basée à Acquigny, nous avons pu, avec l'industriel, discuter des principaux objectifs du projet, comme suit:

Le premier objectif de ce projet est de proposer des solutions pour la réalisation d'un système de supervision d'une machine de cuisson-extrusion (machine servant à fabriquer des produits alimentaires de types snacks apéritif, céréales expansées de petit déjeuner ou spaghetti).

Le deuxième objectif sera de concevoir une interface graphique afin de contrôler/commander la machine. Plus précisément, les phases de mise en marche du système et l'arrêt du système.

== Contraintes ==

Les contraintes du projet seront:

Pour les solutions à proposer, les contraintes seront de rassembler toutes les données nécessaires demandées par l'industrie à savoir: débit de matière, température, contrôle de la vitesse des moteurs, contrôle de l’énergie fournie pour le système mais aussi essayer de connaître le pourcentage de vapeur et d’eau contenu dans le produit afin de connaître le taux d’humidité présente dans la machine. Ces données devront pouvoir être accessibles via une interface graphique ergonomique (tableaux de bord avec historiques) mais aussi permettre l’archivage numérique de ces données pour restitution ultérieure (reproduction des conditions de réglage optimales, aide au diagnostic, traçabilité).

Ensuite, nous devrons choisir le matériel nécessaire à savoir: chercher du matériel robuste car l'environnement est très chaud et humide.

Enfin, le choix de l’ordinateur et de l’automate: il devra être robuste également. Comme solution, nous pensons mettre un ordinateur dans la salle de la machine (il faudra alors installer une cabine ou un système déporté). L’objectif sera de pouvoir contrôler et commander le système autrement qu'en appuyant sur des boutons et pouvoir contrôler le système et envoyer des ordres de n'importe quel endroit.

Dans tous les cas, le système mis en place devra se superposer au système de pilotage manuel actuellement installé et permettre à tout moment un basculement vers celui-ci. Il devra également respecter les protocoles de mise en sécurité de la machine lors des fonctionnements critiques.

== Schéma de principe ==

Ci dessous, le schéma de principe du système qui devra être mis en place:

[[Fichier:Schéma_machine.png]]

= Avancement du projet =

== Instrumentation ==

Nous avons décidé dans un premier temps de nous occuper de la partie instrumentation, à savoir regrouper les informations que SETREM veut récupérer à partir de la machine et de chercher dans un premier temps les capteurs disponible sur le marché. Aussi, certaines données comme l'énergie produite par la machine ainsi que le taux d'humidité présente ne peuvent être directement récoltés à partir de capteurs, nous allons donc chercher à connaitre quels moyens nous pourrons utiliser pour calculer ces données.

Nous avons résumé tout cela sur le schéma suivant:

[[Fichier:schéma_capteur.png]]

Le tableau suivant donne les fonctions de chaque élément du schéma:

[[Fichier:Tableau.jpg]]

'''Capteur de température''': permet de boucler le système de chauffage et d’assurer un bon fonctionnement de processus

'''Capteur de pression''': permet de savoir, à l’endroit où se trouve le capteur, s’il y a une présence de produit, qui sert au démarrage et/ou à l’arrêt. Plusieurs capteurs de pression seront implantés sur la partie “module extrusion”

'''Capteur de pesage''': permet d’assurer la continuité de la production et quantifier la production (débit matière première)

'''Capteur de débit''': va permettre d’obtenir les informations nécessaires afin de connaître le taux d’humidité dans le système

'''Capteur de couple''' (couplemètre) couplé à un capteur de vitesse angulaire: permet de connaître la vitesse du moteur mais aussi le couple, ce qui permettra de connaître la puissance délivré par chaque moteur et donc d’en déduire l’énergie.

[[Capteur température]]

[[Fichier:cap_temperature.PNG]]

[[Choix]]

Nous pensons que les RTD sont les plus judicieux pour cette application, ils sont en effet précis et robuste. Cependant, le temps de réponse étant élevé, on peut se demander s’ils sont vraiment adaptés pour ce type d’application. Cela peut poser des problèmes de régulation. Dans un objectif de contrôle-commande de ce système, il peut donc s’avérer ne pas être très intéressant d’utiliser ces capteurs. Cependant, pour calculer la température directe du produit, ce sont les plus utilisés dans ce domaine, c’est pourquoi nous les utiliseront uniquement pour la température du produit.

Exemple: - PT100 chez Dynisco

Setrem utilise des capteurs de type thermocouple, assez précis (environ 1 degrés près), et avec un temps de réponse très faible, ce qui est intéressant. Aussi, ils sont bons marchés, cependant, ils peuvent s’avérer être fragiles s’ils sont soumis à des conditions et un environnement rude ainsi qu’aux manipulations occasionnées lors du montage/démontage. Nous les utiliserons pour relever la température du fourreau.

Enfin, à la sortie de la filière, il pourra être intéressant d’insérer des capteurs infrarouges, sans contact.

Exemple: Thermo METER micro-epsilon

[[Capteur pression]]

Les pressostats

Dispositif détectant le dépassement d'une valeur prédéterminée, de la pression d'un fluide système de contrôle ou régulation (démarrage d'un compresseur d'air ou d'une pompe si la pression du circuit contrôlé descend en dessous d'une limite déterminée) Enclenchement d’une alarme lorsque la pression dépasse un seuil.

Les capteurs à membrane

Le corps d’épreuve d’un capteur de pression est l’élément assurant la transformation de la pression en déplacement, déformation ou force(membrane)

Capteurs potentiométriques

Le curseur d’un potentiomètre est lié à une membrane. La déformation de la membrane entraîne un déplacement

Capteurs à jauge extensométrique

Les jauges sont des éléments résistifs collés sur le corps d’épreuve assurant la conversion directe d’une déformation de la structure, en variation de résistance électrique

Choix: - Dynisco MRT460
PT46X4

Ce qui nous intéresse ici est de connaître la présence ou non de produit dans la filière. Nous proposons donc d’insérer plusieurs de ce capteurs le long de la vis, de préférence des capteurs de type TOR (interrupteur par exemple).

Aussi, ils peut être intéressant de connaître la pression en sortie de filière qui nous permettra de réguler le processus. Par exemple, s’il y a trop de pression dans le fourreau, le produit ne donnera pas le forme voulu. On proposera donc de diminuer la vitesse de rotation du moteur afin de faire diminuer cette pression. Pour cela, des capteurs à membrane seront intéressants.

[[Capteur de pesage]]

Il existe différents types de capteur pour le pesage, cependant les trois types pouvant nous intéresser sont:

Modules de pesage: ils offrent des solutions intéressantes pour le pesage et la mesure de niveau dans des applications de procès industriels et de dosage dans l'industrie chimique, pharmaceutique, alimentaire et matériaux de construction.

Capteurs à point d'appui central: Les capteurs à point d'appui central ont été conçus avec des propriétés mécaniques et de mesure excellentes pour être employés dans de très nombreuses applications de pesage. Ces capteurs à point d'appui central sont simples et apportent rapidité et sûreté.

Capteurs de pesage numériques: Les capteurs de pesage pesons numériques, construits sur la base de la technologie des jauges de contrainte, fournissent une nouvelle impulsion dans les secteurs du pesage dynamique, du calibrage, du remplissage et du dosage. Le capteur numérique FIT: Fiabilité, Durabilité, Haute Précision.

Choix:

Notre choix se porterait sur les “modules de pesage”, utilisés pour le dosage dans l’industrie et notamment dans l’industrie agro-alimentaire.
Exemple: - Z6/AM de 50 kg à 500 kg
- MultiMount SWB505 de 5Kg à 4.4 t

[[Capteur de débit (volumique)]]

Débitmètre mécanique à hélice (ou turbine)
Un dispositif à ailettes ou hélicoïdal est placé dans l'axe de la conduite d'écoulement, ce qui entraine une rotation du rotor avec une vitesse liée à la vitesse du fluide. Il suffit alors de compter le nombre de tours/mn pour avoir la vitesse et par la suite le débit du fluide par exemple avec des dispositif magnétiques qui détectent le passage de la pale de l'hélice.
Pour mesurer la vitesse d'un liquide on choisira plutôt une turbine. Ce système ne fonctionne bien qu'avec des fluides propres et peu visqueux. La précision peut être de l'ordre de 0.2%, en général le comptage limite l'utilisation de ce type de dispositif en raison de sa durée, le dispositif ne peut pas être utilisé de manière fiable pour des variations importantes de la vitesse du fluide.

Débitmètre électromagnétique
Pour un fluide s'écoulant dans une canalisation aux parois amagnétiques, 2 bobines sont placées de part et d'autre de la conduite, on place aussi deux électrodes de prise de signal dans une direction perpendiculaire au champ magnétique. La f.e.m recueillie entre les deux électrodes est directement proportionnelle à la vitesse.
L'avantage de cette méthode est que le capteur ne perturbe pas l'écoulement ce qui revient à dire que la viscosité du fluide n'intervient absolument pas dans le résultat, de même que la densité du fluide qui n'intervient pas non plus, il en va aussi de même pour la température qui peut être relativement élevée (quelques centaines de °C). Cette méthode possède aussi un faible écart de linéarité.
L'inconvénient de cette méthode est qu'elle ne fonctionne que pour des fluides conducteurs.

Débitmètre à effet Dopler
On utilise des impulsions ultrasonores de fréquence F, qui, diffusées par des particules entraînées par un fluide de vitesse subissent une variation de fréquence proportionnelle à la vitesse des particules et donc du fluide. La mesure de cette fréquence permet de connaître la vitesse d'écoulement et donc le débit.
L'effet Dopler exige des fluides chargés en particules. L'étendue de mesure est comprise entre 0 et 15 m/s, avec une précision de l'ordre de 2%.
Les avantages sont principalement qu'il n'y a pas de perte de charge, et que la méthode est insensible à la nature chimique du fluide.
L'inconvénient est que la mesure dépend de la température.
Choix

Ici, le capteur de débit nous permettra de connaître le débit volumique (volume de vapeur + volume de l’eau). Si nous avons le volume d’eau, nous pouvons ainsi calculer la quantité qui est présente dans le produit. Cette valeur nous permettra de réguler le système. En effet, nous ne pouvons pas dépasser une certaine quantité d’eau dans le produit afin d’éviter qu’il devienne liquide.

Un débitmètre électromagnétique nous permet d’avoir une bonne précision et une grande tolérance par rapport à la température.

Exemple:
- ADMAG AXF chez Yokogawa (débit d’eau)
- DO61W chez Deltatop (débit de vapeur)

[[Couplemètre]]

Le couplemètre va nous permettre d’obtenir des informations quant à l’énergie fournie par le système. En effet, il suffira de faire un essai à vide puis un autre en charge afin de connaître l’énergie et la puissance à fournir pour faire marcher le système. Cette variable étant demandée par SETREM qui voulait recevoir des informations sur cette grandeur.

Couplemètres à contact

Ces capteurs possèdent un système de transmission par contact électrique (balais) limitant leur vitesse de rotation maximale à 2 000 tr/mn. Ils délivrent un signal bas niveau (mV).

Couplemètres sans contact

Les couplemètres sans contact peuvent atteindre des vitesses de 30 000 tr/mn et réduisent la maintenance (absence de balais).
Ils délivrent un signal haut niveau de ±10 V.

Choix: Notre choix se porterait sur des couplemètres sans contact, qui sont beaucoup plus fiable et précis. Ces couplemètres peuvent fonctionner à des vitesses assez élevées.

Exemple: - DR2315 chez Scaime
remarque: axe claveté diamètre 19 mm
couple nominal: 100Nm
vitesse de rotation <8000 tr/min

- T22 chez HBM
remarque: axe claveté diamètre 19 mm
couple nominal: jusqu’à 1kNm
vitesse de rotation de 9000 tr/min à 16 000tr/min

Capteur de vitesse angulaire

Tacchymètre industriel: on connaîtra la vitesse en tr/min, il suffira de multiplier par 2*ℿ/60
pour connaître la vitesse angulaire en rad/s.

Exemple: - Tachymètre type FUA9192

[[Énergie électrique moteurs]]

Ainsi, en connaissant le couple, nous serons capable de connaître la puissance fournie pour les moteurs pour faire tourner les modules (un essai à vide puis en charge):
P=C*Ω 𝛀
( Ω étant la vitesse de rotation angulaire).
Il suffira ensuite d’intégrer cette puissance dans le temps pour avoir une valeur de l’énergie en fonction du temps.

[[Énergie au niveau de la chaudière]]

Le tableau ce dessous nous permet de calculer l’énergie produite par le chauffage dans les modules “pré-conditionnement” et “extrusion”. Cette énergie correspond à l'énergie dissipée pour les changements d’état de l’eau (gazeux à liquide) et les variations de température. La somme de ces deux valeurs nous permet de connaître l’énergie totale.

[[Fichier:energie_dissipee.PNG]]

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T09:41:30Z

Sxing : /* Instrumentation */

Fichier:Cap temperature.PNG

2014-01-14T09:39:53Z

Sxing :

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T09:38:49Z

Sxing : /* Instrumentation */

Développement d'une interface informatique ergonomique de contrôle commande

2014-01-14T09:36:22Z

Sxing : /* Instrumentation */

Fichier:Erreur mapping.jpg

2013-05-15T11:41:46Z

Sxing : a téléversé une nouvelle version de « Fichier:Erreur mapping.jpg »

Fichier:Erreur mapping.jpg

2013-05-15T11:40:22Z

Sxing : a téléversé une nouvelle version de « Fichier:Erreur mapping.jpg »

Fichier:Erreur mapping.jpg

2013-05-15T11:35:06Z

Sxing :

Interface supervision

2013-05-15T11:34:40Z

Sxing : /* Présentation du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:input_output_noerreur.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

[[Fichier:model_labview_simulink.jpg]]

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

[[Fichier:erreur_mapping.jpg]]

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

[[Fichier:rapport_final_XING_MABROUL.pdf]]

Fichier:Model labview simulink.jpg

2013-05-15T11:30:14Z

Sxing :

Interface supervision

2013-05-15T11:29:51Z

Sxing : /* Présentation du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:input_output_noerreur.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

[[Fichier:model_labview_simulink.jpg]]

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

[[Fichier:rapport_final_XING_MABROUL.pdf]]

Fichier:Input output noerreur.jpg

2013-05-15T11:21:47Z

Sxing :

Interface supervision

2013-05-15T11:21:10Z

Sxing : /* Avancement du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:input_output_noerreur.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

*image*

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

[[Fichier:rapport_final_XING_MABROUL.pdf]]

Fichier:Rapport final XING MABROUL.pdf

2013-05-15T11:16:05Z

Sxing : a téléversé une nouvelle version de « Fichier:Rapport final XING MABROUL.pdf »

Fichier:Rapport final XING MABROUL.pdf

2013-05-07T16:51:40Z

Sxing :

Interface supervision

2013-05-07T16:51:15Z

Sxing :

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:test.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

*image*

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

[[Fichier:rapport_final_XING_MABROUL.pdf]]

Interface supervision

2013-05-07T16:49:42Z

Sxing : /* Présentation du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:test.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

*image*

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

[[Fichier:rapport_final.pdf]]

Interface supervision

2013-05-07T14:35:22Z

Sxing : /* Avancement du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:test.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

*image*

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

Interface supervision

2013-05-07T14:23:58Z

Sxing : /* Présentation du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité; Le tunnel ActiveX fonctionne avec un tableur statique, c'est à dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté; Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:test.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux; Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre; Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

*image*

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a creer une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectuer une identification en envoyant un echelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

Interface supervision

2013-05-07T14:15:02Z

Sxing : /* Présentation du projet */

== '''Présentation du projet''' ==

----

'''Encadrant'''

Belkacem OULD BOUAMAMA

'''Binôme'''

Ilyas MABROUK, Shitao XING.

'''Description'''

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

'''Objectifs'''

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

'''Compétences demandées'''

*La commande avancée.

*Modélisation et identification des systèmes linéaires invariants.

*Maîtrise du logiciel de simulation Labview.

*Maîtrise de Simulink ainsi que la boite à outil RTW.

'''Matériel'''

*Le système hydraulique.

*La carte d'acquisition National Instrument.

'''Logiciel'''

*Matlab/Simulink

*Labview

*NI Max

----

=== '''Avancement du projet''' ===

'''Semaine par semaine'''

'''Semaine 1 (04/02/13)'''

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

'''Semaine 2 (14/02/13)'''

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacter National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilité.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données des entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

'''Semaine 3 (27/02/13)'''

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune des ces solutions:

Solution 1: Cette solution est assez intuitive: Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réaliser uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité; Le tunnel ActiveX fonctionne avec un tableur statique, c'est à dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

'''Semaine 4 (04/03/13)'''

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté; Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

[[Fichier:Sinusoide.JPG]]

[[Fichier:Sinusoide2.JPG]]

'''Semaine 5 (07/03/13)'''

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci dessous une image du modèle Simulink initial.

[[Fichier:model1.jpg]]

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait et on obtient un message d'erreur.

[[Fichier:erreur1.jpg]]

'''Semaine 6 (13/03/13)'''

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

[[Fichier:test.jpg]]

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

'''Semaine 7 (20/03/13)'''

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux; Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre; Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

'''Semaine 8 (25/03/13)'''

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

*image*

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a creer une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

'''Semaine 9 (28/03/13)'''

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci dessus le message ainsi affiché.

*Image

'''Semaine 10 (04/04/13)'''

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectuer une identification en envoyant un echelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

[[Fichier:bo.jpg]]

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

[[Fichier:smith.jpg]]

Le correcteur satisfait aux objectifs.

'''Semaine 22 (10/04/13)'''

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

[[Fichier:1.jpg]]

[[Fichier:2.jpg]]

[[Fichier:3.jpg]]

[[Fichier:4.jpg]]

'''Semaine 24 (29/04/13)'''

Réalisation de la vidéo et finalisation du rapport.

Projets IMA4 SC & SA 2012/2013

2013-01-31T16:50:27Z

Sxing : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants !! Elèves
|-
| Adaptation d'une pile TCP/IP sur Arduino
|
|
|-
| Construction d'un point d'accès WiFi
|
|
|-
| Dé WiFi
|
|
|-
| 3615 Facebook
|
|
|-
| Clavier réseau
|
|
|-
| e-monotron
|
|
|-
| Shield arduino Multi-affichage
|
|
|-
| Interface de supervision avec RTW et LABVIEW
|
|
|-
| Radio logicielle
|
|
|-
| Projet Can sat
|
|
|-
| Suivi de vieillissement du béton
|
|
|-
| Compétition TI
|
|
|-
| Localisation de robot
|
|
|-
| Matrice de LED 3D
|
|
|-
| Extensions robot Mindstorm
|
|
|-
| Traceur de choc
|
|
|-
| Site web par SMS
|
|
|-
| Robot mobile
|
|
|-
| Robot de grande taille
|
|
|-
| Suspension magnétique
|
|
|-
| Prototype de chaine de transmission
|
|
|-
| Visualisation 3D pour simulation robotique
|
|
|-
| Vision déportée
|
|
|-
| Banc de test automatisé
|
|
|-
| Musique embarquée
|
|
|-
| Analyseur de chronogramme pour module temps-réel
|
|
|-
| Robotino, joueur de hockey
|
|
|-
| Connexion d’un automate à un environnement virtuel 3D
|
|
|-
| Synchronisation des mouvements Humain-NAO
|
|
|-
| [[WorldSkills2012|Préparation à la compétition WorldSkills International]]
| Rochdi Merzouki
| Florent Chrétien / Mélanie Lelaure
|-
| Commande d'un robot mobile holonome et manipulateur
|
|
|-
| API REST pour AlternC
|
|
|-
| Système d'interaction dans un musée
|
|
|-
|}

== Bilan ==

{| class="wikitable"
! Projet !! Encadrement !! Wiki !! Rapport !! Vidéo
|-
|}

Contrôle de matrice leds, 2011/2012, TD2

2012-06-18T09:00:47Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

'''Le 25 Mai 2012: Séance 1'''

En premier lieu, on a réparti le travail, Shitao s'est occupé de la partie électronique et Ilyas de celle informatique.

'''Partie électronique:'''

Analyse le sujet et modélisation.

Fonctionnement: Le système doit recevoir 8 octets et les afficher sur la matrice de LEDs. La bascule D nous permet de stocker un octet. Le problème est comment stocker les 8 octets de données dans 8 bascules D et les renvoyer dans l'ordre en cohérence avec les bits de contrôles sachant que chaque bit de contrôle gère une colonne de LEDs ?

'''Partie informatique:'''

On a commencé par comprendre le programme de gestion du port série et le modifier pour pouvoir tester l'exemple d’envoi d'un octet. Dans notre projet le programme de gestion du port série s'appelle "gestion_spi.c" et son exécutable "./gestion_spi". On a ensuite envoyé une suite de huit octets choisie aléatoirement pour comprendre comment marche l'affichage sur la matrice de LEDs.

----

'''Le 1 Juin 2012: Séance 2'''

'''Partie électronique:'''

On utilise le Démultiplexeur qui est relié au bit de contrôle de la bascule D. En entrée, on a un compteur lié à un bouton poussoir. Chaque fois le bouton poussoir est poussé, le compteur s'incrémente, puis un seul bit est alors fixé à 1. C'est la bascule D correspondante qui stocke les données et le reste ne change pas. Pour renvoyer un seul octet de la bascule D à la matrice de LEDs, on a choisi un multiplexeur et un démultiplexeur contrôlé par un même compteur. Le compteur est relié avec l'horloge du FPGA, le multiplexeur sert à contrôler les données en sortie et le démultiplexeur détermine quelle est la colonne choisie. Après, on teste le FPGA avec l'oscilloscope. Le système fonctionne, toutefois, à partir du 4ième bit, il y a un retard, le système n'est donc pas synchronisé. Pour cela, on a synchronisé les compteurs avec l'horloge. Le problème est alors réglé.

[[Fichier:montage.png]]

'''Partie informatique:'''

Cette séance était entièrement consacrée à la conception de l'interface web du projet. Au début, on a testé l'exemple fournie pour l'affichage d'une ligne de quatre LEDs qui change de couleur en cliquant dessus. Après, on a modifié la page HTML en page dynamique PHP pour pouvoir afficher les 64 LEDs grâce aux deux boucles suivantes:

----

<?php

$table="";

$val = 0;

for($i=0; $i < 8; $i++){

$table .= "<tr>";

for($j=0; $j < 8; $j++){

$val = $i*10 + $j ;

$table .= "<td>";

$table .= "<img id=$val src='/cercle.php?couleur=vert' onclick='javascript:changeCouleur($val)'";

$table .= "</td>";

}

$table .= "</tr>";

}

echo $table;

?>

----

'''Le 8 juin 2012: Séance 3'''

'''Partie électronique:'''

Au début, le montage ne marchait pas à cause d'un mauvais choix de la résistance. Après, le système fonctionne correctement.

'''Partie informatique:'''

Pendant cette séance on a ajouté des fonctions java-script afin de récupérer les données nécessaires pour le script cgi-bin. Pour cela, on a ajouté deux fonctions: verifier(), unit(), et on a remplacé la fonction changeCouleur(identifiant) par envoyer(identifiant):

unit(): initialise toutes les LEDs en couleur verte.

envoyer(identifiant): change la couleur de la LEDs numéro: identifiant en cliquant dessus et mets la variable allumer=1 si elle est en rouge ou allumer=0 le cas contraire.

verifier(): envoie les numéros de ligne (i) et de colonne (j) des LEDs allumées au script cgi-bin grâce à une requête Ajax sous la forme d'une chaîne de caractère de la forme "_ij_ij_...." à intervalle régulier de 3s.

----

'''Le 15 juin 2012: Séance supplémentaire'''

'''Partie informatique:'''

Modification du scritp cgi-bin qui s'appelle envoie_octet.c dans notre projet. On a ajouté une fonction "get_word(char x[MAX],unsigned char c[]) qui découpe la chaine de caractère reçue de la page web, "x", pour pouvoir déterminer les numéros de ligne et de colonne des LEDs allumées puis envoyer les octets correspondants à l'aide de la chaine "c[ ]".
Ensuite, on a copié les programmes et recompilé dans la Foxbord: Pindex.php, cercle.php, gestion_spi.c, envoie_octet.c. On a testé après la page web avec le banc d’essai disponible dans la salle.

'''Partie électronique:'''

Terminée.

'''Fin:'''

Branchement de la Foxbord avec la Nanobord.

Réalisation de la vidéo de teste.

Conclusion: Le sous-système marche bien.

Fichier:Montage.png

2012-06-18T08:59:00Z

Sxing :

Contrôle de matrice leds, 2011/2012, TD2

2012-06-18T08:58:45Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

'''Le 25 Mai 2012: Séance 1'''

En premier lieu, on a réparti le travail, Shitao s'est occupé de la partie électronique et Ilyas de celle informatique.

'''Partie électronique:'''

Analyse le sujet et modélisation.

Fonctionnement: Le système doit recevoir 8 octets et les afficher sur la matrice de LEDs. La bascule D nous permet de stocker un octet. Le problème est comment stocker les 8 octets de données dans 8 bascules D et les renvoyer dans l'ordre en cohérence avec les bits de contrôles sachant que chaque bit de contrôle gère une colonne de LEDs ?

[[Fichier:montage.png]]

'''Partie informatique:'''

On a commencé par comprendre le programme de gestion du port série et le modifier pour pouvoir tester l'exemple d’envoi d'un octet. Dans notre projet le programme de gestion du port série s'appelle "gestion_spi.c" et son exécutable "./gestion_spi". On a ensuite envoyé une suite de huit octets choisie aléatoirement pour comprendre comment marche l'affichage sur la matrice de LEDs.

----

'''Le 1 Juin 2012: Séance 2'''

'''Partie électronique:'''

On utilise le Démultiplexeur qui est relié au bit de contrôle de la bascule D. En entrée, on a un compteur lié à un bouton poussoir. Chaque fois le bouton poussoir est poussé, le compteur s'incrémente, puis un seul bit est alors fixé à 1. C'est la bascule D correspondante qui stocke les données et le reste ne change pas. Pour renvoyer un seul octet de la bascule D à la matrice de LEDs, on a choisi un multiplexeur et un démultiplexeur contrôlé par un même compteur. Le compteur est relié avec l'horloge du FPGA, le multiplexeur sert à contrôler les données en sortie et le démultiplexeur détermine quelle est la colonne choisie. Après, on teste le FPGA avec l'oscilloscope. Le système fonctionne, toutefois, à partir du 4ième bit, il y a un retard, le système n'est donc pas synchronisé. Pour cela, on a synchronisé les compteurs avec l'horloge. Le problème est alors réglé.

'''Partie informatique:'''

Cette séance était entièrement consacrée à la conception de l'interface web du projet. Au début, on a testé l'exemple fournie pour l'affichage d'une ligne de quatre LEDs qui change de couleur en cliquant dessus. Après, on a modifié la page HTML en page dynamique PHP pour pouvoir afficher les 64 LEDs grâce aux deux boucles suivantes:

----

<?php

$table="";

$val = 0;

for($i=0; $i < 8; $i++){

$table .= "<tr>";

for($j=0; $j < 8; $j++){

$val = $i*10 + $j ;

$table .= "<td>";

$table .= "<img id=$val src='/cercle.php?couleur=vert' onclick='javascript:changeCouleur($val)'";

$table .= "</td>";

}

$table .= "</tr>";

}

echo $table;

?>

----

'''Le 8 juin 2012: Séance 3'''

'''Partie électronique:'''

Au début, le montage ne marchait pas à cause d'un mauvais choix de la résistance. Après, le système fonctionne correctement.

'''Partie informatique:'''

Pendant cette séance on a ajouté des fonctions java-script afin de récupérer les données nécessaires pour le script cgi-bin. Pour cela, on a ajouté deux fonctions: verifier(), unit(), et on a remplacé la fonction changeCouleur(identifiant) par envoyer(identifiant):

unit(): initialise toutes les LEDs en couleur verte.

envoyer(identifiant): change la couleur de la LEDs numéro: identifiant en cliquant dessus et mets la variable allumer=1 si elle est en rouge ou allumer=0 le cas contraire.

verifier(): envoie les numéros de ligne (i) et de colonne (j) des LEDs allumées au script cgi-bin grâce à une requête Ajax sous la forme d'une chaîne de caractère de la forme "_ij_ij_...." à intervalle régulier de 3s.

----

'''Le 15 juin 2012: Séance supplémentaire'''

'''Partie informatique:'''

Modification du scritp cgi-bin qui s'appelle envoie_octet.c dans notre projet. On a ajouté une fonction "get_word(char x[MAX],unsigned char c[]) qui découpe la chaine de caractère reçue de la page web, "x", pour pouvoir déterminer les numéros de ligne et de colonne des LEDs allumées puis envoyer les octets correspondants à l'aide de la chaine "c[ ]".
Ensuite, on a copié les programmes et recompilé dans la Foxbord: Pindex.php, cercle.php, gestion_spi.c, envoie_octet.c. On a testé après la page web avec le banc d’essai disponible dans la salle.

'''Partie électronique:'''

Terminée.

'''Fin:'''

Branchement de la Foxbord avec la Nanobord.

Réalisation de la vidéo de teste.

Conclusion: Le sous-système marche bien.

Contrôle de matrice leds, 2011/2012, TD2

2012-06-18T08:57:23Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

'''Le 25 Mai 2012: Séance 1'''

En premier lieu, on a réparti le travail, Shitao s'est occupé de la partie électronique et Ilyas de celle informatique.

'''Partie électronique:'''

Analyse le sujet et modélisation.

Fonctionnement: Le système doit recevoir 8 octets et les afficher sur la matrice de LEDs. La bascule D nous permet de stocker un octet. Le problème est comment stocker les 8 octets de données dans 8 bascules D et les renvoyer dans l'ordre en cohérence avec les bits de contrôles sachant que chaque bit de contrôle gère une colonne de LEDs ?

[[Fichier:montage.pdf]]
[[Fichier:montage]]

'''Partie informatique:'''

On a commencé par comprendre le programme de gestion du port série et le modifier pour pouvoir tester l'exemple d’envoi d'un octet. Dans notre projet le programme de gestion du port série s'appelle "gestion_spi.c" et son exécutable "./gestion_spi". On a ensuite envoyé une suite de huit octets choisie aléatoirement pour comprendre comment marche l'affichage sur la matrice de LEDs.

----

'''Le 1 Juin 2012: Séance 2'''

'''Partie électronique:'''

On utilise le Démultiplexeur qui est relié au bit de contrôle de la bascule D. En entrée, on a un compteur lié à un bouton poussoir. Chaque fois le bouton poussoir est poussé, le compteur s'incrémente, puis un seul bit est alors fixé à 1. C'est la bascule D correspondante qui stocke les données et le reste ne change pas. Pour renvoyer un seul octet de la bascule D à la matrice de LEDs, on a choisi un multiplexeur et un démultiplexeur contrôlé par un même compteur. Le compteur est relié avec l'horloge du FPGA, le multiplexeur sert à contrôler les données en sortie et le démultiplexeur détermine quelle est la colonne choisie. Après, on teste le FPGA avec l'oscilloscope. Le système fonctionne, toutefois, à partir du 4ième bit, il y a un retard, le système n'est donc pas synchronisé. Pour cela, on a synchronisé les compteurs avec l'horloge. Le problème est alors réglé.

'''Partie informatique:'''

Cette séance était entièrement consacrée à la conception de l'interface web du projet. Au début, on a testé l'exemple fournie pour l'affichage d'une ligne de quatre LEDs qui change de couleur en cliquant dessus. Après, on a modifié la page HTML en page dynamique PHP pour pouvoir afficher les 64 LEDs grâce aux deux boucles suivantes:

----

<?php

$table="";

$val = 0;

for($i=0; $i < 8; $i++){

$table .= "<tr>";

for($j=0; $j < 8; $j++){

$val = $i*10 + $j ;

$table .= "<td>";

$table .= "<img id=$val src='/cercle.php?couleur=vert' onclick='javascript:changeCouleur($val)'";

$table .= "</td>";

}

$table .= "</tr>";

}

echo $table;

?>

----

'''Le 8 juin 2012: Séance 3'''

'''Partie électronique:'''

Au début, le montage ne marchait pas à cause d'un mauvais choix de la résistance. Après, le système fonctionne correctement.

'''Partie informatique:'''

Pendant cette séance on a ajouté des fonctions java-script afin de récupérer les données nécessaires pour le script cgi-bin. Pour cela, on a ajouté deux fonctions: verifier(), unit(), et on a remplacé la fonction changeCouleur(identifiant) par envoyer(identifiant):

unit(): initialise toutes les LEDs en couleur verte.

envoyer(identifiant): change la couleur de la LEDs numéro: identifiant en cliquant dessus et mets la variable allumer=1 si elle est en rouge ou allumer=0 le cas contraire.

verifier(): envoie les numéros de ligne (i) et de colonne (j) des LEDs allumées au script cgi-bin grâce à une requête Ajax sous la forme d'une chaîne de caractère de la forme "_ij_ij_...." à intervalle régulier de 3s.

----

'''Le 15 juin 2012: Séance supplémentaire'''

'''Partie informatique:'''

Modification du scritp cgi-bin qui s'appelle envoie_octet.c dans notre projet. On a ajouté une fonction "get_word(char x[MAX],unsigned char c[]) qui découpe la chaine de caractère reçue de la page web, "x", pour pouvoir déterminer les numéros de ligne et de colonne des LEDs allumées puis envoyer les octets correspondants à l'aide de la chaine "c[ ]".
Ensuite, on a copié les programmes et recompilé dans la Foxbord: Pindex.php, cercle.php, gestion_spi.c, envoie_octet.c. On a testé après la page web avec le banc d’essai disponible dans la salle.

'''Partie électronique:'''

Terminée.

'''Fin:'''

Branchement de la Foxbord avec la Nanobord.

Réalisation de la vidéo de teste.

Conclusion: Le sous-système marche bien.

Contrôle de matrice leds, 2011/2012, TD2

2012-06-15T11:19:47Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

Le 25 Mai 2012

Partie électronique:Analyse le sujet et le modélise.

Fonctionnement: Le système doit recevoir 8 otects et les afficher sur la matrice de LEDs.La bascule D nous permet de stocker un octet.Le problème est comment je peux stocker les 8 octets de données dans 8 bascules D et les renvoyer dans l'ordre en cohérent avec les bits de contrôles.Chaque bit de contrôle gere une colone de LEDs.

[[Fichier:montage.pdf]]

Le 1 Juin 2012

Partie électronique

On utilise le Démultiplexeur qui est relié au bit de contrôle de bascule D. en entrée on a un compteur lié à un bouton poussoir.Chaque fois le bouton poussoir est poussé,le compteur s'incrémente , puis un seule bit sera fixé à 1.C'est la bascule D correspondante qui stocke les données et le reste ne change pas.Pour renvoyer un seul octet du bascule D à la matrice.On choisit un multiplexeur et un démultiplexeur controlé par un même compteur.Le compteur est rélié avec le horloge du FPGA.Le multiplexeur Pour contrôler les données en sortie.Le démultiplexeur détermine quelle colonne choisie .Après tout ça ,on teste le FPGA avec l'oscilloscope,en principal, le système fonctionne,mais ,à partir du 4ième bits, il y a un retard.Le systeme n'est pas synchronisé.Pour synchroniser le système,on synchronise les compteurs avec l'horloge.Le problème est réglé.

Le 8 Juin 2012

Au début,j'ai mal choisit le résistance.Après ,le système fonctionne correctement

Contrôle de matrice leds, 2011/2012, TD2

2012-06-15T11:09:44Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

Le 25 Mai 2012

Partie électronique:Analyse le sujet et le modélise.

Fonctionnement: Le système doit recois 8 otects et les affiche sur la matrice de LEDs.Le bascule D nous permets de stocker un octet.Le problème est comment je peux stocker les 8 octets de données dans 8 bascules D et les renvoie dans l'ordre en cohérent avec les bits de contrôles.Chaque bit de contrôle gere unc colone de LEDs.

[[Fichier:montage.pdf]]

Le 1 Juin 2012

Partie électronique

On utilise le Démultiplexeur qui rélie le bit de contrôle de bascule D. en entrée on a un compteur de bouton poussoir.Chaque fois le bouton poussoir est pussé,le compteur incrémentes , puis un seule bit sera fixé à 1.C'est le bascule D correspondant stocké les données et les rests ne change pas.Pour renvoyer un seule octet du bascule D au matrice.On choisit un multiplexeur et un démultiplexeur controlé par un même compteur.Le compteur est rélié avec le horloge du FPGA.Le multiplexeur Pour contrôleur le données en sortie.Le démultiplexeur détermine lequel collone choisi.Après tout ça ,on teste le FPGA avec l'oscillope,en principal, le système fonctionne,mais ,à partir du 4ième bits, il y a un retard.Le systeme n'est pas synchronisé.Pour synchroniser le système,on synchronise les compteurs avec l'horloge.Le problème est réglé.

Le 8 Juin 2012

Au début,j'ai mal choisit le résistance.Après ,le système fonctionne correctement

Contrôle de matrice leds, 2011/2012, TD2

2012-06-15T11:05:22Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

Le 25 Mai 2012

Partie électronique:Analyse le sujet et le modélise.

Fonctionnement: Le système doit recois 8 otects et les affiche sur la matrice de LEDs.Le bascule D nous permets de stocker un octet.Le problème est comment je peux stocker les 8 octets de données dans 8 bascules D et les renvoie dans l'ordre en cohérent avec les bits de contrôles.Chaque bit de contrôle gere unc colone de LEDs.

Le 1 Juin 2012

Partie électronique

On utilise le Démultiplexeur qui rélie le bit de contrôle de bascule D. en entrée on a un compteur de bouton poussoir.Chaque fois le bouton poussoir est pussé,le compteur incrémentes , puis un seule bit sera fixé à 1.C'est le bascule D correspondant stocké les données et les rests ne change pas.Pour renvoyer un seule octet du bascule D au matrice.On choisit un multiplexeur et un démultiplexeur controlé par un même compteur.Le compteur est rélié avec le horloge du FPGA.Le multiplexeur Pour contrôleur le données en sortie.Le démultiplexeur détermine lequel collone choisi.Après tout ça ,on teste le FPGA avec l'oscillope,en principal, le système fonctionne,mais ,à partir du 4ième bits, il y a un retard.Le systeme n'est pas synchronisé.Pour synchroniser le système,on synchronise les compteurs avec l'horloge.Le problème est réglé.

Le 8 Juin 2012

Au début,j'ai mal choisit le résistance.Après ,le système fonctionne correctement

Contrôle de matrice leds, 2011/2012, TD2

2012-06-15T10:54:43Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao

Le 25 Mai 2012

Partie électronique:Analyse le sujet et le modélise.

Fonctionnement: Le système doit recois 8 otects et les affiche sur la matrice de LEDs.Le bascule D nous permets de stocker un octet.Le problème est comment je peux stocker les 8 octets de données dans 8 bascules D et les renvoie dans l'ordre en cohérent avec les bits de contrôles.Chaque bit de contrôle gere unc colone de LEDs.

Le 1 Juin 2012

Partie électronique

On utilise le Démultiplexeur qui rélie le bit de contrôle de bascule D. en entrée on a un compteur de bouton poussoir.Chaque fois le bouton poussoir est pussé,le compteur incrémentes , puis un seule bit sera fixé à 1.C'est le bascule D correspondant stocké les données et les rests ne change pas.Pour renvoyer un seule octet du bascule D au matrice.On choisit un multiplexeur et un démultiplexeur controlé par un même compteur.Le compteur est rélié avec le horloge du FPGA.Le multiplexeur Pour contrôleur le données en sortie.Le démultiplexeur détermine lequel collone

Contrôle de matrice leds, 2011/2012, TD2

2012-06-08T13:36:32Z

Sxing :

Réalisé par MABROUK Ilyas et XING Shitao