I/O Drivers Guide de référence - Supervision et de contrôle à base de XML à partir de Windows Vista à Windows CE

 
I/O Drivers Guide de référence - Supervision et de contrôle à base de XML à partir de Windows Vista à Windows CE
Supervision et de contrôle à base
de XML à partir de Windows Vista à
Windows CE

I/O Drivers Guide
de référence

                      Cod. DOCS 11 DRV-E Build 1101
I/O Drivers Guide de référence - Supervision et de contrôle à base de XML à partir de Windows Vista à Windows CE
Table des matières
1. INTRODUCTION ........................................................... 3
  1.1. INTRODUCTION AUX DRIVERS ....................................................... 3
  1.2. DRIVERS DANS LES PROJETS ........................................................ 3
  1.3. LIAISONS AVEC LES ZONES MÉMOIRES .............................................. 5
  1.4. ADRESSAGE DYNAMIQUE ............................................................. 6
  1.5. ADRESSAGE PAR TÂCHES ............................................................. 7
  1.6. INSTALLATION D'UN DRIVER ......................................................... 8
  1.7. DUPLICATION DE DRIVER ............................................................ 9
  1.8. DÉMARRAGE DES DRIVERS ......................................................... 10
  1.9. ERREURS HARD SUR RS232 ...................................................... 11

2. PARAMÉTRAGES GÉNÉRALES ..................................... 13
  2.1. DÉBOGAGE .......................................................................... 15

3. PARAMÉTRAGES D'UNE STATION ............................... 17
  3.1. STATIONS............................................................................ 17
  3.2. PROPRIÉTÉS GÉNÉRALES DES STATIONS ......................................... 17
  3.3. PARAMÉTRAGE DES PORTS SÉRIE .................................................. 19
  3.4. TAILLE BUFFER ...................................................................... 19
  3.5. TIMEOUTS ........................................................................... 20
  3.6. PROPRIÉTÉS DU SERVICE BRIDGING .............................................. 20
  3.7. PROPRIÉTÉS TAPI .................................................................. 22
  3.8. PROPRIÉTÉS TCP/IP ............................................................... 24
  3.9. PROPRIÉTÉS RAS ................................................................... 25
  3.10. CONFIGURATIONS SPÉCIALES TAPI ET RAS ................................... 26

4. PARAMÉTRAGES D'UNE TÂCHE DE COMMUNICATION. 27
  4.1. LES TÂCHES ......................................................................... 27
  4.2. LES TÂCHES STATIQUES ............................................................ 27
  4.3. LES TÂCHES DYNAMIQUES .......................................................... 30

5. IMPORT DE LA BASE DE DONNÉES ÉQUIPEMENT ....... 35
  5.1. DESCRIPTION DES ERREURS ....................................................... 37
  5.2. A PROPOS DE ........................................................................ 43

                                                                                                 2
