III.3. SIMULATION DE LA CHAINE D’EXHAURE DE KIPUSHI
III.3.1. ANALYSE DYNAMIQUE DU SYSTEME AVEC LE LOGICIEL MATLAB/SIMULINK ET INTERPRETATION DES RESULTATS
Le but poursuivi de cette analyse est de répondre aux conditions de
travail définies par le cahier des charges afin de s’assurer du bon fonctionnement du système. Ainsi les caractéristiques telles qu’a la stabilité matérialisée par les marges de gain et de phase, la rapidité par le temps de réponse et la précision seront traitées afin de déterminer les actions du régulateur (choix des paramètres optimum du régulateur).
Etant donné que le système présente un intégrateur naturel qui
annule l’erreur statique, il nous reste qu’à choisir un régulateur qui pourra répondre aux exigences de la stabilité et de la rapidité, sans présenter des dépassements, pour satisfaire au cahier de charge.
De ce fait, un régulateur proportionnel suffit pour corriger le système.
Les analyses fréquentielles dans les différents diagrammes ont été effectuées avec le logiciel Mat lab. / Simulink et les résultats obtenus pour chaque niveau sont présentés ci-dessous:
Niveau 512
Nous avons obtenu lors de nos simulations les résultats suivants :
Un temps de réponse de 13.1 secondes ; Marge de gain 49.2 dB ; Marge de phase de 60 degré.
Nous remarquons que pour la consigne échelon de 2,2 m, nous avons un amortissement de 9,93% en régime transitoire et un bon compromis d’après le cahier des charges.
Nous remarquons aussi qu’en régime permanent, l’erreur statique est bel et bien annulée pour une consigne échelon et notre système est suffisamment stable pour un gain proportionnel P = 15,033 et pour un temps de dérivation TD = 498,79 secondes.
00.511.522.533.54
Temps en secondex 104
Figure 35 – Réponse indicielle au niveau 512
Niveau 710
Un temps de réponse de 18.1 secondes ;
Marge de gain 43.8 dB ;
Marge de phase de 60 degré
Nous remarquons que pour la consigne échelon de 2 m, nous avons un
amortissement de 9,42 % en régime transitoire et un bon compromis d’après le cahier des charges.
Nous remarquons aussi qu’en régime permanent, l’erreur statique est bel et bien annulée pour une consigne échelon et notre système est suffisamment stable pour un gain proportionnel P = 9.8513 et pour un temps de dérivation TD = 821.48 secondes.
05001000150020002500300035004000
Temps en seconde
Figure 36 – Réponse indicielle au niveau 710
Niveau 860
Un temps de réponse de 15.4 secondes ; Marge de gain 40.1 dB ; Marge de phase de 60 degré.
Nous remarquons que pour la consigne échelon de 2.6 m, nous avons un
amortissement de 9,09 % en régime transitoire et un bon compromis d’après le cahier des charges.
Nous remarquons aussi qu’en régime permanent, l’erreur statique est bel et bien annulée pour une consigne échelon et notre système est suffisamment stable pour un gain proportionnel P = 9.163 et pour un temps de dérivation TD = 671.040 secondes
Figure 37 – Réponse indicielle au niveau 860.
Niveau 938.5
Un temps de réponse de 203 secondes ; Marge de gain 23.7 dB ;
Marge de phase de 79.5 degré.
Nous remarquons que pour la consigne échelon de 3 m, le dépassement est annulé et nous avons un bon compromis d’après le cahier des charges.
Nous remarquons aussi qu’en régime permanent, l’erreur statique est bel et bien annulée pour une consigne échelon et notre système est suffisamment stable pour P = 8,5098 (Gain proportionnel).
Figure 38 – Réponse indicielle au niveau 938.5.
Niveau 1166
Un temps de réponse de 23.4 secondes ; Marge de gain 59.5 dB ;
Marge de phase de 60 degré.
Nous remarquons que pour la consigne échelon de 2 m, nous avons un
amortissement de 9.51 % en régime transitoire et un bon compromis d’après le cahier des charges.
Nous remarquons aussi qu’en régime permanent, l’erreur statique est bel et bien annulée pour une consigne échelon et notre système est suffisamment stable pour un gain proportionnel P = 6.5331 et pour un temps de dérivation TD = 403.3318 secondes.
00 0.511.522.53
Temps en seconde4 x 10
Figure 39 – Réponse indicielle au niveau 1166.
III.4.PROGRAMMATION DE LA CHAINE D’EHXAURE SOUS STEP-7 MICRO/WIN
III.4.1.DESCRIPTION DE STEP 7-MICRO/WIN
III.4.1.1. LANGAGE DE PROGRAMMATION
Les langages de programmation(LIST), (LOG) et (CONT), font partie
intégrante du logiciel de base.
La liste d’instructions (LIST) est un langage de programmation textuel proche de la machine. Dans un programme (LIST), les différentes instructions correspondent, dans une large mesure, aux étapes par lesquelles la CPU traite le programme.
Le logigramme (LOG) est un langage de programmation
graphique qui utilise les boites de l’algèbre de Boole pour représenter les opérations logiques. Les fonctions complexes, comme par exemple les fonctions mathématiques, peuvent être représentées directement combinées avec les boites logiques.
Le schéma à contacts (CONT) est un langage de programmation graphique. La syntaxe des instructions fait penser aux schémas de circuits électriques.
Le langage (CONT) permet de suivre facilement le trajet du courant entre les barres d’alimentation en passant par les contacts, les éléments complexes et les bobines.
Un programme (CONT) comprend une barre d’alimentation à gauche qui est alimentée en courant. Les contacts fermés permettent au courant de circuler à travers eux vers l’élément suivant alors que les contacts ouverts bloquent le trajet du courant.
La logique est subdivisée en réseaux. Le programme est exécuté
réseau par réseau, de la gauche vers la droite et de haut en bas.
III.4.1.2. ELEMENTS FONDAMENTAUX D’UN PROGRAMME
a. Bloc de code
Un bloc de code est composé de code exécutable et de commentaires.
Le code exécutable comprend un programme principal, des sous-
programmes et des programmes d’interruption facultatifs. Il est compilé et chargé dans le S7-200 ; ce n’est pas le cas des commentaires de programme.
On peut utiliser les éléments d’organisation (programme principal, sous-programmes et programmes d’interruption) pour structurer un programme de commande.
b. Programme principal
Le programme principal (MAIN), également appelé OB1, contient les opérations qui commanderont notre application. Le S7-200 exécute ces opérations séquentiellement, une fois par cycle.
c. Sous-programmes
Ces éléments facultatifs du programme ne sont exécutés que lorsqu’ils sont appelés : par le programme principal, par un programme d’interruption ou par un autre sous-programme.
Les sous-programmes sont utiles pour exécuter une fonction de manière répétée. Plutôt que de réécrire le code pour chaque endroit du programme principal où la fonction doit être exécutée.
d. Programmes d’interruption
Ces éléments facultatifs du programme réagissent à des événements
d’interruption spécifiques.
Un programme d’interruption est conçu pour traiter un événement d’interruption prédéfini. Le S7-200 exécute le programme d’interruption lorsque cet événement précis se produit.
Les programmes d’interruption ne sont pas appelés par le programme
principal. Etant donné qu’ils sont associés à un événement d’interruption prédéfini, le S7-200 exécute les opérations figurant dans le programme d’interruption uniquement lorsque cet événement se produit.
III.4.1.3. AUTRES ELEMENTS DU PROGRAMME
D’autres blocs contiennent des informations destinées au S7-200 et peuvent facultativement être utilisés lorsque le programme est chargé dans la CPU.
a. La table des mnémoniques
Elle permet de définir et d’éditer des mnémoniques (adressage) accessibles par leur nom symbolique de n’importe quel endroit du programme. On peut créer plusieurs tables des mnémoniques. Un onglet dans la table des mnémoniques permet d’accéder aux mnémoniques systèmes qu’on peut utiliser dans le programme. La table des mnémoniques est également appelée table des variables globales.
b. Bloc de données
Le bloc de données contient les valeurs de différentes variables (mémoire
V) utilisées par le programme. On peut s’en servir pour entrer des valeurs initiales pour les données.
c. Bloc de données système
Il permet de configurer différentes options matérielles pour le S7-200.
d. Table de visualisation d’état
Elle permet de visualiser ou de forcer les valeurs des variables du processus lorsque S7-200 exécute le programme de commande. On peut visualiser l’état des entrées, des sorties et des variables du programme en affichant leur valeur en cours. La table de visualisation d’état permet également de forcer les valeurs des variables du processus.
On peut créer plusieurs tables de visualisation d’état afin de
visualiser des éléments de différentes sections du programme.
III.4.2. CREATION DU PROGRAMME POUR L’AUTOMATISATION DE L’EXHAURE
III.4.2.1. CREATION DE LA TABLE DES MNEMONIQUES
Dans tout programme il faut définir la liste des variables qui vont être
utilisées lors de la programmation. L’utilisation des noms appropriés rend le programme plus compréhensible est plus facile à manipuler. Ce type d’adressage est appelé adressage symbolique.
Figure 40 – Table des mnémoniques
CREATION DU BLOC DE CODE
Dans notre étude d’automatisation, il sera constitué par les sous programmes créés pour la gestion des pompes et par le programme du maître.
CREATION DE SOUS PROGRAMMES
Séquences : contrôle de tous les facteurs pouvant amener les différentes pompes à démarrer ou à s’arrêter.
Pompes : les programmes qui contrôlent tous équipements attachés à chaque pompe, ainsi que les conditions de fonctionnement.
Ainsi, on peut détecter les anomalies que ce soit sur un point de vue matériel ou sur un dispositif de commande.
Il y aura un sous-programme spécifique pour chaque pompe.
Communication : permet d’établir la communication entre les diverses parties des programmes impliquant les systèmes de commande, de démarrage, de redémarrage et d’arrêt suite à un défaut.
MBUS_INIT : fait référence à l’initialisation du protocole Modbus esclave par l’affectation de l’interface 0 à la communication dudit protocole.
L’opération MBUS_INIT permet d’activer et d’initialiser ou bien de désactiver la communication Modbus. Il faut que cette opération s’exécute sans erreurs pour qu’on puisse utiliser une opération MBUS_SLAVE.
MBUS_SLAVE
L’opération MBUS_SLAVE sert à desservir une demande du maître Modbus et doit être exécutée à chaque cycle afin qu’elle puisse rechercher et répondre aux demandes Modbus éventuelles.
MBUS_CTRL
Il existe deux versions de la bibliothèque du protocole Modbus maître. L’une utilise l’interface 0 (port 0) de la CPU et l’autre l’interface 1 (port 1). Pour la bibliothèque de l’interface 1, ”_P1” est ajouté aux noms d’UOP (MBUS_CTRL_P1) afin de signaler que l’UOP utilise l’interface 1 de la CPU. Sinon, les deux bibliothèques Modbus maître sont identiques.
L’opération MBUS_CTRL gère l’affectation de l’interface 0 au protocole Modbus maître. 65
L’opération MBUS_CTRL_P1 (de la bibliothèque de l’interface 1) gère l’affectation de l’interface 1 au protocole Modbus maître.
Il faut que cette opération s’exécute sans erreurs pour qu’on puisse utiliser une opération MBUS_MSG.
MBUS_MSG
L’opération MBUS_MSG (ou MBUS_MSG_P1 pour l’interface 1) sert à déclencher une demande vers un esclave Modbus et à traiter la réponse.
SEQUENCES
Les réseaux 1 et 2 gèrent le démarrage automatique. Lorsqu’il y a contact sur Auto Start, il n’y a pas contact sur autostop. Le démarrage automatique est enclenché par Auto Start et doit donc se maintenir à ce niveau pour être toujours effectif quand on retire la main du bouton poussoir. Nous plaçons également en maintient une temporisation qui conduit au redémarrage du système lorsqu’il n’y a aucune de pompes qui tournent réellement.
Nous contrôlons ensuite la disponibilité de chaque pompe, le réseau 3 nous donne l’exemple des paramètres qui nous amènent à déterminer que la pompe 1 est disponible.
1_S1_Auto : indique que le circuit de la pompe est pris en charge par le circuit automatique ; sinon il serait mis en local pour être enclenché manuellement.
temp_max_M1_S1 : Le moteur est contrôlé en température et il y a un seuil acceptable. Il suffit de définir une valeur qui serait critique pour le moteur ; tant que cette valeur n’est pas atteinte, ça va.
Disj_P1_S1 on : on se rassure que le disjoncteur qui coupe le circuit de la pompe1 est enclenché.
Niveau1_S1 : il est considéré comme niveau alerte. Quand il est atteint, toutes les pompes doivent être disponibles de façon à être réquisitionnées une foi le niveau2 atteint.
1_S1_dispo : La suite chronologique de ces évènements nous amène à la conclusion que la pompe1 de la salle 1 est disponible.
Nous allons ensuite contrôler les mêmes éléments pour les différentes pompes et selon les différentes salles pour déterminer leur disponibilité.
Nous allons ensuite contrôler la disponibilité des pompes de façon à savoir si on peut s’en servir au moment opportun. Pour cela nous allons transformer chaque mémoire contenant les informations relatives à la disponibilité des pompes en mots car les mots sont additionnables dans step7. La somme de tous les mots relatif à la disponibilité nous donne VW0 qui est le nombre de pompes disponibles.
Le niveau 2 fait appel au démarrage de la première pompe ; mais avant cela, nous devons d’abord commander l’ouverture des vannes de sécurités. Et cela se fait à condition d’avoir en plus du niveau, au moins une pompe disponible.
Le démarrage de la première pompe sera conditionné par : Le démarrage auto enclenché, le nombre de pompes disponibles ≥ 1, et enfin le niveau 2 qui correspond au niveau seuil pour lequel on doit commencer l’évacuation de l’eau atteint.
Les conditions de démarrage de la deuxième pompe dépendent, comme pour la première pompe, du démarrage auto, du nombre des pompes qui cette fois est ≥ 2, du niveau qui cette foi est le niveau 3, mais aussi d’une temporisation qui est enclenchée par l’augmentation du niveau.
Tant que le niveau 3 sera maintenu, une temporisation va se déclencher toutes les 60 secondes provoquant ainsi le démarrage d’une nouvelle pompe, si le nombre de pompes disponibles correspond au nombre de pompe voulus.
Apres le démarrage de la quatrième pompe, nous plaçons une temporisation qui va déclencher la fermeture de la vanne de sécurité. Si l’eau continue d’augmenter après que la quatrième pompe soit enclenchée, cela signifie que la situation est critique et pour la sécurité du personnel ainsi que des installations, il faudrait arrêter les venues d’eau ; le temps que la situation se stabilise.
Il peut arriver qu’il y ait un décalage entre le nombre de pompes qui doivent normalement tourner dans certaines conditions et le nombre de pompes qui tournent en réalité dans ces conditions. Nous devons donc déterminer le nombre requis des pompes ainsi que le nombre fonctionnel en vue de les comparer pour rééquilibrer les choses.
Si le nombre de pompes requis est supérieur au nombre de pompe qui tournent en réalité, on commande le démarrage de la prochaine pompe ; en choisissant celle qui a le moins d’heure de marche. Si c’est l’inverse, on demande l’arrêt de la pompe qui a le plus d’heure de marche.
Nous allons donc transformer chaque mémoire contenant les informations relatives au démarrage des pompes en mots afin de les additionner.
VW40 représente le nombre de pompes requis donc qui doivent normalement fonctionner dans les conditions définies.
Chaque mémoire contenant Les informations relatives au fonctionnement des pompes (la confirmation de la marche du moteur de la pompe) va être également transformée en mot et être additionné.
VW2 représente le nombre de pompes qui fonctionnent réellement.
Lorsque VW40 > VW2 et que le démarrage automatique est enclenché, on demande le démarrage de la prochaine pompe qui sera celle qui possède le moins d’heures de marche. Nous devons donc placer un compteur pouvant évaluer le nombre d’heure de marche de chaque pompe en favorisant celle qui a le chrono le moins élevé.
SM0.5 est une impulsion d’horloge qui s’active toutes les 0,5 secondes et se désactive ensuite pendant le même nombre de secondes. C’est donc une commande qui lance le compteur toutes les 0,5 secondes.
Le compteur doit agir séparément pour chaque pompe et être redémarré à la fin du parcours complet de tous les cycles.
Pour le démarrage des pompes, Le cycle de la première pompe sera +1 ; celui de la deuxième sera +3.
Dans l’exemple du réseau 50, le parcours est fixé à + 12. Selon la logique incrémentielle, le dernier cycle sera +11et correspondra à la sixième pompe. Donc après que le cycle complet soit atteint, le bit suivant (+12) enclenche le redémarrage du compteur.
Apres la demande de démarrage de la prochaine pompe, le compteur entame le premier cycle dans lequel il compare le nombre d’heures de marche de la première pompe à celui des autres pompes. Si le nombre d’heure de la pompe1 est inférieur à celui des autres pompes et que la pompe en question est disponible, alors on la démarre. Sinon on recommence les opérations pour les autres pompes et on démarre celle qui est le plus dans les critères.
N.B. le nombre d’heures de marche de chaque pompe est pris dans le sous- programme de chaque pompe.
Lorsque VW40 < VW2, on demande l’arrêt de la pompe qui qui possède le plus d’heures de marche. Nous devons donc placer un compteur pouvant évaluer le nombre d’heure de marche de chaque pompe en favorisant, cette fois, celle qui a le chrono le plus élevé.
Est un contact à front montant ; il permet au courant pour un cycle de circuler à chaque transition de 0 à 1.
Dès que l’arrêt de la pompe devient effectif, le front montant fait passer le signal et le redémarrage du compteur devient effectif.
Après la demande d’arrêt de la pompe, le compteur vérifie le nombre d’heures de marche des pompes par cycle et on arrête celle qui est le plus dans les critères.
OMPES
Nous commençons par l’étude de tous les défauts qui peuvent amener la pompe à s’arrêter.
Le Flow switch est un indicateur de débit.
Dans le réseau 1, le circuit est en automatique et le moteur de la pompe est en marche ;
Il n’y a pas de débit ; nous avons des vibrations excessives.
Une fois le défaut avéré, nous plaçons une temporisation de 60 secondes qui va déclencher l’arrêt de la pompe si ce défaut perdure.
Bien entendu, nous prévoyant une option de redémarrage qui s’enclenche dès que la pompe est à l’arrêt.
Si le circuit est en automatique et que le démarrage de la pompe est enclenché ; si la vanne d’aspiration est fermée, on commande son ouverture.
Pour que la commande de démarrage de la pompe soit effective, la vanne d’aspiration doit être ouverte, les facteurs qui entrainent l’arrêt de la pompe ne doivent pas être enclenchés et la pompe elle-même doit être à l’arrêt.
Le bouton poussoir fait appel à une mémoire ; le maintien de la commande doit donc se maintenir au niveau de cette mémoire.
La commande de démarrage de la pompe enclenche le Démarrage du
moteur.
Quand il se fait par étoile-triangle ou par le biais d’un variateur de vitesse, le
programme ne prévoit qu’une temporisation après l’enclenchement du moteur qui durera le temps nécessaire pour que le moteur atteigne son régime normal.
Actuellement il existe des relais multifonctionnels de marque qui contrôlent tous les paramètres électriques sur ces machines. Ex SIMOCODE, NEWELEC, etc. Il suffit donc de les rattacher à ces relais et de câbler ces relais à l’automate. Ainsi les informations nécessaires pourront être lues le cas échéant.
Après :
Après le démarrage du moteur, si la vanne de refoulement est fermée ; on commande son ouverture.
Si le démarrage se fait par élimination des résistances, chaque temporisation va entrainer une commande d’élimination d’une résistance jusqu’à l’élimination complète de ces dernières.
A la fin de ces opérations nous retrouvons exactement la suite du réseau 15 pour la continuité du programme.
Dès que le moteur s’arrête de tourner on commande la fermeture des vannes de refoulement et d’aspiration.
Nous limiterons les heures de marches de la pompe à 8heures afin de reposer les équipements.
Pour cela nous allons placer un compteur qui va s’enclencher après le démarrage du moteur de la pompe et qui va redémarrer toutes les 8heures.
Le résultat du compteur est traduit sous forme de mot pour être utilisé dans les opérations de STEP 7.
b. LE PROTOCOLE MODBUS
Les opérations Modbus sont installées dans le dossier Bibliothèques de l’arborescence d’opérations de STEP 7- Micro/WIN.
Ces opérations permettent de faire agir le S7- 200 en tant qu’unité Modbus. Lorsqu’on insère une opération Modbus dans le programme, un ou plusieurs sous-programmes associés sont automatiquement ajoutés au projet.
c. LA COMMUNICATION
Le sous – programme de communication permet de faire agir par rapport au protocole Modbus les mémoires qui définissent :
L’enclenchement du système automatique ;
L’enclenchement du système manuel
L’enclenchement du démarrage
L’enclenchement de l’arrêt
Et enfin l’enclenchement du redémarrage
On affecte une mémoire du protocole Modbus à une opération distincte, de sorte que lorsqu’OB1 fait appel à cette opération, elle soit exécutée par le biais du protocole.
Adresse
Le protocole est soit paire
soit impaire. Dans ce cas il est paire
Nbre de cases mémoires maximales
Nbre max des Entrées et des sorties
Nbre d’Entrées analogiques maximales
Délai de transmission
Vitesse de communication
Premier cycle
Activation du protocole ac 1 et désactivation ac 0
Adresse
Le protocole est soit paire
soit impaire. Dans ce cas il est paire
Nbre de cases mémoires maximales
Nbre max des Entrées et des sorties
Nbre d’Entrées analogiques maximales
Délai de transmission
Vitesse de communication
Premier cycle
Activation du protocole ac 1 et désactivation ac 0
CREATION du PROGRAMME principal (OB1)
Adresse de début ; Mémoire initiale
Adresse de début ; Mémoire initiale
L’opération MBUS_INIT doit être exécutée exactement une fois pour chaque modification de l’état de communication. Il faut donc activer l’entrée EN par impulsion par l’intermédiaire d’un élément de détection de front ou il faut exécuter cette opération uniquement lors du premier cycle.
Il faut définir le paramètre Party pour qu’il corresponde à la parité du maître Modbus. Tous les paramétrages utilisent un bit d’arrêt. Les valeurs autorisées sont :
: pas de parité
: parité impaire
: parité paire
Le paramètre HoldStart est l’adresse du début des registres de maintien en mémoire V. Cette valeur est généralement définie à VB0 ; ainsi, le paramètre HoldStart est défini à VB0 (adresse de VB0). Il est possible d’indiquer d’autres adresses de mémoire V comme adresse de début pour les registres de maintien afin que VB0 puisse être utilisé à d’autres endroits du projet. Le maître Modbus peut accéder au nombre MaxHold de mots de mémoire V à partir de HoldStart.
La sortie Done est mise à 1 à l’achèvement de l’opération MBUS_INIT. L’octet de sortie Error contient le résultat de l’exécution de l’opération.
On fait ensuite appel à la communication, puis aux séquences et enfin à chaque pompe.
N.B. Chaque automate sera considéré comme un automate esclave et possédera les caractéristiques décrites ci-haut.
Le maitre sera un programme à part qui pourra appeler et contrôler tous les automates esclaves.
PROGRAMME DU MAITRE
L’opération MBUS_CTRL est exécutée une fois l’opération MBUS_INIT
achevée.
Le protocole Modbus maître ne fonctionnera pas correctement si MBUS_CTRL n’est pas appelé à chaque cycle.
En plus du mode qui active ou désactive le protocole, de la vitesse et de la parité qui doit correspondre à celle de l’esclave, nous avons le paramètre timeout qui représente le temps de réponse en milliseconde de l’esclave.
La sortie Done est mise à 1 à l’achèvement de l’opération MBUS_CTRL et La sortie Error contient le résultat de l’exécution de l’opération.
Au premier cycle, remettre à 0 les mémentos (mémoires) de validation utilisés pour les différentes opérations
On place une temporisation qui initialise un compteur toutes les 0,5 secondes.
Le compteur permet d’évaluer la disponibilité des esclaves et permet d’utiliser la case mémoire adéquates pour la communication avec ces derniers.
Lorsque l’entrée qui initialise le protocole Mbus maitre passe de 0 à 1, mettre à 1 le mémento (plage mémoire) de validation pour la première opération MBUS_MSG
L’opération MBUS_MSG déclenche une demande vers un esclave Modbus lorsque l’entrée EN et l’entrée First sont toutes deux à 1.
L’entrée EN doit rester à 1 jusqu’à ce que le bit Done soit mis à 1.
Le paramètre First ne doit être à 1 que pendant un cycle
Lorsqu’il y a une nouvelle demande à envoyer. L’entrée First sous forme d’impulsion doit être suivie d’un élément de détection de front.
Le paramètre Slave est l’adresse de l’esclave Modbus.
Le paramètre RW indique si ce message constitue une lecture ou une écriture. Les deux valeurs suivantes sont autorisées pour RW : 0 pour la lecture et 1 pour l’écriture Le paramètre Addr est l’adresse Modbus de départ.
Le paramètre Count indique le nombre d’éléments de données à lire ou écrire dans cette demande. Count est le nombre de bits pour les types de données bits et le nombre de mots pour les types de données mots.
Le paramètre DataPtr est un pointeur d’adresse indirect qui pointe sur la mémoire V dans la CPU S7–200 pour les données associées à la demande de lecture ou d’écriture.
La sortie Done est désactivée pendant qu’une demande est envoyée et la réponse reçue.
Elle est mise à 1 lorsque la réponse est achevée ou lorsque l’opération MBUS_MSG a été interrompue en raison d’une erreur.
La sortie Error n’est valable que lorsque la sortie Done est à 1.
Lorsque la première opération MBUS_MSG est achevée, effacer le bit de validation pour la première opération MBUS_MSG et mettre à 1 le bit de validation pour la deuxième opération MBUS_MSG.
Si Error (VB1) n’est pas égal à zéro, mettre la sortie à 1 pour signaler
l’erreur.
Le deuxième mémento de validation est à 1 quand le compteur est incrémenté d’1.
Le memento est également ajusté.
L’opération MBUS_MSG suivante est appelée quand l’entrée qui initialise le protocole est à 1.
Ensuite, toujours effacer le bit de validation pour la dernière opération MBUS_MSG effectuée et, Si Error (VB1) n’est pas égal à zéro, mettre la sortie à 1 pour signaler l’erreur.
