serveur opc - geii1.free.fr · pdf fileelectrical & safety · industrial connectivty...

electrical & safety · industrial connectivty · software & electronics · advanced connectivity

WoodheadWoodhead

Opc.doc 04/09/2003

Copyright © 2003 Woodhead Software & Electronics. Tous droits réservés.

http://www.applicom-int.com

Serveur OPC

applicom® 3.7

un produit Woodhead Software & Electronics


WoodheadWoodhead

Opc.doc 04/09/2003 Copyright © 2003 Woodhead Software & Electronics. Tous droits réservés. Tous les produits applicom®, Direct-LinkTM, RJ-LnxxTM, SSTTM sont des marques déposées de Woodhead Software & Electronics. Tous les autres noms de produits sont des marques déposées de leurs fabricants respectifs.

http://www.applicom-int.com


WoodheadWoodhead

Serveur OPC • i • Table des matières

Table des matières

1. Présentation du serveur OPC .......................................................3 Contexte d'utilisation du serveur OPC ....................................................................3 Démarrage du serveur OPC (local et distant) .........................................................5 Interface graphique du serveur OPC ......................................................................6

2. Paramétrage du serveur OPC .......................................................7 Paramètres de base ................................................................................................7 Mode de paramétrage 'expert' ................................................................................7

3. Principe d’accès aux données......................................................8 Le ProgID ................................................................................................................9 Le browsing des ItemID.........................................................................................10 Gestion des groupes (OPC Group).......................................................................11 Mode d'accès aux données du serveur OPC........................................................13 Horodatage des données......................................................................................14 Qualité des items...................................................................................................14 Limitation du nombre d’I/O Items (SW1000ETH seulement) ................................15 Types de topic d’accès aux variables ...................................................................17 Configuration des topics........................................................................................18

4. Accès aux Variables images ou locales ....................................19 Paramètrage minimal d’un topic "variable image" ou "variable locale".................21 Syntaxes des variables internes ...........................................................................21 Accès aux variables unitaires................................................................................24 Optimisation des requêtes synchrones et asynchrones .......................................24 Utilisation du mode tableau...................................................................................25 Utilisation du mode message ................................................................................26 Bit de mots ............................................................................................................27 Suffixe optionnels ..................................................................................................28 Descripteur standard pour l’accès à la data-base.................................................29 Descripteur standard d’accès aux variables images.............................................31 Information de diagnostics et contrôle ..................................................................32 Les noms symboliques..........................................................................................34

5. Accès aux Variables images d’un contrôleur Logix 5000 ........37 Paramétrage d’un topic "variable image" d’un contrôleur Logix 5000 ..................37 Syntaxes des variables internes ...........................................................................38 Optimisation des requêtes synchrones et asynchrones .......................................38 Limitations .............................................................................................................39 Information de diagnostics et contrôle ..................................................................39

6. Accès aux paramètres des fonctions cycliques .......................41 Contrôle des fonctions cycliques de PCCYC........................................................41 Items liés à un topic "fonction cyclique" ................................................................42

7. Accès aux informations générales du serveur (Topic "SYSTEME") ..................................................................................................45


WoodheadWoodhead

Serveur OPC • ii • Table des matières

8. Accès au WatchDog et à l’entrée TOR (Topics "CARDx") .......46

9. Accès aux signaux modems (Topic "CHANx") .........................47

10. Interface de Diagnostic ...............................................................48 Les requêtes de communication ...........................................................................50 Optimisation de la communication ........................................................................50 Vue d'espionnage des items .................................................................................51 Vue des messages................................................................................................53

11. Développement d'un client OPC.................................................54 Contextes de développement ...............................................................................54 Développement d'un client en C et C++ ...............................................................55 Informations nécessaires au développement .......................................................59

12. Index .............................................................................................62


WoodheadWoodhead

Serveur OPC • 3 • Présentation du serveur OPC

1. Présentation du serveur OPC

Contexte d'utilisation du serveur OPC Le package applicom® inclut des interfaces logicielles de haut niveau, permettant de rendre totalement transparent pour l’utilisateur l’accès aux données. Ces interfaces logicielles permettent à des applicatifs "client" de manipuler les données mises à disposition par applicom® sans se soucier de la gestion d’accès vers les interfaces applicom (ou vers l’émulateur) et de l’optimisation de la communication.

OPC : Qu'est ce que c'est? OPC est un standard de communication basé sur la technologie OLE/COM. Cette dernière constitue le moyen d’échange d’informations préconisé par Microsoft entre applications MS-Windows. Le modèle COM est destiné à assurer une interopérabilité entre des composants logiciels développés de manière indépendante par des éditeurs distincts. Cette interopérabilité est indépendante des langages de développement utilisés. COM peut être considéré comme un “bus logiciel” assurant un rôle de “Plug And Play” entre des modules logiciels.

OPC n’est en fait que la spécification d’un standard. Celui-ci décrit l’ensemble des objets et de leurs interfaces que tout “serveur OPC” devra implémenter de façon à assurer une plus grande interopérabilité entre des applications de contrôle/commande/supervision, des équipements industriels (API, capteurs, actionneurs) et des applications bureautiques de gestion. Pour plus d’informations sur les spécifications OPC vous pouvez consulter le site de la fondation OPC http://www.opcfoundation.org.

http://www.opcfoundation.org/


WoodheadWoodhead


Le serveur OPC Le serveur OPC applicom® est une application ("APP_OPC.EXE") pouvant s’exécuter sous les environnements Windows 32 bits et jouant le rôle de serveur de données industrielles auprès de toute application cliente OPC compatible avec les spécifications Custom Data Access 1.0A et 2.0.5

Il est donc aisément utilisable à partir de tout logiciel intégrant de base une interface client OPC :

progiciels de supervision,…

ActiveX de communication applicom®

mais également à partir de développements spécifiques

applications écrites en C ou C++

Le serveur OPC peut être utilisé localement (depuis une application cliente située sur la même machine) ou à distance à travers DCOM (depuis une application cliente située sur une autre machine connectée par le réseau).

Le serveur OPC fonctionne avec tous les protocoles supportés sur les solutions applicom®, exceptés Batibus et 3964 en messagerie libre.

Dans le cas des kits de développement, certaines limitations liées à la nature de votre protocole peuvent intervenir. Nous consulter.

Note : Le serveur OPC applicom® ne peut pas fonctionner simultanément avec le serveur DDE/Suitelink applicom®. Mais il peut cohabiter avec une application utilisant l'interface librairie applicom® "APPLICOM.DLL".

Voir également: Dans ce manuel

Développement d'un client OPC

Dans la base de connaissance

Introduction à DCOM avec un serveur OPC


WoodheadWoodhead


Démarrage du serveur OPC (local et distant) Le démarrage du serveur OPC ne nécessite aucune intervention manuelle sur le poste où est localisé le serveur. En effet, la technologie COM sous-jacente automatise le lancement lors de la première demande d'une application cliente.

Si le serveur est un serveur local, aucune configuration préalable du système n'est nécessaire. (sauf si le client est un service - voir Client OPC sous forme de service)

Si le serveur est un serveur distant (utilisé à travers DCOM), l’installation de certains composants sera nécessaire sur le poste client. De plus, une configuration préalable du système devra être effectuée aussi bien sur le poste client que sur le poste serveur (voir Introduction à DCOM avec un serveur OPC)

Les composants nécessaires pourront être installés :

Soit en effectuant une installation complète du produit applicom sur le poste client

Soit en installant le produit applicom Communication ActiveX Control

Voir également: Dans la base de connaissances

Introduction à DCOM avec un serveur OPC

Client OPC sous forme de service


WoodheadWoodhead


Interface graphique du serveur OPC

Par défaut, le serveur OPC applicom® ne possède pas d’interface graphique. Après son lancement, la présence du serveur est matérialisée par une icône insérée dans la barre de tâches (si les critères de sécurité DCOM le permettent). Par défaut cette icône ne possède pas de menu contextuel. Cependant, celui-ci peut être activé à partir de la boîte de configuration des paramètres OPC, en validant l'option autoriser la vue de diagnostic du serveur. Ce menu vous permet alors, par clic droit de la souris :

d’afficher l’environnement de diagnostic (Menu Diagnostic).

de fermer le serveur (Menu Quitter) Voir également:

Dans ce manuel

Interface de Diagnostic

Paramètres de base

Dans la base de connaissance

Client OPC sous forme de service


WoodheadWoodhead

Serveur OPC • 7 • Paramétrage du serveur OPC

2. Paramétrage du serveur OPC

Paramètres de base Tout le paramétrage nécessaire à l’utilisation du serveur OPC est réalisé à partir de la console applicom®, dans la vue de description de la configuration.

Attention : ces paramètres sont pris en compte au démarrage du serveur OPC. Toute modification devra donc donner lieu à un redémarrage de ce dernier.

Voir également : dans la documentation :

Configuration : Paramètres du serveur OPC

Mode de paramétrage 'expert' Un mode expert de paramétrage du serveur OPC devient disponible au sein de la console applicom® lorsque cette dernière est elle-même commutée en mode expert (voir renvoi "Commande globale du menu Fichier"). Ce mode n'est utile que dans des cas précis tels que la nécessité :

d'utiliser des fonctionnalités avancées et non courantes du produit

de modifier certains facteurs de temps

L'utilisation de ce mode de paramétrage devrait normalement être conditionnée par l'intervention de notre support technique. Certains des paramètres pourraient en effet avoir de lourdes conséquences s'ils venaient à être mal positionnés. Cependant, certaines des fonctionnalités avancées sont documentées dans la Base de connaissance (voir renvois).

Voir également : dans la documentation :

Configuration : Paramètres du serveur OPC

Mise en œuvre : Commande globale du menu Fichier

dans la base de connaissance :

Validation et dévalidation du mode diagnostic


WoodheadWoodhead

Serveur OPC • 8 • Principe d’accès aux données

3. Principe d’accès aux données

La spécification OPC prévoit que l'application cliente référence une variable à l'aide d'une chaîne de caractères nommée ItemID. Dans le cas d’applicom®, cette chaîne est la concaténation :

du chemin du périphérique contenant la variable A partir de la version 3.1 du produit applicom®, le chemin d’accès à la variable est représenté par un topic. En fonction du type de variable visée, ce nom de topic correspondra à l’un des topics configurés:

de type “variable image” pour un accès dans un équipement distant.

de type “variable locale” pour un accès à la zone de donnée partagée data-base applicom®.

de type "fonction cyclique" pour le contrôle des fonctions cycliques. ( Non supporté en Direct-Link )

Ou à l'un des topics prédéfinis:

le topic "SYSTEME" permettant d'accéder à des informations générales du serveur.

les topics "CARDx" (x de 1 à 8) permettant de piloter le watchdog et l'entréee TOR d'une interface applicom® particulière. ( Non supporté en Direct-Link )

les topics "CHANx" (x de 0 à 31) permettant de piloter les signaux modem d'un canal particulier. ( Non supporté en Direct-Link )


WoodheadWoodhead


d’une syntaxe désignant la nature et l’adresse de la variable Pour les topics de type “variable image” ou “variable locale”, un item est le plus souvent un élément de mémoire de type bit, octet, mot, flottant IEEE, message ASCII, etc... Cependant, le serveur OPC met aussi à votre disposition certains items réservés, utilisables uniquement avec ces types de topic.

Pour les topics de type "fonction cyclique"( Non supporté en Direct-Link ), un Item est représentatif d'un paramètre de la fonction cyclique correspondant au topic.

A chaque topic "prédéfini", sont associés des items spécifiques.

Remarques : Dans la chaîne référençant l’item, le délimiteur de champs par défaut est le point “.”. En

cas de besoin, ce délimiteur peut être modifié dans le paramétrage du serveur OPC,

La spécification OPC prévoit également la possibilité pour un client d'utiliser un AccessPath. Le serveur applicom® ne nécessite pas de l'utiliser. Cependant, si celui-ci n'est pas vide, il sera concaténé avec la chaîne ItemID fournie par le client pour fabriquer l'ItemID utilisé par le serveur. Par exemple, si le client fournit comme AccessPath la chaîne "TOPIC" et comme itemID la chaîne "ITEM" le serveur utilisera la chaîne TOPIC.ITEM comme ItemID.

Une compatibilité avec les versions précédentes est assurée :

Pour accéder à des variables locales, le chemin pourra donc être de la forme :

- Card1.Database

Pour accéder à des variables images, le chemin pourra être de la forme :

- Card1.Channel0.EquipmentZ

Z représentant le numéro de l’équipement (configuré dans la console applicom de 0 à 255)

Voir également : dans ce manuel :

Limitation du nombre d’I/O Items (SW1000ETH seulement)

Types de topic d’accès aux variables

Configuration des topics

Le ProgID Lorsque vous êtes utilisateur d’un progiciel, lui-même client OPC, le serveur OPC applicom® est identifié dans celui-ci à l’aide de son ProgID (identificateur de programme) :

ProgID “APPLICOM.OPCServer.1” ;


WoodheadWoodhead


Le browsing des ItemID Le serveur OPC applicom® supporte les capacités optionnelles de browsing (interface IOPCBrowseServerAddressSpace). Elles permettent aux applications clientes d'effectuer une recherche parmi les items disponibles de l'espace d'adressage du serveur OPC en fournissant une liste classée d'itemID valides.

L’application client peut utiliser le browser de la façon suivante :

"OnLine" si la solution applicom est initialisée.

"OffLine" si la solution applicom n'est pas initialisée. Dans ce cas, le serveur OPC reprend la configuration que le client a défini dans la console applicom et considère cette configuration comme son espace d’adressage.

Attention : Pour les topics associés à des équipements de type « Logix5000 – Messagerie Logix5000 (OPC seulement) », aucune syntaxe liée au contrôleur Logix5000 ne sera retournée par le browser en mode OffLine.


WoodheadWoodhead


Gestion des groupes (OPC Group) Les groupes constituent pour le client un moyen simple d’organisation des données auxquelles il souhaite accéder. Cette organisation est laissée entièrement libre pour le client. Par conséquent, un groupe peut contenir des variables totalement hétérogènes collectées sur des équipements différents.

Lorsque vous êtes utilisateur d’un progiciel, lui-même client OPC, celui-ci gère généralement les groupes de données de façon totalement transparente et cachée pour l'utilisateur. Si ce n'est pas le cas, des éléments importants sont cependant à prendre en compte dans la création des groupes :

c’est au niveau du groupe que le client a la possibilité de régler la période de rafraîchissement. Toutes les données (OPC Items) contenues dans un même groupe sont donc impérativement scrutées par le serveur OPC à la même fréquence.

le client a la possibilité d’activer ou de désactiver un groupe, c’est à dire d’autoriser ou d’interdire les remontées de données événementielles sur l’ensemble des données du groupe.

la gestion de la bande morte, telle qu'elle est prévue par la spécification OPC, s’effectue au niveau du groupe.

Attention :

Certains logiciels client fixent la période de rafraîchissement du groupe à 0 (retour des informations au plus vite). Il se peut dans certains cas (par exemple lorsque de grandes quantités de points bougent simultanément ou lors de l'utilisation en DCOM), qu’une période très faible dégrade les performances du système en raison de l’importance du flux d’informations circulant entre le serveur et le client. Il est possible de modifier de façon externe la période minimale du rafraîchissement de tous les groupes en modifiant le champ Période de rafraîchissement minimale des groupes.


WoodheadWoodhead


Bande morte Le client a la possibilité de spécifier pour un groupe une “bande morte” qui affectera l’ensemble des items contenus dans le groupe. Ce paramètre indique le pourcentage minimum d’évolution qui provoquera l’envoi de la donnée vers l’application client. Il est apparu que tous les clients OPC ne positionne pas ce paramètre de la même façon. C’est pourquoi le serveur OPC applicom® permet par configuration de définir la plage utilisé. Il peut donc être compris selon ce choix entre :

0 et 100 (1% =1).

Ou entre 0 et 1 (1% = 0.01).

Cette “bande morte” influence uniquement le mode de remontée événementielle de données

La notion même de “bande morte” nécessite que la variable visée soit du type analogique et qu’elle possède une valeur maximale et une valeur minimale permettant de calculer un pourcentage d’évolution. La remontée de la donnée vers l’application client sera effectuée si :

valeur absolue(dernière valeur remontée- valeur courante) > pPercentDeadband *(valeur max- valeur min)

La valeur min et valeur max d’une donnée est fixe, elle est définie par son type :

VT_UI1 de 0 à 255

VT_I1 de -128 à 127

VT_UI2 de 0 à 65535

VT_I2 de -32768 à 32767

VT_UI4 de 0 à 4294967295

VT_I4 de -2147483648 à 2147483647

VT_R4 de –3.4e+38 à 3.4e+38

VT_R8 De -1.79e+308 à 1.79e+308


WoodheadWoodhead


Mode d'accès aux données du serveur OPC Pour accéder aux données depuis un client OPC, la spécification prévoit trois méthodes :

Méthode Commentaire Evénementielle Le client s'abonne sur un groupe afin d'être averti de façon

événementielle des changements intervenus sur les valeurs des items. Seuls les points actifs du groupe ayant changé sont retournés au client. La période de rafraîchissement du groupe fixe la durée minimale entre deux envois de valeurs.

Synchrone Le client demande explicitement la lecture ou l'écriture d'un item. Le client reste bloqué pendant le traitement de sa demande. La lecture synchrone peut s'effectuer depuis deux sources distinctes :

Le device : les valeurs sont lues dans l'équipement physique.

Le cache : les valeurs sont lues dans le cache interne du serveur OPC.

Asynchrone Le client demande explicitement la lecture ou l'écriture d'un item. L'appel est non bloquant. Le résultat de la lecture ou de l'écriture sera retourné ultérieurement. La lecture peut s'effectuer depuis deux sources distinctes :

Le device : les valeurs sont lues dans l'équipement physique.

Le cache : les valeurs sont lues dans le cache interne du serveur OPC.

Lorsque vous êtes utilisateur d’un progiciel, lui-même client OPC, celui-ci gère généralement le mode d'accès aux données de façon totalement transparente et cachée pour l'utilisateur. Si ce n'est pas le cas, des éléments importants sont cependant à prendre en compte :

Le mode événementiel génère un trafic minimum entre le serveur et le client puisque seules les variables ayant bougé sont retournées. Il est donc le plus efficace des trois modes.

En mode asynchrone, si les demandes sont effectuées plus rapidement que ne peut les traiter le serveur, elles sont empilées. Si trop de requêtes sont mises en attente, des demandes peuvent être refusées.

Les lectures dans le cache sont par définition plus rapides que les lectures effectuées dans l'équipement.


WoodheadWoodhead


Horodatage des données Avec le serveur OPC applicom®, l’horodatage d’une donnée indique le temps correspondant au dernier accès à la variable par le serveur. Il n’indique pas le dernier changement de valeur mais la dernière obtention de la valeur. Ainsi, si l’application client effectue deux lectures successives en mode synchrone ou asynchrone sur une même variable, l’horodatage retourné pourra être différent même si la valeur n’a pas changé. Par contre, cette variable ne sera pas envoyée au client par le mode événementiel puisque la valeur n’a pas évolué.

Le serveur OPC optimise en dynamique l'acquisition des données en minimisant les accès aux équipements distants :

une variable ne sera insérée que dans une seule trame de communication, même si cette variable est demandée par le client au sein de plusieurs groupes (chaque groupe pouvant être configuré avec des périodes de rafraîchissement différentes). Il en est de même si plusieurs applications client demandent la même variable. La variable est alors rafraîchie en tenant compte de la période minimale existante pour cette variable.

le serveur OPC regroupe toujours le maximum de variable dans une même trame de communication. Une telle trame peut donc contenir des items appartenant à des groupes possédant des périodes de rafraîchissement différentes. C'est la période minimale qui est alors utilisée.

Dans les deux cas précédents, l'acquisition des données s'effectue avec la période la plus basse de tous les items concernés. La valeur d'horodatage sera en conséquence mise à jour à la même fréquence.

Qualité des items A chaque item retourné vers le client sont associés une qualité et un horodatage. Le tableau suivant indique les différentes qualités utilisées par le serveur OPC applicom® :

Qualité

Déc Hexa Bit Signification

0 0x0000 0000 0000 La qualité du point est mauvaise. La valeur retournée n'est pas exploitable.

20 0x0014 0001 0100 La qualité du point est mauvaise. La valeur retournée correspond à la dernière valeur connue de bonne qualité.

24 0x0018 0001 1000 La donnée n'a pu être lue ou écrite suite à un problème de communication entre les équipements et le serveur. La valeur de la donnée retournée n'est pas exploitable.

64 0x0040 0100 0000 La qualité de la donnée est incertaine. La valeur retournée n'est pas exploitable.

192 0x00C0 1100 0000 La donnée a été correctement lue et les conversions éventuelles ont pu être effectuées.


WoodheadWoodhead


Limitation du nombre d’I/O Items (SW1000ETH seulement) En cas d’utilisation du produit SW1000ETH, en correspondance avec votre commande produit, une limitation d’I/O Items utilisables par l’ensemble des applications clientes peut être appliquée.

Les I/O Items sont des items visant des équipements distants. Ainsi, les items sur la database applicom, ou les items du topic SYSTEME ne sont pas considérés comme des I/O Items. Dans le cas d’un item tableau, le nombre d’I/O Items est égal au nombre de données unitaire du tableau. Dans le cas d’une chaîne, le nombre d’I/O Items comptabilisé est de 1.

Si la même variable physique est accédée par plusieurs applications clientes distinctes, un I/O item est comptabilisé pour chaque client. Lorsque la limite est atteinte, l’ajout de nouveaux items (AddItem) est refusé. Le décompte total est un décompte instantané. Une application peut donc supprimer des I/O items pour en rajouter d’autres.

Des items du topic SYSTEME vous permettent de récupérer au niveau du client OPC les indications importantes relatives à la limitation du nombre des I/O Items. Il s’agit des quatres items suivants :

LIMIT_ALLOWED : Nombre d’I/O Items maximum utilisables Ce nombre est directement lié à la limitation réclamée lors du passage de votre commande produit.

LIMIT_USED : Nombre d’I/O Items instantané

Cet item vous permet d’accéder au nombre d’I/O Items utilisés à cet instant donné.

LIMIT_MAX_USED : Nombre d’I/O Items maximum Cet item vous permet de connaître le nombre maximum atteint d’I/O Items utilisés par le serveur OPC depuis son lancement.

LIMIT_OVERFLOW : Avertissement d’atteinte de limitation Cet item peut prendre 3 valeurs :

0 : Le nombre d’I/O Items maximum est resté inférieur à 90% de la limite autorisée

1 : Le nombre d’I/O Items maximum à atteint 90% de la limite autorisée

2 : Le nombre d’I/O Items maximum à dépassé la limite autorisée. Des I/O Items n’ont pu être ajoutés dans le serveur.


WoodheadWoodhead


De plus, la barre d’état de la fenêtre de diagnostic d’OPC affiche les informations sur l’utilisation des I/O Items et sur l’état des dépassements.

Si le nombre d’I/O Items maximum atteint est inférieur à 90% de la limite autorisée, la barre d’état indique les informations de limitation sur un fond gris :

Si le nombre d’I/O Items maximum atteint est supérieur à 90% de la limite autorisée, la barre d’état indique les informations de limitation sur un fond orange :

De plus, un message indiquant cet état est affiché dans la vue des messages.

Si le nombre d’I/O Items maximum atteint est supérieur à la limite autorisée, la barre d’état indique les informations de limitation sur un fond rouge :

De plus, un message indiquant cet état est affiché dans la vue des messages.


Accès aux informations générales du serveur (Topic "SYSTEME")

dans la base de connaissance :

Validation et dévalidation du mode Diagnostic


WoodheadWoodhead


Types de topic d’accès aux variables Le serveur OPC utilise un nom arbitraire appelé topic en tant que chemin d’accès aux variables. Différents types de topics sont disponibles :

Les Topics “variable image” et “variable locale” :

L'utilisateur attribue par configuration un nom significatif à un équipement distant (variable image) ou à la base de données des interfaces (ou de l’émulateur) applicom (variable locale), et l'utilise en tant que topic pour accéder ensuite aux variables internes de celui-ci (par ex. DATA_BASE, AUT1...). Le nombre de topics configurables n’est pas limité.

Vous pouvez définir plusieurs noms de topics pour un même équipement.

Le Topics “prédéfinis” :

Le serveur OPC reconnaît un certain nombre de topics prédéfinis :

le topic "SYSTEME", permettant d’accéder à des informations générales du serveur

les topics "CARDx" (x de 1 à 8) permettant d’accéder à des fonctionnalités ratachées à une interface applicom( Non supporté en Direct-Link )

les topics "CHANx" (x de 0 à 31) permettant d’accéder à des fonctionnalités ratachées à un canal particulier ( Non supporté en Direct-Link )

Le Topics “Fonction cyclique” : ( Non supporté en Direct-Link )

L'utilisateur attribue par configuration un nom significatif à une fonction cyclique configurée à l’aide de "PCCYC", et l’utilise en tant que topic pour accéder aux paramètres de la fonction cyclique et pour modifier celle-ci à volonté.

Voir également: Dans ce manuel :

Accès aux Variables images ou locales

Dans la documentation :

Fonctionnalité : Database


WoodheadWoodhead


Configuration des topics Le serveur OPC utilise un nom arbitraire appelé topic en tant que chemin d’accès aux variables. La configuration de ces topics s’opère à partir de la console applicom.

Vous pouvez accéder à la configuration de tous les topics (variable image, variable locale, fonction cyclique) à partir de la vue description de la configuration, en utilisant les nœuds Topic configuration. Pour configurer le topic attribué à un équipement connecté au réseau de terrain (variable image), vous pouvez également :

Sélectionner le nœud Topic configuration directement situé sous l’équipement concerné dans la zone vue protocole de la console applicom.

Lancer la commande Propriétés ou double-cliquez sur le nœud.

La configuration des topics vous permettra de modifier notamment le nom du topic, le commentaire associé ainsi que des paramètres avancés tel que les longueurs maximum des trames et la gestion des messages.


Paramètrage minimal d’un topic "variable image" ou "variable locale"


Mise en œuvre : configuration des topics


WoodheadWoodhead

Serveur OPC • 19 • Accès aux Variables images ou locales

4. Accès aux Variables images ou locales

Le serveur OPC met à votre disposition deux principaux types de variables :

Les “variables locales” : Ce sont les variables d’une zone de données locales (data-base) maintenue en mémoire par les interfaces ou l’émulateur logiciel.

Domaines d’utilisation :

Vous devrez impérativement accéder à ces variables dans le cas d’un fonctionnement en mode esclave ou serveur. En effet, le dialogue avec les équipements distants ne peut se faire qu’à travers la data-base. Cependant, dans le cas d’un canal maître/client, l’utilisateur peut préférer configurer lui même ses trames de lecture (fonctions cycliques configurées avec l’utilitaire PCCYC) pour accéder à un équipement distant ( Non supporté en Direct-Link ).

La data base constitue également un moyen possible de partage de données entre plusieurs applications cliente OPC

Avantages :

Le nombre minimum de topics est restreint (un seul topic par carte peut suffire).

Restrictions :

Dans le cas d’un dialogue avec un équipement distant au travers d’un canal maître/client, il n’est pas possible d’effectuer une écriture directement dans l’équipement. L’écriture s’effectuera uniquement dans la data-base. Ce problème peut éventuellement être contourné en utilisant des fonctions cycliques d’écriture déclenchées Non supporté en Direct-Link .

De plus, vous devrez impérativement utiliser le “Descripteur standard pour l’accès à la Data-base”. L’applicatif ne pourra pas forcément utiliser des adresses identiques à celles des automates (mapping data-base).

Les “variables images”: Ce sont les variables disponibles dans les équipement distants. Elles sont accessibles au travers d’un topic de type “variable image”.

Domaines d’utilisation :

Elles sont accessibles en lecture et écriture au travers des canaux Maîtres/clients des solutions applicom®.


WoodheadWoodhead


Avantages :

Dans ce cas, des requêtes de lecture sont automatiquement créées par le serveur en fonction des besoins en variables dans les applications clients. Jusqu'à 1024 trames peuvent être générées par canal. Elles sont en permanence optimisées pour minimiser la communication.

Vous avez la possibilité de travailler avec des adresses et des syntaxes constructeurs. Une écriture est directement répercutée dans l’équipement distant.

Restrictions :

Ce mode vous impose de définir autant de topics que d’équipements distants.

Voir également:

Dans ce manuel :

Paramètrage minimal d’un topic "variable image" ou "variable locale"

Syntaxes des variables internes

Contrôle des fonctions cycliques de PCCYC

Descripteur standard pour l’accès à la data-base


Fonctionnalité : Database


WoodheadWoodhead


Paramètrage minimal d’un topic "variable image" ou "variable locale" Le simple fait d’avoir créé un topic et de lui avoir associé le chemin d’accès auquel il correspond (numéro de carte, numéro de canal et numéro d’équipement) suffit à son utilisation dans l’applicatif client. Pour la plupart des protocoles, chaque ajout d’équipement donnera lieu à la création automatique d’un topic.

Tous les autres paramètres nécessiteront éventuellement une modification dans les cas suivants :

si vous utilisez certaines fonctionnalités particulières du produit (mode message ou tableau, items personnalisés,…).

si des options avancées s’avèrent nécessaires pour s’adapter à des protocoles ou des types d’équipements particuliers.



Syntaxes des variables internes La syntaxe de la variable correspond au nom de l’item.

Cette dernière permet de désigner la variable locale ou la variable image. Pour les variables images, la syntaxe à utiliser est liée au type d’équipement visé. Un descripteur de syntaxe approprié vous permet en effet d’utiliser certains mnémoniques constructeur, rendant ainsi l’interfaçage plus convivial.

Dans le cas de “variables locales”, vous devrez utiliser des mnémoniques applicom®. Par exemple, le mot de 16 bits situé à l’adresse 10 sera désigné par W10. L’ensemble des mnémoniques utilisables est décrit dans le chapitre “Descripteur standard pour l’accès à la Data-base”

Dans le cas des “variables images”, vous pourrez utiliser des mnémoniques semblables aux syntaxes constructeur. Par exemple, sur un équipement Siemens Simatic® S7, le mot 10 du DB1 sera identifié par DB1.DBW10. Le descripteur adapté à l’équipement visé est déterminé de façon automatique par le logiciel applicom®. Pour consulter les syntaxes autorisées par les différents descripteurs fournis pour votre protocole, reportez-vous au tableau suivant. Remarque avancée : Vous avez cependant la possibilité de forcer l'utilisation d'un autre descripteur (en général, le descripteur standard, composé de syntaxes génériques utilisables quel que soit le protocole ou la messagerie. Ce descripteur peut être positionné par le biais des options avancées). Attention cependant, le descripteur de syntaxes détermine également certaines capacités d’optimisation des requêtes liées au type d’équipement visé et au mapping des données de cet équipement. Si vous changez le descripteur par défaut, certaines optimisations d'accès aux équipements se trouveront ainsi dévalidées, au détriment possible des performances.


WoodheadWoodhead


Type de protocole

Descripteur d’items

Nom du fichier du descripteur

Cegelec sur TCP/IP Alspa C80-35 et C80-75 ITEMCEGE.DLL

UniTe sur TCP/IP Telemecanique TSX Premium

ITEMTSX.DLL

Mitsubishi sur TCP/IP Mitsubishi Serie A, Serie Q ITEMMIT.DLL

GE Fanuc sur TCP/IP Séries 90-30 et 90-70 ITEMSNPX.DLL

Alnet II TCP/IP (Altus) sur TCP/IP ALNET II ITEMALT.DLL

EtherNet/IP (Allen Bradley) sur TCP/IP Allen-Bradley ITEMAB.DLL

Omron sur TCP/IP

Equipement Sysmac C Sysmac C ITEMOMRO.DLL

Equipement Sysmac CS Sysmac CS ITEMOMRO.DLL

Equipement Sysmac CV Sysmac CV ITEMOMRO.DLL

Modbus sur TCP/IP

Equipement Modicon Modbus Modicon TSX ITEMMOD.DLL

Equipement Telemecanique Telemecanique TSX/PMX ITEMTSX.DLL

Autres equipement Modbus Générique ITEMMDB.DLL

Industrial Ethernet

Messagerie S5/TF Simatic S5 (Indus. Ethernet)

ITEMIES5.DLL

Messagerie TI Texas Instrument ITEMTI.DLL

Messagerie S7 Siemens série 7 ITEMS7.DLL

Jbus RTU

Equipement SMC April-SMC ITEMSMC.DLL

Equipement APRIL April-série 1000 ITEMPB.DLL

Autres équipements Descripteur standard ITEMSTD.DLL

Modbus RTU (solution hardware) Descripteur standard ITEMSTD.DLL

Uni-Telway

Equipement APRIL April-série 1000 ITEMPB.DLL

Autres équipements Télémécanique TSX/PMX ITEMTSX.DLL

3964/3964R, Maître-Client/Serveur Siemens Simatic S5 (syntaxe allemande et française and syntaxe anglaise)

ITEMSIEM.DLL

Sucoma, Maître Descripteur standard ITEMSTD.DLL

Data Link, Maître Otic Fischer&Porter (DataLink)

ITEMOTIC.DLL

Kit4000 Descripteur standard ITEMSTD.DLL

Profibus

Messagerie S5 Siemens Simatic S5 ITEMSIEM.DLL


WoodheadWoodhead


(syntaxe allemande et française et syntaxe anglaise)

Messagerie MPI et S7 Descripteur automates Siemens série 7 pour MPI et S7)

ITEMS7.DLL

Messagerie PROFIBUS DP DP) ITEMDP.DLL

Ethway

Equipement APRIL April-série 1000) ITEMAPRL.DLL

Autres equipements Télémécanique TSX/PMX PLC)

ITEMTSX.DLL

Sysmac Way, Maître Omron (Sysmac-Way)) ITEMOMRO.DLL

DF1 Allen-Bradley ITEMAB.DLL

S-Bus, Maître SAIA ITEMSAIA.DLL

PPI, Maître Siemens Simatic S7 ITEMS7.DLL

Fipway, Client/Serveur

Equipement APRIL April-série 1000 ITEMAPRL.DLL

Autres equipements Télémécanique TSX/PMX PLC

ITEMTSX.DLL

AS511 (prog. port), Maître Siemens Simatic S5 (syntaxe allemande et française et syntaxe anglaise)

ITEMSIEM.DLL

TI-Dir, Maître Texas Instrument ITEMTI.DLL

SNP-X, Maître GE-Fanuc ITEMSNPX.DLL

InterBus-S G3, Maître Descripteur standard ITEMSTD.DLL

Modbus Plus, Client/Serveur

Equipement TSX QUANTUM Modbus Modicon TSX ITEMMOD.DLL

Equipement TSX PREMIUM Télémécanique TSX/PMX ITEMTSX.DLL

Equipement Modicon 984 Modbus Modicon 984 ITEMMOD2.DLL

Equipement Modbus générique Modbus générique ITEMMDB.DLL

Modbus ASCII pour solution hardware

Modbus RTU/ASCII pour SW1000SER

Equipement TSX QUANTUM Modbus Modicon TSX ITEMMOD.DLL

Equipement TSX PREMIUM Télémécanique TSX/PMX ITEMTSX.DLL

Equipement Modicon 984 Modbus Modicon 984 ITEMMOD2.DLL

Equipement MODBUS générique Modbus générique ITEMMDB.DLL


Descripteur standard pour l’accès à la data-base

Principe d’accès aux données


WoodheadWoodhead


Accès aux variables unitaires Les variables unitaires désignent les variables natives locales ou images. Elles peuvent être des types simples suivants :

bits (bit internes, bits d’entrée, bits de sortie)

octets (octets internes, octets d’entrée, octets de sortie)

mots (mots internes, mots d’entrée, mots de sortie)

mots doubles

mots flottants

certains ‘objets’ spécifiques à certains équipements

informations de diagnostic

Les syntaxes des variables internes utilisables dépendent du type d’équipement visé.



Optimisation des requêtes synchrones et asynchrones Lorsque l'application client veut effectuer une demande de lecture ou d'écriture synchrone ou asynchrone, elle appelle une des méthodes disponibles en passant en argument la liste des items concernés par la requête (sauf dans le cas de IOPCAsyncIO::Refresh où tous les items du groupe sont implicitement concernés). Le serveur OPC effectue une analyse préalable de cette liste de manière à optimiser le flux de communication nécessaire :

Dans le cas des méthodes de lecture, l'ensemble des items est scruté et ceux-ci sont regroupés de manière à minimiser le nombre de requêtes.

Dans le cas des écritures, les mécanismes mis en œuvre sont plus compliqués. En effet, des variables pouvant être écrites par une même requête doivent impérativement être contiguës. De plus il est impératif de préserver l'ordre d'envoi des différents items. Le serveur OPC pratique donc de la façon suivante :

il commence le parcours de la liste en partant du premier item.

pour chaque item suivant, il vérifie si celui-ci est d'adresse directement supérieure à l'item précédent.

si l'item n'est pas associable avec le précédent, il envoie la requête correspondant aux items précédents et continue l'exploration jusqu'à la fin de la liste.

Exemple : L'application client souhaite écrire trois mots et deux bits dans la data-base applicom®

si la liste est ordonnée ainsi : W10 W11 W12


WoodheadWoodhead


B20 B21

Dans ce cas, le serveur OPC satisfera à la demande en effectuant seulement deux requêtes. Une d'écriture de trois mots à partir de l'adresse 10 et une autre d'écriture de deux bits à partir de l'adresse 20

si la liste est ordonnée ainsi : B20 W12 W10 W11 B21

Dans ce cas, le serveur OPC satisfera à la demande en effectuant quatre requêtes.

écriture du bit d'adresse 20

écriture du mot d'adresse 12

écriture de deux mots à partir de l'adresse 10

écriture du bit d'adresse 21

Il est donc de la responsabilité de l'application client d'ordonner les items de façon croissante et contiguë pour assurer les performances maximales.

Utilisation du mode tableau Il est possible de regrouper les informations de mêmes types et d’adresses contiguës dans un même “item” sous forme soit :

D’une chaîne ASCII de données séparées par un délimiteur configurable (voir chapitre “Configuration du mode tableau”),

D’un tableau de données binaires

Pour le paramétrage lié à l’utilisation du mode tableau, reportez vous au chapitre - Syntaxes des variables internes.

L’emploi du mode tableau (ASCII ou binaire) s’effectue en concaténant à la syntaxe de la première variable une extension du type :

_n pour le mode tableau ou n réprésente le nombre de données.

Les syntaxes utilisables dépendent du type d’équipement visé. Pour consulter les syntaxes autorisées par le descripteur choisi, reportez vous au chapitre - Configuration du mode tableau.

Attention !

Pour certains protocoles ou certaines messageries, les modes message et tableau nécessitent quelques précautions d'utilisation. En effet, certains protocoles offrent la possibilité dans la console de configurer :

l’alignement des données lors de la lecture de mots de 16 bits

et/ou

l’alignement des données lors de la lecture de mots de 32 bits


WoodheadWoodhead


Ces paramètres agissent directement sur la façon dont sont remontées les données durant leur lecture. Ils n’agissent pas pour l’écriture. Ainsi, dans le cas d'un alignement sur des adresses octets lors de la lecture de mots de 16 bits ou d'un alignement sur des adresses octets ou mots lors de la lecture de mot de 32 bits, l'écriture continue de s'effectuer en adressage mot pour les mots 16 bits et mots doubles pour les mots 32 bits. Avec le mode tableau, un item symbolisant par exemple un tableau de mots (WOx_n) ne désigne pas les mêmes variables en écriture qu'en lecture. Le mode tableau ne pourra donc être utilisé qu'en lecture.

Voir également:

Dans ce manuel :

Accès aux variables unitaires

Configuration du mode tableau et matrice

Principe de remontée des données sous forme ASCII

Configuration du mode tableau et matrice La configuration du mode tableau s’effectue par l’onglet Mode message et tableau de la configuration des topics, accessible depuis la console applicom.




Configuration des topics : mode tableau et matrice

Principe de remontée des données sous forme ASCII Exemples : Item représentant une chaîne de données correspondant à 4 mots à partir du mot 0.

Syntaxe de l’item : W0_4 Représentation des données :

Valeur ASCII

De W0 Délimiteur Valeur ASCII

de W1 Délimiteur Valeur ASCII

de W2 Délimiteur Valeur ASCII

de W3

Les applications clients traitent les données comme des chaînes ASCII.

Utilisation du mode message Le mode message permet d'échanger jusqu’à 131 caractères ASCII en lecture et en écriture entre vos applications clients et les équipements. Une suite d'octets dans l'équipement peut être assimilée à une chaîne de caractères ASCII. Si la suite est localisée dans les octets, le premier octet correspond au premier caractère de la chaîne. Si la suite est localisée dans les mots, le premier caractère de cette chaîne peut être localisé sur les 8 bits de poids faibles ou les 8 bits de poids forts du premier mot de cette suite. Vous devez définir la taille du tableau pouvant contenir cette chaîne. Cette définition est réalisée dans le nom de l'item. La taille de la chaîne de caractères peut être variable, sa valeur maximum étant bien sûr celle de la table allouée pour les octets ou deux fois la taille allouée pour les mots. La chaîne est sauvegardée dans cette table de l'adresse la plus faible vers l'adresse la plus haute.


WoodheadWoodhead


Différents choix permettent de définir un ou plusieurs caractères d'arrêt dans le cas de requêtes de lecture. La chaîne de caractères est tronquée et le ou les caractères d'arrêts définis sont intégrés en fin de chaîne. Dans le cas d'une écriture, ce ou ces caractères d'arrêt sont intégrés dans le message ASCII. Le caractère “NULL”(0) est prioritaire sur les caractères d'arrêt de fin de message configurés. il sera également intégré implicitement au message.

Pour le paramétrage lié à l’utilisation du mode message, reportez vous au chapitre Configuration du mode message.

Les syntaxes utilisables dépendent du type d’équipement visé. Pour consulter les syntaxes autorisées par le descripteur choisi, reportez vous au chapitre - Syntaxes des variables internes





Configuration des topics : mode message

Configuration du mode message La configuration du mode message s’effectue par l’onglet Mode message et tableau de la configuration des topics, accessible depuis la console applicom.

Il vous permet notamment de configurer le Délimiteur de fin de messages.





Configuration des topics : mode message

Bit de mots Les différents descripteurs vous proposent parfois des syntaxes vous permettant d’accéder à un bit au sein d’un octet, d’un mot ou d’un mot double (exemple Ox.b et Wx.b du descripteur standard) même lorsque le protocole ne propose pas cette fonctionnalité de façon native. Le serveur génère dans ce cas des trames d’octets (ou de mots).

Les syntaxes utilisables dépendent du type d’équipement visé. Pour consulter les syntaxes autorisées par le descripteur choisi, reportez vous au chapitre reportez vous au chapitre - Syntaxes des variables internes.




WoodheadWoodhead


Suffixe optionnels

Ces suffixes permettent de personnaliser un “item”.

Représentation en valeur signée => item_S

Type de variables Syntaxe de l’item Exemple

OCTET MOT 16 BITS

item_S O100_S W100_S

item : Représente l’item d’une variable numérique simple.

Ce suffixe permet de traiter l’extension de signe pour les valeurs octets (-128 à +127) et les mots de 16bits (de-32768 à + 32767).

Sans ce suffixe ces grandeurs numériques sont de types non signés (de 0 à 255 pour les octets) et (0 à 65535 pour les mots de 16bits).

Représentation en valeur BCD => item_B

Type de variables Syntaxe de l’item Exemple

OCTET MOT 16 BITS

MOT DOUBLE 32 BITS

item_B O100_B W100_B D100_B

item : Représente l’item d’une variable numérique simple.

Ce suffixe permet de transcoder les données d’un octet, mot ou mot double stocké dans l’équipement comme une entité BCD de 1, 2 ou 4 octets non signés (décimal digit) et les convertit au format binaire.

Cette extension n’est pas autorisée dans le cas des chaînes ou des matrices et elle s’applique en lecture et en écriture.

Croisement des octets => item_Xx

Ces suffixes permettent le croisement des octets composant une donnée de type mot 16 bits, mot double 32 bits ou mot flottant. Ils peuvent être utilisés sur des données de type numérique simple, sur l’ensemble des données d’un tableau ou sur un objet.

Le tableau suivant présente les différents types de croisement en fonction du suffixe et du type de l’item :

Mot 16 bits Double mot 32 bits / Flottant _X1 O1 O2 -> O2 O1 (Croisement

des octets) O1 O2 O3 O4 -> O4 O3 O2 O1 (Croisement

des octets)


WoodheadWoodhead


_X2 O1 O2 -> O2 O1 (Croisement des octets)

O1 O2 O3 O4 -> O3 O4 O1 O2 (Croisement des mots)

_X3 O1 O2 -> O2 O1 (Croisement des octets)

O1 O2 O3 O4 -> O2 O1 O4 O3 (Croisement des octets dans les mots)

Le croisement des octets, pour un item "variable locale", peut aussi se configurer directement dans le topic. L’utilisation de ce suffixe est prioritaire par rapport à la configuration pour le topic.

Descripteur standard pour l’accès à la data-base Mode Unitaire Mode Tableau

Bits Bx Bx_n Octets Ox Ox_n Bits dans des octets Ox.b Chaîne ASCII dans les octets M_Ox_n Mots Wx Wx_n Bits dans des mots Wx.b Chaîne ASCII dans les mots M_Wx_n Mots doubles Dx Dx_n Mots flottants Fx Fx_n

Voir également:

Dans ce manuel :

Utilisation du mode tableau

Utilisation du mode message

- Bits => Bx (type : BIT)

x : Numéro du premier bit (0 à 32767)

Exemple : B4

- Bits => Bx_n

x : Numéro du premier bit (0 à 32767)

n : Nombre de bits.(2 à 128)

Exemple : B4_10

- Octets => Ox (type : OCTET)

x : Numéro du premier octet (0 à 13999)

Exemple : O4


WoodheadWoodhead


- Octets => Ox_n


n : Nombre d’octets (2 à 128)

Exemple : O4_10

- Bits dans des octets => Ox.b (type : BIT)


b : Rang du bit dans l’octet(0 à 7).

Exemple : O4.3

- Chaîne ASCII dans les octets => M_Ox_n (type : OCTET)

Pour plus d'information sur l'utilisation des chaînes ASCII, vous pouvez consulter le chapitre "Utilisation du mode message".

x : Numéro du premier octet contenant la chaîne (0 à 13999).

n : Nombre d’octets potentiels pouvant contenir la chaîne ASCII (1 à 131).

Exemple : M_O100_30

Dans l’exemple la table d’octets O100 à O129 peut contenir la chaîne.

- Mots => Wx (type : MOT 16 bits)

x : Numéro du premier mot (0 à 32767).

Exemple : W4

- Mots => Wx_n


n : Nombre de mots(2 à 64).

Exemple : W4_10

– Bits dans des mots => Wx.b


b : Rang du bit dans le mot(0 à 15).


WoodheadWoodhead


Exemple : W4.10

- Chaîne ASCII dans les mots => M_Wx_n (type : MOT 16 bits)

Pour plus d'information sur l'utilisation des chaînes ASCII, vous pouvez consulter le chapitre "Utilisation du mode message".

x : Numéro du premier mot contenant la chaîne.

n : Nombre de mots potentiels pouvant contenir la chaîne ASCII (1 à 65).

Exemple : M_W100_30

Dans l’exemple la table de mots W100 à W129 peut contenir la chaîne.

- Mots doubles => Dx (type : MOT 32 bits)

x : Numéro du premier mot double (0 à 32766).

Exemple : D4

- Mots doubles => Dx_n x : Numéro du premier mot double (0 à 32766).

n : Nombre de mots doubles.(2 à 64)

Exemple : D4_10

- Mots flottant => Fx (type : MOT 32 bits IEEE)

x : Numéro du premier mot de32 bits IEEE(0 à 32766)

Exemple : F4

- Mots doubles => Fx_n

x : Numéro du premier mot de32 bits IEEE(0 à 32766)

n : Nombre de mots doubles.

Exemple : F4_10

Descripteur standard d’accès aux variables images