1. Introduction

 1.1. Introduction aux Drivers
   Les sujets traités dans cette partie concernent le paramétrage qui doit être effectué sur les drivers de
   communication de Superviseur, présents dans la ressource BD Temps réel de chaque projet
   Superviseur.
   Les drivers sont des bibliothèques dynamiques (fichiers .DLL) qui, selon une logique évènementielle,
   transfère l'information reçue des zones mémoires de l'équipement connecté aux zones mémoires de
   Superviseur et vice versa, selon des paramétrages prédéterminés.
   En utilisant les paramètres du Driver vous pouvez définir des associations entre les variables du
   terrain et les variables de Superviseur. Le système, en utilisant un port série, un bus de terrain ou un
   réseau, lit et écrit des variables sur les équipements, selon les modalités définies.

   La technologie Multi Thread, adoptée par les drivers Superviseur, est utilisée pour échanger
   l'information avec les équipements de terrain de façon la plus efficace possible, en gérant
   l'optimisation de la communication automatiquement selon l'utilisation effective des variables dans le
   projet en cours d'exécution.
   En fait, seulement les variables du système effectivement en cours d'utilisation seront
   échangées avec les équipements terrain, laissant au driver le soin d'optimiser et de construire une
   communication la plus efficace possible.

   Les Drivers Superviseur ont été améliorés pour rendre la communication beaucoup plus puissante et
   évolutive.
   Grâce aux fonctions qui sont communes à tous les drivers, vous pouvez arriver à :

     1.   Une communication optimisée et performante
     2.   Ce que les Liens aux adresses API soient gérés directement dans des Variables ou
          indirectement par des 'Tâches'
     3.   Une configuration en Runtime par des scripts VBA
     4.   L'import automatique de la base de données des équipements
     5.   Etablir un pont pour permettre un accès transparent aux équipements externes via un
          modem (c'est-à-dire. le télé service)
     6.   Utiliser les fonctions TAPI pour permettre des appels automatiques d'équipements séries
          distants via un modem
     7.   Utiliser les fonctions RAS pour permettre des appels automatiques d'équipements Ethernet
          distants via un modem
     8.   Déboguer la communication avec des fonctions avancées
     9.   Un test du câble de communication immédiat et direct

 1.2. Drivers dans les Projets
   Un projet Superviseur est construit avec un jeu de ressources et d'objets qui une fois compilés et
   exécutés en Runtime, gère l'information, les interfaces VBA et utilisateur comme souhaité.
   La communication avec les équipements de terrain est déterminée par l'utilisation de Drivers de
   Communication (aussi avec la technologie OPC). Les Drivers, sous formes de bibliothèques

                                                                                                         3
D R I V E R S _ D E _ C O M M U N I C A T I O N

    dynamiques, ont pour tâche de lire et écrire les zones mémoires de l'équipement connecté dans les
    zones mémoires gérées par le projet.

               Par exemple, en utilisant des API le driver utilise le protocole de communication
               fournit par l'équipement pour lire ou écrire des zones mémoire de l'API vers le
               superviseur et vice versa, selon les configurations des jeux de données définies
               dans les propriétés du driver et/ou dans les propriétés des variables du projet
               Superviseur.

    Les zones mémoire dans lesquelles le driver peut lire ou écrire ainsi que les méthodes de
    transmission sont déterminées par les constructeurs d'équipements, donc les instructions fournies
    pour un équipement spécifique auquel vous voulez vous connecter doivent être tout d'abord lues.

              Lire soigneusement et suivre les spécifications données par les
              constructeurs de l'équipement pour connecter et associer des données
              entre l'équipement et le superviseur.

    Indépendant du protocole et des constructeurs de matériel, les drivers de Superviseur permettent au
    programmeur d'utiliser la même interface utilisateur pour configurer et paramétrer la communication
    selon les possibilités de configuration proposées.

    La structure d'un driver de communication de Superviseur est décrite dans le croquis ci-dessous :

    Selon le schéma illustré ci-dessus, le driver gère le protocole de communication à un niveau bas.

      1.   Le driver nécessite la définition des paramètres de communication principaux en utilisant les
           concepts de 'Station' (des paramètres complémentaires sont définis selon si vous traitez un
           driver série ou un driver réseau)
      2.   Au moyen de l'utilisation du concept de "Tâches", le driver installe une association 'indirecte'
           entre les adresses de l'équipement et les variables du projet Superviseur. Les tâches offrent
           la possibilité de communiquer avec des blocs de données, en définissant une variable (ou un
           groupe de variables) en association à l'adresse de l'équipement (ou l'adresse de début). De
           cette façon l'utilisateur peut configurer des liens avec les zones mémoires de l'équipement
           dans un mode indirect et donc indépendamment du projet.
      3.   En utilisant le concept de l''Adresse Dynamique', le driver permet une association directe
           de l'adresse mémoire avec les propriétés des Variables du projet. De cette façon la variable
           pilote directement l'adresse des équipements, laissant au driver le soin de créer
           dynamiquement les tâches de communication qui sont toujours gérées de façon optimisée.
      4.   Le driver travaille toujours avec "la Base de données temps réel" du projet de supervision.
           Une variable est donc associée directement (propriété des Variables) ou indirectement
           (Tâches). En tout cas la communication est optimisée selon le concept des 'Variables en cours
           d'utilisation'

4
I N T R O D U C T I O N

      5.    La configuration du driver est sauvegardée dans des fichiers XML du 'dossier Ressources' du
            projet. Les fichiers sont basés sur le métalangage XML, comme du reste tout le projet, pour
            une transparence maximale. Les fichiers du driver sont :
             .drvsettings = fichiers contenant les paramètres généraux du driver
             .dynsettings = fichiers générés au démarrage du Runtime avec les
            caractéristiques des tâches dynamiques calculées.

                Les Drivers de Superviseur sont des librairies qui peuvent aussi être utilisées
                indépendamment des projets Superviseur, ce qui signifie qu'ils peuvent aussi
                être insérés dans d'autres environnements de programmation qui sont
                compatibles avec la technologie ActiveX.

1.3. Liaisons avec les zones mémoires
    Les variables de la BD temps réel de Superviseur sont chargées dynamiquement dans la mémoire du
    PC, indépendamment des techniques de communication utilisées. La configuration des zones
    mémoires du superviseur est paramétrée dans les 'propriétés générales' de chacune des variables.
    Les variables peuvent être chargées dans deux zones de données différentes, la zone de données
    définie comme 'Mémoire non partagée' (proposée par défaut) et la zone de données définie
    comme 'Mémoire partagée'.

Zone 'Non partagée' du Superviseur
   La zone de données 'Non Partagée' est la zone proposée par défaut en créant des Variables dans le
   projet Superviseur. Quand les zones Non Partagées sont utilisées, le superviseur décide comment et
   où ses Variables sont allouées en mémoire.
   De cette façon l'utilisateur ne doit pas s'inquiéter de l'allocation des variables, ni où Superviseur les
   alloue en Runtime. Cela évite à l'utilisateur de devoir définir des adresses supplémentaires
   nécessaires pour des liens éventuels aux équipements.
   D'habitude ce choix est fait de préférence pour éviter d'allouer des données incorrectes à l'intérieur
   du superviseur. Superviseur gère automatiquement son information intérieure et communique avec
   le driver seulement quand la variable est connectée à l'équipement.

Zone 'Partagée' du Superviseur
   La zone de données 'Partagée', quand elle est sélectionnée, vous permet de définir l'allocation des
   données dans les zones mémoires du superviseur, indépendamment du driver de communication. La
   sélection de cette zone exige obligatoirement que le programmeur définisse la zone et
   l'adresse absolue de la Variable dans la mémoire du superviseur.
   Donc le programmeur doit être très prudent pour définir une adresse correcte afin d'éviter de
   superposer d'autres variables dans la mémoire par erreur.

                                                                                                          5
D R I V E R S _ D E _ C O M M U N I C A T I O N

     La zone Partagée nécessite la sélection d'un Type de Zone parmi celles qui suivent :

       1.   Input/zone d'adresses des entrées
       2.   Output/zone d'adresses des sorties
       3.   Flag/zone des adresses internes

     Indépendamment du type de zone sélectionnée, vous pouvez échangez les variables de la zone
     partagée en utilisant les fonctions de Entrées, Sorties ou Entrées/Sorties

Lien avec l'équipement
   Une tâche définit le lien entre les variables du Superviseur et les zones de mémoire de l'équipement.
   Le Superviseur permet de réaliser les tâches de communication de deux façons différentes : Tâches
   statiques et Tâches dynamiques :

     Tâches dynamiques : Tâches créées automatiquement par le driver au démarrage du projet sur la
     base du lien paramétré dans la propriété "Adresse physique I/O" des variables du projet. Dans ce
     cas, ce sera le driver qui gèrera le regroupement des variables afin d'optimiser au mieux la
     communication.

     Tâches statiquesTâches définies par le programmeur qui devra établir les paquets de variables à
     échanger et les paramètres de communication.

1.4. Adressage Dynamique
     Superviseur permet de spécifier directement l'adresse de l'équipement dans les propriétés générales
     de la Variable, dans la ressource de la Base de données temps réel du projet. En utilisant cette
     technique, le driver génère des tâches de communication en dynamique, selon l'optimisation et les
     concepts prédéterminées de regroupement des données. Au démarrage du projet le driver génère en
     réalité un certain nombre de tâches adaptées en groupant des blocs de données et en
     communiquant seulement quand les variables sont utilisées dans le projet.
     Pour définir une adresse en mode dynamique, vous avez besoin de :

       1.   Sélectionner 'l'Adresse Dynamique' dans les propriétés générales de la variable
       2.   Sélectionner l'Onglet Drivers de communication de la Fenêtre Explorateur
       3.   Double cliquer dans la liste sur le driver souhaité. La fenêtre pour définir l'adresse apparaît
       4.   Spécifier l'adresse mémoire de l'équipement
       5.   5.Spécifier le type de gestion des données (lecture, écriture ou les deux) dans le champ
            "Type".

     La sélection de l'adresse relative à l'équipement peut aussi être faite en spécifiant la syntaxe
     d'adressage directement selon :

             [DRV].Sta=< Nom de station>|Addr=< Adresse équipement>

                Néanmoins, vous devrez vous référer à l'information spécifique relative
                à l'adressage de chaque Driver.

Concepts tâches dynamiques
   Comme mentionné ci-dessus, Superviseur crée dynamiquement un certain nombre de tâches
   nécessaires à la gestion de la communication au démarrage du projet.
   Le "Seuil Minimal", dans la propriété du driver, est le paramètre qui détermine la génération de
   tâche automatique. Ce paramètre définit la valeur minimale du seuil de fragmentation pour la
   génération d'un certain nombre de tâches.

     Par exemple :

                     VAR00001   est   liée   à   l'adresse   mot 0 de l'équipement
                     VAR00002   est   liée   à   l'adresse   mot 3 de l'équipement
                     VAR00003   est   liée   à   l'adresse   mot 12 de l'équipement
                     VAR00004   est   liée   à   l'adresse   mot 18 de l'équipement

 6
I N T R O D U C T I O N

  Le paramètre 'Seuil Minimal' est défini à 5 par défaut. Dans cet exemple quand le projet démarre, le
  driver crée dynamiquement le fichier XML '.dynsettings' dans le dossier des 'Ressources' du projet,
  dans lequel la génération de 2 tâches dynamiques est calculée pour le driver.
  Dans la première tâche les mots 0 à 3 sont lus, dans la deuxième tâche (qui est nécessaire parce que
  le mot suivant à lire est à une adresse qui excède 5 octets comme indiqué par le paramètre 'Seuil
  Minimal') les mots 12 à 18 sont lus.
  Si, cependant, nous définissons le paramètre 'Seuil Minimal' à 20, le driver crée dynamiquement au
  démarrage du projet une seule tâche en lisant du mot 0 au mot 18.

            Le nombre de tâches générées automatiquement dépend de la valeur
            mise dans le paramètre 'Seuil Minimal'.

  Les variables associées au driver en mode 'dynamique' sont automatiquement gérées par défaut en
  lecture - écriture par le driver. Le driver décide s'il faut gérer seulement en écriture ou en lecture -
  écriture selon les possibilités offertes par la zone de l'équipement associé. De plus ce paramètre peut
  être modifié par le fichier XML '.dynsettings' généré automatiquement au début de l'exécution du
  projet. Les données dans le fichier XML suivant le type d'exécution sont comme suit :

           où il est possible de changer la valeur par défaut 1 avec les valeurs suivantes :
          0 = Entrée
          1 = Entrée-sortie
          2 = Exception sur Var de Sorties
          3 = Continue sur Var de Sorties

1.5. Adressage par tâches
  Superviseur permet l'association entre les adresses d'un équipement et les adresses des variables de
  la Base de données temps réel du projet en mode indirect au moyen de l'utilisation des tâches. En
  utilisant cette technique, le driver demande que l'association entre les variables définies dans le
  projet et les zones mémoires de l'équipement soit spécifiée dans les propriétés de configuration de
  chaque Tâche. En plus de cela le type de communication doit aussi être défini (lecture, écriture, ou
  les deux).
  La liste des tâches ainsi créée est sauvegardée dans le fichier XML "drvsettings" reste donc
  indépendante du projet.

  Pour insérer et configurer les tâches, vous avez besoin de :

    1.   Sélectionner l'onglet Tâches dans les paramètres du driver
    2.   Insérer une nouvelle Tâche en utilisant le bouton 'Ajouter'
    3.   Configurer les propriétés de la tâche selon les pré requis d'échange des données
    4.   Confirmer avec OK et faire une autre tâche si nécessaire

            Note Importante : pour définir une liste de variables dans une tâche qui
            soit liée à une adresse de départ dans l'équipement, vous devez saisir
            les noms des variables, séparées par le caractère ';' dans la propriété
            Variables.

  Une tâche créée à travers cette procédure peut inclure une ou plusieurs variables qui devront être du
  même type (ex. toutes Mot, toutes Float, etc.) et lire/écrire une zone consécutive de la mémoire du
  PLC. L'adresse de départ à spécifier dans la tâche sera l'adresse de la première variable à lire sur le
  PLC, qui sera ainsi associée à la première variable de la liste des tâches.
  Seuls quelques drivers permettent la création de tâches incluant des variables de différents types
  (ex. Octet, Mot, etc.). Pour de plus amples informations, consultez le manuel d'instruction du driver.

  Les principes suivants d'exécution d'une Tâche doivent être gardés à l'esprit :

  Entrées                 Ces données sont lues dans l'équipement connecté et écrites
                          dans des Variables Superviseur. Elles peuvent aussi être
                          exécutées sur événement. Dans ce cas la tâche est exécutée
                          seulement quand la variable associée est définie différente de 0.
                          Quand la tâche d'Entrée n'est pas exécutée sur évènement, elle
                          est exécutée en réalisant une scrutation commune aux autres
                          tâches d'entrée.

                                                                                                        7
D R I V E R S _ D E _ C O M M U N I C A T I O N

     Sorties                 Ces données sont lues dans l'équipement connecté et écrites
                             dans des Variables Superviseur. Les tâches de sorties sont
                             exécutées par Superviseur avec la technologie 'sur événement',
                             qui signifie que seulement quand il y a une variation dans des
                             données du superviseur, elle doit être notifiée à l'API ou à
                             l'équipement connecté. Le driver permet aussi l'écriture de
                             données en continue.

     Entrées/Sorties         Les tâches d'entrée-sortie sont gérées par scrutation afin de
                             garder à jour des données lues dans l'équipement connecté,
                             tandis que l'écriture des données est exécutée sur événement
                             seulement quand il y a un changement de données dans le
                             superviseur, en réécrivant les données modifiées sur
                             l'équipement connecté. Les tâches d'entrée-sortie sont donc, tout
                             d'abord des données lues continuellement dans l'équipement, et
                             des données écrites seulement quand c'est utile.

     COM (OLE2)              Superviseur peut aussi gérer les tâches qui n'ont pas été
                             configurées directement dans le driver, mais exécutées en
                             Runtime par un Script Basic VBA. Dans ce cas les tâches sont
                             exécutées par le driver selon le code écrit par l'utilisateur, en
                             exécutant les tâches de lecture ou d'écriture en mode synchrone
                             ou asynchrone.

     Bien que le programmeur doive être très prudent en utilisant les Tâches, il/elle a cependant
     l'avantage de décider comment les données doivent être échangées en lieu et place du superviseur.
     Les tâches de communication sont exécutées par des noms de variable et pas sur des adresses
     absolues.

               Rappelez-vous que les tâches permettent aussi l'utilisation de l'interface COM
               (Component Object Model) pour tout traitement ou toute exécution de tâches de
               communication du driver au moyen de l'utilisation de Scripts VBA.

1.6. Installation d'un Driver
     L'installation de Superviseur permet une installation automatique de la bibliothèque des drivers
     disponibles avec la plate-forme.
     Les Drivers Superviseur, construits avec de simples fichiers .DLL, peuvent être facilement améliorés
     ou mis à jour indépendamment de la plate-forme de développement. Pour mettre à jour ou installer
     un nouveau driver, copier juste le fichier .DLL correspondant dans le dossier Drivers, qui se trouve à
     l'intérieur du dossier d'installation de Superviseur.
     (C'est-à-dire C:\Program Files\Progea\MoviconX2\Drivers)

     Les programmeurs peuvent choisir quels drivers de communication insérer et les configurer un par
     un dans leurs diverses applications, en fonction de leurs besoins, en les sélectionnant dans la liste
     fournie.

     L'insertion et l'installation d'un driver de communication est réalisée en mode programmation dans
     Superviseur, avec la ressource 'Liste des drivers de Communication' du groupe 'BD Temps réel' de la
     fenêtre 'Explorateur de projet'. Quand on active la commande 'Ajouter un nouveau driver de
     Communication' une fenêtre de dialogue, contenant une liste des drivers disponibles, s'affiche.

 8
I N T R O D U C T I O N

  La fenêtre pour la sélection d'un driver de communication reporte, au bas de l'écran, quelques
  informations importantes concernant le driver, telles que :

    •    une brève description du protocole
    •    la liste des équipements pris en charge
    •    les cartes ou les bibliothèques nécessaires
    •    les éventuelles limitations du driver : les zones qui ne sont pas prises en charge, les
         connexions avec plusieurs PLC non admises, etc.

  Une fois que le driver a été inséré, il peut être configuré par la 'fenêtre des propriétés' de
  Superviseur.
  Plusieurs drivers de communication peuvent être insérés dans un projet, dans la mesure où ils
  respectent les options contenues dans la clé de protection.

  Une nouvelle option "Renaming Manager" a été ajoutée dans la liste des fonctions des drivers de
  communication permettant de savoir si le driver prend en charge la gestion des renommages. Les
  drivers qui prennent en charge la gestion des renommages et ont donc cette option sur "true",
  permettent d'afficher les variables avec le nom modifié dans leur fenêtre de configuration et de
  prendre en charge la commande d'application des renommages.

1.7. Duplication de Driver
  Superviseur offre la possibilité d'installer plusieurs drivers dans le système, sélectionnés dans la liste
  des drivers disponibles. Cependant, si vous voulez installer plusieurs drivers identiques (pour PLC ou
  pour des équipements du même type), vous devez suivre les indications données ci-dessous.
  Par exemple, vous devez installer plusieurs drivers du même type pour communiquer dans un même
  environnement simultanément mais il n'est pas suffisant de simplement définir deux Stations
  différentes avec un même protocole pour des équipements du même type.

  Exemple : vous voulez que le PC, sur lequel Superviseur est installé, communique avec deux
  équipements identiques sur deux canaux de communication distincts. Pour dupliquer un Driver de
  Communication il faut faire ainsi :

    1.   Dupliquer la DLL du driver concerné qui se trouve dans le dossier "Drivers" du dossier de
         l'installation de Superviseur. Le fichier doit avoir un nom différent de l'original, par exemple le
         même nom plus un index.
    2.   Mettre à jour le fichier "Drivers.xml" en indiquant le nouveau fichier .DLL dupliqué et donner-
         lui une description et un nom pour qu'ils apparaissent comme deux drivers identiques, mais
         avec des noms et des descriptions différens dans la liste des Drivers Superviseur.

            Quand un driver est dupliqué il a le comportement d'un nouveau driver,
            donc vous devez posséder la licence logicielle pour 2 drivers. En utilisant

                                                                                                          9
D R I V E R S _ D E _ C O M M U N I C A T I O N

              deux drivers, même du même type, car dupliqués, on doit disposer de la
              licence pour deux drivers de communication.

Un exemple pratique :
   Vous voulez gérer un projet où deux drivers "Modbus série" sont utilisés. Les étapes suivantes
   doivent être effectuées :

    Duplication de la dll
    Dans le sous-dossier "Drivers" de l'installation de Superviseur réaliser une copie de l'original
    "Modbus.dll" et le nommer "Modbus1.dll" par exemple.

    Modifications fichier Drivers.xml
    Ouvrir le fichier "Drivers.xml" avec un éditeur de texte. Dans le Tag XML , ajouter le nouveau driver, en donnant une description et le nouveau nom de la
    dll. Par exemple :
     ModBus1.dll. Modification du fichier de communication
    :

                            ModBusTCPIP.dll
                            ModBus.dll
                            ModBus1.dll
                    
                    SapiS7.dll
                    MpiPcAdapter.dll

    De cette façon, quand vous ouvrez la fenêtre de la liste de Drivers disponibles vous trouvez celui que
    vous venez de dupliquer.

1.8. Démarrage des Drivers
    Les drivers de communication installés ou les drivers lancés au démarrage du projet restent actifs en
    permanence, selon les modes d'exécution choisis ou les scripts VBA utilisant l'interface COM
    (Component Object Model) du driver.
    À chaque activation de la communication avec les équipements, le système enregistre un message
    de notification d'état de la communication dans l'Historique d'alarmes.

 10
I N T R O D U C T I O N

              Une LED verte sur la barre d'état en bas de la fenêtre Superviseur (si elle est
              affichée) signifie que le driver installé communique correctement avec
              l'équipement. Si la LED est rouge, il y a une erreur de communication.

  Tous les problèmes de communication (le câble, les connexions, les paramètres, etc.) produisent des
  erreurs de communication qui sont affichées par le driver dans la Barre d'état et enregistrées dans
  l'Historique d'alarmes.

              Note : les drivers sont indépendants du projet et leurs configurations sont
              sauvegardées dans des fichiers séparés, qui sont identifiés par les extensions
              ".drvsettings" et "dynsettings". Cette philosophie garantit que le projet est
              conservé si l'on modifie la communication avec les équipements.

  Le driver peut être subordoné aux conditions établies par le programmeur en runtime.

1.9. Erreurs Hard sur RS232
  L'autodiagnostic des Drivers de Communication de Superviseur émet des codes d'erreurs matérielles
  de communication, selon les indications fournies par l'état enregistré du circuit intégré UART du port
  série installé sur le PC.
  Nous recommandons l'utilisation de port série avec le circuit intégré UART 16550A qui utilise la
  gestion des données sur 16 octets FIFO (premier entré premier sorti). Le type de port série installé
  sur le PC est facilement détecté en exécutant le fichier Microsoft de diagnostic MDS.EXE.

  Les erreurs matérielles de communication sont généralement dues aux causes suivantes :

      •   Perturbations sur la ligne série.
      •   Différence de potentiel entre les masses des équipements.
      •   Cartes séries inadaptées au fonctionnement demandé.
      •   Câbles de communication défectueux ou inadéquats.
      •   Vitesse de transmission (en bauds) trop haute pour le matériel utilisé.
      •   Panne de l'appareil de communication.

  Les erreurs matérielles fournies par le driver relatives aux codes émis sur le registre d'erreur du
  circuit intégré série UART.

  Quand il y a des erreurs matérielles, Superviseur émet une erreur générique représentée
  par un chiffre, traduit en binaire, avec lequel vous pouvez identifier l'erreur ou les
  erreurs en confrontant chacun des bits dont les significations sont décrites dans la table
  ci-dessous :

  VALEUR            CODE                   SIGNIFICATION

  1                 RX OVER                Le port série a reçu plus de caractères que la
                                           capacité du buffer peut contenir
  2                 OVERRUN                Le port série a reçu un caractère avant que le
                                           précédent n'ait été traité par le système
  4                 RX PARITY              Erreur de parité, discordance entre la parité
                                           reçue et celle définie
  8                 FRAME                  Erreur dans la trame de données. Les données
                                           reçues ne respectent pas les caractères définis
                                           (longueur, bit d'arrêt, etc)
  16                BREAK                  Etat Pause demandée

             Toutes les autres erreurs de communication dépendent du protocole utilisé, donc
             vous devez vous référer aux indications de chaque driver. Les messages d'erreur
             du driver sont affichés sur la barre d'état et peuvent être lus dans l'Historique
             d'alarmes.

                                                                                                    11
D R I V E R S _ D E _ C O M M U N I C A T I O N

12
2. Paramétrages Générales

      Certaines des propriétés communes à tous les drivers de communication, peuvent être configurées
      sur cette page de paramètres.
      Il n'est pas nécessaire généralement de modifier les réglages par défaut.

  Wait Time/Temps de pause (ms)
    Le temps de pause, exprimé en millisecondes, entre l'exécution de deux tâches (blocs de données)
    de communication successives. La valeur 0 (aucune pause) a été définie par défaut. Il peut être
    nécessaire de changer la valeur par défaut (0) pour les équipements qui ont besoin d'un temps
    d'attente entre une interrogation et la suivante (c'est-à-dire. Équipement avec de faibles
    performances).

  Timeout :
     Temps de timeout pour exécuter des tâches synchronisées. La valeur est exprimée en millisecondes,
     avec un temps par défaut de 2000 ms.

  Minimum Threshold/Seuil minima de fragmentation
     Ce paramètre détermine le seuil minimal pour la fragmentation des blocs de données échangés avec
     l'équipement. Comme indiqué dans l'introduction, de la gestion des communications dynamique,
     Superviseur calcule automatiquement (au démarrage du projet) la taille et la quantité de tâches
     dynamiques qui doivent être créés dans le driver pour la communication relatives aux variables
     dynamiques (variable avec adresses dynamiques).
     Superviseur, en fait, essaye d'optimiser la communication en combinant le nombre le plus grand de
     données possibles dans une seule tâche. Quand les données sont liées avec des adresses distantes
     l'une de l'autre, cette valeur détermine la différence en octets qui permet à Superviseur de décider
     s'il faut créer ou non une nouvelle tâche pour le bloc de données suivant.

      Par exemple :

              VAR00001   est   liée   à   l'adresse   mot 0 de l'équipement
              VAR00002   est   liée   à   l'adresse   mot 3 de l'équipement
              VAR00003   est   liée   à   l'adresse   mot 12 de l'équipement
              VAR00004   est   liée   à   l'adresse   mot 17 de l'équipement

      Le paramètre 'Seuil Minimal' est défini à 5 par défaut. Dans cet exemple quand le projet démarre, le
      driver crée dynamiquement le fichier XML '.dynsettings' dans le dossier des 'Ressources' du projet,
      dans lequel la génération de 2 tâches dynamiques est calculée pour le driver.
      Dans la première tâche les mots 0 à 3 sont lus, dans la deuxième tâche (qui est nécessaire parce que
      le mot suivant à lire est à une adresse qui dépasse 5 octets comme indiqué par le paramètre 'Seuil
      Minimal') les mots 12 à 17 sont lus.
      Si, cependant, nous définissons le paramètre 'Seuil Minimal' à 20, le driver crée dynamiquement au
      démarrage du projet une seule tâche en lisant du mot 0 au mot 18.

                Le nombre de tâches générées automatiquement dépend de la valeur
                mise dans le paramètre 'Seuil Minimal'.

  Limite d'agrégation d'octets
     Ce paramètre vous permet de spécifier le nombre maximal d'octets à rassembler pour chaque tâche
     dynamique. En laissant ce paramètre avec la valeur définie à zéro (valeur par défaut) le driver utilise
     la valeur maximale définie dans le protocole sélectionné comme limite maximale. Cette modification
     est nécessaire en utilisant les équipements qui ont une limite du nombre d'octets maximum
     inférieure à celle du protocole utilisé pour échanger les tâches.

  Synch.Startup/Syncho logique
     Cette option détermine la synchronisation entre le SoftLogic et le driver de communication au
     démarrage du projet.
     Quand cette option est définie à 'vrai', Superviseur attend que les tâches d'entrées statiques aient
     été complètement exécutées avant le traitement du SoftLogic et des Scripts du projet.
     Valeur par Défaut = faux.
     Bien que cette option ralentisse la mise en route du projet, le SoftLogic est exécuté avec la certitude
     que les valeurs d'entrée soient 'mises à jour'.

                                                                                                        13
D R I V E R S _ D E _ C O M M U N I C A T I O N

COM Interface/Interface COM/OLE2
  Indique si le driver supporte l'interface COM (Component Object Model). L'interface COM, aussi
  appelé OLE2, permet l'utilisation de script VBA pour traiter le driver, selon les méthodes, les
  propriétés et les événements décrits dans les documents appropriés.
  Valeur par Défaut = vrai.

Polling Time/Temps de scrutation
    Ce paramètre, exprimé en millisecondes, représente le temps minimum de scrutation pour effectuer
    les tâches de mise à jour des données lorsque les variables sont en cours d'exploitation.
    Ce paramètre sera acquis par toutes les tâches dynamiques, qui auront donc toutes le même Polling
    Time (seuls quelques drivers permettent de spécifier un Polling Time pour chaque tâche dynamique).
    En ce qui concerne les tâches statiques, ce paramètre est inséré implicitement dans la propriété
    éponyme des tâches ("Polling Time") lors de leur création. Ce paramètre est modifiable
    successivement à travers la propriété de la tâche statique.
    En paramétrant la valeur à 0, cela signifie que les données sont mises à jour à la vitesse maximale.
    Vous pouvez paramétrer une valeur plus élevée, lorsque par exemple, les données ne requièrent pas
    une mise à jour rapide.

Unused Polling Time
   Ce paramètre, exprimé en millisecondes, permet de forcer la mise à jour de données même quand
   les variables ne sont pas en cours d'exploitation, en établissant, cependant, un temps de
   scrutation.
   Ce paramètre sera acquis par toutes les tâches dynamiques, qui auront donc toutes le même Unused
   Polling Time. En ce qui concerne les tâches statiques, ce paramètre est inséré implicitement dans la
   propriété éponyme des tâches ("Unused Polling Time") lors de leur création. Ce paramètre est
   modifiable successivement à travers la propriété de la tâche statique.

              Quand ce paramètre est égal à 0, les tâches ne sont pas exécutées quand les
              variables ne sont pas utilisées.

Error Polling Time/Erreur temps de scrutation
   Ce paramètre, exprimé en millisecondes, fixe le temps de scrutation d'une station (équipement)
   lorsqu'elle est en erreur. Dans cette situation, le driver restera inactif pendant le temps établi avant
   d'effectuer une nouvelle tentative.

Protocol Priority/Priorité Protocole
   Ce champ de saisie est utilisé pour définir la priorité de la voie de communication, qui est la priorité
   donnée à l'exécution du driver par rapport aux autres processus du superviseur.
   Les valeurs en commençant de la plus basse priorité à la plus haute priorité sont :

      •    Normal/Normale
      •    High/Haute
      •    Very High/Très Haute
      •    Real Time/Temps réel

              On recommande lorsque l'on change la valeur par défaut (Normal) de prendre
              soin de ne pas dépasser la charge de travail du processeur (CPU à 100 %).
              Il peut être utile d'essayer et d'augmenter la priorité du driver en raison de
              charges de communication élevées. Dans ce cas, on conseille de définir le
              paramètre du temps de pause à une valeur différente de 0, pour éviter que le
              driver utilise trop de ressources système.

Suspend tasks in case of error / Désactivation des tâches en cas d'erreur
   Cette option n'est active que pour les drivers permettant l'adressage symbolique des tâches "Tag
   Name". Paramétrée "Vrai", elle restera sans effet pour les drivers ne permettant que l'adressage
   numérique "Address Type".
   Paramétrée "Vrai", lorsqu'une erreur de communication se vérifie, toutes les tâches sont désactivées
   sauf celle ayant généré l'erreur. Ce comportement pourrait se révéler inadapté en cas de drivers
   permettant l'utilisation de l'adressage symbolique (nom des variables de l'équipement) tels que le
   Beckhoff TwinCAT ou l'Allen-Bradley Ethernet/IP. Dans ce cas, il convient de définir cette option
   "Faux" afin de maintenir l'activité de toutes les tâches, y compris en cas d'erreur. Le fonctionnement
   sera donc le suivant :
   - le driver poursuivra ses interrogations même en cas de non aboutissement
   - une interrogation non aboutie sera retentée après le temps défini dans le paramètre "Error polling
   Time"

 14
P A R A M É T R A G E S            G É N É R A L E S

    - toute erreur de communication          se   reflètera   sur   l'état   du   bit   de   communication
    (_SysVar_:CommDriverStatus)

Management of "In Use" state for structures
  Paramétrée "Vrai", cette option permet de placer "En utilisation" tous les membres d'une variable
  Structure même s'ils ne sont que partiellement utilisés dans le projet. De cette façon, on aura la
  certitude que le driver échangera toute la variable Structure, même si le projet n'utilise que l'un de
  ses membres. Paramétrée "Faux", chaque membre de la variable Structure sera géré. Par
  conséquent, le driver n'échangera que les membres effectivement utilisés dans le projet.

              Attention ! Le paramétrage "Vrai" de cette option diminue considérablement les
              performances de communication, surtout en présence de nombreuses variables
              Structure contenant à leur tour de nombreux membres.

Direct Output for Input/Output
   Cette option permet au driver de modifier l'exécution des tâches dynamiques de type "input/output".
   Paramétrée "Faux", en cas de modification de la variable sur la supervision, l'output sera précédée
   par un input. Si la variable n'a pas été modifiée sur l'équipement, l'opération sera complétée par un
   output. Paramétrée "Vrai", il sera possible d'effectuer une tâche input/output directement en output,
   c'est à dire sans effectuer une relecture.

2.1. Débogage
    Certaines des propriétés concernant le Débogage, communes à tous les drivers de communication,
    peuvent être configurées sur cette page de paramètres.
    Il n'est généralement pas nécessaire de changer les réglages par défaut.

Debug Window/Fenêtre Débogage
   En sélectionnant 'vrai', le driver affiche tous les messages de diagnostic et de Débogage (mise au
   point) fournis par le driver dans la fenêtre Débogage (ils peuvent aussi être affichés dans la barre
   d'état de l'espace de travail de Superviseur). En sélectionnant "faux", la fenêtre de débogage ne
   s'affichera pas.

              L'activation de la fenêtre de débogage ralentit l'activation de la tâche et
              la vitesse de communication en général. Il est conseillé de n'utiliser
              cette fonction qu'en cas de nécessité absolue, comme dans la phase de
              débogage.

Max Entries/Nbre max. messages
  La valeur, du nombre maximal de messages de diagnostiques affichés dans la fenêtre de Debug
  avant une suppression FIFO, est saisie dans ce champ. Quand la valeur par défaut est laissée, la
  fenêtre garde les 10,000 derniers messages affichés.

Enable Log to file/Autoriser fichier log
   En sélectionnant "vrai", le driver enregistre sur un fichier tous les messages de diagnostiques du
   Debug produits par le driver.
   La quantité de données enregistrées est définie dans le paramètre précédent, tandis que le nom du
   fichier et son chemin sont définis dans le paramètre suivant.

Log FileName/Nom du fichier log
   Le nom du fichier et son chemin pour le Journal des diagnostiques du driver doivent être saisis dans
   ce champ.
   Le fichier généré sera un fichier texte.

                                                                                                       15
D R I V E R S _ D E _ C O M M U N I C A T I O N

16
3. Paramétrages d'une Station

 3.1. Stations
      Dans cette page vous devez insérer et configurer les 'stations de communication'. Pour chaque
      driver, au moins une station de communication doit être configurée.

                  Il est rappelé que Superviseur offre la possibilité d'installer un driver de
                  communication en utilisant soit l'adressage dynamique' soit les concepts de
                  'Tâches' (décrit dans les chapitres concernés). Les tâches dynamiques sont
                  créées automatiquement par le driver au démarrage du projet, en fonction des
                  liens avec les adresses de l'équipement définies dans la propriété 'Adresse
                  Dynamique' de chaque variable).

      Les stations de communication vous permettent de définir, comme pour les drivers, comment la
      communication doit être gérée, où chaque station représente un canal de communication vers
      l'équipement configuré.

  Add/Ajouter
     Le bouton "Ajouter" vous permet d'insérer une nouvelle 'station' pour le driver de communication. En
     insérant une nouvelle station une fenêtre s'affiche automatiquement pour définir les paramètres de
     la communication requise.
     Une fois que la station ou les stations ont été insérées, vous pouvez les éditer ou les supprimer en
     utilisant les boutons décrits ci-dessous.

  Edit/Éditer
     Le bouton 'Éditer' vous permet de modifier les paramètres d'une station précédemment insérée.
     Donc vous devez d'abord sélectionner la station que vous voulez modifier en utilisant le bouton
     'Éditer' ou par double-clic.

  Remove/Supprimer
    Le bouton "Supprimer" vous permet de supprimer une station précédemment insérée. Donc vous
    devez d'abord sélectionner la station que vous voulez modifier puis utiliser le bouton 'Supprimer'.

  Test Cable/Comm./Tester cable
     Ce bouton vous permet d'exécuter un test de communication avec l'équipement. Grâce à cette
     fonction très pratique le driver essaye la communication pour vérifier si les câbles ont été connectés
     correctement.

                Le test de communication est appelé en lisant des données spécifiques selon les
                critères de test de chaque protocole.
                Donc il peut être nécessaire de se référer aux spécifications indiquées par chacun
                des drivers pour voir quel genre de test est effectué.
                Par exemple, avec un protocole générique comme Modbus, le test fait la lecture
                d'un Code Fonction (FC2) spécifique qui n'est pas forcément mis en œuvre sur
                l'équipement connecté.

                Rappelez vous que dans chaque cas le test vérifie seulement si le câble et les
                configurations générales des paramètres ont été faites correctement et que c'est
                le programmeur qui doit vérifier si les données entre le superviseur et
                l'équipement ont été associées correctement.

 3.2. Propriétés Générales des Stations
      Cette page de paramètres est utilisée pour définir les paramètres inhérents au paramétrage du
      groupe des propriétés 'Générales' de la station sélectionnée.

                                                                                                       17
D R I V E R S _ D E _ C O M M U N I C A T I O N

Station Name/Nom de la station
   Le Nom qui identifie la station correspondant à l'équipement avec lequel il doit communiquer. Le
   nom de la station est interne au driver.
   Quand plusieurs stations doivent être définies, chacune doit avoir son propre nom.
   Valeur par Défaut = 'Station par défaut'.

Error Threshold/Seuil d'erreur
   Quand il y a des erreurs de communication, ce paramètre définit le nombre d'erreurs à atteindre
   pour que le Driver émette une notification d'erreur de communication. Le compteur interne n'alerte
   pas immédiatement sur toutes les occurrences de problème de communication, mais essaye d'abord
   de récupérer la communication. Quand le nombre de tentatives a été atteint, le driver envoie un
   avertissement.
   Valeur par Défaut = 1.

State/Command Variable - Etat commande variable (gérée seulement par les
drivers utilisant une bibliothèque de base build 250 et plus)
    En assignant le nom d'une variable numérique définie dans la supervision (type conseillé Octet) à
    cette propriété, vous pouvez contrôler l'état de la communication avec la station sélectionnée, valider
    / invalider la communication avec la station, démarrer/arrêter les connexions TAPI (seulement pour
    les drivers série) ou RAS (seulement pour les drivers Ethernet), et passer entre différents serveurs
    TCP / IP (seulement pour les drivers Ethernet).
    Consultez le tableau suivant pour la signification de chaque bit de la variable. Il faut savoir que
    certains bits ne peuvent être utilisés que pour vérifier l'état de la station, tandis que d'autres peuvent
    être utilisés pour donner des ordres à la station.

      •     Le bit 1 de la variable est utilisable pour vérifier et modifier l'état de validation de la station
            (Active / Inactive, Validée/Invalidée).
      •     Les Bits 4, 5, 6 sont utilisables pour gérer une connexion TAPI (driver série) ou une
            connexion RAS (driver Ethernet).

    Si vous n'avez besoin que de l'information sur l'état de la communication avec la station, vous
    pouvez utiliser une variable de type Bit comme variable d'Etat.

          Bit 0                          Etat de la Communication
          (Etat)                         0 = OK
                                         1 = Erreur

          Bit 1                          Etat de la Station :
          (Etat/Commande)                0 = Active/Validée
                                         1 = Désactivée/Invalidée

          Bit 2                       Change le serveur TCP actif
          (Commande)

          Bit 3                          TCP Serveur actif :
          (Etat)                         0 = Serveur principal
                                         1 = Serveur de secours

          Bit 4                          Etat de la connexion Modem :
          (Etat)                         0 = pas connecté
                                         1 = connecté

          Bit 5                       Ouvre la connexion Modem
          (Commande)

          Bit 6                       Ferme la connexion Modem
          (Commande)

          Bit 7                       Toujours à 0
          (Inutilisé)

 18
P A R A M É T R A G E S       D ' U N E   S T A T I O N

 Keep Opened/Rester Ouvert
    Cela vous permet d'établir si le driver (seulement pour les drivers séries) doit garder le port de
    communication ouvert (et donc toujours occupé). Quand la valeur = Vrai est définie, le driver st
    chargé au démarrage du projet et garde toujours le port de communication associé ouvert (occupé).
    En définissant la valeur à 'Faux', le driver ferme le port série de communication après chaque
    opération d''Entrée' ou de 'Sortie' laissant ainsi le port libre.

3.3. Paramétrage des ports série
     Dans ce groupe de paramètres vous devez définir les configurations inhérentes au groupe des
     propriétés des Paramètres du Port série pour la station sélectionnée :

    En utilisant les paramétrages TAPI de la station pour gérer la communication via modem, la sérielle
    est gérée par le driver du modem. Les paramétrages ouvrant la sérielle sont donc ceux définis dans
    les propriétés avancées du driver du modem. Ils peuvent être différents de ceux définis dans la
    station du driver Movicon ("Paramétrage des ports série").
 Port
    Le numéro du port série à utiliser pour la communication.

                 Note: vous devez vous assurer qu'il n'y a aucun conflit dans Windows en
                 utilisant les ports série. Par exemple, en installant le Com4 et les ports Com4,
                 vous devez vérifier si l'adresse définie et l'IRQ sont compatibles avec les
                 configurations du PC. Donc nous suggérons l'utilisation de cartes séries
                 adressables.

 Baudrate/Vitesse (Baud)
    Définit la vitesse de la communication série (en bauds). La valeur de la vitesse de la communication
    doit correspondre avec celle de l'équipement avec lequel il faut communiquer.

 Byte Size/Taille en octets
    Définit la quantité d'octets requis par le protocole de communication en question.

 Parity/Parité
    Définit le type de parité requis par le protocole de communication en question.

 Stop Bits/Bits de stop
    Définit le nombre de Bits de stop requis par le protocole de communication en question.

 Flow Control/Contrôle de flux
    Définit le type de Contrôle de Flux de données pour le type de communication en question. Cette
    propriété permet d'adapter au flux des données de communication du port série de l'équipement
    connecté les besoins nécessaires du protocole au niveau bas. Le driver définit 'Aucun' par défaut, ce
    qui signifie aucun contrôle de flux, néanmoins il peut être nécessaire de sélectionner un type de
    contrôle de flux (c'est-à-dire lorsque des erreurs sont signalées avec le code '1').
    Les options sont :

          Aucun : Aucun Contrôle de Flux. Le protocole n'exige pas ce contrôle
          Hardware : Le Contrôle de Flux est géré par les signaux électriques de la ligne série (eg. RTS,
          CTS, etc)
          Xon/Xoff : Le Contrôle de Flux de données est Xon/Xoff
          NONE (Signal disabled): définit le contrôle de flux à AUCUN et définit la ligne série pour
          désactiver la gestion des signaux DTR et RTS.
          RTS Toggle: définit la ligne série pour gérer le signal de contrôle RTS en Toggle, c'est à dire
          que la ligne série maintient le signal haut tant qu'il y a des signes à envoyer.

3.4. Taille Buffer
     Dans ce groupe de paramètres vous devez définir les configurations inhérentes à la taille du buffer
     du port série pour la station sélectionnée.

                                                                                                      19
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler