travaux pratiquesekladata.com/o1z_ch5lucmbeuc0lsxtqnzkxvk.pdf · electronique electrotechnique...

UNIVERSITÉ PAUL SABATIER (TOULOUSE III)

--------

MASTER E.E.A. A.E.E.T.S

Electronique Electrotechnique Automatique

Spécialité ISTR

Unité d’Enseignement EM8ETRAM

Techniques de Mise en Œuvre pour les Systèmes à Evénements Discrets

TRAVAUX PRATIQUES

2015 – 2016

E. Le Corronc – L. Houssin – P. Esteban

Salle de Travaux Pratiques

TP EEA Info. Industrielle

Temps Réel

salle I1 - Bâtiment 3 TP 2 - du coté de l'amphi Maxwell

M1-EEA-ISTR – I7 – TMO-SED – 2015/16 Organisation et Consignes Importantes i

ORGANISATION ET CONSIGNES IMPORTANTES

1. OBJECTIFS DES TRAVAUX PRATIQUES Cette série de 6 séances de 3 heures de Travaux Pratiques a pour but d'illustrer différentes techniques de

mise en œuvre pour les SED : MEF, Réseaux de Petri, MEF coordonnées. Différentes techniques et différents langages sont envisagés, sans avoir la prétention de considérer toutes

les techniques possibles.

2. ORGANISATION DE LA SERIE DE MANIPULATIONS Les 6 séances de la séquence s’articulent en 2 parties : - 2 séances de manipulation Chaque binôme réalise 2 manipulations parmi 3 thèmes proposés. Chacune des 3 manipulations est basée sur la commande d’un procédé par 2 techniques différentes. Tous les travaux de modélisation doivent être réalisés lors de la préparation du travail, pour profiter

pleinement des matériels pour mettre au point les commandes. Un contrôle de la commande mise en œuvre est effectué en fin de chaque séance. - 4 séances de mini-projet Chaque binôme développe un mini-projet consistant à commander un processus qui n’a pas été

envisagé dans la 1e partie. Le mini-projet consiste à développer un générateur de code dans un des langages disponibles et pour

une technique de mise en œuvre donnée, en partant de la modélisation du système de commande. Un contrôle du développement du projet est effectué en fin de la 4

e séance.

3. CONTROLE DES CONNAISSANCES Le travail est évalué par un contrôle continu basé sur les contrôles des commandes mises en œuvre et sur

les comptes rendus remis en fin de manipulations et en fin de mini-projet.

M1-EEA-ISTR Techniques de Mise en Œuvre pour les Systèmes à Evénements Discrets

Organisation des TP - 2015-16 18h de TP réparties en 6 séances de 3h : 2 manipulations de 3h suivies de 4 séances de projet de 3h Les binômes sont répartis en 3 groupes P, Q, R de 3 binômes chacun pour traiter 2 manipulations sur 3. Groupes P Q R Binômes P1 P2 P3 Q1 Q2 Q3 R1 R2 R3

Séance1 Manip 1 : Cde d’Ascenseur

par plusieurs MEF en C Manip 2 : Cde de Machine à

Laver par RdP en VHDL Manip 3 : Cde de BCI par

MEF en langage ST

Séance2 Manip 2 : Cde de Machine à

Laver par RdP en VHDL Manip 3 : Cde de BCI par

MEF en langage ST Manip 1 : Cde d’Ascenseur

par plusieurs MEF en C

Séance3 à

Séance6

1 des 2 projets : 1 des 2 projets : 1 des 2 projets : RdP ST BCI

MEF ST BCI

MEF C

Asc

RdP C

Asc

RdP VHDL MàL

MEF VHDL MàL

Groupe 1 lundi 16h30-19h30 du lundi 07/03 au lundi 18/04

P1= . . Q1= . . R1= . .

P2= . . Q2= . . R2= . .

P3= . . Q3= . . R3= . .

Groupe 2 vendredi 16h30-13h30 du vendredi 18/03 au xx/xx P1= . . Q1= . . R1= . . P2= . . Q2= . . R2= . . P3= . . Q3= . . R3= . . Groupe 3 vendredi 13h30-16h30 du vendredi 18/03 au xx/xx

P1= . . Q1= . . R1= . .

P2= . . Q2= . . R2= . .

P3= . . Q3= . . R3= . .

M1-EEA-ISTR – I7 – TMO-SED – 2015/16 - Poste de manipulation 1 - 1/2

- Poste de manipulation 1 -

Commande d’une maquette d’ascenseur Modélisation par MEF coordonnées – Mise en œuvre en C

1. BUT

Ce poste de manipulation a pour objectif d’effectuer la mise en œuvre en C d’un ensemble de MEF coordonnées. Les MEF ne sont pas complètement indépendantes, et concourent à la commande du procédé. Deux techniques de mise en œuvre sont envisagées : réalisation 1 parmi N, mise en œuvre directe de MEF coordonnées.

2. CONTEXTE DE LA MANIPULATION

2.1. Matériel disponible

La maquette d’ascenseur est constituée d’une cabine pouvant monter ou descendre entre 4 paliers (Monter, Descendre), sa position étant connue lorsqu’elle est à un étage (ET_i). A l’intérieur sont disposés 4 boutons de consigne d’étage à atteindre (AP_i). Chaque palier (sauf le 4e) a un bouton d’appel pour monter (P_j_m) et son témoin (T_j_m) et un pour descendre (sauf le 1er) (P_k_d), et son témoin (T_k_d). Chaque porte d’étage a un capteur d’ouverture, et la maquette présente comme information le fait qu’une porte, au moins, est ouverte (PorteOuverte). Une alarme peut être émise (Alarme).

Bilan des signaux :

Capteurs : AP_i, ET_i, i ∈ [1, 4] P_j_m, j ∈ [1, 3] P_k_d, k ∈ [2, 4] PorteOuverte Urgence Actionneurs : T_j_m, j ∈ [1, 3] T_k_d, k ∈ [2, 4] Monter, Descendre Alarme

signaux ignorés dans cette étude

2.2. Commande envisagée : étape 1

La cabine se déplace entre les paliers 1 à 3. Seuls les capteurs AP_i et ET_i, i ∈ [1, 3], doivent être considérés dans l’étude (étape 1 et étape 2).

La cabine étant à l’arrêt, elle se déplace vers l’étage i demandé si AP_i ≠ ET_i. A l’arrivée à l’étage, ouverture puis fermeture de la porte autoriseront un nouveau déplacement. Un nouvel appel n’est pris en compte qu’après fermeture de la porte ; il n’est par ailleurs pris en compte que lorsque la cabine est à l’arrêt.

Au départ, la cabine est à l’arrêt au palier 1.

Modéliser cette commande par une MEF élémentaire.


Le fonctionnement précédent est repris comme base : déplacement si AP_i ≠ ET_i, nouveau déplacement possible après ouverture-fermeture de la porte. Dans cette 2nde étape, les appels doivent être mémorisés pour pouvoir être pris en compte lors du prochain départ. Un appel effectué au cours du déplacement de la cabine ne sera donc pas oublié.

Modéliser cette commande par un réseau de Petri. Identifier les composantes conservatives et décomposer le réseau en plusieurs MEF coordonnées.


3. MISE EN ŒUVRE

La mise en œuvre de la commande suppose que le procédé est câblé au système de commande. La connectique suivante devra être réalisée :

capteurs AP1=0 AP2=1 AP3=2 ET1=3 ET2=4 ET3=5 PorteOuverte=6 sur le port B : bits 0 à 7 = entrées 0 à 7 actionneurs Monter=0 Descendre=1 sur le port A : bits 0 à 7 = sorties 0 à 7

Des fichiers de base sont mis à disposition, sous Linux, dans un dossier partagé, et sont à recopier dans le répertoire de travail :

dossier /home/partage/commun/M1_ISTR_TMOSED/ASCENSEUR_C

Edition, compilation en C et exécution se feront sous Linux :

édition gedit FichierCommande.c & compilation gcc –Wall FichierCommande.c –o Commande –lcomedi exécution ./Commande

3.1. Réalisation par codage 1 parmi N

Mettre en œuvre la commande envisagée à l’étape 1 en décrivant le système d’équations associé.

S’appuyer sur le fichier SqueletteCommande.c et utiliser les fonctions LireEntree et EcrireSortie décrites dans entrees_sorties.c

int LireEntree (int EntreeNo) // renvoie la valeur lue sur la "EntreeNo"eme entree du port d'entree // EntreeNo dans [0..15] void EcrireSortie (int SortieNo, int Valeur) // ecrit la "Valeur" sur la "SortieNo"eme sortie du port de sortie // SortieNo dans [0..7] // Valeur dans [0..1]

3.2. Mise en œuvre directe

Mettre en œuvre la commande envisagée à l’étape 2.

Conserver la réalisation par codage 1 parmi N de la MEF de l’étape 1, en modifiant éventuellement les équations qui la décrivent.

Réaliser par mise en œuvre directe toutes les autres MEF à coordonner.

4. TRANSMISSION DES RESULTATS

Présenter en fin de séance le fonctionnement de la commande mise en œuvre.

Expliquer dans le compte-rendu les raisons ayant permis de construire les différents modèles, ainsi que les restrictions retenues, le cas échéant.

En s’appuyant sur ces modèles, donner des exemples de traduction dans les 2 cas de mise en œuvre envisagés.

Fournir avec le compte-rendu un listing des programmes développés en cours de séance.

Utiliser la commande : a2ps NomDufichierImprimable.c



Commande d’une maquette de Machine à Laver

Modélisation par Réseau de Petri – Mise en œuvre en VHDL

1. BUT

L’objectif de cette manipulation est d’effectuer la mise en œuvre en VHDL (voir documentations VHDL et

« Quartus ») d’un Réseau de Petri sauf. Deux techniques de mise en œuvre sont envisagées : réalisation 1 parmi N

étendue, mise en œuvre directe du réseau de Petri.



La maquette de machine à laver présente un ensemble de boutons de commande : un bouton d’acceptation

(Accept), un d’annulation (Cancel) et 3 choix de programmes (Program Selectors, Prog1 à Prog3). Un capteur

détecte l’ouverture de la porte (Door Open/Close : 1=ouverte). Le moteur du tambour peut être commandé (Moteur :

1=marche) en indiquant dans quel sens il doit tourner (Sens : 0 sens horaire, 1 sens trigo). Une alarme peut être émise

(Alarme), et un chiffre peut être écrit sur un afficheur 7 segments (quadruplet Aff3, Aff2, Aff1, Aff0). La maquette

requiert un signal de contrôle (Validation : à maintenir à 0).

Bilan de ces signaux :

Capteurs : Prog_i, i [1, 3] Accept Cancel Door

Actionneurs : Aff_j, j [0, 3] Moteur Sens Alarme Validation


Lorsque l’utilisateur choisit un des 3 programmes, si la porte est ouverte alors l’alarme doit sonner jusqu’à ce

que la porte soit fermée, sinon, la porte étant fermée, le système se place en attente de confirmation ou annulation par

l’utilisateur. S’il annule son choix, le système est ramené dans son état de départ ; s’il le confirme, le programme de

lavage choisi est alors exécuté jusqu’à être terminé.

Le programme de lavage 1 consiste à faire tourner le tambour dans le sens horaire puis dans le sens trigo, à

chaque fois durant 5 secondes.

Les programmes de lavage 2 et 3 sont ignorés pour l’instant.

Modéliser cette commande par un réseau de Petri sauf. Il peut avoir la forme d’une MEF.


La commande s’appuie sur l’étape 1 qu’elle reprend entièrement, complétée par le programme de lavage 2.

Le programme 2 consiste à exécuter 3 fois la séquence des 2 rotations. Dans la modélisation, cette séquence ne

devra être décrite qu’une seule fois : elle sera parcourue 1 fois pour le programme 1, 3 fois pour le programme 2.

De plus, durant l’exécution des rotations, et à tout instant, actionner l’un des boutons programme, acceptation

ou annulation déclenche l’alarme, qui cesse quand ces actions sont annulées. Le retour en situation de départ après la

fin du cycle du programme de lavage ne peut se faire que lorsqu’il n’y a pas d’alarme.

Le programme de lavage 3 est ignoré.

Modéliser cette commande par un réseau de Petri sauf, en profitant du pouvoir d’expression du parallélisme.


3. MISE EN ŒUVRE

Quelle que soit la technique de mise en œuvre retenue, il faut connecter le système de commande avec le

procédé. Connectique avec la maquette :

Prog1 : 5 Prog2 : 6 Prog3 : 8 Accept: 10 Cancel : 9 Door : 4

Moteur : 21 Sens : 22 Alarme : 24 Validation : 25 Aff[3..0] : 20,18,17,16

Init : 30

Un certain nombre de fichiers sont mis à disposition, sous Windows, dans un dossier accessible en se

connectant au réseau, et sont à recopier dans le répertoire de travail :

se connecter Outils/Connecter un lecteur réseau depuis une fenêtre Windows

au dossier I1/Agamemnon/commun/M1_ISTR_TMOSED/MAL_VHDL

L’accès à l’outil Quartus de Altera permettant la programmation en VHDL du circuit EPM1728SLC84-6

(famille MAX7000S) se fait par un raccourci sur le bureau :

icône Quartus II 9.1 Web Edition

3.1. Réalisation par codage 1 parmi N étendu


Une MEF décrivant la temporisation est déjà écrite. Elle compte le temps tant que la commande sur son entrée

DebTempo est vraie. Elle fournit en sortie le signal FinTempo, vrai lorsque la durée prévue s’est écoulée.

Un fichier VHDL de base est proposé :

RdP_commandeSquelette.vhd squelette de la commande, à compléter.



Pour cela, on dispose de fichiers VHDL spécifiques :

place_b.vhd description du composant place binaire

R_d_P.vhd liste de composants disponibles pour la commande

RdP_binaireSquelette.vhd squelette de la commande, à compléter.

R_d_P.vhd : library ieee;

use ieee.std_logic_1164.all ;

package R_d_P is

component place_b

port (ck, ra0_init, ra1_init, activer, desactiver : in std_logic;

marque : out std_logic);

end component;

end R_d_P;



Expliquer dans le compte-rendu les raisons ayant permis de construire les différents modèles, ainsi que les

restrictions retenues, le cas échéant.





Commande d’une maquette de Banc de Contrôle Industriel (BCI)

Modélisation par MEF – Mise en œuvre en ST sur API

1. BUT

L’objectif de cette manipulation est d’effectuer la mise en œuvre en langage ST (voir annexe) sur Automate

Programmable Industriel Télémécanique (TSX Prémium) d’un système de commande modélisé par MEF. Deux

techniques de mise en œuvre sont envisagées : réalisation 1 parmi N, mise en œuvre directe.



Un convoyeur à chaîne (A4) déplace des bouchons en plastique et un tapis (A5) des bouteilles en métal ; des

capteurs (C1, C4, C6) détectent leur présence et des éjecteurs (A1, A3) peuvent les pousser hors convoyeur et tapis.

A1

A2

Convoyeur à chaîne

glissière à bouteilles

goulotte d'assemblage

zone d'assemblage

zone de test

zone de tri

butée pour

les bouteilles

tapis


Le tapis et le convoyeur à chaîne sont à l’arrêt.

L’action sur un bouton Opérateur met en route le tapis (A5) et le convoyeur (A4). Le tapis s’arrête après le

passage d’une bouteille en fin de zone de test (C6), le convoyeur après le passage d’un bouchon (C1).

Un nouveau cycle est alors possible en actionnant le bouton Opérateur.

Modéliser cette commande par MEF en envisageant tous les cas de fonctionnement.



Le tapis et la chaîne sont à l’arrêt.

L’action sur le bouton Opérateur entraîne le fonctionnement :

• le tapis et le convoyeur sont mis en route simultanément,

• le tapis s’arrête après détection et éjection (A3) d’une bouteille en fin de zone de test,

• le convoyeur s’arrête en détectant un bouchon et attend que la bouteille transportée par le tapis ait atteint

ou dépassé le capteur C4 pour pouvoir éjecter ce bouchon.

• dès que les 2 objets ont été éjectés, un nouveau cycle peut être lancé en actionnant le bouton Opérateur.

Modéliser cette commande par un réseau de Petri sauf. En déduire la MEF équivalente en construisant son

graphe des marquages accessibles.

3. MISE EN ŒUVRE

Quelle que soit la technique de mise en œuvre retenue, il faut connecter le système de commande avec le

procédé. La connectique avec la maquette est déjà établie.

Des fichiers sont mis à disposition, sous Windows, dans un dossier accessible en se connectant au réseau, et

sont à recopier dans le répertoire de travail :

se connecter Outils/Connecter un lecteur réseau depuis une fenêtre Windows

au dossier I1/Agamemnon/commun/M1_ISTR_TMOSED/BCI_ST

3.1. Réalisation par codage 1 parmi N


Le fichier suivant définit la connectique entre l’automate et la maquette de BCI : modeleBCI.stu

Le recopier dans le répertoire de travail. Il sert de base, peut être renommé, et doit être complété.



Remplacer les équations de l’étape 1 par la MEF équivalente au réseau de Petri développé en étape 2.



Expliquer dans le compte-rendu les raisons ayant permis de construire les différents modèles, ainsi que les

restrictions retenues, le cas échéant.



M1-EEA-ISTR – I7 – TMO-SED – 2015/16 - Mini-Projet - 1/4

- Mini-Projet -

Génération de code de commande Divers modèles sources et divers langages cibles – Mise en œuvre en C

1. BUT

L'objectif est de développer une application écrite en C produisant un fichier écrit dans un langage cible donné (C, VHDL, ST ou IL) matérialisant le modèle de commande d'un procédé (MEF, réseau de Petri) suivant une technique de mise en œuvre choisie (codage 1 parmi n, mise en œuvre directe, …). Un tel outil était disponible au 1° semestre pour l'UE SED : la "moulinette".

2. CONTEXTE DU MINI-PROJET


Trois maquettes sont mises à disposition : un ascenseur, une machine à laver, un banc de contrôle industriel. Les caractéristiques de ces matériels ont été évoquées dans la description des Postes de manipulation.