Dans le cas des “variables images”, vous pourrez utiliser des mnémoniques semblables aux syntaxes constructeur. Par exemple, sur un équipement Siemens Simatic® S7, le mot 10 du DB1 sera identifié par DB1.DBW10. Le descripteur adapté à l’équipement visé est déterminé de façon automatique par le logiciel. Vous avez cependant la possibilité de forcer l'utilisation d'un autre descripteur (en général, le descripteur


WoodheadWoodhead


standard, composé de syntaxes génériques utilisables quel que soit le protocole ou la messagerie. Ce descripteur peut être positionné par le biais des options avancées). Attention cependant, le descripteur de syntaxes détermine également certaines capacités d’optimisation des requêtes liées au type d’équipement visé et au mapping des données de cet équipement. Si vous changez le descripteur par défaut, certaines optimisations d'accès aux équipements se trouveront ainsi dévalidées, au détriment possible des performances.

Syntaxes du descripteur standard :

Mode unitaire Mode tableau Bits Bx Bx_n Bits d’entrée BIx BIx_n Bits de sortie BOx BOx_n Octets Ox Ox_n Octets d’entrée OIx OIx_n Octets de sortie OOx OOx_n Bits dans des octets Ox.b Chaîne ASCII dans les octets M_Ox_n Mots Wx Wx_n Mots d’entrée WIx WIx_n Mots de sortie WOx WOx_n Bits dans des mots Wx.b Chaîne ASCII dans les mots M_Wx_n Mots doubles Dx Dx_n Mots flottants Fx Fx_n

x : adresse de la donnée. Doit être calculée selon la formule précisée dans le manuel du protocole visé.

b : offset du bit dans l’octet (de 0 à 7) ou dans le mot (0 à 15).

n : taille du tableau

Information de diagnostics et contrôle

Status des équipements => STATUS Type de variables Syntaxe de l’item Exemple

MOT 16 BITS STATUS STATUS MOT 16 BITS STATUS_READ STATUS_READ MOT 16 BITS STATUS_WRITE STATUS_WRITE

Pour chaque Topic, vous pouvez lire un status local d’écriture (STATUS_WRITE), un status local de lecture (STATUS_READ) et un status recoupant les deux (STATUS). Ils vous donnent des informations concernant les accès aux équipements. La valeur des Status peut évoluer de 0 à 65535. Ci-dessous les principaux status sont répertoriés.


WoodheadWoodhead


Pour plus d’informations, veuillez consulter les manuels protocoles au chapitre “Status de retour des fonctions”.

Valeurs courantes :

0 : Aucune erreur.

255 : c’est la valeur initiale des items de status pour un topic tant qu’aucune transaction n’a été effectuée.

Pour les autres valeurs, référez-vous au manuel protocole.

Nombre de défauts d’advise => ADVISE_FAILED Permet d’accéder au nombre de défauts d’advise survenus pour un “Topic standard”, c’est à dire le nombre de points refusés par OPC en raison d’une mauvaise syntaxe. Cette donnée n’est accessible qu’en lecture.

Nombre d’erreurs d’écriture => WRITE_ERROR Permet d’accéder au nombre d’erreurs d’écriture survenues pour un “Topic standard”. Cette donnée n’est accessible qu’en lecture.

Nombre d’erreurs de lecture => READ_ERROR Permet d’accéder au nombre d’erreurs de lecture survenues pour un “Topic standard”. Cette donnée n’est accessible qu’en lecture.


WoodheadWoodhead


Les noms symboliques Le serveur OPC applicom®, met à votre disposition un moyen supplémentaire d’accès aux variables :

Les “noms symboliques”

Le but du “nom symbolique” est de remplacer le nom d’une “variable locale” ou d’une “variable image” par un mot ayant un sens pour l’utilisateur. Par exemple, Il est possible de remplacer la syntaxe “DB1.DBW10” par le mot “Température”, ce dernier étant beaucoup plus expressif pour un utilisateur.

Fonctionnement

Serveur OPC

Serveur

OPC

Utilitaire de Conversion

Fichier Symbols.sym

Fichier .CSV

Fichier .SCY Fichier .FEF

Pour reconnaître un symbole, le serveur OPC se constitue des listes d’associations (symbole, syntaxe). Celles-ci sont chargées à partir d’un fichier Symbols.sym. Ce dernier est généré à l’aide d’un utilitaire de conversion permettant d’importer ces symboles soit depuis des fichiers provenant d’outils du marché (exemple : PL7 junior de SCHNEIDER) , soit depuis des fichiers d’un format propriétaire (.CSV).

Remarque : Le fichier SYMBOLS.SYM est présent dans le répertoire d’installation du produit applicom®. Il est possible de le visualiser à l’aide du “bloc note” afin de connaître l’ensemble des symboles actuellement reconnus par le serveur OPC. Cependant, il ne faut en aucun cas le modifier directement ou l’utiliser dans l’une de vos applications car son format est sujet à modifications. Si vous désirez importer d’autres formats de fichiers que ceux actuellement proposés, consultez-nous.


WoodheadWoodhead


Création d’une nouvelle liste de noms symboliques Pour attacher une nouvelle liste de noms symboliques à un équipement, il faut importer ceux-ci au préalable avec un utilitaire de conversion à partir d’un fichier :

propriétaire au format “.CSV”,

Les fichiers CSV peuvent être créés avec EXCEL ou avec le “Bloc-notes”. Ce sont des fichiers texte utilisant le “;” comme séparateur de champs. Ces fichiers ont le format suivant :

NomSymbolique1;Syntaxe1



La syntaxe correspond à un mnémonique utilisable en fonction de l’équipement visé. Ces mnémoniques sont documentés dans les différents manuels protocole.

au Format .SCY ou FEF (fichier d’exportation des noms de symboles générés avec le logiciel PL7 junior de SCHNEIDER),

Cette importation se fait au moyen de l’utilitaire IMPSYMB. Celui-ci se présente sous la forme suivante :

La zone “Type de Variable”

La zone Type de Variable permet d’indiquer à quoi vont se rattacher les symboles qui vont être lus dans le fichier source (CSV, SCY, FEF). Les variables peuvent être de type :

variables locales (donc attachée à la data-base). Il faut alors indiquer le numéro de carte sur laquelle se trouve la data-base,

variables images. Dans ce cas, il faut renseigner le numéro de carte, de canal ainsi que le numéro d’équipement sur lequel on désire affecter les symboles.


WoodheadWoodhead


Le bouton “Ouvrir un fichier”

Le bouton Ouvrir un fichier... affiche une boîte de dialogue permettant de localiser et d’ouvrir le fichier de symboles. Attention, l’extension du fichier détermine sa façon d’être importé. Si l’extension est .CSV le fichier est considéré comme étant au format CSV décrit plus haut, Si l’extension est .SCY ou FEF, le fichier est traité comme un fichier de symboles provenant du logiciel PL7 junior.

La zone “Si des symboles existent déjà, que doit faire IMPSYMB ?”

Cette zone permet de choisir le comportement de l’utilitaire de conversion :

Supprimer les anciens symboles. : supprime avant l’importation les symboles déjà existant sur l’équipement visé.

Garder les symboles existant ; en cas de doublon supprimer l’ancien symbole permet de garder l’ensemble des symboles. En cas de doublon le symbole actuellement dans le fichier est supprimé et le nouveau est inséré.

Garder les symboles existant ; en cas de doublon ne pas insérer le nouveau permet de garder l’ensemble des symboles. En cas de doublon le symbole le nouveau n’est pas inséré.

Garder les symboles existant ; en cas de doublon demander à l’utilisateur permet de garder l’ensemble des symboles. En cas de doublon l’utilisateur est interrogé.

le bouton “Importer”

Après avoir renseigné les autres champs, le bouton Importer lance l’importation des symboles et leur insertion dans le fichier SYMBOLS.SYM.

Désignation des noms symboliques dans OPC Une fois l’importation des noms symboliques effectuée pour un équipement donné, l’application client référence un nom symbolique en effectuant la concaténation :

du chemin du périphérique contenant la variable

En utilisant un nom de topic configuré

NomTopic.Symbols

Les syntaxes du type "CardX.Database.Symbols" et "CardX.ChannelY.EquipmentZ.Symbols" sont également supportées pour compatibilité.

d’un nom de variable symbolique

Exemple de syntaxe : Card1.Channel0.Equipment1.Symbols.TEMPERATURE


WoodheadWoodhead

Serveur OPC • 37 • Accès aux Variables images d’un contrôleur Logix 5000

5. Accès aux Variables images d’un contrôleur Logix 5000

Les “variables images”: Ce terme désigne les variables disponibles du ou des contrôleur(s) Logix 5000 distant(s). Elles sont accessibles au travers d’un topic de type “variable image”. Vous devrez définir autant de topics que d’équipements distants.

Les variables images sont accessibles en lecture et en écriture

Les requêtes de lecture sont automatiquement créées par le serveur en fonction des besoins en variables dans les applications clients. Jusqu'à 1024 transactions peuvent être générées par canal. Elles sont en permanence optimisées pour minimiser la communication. Ces transactions contiennent des tags directement définis au sein du contrôleur Logix 5000 auquel vous accédez.

Les écritures sont directement répercutées dans l’équipement distant.

Paramétrage d’un topic "variable image" d’un contrôleur Logix 5000 Le simple fait d’ajouter un équipement de type « Logix5000 - Messagerie Logix5000 (OPC Seulement)» crée un topic associé à cet équipement et suffit à son utilisation dans l’applicatif client.

Cependant, le topic contient le paramètre suivant sur lequel vous pouvez intervenir :

« Optimiser l’accès au champs d’une structure »

Si ce paramètre est coché et qu’un item représentant un champs d’une structure de taille inférieure ou égale à 488 octets est demandé par un client, le tag identifiant la structure complète sera placé dans une transaction. Ainsi, si tout autre item représentant un champ différent de cette même structure est ajouté, aucune modification de transaction ne sera nécessaire. Si ce paramètre n’est pas coché, chaque champs de la structure sera ajouté dans les transactions de façon indépendante.

Voir également: - dans ce manuel :



WoodheadWoodhead


Syntaxes des variables internes Les syntaxes accessibles dans le serveur OPC applicom® sont divisibles en deux catégories :

Les syntaxes obtenues directement par accès en ligne au contrôleur Logix5000. Lors du browsing des items, ces syntaxes sont regroupées sous un nœud « online » placé en dessous du nom du topic. (voir : Accès au données )

Les syntaxes de diagnostic et de contrôle. celles-ci sont spécifiques au serveur OPC applicom® et sont situées lors du browsing directement sous le nom du topic. (voir : Informations de diagnostic et contrôle.)

Voir également:

- dans ce manuel :


- dans la documentation :

Manuel Allen-Bradley sur EtherNet/IP : « Accès aux données »

Optimisation des requêtes synchrones et asynchrones Lorsque l'application client veut effectuer une demande de lecture ou d'écriture synchrone ou asynchrone, elle appelle une des méthodes disponibles en passant en argument la liste des items concernés par la requête (sauf dans le cas de IOPCAsyncIO::Refresh où tous les items du groupe sont implicitement concernés). Le serveur OPC effectue une analyse préalable de cette liste de manière à optimiser le flux de communication nécessaire :

Dans le cas des méthodes de lecture, l'ensemble des items est scruté et ceux-ci sont regroupés de manière à minimiser le nombre de requêtes.

Dans le cas des écritures, les mécanismes mis en œuvre sont plus compliqués. En effet, des variables pouvant être écrites par une même requête doivent impérativement être contiguës. De plus il est impératif de préserver l'ordre d'envoi des différents items. Le serveur OPC pratique donc de la façon suivante :

il commence le parcours de la liste en partant du premier item.

pour chaque item suivant, il vérifie si celui-ci est d'adresse directement supérieure à l'item précédent (valable uniquement pour des items de type tableau).

si l'item n'est pas associable avec le précédent, il envoie la requête correspondant aux items précédents et continue l'exploration jusqu'à la fin de la liste.

Voir également : - dans la documentation :

Manuel Allen-Bradley sur EtherNet/IP « Optimisations en Lecture »

Manuel Allen-Bradley sur EtherNet/IP « Optimisations en Ecriture »


WoodheadWoodhead


Limitations La solution applicom® utilisée avec le contrôleur Logix5000 ne supporte pas les fonctionnalités standards applicom® suivantes :

Les extensions _B (format BCD)et _S (Forçage en valeur signée)

Les extensions de syntaxes « Bits de mots »

Les noms symboliques

Les mécanismes de redondance entre 2 équipements


Status des équipements => STATUS Type de variables Syntaxe de l’item Exemple

MOT 16 BITS STATUS STATUS MOT 16 BITS STATUS_READ STATUS_READ MOT 16 BITS STATUS_WRITE STATUS_WRITE

Pour chaque Topic, vous pouvez lire un status local d’écriture (STATUS_WRITE), un status local de lecture (STATUS_READ) et un status recoupant les deux (STATUS). Ils vous donnent des informations concernant les accès aux équipements. La valeur des Status peut évoluer de 0 à 65535. Ci-dessous les principaux status sont répertoriés.

Pour plus d’informations, veuillez consulter les manuels protocoles au chapitre “Status de retour des fonctions”.

Valeurs courantes :

0 : Aucune erreur.

255 : c’est la valeur initiale des items de status pour un topic tant qu’aucune transaction n’a été effectuée avec l’émulateur.

Les autres valeurs représente une erreur. Consultez le manuel protocole associé pour connaître la signification de la valeur

Nombre de défauts d’advise => ADVISE_FAILED Permet d’accéder au nombre de défauts d’advise survenus pour un “Topic standard”, c’est à dire le nombre de points refusés par OPC en raison d’une mauvaise syntaxe. Cette donnée n’est accessible qu’en lecture.


WoodheadWoodhead


Nombre d’erreurs d’écriture => WRITE_ERROR Permet d’accéder au nombre d’erreurs d’écriture survenues pour un “Topic standard”. Cette donnée n’est accessible qu’en lecture.

Nombre d’erreurs de lecture => READ_ERROR Permet d’accéder au nombre d’erreurs de lecture survenues pour un “Topic standard”. Cette donnée n’est accessible qu’en lecture.


WoodheadWoodhead

Serveur OPC • 41 • Accès aux paramètres des fonctions cycliques

6. Accès aux paramètres des fonctions cycliques

( Non supporté en Direct-Link )

Le configurateur de fonctions cycliques “PCCYC” vous permet de configurer jusqu’à 255 fonctions cycliques par canal. Celles-ci sont chargées sur la carte lors de l’initialisation des interfaces applicom® et rapatrient dès lors des données des équipements vers la data-base applicom® (ou inversement) de manière périodique. L’utilisateur peut configurer des topics fonction cyclique, chacun lui permettant de faire référence à une de ces fonctions cycliques. Au travers de ces topics, il sera possible de manipuler tous les paramètres afférents à la fonction cyclique, au même titre que la fonction “createcyc” si vous utilisez la DLL applicom®.

Le champ Période de rafraîchissement conserve la même signification que pour les Topics standards.

Voir également:

Dans ce manuel :


Contrôle des fonctions cycliques de PCCYC

Items liés à un topic "fonction cyclique"


Mise en œuvre : configuration des topics

Contrôle des fonctions cycliques de PCCYC ( Non supporté en Direct-Link )

Les fonctions cycliques configurées par l’outil PCCYC peuvent être contrôlées par :

Un topic fonction cyclique

Un couple “Flag de commande” “Mot d’état”

Le topic fonction cyclique :

Il vous permet d’accéder à tous les paramètres d’une fonction cyclique de PCCYC et d’effectuer ainsi une reconfiguration en dynamique grâce aux items :

PERIOD TYPE EQUIP_ADDR STATUS_FCYC ACTIVE DB_TYPE_VAR DB_ADDR ACTIVE_ONE

EQUIPMENT NUMBER_VAR STATUS_ADDR


WoodheadWoodhead


Ces items vous permettent notamment de démarrer, d’arrêter, ou de n’activer qu’une seule fois la fonction cyclique visée.

Le couple “Flag de commande” “Mot d’état” : Les 128 premières fonctions cycliques de chaque canal de la carte peuvent être déclenchées. Pour ce faire, une zone de 512 bits de “Flag de commande” et une zone de 512 mots “Mot d’état” sont réservées dans la data-base applicom®.

La zone des bits commence à l'adresse 32200. La zone des mots commence à l'adresse 32100. Elles permettent de démarrer, arrêter, ou n’activer qu’une seule fois la fonction cyclique visée. Cette méthode présente l’avantage de ne pas nécessiter la configuration d’un topic supplémentaire. C’est cette méthode qui devra être utilisée dans le cas des fonctions d’écritures déclenchées (émission de variables locales vers un équipement distant),

La formule pour trouver l'adresse du flag de commande est : 32200 + numéro de canal * 128 + numéro de fonction

La formule pour trouver l'adresse du mot d’état est : 32100 + numéro de canal * 128 + numéro de fonction

Numéro

De Canal

Numéro de fonction cyclique

Zone adresse “Mot d’état”

dans data-base zone mots

Zone adresse “Flag de commande” dans data-base zone

bits 0 1 à 128 32101 à 32228 32201 à 32328 1 1 à 128 32229 à 32356 32329 à 32456 2 1 à 128 32357 à 32484 32457 à 32584 3 1 à 128 32485 à 32612 32585 à 32712

Exemple :

L'adresse du “Flag de commande” et du “Mot d’état” de la fonction numéro 2 du canal 3 est égale à :

adresse bit = 32200 + 3 * 128 + 2 32586

adresse mot = 32100 + 3 * 128 + 2 32486

En positionnant à un le bit “flag de commande” correspondant à la fonction cyclique voulue, le Serveur positionnera la fonction dans l’état défini par la valeur du “mot d’état” :

“mot d’état” = 0 : Activation ponctuelle de la fonction cyclique (Une seule fois).

“mot d’état” = 1 : Démarrage de la fonction cyclique.

“mot d’état” = 2 : Arrêt de la fonction cyclique.

Items liés à un topic "fonction cyclique" ( Non supporté en Direct-Link )

Ces Items permettent d’accéder au différents paramètres d’une fonction cyclique configurée par le configurateur de fonctions cycliques PCCYC, au travers du Topic fonction cyclique qui lui est associé. Les items utilisables sont décrits ci-dessous. La plupart correspondent à un paramètre de la fonction CREATECYC (indiqué en italique) de la DLL.

Pour connaître les valeurs possibles de chacun de ces paramètres, reportez-vous à la fonction CREATECYC du “Manuel de référence librairie” applicom®.

Période de rafraichissement => PERIOD


WoodheadWoodhead


Paramètre per de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder à la période de la fonction cyclique. La valeur est un multiple de 100 ms.

Accessible en lecture / écriture.

Activation / désactivation => ACTIVE Paramètre act de la fonction applicom® CREATECYC.

Cet item vous permet d’activer (poke de la valeur 1) ou de desactiver (poke de la valeur 0) la fonction cyclique.


Numéro d’équipement cible => EQUIPMENT Paramètre neq de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder au numéro d’équipement cible.


Type d’échange => TYPE Paramètre typf de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder au type d’échange.


Type de variable dans data-base => DB_TYPE_VAR Paramètre vardb de la fonction CREATECYC.

Cet item vous permet d’accéder au type de variable dans la data-base.


Nombre de variable => NUMBER_VAR Paramètre nb de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder au nombre de variable.


Adresse variable dans l’équipement => EQUIP_ADDR Paramètre adreq de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder à l’adresse de la première variable dans l’équipement.


Adresse variable dans data-base => DB_ADDR Paramètre adrdb de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder à l’adresse de la première variable dans la data-base.



WoodheadWoodhead


Adresse status dans data-base => STATUS_ADDR Paramètre adrstat de la fonction applicom® CREATECYC.

Cet item vous permet d’accéder à l’adresse de rangement du mot status dans la data-base.


Status de la fonction cyclique => STATUS_FCYC Cet item vous permet d’accéder au status de la fonction cyclique.

Accessible en lecture.

Activation ponctuelle => ACTIVE_ONE Cet item vous permet d’activer ponctuellement (par poke de la valeur 1) la fonction cyclique.


La valeur remontée lors d’une lecture n’est pas significative (toujours = 0).


WoodheadWoodhead

Serveur OPC • 45 • Accès aux informations générales du serveur (Topic "SYSTEME")

7. Accès aux informations générales du serveur (Topic "SYSTEME")

Ce topic prédéfini permet d’accéder à des informations générales du serveur. Il est utilisable avec les items suivants :

Nombre de topics en cours => NB_TOPIC Cet item vous permet d’accéder au nombre de topics accessibles.

Nombre de points en cours => NB_POINT Cet item vous permet d'obtenir le nombre de points en communication.

Nombre d’I/O Items maximum utilisable => LIMIT_ALLOWED (SW1000ETH seulement) Ce nombre est directement lié au code d’installation qui vous a été délivré.

Nombre d’I/O Items instantané => LIMIT_USED (SW1000ETH seulement) Cet item vous permet d’accéder au nombre d’I/O Items utilisé à cet instant donné.

Nombre d’I/O Items maximum => LIMIT_MAX_USED (SW1000ETH seulement) Cet item vous permet de connaître le nombre maximum atteint d’I/O Items utilisés par le serveur OPC depuis son lancement.

Etat d’atteinte de limitation => LIMIT_OVERFLOW (SW1000ETH seulement) Cet item peut prendre 3 valeurs :

0 : Le nombre d’I/O Items maximum est resté inférieur 90% de la limite autorisée

1 : Le nombre d’I/O Items maximum à atteint 90% de la limite autorisée

2 : Le nombre d’I/O Items maximum à dépassé la limite autorisée. Des I/O Items n’ont pu être ajoutés dans le serveur.

Voir également:

Dans ce manuel :


Limitation du nombre d’I/O Items (SW1000ETH seulement)

Interface de Diagnostic


WoodheadWoodhead

Serveur OPC • 46 • Accès au WatchDog et à l’entrée TOR (Topics "CARDx")

8. Accès au WatchDog et à l’entrée TOR (Topics "CARDx")


Le ‘x’ est le numéro de carte applicom® compris entre 1 et 8. Chacun de ces topics identifie une carte applicom®. Ils sont utilisables avec les items suivants :

Chien de garde => WATCHDOG Un contact de chien de garde est à la disposition de l’utilisateur sur chaque interface applicom®. Ce contact peut être forcé fermé, ouvert ou rafraîchi pour une période donnée. Cette fonction se comporte comme un monostable.

Le contact se ferme sur une écriture de cet item et retombe après le temps défini dans la variable WATCHDOG.

Ce monostable est automatiquement réarmé à chaque nouvelle écriture. Si votre application génère des écritures périodiques à une fréquence inférieure à la valeur passée au cours de l’écriture, le contact reste fermé.

WATCHDOG = 0 ouverture maintenue du contact WATCHDOG =-1 fermeture maintenue du contact WATCHDOG >0 et !=-1 fermeture du contact durant cette valeur en secondes

Attention : Les accès sont en lecture/écriture.

Si l’interface applicom® est équipée de Prom supérieure ou égale à 3.2, la valeur de retour est le nombre de seconde restant. Dans le cas contraire, la valeur remontée est sans signification (toujours = 0).

Entrée TOR => INPUT Pour les interfaces équipés d’une entrée TOR, Cet item vous permet de remonter le niveau de celle-ci (0 ou 1)

Attention : Les accès sont en lecture seulement.


WoodheadWoodhead

Serveur OPC • 47 • Accès aux signaux modems (Topic "CHANx")

9. Accès aux signaux modems (Topic "CHANx")


Le ‘x’ est un numéro de canal applicom® compris entre 0 et 31. Chacun de ces topics identifie un canal. Ils sont utilisés pour la gestion des signaux modems avec les items suivants :

Signaux RS232 RTS et DTR => RTS_DTR Cet item vous permet de positionner les signaux RTS et DTR.par une écriture. L’accès se fait en écriture seulement. En lecture, cet item remonte la valeur 255 (non significative).

Poke de la valeur 0: RTS =0 et DTR = 0




Signal RS232 CTS => CTS Cet item vous permet d’accèder au signal CTS. Seule la lecture est autorisée.

Signal RS232 DCD => DCD Cet item vous permet d’accèder au signal DCD. Seule la lecture est autorisée.


WoodheadWoodhead

Serveur OPC • 48 • Interface de Diagnostic

10. Interface de Diagnostic

Pour accéder à l'interface de diagnostic, il convient au préalable de sélectionner l'option Autoriser la vue de diagnostic du serveur dans les paramètres du serveur OPC (voir renvoi ci-dessous). Son affichage se fera par l'icône présente dans la barre des tâches de Windows au démarrage du serveur OPC.

Un double clic sur l'icône affiche l'environnement de diagnostic. Un clic avec le bouton droit de la souris propose le menu permettant :

d'afficher la fenêtre de diagnostic. Menu Diagnostic

de fermer le serveur OPC. Menu Exit

L'interface de diagnostic n’est utile que pour les phases de mise au point de votre application. Son utilisation est consommatrice de ressources. Elle ne doit donc pas être activée durant les phases d’exploitation. L'interface de diagnostic permet :

de générer un fichier, exploitable par l’application « DumpLogger.exe », contenant des informations sur les requêtes de communication

de générer un fichier, exploitable par l’application « DumpLogger.exe », contenant des informations sur l’optimisation de la communication

d'espionner plus particulièrement les évènements survenant sur un item

d'afficher des informations sur le déroulement du serveur.


WoodheadWoodhead


Description des commandes générales

Icône Menu Description

Diagnostic – Communication Request Génère le fichier « dumpOPC.xml » dans le

répertoire de configuration, exploitable par l’application « DumpLogger.exe », contenant des informations sur les requêtes de communication Ce bouton lance automatiquement l’application

« DumpLogger.exe » et l’affichage du fichier « dumpOPC.xml »

Diagnostic – Optimisation

communication Génère le fichier « dumpTopic.xml » dans le

répertoire de configuration, exploitable par l’application « DumpLogger.exe », contenant des informations sur l’optimisation de la communication Ce bouton lance automatiquement l’application

« DumpLogger.exe » et l’affichage du fichier « dumpTopic.xml »

Diagnostic - Items Spy Permet d'espionner une liste d'items.

Diagnostic - Output View – None Ferme la zone de messages.

Diagnostic - Output View – Single Affiche une zone où tous les messages sont écrits

les uns après les autres quelque soit leur provenance.

Diagnostic - Output View - Multiple Affiche une zone de messages en les séparant par

types.

Diagnostic - Run VisuCyc Démarre l'application de visualisation des fonctions

cycliques VisuCyc. (Non disponible avec Direct-Link)

? - About... Affiche des informations sur le logiciel.


Paramétrage du serveur OPC

Les requêtes de communication

Vue d'espionnage des items

Vue des messages


WoodheadWoodhead


Les requêtes de communication

En appuyant sur le bouton suivant : , le fichier « dumpOPC.xml » est généré dans le répertoire de configuration courante. L’application « DumpLogger.exe » s’active et charge aussitôt ce dernier fichier.

Cette vue a pour but de lister l'ensemble des items et des groupes, géré par le serveur OPC.

Un double clic sur l’un des objets de l’arbre affiche une boîte proposant la liste des paramètres internes de l’objet.

Optimisation de la communication

En appuyant sur le bouton suivant : , le fichier « dumpTopic.xml » est généré dans le répertoire de configuration courante. L’application « DumpLogger.exe » s’active et charge aussitôt ce dernier fichier.


WoodheadWoodhead


L'affichage de cette fenêtre est statique et est construit au moment du clic sur le bouton d'affichage.

La partie droite de la vue donne des informations sur l'objet sélectionné dans la fenêtre de gauche. Ces informations ne sont pas documentées mais peuvent être utilisées par le support technique.

Vue d'espionnage des items

La vue d'espionnage des items est obtenue en appuyant sur le bouton suivant :


WoodheadWoodhead


Cette vue est divisée en trois parties. En haut à gauche un navigateur permet de consulter les différentes données accessibles. La partie en bas à gauche montre la liste des items à surveiller et la partie de droite affiche les messages des évènements affectant les items de la liste.

Pour espionner un item sélectionnez l'item à surveiller dans le navigateur

effectuez un "glisser - déplacer" du navigateur vers la liste en dessous

complétez éventuellement la syntaxe (appui sur F2 pour renommer) et cliquez sur la case à cocher pour sélectionner l'item

mettre en route la surveillance en appuyant sur le bouton :

A partir de ce moment, il n'est plus possible de modifier les items en surveillance active. Il est cependant possible d'ajouter des items dans la liste ou de modifier ceux non actifs.

La surveillance peut être stoppée avec le bouton :

Notes:

La liste des items à surveiller peut être sauvegardée et rechargée

La commande Logger parameters... du menu Diagnostic permet de sauvegarder tous les messages affichés dans la vue dans un fichier "Spy.log" situé dans le répertoire de configuration. Attention, ces paramètres sont appliqués à la fois sur le fichier "Spy.log" et sur le fichier "Opc.log" permettant de sauvegarder les messages de l'application.

Commandes disponibles Icône Menu Description

Items Spy – Item set – New list Créer une nouvelle liste d'items à surveiller. Si une

liste existe déjà et n'a pas été sauvegardée, un message apparaît.

Items Spy - Item set – Load Ouvre une liste précédemment sauvegardée sur le

disque. Si une liste existe déjà et n'a pas été sauvegardée, un message apparaît.

Items Spy - Item set – Save Permet d'enregistrer sur le disque, la liste active.

Items Spy – Find… Recherche une chaîne de caractères dans la fenêtre

en cours. La casse n'a pas d'importance.

Items Spy - Trace – Clear Supprime tous les messages de la fenêtre

d'affichage des messages.

Items Spy - Traces – Copy Copie le texte sélectionné de la fenêtre de message

dans le presse papier. Il peut donc être facilement collé dans tout autre fichier de type texte.

Items Spy – Start Mets tous les items sélectionnés de la liste en

espionnage.


WoodheadWoodhead


Items Spy – Stop Arrête l'espionnage de tous les items.

Items Spy – Item set – Add Item Ajoute l'item sélectionné de l'arbre dans la liste.

Items Spy – Item set – Remove Item

Supprime l'item sélectionné de la liste.

Items Spy - Item set – Check Item Sélectionne l'item (ou les items) afin qu'il(s) soit(ent)

espionné(s).

Vue des messages Cette vue permet d'afficher des informations liées au déroulement de l'application. L'activation de cette vue est assurée à l'aide des trois boutons suivants :

Le premier ferme la fenêtre des messages.

Le second affiche la vue en séparant les messages en trois onglets :

onglet Lecture : affiche un message à chaque fois que le serveur va acquérir une donnée auprès de l'émulateur

onglet Ecriture : affiche un message à chaque fois que le serveur envoie une donnée vers l'émulateur

onglet Erreur : affiche un message à chaque fois qu'une erreur se produit (erreur de syntaxe, mauvaise conversion d'une valeur,...)

Le troisième affiche la vue en incorporant tous les messages dans la même fenêtre.


WoodheadWoodhead

Serveur OPC • 54 • Développement d'un client OPC

Il est possible de stopper la trace des messages dans les fenêtres en sélectionnant la commande Diagnostic – Output View – Stop Messages. La commande Restart Messages permet de reprendre les traces. Ces deux commandes agissent sur toutes les fenêtres de messages en même temps. Lors de l'arrêt ou de la reprise, un message est signalé dans chacun des onglets.

Attention : Tous les messages entre l'arrêt et la reprise sont perdus.

La commande Clear Output View permet de supprimer tous les messages de l'onglet visible. Les messages des autres onglets ne sont pas affectés par cette commande.

Remarque :

La commande Logger parameters... du menu Diagnostic permet de sauvegarder tous les messages affichés dans la (les) vue(s) dans un fichier "OPC.log" situé dans le répertoire de configuration. Attention, ces paramètres sont appliqués à la fois sur le fichier "OPC.log" et sur le fichier "Spy.log" permettant de sauvegarder les messages de surveillance d'items.

11. Développement d'un client OPC

Contextes de développement

Beaucoup de progiciels de supervision intègrent de base la fonctionnalité client OPC. Cependant, en cas de besoins spécifiques, il est possible de développer soit-même son propre client OPC, à partir de l'outil de développement de son choix. Les développement peuvent être classés en trois catégories principales :

Les développements effectués à l'aide de l'ActiveX de communication applicom®

L'activeX rend transparent pour l'application cliente l'accès aux serveurs OPC et ne demande que peu de connaissance à propos d'OPC. L'activeX facilite grandement le développement du client en prenant en charge la mise en communication des serveurs et l'activation des groupes et des items. La définition de l'application est réalisée graphiquement sans aucune programmation. L'activeX de communication est utilisable par les environnements de travail container ActiveX, notamment Visual Basic, Delphi, les outils offices, ...

Les développements utilisant le custom interface.

Cette interface est utilisable depuis les langages du type C/C++. Son utilisation nécessite une connaissance complète de la spécification OPC Data Access, des mécanismes OPC en général et des mécanismes OLE/COM.

Les développements effectués à l'aide de la DLL Automation.

Cette interface est plus particulièrement destinée aux outils de développement rapide tels que VB, Delphi, les outils offices,…Elle constitue en fait une surcouche automation du custom interface utilisable depuis les langages du type C/C++. Son utilisation nécessite une connaissance complète de la spécification Data Access Automation Interface et des mécanismes OPC en général.


WoodheadWoodhead


Le produit applicom ne fournit pas la DLL automation. La voie préconisée pour developper un client OPC depuis des progiciels client automation est l’activeX de communication applicom. En cas de besoin, les sources de la DLL Automation peuvent être récupérés auprès de la fondation OPC


Contexte d'utilisation du serveur OPC

Développement d'un client en C et C++ Le serveur OPC applicom® est basé sur les spécifications 2.04 de la fondation OPC. Il supporte les accès au travers de l’OPC custom Interface.

Le but de cette documentation n’est pas de se substituer à la spécification V2.04 éditée par la fondation OPC. Celle-ci décrit dans le détail les différentes interfaces et le rôle des méthodes qu’ils exposent. Ce chapitre est destiné à évoquer toutes les particularités liées au développement d'un client OPC en C++ avec le serveur OPC applicom® et tente de clarifier certains points qui peuvent donner lieu à des interprétations diverses lors de la lecture de la spécification.

Voir également : Document externe :

OPC custom interface V2.04

Les objets et les interfaces supportés L’exécutable APPOPC.EXE est un serveur OPC Data Access compatible avec la spécification 1.0A et 2.0. Il supporte en effet l’ensemble des objets et des interfaces obligatoires définis par ces spécifications, mais aussi l'interface optionnelle de browsing des ItemID.

Objets Interfaces Type

IOPCServer Obligatoire pour V1.0 et V2.0 IOPCItemProperties Obligatoire pour V2.0 IOPCCommon Obligatoire pour V2.0 IconnectionPointContainer Obligatoire pour V1.0 et V2.0

OPCServer

IOPCBrowseServerAddressSpace Optionnelle IOPCGroupStateMgt Obligatoire pour V1.0 et V2.0 IOPCSyncIO Obligatoire pour V1.0 et V2.0 IOPCAsyncIO Obligatoire pour V1.0 IOPCAsyncIO2 Obligatoire pour V2.0 IOPCItemMgt Obligatoire pour V1.0 et V2.0 IdataObject Obligatoire pour V1.0

OPCGroup

IconnectionPointContainer Obligatoire pour V2.0 EnumOpCItemAttributes IenumOpCItemAttributes Obligatoire pour V1.0 et V2.0

Voir également :


WoodheadWoodhead


dans ce manuel :

Le browsing des ItemID

Création d’un objet OPCServer Le serveur OPC applicom® sera identifié dans le système d’exploitation MS-Windows à l’aide de son ProgID (identificateur de programme) et de son CLSID (identificateur de classe), enregistrés dans la base de registres de la machine durant l’installation.

Le CLSID est l’identificateur unique et universel du serveur et il est indépendant de sa version. Le ProgID est une chaîne de caractères traduite du CLSID au moyen de la base de registres. Il constitue un synonyme lisible du CLSID.

Pour créer un objet serveur OPC applicom®, l’application client doit :

1 - Initialiser la librairie COM

2 - Obtenir le CLSID du serveur OPC à partir du ProgID

3 - Créer un objet OPCServer

4 - Appeler une ou des fonctions de l’objet OPCServer

5 - Relâcher les interfaces utilisées.

