Archives par mot-clé : PcVue

A4A : Exemple d’application app3 – Modbus RTU Maitre

Bonjour,

Le projet « Ada for Automation  » s’enrichit avec l’implémentation d’un Maitre Modbus RTU.

A cet effet, le binding de la libraire libmodbus a été étendu afin de pouvoir en utiliser les fonctions gérant la connexion sur une interface sérielle.

Sur ce binding, l’implémentation du Maitre Modbus RTU est réalisée à l’instar de celle du client Modbus TCP déjà disponible.

La tâche Maitre Modbus RTU exécute cycliquement les commandes organisées dans une table et alimente une zone mémoire protégée par un mécanisme de gestion d’accès concurrent de telle sorte que les données restent cohérentes.

Ainsi, la configuration se fait de manière très similaire en remplissant un tableau de commandes :

-----------------------------------------------------------------------
--                       Ada for Automation                          --
--                                                                   --
--              Copyright (C) 2012-2013, Stephane LOS                --
--                                                                   --
-- This library is free software; you can redistribute it and/or     --
-- modify it under the terms of the GNU General Public               --
-- License as published by the Free Software Foundation; either      --
-- version 2 of the License, or (at your option) any later version.  --
--                                                                   --
-- This library is distributed in the hope that it will be useful,   --
-- but WITHOUT ANY WARRANTY; without even the implied warranty of    --
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU --
-- General Public License for more details.                          --
--                                                                   --
-- You should have received a copy of the GNU General Public         --
-- License along with this library; if not, write to the             --
-- Free Software Foundation, Inc., 59 Temple Place - Suite 330,      --
-- Boston, MA 02111-1307, USA.                                       --
--                                                                   --
-- As a special exception, if other files instantiate generics from  --
-- this unit, or you link this unit with other files to produce an   --
-- executable, this  unit  does not  by itself cause  the resulting  --
-- executable to be covered by the GNU General Public License. This  --
-- exception does not however invalidate any other reasons why the   --
-- executable file  might be covered by the  GNU Public License.     --
-----------------------------------------------------------------------


with A4A.MBRTU_Master; use A4A.MBRTU_Master;
with A4A.Protocols; use A4A.Protocols.Device_Strings;
with A4A.Protocols.LibModbus; use A4A.Protocols.LibModbus;

package A4A.Application.MBRTU_Master_Config is

   --------------------------------------------------------------------
   -- Modbus RTU Master configuration
   --------------------------------------------------------------------

   Config : aliased Master_Configuration :=
     (Command_Number    => 11,

      Enabled           => True,
      Debug_On          => False,
      Task_Period_MS    => 10,
      Retries           => 3,
      Timeout           => 0.2,

      Device            => To_Bounded_String("COM1"),
      Baud_Rate         => BR_115200,
      Parity            => Even,
      Data_Bits         => 8,
      Stop_Bits         => 1,

      Commands =>
        (--                                                Offset Offset   Period
         --     Enabled  Slave                Action Length Remote  Local Multiple Shift
         1  => (   True,     2, Read_Input_Registers,    10,     0,     0,      10,  0),
         2  => (   True,     2,       Read_Registers,    10,     0,    10,      20,  1),
         3  => (   True,     2,      Write_Registers,    20,    20,     0,      30,  2),
         4  => (   True,     3,       Read_Registers,    10,     0,    20,      20,  3),
         5  => (   True,     4,       Read_Registers,    10,     0,    30,      20,  4),
         6  => (   True,     5,       Read_Registers,    10,     0,    40,      20,  5),
         7  => (   True,     6,       Read_Registers,    10,     0,    50,      20,  6),
         8  => (   False,    7,       Read_Registers,    10,     0,    60,      20,  3),
         9  => (   True,     8,       Read_Registers,    10,     0,    70,      20,  4),
         10 => (   False,    9,       Read_Registers,    10,     0,    80,      20,  5),
         11 => (   True,    10,       Read_Registers,    10,     0,   100,      20,  6)
        )
     );

end A4A.Application.MBRTU_Master_Config;