La commande de ces maquettes peut être sur plate-forme linux (en langage C) ou windows (langage VHDL ; gestion d'automate programmable industriel pour les langages ST et IL).

maquette binômes modèle et langage modèle technique

Projets envisageables :

banc de contrôle industriel P1…P3 RdP + ST MEF + ST ascenseur Q1…Q3 MEF + C RdP + C

machine à laver R1…R3 RdP + VHDL MEF + VHDL

2.2. Contexte de développement mis à disposition

Les documents de base disponibles sont un ensemble de fichiers contribuant au fonctionnement d'une application permettant de déduire le réseau de Petri obtenu à partir d'une modélisation par Tina. Cette application est développée en langage C ; les fichiers disponibles sont des fichiers "source" (en C) et des fichiers "objet" (pré-compilés), accompagnés de fichiers de contrôle de compilation (Makefile).

L'application décrit en interne une structure de données représentant le réseau de Petri : cette structure doit être utilisée pour générer le code dans le langage cible (C, VHDL, ST ou IL) mettant en œuvre la technique choisie (codage 1 parmi n, mise en œuvre directe).

Le modèle Machine à Etat Fini pouvant être décrit par le modèle réseau de Petri binaire, la structure de données RdP sera exploitée pour mettre en œuvre la commande aussi bien par un réseau de Petri que par une MEF.

2.3. Développement envisagé

Le fichier principal "main.c" présente les étapes principales suivies pour la génération de la "moulinetteRdP" : CreerStructure (LeFichierTINA, &TransitionsRdP, &PlacesRdP);

crée la structure de données représentant le réseau de Petri vu des transitions. Les places listent les actions associées.

GenererLog (PlacesRdP, TransitionsRdP, LeFichierLog); génère un fichier texte indiquant la structure élaborée.

GenererPlaces (PlacesRdP, LeFichierPlaces); génère un fichier C pour la déclaration des places (langage cible : C).

GenererBlocF (TransitionsRdP, LeFichierEnC); génère un fichier pour la mise en œuvre de la commande par description des transitions.

GenererBlocG (PlacesRdP, LeFichierBlocG); génère un fichier C pour la description des actions (langage cible : C).


Pour être adaptable à n'importe quelle maquette commandée par n'importe quel langage, le développement est organisé ainsi :

-1 choisir le matériel à commander, l'outil de modélisation et la technique de mise en œuvre,

-2 modéliser la commande par Tina (une MEF sera modélisée par un RdP binaire),

-3 décrire un squelette de la commande du procédé (dans le langage cible choisi),

-4 développer la fonction "GenererBlocF" pour produire le fichier texte "evolution_modele.txt" décrivant l'évolution du modèle (MEF ou RdP) suivant la technique de mise en œuvre retenue, dans le langage cible choisi,

-5 compiler la "moulinette" ainsi complétée,

-6 exécuter la "moulinette" : elle produit le fichier "evolution_modele.txt" dont le contenu est une partie de la mise en œuvre de la commande modélisée sous Tina,

-7 insérer le contenu du fichier texte "evolution_modele.txt" généré dans le squelette de commande (établi en -3), et compléter cette commande en déclarant correctement tous les éléments (entrées, sorties, variables internes), en lisant toutes les entrées utiles, et en décrivant une équation d'activation pour toutes les sorties nécessaires,

-8 utiliser la commande complétée pour piloter le procédé.

La première partie du projet consiste à développer et mettre au point la fonction "GenererBlocF".

Les étapes -4 à -8 seront réitérées jusqu'à satisfaction.

Ensuite il faudra décrire les autres fonctions, dans l'ordre "GenererBlocG", "GenererPlaces", "CreerStructure".

3. MISE EN ŒUVRE

Pour développer le mini-projet, des fichiers sont mis à disposition dans un dossier partagé :

linux : dossier : home/partage/commun/M1_ISTR_TMOSED/PROJET/linux

Le fichier "Makefile" est disponible pour assurer les phases de compilation. Le fichier "main.c" présente les étapes de traduction du fichier issu de la modélisation par Tina.

Le fichier "GenerateurCode.c" contient un squelette de la fonction "GenererBlocF".

Le fichier "types.c" définit les types utilisés par "CreerStructure" pour décrire le réseau de Petri.

Les autres fichiers sont des fichiers "objet" pré-compilés.

La modélisation sous Tina doit respecter l'utilisation d'étiquettes pour la description des actions associées aux places (ex. : [Action1, Action2]) et des conditions de franchissement des transitions écrites dans le langage cible (ex. en C : [CapteurA&&!CapteurB;]).

Par ailleurs, pour un projet de mise en œuvre de MEF, la MEF sera décrite sous Tina par un réseau de Petri binaire : la fonction "GenererBlocF" adaptera la description de réseau de Petri à une MEF.


Présenter en fin de la dernière séance le fonctionnement du projet jusqu’à la mise en œuvre de la commande.

Préciser dans le compte-rendu le projet retenu (maquette, modèle, technique de mise en œuvre et langage cible envisagés), les choix et restrictions éventuelles par rapport au contexte du projet.

Présenter les algorithmes mis en jeu en indiquant leur articulation avec les autres éléments du projet, et compléter le compte-rendu avec des listings commentés des parties de code développées.

Proposer la suite envisageable au travail fourni.


Fichier "main.c" :

#define MAX_NOM 200 #include <string.h> #include <stdio.h> #include <stdlib.h> #include "types.c" void NettoyerLaChaine (char *); void CreerStructure (char [MAX_NOM], Transition **, Place **); void GenererBlocF (Transition *TransitionsRdP, char [MAX_NOM]); void GenererLog (Place *, Transition * , char [MAX_NOM]); void GenererPlaces (Place *, char [MAX_NOM]); void GenererBlocG (Place *, char [MAX_NOM]); int main(void) { Transition * TransitionsRdP=NULL; Place * PlacesRdP=NULL; char LeFichierTINA[MAX_NOM] = "etiquette.ndr"; char LeFichierLog[MAX_NOM] = "etiquette.log"; char LeFichierEnC[MAX_NOM] = "evolution_modele.txt"; char LeFichierPlaces[MAX_NOM] = "LesPlaces.c"; char LeFichierBlocG[MAX_NOM] = "CalculDesSorties.c"; printf ("nom du fichier a Mouliner :"); scanf ("%s",LeFichierTINA); strcpy(LeFichierLog,LeFichierTINA); strcat(LeFichierTINA, ".ndr"); strcat(LeFichierLog,".log"); // ouverture du fichier issu de tina CreerStructure (LeFichierTINA, &TransitionsRdP, &PlacesRdP); // GenererLog (PlacesRdP, TransitionsRdP, LeFichierLog); // GenererPlaces (PlacesRdP, LeFichierPlaces); GenererBlocF (TransitionsRdP, LeFichierEnC); // GenererBlocG (PlacesRdP, LeFichierBlocG); return 1; }

Fichier "GenerateurCode.c" :

#include "types.c" #include <string.h> void GenererBlocF (Transition * PremiereTransition, char LeFichierEnC[MAX_NOM]) { ... }


Fichier "types.c" :

// a rendre global dans le fichier types #define MAX_NOM 200 #include <stdio.h> typedef struct ACTION { char Actions[MAX_NOM]; struct ACTION * Suivant; } Action; typedef struct ARC { char Place[MAX_NOM]; int Poids ; struct ARC * Suivant; } Arc; typedef struct TRANSITION{ char Nom[MAX_NOM]; int NbPlacesEntree; Arc *ArcsEntrants; int NbPlacesSortie; Arc *ArcsSortants; char Actions[MAX_NOM]; char Predicat[MAX_NOM]; struct TRANSITION * Suivant; } Transition; typedef struct PLACE{ char Nom[MAX_NOM]; int Mo; int NbActions; Action * Actions; struct PLACE * Suivant; } Place;

evolution_modele.txt

squelette de Cde

1

2

3

4

5 6

7

8

fichier.ndr

pilotage

« moulinette » compilation

GenerateurCode.c

Xf(X,Y) Yg(X,Y)

Annexe VHDL VHDL - FPGA p.1/4

VVHHDDLL –– UUNN LLAANNGGAAGGEE DDEE DDEESSCCRRIIPPTTIIOONN

VHDL est un langage surtout utilisé pour la modélisation, l'analyse et la simulation de réalisations électroniques de systèmes à événements discrets. Cette annexe n'a pas la prétention de présenter tous les aspects du langage, mais uniquement ceux qui sont nécessaires à la réalisation d'un système de commande basé sur un modèle séquentiel à événements discrets.

En VHDL, tout système est décrit par une Entité (Entity). La déclaration d'une entité ne s'intéresse qu'à ses entrées/sorties (Port) : c'est une vision externe de l'entité qui est considérée comme une "boîte noire". Exemple :

a, b, Horloge et S sont modélisées par des variables booléennes. La déclaration de l'entité

correspondant à ce système est la suivante :

Entity Commande is Port (a, b, Horloge : In Std_logic; S : Out Std_logic); End Commande;

A partir de cette déclaration, l'identificateur "Commande" peut être associé à la modélisation de TOUT système logique possédant trois entrées et une sortie booléennes.

La description du comportement interne de l'entité fait l'objet d'un bloc nommé "Architecture". Les données d'entrée/sortie sont bien sûr celles qui ont été déclarées dans l'entité. Si des données internes sont nécessaires à la description de l'Architecture de l'entité, elles doivent y être déclarées comme des signaux (signal). Le corps du bloc "Architecture" peut être constitué d'affectation représentant des expressions logiques ou de la description de systèmes séquentiels logiques. 1. Système combinatoire

Exemple de système combinatoire constituant une "Architecture" de l'entité "Commande" déclarée précédemment.

Systèmede

commande

a

bS

Horloge

a

b

S

S_InterneHorloge


Le bloc "Architecture" pouvant représenter ce système est :

Architecture Ou_Non of Commande is Signal : S_Interne : Std_logic; Begin S_Interne <= Not b; S <= S_Interne OR a OR Horloge; End Ou_Non;

Nota : La définition du signal S_Interne est, dans cet exemple, facultative. L'affectation S <= Not b OR a Or Horloge; suffirait à décrire le système Ou_Non. 2. Système séquentiel

Le modèle suivant est aussi une architecture possible de l'entité "Commande".

Pour pouvoir décrire l'Architecture correspondante, il est nécessaire de déclarer les variables internes

EtatPresent et EtatSuivant ainsi que la liste des valeurs symboliques qu'elles prennent dans le graphe d'états.

Type Etat Is (Etat1, Etat2, Etat3); Signal EtatPresent, EtatSuivant : Etat;

Le bloc F est ensuite décrit grâce à des affectations dont la syntaxe est proche de celle des langages

de programmation classique (Pascal ou C). Ceci se fait dans un bloc "Process".

Le bloc M est toujours décrit dans un bloc "Process" comme suit :

Process (Horloge) Begin if ((Horloge'EVENT) And (Horloge = '1')) then EtatPresent <= EtatSuivant ; End if ; End Process;

Le bloc G, combinatoire pur, est constitué par une suite d'affectations combinatoires.

a

bSEtat1 Etat2

Etat3

a

a

a.bb

bS=1

S=1

Horloge


En résumé, le fichier décrivant le système séquentiel ci-dessus peut s'écrire :

Architecture GrapheTroisEtats of Commande is -- ceci est un commentaire -- d'abord la déclaration des variables internes Type Etat Is (Etat1, Etat2, Etat3); Signal EtatPresent, EtatSuivant : Etat; Begin -- Ensuite le process décrivant le bloc F Process (EtatPresent, a, b) Begin Case EtatPresent Is When Etat1 => IF (a = '1') THEN EtatSuivant <= Etat2; ELSIF (b = '1') THEN EtatSuivant <= Etat3; ELSE EtatSuivant <= EtatPresent; End IF; When Etat2 => IF (a = '0') THEN EtatSuivant <= Etat1; ELSIF (b = '1') THEN EtatSuivant <= Etat3; ELSE EtatSuivant <= EtatPresent; End IF; When Etat3 => IF (b = '0') THEN EtatSuivant <= Etat1; ELSE EtatSuivant <= EtatPresent; End IF; End Case; End Process; -- Ensuite le process décrivant le bloc M Process (Horloge, Init) Begin If (Init = '1') then Etatpresent <= Etat1; Elsif (Horloge'EVENT) And (Horloge = '1')) THEN EtatPresent <= EtatSuivant ; End if ; End Process; -- Enfin les affectations décrivant le bloc G S <= '1' When ((EtatPresent = Etat2) Or (EtatPresent = Etat3)) Else '0'; End GrapheTroisEtats;

Les affectations combinatoires (sorties en particulier) peuvent prendre trois formes : 1. Affectation simple

X <= ExpressionLogique; 2. Affectation conditionnelle

X <= Expression1 When Condition Else Expression2;


3. Affectation sélectionnée

With ExpressionSelection Select x <= Expression1 When Valeur1,

Expression2 When Valeur2, ... ExpressionN When ValeurN, ValeurParDefaut When Others;

Dans le cas de l'affectation sélectionnée, si toutes les valeurs prises par ExpressionSelection ne sont pas décrites alors la clause When others doit être décrite. Le bloc G du système précédent peut s'écrire :

With EtatPresent Select S <= '1' When Etat2 | Etat3, -- noter le | pour un ou logique '0' When Etat1 ;

3. Type prédéfinis et opérateurs

Parmi les types prédéfinis nous citerons Integer : type entier (32 bits). l’ intervalle de variation peut être limité. a : IN integer range -128 to 127 ; natural : entiers positifs ou nuls a : IN natural range 0 to 6 ; bit : type scalaire énuméré, deux valeurs possibles 0 et 1 ; bit_vector : vecteur de bits a : IN bit_vector (7 downto 0) ; a(7) est le poids fort, a(0) est le poids faible. Boolean : type scalaire énuméré, deux valeurs possibles FALSE et TRUE ;

Des types complémentaires sont apportés par des bibliothèques ; par exemple les types std_logic et std_logic_vector acceptant les descriptions 0, 1, - (indéterminé)

Ce type est défini dans la bibliothèque ieee et impose l’inclusion des lignes suivantes en en-tête de fichier source :

library ieee ; use ieee-std-logic-1164.all ;

Ce sont ces types que nous utiliserons pour décrire des signaux logiques.

Enfin des types définis par l’utilisateur comme les types énumérés utilisés dans la description de graphe d’états : Exemple : Type Etat Is (etat1, etat2, etat3) ;

Aux opérateurs logiques déjà rencontrés (and, nand, or, nor, xor, not) s’appliquant à des opérandes de type bit, bit_vector et boolean s’ajoutent les opérateurs arithmétiques +, -, *, / s’appliquant à des opérandes de type integer.

Les opérateurs relationnels =, /=, <, <=, >, >= renvoient un résultat booléen. NOTA : VHDL est insensible à la casse des caractères.

Le logiciel Quartus II

1 Création et configuration d'un projet

Pour créer un nouveau projet Quartus, cliquer sur “File/Newproject Wizard”, une fenêtre d'assistance à la création s'ouvre :- la première page permet de choisir le répertoire de travail, le nom du projet et le nom de l'entité principale.- les pages suivantes permettent d'ajouter, si nécessaire, des fichiers existant dans le projet et d'ajouter des outils supplémentaires de conception (aucun dans notre cas).- la quatrième permet de spécifier la famille de FPGA (MAX7000S) et le type de FPGA utilisé (EPM7128SLC84-6). Un filtre permet d'aider la recherche (pin count 84 par exemple permet de sélectionner le bon composant dans une liste réduite).

Il est possible d'avoir une approche de conception descendante (top-down design) ou ascendante (bottom-up design). Nous opterons pour cette dernière approche et nous concevrons et simulerons les différents composants, avant de les exporter et de les intégrer dans une application de plus haut niveau.

2- Conception, simulation, exportation d'un composant.

1- Saisie d'un fichier vhdl

Dans 'File/New' Choisir la fenêtre 'Text editor' puis 'vhdl'. Ou encore si vous disposez d'un fichier modele (exemple modele.vhd), l'ouvrir et le sauver en lui assignant un nom qui correspond au nom de l'entité (Exemple cabine .vhd dans le cas où l'entity a pour nom cabine (ENTITY cabine IS ...))

2- Compilation

– Pour compiler un fichier autre que celui désigné “Top Level entity” , ouvrir ce fichier et cliquer sur 'Project/Set as Top-Level-Entity'.

– Puis “Processing/Start Compilation”. Dans le cas d'erreurs de compilation, cliquer sur un message d'erreur ramène dans le fichier texte (.vhd) où l'erreur a été détectée. Corrigez vos erreurs.

3- Simulation

Cette partie étant délicate, il est conseillé de faire appel à un enseignant lors d'une première simulation.

– Dans “File/New “ choisir l'onglet “Other Files” et sélectionner 'Vector Waveform File'. Un éditeur de chronogramme apparaît. Sauvegardez le fichier : “File/Save” ou “File/Save as ..”

– Pour faire apparaître les signaux à simuler, faire “Edit/Insert/Insert Node or Bus”. Cliquez sur 'Node Finder ' ... Un écran apparaît.

– Si ce n'est pas fait positionnez le filtre sur Pins all et cliquez sur List. Les signaux trouvés s'inscrivent dans la fenêtre gauche (Nodes Found), sélectionnez ceux que vous voulez simuler en les transférant dans la fenêtre droite (Selected Nodes). Cliquez sur OK.

Remarque : Dans le cas de mise en oeuvre de MEFs vérifiez que vous avez accès à l'état présent de votre MEF.

