I/O Drivers Guide de référence - Supervision et de contrôle à base de XML à partir de Windows Vista à Windows CE
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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
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
21. 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
3D 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'
4I 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.
5D 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
6I 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.
7D 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.
8I 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
9D 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.
10I 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.
11D 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'.
13D 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"
14P 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.
15D 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.
17D 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é)
18P 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.
19Vous pouvez aussi lire