Pour compléter la chose, une application exemple, le sujet de cet article donc, « app3 » est également disponible afin de démontrer ces capacités nouvelles. Elle existe en version ligne de commande et aussi en version GUI.

En voici une image montrant l’état du maitre Modbus RTU en action selon la configuration ci-dessus :

A4A-APP3-GUI-MMasterStatus-Win

On y trouve :

  • l’état du chien de garde entre la tâche principale et la tâche Modbus RTU Maitre,
  • l’état de la connexion au port de communication,
  • l’état de chaque commande, en vert lorsque la communication est établie, en rouge dans le cas contraire et en rouge avec la croix lorsque la commande est désactivée, comme dans les cas 8 et 10

Bien évidemment, lorsque vous rajoutez des commandes à la table, l’interface graphique s’adapte automatiquement et l’état des commandes supplémentaires est ajouté.

Pour les tests, on a utilisé le simulateur d’automate Modbus PLC Simulator qui est bien pratique pour cela.

A4A-APP3-PLCSim

Elle n’est pas belle la vie ?

Cordialement,
Stéphane

A4A : app2 – Hilscher cifX – Interface utilisateur relookée

Bonjour,

Nous avons bien travaillé ces derniers temps sur « Ada for Automation » et nous sommes ravis de pouvoir vous faire part des évolutions suivantes :

L’interface graphique a été relookée en s’inspirant du document :
GNOME Human Interface Guidelines 2.2.3

Notamment, les cadres qui structuraient par trop les vues ont été rendus invisibles, les étiquettes sont maintenant en gras, les items sont alignés avec des groupes de taille, etc.

Vous voudrez bien nous faire part de vos remarques et observations sur le forum, merci d’avance.

Ainsi la vue « Identity », qui fournit des informations sur l’application, devient :

A4A-APP2-GUI-Identity-Win

La vue « General Status » donne pour chaque tâche :

  • l’état du chien de garde, surveillance mutuelle entre la tâche et l’interface graphique,
  • l’état de la tâche elle-même, fonction de l’action de l’utilisateur sur les boutons « Stop » et « Start »,
  • quelques statistiques sur la durée d’exécution, Min, Max et moyenne glissante,
  • et pour la tâche principale, les statistiques concernant l’ordonnancement, c’est à dire le retard entre le moment où la tâche est censée être réveillée et le réel obtenu.

A4A-APP2-GUI-GeneralStatus-Win

Le serveur Modbus TCP intégré bénéficie également d’une UI mise à jour :

A4A-APP2-GUI-ServerStatus-Win

Le binding de l’API cifX Device Driver, l’interface applicative du pilote pour les cartes Hilscher cifX, s’est étoffé. Ce n’est pas encore tout à fait terminé mais on accède aujourd’hui à pas mal de fonctions comme vous pouvez le découvrir ci-dessous :

A4A-APP2-GUI-cifXStatus-Win

Ainsi l’on peut récupérer :

  • les informations concernant le pilote, version et nombre de cartes trouvées sur la machine,
  • celles concernant la carte utilisée, le firmware à l’œuvre,
  • et enfin les informations concernant l’état de la communication elle-même.

On y voit les informations concernant une carte Hilscher cifX PCI PROFIBUS DP Maitre, une cifX 50-DP/ML donc, et la communication est établie avec le radar de mesure de niveau Endress+Hauser, ce que l’on peut constater dans la supervision pcVue :

A4A-APP2-PcVue

N’est-ce pas merveilleux ? 😉

Bien sûr, comme cette interface graphique est commune, l’application exemple App1, qui met en œuvre la scrutation cyclique sur Modbus TCP et déjà décrite dans ces colonnes, ainsi que l’application de simulation App1Simu, se voient elles aussi relookées.

A4A-APP1Simu-GUI-ServerStatus-Win

De plus, l’interface graphique pour les clients Modbus TCP, – la scrutation cyclique ou IO Scanning -, est également opérationnelle.

A4A-APP1-GUI-MClientsStatus-Win