– Les signaux à visualiser apparaissent sur le chronogramme. Il faut assigner des valeurs aux signaux d'entrée, conformément à un scénario.

– Sur sélection du signal d'horloge, une fenêtre de dialogue s'ouvre : On peut préciser la taille de la fenêtre de simulation (1 micro seconde : par défaut), et les paramètres count every : 10ns (par défaut), puis le paramètre multiply by : 1 (par défaut). Changer ce dernier en 2, 3, ou 4. Ceci permettra de ne ne pas avoir des fronts de signaux d'entrée simultanés avec le front actif d'hologe.

– Pour changer localement la valeur d'un signal, sélectionnez avec la souris l'intervalle à modifier et choisir la valeur adéquate (0 ou 1) dans la barre d'outil à gauche. La simulation consiste à définir une suite de changements du vecteur d'entrée du système de commande. Ces changements doivent respecter la logique d'évolution du procédé.

– Sauvegardez et simulez “Processing/Start Simulation”. A la première simulation il est nécessaire de préciser le fichier source de la simulation (.vwf) : pour cela choisir “Processing/Simulator Tool”, une page s'ouvre et dans le champ Simulator input préciser le fichier source. De cette page lancer la simulation (Start) puis ouvrir le rapport (Rapport).

4- Créer un bloc symbolique pour le composant.

Pour pouvoir exporter le composant dans “File” choisir “ Create Symbol Files for current File”.Un fichier “nom_composant.bsf” est créé. C'est ce composant qui sera par la suite inséré dans une application de plus haut niveau.

5 - Les phases précédentes 2, 3, 4 sont à répéter pour tous les composants qui seront ensuite instanciés dans l'application finale.

3- Entité principale du projet : Construction, compilation, chargement.

6- Entité principale du projet :

Nous utiliserons un schéma bloc dans lequel nous connecterons les différents blocs préalablement définis.– Faire “File/New” et choisir 'Block Diagram'. Sauvegarder sous le nom choisi lors de la création du

projet. Une page graphique s'ouvre.