Voici un exemple de code effectuant les étapes précédentes (pour la lisibilité du code les cas d'erreur ne sont pas traités):

//Etape 1 : Initialiser la librairie COM HRESULT hr; hr = CoInitialize(NULL); //Etape 2 : Obtenir le CLSID du ProgID CLSID clsid; hr = CLSIDFromProgID((L" APPLICOM.OPCServer "),&clsid); //Etape 3 : Creer l'objet OPCServeur et obtenir la premiere interface (ici IOPCServer) IOPCServer* pServer; hr = CoCreateInstance(clsid,NULL, CLSCTX_LOCAL_SERVER,IID_OPCServer,(void**)&pServer); //Etape 4 : Appeler l'une des fonctions de l'interface. … pServer->GetStatus(…); … //Etape 5 : Relacher les interfaces pServer->Release(); UnInitialize();

Remarque : Le package d’installation, comprend deux fichiers, “APPCLSID.H” et “APPCLSID.C” qui contiennent le ProgID et le CLSID du serveur OPC applicom® et que vous pouvez inclure directement dans votre projet CLIENT en C ou C++.


ProgID et CLSID


WoodheadWoodhead


Création d'un objet OPCGroup La création d’un groupe par le client s’effectue par un appel à la méthode AddGroup de l’interface IOPCServer de l'objet OPCServer.Celle-ci comporte notamment les paramètres suivants :

Nom Description szName Nom du groupe. S'il n'est pas fourni, le serveur en génère un unique (de la

forme APPGROUP + un numéro incrémental). dwRequestedUpdateRate Période de rafraîchissement demandée par le client. La période réellement

admise par le serveur sera retournée dans le paramètre de retour dwRequestedUpdateRate.

dwLCID Ce paramètre n’est pas exploité. pPourcentDeadBand Ce paramètre permet de limiter le retour de la variable au forte variation

(voir "Gestion des groupes")

Voir également :

dans ce manuel :

Gestion des groupes (OPC Group)

Gestion des items La création d’items par le client s’effectue par un appel à la méthode AddItem de l’interface IOPCItemMgt de l'objet OPCGroup. Chaque item symbolise une connexion vers une variable physique. En fait, le client décrit la variable qui l’intéresse par le biais d’une structure OPCITEMDEF.

Les champs de cette structure sont les suivants : Nom Description szAccessPath Non exploité par le serveur OPC applicom®. szItemID Chaîne de caractères référençant l’item. bActive indique l'état d'activation de l'item au moment de sa création. hClient Handle de référence du point pour le client. dwBlobSize le mécanisme de “blob” n’est pas exploité par le serveur OPC applicom®. pblob le mécanisme de “blob” n’est pas exploité par le serveur OPC applicom®. vtRequestedDataType Type du variant demandé par le client . La valeur VT_EMPTY désigne le type

par défaut (décidé par le serveur). Utilisez le renvoi 1 pour connaître les types de variant supportés.

Remarques : Lors de l’ajout d’un nouvel item dans un groupe par la méthode AddItems, le serveur OPC

détermine automatiquement le type canonique de la variable et le retourne dans le champ vtCanonicalDataType de la structure OPCITEMRESULT.

Sauf besoin particulier, Il est donc conseillé à l’application client de toujours passer la valeur VT_EMPTY dans le champ vtRequestedDataType, laissant ainsi le serveur déterminer lui-même le type de la variable.


WoodheadWoodhead



Types de données supportés par le serveur OPC


Remontée des données L'objet OPCGroup et ses différentes interfaces offrent au client quatre voies possibles pour lire des données :

Mécanisme événementiel (IDataObject/IAdviseSink en V1.0A ou IConnectionPoint/IOPCDataCallback en V2.0)

Lecture synchrone (IOPCSyncIO::Read )

Lecture asynchrone (IOPCAsyncIO::AsyncRead en V1.0A ou IOPCAsyncIO2::AsyncRead en V2.0)

Rafraîchissement asynchrone du groupe (IOPCAsyncIO::Refresh en V1.0A ou IOPCAsyncIO2::Refresh en V2.0)

et deux possibilités pour écrire :

Ecriture synchrone (IOPCSyncIO::Write)

Ecriture asynchrone (IOPCAsyncIO::AsyncWrite en V1.0A ou IOPCAsyncIO2::AsyncWrite en V2.0)

Remarques : Lors de lectures/écritures asynchrones, si les demandes sont envoyées plus rapidement

qu'elles ne peuvent être traitées par le serveur, celui-ci les empile. Si trop de requêtes sont empilées, les demandes sont refusées.

Attention : en version 1.0A, le mode événementiel s’appuie, en conformité avec la spécification, sur les interfaces standards OLE IDataObject et IAdviseSink. L’appel par le serveur de la fonction OnDataChange du client est en fait un appel asynchrone (cf aide en ligne de l’interface IAdviseSink). Il est par conséquent impératif que l’application client soit en mesure de récupérer les données aussi rapidement que le serveur les transmet. Dans le cas contraire, les appels sont empilés par le système, entraînant une diminution de la mémoire disponible pouvant aller jusqu'à épuisement. Ce phénomène peut survenir d’autant plus que le serveur est rapide. Il peut donc être provoqué lorsque le client demande une surveillance de données en constante évolution (variables analogiques,...) à des périodes de rafraîchissement très faibles.

Voir également :

dans ce manuel :


Exemple de client OPC en C++ Le package du serveur OPC inclut un client OPC développé à l’aide de Visual C++ 6.0. Ce client, dont tous les codes source sont fournis (dans le sous-répertoire OPC), vous permettra de tester la fonctionnalité du serveur OPC et pourra constituer un modèle de base pour votre propre développement.

Attention :


WoodheadWoodhead


Ce client a été développé à but d’exemple de programmation et de test. Il s’agit d’une application monothread dont les mécanismes d’affichage ne sont vraiment pas optimisés (l’utilisation de liste pour l’affichage des items est très gourmande en ressources CPU). Dans le cas de périodes de rafraîchissement demandées très petites, des changements de valeurs fréquents peuvent engendrer un blocage du rafraîchissement du client. Ce phénomène ne peut pas être imputé aux performances du serveur OPC, mais au contraire, aux remontées rapides effectuées par celui-ci et engendrant un engorgement au niveau du redessin de l’application client.

Informations nécessaires au développement

ProgID et CLSID Le serveur OPC applicom® sera identifié dans le système d’exploitation MS-Windows à l’aide de son ProgID (identificateur de programme) et de son CLSID (identificateur de classe), enregistrés dans la base de registres de la machine durant l’installation :

ProgID “APPLICOM.OPCServer” ;

CLSID {283618B2-8349-11D0-8F82-0080C85344A1}.

Types de données supportés par le serveur OPC Le serveur OPC applicom® supporte les types de donnée suivants : Type de variant Type de donnée Limite VT_BOOL Booléen VT_UI1 octet non signé (de 0 à 255) VT_I1 octet signé (de -128 à 127) VT_UI2 entier 16 bit non signé (de 0 à 65535) VT_I2 entier 16 bit signé (de -32768 à 32767) VT_UI4 entier 32 bit non signé (de 0 à 4294967295) VT_I4 entier 32 bit signé (de -2147483648 à 2147483647) VT_R4 flottant IEEE sur 4 octets (de -3.4e+38 à 3.4e+38) VT_R8 flottant IEEE sur 8 octets VT_BSTR chaîne ASCII

Les types précédents (excepté VT_BSTR) peuvent être associés avec le type VT_ARRAY pour indiquer que la variable est de type tableau.

Voir également : dans la base de connaissances :

Serveur OPC : Types de données retournées par le serveur OPC


WoodheadWoodhead


Remontée des données et comportement du serveur Le tableau suivant résume le comportement du serveur OPC en fonction de l’état du groupe, de celui de l’item et de la provenance des données.

Fonction

Provenance des données

Groupe Active

Item Activé

Comportement et code de retour

Lecture synchrone CACHE O O La valeur et la qualité des items demandés sont retournées.

CACHE O N Les items sont retournés avec le drapeau de qualité OPC_QUALITY_OUT_OF_SERVICE

CACHE N O|N Les items sont retournés avec le drapeau de qualité OPC_QUALITY_OUT_OF_SERVICE

DEVICE O|N O|N La valeur et la qualité des items sont retournées après une lecture dans les équipements

Lecture Asynchrone

CACHE O O La valeur et la qualité des items demandés sont remontées par l’appel à OnDataChange ou par l'interface IOPCDataCallback.

CACHE O N Les items demandés sont retournés par l’appel à OnDataChange ou par l'interface IOPCDataCallback avec le drapeau de qualité OPC_QUALITY_OUT_OF_SERVICE

CACHE N O|N Les items demandés sont retournés par l’appel à OnDataChange ou par l'interface IOPCDataCallback avec le drapeau de qualité OPC_QUALITY_OUT_OF_SERVICE

DEVICE O|N O|N La valeur et la qualité des items sont retournées par l’appel à OnDataChange ou par l'interface IOPCDataCallback après une lecture dans les équipements

Rafraîchissement du groupe

CACHE DEVICE

O O|N La valeur et la qualité de tous les items actifs dans le groupe sont retournées par l’appel à OnDataChange ou par l'interface IOPCDataCallback.

Le serveur retourne E_FAIL si aucun item n’est actif dans le groupe.

N O|N Le serveur retourne E_FAIL immédiatement. Mode événementiel

O O|N Les données sont remontées (pour les items actifs ayant changés depuis la dernière remontée).

N O|N Les données ne sont plus remontées.

Les flags de qualité A chaque item sont associés des “flags” de qualité permettant à l’application client de connaître la validité de l’item. Les flags sont disposés suivant le modèle suivant :

QQSSSSLL


WoodheadWoodhead


QQ : ce sont les bits de qualité principaux. Les valeurs retournées par le serveur applicom® peuvent être 0 (mauvais), 1 (incertain) ou 3 (OK)

SSSS : le sous-status commente la valeur du satus QQ. Le serveur OPC retourne entre autre valeur 7 (Out Of Service) quand les bits QQ sont positionnés sur 0 (mauvais). Ce sous-status est retourné si le client effectue une lecture synchrone ou asynchrone dans le cache alors que l’item n’est pas actif.

LL : Permet d'indiquer un dépassement haut ou bas de la valeur.

Voir également :

dans ce manuel :

Qualité des items


WoodheadWoodhead

Serveur OPC • 62 • Index

12. Index

AccessPath, 9 ActiveX de communication, 75 ADVISE_FAILED, 41, 54 Asynchrone, 15, 28, 51, 81, 86 Bande morte, 13 Bit de mots, 32 Browsing, 12 Cache, 86 Client OPC, 74, 82 CLSID, 78, 84 Configuration, 30, 31 Configuration des topics, 21, 24, 49 CTS, 64 Custom interface, 75 DCD, 64 Descripteurs, 24, 35, 38 Developpement, 74 Device, 86 Diagnostic, 39, 52 Diagnostic du serveur OPC, 65 DLL automation, 75 Evénementiel, 15, 81 Flags de commandes, 58 Fonctions cycliques, 57, 58, 60 Groupes OPC, 13, 79 Horodatage, 16 INPUT, 63 Interface, 77 Interface graphique, 6 Item, 9, 33, 60, 80 ItemID, 9 LIMIT_ALLOWED, 62 LIMIT_MAX_USED, 62 LIMIT_OVERFLOW, 62 LIMIT_USED, 62 Limitation Logix, 52 Limitations, 18 Mode expert, 8 Mode Message, 31 Mode tableau, 29, 30 Modems, 64 NB_POINT, 62 NB_TOPIC, 62 Noms symboliques, 44 Optimisation Logix, 49, 51 Paramètres serveur OPC, 7 ProgID, 11, 78, 84 Qualité d'une donnée, 17, 87 READ_ERROR, 43, 56 RTS_DTR, 64 Serveur OPC, 3 Signaux modems, 64


WoodheadWoodhead

Serveur OPC • 63 • Index

STATUS, 40, 53 Synchrone, 15, 28, 51, 81, 86 Syntaxe Logix, 50 SYSTEME, 62 Topic, 9, 20 Topics Fonction cyclique, 20, 58, 60 Topics prédéfinis, 20, 62, 63, 64 Topics variable image, 20, 22 Topics variable locale, 20, 22 Variable image, 22, 48 Variable internes, 24 Variable locale, 22 Variable Logix, 48 Variable OPC, 22, 48, 85 Variables internes, 50 WATCHDOG, 63 WRITE_ERROR, 42, 55

serveur opc - geii1.free.fr · pdf fileelectrical & safety · industrial connectivty...

Documents