Je profite de cet article pour vous indiquer la sortie en Décembre dernier d’une nouvelle version du DVD pour les solutions de communications Hilscher cifX, comX et netJACK :
Communication Solutions DVD for cifX, comX and netJACK

Vous y découvrirez naturellement de nouvelles versions des documents, logiciels, firmwares, etc… mais également de nouveaux produits dont des cartes cifX munies de deux ports de communication bus de terrain PROFIBUS / CANopen / DeviceNet.

Un document « What’s new » figure sur le DVD dans le répertoire de la documentation.

Cordialement,
Stéphane

A4A : Exemple d’application app2 – Hilscher cifX

Bonjour,

Dans cette deuxième application exemple pour « Ada for Automation » on met en œuvre le « binding » Ada pour le pilote des cartes de communication Hilscher cifX qui avait été présenté ici.

La maquette pour cette application est celle déjà utilisée pour les articles précédents :
cifX : FDT/DTM – Un exemple intéressant
cifX : Mise en œuvre : API – Messages – PROFIBUS DP V1 Class 2
cifX : FDT/DTM – Un exemple intéressant – E+H FieldCare

La partie opérative est donc constituée du niveau en technologie radar de chez Endress+Hauser, le Micropilot M FMR244, du convertisseur PROFIBUS DP/PA de chez Pepperl+Fuchs et une carte PROFIBUS Hilscher cifX-50-DP.

Cette constellation a été configurée avec SYCON.net comme expliqué dans les articles cités.

Pour la partie commande, c’est donc l’application exemple « app2 » qui est en charge de remonter les informations issues du codeur communicant sur PROFIBUS PA vers la supervision PcVue de Arc Informatique en Modbus TCP.

Pour ce faire, on a modifié la tâche « Main_Task » de « A4A.Kernel.Main » en substituant le fichier correspondant pour lui faire gérer la carte cifX PROFIBUS DP avec le firmware Maître au lieu du client Modbus TCP.

Cela montre au passage la facilité avec laquelle vous pouvez adapter l’utilisation du framework à votre besoin.

Le code est bien sûr disponible comme à l’accoutumée :
Télécharger « Ada for Automation »

Le code de cette tâche principale modifié est présenté ci-dessous.

Après avoir démarré les tâches annexes pour la gestion des temporisateurs, celle du serveur Modbus TCP, le pilote cifX est initialisé et ouvert, puis le canal 0 de la carte « cifX0 » est ouvert, il est à présent possible d’utiliser le canal de communication pour lire et écrire les données sur PROFIBUS DP/PA.

Un extrait de ce code disponible dans « app2/src/a4a-kernel-main.adb » :

package body A4A.Kernel.Main is
...
   task body Main_Task is
...
   begin

      Log_Task_Start;

      --------------------------------------------------------------------
      -- Clock Management
      --------------------------------------------------------------------

      Clock_Handler := new Clock_Handler_Task_Type
        (Task_Priority          => System.Default_Priority,
         Task_Itf               => Clock_Handler_Interface'Access,
         Period_In_Milliseconds => 10);
      -- This task manages the real time clock calls
      -- so that the system call does not get overwhelmed
      -- Is that true ? It seems to me because a lot of automation
      -- stuff needs time.

      --------------------------------------------------------------------
      -- Modbus TCP Server Management
      --------------------------------------------------------------------

      MBTCP_Server_Task_Interface.Control.Watchdog_Time_Out_MS := 3000;
      MBTCP_Server_Task := new Server.Periodic_Task
        (Task_Priority  => System.Default_Priority,
         Task_Itf       => MBTCP_Server_Task_Interface'Access,
         Configuration  => A4A.Application.MBTCP_Server_Config.Config1'Access
        );

      A4A.Log.Logger.Put (Who  => My_Ident,
                          What => "Modbus TCP Server created...");

   --------------------------------------------------------------------
   -- Hilscher cifX 0 Management
   --------------------------------------------------------------------

      A4A.Log.Logger.Put (Who  => My_Ident,
                          What => "Initializing cifX Driver...");

      Result := cifX.Driver_Init;
      if Result /= cifX.CIFX_NO_ERROR then
         cifX_Show_Error (Result);
      else
         cifX_Driver_Init_Done := True;

         A4A.Log.Logger.Put (Who  => My_Ident,
                             What => "Opening cifX Driver...");

         Result := cifX.Driver_Open (Driver_Handle'Access);
         if Result /= cifX.CIFX_NO_ERROR then
            cifX_Show_Error (Result);
         else
            cifX_Driver_Open_Done := True;

            A4A.Log.Logger.Put (Who  => My_Ident,
                                What => "Opening cifX Channel...");

            Result := cifX.Channel_Open
              (Driver_Handle          => Driver_Handle,
               Board_Name             => "cifX0",
               Channel_Number         => 0,
               Channel_Handle_Access  => Channel_Handle'Access);

            if Result /= cifX.CIFX_NO_ERROR then
               cifX_Show_Error (Result);
            else
               cifX_Channel_Open_Done := True;
            end if;
         end if;
      end if;
...

On entre ensuite dans le vif du sujet avec la boucle principale qui gère son propre chien de garde avec la tâche qui l’a démarrée, -la fonction principale de l’application-, le chien de garde de la tâche serveur Modbus TCP, puis lit les entrées qui proviennent de la carte cifX, lit celles qui proviennent du serveur Modbus TCP, appelle le programme utilisateur principal si l’état de l’application est « Running » ou remet à 0 les sorties dans le cas contraire et enfin écrit les sorties dans la carte et le serveur Modbus TCP.

      --------------------------------------------------------------------
      -- Main loop
      --------------------------------------------------------------------

      Main_Loop:
      loop
...
         Result := cifX.Channel_IO_Read
           (Channel_Handle => Channel_Handle,
            Area_Number    => 0,
            Offset         => 0,
            Data_Length    => Hilscher_cifx0_Inputs'Length,
            Data_In        => Hilscher_cifx0_Inputs,
            Time_Out       => 10);

         if Result /= cifX.CIFX_NO_ERROR then
            cifX_Show_Error(Result);
         end if;

         Server.Registers_Read
           (Outputs => A4A.Memory.MBTCP_IOServer_Registers,
            Offset  => 0);

         if Task_Itf.Status.Running then
            A4A.Application.Main_Cyclic;
         else
            A4A.Memory.Hilscher_cifx0_Outputs := (others => 0);
         end if;

         Result := cifX.Channel_IO_Write
           (Channel_Handle => Channel_Handle,
            Area_Number    => 0,
            Offset         => 0,
            Data_Length    => Hilscher_cifx0_Outputs'Length,
            Data_Out       => Hilscher_cifx0_Outputs,
            Time_Out       => 10);

         if Result /= cifX.CIFX_NO_ERROR then
            cifX_Show_Error(Result);
         end if;

         Server.Inputs_Registers_Write
           (Inputs => A4A.Memory.MBTCP_IOServer_Input_Registers,
            Offset => 0);

...

Tout à une fin, cette tâche peut être terminée par un Ctrl+C ou le bouton « Quit ».
On referme tout proprement avant de se terminer.

...
      end loop Main_Loop;

      if cifX_Channel_Open_Done then
         A4A.Log.Logger.Put (Who  => My_Ident,
                             What => "Closing cifX Channel...");

         Result := cifX.Channel_Close (Channel_Handle);
         if Result /= cifX.CIFX_NO_ERROR then
            cifX_Show_Error (Result);
         end if;

         cifX_Channel_Open_Done := False;
      end if;

      if cifX_Driver_Open_Done then
         A4A.Log.Logger.Put (Who  => My_Ident,
                             What => "Closing cifX Driver...");

         Result := cifX.Driver_Close (Driver_Handle);
         if Result /= cifX.CIFX_NO_ERROR then
            cifX_Show_Error (Result);
         end if;

         cifX_Driver_Open_Done := False;
      end if;

      if cifX_Driver_Init_Done then
         A4A.Log.Logger.Put (Who  => My_Ident,
                             What => "Deinitializing cifX Driver...");

         cifX.Driver_Deinit;

         cifX_Driver_Init_Done := False;
      end if;

      A4A.Log.Logger.Put (Who  => My_Ident,
                          What => "finished !");
      Task_Itf.Status.Terminated (Task_Itf.Control.Quit);
      Main_Task_Created := False;

   end Main_Task;

Le code du programme utilisateur est des plus simples puisqu’il ne fait que transférer les données du capteur vers la supervision. Tout est dans le dossier « app2 ».

La tâche principale appelle donc la procédure principale du programme utilisateur, « A4A.Application.Main_Cyclic ».
Cette procédure est dans le paquetage « A4A.Application » et définie dans le fichier « app2/src/a4a-application.adb » :

with A4A.Memory; use A4A.Memory;

with A4A.User_Objects; use A4A.User_Objects;
with A4A.User_Functions; use A4A.User_Functions;

package body A4A.Application is

   procedure Main_Cyclic is
      My_Ident : String := "A4A.Application.Main_Cyclic";
   begin

      Map_Inputs;

      Map_HMI_Inputs;

      null;

      Map_Outputs;

      Map_HMI_Outputs;

   end Main_Cyclic;
...

Cette procédure principale appelle à son tour les fonctions et procédures utilisateur ici définies dans le paquetage « A4A.User_Functions » dans le fichier « app2/src/a4a-user_functions.adb ». Pour ce programme exemple, seule la procédure « Map_HMI_Outputs » fait quelque chose d’utile, recopier les octets dans le bon ordre au bon endroit :

...
   procedure Map_HMI_Outputs is
   begin

      Bytes_To_Word (LSB_Byte => Hilscher_cifx0_Inputs(1),
                     MSB_Byte => Hilscher_cifx0_Inputs(0),
                     Word_out => MBTCP_IOServer_Input_Registers(1));

      Bytes_To_Word (LSB_Byte => Hilscher_cifx0_Inputs(3),
                     MSB_Byte => Hilscher_cifx0_Inputs(2),
                     Word_out => MBTCP_IOServer_Input_Registers(0));

      Bytes_To_Word (LSB_Byte => Hilscher_cifx0_Inputs(4),
                     MSB_Byte => 0,
                     Word_out => MBTCP_IOServer_Input_Registers(2));

   end Map_HMI_Outputs;
...

Il existe une version de l’application en ligne de commande et une avec interface graphique.

L’interface graphique est pour l’instant identique à celle de l’application exemple « app1 » déjà évoquée ici :
A4A : app1 – Interface graphique

Voici une vue montrant l’état général :

A4A-APP2-GUI 00

Celle-ci montre l’état du serveur Modbus TCP sur lequel est connectée l’application de supervision PcVue :

A4A-APP2-GUI 01

La supervision est succincte, on y trouve la mesure et l’état remontés, ce qui suffit à ma démonstration :

A4A-APP2-Syno 00

Cette application où l’on surveille des données process à évolution lente est tout à fait représentative du type d’application que vous pouvez traiter avec « Ada for Automation » sur une machine standard, le débit de la communication sur PROFIBUS PA plafonnant à 45 kbds.

Ainsi votre aire de stockage ou votre dépôt pétrolier sera bien surveillé… 😉

Cordialement,
Stéphane

A4A : app1 – Interface graphique

Bonjour,

Recevez mes meilleurs vœux pour cette nouvelle année !

Jusqu’à présent votre application « Ada for Automation » ne disposait que d’une maigre interface en ligne de commande.

Bien sûr, il était déjà possible de s’y connecter via le serveur Modbus TCP et de réaliser une interface graphique évoluée avec PcVue de Arc Informatique par exemple comme démontré ici.

L’interface en ligne de commande est certes un peu frustre mais a des avantages :

  • votre application ne nécessite pas de matériel (écran, clavier, souris) ni de bibliothèque supplémentaire, c’est parfait si vous installez la CPU qui exécute celle-ci dans une armoire ou un coffret électrique,
  • elle est moins lourde, sur de petites configuration ça compte,
  • et elle est plus simple, ce qui est un avantage important quand on débute.

Mais l’interface graphique c’est quand même sympathique. Elle permet une interaction utilisateur – application bien plus riche et une prise en main plus rapide.

Vous en rêviez, c’est aujourd’hui disponible ! 😉

– Hein ?
Oui ça marche sous Linux comme sous Windows® car l’on utilise le binding Ada de la bibliothèque GTK+, GtkAda.

– GTK+ 2 ou 3 ?
Pour l’instant GTK+ 2. Sous Debian Linux, le binding Ada GTK+ 3 n’est pas encore disponible. Et sous Windows® il est encore un peu jeune.

Donc, sous Windows® j’installe la version 2013 de GNAT et la version 2012 de GtkAda depuis :
http://libre.adacore.com/

Et ça ressemble à quoi ? Hé bien à ceci :

A4A-APP1-GUI 00

On y trouve des boutons :

  • Quit : l’équivalent du Ctrl+C disponible dans l’application en ligne de commande, qui permet de quitter l’application proprement.
  • Stop : arrête le traitement du programme utilisateur. Cela n’interrompt pas les tâches de communication qui continuent donc de s’exécuter. Les sorties sont cependant mises à 0.
  • Start : démarre le traitement du programme utilisateur.

Et des onglets présentant :

  • l’identité de l’application,
  • l’état général de celle-ci,
  • l’état du serveur Modbus TCP,
  • l’état des clients Modbus TCP, (pas encore terminé)

L’état général ci-dessous montre l’application au démarrage. Le programme utilisateur est à l’arrêt, ce qui est signalé par les deux loupiotes rouges, la première, verte ici, indique que le chien de garde de la tâche n’est pas déclenché.

On y voit également la date et heure à laquelle l’application a été démarrée ainsi que la durée d’exécution.

A4A-APP1-GUI 01

Ci-après, le programme utilisateur est démarré, les loupiotes sont toutes vertes. Sont également présentées les informations concernant la configuration des tâches et des statistiques qu’il faut prendre avec des pincettes comme toutes les statistiques.

Ainsi les valeurs mini et maxi de la durée d’exécution des tâches sont indicatives. En effet, elles peuvent être préemptées par le système d’exploitation et donc le maxi est très approximatif.

La moyenne est une moyenne glissante calculée sur 256 échantillons. Au bout d’un temps, fonction de la période affectée, elle donne une valeur plutôt correcte.

Les données concernant l’ordonnancement donnent une idée du comportement plus ou moins temps réel selon le système d’exploitation utilisé et la charge système.
Ces mesures montrent l’écart entre le temps de réveil de la tâche programmé et le réalisé.

Sous Windows®, c’est pas terrible, comme attendu, mais ça convient pour beaucoup d’usages cependant.

A4A-APP1-GUI 02

Ci-dessous, la vue présente l’état du serveur Modbus TCP intégré. On y trouve le nombre de clients Modbus TCP connectés et les compteurs des requêtes servies.

A4A-APP1-GUI 03

Enfin, les logs sont toujours affichés dans la fenêtre de démarrage de l’application.

A4A-APP1-GUI 04

Pour terminer, voici une démonstration sous Debian Linux (Sid). Ce qui frappe, hormis l’esthétique plutôt réussie à mon goût, c’est la qualité de l’ordonnancement.
Attention aux conclusions hâtives, ce n’est pas du tout la même machine cependant, des années les séparent. Il faudrait que je réalise un test sous Windows® 7

A4A-APP1-GUI-05

N’hésitez pas à vous inscrire et participer sur le forum :
http://forum.slo-ist.fr

Cordialement,
Stéphane

A4A : app1 – Spécifications Fonctionnelles

Bonjour,

Je vous ai déjà présenté rapidement cette application exemple « app1 » pour « Ada for Automation » ici.

Voici ci-après les spécifications fonctionnelles de cette application.

Objet

Cette application a pour objet la gestion automatique de l’arrosage du jardin de Beau Papa.

Description

Une cuve stocke les eaux pluviales récupérées du toit de la maison, de l’ordre de 700 à 900 litres par mètre carré et par an dans la Loire.

La cuve peut-être alimentée par le réseau municipal pour pallier un déficit de précipitations, une électrovanne normalement fermée commande le débit.

Le jardin est desservi par un système de tuyaux et une pompe de refoulement.

La cuve est équipée :

  • d’un capteur de niveau fournissant une mesure analogique numérisée,
  • d’un capteur de niveau TOR haut, dont l’information est utilisée pour couper l’électrovanne d’alimentation en eau, pour ne pas remplir l’étang en contrebas,
  • d’un capteur de niveau TOR bas, dont l’information est utilisée pour couper l’alimentation de la pompe pour la protéger d’un fonctionnement à vide.

L’information de niveau analogique est traitée pour fournir les seuils d’automatisme, avec une hystérésis, les seuils étant utilisés pour la gestion des actionneurs :

  • XHH : ferme l’électrovanne,
  • XH :
  • XL : ouvre l’électrovanne,
  • XLL : arrête la pompe.

Les informations des capteurs de niveau TOR (SL et SH) sont disposés d’une part dans la chaine de commande des actionneurs (fonction de sécurité) et, d’autre part, remontent à l’automatisme pour la génération d’alarmes correspondantes.

On a : SL < XLL et SH > XHH

La vanne est instrumentée, deux fins de course, ouvert et fermé, sont remontés.

Le contacteur de la pompe dispose d’un retour d’information.

Modes de marche

L’installation possède deux modes de marche, le mode manuel et le mode automatique.

La sélection du mode de marche se fait sur le tableau de commande via un commutateur.

Le mode manuel permet le test de l’installation ou le remplissage de la cuve par anticipation.

Mode manuel

La vanne peut être pilotée par l’intermédiaire des commandes disponibles sur l’IHM.
Le seuil XHH ferme la vanne.

La pompe peut également être pilotée par l’intermédiaire des commandes disponibles sur l’IHM.
Le seuil XLL arrête la pompe.

Mode automatique

L’arrosage est démarré selon un horaire et en fonction de capteurs d’humidité. (en version ultérieure car pas assez de variables au niveau IHM…)

Lorsque l’arrosage est en marche, le seuil XL déclenche l’ouverture de la vanne, le seuil XHH la fermeture de celle-ci.

La pompe est mise en service durant l’arrosage tant que le seuil XLL est couvert.

Interface Homme – Machine

L’IHM affiche les données remontées de l’automatisme, état des entrées et sorties, alarmes, courbe de tendance sur le niveau et permet le pilotage des organes en mode manuel.

Il permet également le réglage de l’horaire d’arrosage.

Tableau de commande

On trouve sur ce tableau un commutateur Auto / Manu et un bouton poussoir pour l’acquittement des défauts.

Instrumentation

Un transmetteur de niveau ou LT (Level Transmitter, LT10)
Un détecteur de niveau ou LS (Level Switch, LS11) avec un seuil haut SH,
Un détecteur de niveau ou LS (Level Switch, LS12) avec un seuil bas SL.

Entrées / Sorties

Entrées Numériques

Level Transmitter LT10

Entrées Tout ou Rien

LS11_SH
LS12_SL
Pump13_FB, retour contacteur pompe
V14_ZO, fin de course position ouverte électrovanne
V14_ZF, fin de course position fermée électrovanne
Auto, commutateur Auto / Manu
Manu, commutateur Auto / Manu
Ack_Fault, bouton poussoir Acquit Défaut

Sorties Tout ou Rien

P13_Coil, bobine contacteur pompe
V14_Coil, bobine électrovanne

Interface Homme – Machine

IHM => Automate

Les commandes Manu des pompe et vanne.

Automate => IHM

Les états des capteurs et actionneurs.

Simulation

A défaut de partie opérative, une application de simulation sera développée pour les tests, la réception et la formation des utilisateurs. 🙂

Cordialement,
Stéphane