7- Intégration des composants :

– Pour introduire les composants définis lors des étapes précédentes, aller dans “Edit/Insert Symbol ...” et désigner le composant (.bsf) que vous voulez instancier. Autre solution, sur la page graphique, faire un clic droit de la souris pour ouvrir un menu contextuel et choisir ''Insert/symbol”.

– Il faut alors connecter ces blocs entre eux et aux entrées/sorties.

- Pour ajouter les entrées/sorties il faut ouvrir la fenêtre d'ajout de symbole “Edit/Insert Symbol ...”), les symboles d'entrée/sortie sont dans des librairies situées en

C:Quartus/70/librairies puis “primitives/pin”, choisir “input' ou 'output”.Nommer les entrées /sorties. Clic droit sur la broche concernée, puis Properties et dans la zone de saisie “Pin_name” taper le nom.

- Il faut également connecter les composants entre eux. Soit par connexion directe (à l'aide des outils graphiques proposés ou en nommant les fils ou bus en sortie d'un composant et en reprenant ce nom à l'entrée du composant suivant (même démarche que pour nommer les entrées-sorties).

Quand ce travail est terminé, compiler l'application complète.

8- Assignation des broches.

Il faut maintenant spécifier le branchement physique de chaque broche à la carte.Par “Assigments/Pins”, choisir la broche à assigner dans la colonne 'Location'. Un double clic dans la cellule permet de choisir le numéro de broche dans une liste. Se conformer au brochage spécifié dans le texte du TP. Pour le type de circuit utilisé le brochage du signal d'horloge n'a pas à être spécifié (83).

Recompiler avant de télécharger sur la cible !

9- Chargement sur la carte cible :

Choisir “Tools/programmer” . Une fenêtre apparaît. Sélectionner le fichier .pof à télécharger et cliquer sur Start. Après chargement sur la cible, tester le fonctionnement.

Remarques :

1. Des icônes offrent des raccourcis pour invoquer le compilateur, le simulateur, le chargeur.

2. On peut ajouter des fichiers VHDL à un projet “Project->Add/remove Files in Project”. Dans la fenêtre qui s'affiche, ceux-ci sont ajoutés à la liste via 'Add'. Terminer par 'Ok'.

Les fichiers apparaissent alors dans le navigateur de projet (à gauche), sur l'onglet 'Files' dans le dossier 'Device Design Files' on peut créer un bloc symbolique pour chaque composant (.vhd) via le clic droit puis 'Create Symbol Files for Current File'.

Il faut ensuite ouvrir la fenêtre d'ajout de symbole dans l'entité principale (nom_projet.bdf) puis rechercher les blocs par “Edit/Insert symbol” (ou clic droit et Insert symbol).

Annexe IL, ST p.1/5

AANNNNEEXXEE IILL,, SSTT 1. LES AUTOMATES PROGRAMMABLES

Un automate programmable est un calculateur spécialisé dans l'exécution d'opérations logiques. Il est composé d'un processeur, d'une mémoire, de modules d'entrées/sorties et d'un moniteur.

La mémoire contient le programme qui décrit le fonctionnement du système de commande. Les blocs

d'entrées et de sorties assurent la connexion de l'automate avec le procédé à commander. Le moniteur de l'automate (son système d'exploitation en quelque sorte) se charge d'enchaîner de manière cyclique les tâches suivantes :

1. exécution du programme utilisateur, 2. lecture des entrées, 3. écriture des sorties,

le tout en temps réel, c'est à dire qu'un cycle programme (exécution des trois tâches ci-dessus) a une durée compatible avec le temps de réponse du procédé. Un programme manipule des bits et des mots. Il peut être décrit dans un des quatre langages normalisés.

1. Programme GRAFCET (SFC) 2. Programme LADDER (LD) 3. Programme LIST (IL) 4. Programme ST

Dans les séances de manipulation sont utilisés le langage LIST (ou IL) et le langage littéral structuré ST.

Remarque : Le langage à contacts, historique et daté, est rappelé très succinctement ici (on peut éventuellement l’utiliser pour décrire les transitions et les actions du GRAFCET mais on préférera les langages IL et ST plus évolués). Le langage à contacts est un diagramme à relais et peut être interprété comme un schéma électrique. Deux éléments mis en série forment un ET. Deux éléments mis en parallèle forment un OU. Exemple :

Ce diagramme traduit l’expression : ( a + b) . c qui est associée au récepteur M.

2. LE LANGAGE LIST (LISTE D’INSTRUCTIONS)

Le langage IL est un langage de bas niveau bien adapté à la programmation des équations logiques.

Son caractère langage booléen peut être utilisé pour programmer des machines à états à partir des équations logiques des variables d’état et des sorties.

L’automate peut être considéré comme un processeur booléen possédant un accumulateur booléen (acc) auquel se rapportent toutes les instructions du langage.

a

c

b

M

Annexe IL, ST p.2/5

2.1 Présentation du langage LIST (ou langage IL)

Instructions de modification de la valeur de l’accumulateur (l’opérande x est une variable booléenne) Instruction Effet sur l’accumulateur

Chargement : LD x (acc ← x) OU Logique : OR x (acc ← acc + x) ET logique : AND x (acc ← acc . x) OU EXCLUSIF : XOR x (acc ← acc ⊕ x)

Ces quatre instructions peuvent s’appliquer à un opérande complémenté.

Chargement : LDN x (acc ← x ) OU Logique : ORN x (acc ← acc + x ) ET logique : ANDN x (acc ← acc . x ) OU exclusif : XORN x (acc ← acc ⊕ x )

Instructions de stockage de la valeur de l’accumulateur (l’opérande x est une variable booléenne)

ST x (x ← acc) STN x (x ← acc )

Instructions de saut

JMP %Lx (saut inconditionnel à l’étiquette Lx) JMPC %Lx (saut conditionnel (acc = vrai) à l’étiquette Lx) JMPCN %Lx (saut conditionnel (acc = faux) à l’étiquette Lx)

Remarque : les instructions ST, STN, JMP, JMPC, JMPNC ne modifient pas la valeur de l’accumulateur

2.2 Structure d’un programme LIST

Un programme LIST peut comprendre les éléments suivants : 1. un commentaire (* ceci est un commentaire *) 2. une étiquette symbolique %Lx : 3. une liste d’instructions dont la première doit être un chargement (LD) ou un saut inconditionnel (JMP).

Les instructions s’écrivent une instruction par ligne ou un opérateur par ligne.

L’éditeur interprète les instructions au fur et à mesure de leur saisie et signale les erreurs de syntaxe, variables non encore déclarées … en soulignant en rouge les problèmes détectés mais ces avertissements ne sont pas bloquants pour la saisie ou la sauvegarde du fichier. Exemple : soit à programmer l’expression logique y = x1.( x2 + x3) (* calcul de l’expression logique de y *)

%L0 : LD x1 AND( x2 NOT OR x3

) ST y

Noter l’utilisation des parenthèses qui permettent d’exprimer des formes produit de somme sans les

développer. On peut associer des Négations aux parenthèses ouvertes avec AND et OR.

Annexe IL, ST p.3/5

3. LE LANGAGE LITTERAL STRUCTURE ST Une section de programme littéral comporte les éléments optionnels suivants :

- une étiquette qui permet de repérer une phrase (par exemple %L22:) - des commentaires : (* commentaires *) - une à plusieurs instructions séparées par des « ; »

3.1 Présentation du langage ST

INSTRUCTIONS :

Affectation A := expression Choix IF…THEN

Syntaxe forme simple :

IF condition THEN

action_if ;

ELSE action_else ;

END_IF ; Syntaxe forme générale :

IF condition1 THEN

action_if1 ;

ELSIF condition2 THEN

action_if2 ;

ELSE action_else ;

END_IF ; Les conditions peuvent être multiples. Chaque action représente une liste d’instructions. Plusieurs IF peuvent être imbriqués, le nombre de ELSEIF est illimité mais il y a au maximum une partie ELSE (il peut ne pas y en avoir).

Choix multiple CASE…OF Syntaxe : CASE selecteur OF 1: instruction1 ;

2 : instruction2 ;

ELSE instructiondefaut ;

END_CASE ; Le sélecteur est de type entier, si le sélecteur prend une valeur différente des valeurs d’aiguillage, l’instruction suivant la clause ELSE est exécutée.

Boucles FOR Syntaxe :

FOR indice:= valeur_initiale TO valeur_finale DO action ;

END_FOR ;

L’action représente une liste d’instructions. L’incrémentation de l’indice se fait automatiquement. Plusieurs FOR peuvent être imbriqués.

Annexe IL, ST p.4/5

3

/B /A. B

Inter1 S

A

M. /A

2 1

WHILE…DO Syntaxe :

WHILE condition DO action ;

END_WHILE ; La condition peut être multiple. L’action représente une liste d’instructions. Plusieurs WHILE peuvent être imbriqués.

REPEAT…UNTIL Syntaxe :

REPEAT action ;

UNTIL condition

END_REPEAT ; La condition peut être multiple. L’action représente une liste d’instructions. Plusieurs REPEAT peuvent être imbriqués.

L’instruction EXIT permet d’arrêter l’exécution d’une boucle et de continuer sur l’instruction suivant l’instruction fin de boucle. Cette instruction est rattachée à la boucle englobante la plus proche, elle n’arrête pas toutes les boucles qui l’englobent.

Opérateurs

• LOGIQUE : and, not, or, xor

• RELATIONNEL : <, >, <=, >=, =, <>

3.2 Mise en œuvre directe d’une machine à états

Les variables etatpresent et etatsuivant sont de type entier (INT), inter1 est de type booléen (EBOOL) , A, B, S sont des bits d’entrée/sortie (type EBOOL) . (* BLOC F *)

CASE etatpresent OF

1: IF ((not A) and M) THEN etatsuivant := 2;

END_IF;

2: IF (A) THEN etatsuivant := 1;

ELSIF ((not A) and B) THEN etatsuivant := 3;

END_IF;

3: IF (not B) THEN etatsuivant := 1;

END_IF;

ELSE etatsuivant := 1;

END_CASE;

(* bloc M et initialisation de la MEF *)

IF (Inter1) THEN

etatsuivant := 1;

END_IF;

etatpresent := etatsuivant;

(* bloc G *)

S := (etatpresent=2);

Annexe IL, ST p.5/5

4- TEMPORISATIONS Dans un système de commande une temporisation est traitée comme une sortie du système (actionneur) et une entrée de ce système (capteur), un exemple est donné figure suivante avec ActiveTempo (actionneur) et FinTempo (capteur)

Utilisation d'une temporisation dans un graphe d’état.

Le fonctionnement du temporisateur est décrit par le chronogramme suivant (dans le cas d’une mise à 1 de la sortie du temporisateur (entrée du système de commande)

Un temporisateur est une entité prédéfinie de type TON (mise à 1) ou TOFF (mise à zéro), invoquée à partir de son nom (On choisit un nom de variable pour le temporisateur et on déclare cette variable de type TON). Exemple : temporisateur de nom « Tempo1 » déclenché sur l’état 2 (ou en présence de ActiveTempo1 variable de type BOOL, cas IL), de durée préfixée 5s, de sortie FinTempo1, calculé avec une variable interne de type TIME nommée Valeurtempo1. En IL (appel de fonction dans le bloc G) : cal Tempo1 (IN := ActiveTempo1, PT := Time#5s, Q => FinTempo1, ET => Valeurtempo1) En ST (invocation dans le bloc G) : Tempo1 (IN := (etatpresent = 2), PT := Time#5s, Q => FinTempo1, ET => Valeurtempo1) ; Remarque : il est également possible de définir la temporisation en LD (réseau de contacts). Le bit IN du temporisateur de type TON est piloté par ActiveTempo (connecté sur tempo1.IN), la sortie Q du temporisateur (tempo1.Q) est reliée à Fintempo1. Il est nécessaire de définir la durée du temporisateur sur le temporisateur : Ouvrir les Blocs FB prédéfinis, cliquer sur le temporisateur choisi et faire apparaître ses différents champs pour documenter le Preset.

Représentation temporisateur en LD On peut donc être amené dans le cas de mise en œuvre de MEFs à avoir 3 sections IL, ST et LD :

- réalisation des variables internes à partir des équations logiques en IL, - mise en œuvre directe en ST. - le temporisateur en LD.

E2

ActiveTempo FinTempo

Durée temporisation

ActiveTempo

FinTempo

FinTempo1 IN Q

Tempo1 ActiveTempo

travaux pratiquesekladata.com/o1z_ch5lucmbeuc0lsxtqnzkxvk.pdf · electronique electrotechnique...

Documents