Schneider Electric LUFP9 v1, Passerelle DeviceNet/Modbus RTU Mode d'emploi

LUFP9
Telemecanique
Guide d’exploitation
Passerelle
DeviceNet / Modbus RTU
1
2
Table des matières
Table des matières ...................................................3
Informations de sécurité...........................................4
Avis de non responsabilité.......................................4
A propos de ce manuel .............................................5
1. Introduction............................................................6
1.1. Introduction du Guide d’exploitation....................................... 6
1.2. Présentation de la passerelle LUFP9..................................... 8
1.3. Terminologie........................................................................... 8
1.4. Présentation de l’architecture « système » des
communications ...................................................................... 9
1.5. Principe de configuration et de fonctionnement de la
passerelle.............................................................................. 10
2. Mise en œuvre matérielle de la passerelle
LUFP9............................................................... 12
2.1. Réception ............................................................................. 12
2.2. Présentation de la passerelle LUFP9................................... 12
2.3. Montage de la passerelle sur rail DIN .................................. 13
2.4. Alimentation de la passerelle ............................................... 14
2.5. Raccordement de la passerelle au réseau Modbus............. 14
2.5.1. Exemples de topologies de raccordement Modbus ....... 14
2.5.2. Brochage........................................................................ 17
2.5.3. Recommandations de câblage du réseau Modbus........ 18
2.6. Connexion de la passerelle LUFP9 au réseau DeviceNet ... 20
2.7. Configuration des fonctions de communication DeviceNet.. 21
2.7.1. Codage de la vitesse DeviceNet .................................... 21
2.7.2. Codage de l’adresse de la passerelle............................ 22
2.7.3. Exemples de configuration de la passerelle .................. 23
3. Signalisation ....................................................... 24
4. Mise en œuvre logicielle de la passerelle ........ 26
4.1. Introduction........................................................................... 26
4.1.1. Architecture système...................................................... 26
4.1.2. Configuration des départs-moteurs................................ 27
4.1.3. Temps de cycle Modbus ................................................ 27
4.1.4. Gestion des modes dégradés avec la configuration par
défaut de la passerelle ................................................... 27
4.2. Configuration de la passerelle sous RsNetWorx.................. 32
4.2.1. Sélection et ajout du scanner DeviceNet de l’automate
maître ............................................................................. 32
4.2.2. Mise en place du fichier de description de la passerelle 32
4.2.3. Sélection et ajout d’une passerelle au réseau DeviceNet
........................................................................................ 33
4.2.4. Modification des paramètres de la passerelle................ 33
4.2.5. Configuration du Scanner DeviceNet............................. 35
4.2.6. Configuration des entrées issues de la passerelle ........ 36
4.2.7. Configuration des sorties destinées à la passerelle....... 37
4.2.8. Transfert de la configuration du scanner DeviceNet ...... 38
4.2.9. Développement d’une application DeviceNet. ............... 38
4.3. Gestion du réseau aval Modbus : ........................................ 38
5. Initialisation et diagnostic de la passerelle ..... 40
5.1. Gestion complète..................................................................40
5.1.1. Mot de commande du maître DeviceNet ........................40
5.1.2. Mot d’état de la passerelle..............................................41
5.2. Diagnostic seul .....................................................................41
5.2.1. Mot de commande du maître DeviceNet ........................41
5.2.2. Mot d’état de la passerelle..............................................42
5.3. Fonctionnement simplifié ......................................................42
5.4. Description du mot de commande du maître DeviceNet ......43
5.5. Description du mot d’état de la passerelle............................45
6. Configuration de la passerelle .......................... 47
6.1. Raccordement de la passerelle au PC de configuration.......47
6.1.1. Brochage ........................................................................48
6.1.2. Protocole de la liaison RS-232 .......................................48
6.2. Installation de ABC-LUFP Config Tool .................................49
6.3. Importation de la configuration de la passerelle ...................49
6.4. Transfert d’une configuration vers la passerelle ...................50
6.5. Suivi du contenu de la mémoire de la passerelle .................50
6.6. Suppression d’un esclave Modbus .......................................52
6.7. Ajout d’un esclave Modbus...................................................53
6.8. Modification des données périodiques échangées avec un
esclave Modbus ....................................................................55
6.8.1. Remplacement d’une donnée périodique d’entrée.........55
6.8.2. Remplacement d’une donnée périodique de sortie ........56
6.8.3. Augmentation du nombre des données périodiques
d’entrée ...........................................................................57
6.8.4. Augmentation du nombre des données périodiques de
sortie ...............................................................................61
6.9. Suppression des données apériodiques de paramétrage ....66
6.10. Modification de la configuration d’un esclave Modbus .......68
6.10.1. Modification du nom d’un esclave Modbus...................69
6.10.2. Modification de l’adresse d’un esclave Modbus ...........69
6.11. Ajout et paramétrage d’une commande Modbus................70
6.11.1. Cas des départs-moteurs TeSys U ..............................70
6.11.2. Cas d’un esclave Modbus générique ...........................72
6.11.3. Ajout d’une commande Modbus spéciale.....................86
6.12. Configuration des caractéristiques générales de la
passerelle ..............................................................................88
6.12.1. Elément « Fieldbus »....................................................88
6.12.2. Elément « ABC » ..........................................................89
6.12.3. Elément « Sub-Network ».............................................90
6.13. Ajout d’un nœud de diffusion ..............................................92
Annexe A: Caractéristiques techniques .............. 93
Annexe B: Configuration par défaut..................... 96
Annexe C: Exemple d’utilisation (RSLogix 500).. 99
Annexe D: Objets DeviceNet ............................... 108
Annexe E: Commandes Modbus ........................ 127
Index ...................................................................... 131
Glossaire ............................................................... 132
3
Informations de sécurité
AVIS :
Lisez attentivement ces instructions et examinez le matériel pour vous familiariser avec
l'appareil avant de tenter de l'installer, de le faire fonctionner ou d’assurer son entretien.
Vous pourrez voir apparaître les messages spéciaux suivants tout au long de cette
documentation ou sur l'appareil. Ils ont pour but de vous mettre en garde contre des
risques potentiels ou d’attirer votre attention sur des informations qui clarifient ou
simplifient une procédure.
Les éléments ci-contre sont des symboles d’alerte de sécurité. Ils ont pour but de
vous mettre en garde contre des risques potentiels de blessure corporelle.
Respectez tous les messages de sécurité suivant ces symboles afin d’éviter tout
risque mortel, de blessure ou d’endommagement de l’appareil.
DANGER
DANGER signale une situation dangereuse imminente qui, si elle n'est pas évitée,
entraînera la mort, des blessures graves ou des dommages matériels.
AVERTISSEMENT
AVERTISSEMENT signale une situation dangereuse potentielle qui, si elle n'est pas
évitée, peut entraîner la mort, des blessures graves ou des dommages matériels.
ATTENTION
ATTENTION signale une situation dangereuse potentielle qui, si elle n'est pas évitée,
peut entraîner des blessures ou des dommages matériels.
Avis de non responsabilité
VEUILLEZ
NOTER :
Seul un personnel qualifié doit assurer l’entretien de l’équipement électrique.
Schneider Electric décline toute responsabilité quant aux conséquences de l’utilisation
de cet appareil ou du Guide d’exploitation associé. Ce document ne constitue pas un
manuel d’instructions pour des personnes inexpérimentées.
© 2005 Schneider Electric. Tous droits réservés.
4
A propos de ce manuel
Remarque
sur la validité
Les données et illustrations fournies dans ce manuel ne sont pas contractuelles. Nous nous
réservons le droit de modifier nos produits conformément à notre politique de
développement permanent. Les informations figurant dans ce document peuvent faire
l'objet de modifications sans préavis et ne doivent pas être interprétées comme un
engagement de la part de Schneider Electric
_________________________________________________________________________
Documents
associés
Titre du document
Référence
AnyBus Communicator – User Manual
ABC_User_Manual.pdf
Safety Guidelines for the Application,
Maintenance of Solid State Control
Installation,
and NEMA ICS 1.1
(nouvelle édition)
Safety Standards for Construction and Guide for Selection, NEMA ICS 7.1
Installation and Operation of Adjustable-Speed Drive Systems
(nouvelle édition)
Modbus User Guide
TSX DG MDB E
Modicon Modbus Protocol Reference Guide
Informations
relatives au
produit
Commentaires
des utilisateurs
PI-MBUS-300 Rev. J
Schneider Electric n’est nullement responsable des erreurs pouvant figurer dans ce
document. Merci de nous contacter pour toute suggestion d'amélioration ou de
modification, ou si vous trouvez des erreurs dans cette publication.
Aucune partie de ce document ne peut être reproduite sous quelque forme ou par quelque
moyen que ce soit, électronique, mécanique ou photocopie, sans autorisation préalable de
Schneider Electric.
Toutes les réglementations de sécurité pertinentes locales, régionales et nationales doivent
être observées lors de l'installation et de l'utilisation de ce produit. Pour des raisons de
sécurité et pour garantir la conformité aux données système documentées, seul le fabricant
peut effectuer des réparations sur les composants.
_________________________________________________________________________
Ce document est évolutif. En tant que tel, il sera révisé de temps à autres afin d’ajouter du
contenu ou de réviser le contenu existant si nécessaire. Ce manuel a été rédigé pour vous.
Vos questions et vos commentaires au sujet de ce document sont les bienvenus. Envoyezles par courrier électronique à l’adresse techpub@schneider-electric.com.
5
1. Introduction
1.1. Introduction du Guide d’exploitation
Chapitre 1
Chapitre 2
Introduction: Ce chapitre décrit la passerelle, son guide d’exploitation ainsi que les termes qui y
sont employés.
Mise en œuvre matérielle de la passerelle LUFP9 : Ce chapitre présente la passerelle et décrit
l’ensemble des éléments à manipuler lors de sa mise en œuvre, qu’ils soient internes (roues
codeuses) ou externes (câbles et connecteurs) à la passerelle.
Chapitre 3
Signalisation : Ce chapitre décrit les six DEL situées sur la face avant de la passerelle.
Chapitre 4
Mise en œuvre logicielle de la passerelle : Ce chapitre décrit les étapes successives
permettant de mettre en œuvre la passerelle dans sa configuration par défaut, avec un automate
utilisant DeviceNet. Les passerelles LUFP9 sont livrées pré-configurées pour permettre d’interfacer
un maître DeviceNet avec 8 esclaves Modbus prédéfinis (départs-moteurs TeSys U).
Chapitre 5
Initialisation et diagnostic de la passerelle : Ce chapitre décrit deux registres présents dans la
mémoire de la passerelle, ceux-ci étant réservés à l’initialisation et aux diagnostics de la
passerelle. Ils sont uniquement échangés entre le maître DeviceNet et la passerelle.
Chapitre 6
Configuration de la passerelle : Ce chapitre décrit l’utilisation du logiciel « ABCLUFP Configurator », qui permet de modifier ou de créer une nouvelle configuration destinée à la
passerelle, et présente les différentes fonctions de ce logiciel (ajout ou suppression d’un esclave
Modbus, ajout ou modification d’une commande Modbus, etc.).
Ce chapitre présente également les changements à reporter sur les opérations de mise en œuvre
logicielle sous RSNetWorx.
Annexe A
Caractéristiques techniques : Cette annexe décrit les aspects techniques de la passerelle et
des réseaux auxquels elle est interfacée, c’est-à-dire les réseaux DeviceNet et Modbus RTU.
Annexe B
Configuration par défaut : Cette annexe décrit les principales caractéristiques de la
configuration par défaut de la passerelle LUFP9, sans toutefois rentrer dans les détails liés à
ABC-LUFP Config Tool.
Annexe C
Exemple d’utilisation (RSLogix 500)
Cette annexe décrit un exemple simple d’utilisation de la configuration par défaut de la passerelle
LUFP9. Cet exemple exploite les registres de commande et de surveillance de 8 départs-moteurs
TeSys U et utilise les services apériodiques de lecture et d’écriture de la valeur d’un paramètre de
départ-moteur.
Annexe D
Objets DeviceNet : Cette annexe décrit les objets DeviceNet génériques ainsi que les objets
DeviceNet spécifiques à la passerelle LUFP9. Les valeurs des attributs de ces objets y sont
également fournies.
Annexe E
Commandes Modbus : Cette annexe décrit le contenu des trames des commandes Modbus
supportées par la passerelle LUFP9.
6
1. Introduction
Accès rapide aux informations critiques
utilisant…
(1)
Utilisateur de…
Présentation
du
matériel
et des
connexions
(2) Produits TeSys U
la configuration
(2b) prédéfinie, le nombre
modifiant…
d’esclaves (< 8)
utilisant…
Utilisateur de...
(4)
(3)
la configuration
(2a) prédéfinie
(avec 8 esclaves)
autres produits
(2c) de nouvelles variables
utilisant…
via ABC-LUFP
Config Tool
Gestion des pertes de communication
dans le cas d’une configuration prédéfinie
(5) Signalisation et diagnostics
(1) Présentation du matériel et des connexions
Voir Chapitre 2
- alimentation,
- installation,
- raccordement au réseau Modbus,
- raccordement au réseau DeviceNet,
- sélection de la vitesse de transmission et des
(3) Utilisateur d’autres produits génériques Modbus
Voir Chapitre 6
(6.7 à 6.11, 6.11.2)
adresses.
(2) Utilisateur de produits TeSys U
(2a) avec 8 esclaves
(2b) réduction du nombre d’esclaves
Voir les chapitres
4.1.4.1 et 6.11.2.2
Utilisation de ABC-LUFP Config Tool :
- installation (6.2),
- connexion (6.1),
- retrait d’esclaves (6.6)
(2c) accès à de nouvelles variables
Voir Chapitre 6
- définir votre propre configuration (voir
le manuel d’utilisation de ABC)
(4) Perte de communication
Voir Chapitre 4
Voir Chapitre 6
Choisissez entre :
- adapter la configuration prédéfinie
fournie avec la passerelle, si elle est
suffisamment proche de celle
souhaitée (1 registre de lecture et 1
registre d’écriture, 1 adresse de
registre à modifier) ou
Utilisation de ABC-LUFP Config Tool pour
accéder à des registres autres que les registres
standard 704 (Command) et 455 (Status)
avec la même requête :
- remplacement d’un registre par un autre (par
exemple 455 par 458)
- augmentation de la taille (le nombre de
registres)
Les variables décrites sont :
- Reconnect time
(unité = 10ms, valeur par
défaut = 10s)
- Retries (valeur par défaut = 3)
- Timeout time
(unité = 10ms, valeur par
défaut = 1s)
(5) Signalisation des défaillances et des états, diagnostics
Voir Chapitre 3
Voir Chapitre 5
Signalisation des défaillances et de
l’état de la passerelle par DEL sur le
panneau avant
Mode d’initialisation de la passerelle
et description des informations de
diagnostic
avec une requête additionnelle :
- ajout de commandes supplémentaires
- autres opérations (6.7 à 6.11)
7
1. Introduction
1.2. Présentation de la passerelle LUFP9
La passerelle LUFP9 permet à un maître situé sur un réseau DeviceNet de dialoguer avec les esclaves d’un
réseau Modbus RTU. Il s'agit d'un convertisseur de protocole générique qui fonctionne de manière transparente
pour l'utilisateur.
Cette passerelle vous permet de relier de nombreux produits distribués par Schneider Electric à un réseau
DeviceNet, tels que les départs-moteurs TeSys U, les variateurs Altivar et les démarreurs Altistart.
1.3. Terminologie
Tout au long de ce document, le terme « utilisateur » désigne la ou les personnes amenées à manipuler ou à se
servir de la passerelle.
Le terme « RTU », qui caractérise le protocole de communication Modbus RTU, sera omis la plupart du temps.
Par conséquent, le simple terme « Modbus » désignera le protocole de communication Modbus RTU.
Comme cela reste le cas pour tous les systèmes communicants, les termes « entrée » et « sortie » sont
ambigus. Pour éviter toute confusion, nous utilisons une convention unique dans ce document. Ainsi, les notions
« entrée » et « sortie » sont toujours vues de l’automate, ou du maître / scanner DeviceNet.
Une « sortie » est donc un signal de commande envoyé à un esclave Modbus, tandis qu’une « entrée » est un
signal de surveillance généré par ce même esclave Modbus.
Le schéma représenté ci-dessous symbolise le flux des « entrées » et des « sorties » échangées entre un
maître DeviceNet et des esclaves Modbus RTU via la passerelle LUFP9 :
Maître DeviceNet
SORTIES
Passerelle
LUFP9
ENTREES
Altistart 48
Esclaves Modbus RTU
NOTE : Pour obtenir davantage d’informations concernant des termes spécifiques, reportez-vous au Glossaire
disponible à la fin de ce guide.
8
1. Introduction
1.4. Présentation de l’architecture « système » des communications
Chaque passerelle DeviceNet / Modbus RTU LUFP9 permet à un automate présent sur le réseau DeviceNet de
commander, de contrôler et de configurer jusqu’à 8 esclaves Modbus. Il est possible de distribuer 25
commandes à 8 esclaves, sans contrainte de temps. Si le nombre d’esclaves Modbus est supérieur à 8, vous
devrez avoir recours à un nombre approprié de passerelles LUFP9.
Maître
DeviceNet
Réseau amont (DeviceNet)
Total de
16 départs-moteurs
(modèle TeSys U)
Réseau aval n°1
(Modbus)
Réseau aval
n°2
(Modbus)
ATS48
VW33-A48
ATS46
VW3-G46301
Réseau aval n°3 (Modbus)
9
1. Introduction
La passerelle LUFP9 se comporte à la fois comme un esclave DeviceNet sur le réseau amont et comme un
maître Modbus RTU sur le réseau aval.
Reportez-vous à l’Appendix A: Caractéristiques techniques, si vous souhaitez prendre connaissance des
caractéristiques techniques de communication de la passerelle.
La passerelle peut effectuer ses échanges de données (entrées et sorties de tous types) avec les esclaves
Modbus de manière cyclique, apériodique ou événementielle. L’ensemble de ces échanges Modbus forment le
« scanner Modbus » de la passerelle et on utilise le logiciel « ABC-LUFP Config Tool » pour configurer les
échanges de ce scanner. Chaque donnée échangée de cette manière est mise à la disposition du maître
DeviceNet, qui pourra y accéder de diverses façons (échanges cycliques, apériodiques ou événementiels).
NOTE : Si, par exemple, une communication est périodique sur le réseau Modbus, il n’est pas obligatoire que
les données correspondantes soient échangées de manière périodique sur le réseau DeviceNet, et vice versa.
Le schéma situé sur la page précédente illustre la répartition de plusieurs esclaves sur trois réseaux avals Modbus RTU,
chacun de ces réseaux étant interfacé avec l’automate maître DeviceNet à l’aide d’une passerelle LUFP9.
1.5. Principe de configuration et de fonctionnement de la passerelle
La passerelle LUFP9 fait partie d’une famille de produits (désignés par LUFPz) conçus pour répondre à des
besoins génériques de connexion entre deux réseaux utilisant des protocoles de communication distincts.
Les éléments logiciels communs à toutes ces passerelles (outil de configuration, appelé « ABC-LUFP Config
Tool », et logiciel Modbus embarqué) cohabitent avec les spécificités du réseau amont de chacune d’elle
(DeviceNet dans le cas de la passerelle LUFP9) d’une manière générique. C’est l’une des raisons pour lesquelles
l’interfaçage entre le réseau amont et le réseau Modbus est intégralement effectué via la mémoire physique de la
passerelle.
Ö
Les échanges entre la passerelle (qui fait office de maître Modbus) et les esclaves Modbus sont
entièrement configurés à l’aide de « ABC-LUFP Config Tool ». Cet outil de configuration atteint un niveau de
détail particulièrement élevé (temporisations des échanges, modes de communication, contenu des trames,
etc.), ce qui rend son utilisation d’autant plus délicate. Un chapitre entier (chapitre 6 Configuration de la
passerelle) lui a donc été consacré dans le présent guide
10
1. Introduction
Ö Chaque passerelle LUFP9 est livrée pré-configurée pour en simplifier l’utilisation et pour servir de base à une
configuration qui répondrait au mieux aux attentes de l’utilisateur. Les opérations typiques applicables à cette
configuration par défaut sont décrites dans le chapitre 6 Configuration de la passerelle.
Le réseau DeviceNet est totalement dissocié du réseau Modbus. Les trames d’un réseau ne sont pas directement
« traduites » par la passerelle pour générer des trames sur l’autre réseau. Au lieu de cela, les échanges entre le
contenu de la mémoire de la passerelle et les esclaves Modbus forment un système indépendant de celui qui est
chargé de la gestion des échanges entre cette même mémoire et le maître DeviceNet. Le système garantit la
cohérence des données échangées dans la mémoire partagée.
Vous devez veiller à ce que la taille des données DeviceNet corresponde à la taille de la mémoire utilisée pour
les échanges Modbus, car la passerelle configure ses échanges DeviceNet en se basant sur la mémoire utilisée
par les trames Modbus. Si la taille ne correspond pas, la DEL Diag n°4 du bus de terrain clignote à une
fréquence de 1 Hertz, les échanges Modbus cycliques sont activés et les registres Modbus accessibles en
écriture sont définis sur 0.
L’exemple suivant illustre la gestion indépendante de chacun des deux réseaux :
— Gestion des échanges Passerelle↔ Esclaves Modbus —
11
2. Mise en œuvre matérielle de la passerelle LUFP9
2.1. Réception
Après ouverture de l’emballage, vérifiez la présence d’une passerelle LUFP9 DeviceNet / Modbus RTU équipée
de connecteurs.
2.2. Présentation de la passerelle LUFP9
Les câbles et autres accessoires de raccordement aux réseaux DeviceNet et Modbus doivent être commandés
séparément.
Légende :
c Connecteur débrochable d’alimentation
de la passerelle (
24V).
d
Connecteur RJ45 femelle pour liaison
avec un PC doté du logiciel de
configuration ABC-LUFP.
e
Connecteur RJ45 femelle du réseau
aval Modbus RTU .
f
g
Six DEL de diagnostic .
h
Connecteur
débrochable.
Capot amovible dissimulant les
commutateurs de configuration de la
passerelle, représentés et décrits
dans le chapitre 2.7 Configuration des
fonctions
de
communication
DeviceNet. L’étiquette de description
des DEL est collée sur ce même
capot.
DeviceNet
femelle
12
2. Mise en œuvre matérielle de la passerelle LUFP9
La passerelle LUFP9 permet des communications entre un réseau DeviceNet et des périphériques Modbus pour
des applications industrielles d’automatisation et de contrôle. Comme pour tout composant utilisé dans un
système de contrôle industriel, le concepteur doit évaluer les dangers potentiels découlant de l’utilisation de la
passerelle LUFP9 pour cette application.
AVERTISSEMENT
PERTE DE CONTRÔLE
•
Le concepteur de tout système de contrôle doit tenir compte des modes de défaillances potentielles des
chemins de contrôle et, pour certaines fonctions de contrôle critiques, prévoir un moyen d’atteindre un
état sécurisé durant et après la défaillance d'un chemin. L’arrêt d'urgence et l’arrêt en cas de sur-course
constituent des exemples de fonctions de contrôle critiques.
•
Des chemins de contrôle distincts ou redondants doivent être prévus pour les fonctions de contrôle
critiques.
•
Les chemins de contrôle du système peuvent inclure des liaisons de communication. Il est nécessaire de
tenir compte des conséquences des retards de transmission inattendus ou des défaillances d’une liaison. a
•
Chaque mise en œuvre d’une passerelle LUFP• doit être testée de manière individuelle et approfondie
afin de vérifier son fonctionnement avant de la mettre en service.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
a
Pour plus d’informations, reportez-vous aux documents NEMA ICS 1.1 (nouvelle édition), « Safety Guidelines for the Application, Installation, and
Maintenance of Solid State Control » et NEMA ICS 7.1 (nouvelle édition), « Safety Standards for Construction and Guide for Selection, Installation
and Operation of Adjustable-Speed Drive Systems ».
2.3. Montage de la passerelle sur rail DIN
Démontage de la passerelle
Montage de la passerelle
1
1
2
Commencez par appliquer l’embase arrière de la
passerelle sur la partie supérieure du rail, en
poussant vers le bas (1) pour comprimer le ressort
de la passerelle. Poussez ensuite la passerelle
contre le rail DIN (2) jusqu’à ce que l’embase du
boîtier de la passerelle s’emboîte sur le rail.
2
Commencez par pousser la passerelle vers le bas
(1) pour comprimer le ressort de la passerelle. Tirez
ensuite le bas du boîtier de la passerelle vers
l’avant (2) jusqu’à ce que le dos du boîtier se
déboîte du rail.
NOTE : Le ressort fait également office d’organe de mise à la terre de la passerelle (Protective Earth).
13
2. Mise en œuvre matérielle de la passerelle LUFP9
2.4. Alimentation de la passerelle
Passerelle DeviceNet / Modbus RTU - Vue de dessous
–
+
Alimentation
24V isolée
95 mA max.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
N’utilisez pas l’alimentation 24 V CC fournie par le câble du réseau DeviceNet pour alimenter les passerelles
LUFP•, car la borne négative (⎯) de cette alimentation n’est pas nécessairement au même potentiel de mise
à la terre que l'installation. L’utilisation d’une alimentation sans mise à la terre peut provoquer un
fonctionnement imprévisible des périphériques LUFP•.
Pour garantir un fonctionnement sûr, les passerelles LUFP• exige une alimentation séparée, dont la borne
négative (⎯) est connectée à la mise à la terre du système.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
2.5. Raccordement de la passerelle au réseau Modbus
Trois exemples types de raccordement Modbus de la passerelle et de ses esclaves sont présentés ci-après. Il
existe de nombreuses autres possibilités de raccordement Modbus, mais elles ne font pas l’objet de ce document.
2.5.1. Exemples de topologies de raccordement Modbus
• Topologie « étoile » : Cette topologie utilise des répartiteurs Modbus LU9GC03, qui sont dotés de 8 prises
RJ45 femelles. Ces répartiteurs doivent être placés à proximité des esclaves Modbus, auxquels ils sont
connectés à l’aide de câbles VW3 A8 306 R••. En revanche, la nature du câble reliant la passerelle LUFP9
à l’un de ces répartiteurs dépendra de l’architecture du réseau, du moment qu’il est pourvu d’un connecteur
RJ45 mâle à chacune de ses extrémités. Au besoin, une ou deux terminaisons de ligne pourront être
directement connectées sur les répartiteurs.
14
2. Mise en œuvre matérielle de la passerelle LUFP9
Les branchements sont schématisés ci-dessous :
Passerelle LUFP9
Modbus
VW3 A8 306 R••
Répartiteurs Modbus
LU9GC03
Terminaison
de ligne
Terminaison
de ligne
Vers 8 esclaves Modbus
15
2. Mise en œuvre matérielle de la passerelle LUFP9
Topologie « Bus » avec dérivations VW3 A8 306 TF3 : Cette topologie utilise des boîtiers de dérivation
VW3 A8 306 TF3 afin de relier chacun des esclaves Modbus au tronçon principal du réseau Modbus. Chaque
boîtier doit être placé à proximité immédiate de l’esclave Modbus auquel il est associé. Le câble du tronçon
principal du réseau Modbus doit être doté de connecteurs RJ45 mâles (tel que le câble VW3 A8 306 R•• utilisé
pour la topologie « étoile »). Le cordon reliant le boîtier de dérivation à l’esclave ou à la passerelle Modbus fait
partie intégrante de ce même boîtier. Les branchements sont schématisés ci-dessous :
Passerelle LUFP9
Modbus
VW3 A8 306 TF3
Terminaison
de ligne
Vers 2 esclaves Modbus
Vers 3 esclaves Modbus
Terminaison
de ligne
Vers 3 esclaves Modbus
16
2. Mise en œuvre matérielle de la passerelle LUFP9
Topologie « bus » avec boîtiers de dérivation : Cette topologie est similaire à la précédente, sauf qu'elle
utilise les connecteurs de l'abonné TSXSCA62 et/ou les connecteurs de l'abonné TSXCA50. Il est recommandé
d'utiliser un câble de connexion VW3 A68 306 et des câbles Modbus TSXCSA•00. Raccordez le connecteur
RJ45 du câble VW3 A68 306 au connecteur Modbus de la passerelle LUFP9.
Les branchements sont schématisés ci-dessous :
VW3 A68 306
TSXSCA62
Modbus
Passerelle LUFP9
TSXCSA•00
2.5.2. Brochage
En plus du brochage de la prise située sur la passerelle, celui du câble VW3 A68 306 est également présenté cidessous, car il est le seul câble Modbus à ne pas utiliser exclusivement une connectique en RJ45.
— Prise LUFP9 —
———— Câble VW3 A68 306 pour boîtier TSXSCA62 ————
RJ45 femelle
RJ45 mâle
SUB-D 15 points mâle
1
2
1
2
3
3
D(B)
4
D(B)
4
14 D(B)
D(A)
5
D(A)
5
7
0V
6
6
7
7
8
0V
8
D(A)
15 0 V
17
2. Mise en œuvre matérielle de la passerelle LUFP9
2.5.3. Recommandations de câblage du réseau Modbus
• Utilisez un câble blindé avec 2 paires de conducteurs torsadés,
• reliez les potentiels de référence entre eux,
• longueur maximale de la ligne : 1 000 mètres
• longueur maximale d’une dérivation : 20 mètres
• ne connectez pas plus de 9 stations sur un bus (esclaves et passerelle LUFP9 confondus),
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
Ne connectez pas plus de 9 stations au bus de terrain Modbus (8 esclaves et une passerelle). Même si la
passerelle semble fonctionner correctement avec plus de 9 périphériques, il est probable qu’un ou plusieurs
périphériques communiquent par intermittence uniquement, provoquant un comportement imprévisible du
système.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
• cheminement du câble : éloignez le bus des câbles d’alimentation (30 cm au minimum), effectuez les
croisements à angle droit si nécessaire et raccordez le blindage du câble à la masse de chaque équipement,
• adaptez la ligne à ses deux extrémités à l’aide d’un terminateur de ligne de type RC (voir schéma et
terminaison VW3 A8 306 RC ci-dessous).
D(B)
4
120 Ω
D(A)
5
1 nF
— Adaptation de fin de ligne recommandée aux 2 extrémités —
— Terminaison de ligne VW3 A8 306 RC —
AVERTISSEMENT
TERMINAISON DE LIGNE MODBUS À L’AIDE DE LA METHODE PAR RESISTANCE UNIQUEMENT
Utilisez uniquement des terminaisons de câble Modbus RC (Resistance-Capacitance) avec la passerelle
LUFP9. Les passerelles LUFP• sont conçues pour prendre en charge des équipements clients qui ne
fonctionneront pas correctement sans utiliser de terminaisons de câble Modbus de type RC.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Pour faciliter le raccordement des équipements selon les topologies décrites dans le chapitre 2.5.1 Configuration
de la passerelle, divers accessoires sont proposés dans le catalogue Schneider Electric :
18
2. Mise en œuvre matérielle de la passerelle LUFP9
1) Répartiteurs, dérivations et terminaisons de ligne :
Répartiteur LU9GC03 ........... Ce boîtier passif comporte 8 connecteurs femelles RJ45. Chacun de ces
(topologie « étoile »)
connecteurs peut être connecté à un esclave Modbus, à un maître Modbus, à un
autre répartiteur Modbus ou à une terminaison de ligne.
Boîtier de dérivation VW3 A8 306 TF3....
(topologie « bus » avec dérivations
VW3 A8 306 TF3)
Ce boîtier passif comporte un cordon court avec connecteur
RJ45 mâle permettant de le brancher directement sur un
esclave Modbus, sans devoir utiliser un câble distinct. Il est
équipé de 2 connecteurs femelles RJ45 pour le raccordement
de deux câbles Modbus de type VW3 A8 306 R••.
Prise abonnés 2 voies TSXSCA62
Ce boîtier passif comporte un circuit imprimé équipé de borniers
à vis et permet le raccordement de 2 abonnés sur le bus
(2 connecteurs SUB-D 15 points femelles). Il inclut la
terminaison lorsque le connecteur se situe en bout de ligne. Il
est équipé de 2 borniers à vis pour le raccordement de deux
câbles Modbus double paire torsadée.
(topologie « bus » avec boîtiers de dérivation)
Boîtier de dérivation TSXCA50
(topologie « bus » avec boîtiers de dérivation)
Double terminaison VW3 A8 306 RC
(toutes topologies)
Ce boîtier passif permet de connecter une unité Modbus à un
bornier à vis. Il inclut la terminaison lorsque le connecteur se
situe en bout de ligne. Il est équipé de 2 borniers à vis pour le
raccordement de deux câbles Modbus double paire torsadée.
Chacun de ces deux boîtiers passifs de couleur rouge est un
connecteur RJ45 mâle de 3 cm de long contenant une
terminaison de ligne RC (voir schéma et illustration ci-dessus).
Seule l’abréviation « RC » est portée sur ces boîtiers.
2) Câbles :
ƒ Câble Modbus VW3 A8 306 R••................................... Câble blindé doté d’un connecteur mâle RJ45 à
(topologie « étoile » / topologie « bus » avec boîtiers de
chacune de ses extrémités.
dérivation)
ƒ Câble Modbus VW3 A8 306 ......................................... Câble blindé doté d’un connecteur mâle RJ45 et d’un
(topologie « bus » avec boîtiers de dérivation)
connecteur SUB-D 15 points mâle. Il sert à raccorder
un abonné Modbus (esclave ou maître) à un boîtier
TSXSCA62 ou TSXCA50.
ƒ Câble Modbus double paire torsadée blindé................ Câble nu (sans connecteurs) destiné à constituer le
(topologie « bus » avec boîtiers de dérivation)
tronçon principal du réseau Modbus. Trois références
sont disponibles : TSXCSA100 (100 m), TSXCSA200
(200 m) et TSXCSA500 (500 m).
19
2. Mise en œuvre matérielle de la passerelle LUFP9
2.6. Connexion de la passerelle LUFP9 au réseau DeviceNet
Si la passerelle LUFP9 est
physiquement située à l’une des
deux extrémités du réseau
DeviceNet, il est nécessaire de
brancher une terminaison de
ligne aux bornes de son
connecteur DeviceNet.
Passerelle
LUFP9
Connecteur femelle
débrochable
La
résistance
de
cette
terminaison de ligne doit être
égale à 121 Ω et elle doit être
connectée entre les broches 2
et 4 du connecteur de la
passerelle, c’est-à-dire entre les
signaux CAN_L et CAN_H.
Câble DeviceNet
Brochage
Modbus
Broche
1
2
3
4
5
Nom
GND
CAN_L
SHIELD
CAN_H
V+
Couleur du fil
Noir
Bleu
Aucun (fil dénudé)
Blanc
Rouge
20
2. Mise en œuvre matérielle de la passerelle LUFP9
2.7. Configuration des fonctions de communication DeviceNet
Cette configuration doit être effectuée lorsque la passerelle est hors tension.
ATTENTION
OUVERTURE DU CAPOT DE LA PASSERELLE LUFP• SOUS TENSION
L’alimentation de la passerelle doit être coupée avant d’ouvrir le capot. Une fois le capot retiré, veillez à ne
toucher ni les circuits électriques, ni les composants électroniques, car vous risqueriez d’endommager
l’appareil.
Le non-respect de ces instructions peut entraîner des blessures ou des dommages matériels.
Le bloc de commutateurs permettant de configurer les fonctions de communication DeviceNet est dissimulé
derrière le capot g de la passerelle (voir illustration au chapitre 2.2 Présentation de la passerelle LUFP9
Pour retirer ce capot, il suffit de glisser la pointe d’un petit tournevis entre le sommet du capot et le boîtier de la
passerelle, puis de le dégager avec précaution.
Le bloc de commutateurs est schématisé ci-dessous, chaque commutateur étant symbolisé dans sa position de
réglage usine :
Vitesse
ON
1
2
Adresse (MAC ID)
3
4
5
6
7
Un commutateur est à l’état 0 lorsqu’il est en position
OFF et à l’état 1 lorsqu’il est en position ON.
Note : Toute modification des fonctions de
communication de la passerelle ne sera prise en
compte qu’à la prochaine mise sous tension de la
passerelle.
8
2.7.1. Codage de la vitesse DeviceNet
La vitesse de communication de la passerelle sur le réseau DeviceNet doit être identique à celle du maître
DeviceNet. Dans le cas contraire, une erreur de configuration surviendra.
Le réglage usine est 500 kbits/s.
La valeur de cette vitesse dépend du positionnement des commutateurs 1 et 2.
Vitesse
ON
1
2
Adresse (MAC ID)
3
4
5
6
7
8
Commutateurs
12345678
Débit DeviceNet
00xxxxxx
125 kbits/s
01xxxxxx
250 kbits/s
10xxxxxx
500 kbits/s
11xxxxxx
Configuration invalide
21
2. Mise en œuvre matérielle de la passerelle LUFP9
2.7.2. Codage de l’adresse de la passerelle
La passerelle LUFP9 est identifiée sur le bus DeviceNet par son adresse (ou « Mac ID »), comprise entre 0 et
63.
Vitesse
ON
1
2
Commutateurs
12345678
xx000000
xx000001
xx000010
xx000011
xx000100
xx000101
xx000110
xx000111
xx001000
xx001001
xx001010
xx001011
xx001100
xx001101
xx001110
xx001111
xx010000
xx010001
xx010010
xx010011
xx010100
xx010101
Adresse (MAC ID)
3
4
5
Adresse
DeviceNet
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
6
7
8
L’adresse DeviceNet de la passerelle dépend du
positionnement des commutateurs 3 à 8. Elle
correspond au nombre binaire donné par la position
ON (1) ou OFF (0) de ces 6 commutateurs.
Commutateurs
12345678
xx010110
xx010111
xx011000
xx011001
xx011010
xx011011
xx011100
xx011101
xx011110
xx011111
xx100000
xx100001
xx100010
xx100011
xx100100
xx100101
xx100110
xx100111
xx101000
xx101001
xx101010
xx101011
Adresse
DeviceNet
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Commutateurs
12345678
xx101100
xx101101
xx101110
xx101111
xx110000
xx110001
xx110010
xx110011
xx110100
xx110101
xx110110
xx110111
xx111000
xx111001
xx111010
xx111011
xx111100
xx111101
xx111110
xx111111
Adresse
DeviceNet
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
22
2. Mise en œuvre matérielle de la passerelle LUFP9
2.7.3. Exemples de configuration de la passerelle
Vitesse = 250 kbits/s
Adresse = 12
Vitesse
ON
1
2
Vitesse = 500 kbits/s
Adresse = 5
Adresse (MAC ID)
3
4
5
6
7
8
Vitesse
ON
1
2
Adresse (MAC ID)
3
4
5
6
7
8
23
3. Signalisation
Les 6 DEL de la passerelle et l’étiquette descriptive figurant sur le capot amovible permettent de diagnostiquer
l’état de la passerelle :
d
c
LUFP9
n o
p q
r s
f
e
1 NETWORK STATUS
2 MODULE STATUS
3 NOT USED
4 NOT USED
5 MODBUS
6 GATEWAY
h
g
DeviceNet™
DEL
n
p
NETWORK
STATUS
NOT
USED
DEL Æ Etat de la passerelle
Eteinte : Passerelle non
connectée au bus DeviceNet.
Verte : Passerelle connectée au
bus DeviceNet : Connexion
établie
Rouge : Echec fatal lors de la
connexion au bus DeviceNet
Clignotante (vert) : Passerelle
connectée au bus DeviceNet :
Connexion non établie
Clignotante (rouge) :Timeout de
connexion au bus DeviceNet
La durée de ce timeout est
définie par le maître DeviceNet.
DEL
Eteinte : Pas d'alimentation
o
MODULE
STATUS
Clignotante (rouge) : Défaillance
q
NOT
USED
Eteinte : —
GATEWAY
Eteinte : Pas d'alimentation
Clignotante (rouge/vert) :
Configuration absente / non valide
Utilisez ABC-LUFP Config
Tool pour charger une
configuration correcte.
Verte : Passerelle en cours
d’initialisation et de configuration
Clignotante (vert) :
Passerelle en ordre de
fonctionnement : Configuration
OK
Eteinte : Pas d'alimentation
Verte : Communications Modbus
OK
r
MODBUS
Rouge :
- Perte de communication avec un
ou plusieurs esclaves Modbus
(pas de réponse de l’esclave) (1)
Rouge : Défaut irrémédiable
Verte : Passerelle opérationnelle
Eteinte : —
Clignotante (vert) : Pas de
communications Modbus
DEL Æ Etat de la passerelle
s
- Code d’exception provenant
d’une commande ou d’une
transaction
(1) La DEL Modbus r devient rouge lorsqu’un ou plusieurs esclaves Modbus ne répondent pas à la passerelle de
façon attendue. Ce comportement peut être dû à :
24
3. Signalisation
ƒ une perte de communication (un câble est endommagé ou déconnecté, par exemple),
ƒ une écriture de valeurs incorrecte dans les sorties qui correspondent aux deux services apériodiques de
lecture/écriture (voir chapitre 4.3, Description des services affectés aux E/S de la passerelle).
Note : Lorsque la DEL MODBUS r clignote en rouge en raison d’une simple perte de communication, elle
redeviendra verte lorsque les communications sont restaurées. Lorsque la DEL (5) clignote en rouge en raison
de l’utilisation de valeurs incorrectes avec les services apériodiques de lecture/écriture, la seule façon d'effacer
cette erreur est de réutiliser ces services apériodiques avec des valeurs correctes.
Note : Si la DEL DEVICENET STATUS s clignote suivant une séquence commençant par un ou plusieurs
flashs rouges, il est conseillé de noter l’ordre du déroulement de cette séquence et de communiquer ces
renseignements au service de support de Schneider Electric. Dans certains cas, le problème se résout
simplement par la mise hors tension de la passerelle puis sa remise sous tension.
25
4. Mise en œuvre logicielle de la passerelle
4.1. Introduction
Ce chapitre présente une mise en œuvre rapide de la passerelle LUFP9, grâce à l’utilisation de sa configuration
par défaut, l’ensemble des passerelles LUFP9 étant livrées pré-configurées.
NOTE : La configuration a été définie pour 8 départs-moteurs. Si vous en utilisez moins de 8, reportez-vous au
chapitre 6, Configuration de la passerelle.
La configuration par défaut proposée par Schneider Electric a pour objectif de fournir un bon point de départ
pour les clients utilisant des départs-moteurs TeSys U, ainsi que de limiter les modifications de la configuration
nécessaires pour la plupart des installations. La configuration par défaut permet la mise en œuvre de la
passerelle à l’aide d’un outil de configuration pour automate maître DeviceNet. Cependant, il incombe à
l’utilisateur uniquement de s’assurer que la configuration par défaut, ou toute autre configuration, est sûre et
appropriée pour ses installations et l’usage prévu.
4.1.1. Architecture système
La configuration par défaut d’une passerelle LUFP9 lui permet d’effectuer la commande, la surveillance et le
paramétrage de 8 départs-moteurs TeSys U :
Automate
maître
DeviceNet
(SLC500)
DeviceNet (réseau amont)
Passerelle
LUFP9
Adresses
Modbus
c
d
e
f
Total de 8
départs-moteurs
(modèle TeSys U)
g
h
i
j
Modbus (réseau aval)
Terminaison
de ligne
Boîtiers de
connexion
Reportez-vous au chapitre 2 passerelle LUFP9, pour la mise en œuvre matérielle de la configuration par défaut.
26
4. Mise en œuvre logicielle de la passerelle
4.1.2. Configuration des départs-moteurs
Chaque départ-moteur doit être configuré de la manière suivante :
Protocole :
Adresse Modbus
Vitesse de transmission
Bits de données
Modbus RTU esclave
1à8
19 200 bits/s
8
Bits de start
Parité
Bit de parité
Bits de stop
1
Aucune
0
1
Dans le cas d’un départ-moteur TeSys U doté d’un module de communication Modbus (module LULC031), les
paramètres de configuration de la liaison RS485 sont automatiquement détectés ; seule doit être configurée
l’adresse Modbus du départ-moteur.
4.1.3. Temps de cycle Modbus
La configuration par défaut de la passerelle LUFP9 impose un temps de cycle de 300 ms aux commandes
Modbus. Ce temps de cycle correspond au temps d’interrogation nécessaire pour couvrir les 8 départs-moteurs.
4.1.4. Gestion des modes dégradés avec la configuration par défaut de la passerelle
La gestion des modes dégradés avec la configuration par défaut de la passerelle est décrite ci-dessous, mais
elle ne tient pas compte de l’automate utilisé, ni du scanner DeviceNet. Reportez-vous au chapitre 6.11.2.1
Gestion des modes dégradés, si vous souhaitez gérer les modes dégradés de toute autre configuration.
4.1.4.1. Description des options de mode dégradé de la passerelle
Offline options for fieldbus
Cette option affecte les données envoyées à un esclave Modbus si aucune communication ne provient du
maître DeviceNet.
Elle est définie au niveau de la requête de chaque commande ou transaction envoyée aux différents esclaves.
Cette option peut prendre 3 valeurs :
Clear :
Toutes les données envoyées à l’esclave Modbus concerné ont la valeur 0.
Freeze :
Toutes les données envoyées conservent leur valeur actuelle.
No scanning : La requête n'est plus transmise.
Avec la configuration par défaut de la passerelle :
L’option « Clear » est sélectionnée pour les échanges périodiques.
L’option « No scanning » est sélectionnée pour les échanges apériodiques.
Cela signifie que les registres Tesys Command et Status continuent à être actualisés,
mais la mémoire de sortie associée (registres de commande du Tesys U) est forcée à 0,
et la mémoire d’entrée (registres d’état du Tesys U) fonctionne normalement,
alors que les échanges Modbus apériodiques sont interrompus.
Timeout time
Cette option définit le délai pendant lequel la passerelle attend une réponse avant d’essayer de renvoyer la
même requête ou de déconnecter l’esclave et de le déclarer manquant.
Elle est définie au niveau de la requête de chaque commande ou transaction envoyée aux différents esclaves.
Avec la configuration par défaut de la passerelle, ce délai est de 300 ms.
27
4. Mise en œuvre logicielle de la passerelle
Retries
Cette option détermine le nombre de retransmissions effectuées par la passerelle en cas d’absence de réponse
de l’esclave.
Elle est définie au niveau de la requête de chaque commande ou transaction envoyée aux différents esclaves.
Avec la configuration par défaut de la passerelle, cette option est définie sur la valeur 3.
Reconnect time
Cette option définit le temps durant lequel la passerelle attend une réponse avant de reconnecter un esclave
manquant.
Elle est définie au niveau de la requête de chaque commande ou transaction envoyée aux différents esclaves.
Avec la configuration par défaut de la passerelle, ce délai est de 10 secondes.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
Durant le délai de reconnexion, il est impossible de contrôler un esclave (lecture/écriture) via le bus. Selon les
caractéristiques de l’esclave et la configuration du chien de garde, l’esclave peut conserver le même état ou
prendre une position de repli.
Afin d’éviter tout fonctionnement imprévu de l’appareil, vous devez connaître l’état possible d’un esclave et
adapter le délai de timeout et de reconnexion en fonction de la vitesse d’envoi de la requête.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Offline options for sub-network
Cette option affecte les données envoyées au scanner DeviceNet lorsque aucune réponse ne provient d'un
esclave.
Elle est définie au niveau de la réponse de chaque commande ou transaction envoyée depuis les différents
esclaves.
Cette option peut prendre 2 valeurs :
Clear :
Toutes les données envoyées au scanner DeviceNet ont la valeur 0.
Freeze : Toutes les données envoyées au scanner DeviceNet conservent leur valeur actuelle.
Avec la configuration par défaut de la passerelle, l’option « Clear » est sélectionnée et les registres d’état du
Tesys U ainsi que les données d’entrée apériodiques sont forcées à 0.
4.1.4.2. Description du mode dégradé
Cette description prend en compte les éléments suivants :
Le processeur de l’automate
Le scanner DeviceNet
La passerelle LUFP9
Les démarreurs-contrôleurs Tesys U.
28
4. Mise en œuvre logicielle de la passerelle
Arrêt ou défaillance du processeur de l’automate
Réponse du processeur de l’automate
Sorties :
Erreur logicielle, réinitialisation des sorties sur leur état par défaut ou conservation de leur état
actuel, selon la configuration.
Erreur matérielle (EEPROM ou défaillance matérielle), état de sortie indéterminé.
Entrées :
L’automate cesse de répondre aux entrées, quel que soit l’état d’erreur.
Réponse du scanner DeviceNet
En fonction de la configuration du scanner :
le scanner cesse de communiquer avec la passerelle LUFP9,
force les sorties DeviceNet sur la valeur 0 et actualise les entrées
ou maintient les sorties DeviceNet sur leur dernière position et actualise les entrées.
Réponse de la passerelle LUFP9
Si le scanner cesse de communiquer avec la passerelle :
les échanges Modbus périodiques continuent de s’exécuter
avec la mémoire de sortie associée forcée sur la valeur 0,
la mémoire d’entrée continue à être actualisée,
les échanges Modbus apériodiques sont interrompus.
Si le scanner force les sorties DeviceNet sur la valeur 0 et actualise les entrées :
les échanges Modbus périodiques continuent de s’exécuter
avec les sorties définies sur 0,
la mémoire d’entrée continue à être actualisée,
les échanges Modbus apériodiques sont interrompus.
Si le scanner maintient les sorties DeviceNet et actualise les entrées :
les échanges Modbus périodiques continuent de s’exécuter
avec la mémoire de sortie associée maintenue sur sa dernière position,
la mémoire d’entrée continue à être actualisée,
les échanges Modbus apériodiques sont interrompus.
Réponse du Tesys U
Si le scanner cesse de communiquer ou force les sorties sur 0 :
les échanges Modbus périodiques continuent de s’exécuter
les registres de commande sont définis sur 0 et les moteurs sont arrêtés,
le registre d’état est transmis à la passerelle,
les échanges Modbus apériodiques sont interrompus.
Si le scanner maintient les mots de sortie DeviceNet et actualise les mots d’entrées :
les échanges Modbus périodiques continuent de s’exécuter,
les registres de commande conservent leur dernière valeur et les moteurs restent
dans le même état,
les données du registre d’état sont transmises à la passerelle,
les échanges Modbus apériodiques sont interrompus.
29
4. Mise en œuvre logicielle de la passerelle
Arrêt ou défaillance du scanner DeviceNet
Réponse du processeur de l’automate
Le processeur de l’automate fournit à l’application plusieurs erreurs et/ou objets de diagnostic au cas
où le scanner DeviceNet cesserait de fonctionner ou connaîtrait une défaillance (entrée/sortie non
valide).
Reportez-vous au manuel d’utilisation de l’automate pour consulter leur description.
Ces informations doivent être gérées dans l’application de l’automate.
Réponse du scanner DeviceNet
Si le scanner DeviceNet est arrêté (commande provenant de l’application) :
le scanner cesse de communiquer avec la passerelle LUFP9.
Si le scanner DeviceNet connaît une défaillance,
le scanner cesse de communiquer avec le processeur et la passerelle LUFP9.
Réponse de la passerelle LUFP9
Avec la configuration par défaut de la passerelle (Offline option for fieldbus) :
les échanges Modbus périodiques continuent de s’exécuter,
avec la mémoire de sortie associée forcée sur la valeur 0,
la mémoire d’entrée continue à être actualisée,
les échanges Modbus apériodiques sont interrompus.
Réponse du Tesys U
les échanges Modbus périodiques continuent de s’exécuter :
les registres de commande sont définis sur 0 et les moteurs sont arrêtés,
les données du registre d’état sont transmises à la passerelle,
les échanges Modbus apériodiques sont interrompus.
Passerelles LUFP9 déconnectées du côté DeviceNet
Réponse de l’automate
Le processeur de l’automate fournit plusieurs objets d’erreur et de diagnostic provenant du scanner
DeviceNet en cas de déconnexion d’un esclave de l’application :
Reportez-vous au manuel d’utilisation de l’automate pour consulter leur description.
Ces informations doivent être gérées dans l’application de l’automate.
Réponse du scanner DeviceNet
Le scanner DeviceNet fournit au processeur différents objets d’erreur et de diagnostic en cas de
déconnexion d’un esclave DeviceNet.
Réponse de la passerelle LUFP9
Avec la configuration par défaut de la passerelle (Offline option for fieldbus) :
Les échanges Modbus périodiques continuent de s’exécuter,
avec la mémoire de sortie associée forcée sur la valeur 0,
la mémoire d’entrée continue à être actualisée,
les échanges Modbus apériodiques sont interrompus.
Réponse du Tesys U
Les échanges Modbus périodiques continuent de s’exécuter :
Les registres de commande sont définis sur 0 et les moteurs sont arrêtés,
les données du registre d’état sont transmises à la passerelle,
les échanges Modbus apériodiques sont interrompus.
30
4. Mise en œuvre logicielle de la passerelle
Défaillance des passerelles LUFP9
Réponse de l’automate
Le processeur de l’automate fournit plusieurs objets d’erreur et de diagnostic provenant du scanner
DeviceNet en cas de défaillance d’un esclave vers l’application.
Reportez-vous au manuel d’utilisation de l’automate pour consulter leur description.
Ces informations doivent être gérées dans l’application de l’automate.
Réponse du scanner DeviceNet
Le scanner DeviceNet fournit au processeur différents objets d’erreur et de diagnostic en cas de
défaillance d’un esclave DeviceNet.
Réponse de la passerelle LUFP9
En cas de défaillance, la passerelle cesse de communiquer avec le scanner DeviceNet et les esclaves
Modbus.
Réponse du Tesys U
Selon la configuration du Tesys U :
Si les démarreurs-contrôleurs ne reçoivent aucune requête, ils :
stoppent le moteur,
conservent le même état
ou actionnent le moteur.
Reportez-vous aux manuels d’utilisation du Tesys U pour régler ces positions de repli.
Passerelles LUFP9 déconnectées du côté Modbus ou défaillance du Tesys U
Réponse de l’automate
Le processeur donne accès au mot d’état de la passerelle provenant de la table d’entrée du scanner
DeviceNet, ainsi qu’au mot de commande de la passerelle provenant de la table de sortie.
Ces 2 mots doivent être gérés dans l'application de l'automate afin de détecter si un esclave Modbus
est manquant.
Réponse du scanner DeviceNet
Le scanner DeviceNet doit être configuré de façon à accéder à l'état de la passerelle et aux mots de
commande afin de fournir des informations de diagnostic Modbus.
Réponse de la passerelle LUFP9
Avec la configuration par défaut de la passerelle : Timeout time = 300 ms, Retries = 3,
Reconnect time = 10 sec et Offline option for sub-network = Clear.
Après l’envoi d’une requête à un esclave, si aucune réponse ne parvient après 300 ms, la passerelle
l’envoie de nouveau deux fois avant de fournir des informations relatives à l’esclave manquant dans le
mot d’état de la passerelle. Toutes les données envoyées au scanner DeviceNet (requêtes de lecture)
ont la valeur 0. La passerelle essaie de reconnecter l’esclave manquant en respectant le même ordre
toutes les 10 secondes.
Réponse du Tesys U
Si la passerelle LUFP9 est déconnectée du côté Modbus :
Les démarreurs-contrôleurs ne reçoivent aucune requête. Selon leur configuration, ils :
stoppent le moteur,
conservent le même état
ou actionnent le moteur.
Reportez-vous aux manuels d’utilisation du Tesys U pour régler la position de repli.
En cas de défaillance du Tesys U :
Aucune réponse n’est envoyée à la passerelle. L’état du moteur est indéterminé. Ce cas doit être
gérée dans l’application de l’automate.
31
4. Mise en œuvre logicielle de la passerelle
4.2. Configuration de la passerelle sous RsNetWorx
L’automate maître DeviceNet doit être configuré de façon à avoir accès à toutes les données décrites dans
l’Appendix B: Configuration par défaut, mémoire de données d'entrée et de sortie.
Les chapitres suivants décrivent les étapes de configuration sous RSNetWorx qu’il est nécessaire d’effectuer pour
que la passerelle soit correctement reconnue par l’automate maître DeviceNet.
NOTE : Le réseau DeviceNet qui est décrit dans les chapitres suivants comporte un maître et un seul esclave
(passerelle LUFP9). Vous devrez donc adapter l’adressage des entrées et des sorties présenté ci-après (%IW et
%QW) en fonction des autres esclaves du réseau DeviceNet que vous aurez à configurer.
4.2.1. Sélection et ajout du scanner DeviceNet de l’automate maître
Sous RSNetWorx, sélectionnez le type de scanner dont vous disposez et ajoutez-le à la topologie du réseau
DeviceNet.
Dans notre exemple, ce scanner est un « 1747-SDN Scanner Module (4) » et son adresse MAC ID est égale
à 00.
4.2.2. Mise en place du fichier de description de la passerelle
Le fichier EDS qui décrit la passerelle doit être placé sur le disque dur du PC afin que le logiciel RSNetWorx
puisse y avoir accès à tout moment.
Ce fichier est situé sur le CD LU9CD1 : « LUFP9_100.eds ».
Î Une fois sous RSNetWorx, reportez-vous à sa documentation afin de prendre connaissance de la procédure
à effectuer pour importer un fichier EDS. Cette procédure doit être ensuite appliquée au fichier
« LUFP9_100.eds ». Elle utilise l’assistant « EDS wizard », accessible depuis le menu « Tools ».
Les deux entrées suivantes sont alors ajoutées dans l’arborescence des produits DeviceNet reconnus :
•
DeviceNet / Category / Communication Adapter / LUFP9
•
DeviceNet / Vendor / Schneider Automation / LUFP9
32
4. Mise en œuvre logicielle de la passerelle
4.2.3. Sélection et ajout d’une passerelle au réseau DeviceNet
Sélectionnez « LUFP9 » dans la liste de gauche, puis ajoutez-le à la topologie du réseau DeviceNet.
Dans notre exemple, nous avons affecté l’adresse MAC ID à la passerelle (la configuration de l’adresse d’une
passerelle est décrite dans le chapitre 2.7.2 2.7.2).
4.2.4. Modification des paramètres de la passerelle
Double-cliquez sur l’icône qui correspond à la passerelle, dans le cadre droit.
Dans la fenêtre qui apparaît alors, sélectionnez l’onglet « Device Parameters » et vérifiez que les valeurs des
paramètres correspondent à celles des paramètres reproduits ci-dessous.
Au besoin, modifiez-les (seuls les paramètres 1 à 5 sont accessibles en écriture pour l’utilisateur), puis cliquez
sur le bouton « Download To Device » afin de transmettre ces modifications à la passerelle.
33
4. Mise en œuvre logicielle de la passerelle
En cas de doute sur l’affichage obtenu, cliquez sur le bouton « Upload From Device », puis sur « Start Monitor ». Le
logiciel RSNetWorx commence alors à lire dans la passerelle les valeurs des paramètres affichés. Cliquez sur le
bouton « Stop Monitor » pour arrêter ce processus de lecture.
Les paramètres les plus importants, dans le cas de la configuration par défaut de la passerelle, sont les
paramètres 1 et 2 (transferts périodiques entre l’automate et la passerelle via une connexion périodique appelée
« polled »), 6 et 7 (offset et taille de la zone des données d’entrée dans la mémoire d’entrée de la passerelle), 18
et 19 (offset et taille de la zone des données de sortie dans la mémoire de sortie de la passerelle). La valeur de
chaque paramètre de type « offset » fait référence à un décalage depuis le début de la zone mémoire des
données d’entrée de la passerelle.
NOTE : Seul le contrôle des zones « Input1 » et « Output1 » est évoqué dans ce manuel. Le contrôle des zones
Input2 à Input6 et Output2 à Output6 est une application avancée et ne constitue pas l’objet de ce manuel.
Contactez le service de support de Schneider Electric pour obtenir de l’aide concernant le contrôle de ces
paramètres.
NOTE : Si vous créez ou modifiez une configuration à l'aide de ABC-LUFP Config Tool (voir le chapitre 6),
vérifiez que les zones de données d’entrée / sortie définies dans la mémoire de la passerelle sont appropriées
pour la nouvelle configuration et pour les communications à l’aide du maître DeviceNet. Ces zones de données
d’entrée / sortie définissent l’ensemble des octets échangés avec les esclaves Modbus via les champs « Data »
ou « Preset Data » des trames Modbus. Le non-respect de ces étapes peut générer une erreur de configuration.
34
4. Mise en œuvre logicielle de la passerelle
4.2.5. Configuration du Scanner DeviceNet
Double-cliquez sur l’icône qui correspond au scanner DeviceNet.
La fenêtre qui apparaît alors permet de configurer les échanges effectués par le scanner. Sélectionnez l’onglet
« Scanlist » et ajoutez la passerelle « LUFP9 » à la « Scanlist » (boutons > ou >> ). Après sélection de la
passerelle dans cette liste, le bouton « Edit I/O Parameters… » devient accessible.
Cliquez sur le bouton « Edit I/O
Parameters… ».
Dans la fenêtre qui apparaît alors, cochez la
case « Polled: », puis configurez la taille des
données reçues (Rx = 32 octets) et la taille des
données émises (Tx = 32 octets) par le
scanner.
Dans le cas de la configuration par défaut de la
passerelle LUFP9, ces valeurs permettent
d’échanger
l’ensemble
des
données
présentées dans l’Appendix B: Configuration
par défaut.
NOTE : Si vous créez ou modifiez une configuration à l'aide de ABC-LUFP Config Tool, reportez-vous au
chapitre 6 Configuration de la passerelle
35
4. Mise en œuvre logicielle de la passerelle
4.2.6. Configuration des entrées issues de la passerelle
Dans l’onglet « Input », sélectionnez la passerelle « LUFP9 », puis cliquez sur le bouton « AutoMap ».
RSNetWorx établit alors de manière automatique la correspondance entre les 32 octets de données (format
8 bits) issues de la passerelle et les 16 entrées automate « I:1.1 » à « I:1.16 » (format 16 bits) correspondantes.
Vérifiez qu’une correspondance entre toutes les données issues de la passerelle et les entrées automate
« I:1.1 » à « I:1.16 » a été établie.
La correspondance entre le contenu de la mémoire d’entrée de la passerelle (voir Appendix B: Configuration par
défaut) et les entrées de l’automate « I:1.1 » à « I:1.16 » est donnée dans le tableau suivant :
Service
Entrée
Automate
Gestion du réseau aval Modbus
(Mots d’état)
I:1.1
Communications périodiques
—
Surveillance des
départs-moteurs TeSys U
I:1.2
I:1.3
I:1.4
I:1.5
I:1.6
I:1.7
I:1.8
I:1.9
Communications apériodiques
—
Lecture de la valeur d’un paramètre de
départ-moteur (REPONSE)
Communications apériodiques
—
Ecriture de la valeur d’un paramètre de
départ-moteur (REPONSE)
Communications apériodiques
(« Trigger bytes » des réponses)
I:1.10
I:1.11
I:1.12
I:1.13
I:1.14
I:1.15
I:1.16
Description
Bit 0......................... Bit 7 Bit 8........................Bit 15
Mot d’état de la passerelle LUFP9
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Valeur du registre d’état du départ-moteur c
Valeur du registre d’état du départ-moteur d
Valeur du registre d’état du départ-moteur e
Valeur du registre d’état du départ-moteur f
Valeur du registre d’état du départ-moteur g
Valeur du registre d’état du départ-moteur h
Valeur du registre d’état du départ-moteur i
Valeur du registre d’état du départ-moteur j
Emplacement mémoire
N° esclave (0x01-0x08)
libre
Numéro de la fonction
Nombre d’octets
(0x03)
lus (0x02)
Valeur du paramètre lu
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
N° esclave (0x01-0x08)
N° fonction (0x06)
Adresse du paramètre écrit
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Valeur du paramètre écrit
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Compteur de réponse de
Compteur de réponse de
la lecture d’un paramètre
l’écriture d’un paramètre
36
4. Mise en œuvre logicielle de la passerelle
4.2.7. Configuration des sorties destinées à la passerelle
Dans l’onglet « Output », sélectionnez la passerelle « LUFP9 », puis cliquez sur le bouton « AutoMap ». RSNetWorx
établit alors de manière automatique la correspondance entre les 32 octets de données (format 8 bits) à transmettre à
la passerelle et les 16 sorties automate « O:1.1 » à « O:1.16 » (format 16 bits) correspondantes.
Vérifiez qu’une correspondance entre toutes les données destinées à la passerelle et les sorties automate
« O:1.1 » à « O:1.16 » a été établie.
La correspondance entre le contenu de la mémoire de sortie de la passerelle (voir Appendix B: Configuration par
défaut et les sorties de l’automate “O:1.1” à “O:1.16” est donnée dans le tableau suivant :
Service
Gestion du réseau aval Modbus
(Mot de commande)
Communications
périodiques
—
Commande des
départs-moteurs TeSys U
Communications apériodiques
—
Lecture de la valeur d’un
paramètre de départ-moteur
(REQUETE)
Communications apériodiques
—
Ecriture de la valeur d’un
paramètre de départ-moteur
(REQUETE)
Communications apériodiques
(« Trigger bytes » des requêtes)
Sortie
Automate
O:1.1
O:1.2
O:1.3
O:1.4
O:1.5
O:1.6
O:1.7
O:1.8
O:1.9
O:1.10
O:1.11
O:1.12
O:1.13
O:1.14
O:1.15
O:1.16
Description
Bit 0......................Bit 7
Bit 8 ...................Bit 15
Mot de commande du maître DeviceNet
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Valeur du registre de commande du départ-moteur c
Valeur du registre de commande du départ-moteur d
Valeur du registre de commande du départ-moteur e
Valeur du registre de commande du départ-moteur f
Valeur du registre de commande du départ-moteur g
Valeur du registre de commande du départ-moteur h
Valeur du registre de commande du départ-moteur i
Valeur du registre de commande du départ-moteur j
N° esclave (0x01-0x08)
N° fonction (0x03)
Adresse du paramètre à lire
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Nombre de paramètres à lire
(MSB Æ 0x00••)
(LSB Æ 0x••01)
N° fonction (0x06)
N° esclave (0x01-0x08)
Adresse du paramètre à écrire
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Valeur du paramètre à écrire
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Compteur de requête de
Compteur de requête de
la lecture d’un paramètre
l’écriture d’un paramètre
37
4. Mise en œuvre logicielle de la passerelle
4.2.8. Transfert de la configuration du scanner DeviceNet
Une fois que vous aurez achevé les opérations précédemment décrites, assurez-vous que les modifications
effectuées sont transmises au scanner DeviceNet. Pour cela, cliquez sur le bouton « Download to Scanner… »
présent dans chacun des onglets « Module » et « Scanlist » de la fenêtre des propriétés du scanner DeviceNet.
Si besoin est, reportez-vous à la documentation de RSNetWorx pour de plus amples détails à ce sujet.
4.2.9. Développement d’une application DeviceNet.
L’automate maître DeviceNet pris pour exemple est un SLC500, commercialisé par Allen Bradley. Un exemple
d’application automate, développé sous RSLogix 500, est présenté dans l’Appendix C: Exemple d’utilisation
(RSLogix 500)
Cet exemple utilise l’automate, la passerelle et les 8 départs-moteurs TeSys U présentés dans la section Mise
en œuvre logicielle de la passerelleDescription des services affectés aux entrées/sorties de la passerelle.
4.3. Description des services affectés aux E/S de la passerelle :
Communications périodiques Reportez-vous au chapitre 5.2, Diagnostic seul pour obtenir une description
détaillée de ce service. L’exemple fourni et décrit dans Appendix C: Programme principal, effectue uniquement
un acquittement automatique des diagnostics de la passerelle, c’est-à-dire qu’il n’exploite pas les données de
ces diagnostics. Dans le cas de la configuration par défaut de la passerelle, dans ABC-LUFP Config Tool, le
champ « Control/Status Byte » de l’élément « ABC » est défini sur « Enabled but no startup lock ».
Communications périodiques (entrées) : La valeur de chacun des 8 mots de ce service correspond à celle du
registre d’état d’un départ-moteur TeSys U (registre situé à l’adresse 455).
Communications périodiques (sorties) : La valeur de chacun des 8 mots de ce service correspond à la valeur
à destination du registre de commande d’un départ-moteur TeSys U (registre situé à l’adresse 704).
Reportez-vous à l’Appendix C: Sous-programme de commande/surveillance, pour consulter un exemple
d’utilisation simplifiée de ces services de « communications périodiques ».
Communications apériodiques : Reportez-vous à l’Appendix C: Sous-programme de lecture d’un paramètre…
et Sous-programme d’écriture d’un paramètre…, pour consulter un exemple d’utilisation des services de
« communications apériodiques ».
Ces services de communications apériodiques proposent des fonctions similaires à celles des « variables
périodiques indexées », ou PKW, que l’on peut trouver sur certains produits Schneider Electric, tels que les
variateurs de vitesse de type ATV.
Lors de l’utilisation d'entrées et de sorties 16 bits pour lesquelles l'ordre du LSB et du MSB est spécifié, le maître
DeviceNet utilise les octets dans l’ordre LSB MSB (‘Big Endian’), alors que les esclaves Modbus utilisent l’ordre
MSB LSB (‘Little Endian’). Dans de nombreuses situations, le maître DeviceNet gère cette conversion en
interne. Il est possible que cela ne soit pas le cas avec certaines configurations, certains services apériodiques
ou certaines applications personnalisées. Il est nécessaire que ce comportement soit correctement identifié
avant de mettre le système en service.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
L’utilisateur doit s’assurer que la conversion de l’ordre des octets (‘Endian’) dans un mot de 16 bits est
correcte entre les bus de terrain DeviceNet et Modbus. Durant la configuration du maître DeviceNet, lors de
l’utilisation d’applications personnalisées ou lors d’une opération de programmation visant à établir une
communication entre le maître DeviceNet et les esclaves Modbus par l’intermédiaire de la passerelle, la
gestion de l’ordre des octets (‘Endian’) dans un mot de 16 bits doit être correcte pour chaque bus de terrain.
Si l’ordre des octets transmis à des entrées et à des sorties de 16 bits est gérée de façon inappropriée, des
données incorrectes peuvent être écrites dans la configuration du périphérique Modbus ou dans les registres
de commande, provoquant un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
38
4. Mise en œuvre logicielle de la passerelle
• Exemple de lecture d’un paramètre de départ-moteur :
Lecture du 1er registre de défaut (adresse = 452 = 0x01C4) sur le départ-moteur « TeSys U n°5 ». Les
valeurs initiales de O:1.16 et de I:1.16 sont égales à 0x1306. Le résultat de la lecture est 0x0002 (défaut
magnétique).
Sortie
O:1.10
Valeur
0x0305
O:1.11
0xC401
O:1.12
0x0100
O:1.16
0x1307
Signification (MSB + LSB)
N° Fonction + N° Esclave
Adresse paramètre (MSB↔LSB)
Nombre de paramètres (MSB↔LSB)
« Trigger byte » de la requête
(LSB)
Entrée
I:1.10
Valeur
0x0500
Signification (MSB + LSB)
N° Esclave + (non utilisé)
I:1.11
0x0203
Nombre d’octets + N° Fonction
I:1.12
0x0200
Valeur lue (MSB↔LSB)
I:1.16
0x1307
« Trigger byte » de la réponse (LSB)
• Exemple d’écriture d’un paramètre de départ-moteur :
Ecriture du 2nd registre de commande (adresse = 705 = 0x02C1) sur le départ-moteur « TeSys U n°7 » à la
valeur 0x0006 (RAZ statistiques + RAZ mémoire thermique). Les valeurs initiales de O:1.16 et de I:1.16 sont
égales à 0x1307. Le résultat de l’écriture est un écho à la commande, c’est-à-dire que les valeurs des champs
« adresse paramètre » et « valeur à écrire » sont identiques dans la requête et dans la réponse.
Sortie
O:1.13
Valeur
0x0607
O:1.14
0xC102
O:1.15
0x0600
O:1.16
0x1407
Signification (MSB + LSB)
N° Fonction + N° Esclave
Adresse paramètre (MSB↔LSB)
Valeur à écrire (MSB↔LSB)
« Trigger byte » de la requête
(MSB)
Entrée
I:1.13
Valeur
0x0607
I:1.14
0xC102
Signification (MSB + LSB)
N° Fonction + N° Esclave
Adresse paramètre (MSB↔LSB)
I:1.15
0x0600
Valeur à écrire (MSB↔LSB)
I:1.16
0x1407
« Trigger byte » de la réponse (MSB)
Aucune vérification des erreurs n’est effectuée pour les données transmises à l’aide des services apériodiques
décrits ci-dessus. Les valeurs incorrectes écrites vers les sorties et qui correspondent à des services de
communication apériodiques provoqueront la transmission d’un cadre Modbus incohérent. Ce cadre Modbus
incohérent peut retourner une erreur ou provoquer un comportement imprévisible des périphériques esclaves.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
L’utilisateur doit vérifier les erreurs et les gérer de façon appropriée pour les valeurs écrites vers les sorties,
qui correspondent aux services de communication apériodiques. L’envoi de valeurs incorrectes aux sorties
des services apériodiques peut provoquer un comportement imprévisible du système.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
39
5. Initialisation et diagnostic de la passerelle
Ce chapitre décrit le principe de l’initialisation et du diagnostic de la passerelle selon chacune des trois options
offertes par celle-ci. Ces options peuvent être configurées via ABC-LUFP Config Tool, en modifiant l’affectation
du champ « Control/Status Byte » de l’élément « ABC » (voir chapitre 6.12.2). Ces options sont les suivantes :
Champ « Control/Status Byte » :
Signification
Activé..................................................................Gestion complète
Enabled but no startup lock ..............................Diagnostic seul
Désactivé ...........................................................Fonctionnement simplifié
L’option retenue dans le cas de la configuration par défaut est l’option « Enabled but no startup lock »,
encadrée ci-dessus.
Gestion dans l’application d’automate :
Æ du démarrage des échanges Modbus cycliques
Æ du diagnostic du réseau Modbus.
Gestion dans l’application d’automate :
Diagnostic seul
Æ du diagnostic du réseau Modbus.
Æ Démarrage automatique des échanges Modbus cycliques
Fonctionnement simplifié
Æ Aucun diagnostic du réseau Modbus
Gestion complète
5.1. Gestion complète
Le maître DeviceNet gère le démarrage des échanges Modbus cycliques et du diagnostic Modbus au moyen de
2 mots :
ƒ
Un mot de commande DeviceNet
transmis par l’application de l’automate
et associé aux adresses 0x0200 et 0x0201 de la mémoire de sortie de la passerelle ;
ƒ
Un mot d’état de la passerelle
transmis par la passerelle
et associé aux adresses 0x0000 et 0x0001 de la mémoire d’entrée de la passerelle.
Le mot d’état de la passerelle n’est pas actualisé de façon cyclique. La mise à jour de ce mot repose sur un
système de bit de basculement qui doit être géré dans l’application de l’automate :
Le diagnostic est actualisé par la passerelle à l’aide du bit de basculement B15.
Toute nouvelle commande provenant du maître DeviceNet est envoyée à l’aide du bit de basculement B14.
5.1.1. Mot de commande du maître DeviceNet
B15 B14 B13 B12 B11 B10 B9 B8
B7 B6
B5 B4 B3
B2
B1 B0
Réservé
FB_DU : démarrage des échanges Modbus cycliques
FB_HS_SEND : Bit de basculement - Nouvelle commande provenant du maître
DeviceNet
FB_HS_CONFIRM : Bit de basculement - Acquittement du diagnostic
Reportez-vous au chapitre 5.4 pour consulter la description détaillée de chaque bit.
40
5. Initialisation et diagnostic de la passerelle
5.1.2. Mot d’état de la passerelle
B15 B14 B13 B12 B11 B10 B9 B8
B7 B6
EC = Code d’erreur
B5 B4 B3
B2
B1 B0
ED = Détails de l’erreur
ABC_PER : Echanges Modbus cycliques avec informations sur tous les
esclaves
ABC_DU : Echanges Modbus cycliques activés
ABC_HS_CONFIRM : Bit de basculement - Acquittement de la commande
FB_HS_SEND : Bit de basculement - Nouveau diagnostic de la passerelle
Reportez-vous au chapitre 5.5 pour consulter la description détaillée de chaque bit.
5.2. Diagnostic seul
Le maître DeviceNet gère uniquement le diagnostic du réseau Modbus à l’aide des 2 mêmes mots que pour la
gestion complète.
Les bits de gestion des échanges Modbus cycliques sont inactifs.
5.2.1. Mot de commande du maître DeviceNet
B15 B14 B13 B12 B11 B10 B9 B8
B7 B6
B5 B4 B3
B2
B1 B0
Réservé
FB_HS_CONFIRM : Bit de basculement - Acquittement du diagnostic
Reportez-vous au chapitre 5.4 pour consulter la description détaillée de chaque bit.
41
5. Initialisation et diagnostic de la passerelle
5.2.2. Mot d’état de la passerelle
B15 B14 B13 B12 B11 B10 B9 B8
B7 B6
EC = Code d’erreur
B5 B4 B3
B2
B1 B0
ED = Détails de l’erreur
ABC_PER : Echanges Modbus cycliques avec informations sur tous les
esclaves
ABC_DU : Echanges Modbus cycliques activés
Réservé
FB_HS_SEND : Bit de basculement - Nouveau diagnostic de la passerelle
Reportez-vous au chapitre 5.5 pour consulter la description détaillée de chaque bit.
Dans les modes « Gestion complète » et « Diagnostic seul », il est important que vous configuriez votre maître
DeviceNet pour qu’il ait accès aux deux premiers octets de la zone des données de sortie de la passerelle, ainsi
qu’aux deux premiers octets de la zone des données d’entrée de la passerelle
AVERTISSEMENT
CONFIGURATION ERRONEE DES ZONES DE DONNEES DE LA PASSERELLE LUFP•
Configurez votre maître DeviceNet pour qu’il ait accès aux deux premiers octets de la zone des données de
sortie de la passerelle, ainsi qu’aux deux premiers octets de la zone des données d’entrée de la passerelle.
Un défaut de configuration de l'accès à ces octets peut engendrer une incapacité à arrêter les
communications Modbus et empêcher l’enregistrement des conditions d’erreur pour une évaluation ultérieure.
Chacune de ces conséquences peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Reportez-vous au chapitre 4.2 Configuration de la passerelle sous RsNetWorx, pour plus d’informations.
5.3. Fonctionnement simplifié
Les deux registres de 16 bits situés aux adresses 0x0000-0x0001 (entrées) et 0x0200-0x0201 (sorties) ne sont
plus utilisés. Ces deux adresses peuvent donc être utilisées pour échanger des données avec l’esclave Modbus.
Aucun diagnostic n’est renvoyé à l’automate. Le mot de commande du maître DeviceNet et le mot d’état de la
passerelle n’existent pas durant des opérations simplifiées.
42
5. Initialisation et diagnostic de la passerelle
5.4. Description du mot de commande du maître DeviceNet
Le mot de sortie situé aux adresses 0x0200 (MSB) et 0x0201 (LSB) dans la mémoire de sortie de la passerelle
constitue le mot de commande du maître DeviceNet. Sa structure est décrite ci-dessous :
Bits
15
Description
FB_HS_CONFIRM : Bit d’acquittement d’un diagnostic de la passerelle
Le maître DeviceNet doit comparer la valeur du bit FB_HS_CONFIRM à celle du bit ABC_HS_SEND
(bit 15 du mot d’état de la passerelle). Si ces deux valeurs sont différentes, cela signifie que la
passerelle a transmis un nouveau diagnostic au maître DeviceNet.
Pour indiquer à la passerelle qu’il a pris connaissance d’un diagnostic, le maître DeviceNet doit
recopier la valeur du bit ABC_HS_SEND dans le bit FB_HS_CONFIRM. Cela autorise la passerelle à
émettre un nouveau diagnostic.
14
Récapitulatif :
• Si ( FB_HS_CONFIRM = ABC_HS_SEND ) Æ Le mot d’état de la passerelle contient un
diagnostic qui a déjà été acquitté par le maître DeviceNet. La passerelle pourra donc à nouveau
utiliser ce mot d’état pour y placer un autre diagnostic.
• Sinon Æ Un nouveau diagnostic est disponible dans le mot d’état de la passerelle. Le maître
DeviceNet peut lire ce diagnostic, mais doit également recopier la valeur de ABC_HS_SEND
dans FB_HS_CONFIRM afin d’autoriser la passerelle à générer de nouveaux diagnostics.
FB_HS_SEND : Bit de basculement - Nouvelle commande provenant du maître DeviceNet
(Réservé en mode « Diagnostic seul »)
13
Avant de modifier la valeur de FB_DU, le maître DeviceNet doit comparer les valeurs de
FB_HS_SEND et de ABC_HS_CONFIRM (bit 14 du mot d’état de la passerelle). Si ces deux valeurs
sont différentes, cela signifie que la passerelle n’a pas encore tenu compte de la commande
précédente du maître DeviceNet. Dans le cas contraire, le maître DeviceNet peut transmettre une
nouvelle commande. Il peut alors mettre à jour le bit FB_DU en fonction de la nature de sa
commande (arrêt ou activation des échanges Modbus), puis faire basculer la valeur du bit
FB_HS_SEND afin de signifier à la passerelle qu’il lui a transmis une nouvelle commande.
Récapitulatif :
• Si ( FB_HS_SEND ≠ ABC_HS_CONFIRM ) Æ Le mot de commande du maître DeviceNet
contient une commande n’ayant pas encore été acquittée par la passerelle. Le maître DeviceNet
ne peut donc pas utiliser ce mot pour y placer une nouvelle commande.
• Sinon Æ La commande précédente du maître DeviceNet a été acquittée par la passerelle, ce qui
l’autorise à émettre une nouvelle commande. Dans ce cas, il modifie la valeur du bit FB_DU,
puis fait basculer la valeur du bit FB_HS_SEND.
FB_DU : Mise en route des échanges Modbus
(Réservé en mode « Diagnostic seul »)
La mise à un de ce bit par le maître DeviceNet sert à autoriser les communications entre la
passerelle et les esclaves Modbus. Sa remise à zéro sert à les inhiber.
0-12
Lorsque le maître DeviceNet met ce bit à un, il est préférable que l’ensemble des données de sortie
qu’il aura placées dans la mémoire de sortie de la passerelle soient à jour (« FB_DU » signifie
« FieldBus - Data Updated »). Si elles ne le sont pas, ces données seront transmises telles quelles
aux esclaves Modbus.
Réservé.
43
5. Initialisation et diagnostic de la passerelle
En raison de l’inversion du LSB et du MSB de ce registre entre la passerelle et le maître DeviceNet, la structure
du mot de sortie correspondant (« O:1.1 » dans le cas de la configuration par défaut) est la suivante :
Bits
8-15
7
6
5
0-4
Description
Réservé.
FB_HS_CONFIRM : Bit d’acquittement d’un diagnostic de la passerelle
FB_HS_SEND : Nouvelle commande du maître DeviceNet (Réservé en mode « Diagnostic seul »)
FB_DU : Mise en route des échanges Modbus (Réservé en mode « Diagnostic seul »)
Réservé.
Exemple : Si le mot de sortie O:1.1 est égal à 0x00A0, le mot de commande du maître DeviceNet sera égal à 0xA000.
L’utilisation correcte de ce mot de commande par le maître DeviceNet, afin de transmettre une nouvelle
commande à la passerelle, passe par les étapes suivantes :
• Vérification de ( FB_HS_SEND = ABC_HS_CONFIRM ) ;
• Mise à jour de la commande, c’est-à-dire de la valeur du bit FB_DU ;
• Inversion de la valeur du bit FB_HS_SEND.
NOTE : Il est possible de simplifier cette utilisation de la manière suivante :
• Mise à un des bits FB_DU et FB_HS_SEND pour activer les communications Modbus.
• Remise à zéro des bits FB_DU et FB_HS_SEND pour arrêter les communications Modbus.
Même si l’écriture de données à 8 bits et de données à 16 bits dans le mot de commande du maître DeviceNet
est possible en théorie, l’écriture directe dans le mot de commande du maître DeviceNet de données au format
16 bits peut engendrer des erreurs. Ce type d'écriture de données à 16 bits peut perturber le fonctionnement du
transfert des diagnostics de la passerelle (modification non souhaitée de FB_HS_CONFIRM).
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
N’écrivez pas directement au format 16 bits dans le mot de commande du maître DeviceNet, car cela peut
perturber le fonctionnement du transfert des informations de diagnostic de la passerelle vers le maître. Selon
la configuration de l’utilisateur, cela peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
44
5. Initialisation et diagnostic de la passerelle
5.5. Description du mot d’état de la passerelle
Le mot d’entrée situé aux adresses 0x0000 (MSB) et 0x0001 (LSB) dans la mémoire d’entrée de la passerelle
constitue le mot d’état de la passerelle. Sa structure est décrite ci-dessous :
Bits
15
14
13
Description
ABC_HS_SEND : Nouveau diagnostic de la passerelle
(Voir description du bit 15 du mot de commande du maître DeviceNet, FB_HS_CONFIRM.)
ABC_HS_CONFIRM : Bit d’acquittement d’une commande du maître DeviceNet
(Réservé en mode « Diagnostic seul »)
(Voir description du bit 14 mot de commande du maître DeviceNet, FB_HS_SEND.)
ABC_DU : Echanges Modbus activés
La passerelle active ce bit pour signaler au maître DeviceNet que toutes les données Modbus qui
sont situées dans sa zone mémoire d’entrée ont été mises à jour au moins une fois depuis la
dernière activation de FB_DU (« ABC_DU » signifie « ABC – Data Updated »). Ces données Modbus
d’entrée comprennent toutes les données des réponses de tous les esclaves Modbus, commandes
périodiques et commandes apériodiques confondues.
Ce bit est désactivé par la passerelle lorsque le bit FB_DU est désactivé, c’est-à-dire lorsque le
maître DeviceNet demande l’arrêt des échanges Modbus.
12
NOTE : Une fois qu’il est actif, ce bit n’est pas désactivé lorsque surviennent des erreurs de
communication avec les esclaves Modbus. Pour signaler ce type d’erreurs, la passerelle utilise le
bit 12 de son mot d’état.
Périodicité des échanges Modbus
La passerelle active ce bit tant qu’elle communique de manière périodique avec l’ensemble des
esclaves Modbus. Elle le désactive dès qu’elle perd la communication avec l’un d’entre eux.
Les éléments « Reconnect time (10ms) », « Retries » et « Timeout time (10ms) » de chacune des
requêtes Modbus (voir chapitre 6.11.2.2) sont utilisés pour déterminer s’il y a perte, puis reprise, de
communication.
8-11
0-07
NOTE : Si plusieurs échanges périodiques sont configurés pour un même esclave Modbus, il suffit
qu’un seul d’entre eux reste actif pour que les communications périodiques avec cet esclave soient
déclarées actives.
EC : Code de l’erreur associée au réseau Modbus
Code de l’erreur détectée sur le réseau Modbus par la passerelle et émise au maître DeviceNet (voir
le tableau EC-ED).
ED : Donnée de l’erreur associée au réseau Modbus
Donnée associée au code d’erreur EC (voir le tableau EC-ED).
En raison de l’inversion du LSB et du MSB de ce registre entre la passerelle et le maître DeviceNet, la structure
du mot d’entrée correspondant (« I:1.1 » dans le cas de la configuration par défaut) est la suivante :
Bits
8-15
7
6
5
4
0-3
Description
ED : Donnée de l’erreur associée au réseau Modbus
ABC_HS_SEND : Nouveau diagnostic de la passerelle
ABC_HS_CONFIRM : Bit d’acquittement d’une commande du maître DeviceNet
(Réservé en mode « Diagnostic seul »)
ABC_DU : Echanges Modbus activés
Périodicité des échanges Modbus
EC : Code de l’erreur associée au réseau Modbus
Exemple : Si le mot d’état de la passerelle est égal à 0xF031, le mot d’entrée I:1.1 sera égal à 0x31F0.
45
5. Initialisation et diagnostic de la passerelle
L’utilisation correcte de ce mot d’état par le maître DeviceNet, afin de prendre connaissance d’un diagnostic
généré par la passerelle, passe par les étapes suivantes :
• Vérification de ( ABC_HS_SEND ≠ FB_HS_CONFIRM ) ;
• Lecture de la valeur de ABC_DU pour déterminer si toutes les données Modbus d’entrée sont à jour ;
• Lecture de la valeur du bit « Périodicité des échanges Modbus » pour déterminer si la périodicité des
communications Modbus est maintenue ;
• Lecture des valeurs de EC et de ED pour prendre connaissance d’une éventuelle erreur détectée par la
passerelle sur le réseau Modbus (voir tableau ci-dessous) ;
• Recopie de la valeur du bit ABC_HS_SEND dans le bit FB_HS_CONFIRM.
Cette dernière étape est très importante si le système est conçu pour lire les diagnostics de la passerelle et
effectuer certaines actions en fonction du résultat. La copie de la valeur du bit ABC_HS_SEND dans le bit
FB_HS_CONFIRM permet à la passerelle de transmettre un diagnostic futur, empêchant la perte d’informations
relatives aux erreurs ultérieures.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
L’utilisateur doit s’assurer que la programmation du maître DeviceNet conclut des opérations de lecture en
copiant la valeur du bit ABC_HS_SEND sur le bit FB_HS_CONFIRM. En cas d’omission de cette étape dans
les applications dans lesquelles les diagnostics de la passerelle sont lus et génèrent une réaction, les
informations de diagnostics futurs seront bloquées. Selon la configuration de l’utilisateur, cela peut provoquer
un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Les valeurs des champs EC et ED sont décrites dans le tableau suivant :
EC
2#0000
2#0001
2#0010
2#0011
2#0100
Description de l’erreur
Ré-émissions sur le
réseau Modbus
Absence d’un esclave
Modbus
Absence de plusieurs
esclaves Modbus
Données excessives dans
une réponse Modbus
Erreur Modbus inconnue
ED
Nombre de
ré-émissions
Adresse de l’esclave
Modbus absent
—
Adresse de l’esclave
Modbus incriminé
Adresse de l’esclave
Modbus incriminé
Remarques
Nombre total de ré-émissions effectuées sur
le sous-réseau, tous esclaves confondus.
—
—
Cette erreur se produit lorsque la passerelle
reçoit un trop grand nombre de données dans la
réponse émise par l’un de ses esclaves Modbus.
—
Le compteur de ré-émissions utilisé pour signaler cette erreur n’est pas remis à zéro lorsque la passerelle
génère ce code d’erreur. En cas de problèmes récurrents de communication sur le réseau Modbus, la passerelle
générera ce même diagnostic de manière répétitive, afin de renseigner le plus souvent possible le maître
DeviceNet du nombre total de ré-émissions effectuées. La remise à zéro de ce compteur est effectuée lorsque
sa valeur dépasse sa valeur maximale (compteur modulo 256 : 0xFF Æ 0x00).
En cas de déconnexion d’un ou de plusieurs équipements du sous-réseau Modbus, la passerelle LUFP9
commence par reporter des erreurs de ré-émissions, puis l’erreur « Absence d’un esclave Modbus » ou
« Absence de plusieurs esclaves Modbus ». Ensuite, lorsque la passerelle procède aux tentatives de re-connexion,
seule l’erreur de ré-émission est reportée. De ce fait, l’indication des erreurs « Absence d’un esclave Modbus » ou
« Absence de plusieurs esclaves Modbus » peut être perçue comme fugitive.
46
6. Configuration de la passerelle
Chacune des parties de ce chapitre décrit une étape distincte permettant de personnaliser la configuration de la
passerelle, selon les besoins de l’utilisateur. Chaque partie présente une opération élémentaire en l’isolant du
reste de la configuration et en décrivant les opérations à effectuer à l’aide de ABC-LUFP Config Tool
(principalement) et de RSNetWorx (si besoin est), ainsi que leurs implications sur le comportement général de la
passerelle.
Dans tous les cas, les deux premières étapes sont obligatoires, puisqu’elles permettent d’établir le dialogue
entre la passerelle et le logiciel du PC qui permet de la configurer, c’est-à-dire ABC-LUFP Config Tool.
La lecture du chapitre 4 Mise en œuvre logicielle de la passerelle, est fortement recommandée, car toutes les
opérations effectuées sous AbcConf ou sous RsNetWorx partent du principe que l’on utilise la configuration par
défaut de la passerelle LUFP9.
6.1. Raccordement de la passerelle au PC de configuration
Cette étape est obligatoire lors de la mise en œuvre du logiciel permettant de configurer la passerelle,
ABC-LUFP Config Tool.
Le raccordement de la passerelle à l'un des ports série (COM) d'un ordinateur nécessite un câble direct
PowerSuite et un convertisseur RS232/RS485. Ces deux éléments sont les mêmes que ceux qui permettent de
dialoguer avec des variateurs et des démarreurs depuis le logiciel PowerSuite, et sont tous deux disponibles
sur catalogue (réf. : VW3 A8 106).
Assurez-vous de bien utiliser le câble libellé « POWERSUITE » et le convertisseur « RS232 / RS485 PC ». Un
câble « ATV28 before 09 / 2001 » et un convertisseur « ATV 58 » sont également fournis avec ces éléments,
mais ils ne doivent pas être utilisés avec la passerelle LUFP9.
Passerelle LUFP9 (vue de dessous)
Configuration
PC
RS485
RJ45
VW3 A8 106
SubD 9
mâle
RS232
(COM)
RJ45
Câble POWERSUITE droit
SubD 9
femelle
Convertisseur
RS232 / RS485
Une fois la passerelle reliée à un PC à l’aide du câble PowerSuite et du convertisseur RS232/RS485, sa
configuration peut être modifiée grâce à l’outil de configuration « ABC-LUFP Config Tool ». Ce configurateur
permet également d’effectuer quelques diagnostics sur la passerelle.
47
6. Configuration de la passerelle
6.1.1. Brochage
— LUFP9 (Configuration) —
RJ45 mâle
RJ45 femelle
RS-485 D(B)
RS-485 D(A)
+10 V
GND
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
8
D(B)
D(A)
+10 V
0V
Câble direct POWERSUITE
——— Convertisseur RS485 / RS232 ———
RJ45 mâle
RJ45 femelle
SUB-D 9 points femelle
–—— PC (COM) ——–
SUB-D 9 points mâle
1
1
Tx
2
2
RS-232 Rx
Rx
3
3
RS-232 Tx
4
4
5
5
6
6
+10 V
7
7
0V
8
8
9
9
1
1
2
2
3
3
D(B)
4
4
D(B)
D(A)
5
5
D(A)
6
6
+10 V
7
7
0V
8
8
GND
GND
NOTE : Le croisement des signaux Rx et Tx entre la passerelle et le PC est représenté au niveau des
connecteurs SUB-D 9 points, car au-delà de cette jonction, les signaux RS-232 sont remplacés par les
polarisations D(A) et D(B) des signaux RS-485.
6.1.2. Protocole de la liaison RS-232
Il n’est pas nécessaire de configurer le port COM du PC, car ABC-LUFP Config Tool utilise un paramétrage
spécifique qui vient remplacer celui du port utilisé. Ce remplacement est temporaire et est annulé dès que
ABC-LUFP Config Tool est fermé.
48
6. Configuration de la passerelle
6.2. Installation de ABC-LUFP Config Tool
La configuration minimum requise pour pouvoir utiliser ABC-LUFP Config Tool est la suivante :
•
•
•
•
•
Processeur .....................................Pentium 133 MHz
Espace libre sur le disque dur ........10 Mo
RAM................................................08 Mo
Système d’exploitation ...................MS Windows 95 / 98 / ME / NT / 2000 / XP
Navigateur ......................................MS Internet Explorer 4.01 SP1
Le programme d’installation de ABC-LUFP Config Tool se trouve sur le CD de PowerSuite (réf. VW3 A8 104).
Pour l’installer, il suffit de lancer le programme « ABC-LUFP_Setup.exe » correspondant, puis de suivre les
instructions affichées à l’écran.
L’utilisation de ABC-LUFP Config Tool est décrite dans un manuel d’utilisation intitulé AnyBus Communicator User Manual, également disponible sur le CD de PowerSuite : « ABC_User_Manual.pdf ». Nous vous
recommandons vivement de vous reporter à ce manuel lors de l’utilisation de ABC-LUFP Config Tool, car le
présent guide décrit uniquement les différentes possibilités offertes par cet outil dans le cadre de la mise en
œuvre de la passerelle LUFP9.
6.3. Importation de la configuration de la passerelle
Avant de pouvoir apporter des modifications à la configuration de la passerelle, vous devez tout d’abord importer
sa configuration actuelle. Si cette configuration est déjà présente sur votre disque dur, il vous suffit d’ouvrir le
fichier correspondant à cette configuration.
Vérifiez que la passerelle dispose d’une configuration valide et qu’elle fonctionne correctement, c’est-à-dire que
la DEL s DEVICE STATUS clignote en vert.
Dans ABC-LUFP Config Tool, sélectionnez « Upload
configuration from ABC-LUFP » dans le menu « File » ou
cliquez sur le bouton
de la barre d’outils. Une fenêtre
nommée « Upload » s’ouvre alors et une barre de progression
indique l’état d’avancement de la récupération de la
configuration de la passerelle. Cette fenêtre disparaît une fois
la récupération achevée.
Cette étape est particulièrement importante si vous souhaitez prendre connaissance des détails de configuration
par défaut de la passerelle, suite à son déballage. Cette configuration pourra ensuite vous servir de modèle pour
les modifications que vous apporterez par la suite, vous évitant ainsi d’en créer une de toutes pièces et
diminuant les risques d’erreurs possibles.
NOTE :
ƒ
ƒ
Sauvegardez cette configuration sur le disque dur de votre PC afin de pouvoir en disposer à tout
moment. Cela vous permettra de reconfigurer la passerelle de manière « propre » dans l’éventualité où
sa configuration serait devenue invalide.
La configuration par défaut de la passerelle LUFP9 se trouve sur le CD LU9CD1 : « LUFP9.cfg ».
49
6. Configuration de la passerelle
6.4. Transfert d’une configuration vers la passerelle
Lorsque vous utilisez ABC-LUFP Config Tool, vous pouvez à tout moment transférer vers la passerelle la
configuration qui est en cours d’édition.
Sélectionnez « Download configuration to ABC-LUFP » dans le
menu « File » ou cliquez sur le bouton
de la barre d’outils.
Une phase de vérification du type de la passerelle est initialisée
par ABC-LUFP Config Tool.
NOTE : Pendant cette phase de vérification, le PC ne doit
effectuer aucune autre opération, car cela peut provoquer le
blocage apparent de ABC-LUFP Config Tool et le ralentissement
du fonctionnement général du PC, et ce pendant plusieurs
minutes ! Une fois cette vérification terminée, le PC retrouve sa
pleine vitesse et peut être utilisé normalement.
Une fois cette phase achevée, une fenêtre intitulée « Download »
s’ouvre et une barre de progression indique l’état d’avancement
du transfert de la configuration vers la passerelle.
NOTE : N’interrompez pas cette opération, car vous seriez obligé
de la reprendre depuis le début.
Vérifiez que le transfert s’est correctement déroulé : la DEL s DEVICE STATUS doit clignoter en vert.
Si cette DEL clignote alternativement en rouge et en vert, sauvegardez la configuration que vous étiez en train
d’éditer, ouvrez le fichier contenant la configuration par défaut des passerelles LUFP9, puis procédez à son
transfert vers la passerelle. Cette procédure permettra de la remettre dans un état initial connu. Vous pourrez
ensuite reprendre la configuration précédemment transférée, puis procéder aux corrections nécessaires.
6.5. Surveillance du contenu de la mémoire de la passerelle
L’une des principales commandes que vous aurez à utiliser lors de la mise en œuvre de la passerelle est la
commande qui permet de lire le contenu de la mémoire de la passerelle et de l’afficher dans une fenêtre prévue
à cet effet. Elle vous sera particulièrement utile lors de la mise au point de vos configurations et de vos
applications automate. Cependant, elle permet de visualiser uniquement les données des champs « Data » et
« Preset Data » configurés dans les éléments « Query » et « Response » d’un seul des esclaves Modbus, plus
le contenu des deux registres réservés de la passerelle, situés aux adresses mémoire 0x0000-0x0001 (mot
d’état de la passerelle) et 0x0200-0x0201 (mot de commande du maître DeviceNet).
Pour effectuer la surveillance du contenu de la mémoire de la passerelle, commencez par sélectionner le nœud
qui correspond à l’esclave Modbus dont vous souhaitez visualiser les données, puis exécutez la commande
« Monitor » dans le menu dont le nom correspond au nom du nœud préalablement sélectionné. Une fenêtre de
surveillance apparaît alors. L’exemple de fenêtre qui est reproduit en haut de la page suivante correspond à la
visualisation du contenu de la mémoire qui est échangé, dans le cas de la configuration par défaut de la
passerelle, avec le départ-moteur « TeSys U n°1 ».
50
6. Configuration de la passerelle
La partie supérieure de cette fenêtre permet de choisir une commande Modbus, d’en éditer le contenu, puis de
l’envoyer sur le réseau Modbus (menu « Command »). La réponse sera ensuite affichée dans cette même
partie. Reportez-vous au chapitre 2.10 Node monitor du manuel d’utilisation de ABC-LUFP Config Tool, intitulé
AnyBus Communicator – User Manual, pour obtenir de plus amples informations sur l’utilisation de cette
fenêtre. Ce manuel est disponible sur le CD LU9CD1 : « ABC_User_Manual.pdf ».
La partie inférieure de cette fenêtre permet de visualiser le contenu de la mémoire de la passerelle, mais
uniquement les octets qui sont utilisés dans les trames des requêtes et des réponses des commandes et des
transactions configurées pour le nœud sélectionné. Les valeurs des deux mots réservés de la passerelle
(adresses 0x0000-0x0001 et 0x0200-0x0201) sont également affichées, quel que soit le nœud sélectionné.
Dans la fenêtre reproduite ci-dessus, les données affichées correspondent aux valeurs situées aux emplacements
mémoire désignés par les champs « Data » des commandes et transactions configurées pour le nœud « TeSys U
n°1 », c’est-à-dire les commandes suivantes : « Read Holding Registers », « Preset Multiple Registers »,
« Transactions 1 » et « Transactions 2 ».
NOTE : Les données échangées avec l’esclave Modbus précédemment sélectionné sont affichées dans l’ordre
octet LSB / octet MSB (lecture de gauche à droite, dans le sens des adresses mémoire croissantes), à condition
que l’option « Byte Swap » de l’élément « Data » ou Preset Data » de la commande Modbus soit définie sur
« Swap 2 bytes » (voir chapitre 6.11.2.5 Configuration du contenu de la trame de la réponse
Dans le cas des deux mots réservés à la gestion du réseau aval Modbus, c’est le contraire : octet MSB / octet
LSB.
En revanche, dans le cas du nœud « TeSys U n°1 » uniquement, les données situées à partir des adresses
0x0013, 0x0018, 0x0212 et 0x0218 (voir Appendix B: Contenu de la mémoire DPRAM de la passerelle) suivent
le même ordre que le contenu des trames auxquelles elles correspondent (voir Appendix E: Commandes), du
premier au dernier octet (hors checksum), dans le sens des adresses croissantes dans la mémoire de la
passerelle. Enfin, les octets 0x001E, 0x001F, 0x021E et 0x021F correspondent aux compteurs de réception et
d’émission de ces trames (« Trigger bytes » des transactions 1 et 2). En revanche, tous ces octets sont
permutés deux à deux entre la passerelle et le maître DeviceNet.
Les boutons de la barre d’outils de cette fenêtre sont brièvement décrits ci-dessous :
Arrêt / Mise en route des communications avec le nœud sélectionné.
Sélection / Envoi de la commande Modbus présentée dans la partie supérieure de la fenêtre.
Arrêt / Reprise du rafraîchissement des données affichées dans la partie inférieure de la fenêtre.
51
6. Configuration de la passerelle
6.6. Suppression d’un esclave Modbus
Cette étape permet, par exemple, de libérer un emplacement sur le réseau aval Modbus, appelé
« Sub-Network » dans ABC-LUFP Config Tool, afin de remplacer un esclave Modbus par un autre.
En effet, la configuration par défaut de la passerelle lui permet de communiquer avec huit départs-moteurs
TeSys U, ce qui constitue le nombre maximum d’esclaves Modbus.
Si la passerelle est utilisée pour gérer les échanges sur un réseau Modbus comportant moins de huit départsmoteurs TeSys U, il est préférable de supprimer de la passerelle les départs-moteurs TeSys U redondants. Vous
devez effectuer cette opération à l’aide de ABC-LUFP Config Tool.
Si vous utilisez les services apériodiques de lecture/écriture, n’oubliez pas que ces services sont configurés à
l’aide de l’espace mémoire du premier départ-moteur TeSys U configuré. Par conséquent, la suppression du
premier départ-moteur TeSys U configuré peut également engendrer la suppression des services apériodiques
de lecture/écriture.
AVERTISSEMENT
PERTE DES COMMUNICATIONS APERIODIQUES
Ne supprimez pas le premier départ-moteur TeSys U configuré si vous utilisez les services apériodiques de
lecture/écriture. La suppression de ce premier élément provoquera également la suppression des services
apériodiques. Puisque ces services permettent de communiquer avec tous les périphériques Modbus
configurés, et pas uniquement avec le premier périphérique, vous risquez de perdre les communications avec
tous les périphériques et de provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Procédure de suppression d’un esclave Modbus :
1) Sélectionnez le nœud qui correspond à l’esclave Modbus que vous souhaitez supprimer de la configuration.
S’il ne reste plus que cet unique nœud dans la configuration, vous ne pourrez pas le supprimer, car le réseau
aval Modbus doit comporter au moins un esclave.
2) Cliquez, à l’aide du bouton droit de la souris, sur l’icône ou sur le nom de cet esclave Modbus. Un menu
apparaît sous le curseur de la souris.
ou
Dans le menu principal de ABC-LUFP Config Tool, ouvrez le menu dont le nom correspond au nom du nœud
précédemment sélectionné.
3) Dans ce menu, cliquez sur la commande « Delete ». La fenêtre de confirmation illustrée ci-dessous apparaît
alors, vous demandant de confirmer ou d’annuler la suppression du nœud sélectionné (« TeSys U n°2 » dans
le cas de l’exemple présenté ici).
4) Si vous confirmez la suppression du nœud, le
menu
disparaît,
ainsi
que
le
nœud
précédemment sélectionné. Dans le cas
contraire, le nœud sera toujours présent après la
disparition de la fenêtre.
Raccourci clavier : touche « Suppr ».
Ajustement de la mémoire de la passerelle (étape optionnelle) :
Les données préalablement échangées entre la passerelle et l’esclave Modbus qui vient d’être supprimé
libéreront des emplacements dans la mémoire de la passerelle. Si vous souhaitez optimiser les échanges entre
la mémoire de la passerelle et les entrées/sorties du scanner DeviceNet de l’automate maître, vous devrez
modifier la configuration de tous les autres esclaves Modbus afin d’ajuster le contenu de la mémoire de la
passerelle.
52
6. Configuration de la passerelle
Cependant, ces opérations sont inutiles dans le cas de la suppression d’un unique esclave. A l’inverse, elles
deviennent quasiment indispensables lorsque la majeure partie des esclaves Modbus sont supprimés, car ces
suppressions morcellent la mémoire de la passerelle.
Reportez-vous au chapitre 6.11 Ajout et paramétrage d’une commande Modbus, qui décrit l’ensemble des
modifications pouvant être apportées à la configuration de chacune des commandes Modbus..
6.7. Ajout d’un esclave Modbus
Cette fonctionnalité vous servira à ajouter un esclave Modbus dont le type est différent de celui des autres esclaves
Modbus présents dans la configuration. En revanche, si le type de l’esclave correspond à celui de l’un des esclaves
précédemment configurés, il est préférable de dupliquer cet esclave plutôt que d’en créer un nouveau.
Une fonctionnalité supplémentaire d’importation/exportation vous permet également de sauvegarder de manière
individuelle la configuration complète d’un esclave Modbus, dans le but d’y avoir accès, dans ABC-LUFP Config
Tool, depuis n’importe quelle configuration et à n’importe quel moment.
Ces deux fonctionnalités ne sont disponibles qu’à la condition qu’il y ait moins de 8 esclaves Modbus déclarés,
ce qui n’est pas le cas de la configuration par défaut, celle-ci comportant 8 départs-moteurs TeSys U.
Ajout d’un nouveau type d’esclave Modbus :
Procédez selon l’une des deux méthodes présentées ci-dessous :
a) Sélectionnez l’élément « Sub-Network », puis exécutez la commande « Add Node » du menu « SubNetwork ». Un nouveau nœud est ajouté à la suite de tous les autres nœuds configurés. Par défaut, son nom
est « New Node ».
b) Sélectionnez l’un des nœuds de l’élément « Sub-Network », puis exécutez la commande « Insert New
Node » du menu dont le nom correspond au nom du nœud sélectionné. Un nouveau nœud est ajouté juste
avant le nœud sélectionné. Par défaut, son nom est « New Node ».
L’ensemble des étapes permettant de configurer le nouveau nœud sont décrites dans le chapitre
6.10 Modification de la configuration d’un esclave Modbus.
Duplication d’un esclave Modbus précédemment configuré :
Sélectionnez le nœud qui correspond à l’esclave dont vous comptez recopier la configuration, puis exécutez la
commande « Copy » du menu dont le nom correspond au nom du nœud sélectionné. Raccourci clavier :
« Ctrl C ».
Procédez ensuite selon l’une des deux méthodes présentées ci-dessous :
a) Sélectionnez l’élément « Sub-Network », puis exécutez la commande « Paste » du menu « Sub-Network ».
Un nouveau nœud est ajouté à la suite de tous les autres nœuds configurés. Son nom et l’ensemble de sa
configuration sont identiques à ceux du nœud précédemment copié. Raccourci clavier : « Ctrl V ».
b)
Sélectionnez l’un des nœuds de l’élément « Sub-Network », puis exécutez la commande « Insert » du
menu dont le nom correspond au nœud sélectionné. Un nouveau nœud est ajouté juste avant celui qui est
sélectionné. Son nom et l’ensemble de sa configuration sont identiques à ceux du nœud précédemment copié.
53
6. Configuration de la passerelle
Le nouveau nœud et le nœud d’origine étant identiques en tous points, vous devrez procéder à la modification
(1) du nom du nœud, (2) de l’adresse de l’esclave Modbus correspondant et (3) de l’emplacement des données
échangées entre la mémoire de la passerelle et cet esclave Modbus. Reportez-vous au chapitre 6.10 Modbus et
au chapitre 6.11 Ajout et paramétrage d’une commande Modbus
AVERTISSEMENT
ADRESSES MODBUS OU PLAGES DE MEMOIRE DE LA PASSERELLE DUPLIQUEES
Si l’utilisateur choisit d’ajouter un esclave Modbus en recopiant la configuration d’un esclave Modbus existant,
il doit modifier l’adresse Modbus du périphérique ajouté et les emplacements mémoire que ce dernier utilise
afin d’échanger des données avec la passerelle. Les adresses Modbus ou les emplacements mémoire de la
passerelle dupliqués peuvent provoquer des erreurs de communications, l’écriture d’informations incorrectes
dans les registres d’un esclave ou l’écriture dans les registres d’un périphérique non souhaité. Chacune de
ces erreurs peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Importation/exportation de la configuration d’un esclave Modbus :
ABC-LUFP Config Tool offre la possibilité de sauvegarder et de charger de manière indépendante la
configuration d’un nœud sur le réseau aval « Sub-Network ». Cela vous permettra, par exemple, de constituer
une bibliothèque de modèles d’esclaves Modbus, afin de les utiliser dans n’importe quelle configuration.
Pour sauvegarder la configuration d’un esclave Modbus, sélectionnez le nœud auquel il correspond, puis
exécutez la commande « Save Node » du menu dont le nom correspond au nom du nœud sélectionné. Une
boîte de dialogue vous permettra alors d’en sauvegarder la configuration (exportation au format XML).
Pour insérer un nœud en prenant pour modèle le fichier XML contenant la configuration d’un esclave Modbus,
procédez selon l’une des deux méthodes présentées ci-dessous :
a) Sélectionnez l’élément « Sub-Network », puis exécutez la commande « Load Node » du menu « SubNetwork ». Une boîte de dialogue vous permet ensuite de choisir un fichier contenant la configuration
d’un esclave Modbus (import au format XML). Un nouveau nœud est ajouté à la suite de tous les autres
nœuds configurés. Son nom et l’ensemble de sa configuration sont identiques à ceux de l’esclave
Modbus, tel qu’il était configuré lors de sa sauvegarde.
b) Sélectionnez l’un des nœuds de l’élément « Sub-Network », puis exécutez la commande « Insert from
File » du menu dont le nom correspond au nom du nœud sélectionné. Un nouveau nœud est ajouté
juste avant le nœud sélectionné. Son nom et l’ensemble de sa configuration sont identiques à ceux de
l’esclave Modbus, tel qu’il était configuré lors de sa sauvegarde.
Vous devrez ensuite procéder à la modification (1) du nom du nœud, (2) de l’adresse de l’esclave Modbus
correspondant et (3) de l’emplacement des données échangées entre la mémoire de la passerelle et cet esclave
Modbus. Reportez-vous au chapitre 6.10Modification de la configuration d’un esclave Modbus, et au
chapitre 6.11 Ajout et paramétrage d’une commande Modbus
AVERTISSEMENT
ADRESSES MODBUS OU PLAGES DE MEMOIRE DE LA PASSERELLE DUPLIQUEES
Si l’utilisateur choisit d’ajouter un esclave Modbus en recopiant la configuration d’un esclave Modbus existant,
il doit modifier l’adresse Modbus du périphérique ajouté et les emplacements mémoire que ce dernier utilise
afin d’échanger des données avec la passerelle. Les adresses Modbus ou les emplacements mémoire de la
passerelle dupliqués peuvent provoquer des erreurs de communications, l’écriture d’informations incorrectes
dans les registres d’un esclave ou l’écriture dans les registres d’un périphérique non souhaité. Chacune de
ces erreurs peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
54
6. Configuration de la passerelle
6.8. Modification des données périodiques échangées avec un esclave Modbus
Cette opération consiste à remplacer, à ajouter ou à supprimer des données périodiques échangées avec l’un
des esclaves Modbus. Dans le cas de chacune de ces opérations, nous prendrons pour exemple la
configuration par défaut de la passerelle LUFP9, c’est-à-dire que toute modification précédemment effectuée
aura été annulée au début de chaque opération. De plus, les opérations à effectuer sont présentées dans le
cadre d’un exemple ciblé.
N’oubliez pas de sauvegarder les modifications effectuées ou de transférer l’ensemble de la configuration vers la
passerelle. Vous pourrez ainsi vérifier la validité de la configuration, car la passerelle vérifie automatiquement la
configuration lorsqu’elle est transmise.
6.8.1. Remplacement d’une donnée périodique d’entrée
Dans notre exemple, nous utiliserons le nœud correspondant au départ-moteur « TeSys U n°3 ». Nous cherchons à
remplacer la surveillance du registre « TeSys U Status Register » (adresse 455 = 0x01C7) par la surveillance du
registre « 1st Fault Register » (adresse 452 = 0x01C4).
L’opération à effectuer est très simple et consiste uniquement à modifier la valeur de l’élément « Starting
Address (Hi, Lo) » de la requête « Query » de la commande « Read Holding Registers » (commande Modbus de
lecture des valeurs de plusieurs registres).
Sélectionnez cet élément, puis modifiez sa valeur comme cela est indiqué ci-dessous. Vous pouvez saisir
l’adresse du paramètre au format décimal. Elle sera automatiquement convertie au format hexadécimal par
ABC-LUFP Config Tool.
Cette opération ne modifie en rien la configuration de la mémoire de la passerelle, car nous n’avons pas besoin
de modifier les valeurs des champs « Data length » et « Data location » de l’élément « Data » de la réponse
« Response » à la commande précédemment mentionnée. Aucune opération supplémentaire ne sera donc
nécessaire, ni dans ABC-LUFP Config Tool, ni sous RSNetWorx.
En revanche, le logiciel de l’automate maître DeviceNet devra tenir compte du changement de la nature de
l’entrée correspondante. Dans l’Appendix B:, Zone mémoire des données d’entrée, la description du mot situé à
l’adresse 0x0006 devient « Valeur du 1er registre de défaut du départ-moteur ». Ce mot correspond au mot
d’entrée I:1.4 de l’automate (voir chapitre 4.2.6 Configuration des entrées issues de la passerelle
55
6. Configuration de la passerelle
6.8.2. Remplacement d’une donnée périodique de sortie
Dans notre exemple, nous utiliserons le nœud correspondant au départ-moteur « TeSys U n°6 ». Nous cherchons à
remplacer la commande du registre « Command Register » (adresse 704 = 0x02C0) par la commande du
registre « 2nd Command Register » (adresse 705 = 16#02C1).
L’opération consiste à modifier la valeur de l’élément « Starting Address » dans la requête « Query » et dans la
réponse « Response » de la commande « Preset Multiple Registers » (commande Modbus d’écriture des
valeurs de plusieurs registres).
Sélectionnez l’élément « Starting Address » de la requête « Query », puis modifiez sa valeur comme cela est
indiqué ci-dessous. Vous pouvez saisir l’adresse du paramètre au format décimal. Elle sera automatiquement
convertie au format hexadécimal par ABC-LUFP Config Tool. Faites de même pour l’élément « Starting
Address » de la réponse « Response » car la passerelle vérifie la valeur de ce champ lors de la réception de
chaque réponse Modbus. Si la valeur ne correspond pas à celle de la requête, la passerelle ne tiendra pas
compte de la réponse.
Cette opération ne modifie en rien le contenu de la mémoire de la passerelle, car nous n’avons pas besoin de
modifier les valeurs des champs « Data length » et « Data location » de l’élément « Data » de la requête
« Query ». Aucune opération supplémentaire ne sera donc nécessaire, ni dans ABC-LUFP Config Tool, ni sous
RSNetWorx.
En revanche, le logiciel de l’automate maître DeviceNet devra tenir compte du changement de la nature de la
sortie correspondante. Un mot situé à l’adresse 0x020C devient « Valeur du 2ème registre de commande du
départ-moteur ». Ce mot correspond au mot de sortie O:1.7 de l’automate (voir chapitre 4.2.7 Configuration des
sorties destinées à la passerelle
56
6. Configuration de la passerelle
6.8.3. Augmentation du nombre des données périodiques d’entrée
Dans notre exemple, nous utiliserons le nœud correspondant au départ-moteur « TeSys U n°2 ». Nous cherchons à
compléter la surveillance de ce départ-moteur en partant du registre actuellement surveillé, c’est-à-dire
« TeSys U Status Register » (adresse 455 = 0x01C7), et en allant jusqu’au registre « Reserved : 2nd Warning
Register » (adresse 462 = 0x01CE). Le nombre de registres surveillés passe donc de 1 à 8.
Dans le cas présent, le nombre d’opérations à effectuer est relativement important. Elles sont décrites, dans
l’ordre, ci-après :
1) Modification du nombre de registres surveillés : Cette étape consiste à modifier la valeur de l’élément
« Number of points (Hi, Lo) » de la requête « Query » de la commande « Read Holding Registers »
(commande Modbus de lecture des valeurs de plusieurs registres). Sélectionnez cet élément, puis modifiez
sa valeur comme cela est indiqué ci-dessous. Toute valeur saisie au format décimal sera automatiquement
convertie au format hexadécimal par ABC-LUFP Config Tool.
2) Modification du nombre d’octets de données dans la réponse Modbus : Le nombre d’octets lus dans la
mémoire du départ-moteur « TeSys U n°2 » passe de 2 à 16, puisque le nombre de registres surveillés est
passé de 1 à 8. Sélectionnez l’élément « Byte count » de la réponse « Response » et modifiez sa valeur
comme cela est indiqué ci-dessous. Toute valeur saisie au format décimal sera automatiquement convertie
au format hexadécimal par ABC-LUFP Config Tool.
57
6. Configuration de la passerelle
3) Modification de l’emplacement des données Modbus reçues dans la mémoire de la passerelle : Le nombre
d’octets récupérés (voir étape précédente) étant passé de 2 à 16, les données Modbus reçues doivent être
placées à un endroit différent dans la mémoire de la passerelle, et la taille de la mémoire occupée doit elle
aussi être ajustée de manière appropriée.
Si vous n’êtes pas certain de l’occupation mémoire actuelle de la passerelle, sélectionnez l’élément
« Sub-Network » et exécutez la commande « Monitor » du menu « Sub-Network ». La fenêtre suivante
apparaît alors, vous permettant de consulter l’occupation de la mémoire de la passerelle.
Pour connaître les emplacements mémoire occupés par les données de la commande qui nous intéresse, il
suffit de décocher la case qui correspond à la commande « Read Holding Registers » du nœud « TeSys U
n°2 », comme cela est indiqué ci-dessus. Nous constatons que les données Modbus reçues en réponse à
cette commande occupent 2 octets situés à partir de l’adresse 0x0004.
NOTE : Les emplacements mémoire 0x0000 et 0x0001 sont réservés (voir chapitre5 Initialisation et
diagnostic de la passerelle). Vous ne pourrez donc pas y placer de données Modbus.
Les tailles indiquées au-dessus des zones graphiques de cette fenêtre (« In Area 32 bytes » et « Out Area
32 bytes ») correspondent aux tailles totales des entrées et des sorties que vous devez observer sous
RSNetWorx (voir point 6, page suivante) et configurer pour le scanner DeviceNet (voir point 7)).
Si nous souhaitons placer en mémoire les 16 octets de données Modbus qui seront reçues par la passerelle
pour cette commande, une fois les modifications effectuées, nous devons soit décaler de 14 octets toutes les
autres données reçues, ce qui peut être fastidieux, soit modifier l’emplacement mémoire du bloc des
données reçues. Dans le cadre de l’exemple décrit ici, nous utiliserons la seconde solution, bien que la
première solution soit préférable, dans le principe, car elle évite de laisser des « trous » dans la mémoire de
la passerelle, optimisant ainsi le transfert de l’ensemble des données vers l’automate maître DeviceNet. De
plus, le scanner 1747-SDN ne peut échanger que 32 mots d’entrée avec l’automate maître. Le fait de laisser
de tels « trous » dans la mémoire de la passerelle est donc déconseillé dans le cas de configurations
volumineuses.
Nous placerons les 16 octets de données à partir de l’adresse 0x0020 (32 au format décimal), c’est-à-dire
directement à la suite des données d’entrée de la configuration par défaut de la passerelle.
58
6. Configuration de la passerelle
Fermez la fenêtre « Sub-network Monitor », puis, de retour dans la fenêtre principale de ABC-LUFP Config
Tool, sélectionnez l’un après l’autre les champs « Data length » et « Data location » de l’élément « Data » de
la réponse « Response » et modifiez leurs valeurs comme cela est indiqué en haut de la page suivante.
Toute valeur saisie au format décimal sera automatiquement convertie au format hexadécimal par
ABC-LUFP Config Tool.
Afin de vérifier que ces modifications ont été prises en compte dans la configuration, exécutez à nouveau la
commande « Monitor » du menu « Sub-Network » :
4) Transfert de cette configuration vers la passerelle : Voir chapitre 6.4 Transfert d’une configuration vers la
passerelle. Vérifiez que la configuration est valide (clignotement vert de la DEL s DEVICE STATUS).
5) Sauvegarde de cette configuration sur le disque dur de votre PC.
6) Vérification du paramétrage de la passerelle : Sous RSNetWorx, procédez à la vérification des valeurs des
paramètres de la passerelle (voir chapitre 4.2.4 Modification des paramètres de la passerelle Seule la valeur du
paramètre n°7, « Input1 length », doit avoir été modifiée, passant de « 32 bytes » à « 48 bytes ».
NOTE : Vous devez vérifier que les valeurs des paramètres affichés soient identiques aux tailles des
échanges indiquées dans la fenêtre « Sub-network Monitor ». Dans le cas de l’exemple présent, « In Area
48 bytes » implique que la zone « Input1 » commence à l’offset 0 (adresse physique 0x0000) et que sa
longueur soit égale à 48 octets. De même, « Out Area 32 bytes » implique que la zone « Output1 »
commence à l’offset 0 (adresse physique 0x0200) et que sa longueur soit égale à 32 octets.
59
6. Configuration de la passerelle
7)
Modification du nombre de données reçues par le scanner DeviceNet : Toujours sous RsNetWorx, modifiez
la valeur du nombre de données périodiques reçues par le scanner DeviceNet (voir chapitre 4.2.5 Configuration
du Scanner DeviceNet) Modifiez la valeur du champ « Rx Size: » de 32 à 48, dans la section « Polled: ».
8)
Configuration des entrées de l’automate maître DeviceNet : Sous RSNetWorx, établissez une nouvelle
correspondance entre les données issues de la passerelle et les entrées automate, selon les besoins de votre
application (voir chapitre 4.2.6 Configuration des entrées issues de la passerelle Les différentes possibilités
offertes par RSNetWorx afin d’établir une correspondance entre les données issues d’un abonné DeviceNet et
les entrées automate ne seront pas décrites ici. Reportez-vous à la documentation de ce logiciel afin d’en savoir
plus sur cette étape de la mise en œuvre d’un automate maître DeviceNet.
Dans le cadre du présent guide, nous utiliserons la commande « AutoMap » afin d’établir une correspondance
« brute » avec toutes les données issues de la passerelle LUFP9. Nous obtenons alors la correspondance
représentée ci-dessous, dérivée de celle qui est utilisée dans le cas de la configuration par défaut de la passerelle.
Les modifications par rapport à la configuration par défaut sont représentées par un fond grisé, tout comme les
« emplacements mémoire libres ».
Service
Entrée
Automate
Gestion du réseau aval Modbus
I:1.1
Communications périodiques
—
Surveillance des
départs-moteurs TeSys U
Communications apériodiques
—
Lecture de la valeur d’un paramètre
de départ-moteur (REPONSE)
Communications apériodiques
—
Ecriture de la valeur d’un
paramètre de départ-moteur
(REPONSE)
Communications apériodiques
(« Trigger bytes » des réponses)
I:1.2
I:1.3
I:1.4
I:1.5
I:1.6
I:1.7
I:1.8
I:1,9
I:1.10
I:1.11
I:1.12
I:1.13
I:1.14
I:1.15
I:1.16
I:1.17
I:1.18
I:1.19
Communications périodiques
—
Surveillance du
départ-moteur TeSys U d
I:1.20
I:1.21
I:1.22
I:1.23
I:1.24
Description
Bit 0 ......................Bit 7
Bit 8 ................... Bit 15
Mot d’état de la passerelle LUFP9
(LSB Æ 0x••xx)
(MSB Æ 0xxx••)
Valeur du registre d’état du départ-moteur c
Emplacement mémoire libre
Valeur du registre d’état du départ-moteur e
Valeur du registre d’état du départ-moteur f
Valeur du registre d’état du départ-moteur g
Valeur du registre d’état du départ-moteur h
Valeur du registre d’état du départ-moteur i
Valeur du registre d’état du départ-moteur j
Emplacement mémoire libre
N° esclave (0x01-0x08)
Numéro de la fonction
Nombre d’octets lus (0x02)
(0x03)
Valeur du paramètre lu
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
N° fonction (0x06)
N° esclave (0x01-0x08)
Adresse du paramètre écrit
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Valeur du paramètre écrit
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Compteur de réponse de Compteur de réponse de
la lecture d’un paramètre
l’écriture d’un paramètre
Valeur du registre « TeSys U Status Register »
Valeur du registre « Complementary Status Register »
Valeur du registre « K7 Status Register »
Valeur du registre « K7 Status Register 2 (free
format) »
Valeur du registre « K7 Status Register 3 (free
format) »
Valeur du registre « Warning Number »
Valeur du registre « Warning Register »
Valeur du registre « Reserved : 2nd Warning Register »
60
6. Configuration de la passerelle
9) Transfert de la configuration du scanner DeviceNet : Suite aux modifications apportées à la liste des
échanges du scanner DeviceNet, il est nécessaire de la transférer vers le scanner DeviceNet. Reportez-vous au
chapitre 4.2.8 4.2.8 Transfert de la configuration du scanner DeviceNet
6.8.4. Augmentation du nombre des données périodiques de sortie
Dans notre exemple, nous utiliserons le nœud correspondant au départ-moteur « TeSys U n°4 ». Par défaut,
nous contrôlons la commande de registre Command Register 704. Pour contrôler également la commande de
registre Command Register 705, nous allons effectuer les opérations suivantes.
1) Modification du nombre de registres commandés : Cette étape consiste à modifier la valeur de l’élément
« No. of Registers » dans la requête « Query » et dans la réponse « Response » de la commande « Preset
Multiple Registers » (commande Modbus d’écriture des valeurs de plusieurs registres). Commencez par
sélectionner l’élément « N° of Registers » de la requête « Query », puis modifiez sa valeur comme indiqué cidessous. Toute valeur saisie au format décimal sera automatiquement convertie au format hexadécimal par
ABC-LUFP Config Tool. Faites de même pour l’élément « N° of Registers » de la réponse « Response », car
la passerelle vérifie la valeur de ce champ lors de la réception de chaque réponse Modbus. Si la valeur ne
correspond pas à celle de la requête, la passerelle ne tiendra pas compte de la réponse.
61
6. Configuration de la passerelle
2) Modification du nombre d’octets de données dans la requête Modbus : Le nombre d’octets écrits dans la
mémoire du départ-moteur « TeSys U n°4 » passe de 2 à 4, puisque le nombre de registres commandés est
passé de 1 à 2. Sélectionnez l’élément « Byte count » de la requête « Query » et modifiez sa valeur comme
cela est indiqué ci-dessous. Toute valeur saisie au format décimal sera automatiquement convertie au format
hexadécimal par ABC-LUFP Config Tool.
3) Modification de l’emplacement des données Modbus transmises dans la mémoire de la passerelle : Le
nombre d’octets transmis (voir étape précédente) étant passé de 2 à 4, les données Modbus à transmettre
au départ-moteur « TeSys U n°4 » doivent être placées à un endroit différent dans la mémoire de la
passerelle et la taille de la mémoire occupée doit elle aussi être ajustée de manière appropriée.
Si vous n’êtes pas certain de l’occupation mémoire actuelle de la passerelle, sélectionnez l’élément « SubNetwork » et exécutez la commande « Monitor » du menu « Sub-Network ». La fenêtre ci-dessous apparaît
alors, vous permettant de consulter l’occupation de la mémoire de la passerelle.
62
6. Configuration de la passerelle
Pour connaître les emplacements mémoire occupés par les données de la commande qui nous intéresse, il
suffit de décocher la case qui correspond à la commande « Preset Multiple Registers » du nœud « TeSys U
n°4 », comme cela est indiqué ci-dessus. Nous constatons que les données Modbus transmises avec la
requête correspondant à cette commande occupent 2 octets situés à partir de l’adresse 0x0208.
NOTE : Les emplacements mémoire 0x0200 et 0x0201 sont réservés (voir chapitre 5 Initialisation la
passerelle). Vous ne pourrez donc pas y placer de données Modbus.
Les tailles indiquées au-dessus des zones graphiques de cette fenêtre (« In Area 32 bytes » et « Out Area
32 bytes ») correspondent aux tailles totales des entrées et des sorties que vous devez observer sous
RSNetWorx (voir point 6, page suivante) et configurer pour le scanner DeviceNet (voir point 7)).
Si nous souhaitons placer en mémoire les 4 octets de données Modbus qui seront transmises par la passerelle
pour cette commande, une fois les modifications effectuées, nous devons soit décaler de 2 octets toutes les
autres données transmises, ce qui peut être fastidieux, soit modifier l’emplacement mémoire du bloc des
données transmises. Dans le cadre de l’exemple décrit ici, nous utiliserons la seconde solution, bien que la
première solution soit préférable, dans le principe, car elle évite de laisser des « trous » dans la mémoire de la
passerelle, optimisant ainsi le transfert de l’ensemble des données vers l’automate maître DeviceNet. De plus, le
scanner 1747-SDN ne peut échanger que 32 mots de sortie avec l’automate maître. Le fait de laisser de tels
« trous » dans la mémoire de la passerelle est donc déconseillé dans le cas de configurations volumineuses.
Lorsque vous sélectionnez une valeur pour le champ « Data Location », les données doivent être situées à
des adresses paires afin d’aligner les données Modbus (au format 16 bits) sur les sorties O:1.x du scanner
DeviceNet. Si les données ne sont pas situées à des adresses paires, les valeurs prévues pour les registres
Modbus peuvent être réparties sur deux mots de l’automate DeviceNet. Ceci complique considérablement la
programmation de l’application, car celle-ci peut être contrainte d’analyser un mot de l’automate pour l’octet
Modbus LSB et un autre pour l’octet Modbus MSB. Si ce problème n’est pas géré correctement, il est
possible de lire et d’écrire des valeurs de données erronées sur les esclaves Modbus.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
L’utilisateur doit utiliser des valeurs paires pour le champ « Data Location ». La sélection de valeurs de
données impaires complique la programmation de l’application et augmente les risques d’écriture ou de
lecture de valeurs Modbus incorrectes sur ou depuis les périphériques esclaves. Selon la configuration de
l’utilisateur, cela peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Pour revenir à notre exemple précédent, la valeur à affecter au registre CMD de l’ATS48 doit être placée
dans la zone des données de sortie de la passerelle. Nous utiliserons le premier emplacement libre
commençant à une adresse paire, c’est-à-dire celui qui est situé à l’adresse 16#0220, dans le cas de la
configuration par défaut de la passerelle.
Nous placerons les 4 octets de données à partir de l’adresse 0x0220 (544 au format décimal).
63
6. Configuration de la passerelle
Fermez la fenêtre « Sub-network Monitor », puis, de retour dans la fenêtre principale de ABC-LUFP Config
Tool, sélectionnez l’un après l’autre les champs « Data length » et « Data location » de l’élément « Data » de
la requête « Query » et modifiez leurs valeurs comme indiqué en haut de la page suivante. Toute valeur
saisie au format décimal sera automatiquement convertie au format hexadécimal par ABC-LUFP Config Tool.
Afin de vérifier que ces modifications ont été prises en compte dans la configuration, exécutez à nouveau la
commande « Monitor » du menu « Sub-Network » :
4) Transfert de cette configuration vers la passerelle Reportez-vous au chapitre 6.4 Transfert d’une
configuration vers la passerelle. Vérifiez que la configuration est valide (clignotement vert de la DEL s DEVICE
STATUS).
5) Sauvegarde de cette configuration sur le disque dur de votre PC.
6) Vérification du paramétrage de la passerelle : Sous RSNetWorx, procédez à la vérification des valeurs des
paramètres de la passerelle (voir chapitre 4.2.4 Modification des paramètres de la passerelle). Seule la valeur
du paramètre n°19, « Output1 length », doit avoir été modifiée, passant de « 32 bytes » à « 36 bytes ».
NOTE : Vous devez vérifier que les valeurs des paramètres affichés sont identiques aux tailles des échanges
indiquées dans la fenêtre « Sub-network Monitor ». Dans le cas de l’exemple présent, « In Area 32 bytes »
implique que la zone « Input1 » commence à l’offset 0 (adresse physique 0x0000) et que sa longueur soit égale
à 32 octets. De même, « Out Area 36 bytes » implique que la zone « Output1 » commence à l’offset 0 (adresse
physique 0x0200) et que sa longueur soit égale à 36 octets.
64
6. Configuration de la passerelle
7) Modification du nombre de données émises par le scanner DeviceNet : Toujours sous RSNetWorx, modifiez
la valeur du nombre de données périodiques transmises par le scanner DeviceNet (voir chapitre 4.2.5
Configuration du Scanner DeviceNet). Modifiez la valeur du champ « Tx Size: » de 32 à 36, dans la section
« Polled: ».
8) Configuration des sorties de l’automate maître DeviceNet : Sous RSNetWorx, établissez une nouvelle
correspondance entre les données transmises à la passerelle et les sorties automate, selon les besoins de votre
application (voir chapitre Configuration des sorties destinées à la passerelle). Les différentes possibilités
offertes par RSNetWorx afin d’établir une correspondance entre les données transmises à un abonné
DeviceNet et les sorties automate ne seront pas décrites ici. Reportez-vous à la documentation de ce logiciel
afin d’en savoir plus sur cette étape lors de la mise en œuvre d’un automate maître DeviceNet.
Dans ce guide, nous utiliserons la commande « AutoMap » afin d’établir une correspondance « brute » avec
toutes les données transmises à la passerelle LUFP9. Nous obtenons alors la correspondance représentée cidessous, dérivée de celle qui est utilisée dans le cas de la configuration par défaut de la passerelle. Les
modifications par rapport à la configuration par défaut sont représentées par un fond grisé, tout comme les
« emplacements mémoire libres ».
Service
Sortie
Automate
Gestion du réseau aval Modbus
O:1.1
Communications
périodiques
—
Commande des
départs-moteurs TeSys U
Communications apériodiques
—
Lecture de la valeur d’un
paramètre de départ-moteur
O:1.2
O:1.3
O:1.4
O:1.5
O:1.6
O:1.7
O:1.8
O:1.9
O:1.10
O:1.11
(REQUETE)
O:1.12
Communications apériodiques
—
Ecriture de la valeur d’un
paramètre de départ-moteur
(REQUETE)
Communications apériodiques
(« Trigger bytes » des requêtes)
O:1.13
Communications périodiques
Surveillance du départ-moteur
TeSys U f
O:1.17
O:1.14
O:1.15
O:1.16
O:1.18
Description
Bit 0 ......................Bit 7
Bit 8 ................... Bit 15
Mot de commande du maître DeviceNet
(LSB Æ 0x••xx)
(MSB Æ 0xxx••)
Valeur du registre de commande du départ-moteur c
Valeur du registre de commande du départ-moteur d
Valeur du registre de commande du départ-moteur e
Emplacement mémoire libre
Valeur du registre de commande du départ-moteur g
Valeur du registre de commande du départ-moteur h
Valeur du registre de commande du départ-moteur i
Valeur du registre de commande du départ-moteur j
N° esclave (0x01-0x08)
N° fonction (0x03)
Adresse du paramètre à lire
(LSB Æ 0x••xx)
(MSB Æ 0xxx••)
Nombre de paramètres à lire
(LSB Æ 0x••01)
(MSB Æ 0x00••)
N° fonction (0x06)
N° esclave (0x01-0x08)
Adresse du paramètre à écrire
(LSB Æ 0x••xx)
(MSB Æ 0xxx••)
Valeur du paramètre à écrire
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Compteur de requête de
Compteur de requête de
la lecture d’un paramètre
l’écriture d’un paramètre
Valeur du registre de commande : « Command
Register »
Valeur du deuxième registre de commande : « 2nd
Command Register »
9) Transfert de la configuration du scanner DeviceNet : Suite aux modifications apportées à la liste des
échanges du scanner DeviceNet, il est nécessaire de la transférer vers le scanner DeviceNet. Reportez-vous
au chapitre Transfert de la configuration du scanner DeviceNet.
65
6. Configuration de la passerelle
6.9. Suppression des données apériodiques de paramétrage
Si votre application automate n’a pas besoin du service apériodique de paramétrage des esclaves Modbus, vous
pouvez supprimer les commandes qui lui sont associées. Si vous comptez également ajouter des données
Modbus, et donc utiliser de nouveaux emplacements dans la mémoire de la passerelle, il est préférable que vous
supprimiez les commandes de paramétrage dès le début afin d’en réutiliser les emplacements mémoire.
En revanche, si la seule opération de configuration que vous souhaitez effectuer sur la passerelle LUFP9 consiste
à ne pas utiliser le service apériodique de paramétrage, vous pouvez vous contenter de ne pas utiliser ce
service sous RSNetWorx. Passez directement à l’étape 8.
Si vous décidez de supprimer les commandes apériodiques, vous devez effectuer les opérations suivantes :
1) Affichage des commandes de paramétrage : Sélectionnez le tout premier nœud du réseau aval Modbus,
« TeSys U n°1 », et développez l’arborescence de ses commandes et de ses transactions. L’affichage obtenu
est reproduit ci-dessous :
2) Suppression de la commande de lecture d’un paramètre : Sélectionnez la commande personnalisée
« Transactions 1 » et supprimez-la à l’aide de la touche « Suppr » (ou la commande « Delete » du menu
dont le nom correspond au nom du nœud sélectionné). Une demande de confirmation apparaît alors, vous
proposant de procéder ou non à la suppression de la commande « Transactions 1 ». Dans le cas présent,
validez la suppression à l’aide du bouton « Yes ».
3) Suppression de la commande d’écriture d’un paramètre : De retour dans la fenêtre principale de ABC-LUFP
Config Tool, la commande « Transactions 1 » a été supprimée. La seconde commande personnalisée,
« Transactions 2 », est automatiquement renommée en « Transactions 1 », mais conserve l’ensemble de son
paramétrage. Supprimez-la à son tour, de la même manière que pour la commande précédente. Cette
opération n’a aucune conséquence sur les autres nœuds.
66
6. Configuration de la passerelle
4) Vérification de la nouvelle occupation mémoire : Si vous souhaitez vérifier la nouvelle occupation mémoire de
la passerelle, sélectionnez l’élément « Sub-Network » et exécutez la commande « Monitor » du menu « SubNetwork ». La fenêtre suivante apparaît alors, vous permettant de consulter la nouvelle occupation de la
mémoire de la passerelle par les données Modbus. La partie encadrée en rouge représente l’occupation de la
mémoire avant la suppression des deux commandes de paramétrage. Elle a été incrustée dans l’illustration
présentée ci-dessous pour vous permettre de constater les effets des suppressions effectuées.
Vous constaterez que la section « TeSys U n°1 » ne comporte plus que les deux commandes Modbus
communes aux huit départs-moteurs TeSys U et que les emplacements mémoire qui correspondaient au deux
commandes personnalisées sont désormais libres.
NOTE : L’emplacement mémoire libre situé à l’adresse 0x0012 de la mémoire de la passerelle ne fait désormais
plus partie des entrées de la passerelle, car il n’y a plus aucune donnée d’entrée utilisée au-delà de cette
adresse.
5) Transfert de cette configuration vers la passerelle : Reportez-vous au chapitre .Transfert d’une configuration
vers la passerellea configuration est valide (clignotement vert de la DEL s DEVICE STATUS).
6) Sauvegarde de cette configuration sur le disque dur de votre PC.
7) Vérification du paramétrage de la passerelle : Sous RSNetWorx, procédez à la vérification des valeurs des
paramètres de la passerelle (voir chapitre) 4.2.4.Modification des paramètres de la passerelle La valeur du
paramètre n°7, « Input1 length », doit avoir été modifiée, passant de « 32 bytes » à « 18 bytes ». La valeur du
paramètre n°19, « Output1 length », passe de « 32 bytes » à « 18 bytes ».
8) Modification du nombre de données reçues et du nombre de données émises par le scanner DeviceNet :
Toujours sous RSNetWorx, modifiez le nombre de données périodiques reçues et le nombre de données
périodiques transmises par le scanner DeviceNet (voir chapitre) 4.2.5.Configuration du Scanner DeviceNet
Dans la section « Polled: », modifiez la valeur du champ « Rx Size: » de 32 à 18 et la valeur du champ
« Tx Size: » de 32 à 18.
9) Configuration des entrées et des sorties de l’automate maître DeviceNet : Sous RSNetWorx, établissez une
nouvelle correspondance entre les données issues de la passerelle et les entrées automate (voir chapitre 4.2.6.
Configuration des entrées issues de la passerelle Effectuez la même opération pour la correspondance entre
les données transmises à la passerelle et les sorties automate (voir chapitre 4.2.7 Configuration des sorties
destinées à la passerelle
Nous obtenons alors les deux correspondances représentées sur la page suivante, dérivées de celles qui
sont utilisées dans le cas de la configuration par défaut de la passerelle.
67
6. Configuration de la passerelle
Service
Entrée
Automate
Gestion du réseau aval Modbus
I:1.1
Communications périodiques
—
Surveillance des
départs-moteurs TeSys U
I:1.2
I:1.3
I:1.4
I:1.5
I:1.6
I:1.7
I:1.8
I:1.9
Description
Bit 0 ......................Bit 7
Bit 8 ................... Bit 15
Mot d’état de la passerelle LUFP9
(LSB Æ 0x••xx)
(MSB Æ 0xxx••)
Valeur du registre d’état du départ-moteur c
Valeur du registre d’état du départ-moteur d
Valeur du registre d’état du départ-moteur e
Valeur du registre d’état du départ-moteur f
Valeur du registre d’état du départ-moteur g
Valeur du registre d’état du départ-moteur h
Valeur du registre d’état du départ-moteur i
Valeur du registre d’état du départ-moteur j
Service
Sortie
Automate
Description
Bit 0 ......................Bit 7
Bit 8 ................... Bit 15
Gestion du réseau aval Modbus
O:1.1
Communications
périodiques
—
Commande des
départs-moteurs TeSys U
O:1.2
O:1.3
O:1.4
O:1.5
O:1.6
O:1.7
O:1.8
O:1.9
Mot de commande du maître DeviceNet
(MSB Æ 0xxx••)
(LSB Æ 0x••xx)
Valeur du registre de commande du départ-moteur c
Valeur du registre de commande du départ-moteur d
Valeur du registre de commande du départ-moteur e
Valeur du registre de commande du départ-moteur f
Valeur du registre de commande du départ-moteur g
Valeur du registre de commande du départ-moteur h
Valeur du registre de commande du départ-moteur i
Valeur du registre de commande du départ-moteur j
10) Transfert de la configuration du scanner DeviceNet : Suite aux modifications apportées à la liste des
échanges du scanner DeviceNet, il est nécessaire de la transférer vers le scanner DeviceNet. Reportez-vous au
chapitre 4.2.8 Transfert de la configuration du scanner DeviceNet.
6.10. Modification de la configuration d’un esclave Modbus
La configuration d’un esclave Modbus lui-même reste très simple, car elle concerne uniquement le nom et
l’adresse Modbus du nœud auquel il correspond. En revanche, la configuration des commandes Modbus est
beaucoup plus compliquée et fait l’objet d’un chapitre à part entière (voir chapitre 6.11 Ajout et paramétrage d’une
commande Modbus).
La modification de la configuration d’un esclave Modbus est nécessaire lorsque vous ajoutez un nouvel
équipement Modbus (voir chapitre 6.7, Ajout d’un esclave Modbus.
La modification du nom du nœud correspondant à un esclave Modbus permet de le distinguer des autres nœuds
lorsque la configuration de ses commandes Modbus a été modifiée.
68
6. Configuration de la passerelle
6.10.1. Modification du nom d’un esclave Modbus
Pour effectuer cette opération, il suffit de sélectionner le nœud qui correspond à l’esclave Modbus concerné
(section « Devices: »), de cliquer sur le nom actuel (valeur du champ « (Name) », dans la section
« Configuration: »), puis de le modifier. Après validation du nouveau nom (touche « Entrée » ou clic en dehors du
champ de saisie du nom), celui-ci sera pris en compte par ABC-LUFP Config Tool et le nom du nœud sera
automatiquement mis à jour dans la section « Devices: ». Un exemple est donné en haut de la page suivante. Les
trois cadres rouges représentés sur cet exemple indiquent la séquence des modifications effectuées.
6.10.2. Modification de l’adresse d’un esclave Modbus
Pour effectuer cette opération, il suffit de sélectionner le nœud correspondant à l’esclave Modbus concerné (section
« Devices: »), de cliquer sur la valeur de l’adresse actuelle (valeur du champ « Slave address », dans la section
« Configuration: »), puis de la modifier.
Rappel : L’adresse d’un esclave Modbus doit être comprise entre 1 et 247. Le système ne vous permettra pas
d’ajouter une valeur supérieure à 247.
AVERTISSEMENT
UTILISATION D’ADRESSES MODBUS RESERVEES
N’utilisez pas les adresses Modbus 65, 126 ou 127 si les esclaves Modbus d’une passerelle comportent un
système de variation de vitesse Schneider Electric, tel qu’un démarreur Altistart ou un variateur Altivar. Les
périphériques Altistart et Altivar réservent ces adresses pour d’autres communications et l’utilisation de ces
adresses dans un tel système peut avoir des conséquences imprévues.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
69
6. Configuration de la passerelle
Après validation de la nouvelle adresse (touche « Entrée » ou clic en dehors du champ de saisie de l’adresse de
l’esclave Modbus), celle-ci sera prise en compte par ABC-LUFP Config Tool et les valeurs des éléments « Slave
Address » des requêtes et des réponses des commandes Modbus du nœud sélectionné seront automatiquement
mises à jour. Un exemple avec la mise à jour d’un seul élément « Slave Address » est représenté ci-dessous :
6.11. Ajout et paramétrage d’une commande Modbus
6.11.1. Cas des départs-moteurs TeSys U
Dans le cas des départs-moteurs TeSys U, l’ajout d’une commande Modbus permet de commander ou de surveiller
des registres supplémentaires, sans modifier la configuration par défaut. Ainsi, le fonctionnement des services
périodiques et des services apériodiques de communication reste le même qu’avec la configuration par défaut,
contrairement aux opérations décrites dans le chapitre 6.8 Modification des données périodiques échangées avec
un esclave Modbus.
Plutôt que d’ajouter une commande et de la configurer entièrement, il est préférable de copier l’une des deux
commandes par défaut « Read Holding Registers » ou « Preset Multiple Registers » à partir d’un nœud existant
et de la coller dans la liste des commandes Modbus du nœud approprié.
Pour copier une commande Modbus déjà configurée à partir d’un nœud existant, sélectionnez-la, puis exécutez la
commande « Copy » du menu dont le nom correspond à celui du nœud sélectionné. Raccourci clavier :
« Ctrl C ». Continuez ensuite selon l’une des deux méthodes présentées ci-dessous :
a) Sélectionnez le nœud correspondant à l’esclave Modbus pour lequel vous souhaitez ajouter cette commande
(par exemple, « TeSys U n°4 »), puis exécutez la commande « Paste » du menu dont le nom correspond au
nœud sélectionné. Une nouvelle commande est ajoutée à la suite de toutes les autres commandes
configurées pour ce nœud. L’ensemble de sa configuration est identique à celle de la commande
précédemment copiée. Raccourci clavier : « Ctrl V ».
b) Sélectionnez l’une des commandes du nœud concerné, puis exécutez la commande « Insert » du menu dont
le nom correspond à celui de la commande sélectionnée. Une nouvelle commande est ajoutée juste avant celle
qui est sélectionnée. L’ensemble de sa configuration est identique à celle de la commande précédemment
copiée.
70
6. Configuration de la passerelle
La nouvelle commande Modbus et la commande Modbus d’origine étant identiques, vous devrez procéder aux
modifications des champs surlignés en bleu dans l’un des deux schémas suivants, selon qu’il s’agit d’une
commande « Preset Multiple Registers » ou d’une commande « Read Holding Registers » (voir chapitre 6.8
Modification des données périodiques échangées avec un esclave Modbus). La correspondance entre les
différents éléments apparaissant dans ces arborescences et la terminologie standard Modbus est située à leur
droite :
NOTE : Dans tous les cas, les éléments « Query / Slave Address » et « Response / Slave Address » sont
automatiquement mis à jour par ABC-LUFP Config Tool en fonction du nœud dans lequel la commande est située.
Leurs valeurs ne peuvent pas être modifiées par l’utilisateur. De même, les champs « Query / Function » et
« Response / Function » dépendent de la nature de la commande Modbus et ne peuvent pas être modifiés par
l’utilisateur.
71
6. Configuration de la passerelle
Les opérations à effectuer sont sensiblement les mêmes que celles qui consistent à modifier les commandes par
défaut. Pour la commande « Read Holding Registers », reportez-vous au chapitre 6.8.1 Remplacement d’une
donnée périodique d’entrée et au chapitre 6.8.3 Augmentation du nombre des données périodiques d’entrée.
Pour la commande « Preset Multiple Registers », reportez-vous au chapitre 6.8.2 Remplacement d’une donnée
périodique de sortie et au chapitre 6.8.4Augmentation du nombre des données périodiques de sortie.
6.11.2. Cas d’un esclave Modbus générique
Dans ce chapitre, nous allons ajouter et configurer des commandes Modbus différentes des commandes par
défaut de la passerelle LUFP9.
Reportez-vous à l'Appendix E: Commandes pour consulter la liste des fonctions Modbus prises en charge par la
passerelle LUFP9. Si vous avez besoin d’utiliser une commande qui n’est pas prise en charge par la passerelle,
vous pouvez la configurer. Une telle commande est englobée dans un élément spécifique appelé
« Transactions » ou devient une nouvelle commande Modbus à part entière. Reportez-vous au dernier
paragraphe pour plus d’informations à ce sujet.
Pour cet exemple, nous allons utiliser un démarreur Altistart, l’ATS48, et une commande Modbus reconnue par
la passerelle et l’ATS48. Il s’agit de la commande « Preset Single Register », dont le code fonction est 6 et qui
permet d’écrire la valeur d’un unique mot de sortie. Cette fonction servira à écrire de manière périodique la
valeur du registre de commande CMD de l’ATS48, situé à l’adresse W400 (adresse 400 = 0x0190).
Puisque la configuration par défaut de la passerelle comporte déjà 8 esclaves Modbus, il est nécessaire d’en
supprimer un, tel que le nœud « TeSys U n°2 », par exemple, et d’ajouter un nouveau nœud à sa place (voir
chapitre 6.6 Suppression d’un esclave Modbus et le chapitre 6.7 Ajout d’un esclave Modbus).
Rappel : Il est fortement déconseillé de supprimer le nœud « TeSys U n°1 », car il contient les commandes qui
correspondent aux services de lecture et d’écriture d’un paramètre dans un esclave Modbus.
72
6. Configuration de la passerelle
Après avoir créé le nouveau
nœud,
nous
devons
le
renommer et lui attribuer
l’adresse Modbus 10, comme
indiqué ci-contre :
Nous ajoutons ensuite la
commande « Preset Single
Register » en exécutant la
commande « Add Command »
du menu « ATS48 ».
Dans la fenêtre qui apparaît (reproduite ci-contre), sélectionnez la
commande « 0x06 Preset Single Register » et exécutez la commande
« Select » du menu « File ».
De retour dans la fenêtre principale de ABC-LUFP Config Tool, la
commande « Preset Single Register » apparaît désormais dans la liste
des commandes Modbus du nœud « ATS48 ».
Développez l’arborescence complète de cette commande, comme illustré ci-dessous. La correspondance entre les
différents éléments apparaissant dans cette arborescence et la terminologie standard Modbus est située à sa droite.
Ces éléments peuvent être configurés à l’aide de ABC-LUFP Config Tool, comme décrit dans les chapitres
suivants.
73
6. Configuration de la passerelle
6.11.2.1. Gestion des modes dégradés
Arrêt ou défaillance du processeur de l’automate
Réponse du processeur de l’automate
Sorties :
Erreur logicielle, réinitialisation des sorties sur leur état par défaut ou conservation de leur état
actuel, selon la configuration.
Erreur matérielle (EEPROM ou défaillance matérielle), état de sortie indéterminé.
Entrées : L’automate cesse de répondre aux entrées quel que soit l’état d’erreur.
Réponse du scanner DeviceNet
En fonction de la configuration du scanner :
le scanner cesse de communiquer avec la passerelle LUFP9,
force les sorties DeviceNet sur la valeur 0 et actualise les entrées,
ou maintient les sorties DeviceNet sur leur dernière position et actualise les entrées.
Réponse de la passerelle LUFP9
Si le scanner cesse de communiquer avec la passerelle, le comportement dépend des options « Offline
options for fieldbus » :
Clear :
Toutes les données envoyées à l’esclave Modbus concerné ont la valeur 0.
Freeze :
Toutes les données envoyées conservent leur valeur actuelle.
No scanning : La requête n'est plus transmise.
Si le scanner force les sorties DeviceNet sur la valeur 0 et actualise les entrées :
toutes les données émises (requêtes d’écriture) sont configurées sur la valeur 0,
la lecture à partir des esclaves continue de s’effectuer normalement.
Si le scanner maintient les sorties DeviceNet et actualise les entrées :
toutes les données envoyées (requêtes d’écriture) conservent leur valeur actuelle,
la lecture à partir des esclaves continue de s’effectuer normalement.
Réponse de l’esclave
La réponse dépend de chaque esclave.
Arrêt ou défaillance du scanner DeviceNet
Réponse du processeur de l’automate
Le processeur de l’automate fournit à l’application plusieurs erreurs et/ou objets de diagnostic au cas où le
scanner DeviceNet cesserait de fonctionner ou connaîtrait une défaillance (entrée/sortie non valide).
Reportez-vous au manuel d’utilisation de l’automate pour consulter leur description.
Ces informations doivent être gérées dans l’application de l’automate.
Réponse du scanner DeviceNet
Si le scanner DeviceNet est arrêté (commande provenant de l’application) :
le scanner cesse de communiquer avec la passerelle LUFP9.
Si le scanner DeviceNet connaît une défaillance,
le scanner cesse de communiquer avec le processeur et la passerelle LUFP9.
Réponse de la passerelle LUFP9
Si le scanner cesse de communiquer avec la passerelle, le comportement dépend des options « Offline
options for fieldbus » :
Clear :
Toutes les données envoyées à l’esclave Modbus concerné ont la valeur 0.
Freeze :
Toutes les données envoyées conservent leur valeur actuelle.
No scanning : La requête n'est plus transmise.
74
6. Configuration de la passerelle
Réponse de l’esclave
La réponse dépend de chaque esclave.
Passerelles LUFP9 déconnectées du côté DeviceNet
Réponse de l’automate
Le processeur de l’automate fournit plusieurs objets d’erreur et de diagnostic provenant du scanner
DeviceNet en cas de déconnexion d’un esclave de l’application.
Reportez-vous au manuel d’utilisation de l’automate pour consulter leur description.
Ces informations doivent être gérées dans l’application de l’automate.
Réponse du scanner DeviceNet
Le scanner DeviceNet fournit au processeur différents objets d’erreur et de diagnostic en cas de
déconnexion d’un esclave DeviceNet.
Réponse de la passerelle LUFP9
Le comportement dépend des options « Offline options for fieldbus » :
Clear :
Toutes les données envoyées à l’esclave Modbus concerné ont la valeur 0.
Freeze :
Toutes les données envoyées conservent leur valeur actuelle.
No scanning : La requête n'est plus transmise.
Réponse de l’esclave
La réponse dépend de chaque esclave.
Défaillance des passerelles LUFP9
Réponse de l’automate
Le processeur de l’automate fournit plusieurs objets d’erreur et de diagnostic provenant du scanner
DeviceNet en cas de défaillance d’un esclave vers l’application.
Reportez-vous au manuel d’utilisation de l’automate pour consulter leur description.
Ces informations doivent être gérées dans l’application de l’automate.
Réponse du scanner DeviceNet
Le scanner DeviceNet fournit au processeur différents objets d’erreur et de diagnostic en cas de défaillance
d’un esclave DeviceNet.
Réponse de la passerelle LUFP9
En cas de défaillance, la passerelle cesse de communiquer avec le scanner DeviceNet et les esclaves
Modbus.
Réponse de l’esclave
La réponse dépend de chaque esclave.
75
6. Configuration de la passerelle
Passerelles LUFP9 déconnectées du côté Modbus ou défaillance d’un esclave
Réponse de l’automate
Le processeur donne accès au mot d’état de la passerelle provenant de la table d’entrée du scanner
DeviceNet, ainsi qu’au mot de commande de la passerelle provenant de la table de sortie.
Ces 2 mots doivent être gérés dans l'application de l'automate afin de détecter si un esclave Modbus est
manquant.
Réponse du scanner DeviceNet
Le scanner DeviceNet doit être configuré de façon à accéder à l'état de la passerelle et aux mots de
commande afin de fournir des informations de diagnostic Modbus.
Réponse de la passerelle LUFP9
Le comportement dépend des différentes options :
Timeout time, nombre de Retries, Reconnect time et Offline option for sub-network.
Réponse de l’esclave
En cas de déconnexion Modbus, le comportement dépend de chaque esclave.
En cas de défaillance d’un esclave, il présente un état indéterminé qui doit être géré dans l’application de
l’automate.
76
6. Configuration de la passerelle
6.11.2.2. Configuration de la requête
Sélectionnez l’élément « Query » de la commande Modbus. Les
différents éléments de la configuration de la requête de cette
commande sont reproduits ci-contre. Les valeurs affichées
correspondent aux valeurs par défaut pour toute nouvelle
commande.
Ces éléments permettent de configurer la gestion de l’ensemble de
la commande, y compris la gestion des modes dégradés (nombre
de ré-émissions, par exemple).
Chacun de ces éléments est décrit, dans l’ordre, dans le tableau situé ci-dessous. Lorsqu’une unité est attribuée
à un élément, elle est indiquée entre parenthèses à la suite du nom de l’élément :
Elément de
configuration
Offline options
for fieldbus
Reconnect time
(10ms)
Valeur par
défaut :
10 ms x 1000 =
10 s
Retries
Valeur par
défaut : 3
Timeout time
(10ms)
Valeur par
défaut : 10 ms x
100 = 1 s
Description
Cet élément affecte les données envoyées à l’esclave Modbus (pour la seule requête à
laquelle appartient cet élément) lorsque la passerelle est déconnectée du réseau DeviceNet.
Cet élément prend l’une des trois valeurs suivantes :
- Clear ..............Les données envoyées à l’esclave Modbus à l’aide de cette requête sont
désormais égales à 0x0000 (RAZ des données de sortie dans la mémoire
de la passerelle).
- Freeze ...........Les données envoyées à l’esclave Modbus à l’aide de cette requête
conservent leur valeur actuelle (gel des données de sortie dans la mémoire
de la passerelle).
- NoScanning ...La requête n’est plus envoyée à l’esclave Modbus par la passerelle.
En cas de non-réponse de l’esclave Modbus à une requête, ou suite à la réception d’une
réponse erronée, la passerelle utilise les éléments « Retries » et « Timeout time (10ms) »
pour effectuer des ré-émissions. Si l’esclave Modbus n’a toujours pas répondu
correctement suite à ces ré-émissions, la passerelle cesse de lui envoyer la requête
correspondante pendant une durée réglable à l’aide de l’élément « Reconnect time
(10ms) ».
Lorsque cette durée s’achève, la passerelle tente de restaurer la communication avec
l’esclave Modbus.
Cet élément indique le nombre de ré-émissions effectuées par la passerelle en cas de nonréponse de l’esclave Modbus à une requête ou en cas de réponse erronée. Ce processus
de ré-émission cesse dès que la passerelle obtient dans les temps une réponse correcte. Si
aucune des ré-émissions n’a permis à la passerelle d’obtenir une réponse correcte,
l’esclave Modbus est considéré comme étant déconnecté, mais uniquement vis-à-vis de la
commande concernée. La passerelle utilise alors les éléments « Offline options for subnetwork » et « Reconnect time (10ms) » et la DEL r MODBUS devient rouge. Celle-ci ne
redeviendra verte qu’à condition que la commande Modbus associée obtienne une réponse
correcte, suite à la reprise des communications (voir élément « Reconnect time (10ms) »).
Si le nombre de ré-émissions est égal à 0, le processus décrit ci-dessus ne sera pas
exécuté.
Cet élément représente le temps d’attente d’une réponse de la part de la passerelle. Si une
réponse n’est pas parvenue à la passerelle dans le temps imparti, configuré à l’aide de
l’élément « timeout time (10ms) », la passerelle procède à une ré-émission. Ce processus
continue jusqu’à atteindre la dernière ré-émission autorisée (voir élément « Retries »), puis
la passerelle déclare l’esclave Modbus comme étant déconnecté, mais uniquement vis-àvis de la commande à laquelle appartient l’élément « timeout time (10ms) ».
77
6. Configuration de la passerelle
Elément de
configuration
Trigger byte
address
Update mode
Description
Cet élément n’est utilisé par la passerelle qu’à la condition que « Update mode » soit défini
sur « Change of state on trigger ». Dans ce cas, il spécifie l’adresse, dans la mémoire de
sortie de la passerelle (0x0202 à 0x03FF), d’un compteur 8 bits géré par le maître
DeviceNet.
Lorsque le maître DeviceNet actualise la valeur de l’élément « Trigger Byte Address » en lui
attribuant toute autre valeur que zéro, la requête configurée à l’aide d’un « Update Mode »
défini sur « Change of state on trigger » est transmise à l’esclave Modbus. Le maître
DeviceNet doit donc avoir accès à ce compteur de la même manière que pour les registres
de sortie périodiques destinés aux départs-moteurs TeSys U.
Comparativement à la valeur « On data change » du « Update Mode », ce mode permet
d’envoyer une commande sur ordre spécifique du maître DeviceNet si, par exemple, celui-ci
ne peut pas mettre à jour l’ensemble des données d’une requête au même moment.
NOTE : Dans le cas de la configuration par défaut de la passerelle, le mode des
commandes personnalisées « Transactions 1 » et « Transactions 2 » du nœud « TeSys U
n°1 » est défini sur « Change of state on trigger ». Ces commandes apériodiques servent,
respectivement, à lire et à écrire la valeur d’un paramètre de l’un des esclaves Modbus.
Les éléments « Trigger byte address » des éléments « Query » de ces deux commandes
sont configurés aux adresses 0x021E et 0x021F. Il s’agit des « compteurs de requête de la
lecture/écriture d’un paramètre ». Vis-à-vis du scanner DeviceNet et de RSNetWorx, ces
deux données sont configurées de la même manière que les autres sorties (voir
chapitre 4.2.4 Modification des paramètres de la passerelle) et correspondent à la sortie
O:1.16.
Pour émettre l’une de ces deux commandes, l’automate maître DeviceNet devra tout
d’abord mettre à jour l’ensemble des données à transmettre sur le réseau Modbus pour
cette commande (adresses 0x0212 à 0x0217 ou adresses 0x0218 à 0x021D), puis modifier
la valeur du compteur associé (adresse 0x021E ou 0x021F). La passerelle transmettra
alors la requête qui correspond à la commande.
NOTE : Il n’est pas obligatoire que le « trigger byte » soit une donnée de sortie mise à jour
par le maître DeviceNet. Il est tout à fait envisageable qu’il s’agisse d’une entrée comprise
entre 0x0002 et 0x01FF. Dans ce cas, l’esclave Modbus qui met à jour cet octet
conditionnera les échanges de la commande en cours de configuration.
Cet élément sert à préciser le mode d’émission de la requête sur le réseau Modbus. Il
prend l’une des quatre valeurs suivantes :
- Cyclically................................. Mode de communication par défaut. La requête est transmise
de manière périodique sur le réseau Modbus (voir élément « Update time »).
- On data change ...................... La passerelle transmet la requête sur le réseau Modbus
lorsqu’au moins l’une des données de cette requête est modifiée par le maître
DeviceNet. Il s’agit donc d’un mode de communication apériodique.
- Single Shot ............................. Ce mode de transmission n’autorise qu’un seul échange
Modbus pour toute la durée de fonctionnement de la passerelle. Cet échange a lieu
juste après l’initialisation de celle-ci.
- Change of state on trigger...... Avec ce mode de communication apériodique, la requête
Modbus est envoyée à chaque fois que le maître DeviceNet modifie la valeur d’un
compteur 8 bits désigné par l’élément « Trigger byte address ». C’est le cas, par
exemple,
des
requêtes
associées
aux
commandes
personnalisées
« Transactions 1 » et « Transactions 2 » du nœud « TeSys U n °1 » de la
configuration par défaut de la passerelle. Ces requêtes sont transmises lorsque la
valeur des « trigger bytes » associés (adresses 0x021E et 0x021F) sont modifiées
par le maître DeviceNet. Reportez-vous à la description de cet élément pour obtenir
de plus amples informations sur l’utilité de ce mode de communication.
78
6. Configuration de la passerelle
Elément de
configuration
Update time
(10ms)
Description
Cet élément n’est utilisé par la passerelle qu’à la condition que « Update mode » soit défini sur
« Cyclically ». Dans ce cas, il spécifie la période d’émission de la requête sur le réseau
Modbus.
Valeur par
défaut : 10ms x
100 = 1s
Pour revenir à notre exemple utilisant l’ATS48 à l’adresse 10, nous
utiliserons la configuration présentée ci-contre. Les points notables
de cette configuration sont les suivants :
• Lors de la déconnexion, les données sont réinitialisées sur les
deux réseaux.
• 3 ré-émissions sont effectuées avec un timeout de 100 ms.
• Les communications périodiques ont un « Update time »
cyclique égal à 300 ms.
79
6. Configuration de la passerelle
6.11.2.3. Configuration de la réponse
Sélectionnez ensuite l’élément « Response » de la commande
Modbus. Les différents éléments de la configuration de la réponse
à cette commande sont reproduits ci-contre. Les valeurs affichées
correspondent aux valeurs par défaut pour toute nouvelle
commande.
Ces éléments permettent de configurer un seul aspect de la gestion de la commande, décrit en haut de la page
de droite. Chacun de ces éléments est décrit, dans l’ordre, dans le tableau situé ci-dessous :
Elément de
configuration
Trigger byte
Trigger byte
address
Description
Cet élément est utilisé par la passerelle pour activer ou non l’incrémentation unitaire d’un
compteur 8 bits afin de signaler au maître DeviceNet la réception d’une nouvelle réponse à la
commande Modbus associée. Il prend l’une des deux valeurs suivantes :
- Disabled...................................Configuration par défaut. La passerelle n’incrémente aucun
compteur sur réception de la réponse Modbus.
- Enabled ...................................Chaque fois que la passerelle reçoit une nouvelle réponse à la
commande Modbus associée, elle incrémente la valeur d’un compteur 8 bits désigné par
l’élément « Trigger byte address » (voir ci-dessous). Cette modification de la valeur de
l’élément « Trigger Byte Address » peut être utilisée pour indiquer au maître DeviceNet
que les données de la réponse Modbus sont déjà sur le point d'être interrogées.
Cet élément n’est utilisé par la passerelle qu’à la condition que l’élément « Trigger byte » soit
défini sur « Enabled ». Dans ce cas, il spécifie l’adresse, dans la mémoire d'entrée de la
passerelle (0x0002 0 0x01FF), d’un compteur 8 bits géré par la passerelle.
Lorsque la passerelle reçoit une réponse à la commande Modbus associée, elle incrémente la
valeur de ce compteur de manière unitaire (valeur = valeur+1). Le maître DeviceNet doit donc
avoir accès à ce compteur de la même manière que pour les registres d’entrée périodiques
issus des départs-moteurs TeSys U.
Ce mode permet d’informer le maître DeviceNet qu’une nouvelle réponse est disponible. Cela
peut être utile, par exemple, s’il est possible que les données de deux réponses successives
soient identiques.
NOTE : Dans le cas de la configuration par défaut de la passerelle, l’élément « Trigger byte »
des réponses aux commandes personnalisées « Transactions 1 » et « Transactions 2 » du nœud
« TeSys U n°1 » est défini sur « Enabled ». La gestion des réponses aux commandes de lecture
et d’écriture de paramètres est donc événementielle.
Les éléments « Trigger byte address » des éléments « Response » de ces deux commandes
sont configurés aux adresses 0x001E et 0x001F. Il s’agit des « compteurs de réponse de la
lecture/écriture d’un paramètre ». Vis-à-vis du scanner DeviceNet et de RSNetWorx, ces deux
données sont configurées de la même manière que les autres entrées (voir chapitre 4.2.6
Configuration des entrées issues de la passerelle) et correspondent tous deux à l’entrée I:1.16.
L’automate maître DeviceNet pourra détecter la réception d’une réponse de la part d’un
esclave Modbus en comparant la valeur précédente et la valeur actuelle du compteur associé
(adresse 0x001E or 0x001F). S’il y a eu incrémentation unitaire de ce compteur, l’automate
pourra, par exemple, lire l’ensemble des données de la réponse (adresses 0x0013 à 0x0017 ou
adresses 0x0018 à 0x001D) et autoriser l’émission d’une nouvelle requête de lecture ou
d’écriture de la valeur d’un paramètre (à l’aide d’un « Trigger byte » dédié aux requêtes).
Contrairement aux autres compteurs « Query », la valeur enregistrée à l’adresse « Response »
du Trigger byte est un véritable compteur 256, c’est-à-dire que la valeur nulle doit être prise en
compte (… 254, 255, 0, 1, 2 …).
Dans cet exemple utilisant l’ATS48, nous ne souhaitons pas que la réponse devienne événementielle. Nous
conserverons par conséquent la configuration par défaut.
80
6. Configuration de la passerelle
6.11.2.4. Configuration du contenu de la trame de la requête
La fenêtre reproduite ci-dessous est obtenue à l’aide de la commande « Edit Frame » du menu « Query ».
Contrairement à l’arborescence de la fenêtre principale de ABC-LUFP Config Tool, cet affichage présente
l’avantage de visualiser l’ensemble des champs de la trame en même temps que leurs valeurs. Les valeurs
affichées ci-dessous correspondent aux valeurs affectées par défaut à la requête de la commande Modbus que
nous avons créée. Sous cette fenêtre a été ajoutée la correspondance avec le contenu de la trame Modbus
correspondante.
N° esclave
N° fonction
Numéro du mot ( MSB / LSB )
Valeur du mot ( MSB / LSB )
CRC16 ( LSB / MSB )
Editez les valeurs non grisées les unes après les autres. Leur description est fournie ci-après.
La nature des champs d’une trame dépend de la commande Modbus à laquelle elle correspond. Cependant, un
certain nombre de ces champs sont communs à toutes les trames, tandis que d’autres sont communs à
plusieurs d’entre elles. Voici la description de celles qui sont présentées ci-dessus, dans le cadre de l’exemple
décrit au début du chapitre 6.11.2.
Champ dans
la trame
Slave
Address
Function
Register
Taille dans la
Description
trame
1 octet
Ce champ ne peut pas être modifié par l’utilisateur et sa valeur est grisée pour
le lui signaler. ABC-LUFP Config Tool met à jour la valeur de ce champ de
manière automatique à l’aide de l’adresse de l’esclave Modbus qui correspond
au nœud courant.
NOTE : Ce champ est commun aux requêtes de toutes les commandes Modbus.
Exemple : La valeur de ce champ est définie sur l’adresse de l’esclave Modbus
qui correspond aux nœuds « ATS48 », c’est-à-dire à 0x0A.
1 octet
Ce champ ne peut pas être modifié par l’utilisateur et sa valeur est grisée pour
le lui signaler. ABC-LUFP Config Tool met à jour la valeur de ce champ de
manière automatique à l’aide du code fonction de la commande Modbus
correspondante.
2 octets
NOTE : Ce champ est commun aux requêtes de toutes les commandes Modbus.
Exemple : La valeur de ce champ est égale au code de la commande « Preset
Single Register » (écriture de la valeur d’un mot de sortie), c’est-à-dire à 0x06.
Adresse d’un mot de sortie, ou d’un registre, dans la mémoire de l’esclave
Modbus. Ce champ désigne donc l’objet mémoire sur lequel porte la commande.
NOTE : Ce champ est commun aux requêtes de toutes les commandes
Modbus ayant pour but d’accéder à un ou plusieurs emplacements dans la
mémoire d’un esclave Modbus. Dans le cas d’un accès à plusieurs
emplacements mémoire, le champ « Register » désigne l’adresse du premier
mot pris pour objet par la commande.
Exemple : La valeur de ce champ doit être modifiée en saisissant l’adresse du
registre de commande CMD, c’est-à-dire 400 (0x0190). Cette valeur sera
automatiquement convertie au format hexadécimal si l’utilisateur la saisit au
format décimal.
81
6. Configuration de la passerelle
Champ dans
la trame
Preset Data
Taille dans la
trame
2 octets
ou plus s’il
s’agit d’un
bloc de
données
Description
Data Location : Adresse, dans la mémoire des données de sortie de la
passerelle (0x0202 to 0x03FF), de la donnée à transmettre dans le champ
« Preset Data » de la trame de la requête.
NOTE : Le champ « Data location » est utilisé pour chaque trame permettant
de faire transiter des données entre les esclaves Modbus et le maître
DeviceNet. Dans ce cas, il désigne l’adresse de début du bloc de données à
transmettre.
Lorsque vous sélectionnez une valeur pour le champ « Data Location », les
données doivent être situées à des adresses paires afin d’aligner les données
Modbus (au format 16 bits) sur les sorties O:1.x du scanner DeviceNet. Si les
données ne sont pas situées à des adresses paires, les valeurs prévues pour
les registres Modbus peuvent être réparties sur deux mots de l’automate
DeviceNet. Ceci complique considérablement la programmation de
l’application, car celle-ci peut être contrainte d’analyser un mot de l’automate
pour l’octet Modbus LSB et un autre pour l’octet Modbus MSB. Si ce problème
n’est pas géré correctement, il est possible de lire et d’écrire des valeurs de
données erronées sur les esclaves Modbus.
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
L’utilisateur doit utiliser des valeurs paires pour le champ « Data Location ». La sélection de valeurs de
données impaires complique la programmation de l’application et augmente les risques d’écriture ou de lecture
de valeurs Modbus incorrectes sur ou depuis les périphériques esclaves. Selon la configuration de l’utilisateur,
cela peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Pour revenir à notre exemple précédent, la valeur à affecter au registre CMD
de l’ATS48 doit être placée dans la zone des données de sortie de la
passerelle. Nous utiliserons le premier emplacement libre commençant à une
adresse paire, c’est-à-dire celui qui est situé à l’adresse 0x0220, dans le cas
de la configuration par défaut de la passerelle.
Data length : Longueur du bloc des données de sortie, dans la mémoire de la
passerelle, dont les valeurs doivent être transmises dans le champ « Preset
Data » de la trame de la requête. Elle est exprimée en nombre d’octets.
NOTE : Le champ « Data length » est toujours utilisé conjointement au champ
« Data location », décrit ci-dessus.
Exemple : Puisque la commande « Preset Single Register » sert à écrire la
valeur d’un seul registre (16 bits), la valeur du champ « Data length » doit être
égale à 2.
Consultez la documentation de chaque esclave Modbus pour connaître le
nombre maximum de données 8 bits qu’il est possible de placer dans les
champs de type « Data » des requêtes et des réponses de cet esclave. Dans
le cas de l’ATS48, par exemple, ce nombre est limité à 30 mots de 16 bits (la
longueur du champ « Data » est limitée à ≤ 60).
82
6. Configuration de la passerelle
Champ dans
la trame
Taille dans la
trame
Description
Byte swap : Précise si les octets des données de sortie à transmettre à
l’esclave Modbus doivent être ou non permutés avant d’être placés dans la
trame Modbus. Les trois valeurs possibles sont les suivantes :
- No swapping ....... Configuration par défaut. Les données sont transmises
dans le même ordre que celui de leur présence dans la mémoire de la
passerelle.
- Swap 2 bytes ...... Les octets à transmettre sont permutés deux à deux. Pour
une donnée 16 bits, l’octet de poids fort est placé en premier dans la trame
Modbus, alors qu’elle est toujours écrite dans la mémoire de la passerelle
par un maître DeviceNet avec l’octet de poids faible en premier.
- Swap 4 bytes ...... Les octets à transmettre sont permutés quatre à quatre. Ce
cas est très peu utilisé, car il concerne uniquement les données 32 bits.
Son principe est similaire à celui du cas précédent, « Swap 2 bytes ».
NOTE : Avec DeviceNet, utilisez « Swap 2 bytes ».
Checksum
2 octets
Exemple : Nous utiliserons la valeur « Swap 2 bytes », car les deux octets de
la valeur à écrire dans le registre CMD de l’ATS48, transmis par l’automate
SLC500, sont placés dans la mémoire de la passerelle dans l’ordre poids
faible / poids fort.
Error check type : Type du contrôle d’erreur pour la trame.
- CRC .................... Méthode par défaut.
Il s’agit de la méthode qui a été adoptée pour le protocole Modbus RTU. Il est
impossible de la changer.
Error check start byte : Indique le numéro de l’octet, dans la trame, à partir
duquel le calcul du « checksum » doit commencer. Le premier octet de chaque
trame porte le numéro 0.
NOTE : Le calcul du checksum d’une trame doit toujours commencer par le
premier octet. Ne remplacez pas la valeur par défaut « zéro » de l’élément
« Error check start byte ». Une valeur différente de zéro provoquera une erreur
de CRC et toutes les communications Modbus retourneront une erreur.
83
6. Configuration de la passerelle
6.11.2.5. Configuration du contenu de la trame de la réponse
La fenêtre reproduite ci-dessous est obtenue à l’aide de la commande « Edit Frame » du menu « Response ».
Les valeurs qui y sont présentées correspondent aux valeurs affectées par défaut à la réponse de la commande
Modbus que nous avons créée. Sous cette fenêtre a été ajoutée la correspondance avec le contenu de la trame
Modbus correspondante.
N° esclave
N° fonction
Numéro du
mot
( MSB / LSB )
Valeur du mot ( MSB / LSB )
CRC16 ( LSB / MSB )
Editez les valeurs non grisées les unes après les autres.
Leur description est fournie sur la page suivante, mais reportez-vous également au chapitre précédent, car la
nature du contenu des trames des réponses est très proche de celle des champs des trames des requêtes
Modbus.
NOTE: Si la valeur de l’un des champs de la réponse d’un esclave Modbus est différente de celle qui est
configurée via ABC-LUFP Config Tool, la réponse sera refusée par la passerelle. Celle-ci procédera alors à une
ré-émission de la requête, à condition qu’au moins une ré-émission ait été configurée pour cette commande (voir
chapitre 6.11.2.2 Configuration de la requête
84
6. Configuration de la passerelle
Champ dans Taille dans la
la trame
trame
Slave Address
1 octet
Function
1 octet
Register
2 octets
Preset Data
2 octets
ou plus s’il
s’agit d’un
bloc de
données
Description
Identique à celle du champ « Slave Address » de la requête.
Identique à celle du champ « Function » de la requête.
Identique à celle du champ « Register » de la requête, puisque la réponse
Modbus, dans le cas de la commande « Preset Single Register », est un écho
à la requête correspondante.
Vous devez ici aussi saisir l’adresse de l’objet mémoire sur lequel porte la
commande.
Si vous recevez un code d’exception, reportez-vous à (*).
Data Location : Adresse, dans la mémoire des données d’entrée de la
passerelle (0x0002 à 0x01FF), de la donnée reçue dans le champ « Preset
Data » de la trame de la réponse.
NOTE : Veillez à ce que les données soient situées à des adresses paires afin
d’aligner les données Modbus (au format 16 bits) sur les entrées I:1.x du
scanner DeviceNet.
Exemple : La valeur renvoyée en guise d’écho à la commande doit être placée
dans la zone des données d’entrée de la passerelle. Nous utiliserons le
premier emplacement libre, c’est-à-dire celui qui est situé à l’adresse 0x0020,
dans le cas de la configuration par défaut de la passerelle.
Si vous recevez un code d’exception, reportez-vous à (*).
AVERTISSEMENT
RISQUE DE FONCTIONNEMENT IMPREVU DE L’APPAREIL
L’utilisateur doit utiliser des valeurs paires pour le champ « Data Location ». La sélection de valeurs de
données impaires complique la programmation de l’application et augmente les risques d’écriture ou de lecture
de valeurs Modbus incorrectes sur ou depuis les périphériques esclaves. Selon la configuration de l’utilisateur,
cela peut provoquer un fonctionnement imprévu de l’appareil.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Data length : Longueur du bloc des données d’entrée reçues dans le champ
« Preset Data » de la trame de la réponse. Elle est exprimée en nombre
d’octets.
Exemple : La valeur du champ « Data length » doit être égale à 2.
Byte swap : Identique à celle du champ « Byte swap » de la requête (reportezvous au tableau des requêtes pour plus d’informations).
Exemple : Nous utiliserons ici aussi la valeur « Swap 2 bytes », pour les
mêmes raisons que dans le cas de la requête.
Checksum
2 octets
Error check type : Identique à celle du champ « Error check type » de la
requête.
Error check start byte : Identique à celle du champ « Error check start byte »
de la requête.
NOTE : Ces deux champs ne peuvent pas être modifiés par l’utilisateur et
leurs valeurs sont grisées pour le lui signaler. ABC-LUFP Config Tool met à
jour les valeurs de ces champs de manière automatique à l’aide de celles des
champs « Error check type » et « Error check start byte » de la requête.
(*) Si vous recevez un code d’exception, la passerelle procède à la ré-émission de la requête conformément au
nombre de nouvelles tentatives qui a été défini. Elle déconnecte ensuite l’esclave.
85
6. Configuration de la passerelle
6.11.3. Ajout d’une commande Modbus spéciale
En dehors des commandes Modbus standards dont il est question dans le chapitre précédent, il est possible de
créer deux types de commandes Modbus spéciales : des commandes Modbus utilisant le même modèle que les
commandes standards, et des commandes Modbus dont la nature et le contenu des trames est entièrement
modifiable par l’utilisateur.
6.11.3.1. Commandes Modbus ayant pour modèle les commandes standard
Pour créer une commande de ce type, dans la fenêtre « Select Command » (voir chapitre 6.11.2 Cas d’un
esclave Modbus générique), exécutez la commande « Add Command » du menu « Command ». La fenêtre
reproduite en haut de la page suivante apparaît alors. Elle présente la structure des trames des requêtes et des
réponses de la future commande, qui sera ensuite ajoutée à la liste des commandes Modbus disponibles. Cette
structure comprend les éléments standard, c’est-à-dire les champs « Slave Address », « Function » et
« Checksum », décrits dans les chapitres précédents.
Reportez-vous au chapitre 2.12 « Command editor » du manuel d’utilisation de ABC-LUFP Config Tool, intitulé
AnyBus Communicator – User Manual, pour de plus amples informations sur la création de commandes
Modbus standards. Ce manuel est disponible sur le CD LU9CD1 : « ABC_User_Manual.pdf ».
86
6. Configuration de la passerelle
6.11.3.2. Commandes Modbus personnalisables
Dans ABC-LUFP Config Tool, ces commandes sont appelées des « Transactions ». Contrairement aux
exemples précédents, dans lesquels de nombreuses variables étaient fixes en raison de la commande Modbus
sélectionnée, l’ensemble de la structure des trames de requêtes et de réponses associées à ces transactions
repose sur les données présentes dans la mémoire de la passerelle. Ces champs de données présents dans la
mémoire de la passerelle peuvent contenir des données aux formats Byte, Word ou DWord et un champ final
« Checksum ».
(Reportez-vous au tableau des requêtes pour plus d’informations.)
Toutes les données contenues dans les champs « Data » des requêtes et des réponses d’une commande de
type « Transactions » sont gérées par le maître DeviceNet, y compris les champs « Slave address » et
« Function » si ceux-ci sont placés dans un champ « Data ». Cela permet, par exemple, de gérer l’intégralité des
champs des trames Modbus depuis le maître DeviceNet si l’ensemble des champs de la requête et de la
réponse d’un élément « Transactions » (hors « Checksum ») sont des champs de type « Data ».
AVERTISSEMENT
CHAMPS « DATA » MULTIPLES DANS UNE TRAME MODBUS
N’utilisez pas plus d’un champ « Data » par trame Modbus. Plusieurs champs « Data » utilisés dans une
même trame Modbus risquent de ne pas être exécutés dans l'ordre approprié par la passerelle, provoquant
des conséquences imprévues.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Les constantes au format Byte, Word ou DWord placent les valeurs de ces constantes dans les trames des
requêtes Modbus (constantes des éléments « Query ») ou les comparent à celles qui sont situées dans les
réponses Modbus (constantes des éléments « Response »). Ces comparaisons servent à accepter (valeurs
identiques) ou à refuser (valeurs différentes) les réponses Modbus de la même façon que dans le cas des
commandes Modbus standards. Le maître DeviceNet n’a pas accès à ces constantes. Elles servent
principalement à remplacer des champs tels que « Slave address », « Function », « Starting Address », etc.
Reportez-vous à la section « Actions on query/response » du chapitre 2.6.4 Transaction et au chapitre 2.6.6
Frame objects du manuel d’utilisation de ABC-LUFP Config Tool, intitulé AnyBus Communicator – User
Manual, pour de plus amples informations sur la manipulation des commandes de type « Transactions ». Ce
manuel est disponible sur le CD LU9CD1 : « ABC_User_Manual.pdf ».
La configuration par défaut de la passerelle LUFP9 comporte deux commandes de type « Transactions ». Il
s’agit des commandes apériodiques de lecture et d’écriture de la valeur d’un paramètre d’esclave Modbus
(forcément un départ-moteur TeSys U dans le cas de la configuration par défaut). Elles sont configurées pour le
seul nœud « TeSys U n°1 », car l’adresse de l’esclave est pilotée par le maître DeviceNet via le premier octet du
champ « Data », qui correspond au champ « Slave Address » des commandes Modbus standards. Cela permet
au maître DeviceNet d’envoyer cette commande à tous les esclaves Modbus, en procédant esclave par esclave,
par le biais du premier octet du champ « Data ». Le reste des trames de ces deux commandes est lui aussi
placé dans le même champ « Data ». Le maître DeviceNet a donc accès à l’intégralité du contenu des trames de
ces deux commandes.
87
6. Configuration de la passerelle
6.12. Configuration des caractéristiques générales de la passerelle
Cette opération concerne les caractéristiques générales de la passerelle
(éléments « Fieldbus » à « Sub-Network »), alors que les chapitres
précédents s’attachaient à décrire la configuration des esclaves Modbus
(éléments situés sous l’élément « Sub-Network »).
L’élément « Fieldbus » décrit le réseau amont, c’est-à-dire le réseau
DeviceNet dans le cas de la passerelle LUFP9.
Les éléments « ABC » et « Sub-Network » décrivent le réseau aval, c’està-dire le réseau Modbus RTU dans le cas de la passerelle LUFP9, et
permettent d’identifier la version du logiciel présent dans la passerelle.
La configuration de ces trois éléments, ainsi que les commandes
auxquelles ils donnent accès, sont décrites dans les trois chapitres
suivants.
6.12.1. Elément « Fieldbus »
Sous cet élément figure la liste des télégrammes (appelés « mailboxes ») configurés par défaut. Ces éléments
ne sont pas décrits ici, car ils sont propres à la gestion interne de la passerelle. Ces « mailboxes » configurés
par défaut ne peuvent être ni modifiés, ni supprimés. Leur nombre et leur nature dépendent du type du réseau
amont.
Lorsque l’élément « Fieldbus » est sélectionné, vous avez la
possibilité de sélectionner le type du réseau amont :
« DeviceNet » avec la passerelle LUFP9.
Si le réseau sélectionné ne correspond pas à la passerelle,
un message d’erreur s’affiche et la configuration n’est pas
chargée.
Si votre PC est relié à la passerelle à l’aide du câble PowerSuite et que vous utilisez ABC-LUFP Config Tool en
mode « connecté » dès le démarrage de ABC-LUFP Config Tool, le type du réseau amont sera
automatiquement détecté.
L’unique commande accessible depuis le menu
« Fieldbus » est la commande « About Fieldbus… ».
En mode « connecté », la fenêtre représentée cicontre s’affiche. En mode « déconnecté », la mention
« Unknown » remplacera « DeviceNet » pour signifier
que le type de réseau amont ne peut pas être identifié.
88
6. Configuration de la passerelle
6.12.2. Elément « ABC »
Les deux commandes accessibles depuis le menu « ABC » sont les
commandes « About ABC… » et « Disconnect » (ou « Connect » si l’on est en
mode « déconnecté »).
- L’exécution
de
la
commande « About ABC… »
permet à ABC-LUFP Config
Tool de récupérer et d’afficher
l’ensemble des informations
permettant
d’identifier
la
version du logiciel présent sur
le PC et celle du logiciel
présent dans la passerelle.
Un exemple est illustré cicontre.
Lorsque la commande « About ABC… » est exécutée en mode « déconnecté », les trois derniers champs sont
remplacés par « Unknown » pour signifier que la version du logiciel de la passerelle ne peut pas être identifiée.
NOTE : Seule la version du logiciel présent dans la carte Modbus de la passerelle est affichée. Ce logiciel est
commun à plusieurs types de passerelles commercialisées par Schneider Electric. La version du logiciel de la
carte DeviceNet de la passerelle est uniquement accessible à l’aide de l’objet DeviceNet approprié (voir
Appendix D:, Identité de l'objet).
- La commande « Disconnect » permet de passer du mode « connecté » au mode « déconnecté ». Elle n’est
disponible qu’en mode « connecté ». Elle est remplacée par la commande « Connect » une fois en mode
« déconnecté ».
En dehors de ces deux commandes exclusives, le passage en mode « connecté » est demandé par ABC-LUFP
Config Tool lors de certains événements (démarrage de ABC-LUFP Config Tool, utilisation des commandes
« Upload » et « Download », etc.).
Le mode de connexion de ABC-LUFP Config Tool est affiché à droite de sa barre d’état :
Mode « connecté » (DEL de gauche verte)
Mode « déconnecté » (DEL de droite rouge)
89
6. Configuration de la passerelle
Quatre options permettent de configurer certains aspects du système de la passerelle :
- Control/Status Byte : Les trois possibilités disponibles pour cette option sont décrites dans le chapitre 5 5.
- Module Reset : Par défaut, cette option empêche la passerelle de se réinitialiser lorsqu’un problème de
fonctionnement interne se produit. La modification de cette option est principalement destinée à un usage de
type « laboratoire ».
- Physical Interface : L’unique possibilité offerte pour cette option indique que l’interface physique du réseau aval
de la passerelle est une liaison série.
- Protocol : Cette option ne doit pas être modifiée, car elle indique le type de protocole utilisé sur le réseau aval de la
passerelle. Dans le cas de la passerelle LUFP9, « Master Mode » doit impérativement être sélectionnée. Les
autres possibilités offertes sont réservées à d’autres produits de la même famille que cette passerelle.
6.12.3. Elément « Sub-Network »
Les cinq commandes accessibles depuis le menu « Sub-Network » sont :
- « Monitor » : Permet de consulter la correspondance entre les données
des commandes Modbus et le contenu de la mémoire de la passerelle.
Des exemples de l’utilisation de cette commande sont présentés dans
les chapitres 6.8.3, 6.8.4 et 6.9.
- « Add Node » : Permet d’ajouter un nouveau nœud sur le réseau aval
Modbus. Chaque nœud correspond à un esclave Modbus différent.
Cette commande n’est pas disponible s’il y a déjà 8 esclaves Modbus,
ce qui est le cas de la configuration par défaut de la passerelle.
- « Add Broadcaster » : Permet d’ajouter un nœud de diffusion (voir chapitre 6.13 Ajout d’un nœud de diffusion
- « Load Node » : Permet d’ajouter un nœud pré-configuré sur le réseau aval Modbus. La configuration de ce
nœud est contenue dans un fichier XML (voir section « Importation/exportation de la configuration d’un esclave
Modbus » du chapitre 6.7 Ajout d’un esclave Modbus). Cette commande n’est pas disponible s’il y a déjà
8 esclaves Modbus, ce qui est le cas de la configuration par défaut de la passerelle.
90
6. Configuration de la passerelle
-« Sub-Network Status… » : En mode « connecté » (voir
chapitre 6.12.2 Elément « ABC » cette commande permet
d’afficher une fenêtre récapitulant les valeurs des compteurs
d’erreurs de la passerelle. Ces compteurs sont également
utilisés par la passerelle pour mettre à jour la valeur de son
mot d’état (voir chapitre 5.5 Description du mot d’état de la
passerelle). Le bouton « Update » permet de relire les
valeurs actuelles de ces compteurs.
Lorsque cette commande est exécutée en mode
« déconnecté », toutes les valeurs affichées sont
remplacées par la mention « Unknown » pour signifier
qu’elles ne peuvent pas être lues sur la passerelle. Le
bouton « Update » devient alors inaccessible.
Lorsque l’élément « Sub-Network » est sélectionné, vous avez accès à l’ensemble des options permettant de
paramétrer le format du protocole de communication de la passerelle sur le réseau Modbus. Les différents
paramétrages que vous pouvez effectuer sont décrits ci-dessous. L’ensemble des esclaves Modbus présents
doivent supporter ce paramétrage et être configurés de manière appropriée.
- Bitrate (bits/s) : La passerelle
supporte un nombre limité de
vitesses de communication.
Sélectionnez
celle
qui
convient à l’esclave le plus
lent.
- Data bits : 8 bits (obligatoire).
- Message delimiter (10ms) :
Durée de silence ajoutée au
temps de silence normal
entre la fin d’un message et
le début du message suivant.
Le temps de silence normal
correspond
au
temps
d’émission de 3,5 caractères.
- Parity : Choisissez la parité
en fonction du format retenu
pour les communications sur
votre réseau Modbus.
- Physical standard : RS485
(obligatoire).
- Start bits : 1 bit (obligatoire).
- Stop bits : 1 bit (parité paire
ou impaire) ou 2 bits (sans
parité).
91
6. Configuration de la passerelle
6.13. Ajout d’un nœud de diffusion
Un nœud de diffusion ne correspond à aucun esclave Modbus en particulier, car il s’applique à tous les
esclaves Modbus. Toutes les commandes qui seront configurées pour ce nœud seront émises avec le champ
« Slave Address » égal à 0x00. Cela signifie que tous les esclaves exécuteront la commande, mais qu’aucun
d’entre eux n’y répondra.
Pour ajouter un nœud de diffusion, sélectionnez l’élément « Sub-Network »,
puis exécutez la commande « Add Broadcaster » du menu « Sub-Network ». Le
nœud de diffusion ainsi créé ne compte pas dans la limite du nombre de nœuds
configurables. Un exemple simple figure ci-contre :
L’ajout et le paramétrage d’une commande Modbus dans la liste des
commandes du nœud de diffusion sont effectués de la même manière que pour
les autres nœuds, aux différences suivantes près :
- La liste des commandes Modbus standard qu’il est possible d’utiliser en
diffusion est considérablement réduite. Seules les fonctions 0x06 et 0x10
peuvent être utilisées (voir la liste du chapitre 6.11.2).
- La commande est constituée d’une requête, mais ne comporte aucune réponse. La requête porte le nom de
la commande elle-même, au lieu de l’appellation « Query ». De plus, chaque commande de diffusion ne
consomme qu’une seule des 50 requêtes et réponses admises par la passerelle, puisqu’il n’y a aucune
réponse possible pour une telle commande.
- La valeur du champ « Slave Address » de la trame de la requête est égale à 0x00.
Reportez-vous au chapitre 6.11.2.2 Configuration de la requête, pour plus d’informations concernant la
configuration d’une requête Modbus.
92
Appendix A: Caractéristiques techniques
Environnement
Dimensions (hors connecteurs)
Apparence externe
Couple de serrage
Alimentation
Humidité relative maximale
Température de l’air ambiant
au voisinage de l’appareil, en
milieu sec
UL
CE
Compatibilité électromagnétique
(CEM) : Emission
Compatibilité électromagnétique
(CEM) : Immunité
Hauteur : 120 mm
Largeur : 27 mm
Profondeur : 75 mm
Boîtier plastique avec dispositif de fixation à un rail DIN.
Connecteur d’alimentation : compris entre 0,56 et 0,79 N-m.
24 V régulée à ± 10 %
Consommation maximale : Environ 95 mA
95% sans condensation ni ruissellement, conformément à la norme
IEC 68-2-30
Conformément aux normes IEC 68-2-1 Ab, IEC 68-2-2 Bb et IEC 68-2-14 Nb :
• Stockage :
–25°C (± 3)
à
+85°C (± 2)
• Fonctionnement : -5°C (± 3)
à
+70°C (± 2)
Certificat E 214107
Catégorie « type ouvert »
Le produit doit être installé dans une armoire électrique ou dans un emplacement
équivalent.
Certifié conforme aux normes européennes, sauf avis contraire.
Conforme à la norme EN 50 081-2:1993 (environnement industriel)
Testé selon la classe A en rayonnement de la norme EN 55011:1990
Conformité aux normes EN 50 082-2:1995 et EN 61 000-6-2:1999
(environnement industriel)
Testé selon les normes EN 50 204:1995, EN 61000-4-2:1995, EN 61000-43:1996, EN 61000-4-4:1995, EN 61000-4-5:1995 et EN 61000-4-6:1996.
Caractéristiques de communication
Réseau « amont »
Réseau « aval »
Caractéristiques
DeviceNet
DeviceNet
Modbus RTU
• Topologie du réseau : Topologie linéaire multipoints (bus) avec terminaisons de ligne
adaptées (impédance de 121 Ω ± 1 % ¼ W).
• Média physique :
Quatre types de câbles DeviceNet spécifiques, avec alimentation
24V intégrée :
c Câble cylindrique épais à double paire torsadée e Câble plat
d Câble cylindrique fin à double paire torsadée
f Câble de type « KwikLink »
• Vitesse de communication : 125, 250 ou 500 kbits/s
• Longueur totale maximale du réseau : 500 m à 125 kbits/s
250 m à 250 kbits/s
100 m à 500 kbits/s
• Nombre maximum d’abonnés : 64
• Transactions : Jusqu’à 8 octets de données par trame.
• Possibilité de connecter ou de déconnecter un abonné sans affecter les
communications entre les autres abonnés.
93
Annexe A : Caractéristiques techniques
Spécificités DeviceNet
de la passerelle LUFP9
Caractéristiques
Modbus RTU
• La passerelle LUFP9 est un abonné DeviceNet de type « group two only server »
(reportez-vous à DeviceNet Specifications).
• Support de la fragmentation pour les transactions exigeant plus de 8 octets de
données.
• Connexions supportées : 1 connexion « Explicit Connection »
1 connexion « Polled Command/Response »
1 connexion « Bit Strobed Command/Response »
1 connexion « Change-of-State / Cyclic »
• Vitesse de communication configurée à l’aide de 2 commutateurs.
• Adresse DeviceNet (MAC ID) de la passerelle configurée à l’aide de
6 commutateurs (adresse comprise entre 0 et 63).
• Configuration facilitée par l’usage d’un fichier EDS spécifique.
• Média physique : Liaison série RS485
• Topologie du réseau : Topologie linéaire multipoints avec terminaisons de ligne
adaptées (impédance de 120 Ω en parallèle avec une capacité de 1 nF)
• Vitesse de communication : 1 200 à 57 600 bits/s
• Bits de données : 8
• Adresses des abonnés : 1 à 247. Adresse 0 réservée à la diffusion. Adresses 65,
126 et 127 réservées si des produits de la gamme Variation de Vitesse de
Schneider Electric sont utilisés sur le même réseau Modbus.
• Temps de silence : Equivalent à la transmission de 3,5 caractères.
AVERTISSEMENT
UTILISATION D’ADRESSES MODBUS RESERVEES
N’utilisez pas les adresses Modbus 65, 126 ou 127 si les esclaves Modbus d’une passerelle comportent un
système de variation de vitesse Schneider Electric, tel qu’un démarreur Altistart ou un variateur Altivar. Les
périphériques Altistart et Altivar réservent ces adresses pour d’autres communications et l’utilisation de ces
adresses dans un tel système peut avoir des conséquences imprévues.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
• Nombre maximum d’abonnés (hors passerelle) : 8 esclaves Modbus.
• Nombre maximum de commandes configurées : Jusqu’à 50 requêtes et réponses
Modbus configurées pour la même passerelle à l’aide de ABC-LUFP Config Tool.
• Vitesse de communication : 1 200, 2 400, 4 800, 9 600 ou 19 200 bits/s ;
configurée à l’aide de ABC-LUFP Config Tool.
• Temps de silence : Possibilité d’augmenter le temps de silence de la passerelle,
par pas de 10 ms, à l’aide de ABC-LUFP Config Tool.
• Parité : Aucune, paire ou impaire, configurée à l’aide de ABC-LUFP Config Tool.
• Bits de départ : 1 bit, configuration à l’aide de ABC-LUFP Config Tool.
• Bits d'arrêt : 1 ou 2 bits, configuration à l’aide de ABC-LUFP Config Tool.
2 octets pour le diagnostic des erreurs du réseau aval par la passerelle (voir
Structure de la mémoire •
de la passerelle LUFP9 :
chapitre 5 Initialisation et diagnostic de la passerelle).
•
510 octets accessibles par le maître DeviceNet sous la forme de données
d’entrée (voir Appendix Exemple d’utilisation (RSLogix 500), Zone mémoire
Entrées
des données d’entrée, pour l’utilisation par défaut de ces données d’entrée).
Spécificités
Modbus RTU de la
passerelle LUFP9
Adresses
0x0000
0x0001
0x0002
:
0x01FF
Zone des données d’entrée
Mot d’état de la passerelle
(sauf si « Control/Status Byte » = « Disabled »)
Entrées accessibles par le maître DeviceNet
510 octets
1 zone de données d’entrée
94
Annexe A : Caractéristiques techniques
Structure de la mémoire
de la passerelle LUFP9 :
Sorties
• 2 octets pour l’activation ou l’inhibition du réseau aval par la passerelle (voir
chapitre 5 Initialisation et diagnostic de la passerelle)
• 510 octets accessibles par le maître DeviceNet sous la forme de données de
sortie (voir Appendix B, Configuration par défaut, Zone mémoire des données
de sortie, pour l’utilisation par défaut de ces données de sortie).
Adresses
0x0200
0x0201
0x0202
:
0x03FF
Structure de la mémoire
de la passerelle LUFP9 :
Données
générales
Ordre de transfert des
données (swapping)
Zone des données de sortie
Mot de commande du maître DeviceNet
(sauf si « Control/Status Byte » = « Disabled »)
Sorties accessibles par le maître DeviceNet
510 octets
1 zone de données de sortie
• 960 octets inaccessibles par le maître DeviceNet.
Adresses
0x0400
0x051F
0x0520
0x063F
0x0640
.......
0x07BF
Zone des données générales
Zone d’entrée réservée aux Mailboxes
(288 octets)
Zone de sortie réservée aux Mailboxes
(288 octets)
Zone interne réservée à la gestion du réseau amont
(384 octets)
(zone d’entrée / zone de sortie / zone bidirectionnelle)
NOTE : Vous pouvez utiliser cette zone de données pour y placer les donnés
d’une réponse Modbus que vous ne souhaitez pas faire remonter jusqu’au maître
DeviceNet. Dans ce cas, utilisez toujours 0x0400 comme adresse de départ. Si
vous utilisez plusieurs fois les mêmes adresses dans cette zone, ces
emplacements apparaîtront en rouge dans la zone « General Area » de l’écran
« Sub-network Monitor » (voir exemple page 58). Cependant, cela n’aura aucune
conséquence sur le fonctionnement de la passerelle.
• Réseau DeviceNet : LSB en premier et MSB en dernier.
• Réseau Modbus RTU : MSB en premier et LSB en dernier.
• Passerelle LUFP9 : MSB stocké dans l’adresse mémoire la plus basse.
→ Dans la plupart des cas, l’option qui doit être retenue pour les données
Modbus stockées dans la mémoire de la passerelle est « Swap 2 bytes ».
Cette option concerne tous les champs « Data » des trames des requêtes et
des réponses Modbus.
95
Appendix B: Configuration par défaut
La configuration décrite ci-dessous correspond à la configuration par défaut de la passerelle LUFP9.
NOTE : Ce chapitre est principalement destiné à renseigner l’utilisateur sur les performances obtenues sur le
réseau aval Modbus. Il permet à l’utilisateur de décider s’il doit, par exemple, modifier la période des échanges
cycliques effectués avec un ou plusieurs des départs-moteurs TeSys U (voir chapitre 6 Configuration de la
passerelle).
Configuration des échanges Modbus
La passerelle LUFP9 effectue quatre types d’échanges avec chacun des 8 départs-moteurs TeSys U. Les deux
premiers échanges sont cycliques et permettent de commander et de surveiller le départ-moteur. Les deux
derniers échanges sont apériodiques (uniquement sur changement des valeurs des données à transmettre au
départ-moteur) et permettent de lire et de modifier la valeur de n’importe quel paramètre du départ-moteur.
Fonction
0x03
0x10
Fonction
Modbus
Read Holding
Registers
Preset Multiple
Registers
Nombre
d’octets (1)
11,5 + 10,5
14,5 + 11,5
(0x03)
(Read Holding
Register)
011,5 + 10,5
(0x06)
(Preset Single
Register)
11,5 + 11,5
Echange entre la passerelle LUFP9
et le départ-moteur TeSys U
Lecture périodique (période de 300 ms) du seul registre
d’état du départ-moteur TeSys U (adresse 455 = 0x01C7)
Ecriture périodique (période de 300 ms) du seul registre
d’état du départ-moteur TeSys U (adresse 704 = 0x02C0)
Lecture apériodique de la valeur d’un seul paramètre,
pour un seul départ-moteur TeSys U à la fois (fonction et
adresse fournies par l’utilisateur)
Ecriture apériodique de la valeur d’un seul paramètre,
pour un seul départ-moteur TeSys U à la fois (fonction,
adresse et valeur fournies par l’utilisateur)
(1) Nombre d’octets de la requête (Query) + nombre d’octets de la réponse (Response), avec + 3,5 caractères
de temps de silence pour chacune de ces deux trames (voir description du paramètre « Message delimiter
(10ms) » dans le chapitre 6.12.3 Elément « Sub-Network »). Chaque octet sera transmis sous la forme d’un
groupe de 10 bits (8 bits de données, 1 bit de start et 1 bit de stop). Ces valeurs permettent de calculer le
trafic approximatif sur le réseau aval Modbus de la manière suivante :
Volume du trafic périodique (période de 300 ms) ... [ ( 11,5 + 10,5 ) + ( 14,5 + 11,5 ) ] × ( 8 + 1 + 1 ) = 480 bits
Pour 1 départ-moteur TeSys U......................................................... 1 × 480 × ( 1 000 ÷ 300 ) = 01 600 bits/s
Pour 8 départs-moteurs TeSys U ..................................................... 8 × 480 × ( 1 000 ÷ 300 ) = 12 800 bits/s
Par conséquent, sur un réseau fonctionnant à 9 600 bits/s, il sera nécessaire d’augmenter de manière
importante le temps de cycle de tout ou partie des commandes Modbus périodiques. En revanche, à la
vitesse de 19 200 bits/s (vitesse par défaut), la réserve de la bande passante est suffisante pour assurer
des communications correctes, même en cas de mode dégradé occasionnel (répétitions de trames par
ré-émission), et pour permettre l’utilisation des échanges apériodiques de paramétrage.
96
Annexe B : Configuration par défaut
Contenu de la mémoire DPRAM de la passerelle
La mémoire DPRAM de la passerelle LUFP9 contient toutes les données échangées entre la passerelle et les
8 départs-moteurs TeSys U, ainsi que deux registres spéciaux uniquement échangés entre la passerelle et le
maître DeviceNet (mots utiles à la gestion du réseau aval Modbus).
Le flux des données échangées entre les départs-moteurs TeSys U, la passerelle et le maître DeviceNet est
schématisé ci-dessous, afin de représenter l’implication de la mémoire de la passerelle dans ces échanges :
Départs-moteurs TeSys U
Passerelle LUFP9
Sorties
Zone mémoire des
données d'ENTREE
Modbus
c d
e
j
Entrées
Maître DeviceNet (SLC500)
Sorties
DeviceNet
Zone mémoire des
données de SORTIE
Entrées
Zone mémoire des données d’entrée
La passerelle dispose de 512 octets d’entrée. Seuls les 32 premiers octets sont utilisés. L’ensemble de ces
32 octets forme la zone d’entrée de la passerelle, référencée « Input 1 » dans le configurateur RSNetWorx.
Service
Adresse
Taille
Description
Gestion du réseau aval Modbus
0x0000
1 mot
Mot d’état de la passerelle
0x0002
1 mot
Valeur du registre d’état du départ-moteur c
0x0004
1 mot
Valeur du registre d’état du départ-moteur d
0x0006
1 mot
Valeur du registre d’état du départ-moteur e
0x0008
1 mot
Valeur du registre d’état du départ-moteur f
0x000A
1 mot
Valeur du registre d’état du départ-moteur g
0x000C
1 mot
Valeur du registre d’état du départ-moteur h
0x000E
1 mot
Valeur du registre d’état du départ-moteur i
0x0010
1 mot
Valeur du registre d’état du départ-moteur j
——
0x0012
1 octet
Emplacement mémoire libre
Communications apériodiques
—
Lecture de la valeur d’un
paramètre de départ-moteur
(REPONSE)
0x0013
1 octet
N° esclave (0x01 à 0x08)
0x0014
1 octet
N° fonction (0x03)
0x0015
1 octet
Nombre d’octets lus (0x02)
0x0016
1 mot
Valeur du paramètre lu (0xxxxx)
Communications apériodiques
—
Ecriture de la valeur d’un
paramètre de départ-moteur
(REPONSE)
0x0018
1 octet
N° esclave (0x01 à 0x08)
0x0019
1 octet
N° fonction (0x06)
0x001A
1 mot
Adresse du paramètre écrit (0xxxxx)
0x001C
1 mot
Valeur du paramètre écrit (0xxxxx)
0x001E
1 octet
Compteur de réponse de la lecture d’un
paramètre
0x001F
1 octet
Compteur de réponse de l’écriture d’un
paramètre
0x0020
…
0x01FF
1 octet
…
1 octet
Zone d’entrée libre
(480 octets)
Communications périodiques
—
Surveillance des
départs-moteurs TeSys U
Communications apériodiques
(« Trigger bytes » des réponses)
——
97
Annexe B : Configuration par défaut
Zone mémoire des données de sortie
La passerelle dispose de 512 octets de sortie. Seuls les 32 premiers octets sont utilisés. L’ensemble de ces
32 octets forment la zone de sortie de la passerelle, référencée « Output 1 » dans le configurateur RSNetWorx.
Service
Adresse
Taille
Description
Gestion du réseau aval Modbus
0x0200
1 mot
Mot de commande du maître DeviceNet
0x0202
1 mot
0x0204
1 mot
Valeur du registre de commande du départmoteur c
Valeur du registre de commande du départ-moteur d
0x0206
1 mot
Valeur du registre de commande du départ-moteur e
0x0208
1 mot
Valeur du registre de commande du départ-moteur f
0x020A
1 mot
Valeur du registre de commande du départ-moteur g
0x020C
1 mot
Valeur du registre de commande du départ-moteur h
0x020E
1 mot
Valeur du registre de commande du départ-moteur i
0x0210
1 mot
Valeur du registre de commande du départ-moteur j
Communications apériodiques
—
Lecture de la valeur d’un
paramètre de départ-moteur
(REQUETE)
0x0212
1 octet
N° esclave (0x01 à 0x08)
0x0213
1 octet
Numéro de la fonction (0x03)
0x0214
1 mot
Adresse du paramètre à lire (0xxxxx)
0x0216
1 mot
Nombre de paramètres à lire (0x0001)
Communications apériodiques
—
Ecriture de la valeur d’un
paramètre de départ-moteur
(REQUETE)
0x0218
1 octet
N° esclave (0x01 à 0x08)
0x0219
1 octet
Numéro de la fonction (0x06)
0x021A
1 mot
Adresse du paramètre à écrire (0xxxxx)
0x021C
1 mot
Valeur du paramètre à écrire (0xxxxx)
Communications apériodiques
(« Trigger bytes » des requêtes)
0x021E
1 octet
Compteur de requête de la lecture d’un
paramètre
0x021F
1 octet
Compteur de requête de l’écriture d’un paramètre
0x0220
…
0x03FF
1 octet
…
1 octet
Zone de sortie libre
(480 octets)
Communications périodiques
—
Commande des
départs-moteurs TeSys U
——
Nombre total de requêtes et de réponses Modbus
Le nombre total de requêtes et de réponses Modbus est égal à 36 (2 requêtes et 2 réponses périodiques
pour chacun des 8 départs-moteurs TeSys U, plus 2 requêtes et 2 réponses apériodiques pour l’ensemble de
ces départs-moteurs). Puisque le nombre total de requêtes et de réponses Modbus qu’il est possible de
configurer pour une seule et même passerelle est limité à 50, il ne reste donc plus qu’une réserve de
14 requêtes et réponses Modbus (c’est-à-dire l’équivalent de 7 commandes Modbus).
Cette réserve ne permet donc pas d’ajouter une même commande Modbus pour chacun des départs-moteurs
TeSys U, puisque cet ajout nécessiterait l’utilisation de 16 requêtes et réponses Modbus (1 requête et 1 réponse
pour chacun des 8 départs-moteurs).
98
Appendix C: Exemple d’utilisation (RSLogix 500)
NOTE : Cette annexe est réservée aux utilisateurs possédant une bonne connaissance des produits Rockwell
Automation RSNetWorx et RSLogix 500.
Un exemple d’utilisation est disponible sur le CD LU9CD1. Il est composé de deux fichiers. Le premier de ces
fichiers, nommé « SLC_Guide_LUFP9.dnt », présente la configuration du scanner DeviceNet sous
RSNetWorx, décrit dans les chapitres précédents. Le second, nommé « » SLC_Guide_LUFP9_EN.rss », est
un fichier RSLogix 500 file et constitue donc l'exemple en lui-même.
La configuration du fichier RSNetWorx correspondant exactement à ce qui est décrit dans les chapitres
précédents, son contenu ne sera pas repris ici. En revanche, le fichier RSLogix 500 est décrit ci-après, en se
basant sur la structure des sous-programmes utilisés.
Programme principal : « LAD 2 - MAIN_LUFP9 »
Le rôle du programme principal consiste à activer les communications DeviceNet et Modbus, ainsi qu’à appeler
les autres sous-programmes, décrits dans les chapitres suivants. Les processus effectués dans le programme
principal sont décrits ci-dessous, dans l’ordre de leur exécution :
• Validation des échanges DeviceNet du scanner par activation du bit O:1.0/0.
• Activation des communications Modbus de la passerelle à l’aide des bits 13 (FB_DU) et 14 (FB_HS_SEND)
du mot de commande du maître DeviceNet. Ces deux bits correspondent aux bits O:1.1/5 et O:1.1/6 du
scanner DeviceNet.
NOTE : Ce processus n’est utile qu’à la condition que l’option « Control/Status Byte » soit définie sur
« Enabled ». Dans le cas de la configuration par défaut de la passerelle LUFP9 (« Control/Status Byte » =
« Enabled but no startup lock »), ce processus est inutile mais peut tout de même être conservé. Enfin, cet
exemple ne doit pas être utilisé lorsque cette option est définie sur « Disabled », car les mots I:1.1 et O:1.1
ne sont plus réservés à la « gestion du réseau aval Modbus ». Reportez-vous au chapitre 5 Initialisation et
diagnostic de la passerelle, pour de plus amples informations à ce sujet.
• Acquittement automatique des diagnostics de la passerelle par le maître DeviceNet. Il suffit de recopier la
valeur du bit 15 (ABC_HS_SEND) du mot d’état de la passerelle dans le bit 15 (FB_HS_CONFIRM) du mot
de commande du maître DeviceNet (voir chapitre 5 Initialisation et diagnostic de la passerelle). Cet
acquittement automatique permet surtout de ne pas bloquer le mécanisme de remontée des diagnostics de
la passerelle au maître DeviceNet.
• Commande/surveillance du départ-moteur « TeSys U n°1 » par utilisation du sous-programme U:3, c’est-àdire le sous-programme « LAD 3 - CMD_SURV ». Ce sous-programme utilise des variables locales en tant
que paramètres. Le mot N7:0 est utilisé pour indexer le registre de sortie et le registre d’entrée, utilisés pour
effectuer la commande et la surveillance du départ-moteur « TeSys U n°1 ». Avant l’appel du sousprogramme, la valeur de ce mot est donc fixée à 2 afin d’accéder aux mots O:1.2 et I:1.2. N7:0 est
également utilisé pour indexer l’un des bits de chacun des registres N7:32, 33, 34 et 35 (registres
manipulés par l’utilisateur).
• Commande/surveillance du départ-moteur « TeSys U n°2 » : Idem, mais en fixant la valeur de N7:0 à 3
(O:1.3 et I:1.3).
• Commande/surveillance du départ-moteur « TeSys U n°3 » : Idem, mais en fixant la valeur de N7:0 à 4
(O:1.4 et I:1.4).
• Commande/surveillance du départ-moteur « TeSys U n°4 » : Idem, mais en fixant la valeur de N7:0 à 5
(O:1.5 et I:1.5).
• Commande/surveillance du départ-moteur « TeSys U n°5 » : Idem, mais en fixant la valeur de N7:0 à 6
(O:1.6 et I:1.6).
• Commande/surveillance du départ-moteur « TeSys U n°6 » : Idem, mais en fixant la valeur de N7:0 à 7
(O:1.7 et I:1.7).
99
Annexe C : Exemple d’utilisation (RSLogix 500)
• Commande/surveillance du départ-moteur « TeSys U n°7 » : Idem, mais en fixant la valeur de N7:0 à 8
(O:1.8 et I:1.8).
• Commande/surveillance du départ-moteur « TeSys U n°8 » : Idem, mais en fixant la valeur de N7:0 à 9
(O:1.9 et I:1.9).
• Lecture de la valeur d’un même paramètre sur l’ensemble des départs-moteurs TeSys U, par utilisation du
sous-programme U:4, c’est-à-dire le sous-programme « LAD 4 - LECT_PAR ».
• Ecriture de la valeur d’un paramètre dans un seul départ-moteur TeSys U à la fois, par utilisation du sousprogramme U:5, c’est-à-dire le sous-programme « LAD 5 - LECT_PAR ».
• Mise à jour de la sortie O:1.16 à l’aide des deux compteurs N7:36 et N7:37. Cette sortie contient les deux
« Trigger bytes » utilisés pour provoquer l’émission de la requête de lecture d’un paramètre (LSB) et la
requête d’écriture d’un paramètre (MSB). Ces deux compteurs sont mis à jour de manière indépendante
dans les sous-programmes « LAD 4 – RD_PAR », pour N7:36, et « LAD 5 – WR_PAR », pour N7:37.
NOTE : La lecture d’un paramètre sur tous les départs-moteurs et l’écriture d’un paramètre sur l’un d’entre eux
peuvent être effectuées en parallèle, car ces services utilisent des commandes Modbus différentes.
Les différentes données utilisées par le programme principal sont rassemblées dans le tableau suivant :
Adresse
Symbole
I:1.1/07 → I:1/23
ABC_HS_SEND
O:1.0/00 → O:1/00
VALIDATION_DU_SCA
N
O:1.1/05 → O:1/21
FB_DU
O:1.1/06 → O:1/22
FB_HS_SEND
O:1.1/07 → O:1/23
FB_HS_CONFIRM
N7:0
O:1.16
N7:36
N7:37
Description
Bascule indiquant la présence d’un nouveau diagnostic de la passerelle
Validation des communications DeviceNet : ce bit doit être à 1 pour valider
les échanges
Activation des communications Modbus par la passerelle
Bascule indiquant à la passerelle la présence d’une nouvelle commande
Bit d’acquittement des diagnostics de la passerelle par le maître DeviceNet
Paramètre d’accès (index) au départ-moteur (appelé « module » pour
simplifier)
TRIGGER_OUT_RD_W « Trigger bytes" provoquant l’émission de la commande de lecture (LSB) ou
R
d’écriture (MSB) d’un paramètre
Compteur local pour le "trigger byte" de la requête de lecture d’un
————
paramètre
————
Compteur local pour le "trigger byte" de la requête d’écriture d’un paramètre
MODULE
Sous-programme de commande/surveillance d’un départ-moteur TeSys U :
« LAD 3 - CMD_SURV »
Le rôle de ce sous-programme consiste à effectuer une commande très simple sur l’un des départs-moteurs
TeSys U, en fonction de son état actuel et des commandes de l’utilisateur. Les processus effectués dans ce
sous-programme sont décrits ci-dessous, dans l’ordre de leur exécution :
• Commande du moteur en marche avant / marche arrière / arrêt. Le registre N7:0 est utilisé en guise de
paramètre. Il contient le numéro du mot d’entrée et du mot de sortie à utiliser pour commander et pour
surveiller le départ-moteur TeSys U. Ce même numéro sert à indexer le bit à prendre en compte dans les
registres N7:32 à N7:35. Le mot d’entrée utilisé est compris entre I:1.2 et I:1.9 (départs-moteurs n°1 à 8), et
le mot de sortie utilisé est compris entre O:1.2 et O:1.9 (idem). La valeur de N7:0 doit donc être comprise
entre 2 et 9, selon le numéro du départ-moteur commandé.
L’utilisateur pilote le mode de marche du départ-moteur à l’aide des bits 2 à 9 (départs-moteurs n°1 à 8)
des registres N7:32 ( Run (1) / Stop (0) ) et N7:33 ( Marche Avant (0) / Marche Arrière (1) ).
100
Annexe C : Exemple d’utilisation (RSLogix 500)
Les commandes de marche avant, de marche arrière et d’arrêt du départ-moteur TeSys U sont effectuées aux
conditions suivantes :
ƒ Bit 14 du mot d’état d’un TeSys U = 0 ..... Le départ-moteur n’est pas en mode local.
ƒ Bit 2 du mot d’état d’un TeSys U = 0 ....... Le départ-moteur n’est pas en défaut.
ƒ Bit 0 ou 1 du mot d’état d’un TeSys U = 1 Le départ-moteur est en état « Ready » ou « Switched on ».
Lorsque ces conditions sont toutes rassemblées, les registres N7:32 et N7:33 (bit 2 à 9, selon la valeur de N7:0)
sont utilisés pour commander soit la marche avant / marche arrière du départ-moteur, soit son arrêt par
freinage. Ces deux registres sont mis à jour bit à bit par l’utilisateur, en fonction des commandes qu’il souhaite
effectuer.
• Remise à zéro des défauts du départ-moteur TeSys U. Le registre N7:0 est utilisé de la même manière que
ci-dessus et les mots d’entrée et de sortie sont les mêmes que pour la commande du départ-moteur.
Lorsqu’un défaut est présent sur le départ-moteur (bit 2 du registre de surveillance égal à 1), ce défaut est
recopié dans l’un des bits 2 à 9 (un bit par départ-moteur) du registre N7:34 (Présence Défaut (1) / Départmoteur OK (0) ), simplement pour faire figurer cet état de manière conjointe à la commande utilisateur qui
permet de remettre à zéro les défauts du départ-moteur. Cette commande utilisateur correspond à l’un des
bits 2 à 9 du registre N7:35 ( RAZ défaut (1) ) et sert à activer le bit 3 du registre de commande du départmoteur TeSys U correspondant (bit de « Reset »), c’est-à-dire le bit O:1.[N7:0]/3.
Cette commande de remise à zéro des défauts par l’utilisateur est ensuite annulée par programme lorsque
le départ-moteur TeSys U ne signale plus la présence d’un défaut.
101
Annexe C : Exemple d’utilisation (RSLogix 500)
Les différentes données utilisées par ce sous-programme sont rassemblées dans le tableau suivant :
Adresse
I:1.[N7:0]/00
I:1.[N7:0]/01
I:1.[N7:0]/02
Symbole
—
—
—
I:1.[N7:0]/14
N7:32/[N7:0]
N7:33/[N7:0]
N7:34/[N7:0]
N7:35/[N7:0]
O:1.[N7:0]/00
O:1.[N7:0]/01
O:1.[N7:0]/02
O:1.[N7:0]/03
N7:0
Description
Bit 00 « Ready » du registre d’état du TeSys U
Bit 01 « On » du registre d’état du TeSys U
Bit 02 « Fault » du registre d’état du TeSys U
Bit 14 « Reserved : Local control » du registre d’état du
—
départ-moteur TeSys U
Commande utilisateur : Marche (1) / Arrêt (0) sur le départCMD_RUN [ MODULE ]
moteur dont le numéro est défini sur N7:0
Commande utilisateur : Avant (0) / Arrière (1) sur le départCMD_REVERSE [ MODULE ]
moteur dont le numéro est défini sur N7:0
SURV_FAULTY_DEV
Surveillance utilisateur : Présence (1) / Absence (0) d'un
[ MODULE ]
défaut sur le départ-moteur dont le numéro est défini sur N7:0
Commande utilisateur : RAZ défaut (1) sur le départ-moteur
CMD_RESET [ MODULE ]
repéré à l’aide de l’index N7:0
Bit 0 « Reserved : Run Forward » du registre de commande du
—
TeSys U repéré à l’aide de l’index N7:0
Bit 1 « Reserved : Run Reverse » du registre de commande du
—
TeSys U repéré à l’aide de l’index N7:0
Bit 2 « Reserved (stopping) » du registre de commande du
—
TeSys U repéré à l’aide de l’index N7:0
Bit 3 « Reset » du registre de commande du TeSys U repéré
—
à l’aide de l’index N7:0
Paramètre d’accès au départ-moteur (index compris entre 2
MODULE
et 9, pour les départs-moteurs TeSys U n°1 à n°8)
L’exemple comporte un écran de surveillance des données personnalisé, appelé « CDM 0 - CMD_SURV », afin
de simplifier l’utilisation de cet exemple. Le contenu de cet écran est reproduit ci-dessous :
Adresse
O:1/00
O:1/21
O:1/22
N7:0
N7:32
N7:33
N7:34
N7:35
I:1.2
O:1.2
I:1.3
O:1.3
Symbole
VALIDATION_DU_SCAN
FB_DU
FB_HS_SEND
MODULE
CMD_RUN
CMD_REVERSE
SURV_FAULTY_DEV
CMD_RESET
SURV_TESYS_U_1
CMD_TESYS_U_1
SURV_TESYS_U_2
CMD_TESYS_U_2
Affichage
Binaire
Binaire
Binaire
Décimal
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Adresse
I:1.4
O:1.4
I:1.5
O:1.5
I:1.6
O:1.6
I:1.7
O:1.7
I:1.8
O:1.8
I:1.9
O:1.9
Symbole
SURV_TESYS_U_3
CMD_TESYS_U_3
SURV_TESYS_U_4
CMD_TESYS_U_4
SURV_TESYS_U_5
CMD_TESYS_U_5
SURV_TESYS_U_6
CMD_TESYS_U_6
SURV_TESYS_U_7
CMD_TESYS_U_7
SURV_TESYS_U_8
CMD_TESYS_U_8
Affichage
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
Binaire
102
Annexe C : Exemple d’utilisation (RSLogix 500)
Sous-programme de lecture d’un paramètre dans tous les départs-moteurs
TeSys U : « LAD 4 - LECT_PAR »
Le rôle de ce sous-programme consiste à effectuer la lecture de la valeur d’un seul et même paramètre pour
l’ensemble des départs-moteurs TeSys U. Les résultats sont placés, au fur et à mesure de la lecture, dans un
tableau commençant en N7:4 (départ-moteur n°1) et s’achevant en N7:11 (départ-moteur n°8). L’index N7:2 est
utilisé pour avoir accès à ces différentes adresses. Les processus effectués dans ce sous-programme sont
décrits ci-dessous, dans l’ordre de leur exécution :
• La modification par l’utilisateur du numéro (ou adresse) du paramètre à lire (N7:1) provoque l’initialisation des
•
•
•
•
•
données utilisées par le sous-programme, mais uniquement si le processus de lecture précédent est achevé
(B3:0/0 = 0). La comparaison entre N7:1 (nouvelle adresse) et O:1.11 (adresse dans la dernière commande
utilisée) est effectuée au travers d’une variable de travail, N9:0, dans laquelle l’inversion entre le LSB et le MSB
de la nouvelle adresse est effectuée. Les initialisations sont résumées ci-dessous :
ƒ B3:0/0 = 1 ...............Lecture d’un paramètre sur tous les départs-moteurs TeSys U : En cours de réalisation.
ƒ Reset (C5:0) ...........Réinitialisation du compteur du nombre de départs-moteurs interrogés.
ƒ Reset (T4:0)............Réinitialisation de la temporisation associée au timeout d’attente d’une réponse de
lecture d’un paramètre.
ƒ N7:2 = 4 .................Indice dans le tableau des résultats → N° du 1er élément du tableau = N7:4.
ƒ N7:3 = 1 .................Adresse de l’esclave Modbus interrogé → Adresse du premier départ-moteur TeSys U,
c’est-à-dire 1.
ƒ N7:[4..11] = 0..........RAZ du contenu du tableau des résultats.
ƒ B3:0/5 = 0 ...............Autorisation de mise à jour du compteur / « trigger byte » provoquant l’émission de la
requête.
Mise à jour des données de sortie qui correspondent à la requête de lecture (O:1.10 à O:1.12), incrémentation du
compteur N7:36 (« trigger byte »). Cette mise à jour n’est effectuée qu’une seule fois (utilisation du bit B3:0/5
dans ce but). Rappel : Dans la configuration par défaut de la passerelle LUFP9, ces données de sortie
correspondent aux données de la commande Modbus personnalisée « Transactions 1 » du nœud « TeSys U
n°1 ». La trame de la requête de cette commande personnalisée est envoyée sur changement de la valeur du
« trigger byte » situé dans les bits 0-7 du mot 0:1.16 (« Update mode » = « Change of state on trigger »). Par
conséquent, l’incrémentation du compteur N7:36, puis la mise à jour de O:1.16 à l’aide de N7:36 (dans « LAD 2 –
MAIN_LUFP9 »), provoque l’envoi de cette requête. L’ensemble des données de sortie O:1.10 à O:1.12 doivent
être correctes pour que le contenu de la requête Modbus soit cohérent !
Vérification des données de la réponse Modbus qui correspond à cette commande de lecture. Les valeurs des
entrées I:1.10 et I:1.11 sont comparées à celles de la sortie O:1.10 et de la valeur 0x02xx (masque ET égal à
0#FF00) afin de déterminer si la réponse à la commande est arrivée ou non. Si le numéro de l’esclave et le
numéro de la fonction correspondent à ceux de la requête (voir ci-dessus) et si le nombre d’octets de données
reçus est correct, le bit B3:0/1 est activé pour signaler au reste du sous-programme que la réponse est arrivée et
qu’elle est correcte. La variable temporaire N9:0 est utilisée pour permettre de comparer les entrées et les sorties
sous un même format.
Recopie de la valeur du paramètre lu dans le tableau des résultats. La valeur de I:1.12 est donc transférée à
l’emplacement qui est réservé au résultat du départ-moteur actuellement interrogé (utilisation de l’index N7:2). Ce
transfert n’a lieu qu’à la condition que la réponse soit arrivée et que son contenu soit correct (bit B3:0/1 actif). Le
LSB et le MSB de cette valeur sont ensuite permutés dans ce tableau afin de rétablir la valeur du paramètre lu.
La temporisation du timeout d’attente de la réponse (T4:0) est réinitialisée pour préparer le processus de la
lecture du même paramètre sur le départ-moteur suivant.
Gestion du timeout d’attente de la réponse (bloc TON sur la variable T4:0). Tant que la réponse n’est pas arrivée
ou que son contenu est incorrect (bit B3:0/1 = 0), une temporisation de 3 secondes est activée. Sur
déclenchement de ce timeout (T4:0/DN = 1), la temporisation associée est réinitialisée et un résultat égal à –1 est
placé dans le tableau des résultats, à l’emplacement normalement réservé au départ-moteur interrogé.
Sur réception de la réponse, ou suite au déclenchement du timeout, les données internes au sous-programme
sont mises à jour pour permettre la lecture du même paramètre sur le départ-moteur suivant, et ce jusqu’au
dernier départ-moteur, pour un total de 8 départs-moteurs (adresses 1 à 8). Le compteur C5:0 est utilisé pour
compter le nombre de départs-moteurs ayant été interrogés jusqu’à présent.
• Lorsque la lecture du 8ème départ-moteur est achevée (compteur C5:0 atteignant sa valeur de présélection), le
processus de lecture est stoppé (RAZ du bit B3:0/0). En revanche, tant que la lecture du paramètre du 8ème
départ-moteur n’est pas achevée, le sous-programme recommence depuis le début au cycle automate suivant
(passage au départ-moteur suivant ou poursuite de l’attente de la réponse pour le départ-moteur actuellement
interrogé).
103
Annexe C : Exemple d’utilisation (RSLogix 500)
Les différentes données utilisées par ce sous-programme sont rassemblées dans le tableau suivant :
Adresse
Symbole
Description
B3.0/0
LECT_RUNNING
Lecture d’un paramètre dans tous les départs-moteurs TeSys U : En cours
Lecture d’un paramètre dans tous les départs-moteurs TeSys U : Lecture
B3.0/1
LECT_OK_KO
correcte (OK) ou incorrecte (KO) pour un départ-moteur (si la réponse est
arrivée ou sur déclenchement du timeout T4:0)
Mise à jour du « trigger byte » d’émission effectuée : Oui (1) / Non (0)
Lecture d’un paramètre dans les départs-moteurs TeSys U : Compteur.
C5:0
CPT_LECT_TESYS_U
Lorsque la valeur de ce compteur parvient à 9, le processus de lecture d’un
paramètre sur l’ensemble des départs-moteurs TeSys U est arrêté.
Résultat de la lecture d’un paramètre : Esclave (0x01 à 0x08) en MSB. La
CR_RDPAR_XXX_SLAV
I:1.10
valeur de ce champ est comparée à celle du champ correspondant dans la
E
trame de la requête. Le LSB de ce mot d’entrée n’est pas utilisé.
Résultat de la lecture d’un paramètre : Fonction (toujours 0x03) en LSB (la valeur
CR_RDPAR_FCT_BYTE
I:1.11
de ce champ est comparée à celle du champ correspondant dans la trame de la
S
requête) + Nombre d’octets lus (0x02) en MSB (valeur masquée et vérifiée).
Résultat de la lecture d’un paramètre : Valeur du paramètre lu (MSB et LSB
I:1.12
CR_RDPAR_VALUE
inversés). Cette valeur est placée dans le tableau N7:[N7:2], puis son MSB et
son LSB y sont permutés afin de rétablir la valeur correcte du paramètre lu.
N7:1
NUMPARAM
Commande utilisateur : Numéro du paramètre lu.
Indice dans le tableau des résultats de la lecture d’un paramètre TeSys U.
N7:2
LECT_INDEX
Valeur = 4 à 11 (départs-moteurs n°1 à 8).
Adresse de l’esclave Modbus dont l’un des paramètres est en cours de lecture.
N7:3
ADRESSE
Valeur = 1 à 8.
Tableau des résultats de la lecture d’un paramètre TeSys U (départs-moteurs
N7:[N7:2]
— [ LECT_INDEX ]
n°1 à 8). Eléments N7:4 à N7:11 (voir N7:2). Valeur = –1 en cas d’erreur (timeout
de l’attente de la réponse).
N7:36
————
Compteur local correspondant au « trigger byte » de la requête d’écriture.
N9:0
VAR_EPHEMERE_1
Variable temporaire de travail servant à effectuer des calculs intermédiaires.
Demande de lecture d’un paramètre : Esclave (de 0x01 à 0x08) en LSB +
O:1.10
RDPAR_SLAVE_FCT
Fonction (toujours 0x03) en MSB.
Demande de lecture d’un paramètre : Adresse du paramètre (recopie de N7:1,
O:1.11
RDPAR_ADRPAR
avec permutation du LSB et du MSB).
Demande de lecture d’un paramètre : Nombre de paramètres à lire (toujours
O:1.12
RDPAR_NBPARS
0x0001, mais avec inversion du MSB et du LSB, c’est-à-dire 0x0100).
T4:0
TIMEOUT_LECT_PARAM Temporisation du timeout de la lecture d’un paramètre (3 secondes)
B3:0/5
————
L’exemple comporte un écran de surveillance personnalisée des données, appelé « CDM 1 - LECT_PAR », afin
d’en simplifier l’utilisation. Le contenu de cet écran est reproduit ci-dessous :
Adresse
N7:1
Symbole
NUMPARAM
Affichage
Décimal
B3:0/0
B3:0/1
N7:2
N7:3
N7:4
N7:5
N7:6
N7:7
N7:8
N7:9
LECT_RUNNING
LECT_OK_KO
LECT_INDEX
ADRESSE
PARLU1
PARLU2
PARLU3
PARLU4
PARLU5
PARLU6
Binaire
Binaire
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Adresse
N7:10
N7:11
O:1.10
O:1.11
O:1.12
I:1.10
I:1.11
I:1.12
I:1.16
O:1.16
N7:36
B3:0/5
Symbole
PARLU7
PARLU8
RDPAR_SLAVE_FCT
RDPAR_ADRPAR
RDPAR_NBPARS
CR_RDPAR_XXX_SLAVE
CR_RDPAR_FCT_BYTES
CR_RDPAR_VALUE
TRIGGER_IN_RD_WR
TRIGGER_OUT_RD_WR
————
————
Affichage
Décimal
Décimal
Hexadécimal
Décimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Binaire
104
Annexe C : Exemple d’utilisation (RSLogix 500)
Sous-programme d’écriture d’un paramètre dans un seul départ-moteur
TeSys U : « LAD 5 - ECRIT_PAR »
Le rôle de ce sous-programme consiste à effectuer l’écriture de la valeur d’un paramètre dans un seul départmoteur TeSys U. L’utilisateur doit procéder à la saisie de l’adresse du départ-moteur TeSys U (N7:12), de
l’adresse du paramètre (N7:13) et de la valeur à affecter au paramètre (N7:14). Enfin, il doit activer le bit B3:0/2
pour activer le processus d’écriture. Ce bit est automatiquement remis à zéro par le sous-programme LAD 5.
Lorsque le processus d’écriture s’achève, le résultat de l’écriture (adresse du paramètre et valeur du paramètre)
est placé dans un tableau commençant en N7:16 (pour le départ-moteur n°1) et s’achevant en N7:31 (pour le
départ-moteur n°8), en utilisant la variable N7:15 comme index. Deux cases successives de ce tableau sont
utilisées pour chaque départ-moteur : la première reçoit l’adresse du paramètre et la deuxième reçoit sa valeur.
Les processus effectués dans ce sous-programme sont décrits ci-dessous, dans l’ordre de leur exécution :
• Mise en attente du sous-programme. Tant que l’utilisateur n’a pas activé le bit B3:0/2, le reste du sousprogramme n’est pas exécuté. Cela permet à l’utilisateur de saisir les valeurs des données N7:12, 13 et 14
les unes après les autres.
• Initialisation des données que le sous-programme utilise par la suite, mais uniquement si le processus
d’écriture précédent est achevé (B3:0/3 = 0). Ces initialisations sont résumées ci-dessous :
ƒ
B3:0/2 = 0............................. Commande utilisateur : RAZ de la commande d’écriture d’un paramètre
dans un départ-moteur TeSys U.
ƒ
B3:0/3 = 1.............................Ecriture d’un paramètre dans un départ-moteur TeSys U : En cours de
réalisation.
ƒ
Reset (T4:1) .........................RAZ de la temporisation associée au timeout d’attente d’une réponse
d’écriture d’un paramètre.
ƒ
N7:15 = (N7:12 × 2) + 14 .....Indice dans le tableau des résultats.
ƒ
N7:[N7:15] = { 0 ; 0 } ............RAZ du contenu du tableau des résultats, mais uniquement pour le
départ-moteur concerné par la requête d’écriture (deux octets successifs).
ƒ
B3:0/6 = 0.............................Autorisation de mise à jour du compteur / « trigger byte » provoquant l’émission
de la requête.
• Mise à jour des données de sortie qui correspondent à la requête d’écriture (O:1.13 à O:1.15),
incrémentation du compteur N7:37 (« trigger byte »). Cette mise à jour n’est effectuée qu’une seule fois
(utilisation du bit B3:0/6 dans ce but). Rappel : Dans la configuration par défaut de la passerelle LUFP9, ces
données de sortie correspondent aux données de la commande Modbus personnalisée « Transactions 2 » du
nœud « TeSys U n°1 ». La trame de la requête de cette commande personnalisée est envoyée sur
changement de la valeur du « trigger byte » situé dans les bits 8-15 du mot 0:1.16 (« Update mode »
= « Change of state on trigger »). Par conséquent, l’incrémentation du compteur N7:37, puis la mise à jour
de O:1.16 à l’aide de N7:37 (dans « LAD 2 – MAIN_LUFP9 »), provoque l’envoi de cette requête.
L’ensemble des données de sortie O:1.13 à O:1.15 doivent être correctes pour que le contenu de la
requête Modbus soit cohérent ! Le LSB et le MSB des sorties O:1.14 et O:1.15 doivent être permutés. La
variable temporaire N9:0 est utilisée pour effectuer cette inversion entre les variables N7:13 et N7:14 et les
sorties O:1.14 et O:1.15.
• Vérification des données de la réponse Modbus qui correspond à cette commande d’écriture. Les valeurs
des entrées I:1.13 à I:1.15 sont comparées à celles des sorties O:1.13 à O:1.15 afin de déterminer si la
réponse à la commande est arrivée ou non. Si le numéro de l’esclave, le numéro de la fonction, l’adresse
du paramètre et sa valeur correspondent à ceux de la requête (voir ci-dessus), et si le nombre d’octets de
données reçus est correct, le bit B3:0/4 est activé pour signaler au reste du sous-programme que la
réponse est arrivée et qu’elle est correcte.
• Recopie de l’adresse et de la valeur du paramètre dans le tableau des résultats. Cette recopie est effectuée
dans deux emplacements successifs du tableau (indexation effectuée à l’aide de N7:15), réservés au
départ-moteur actuellement interrogé, et n’a lieu qu’à la condition que la réponse soit arrivée et que son
contenu soit correct (bit B3:0/4 actif). Le LSB et le MSB de chacune de ces deux données sont ensuite
permutés afin de rétablir sa valeur correcte. La temporisation du timeout d’attente de la réponse (T4:1) est
réinitialisée pour préparer une future commande d’écriture. Le bit B3:0/3 est remis à zéro pour signaler que
la commande est achevée, évitant ainsi au reste du sous-programme d’être exécuté.
105
Annexe C : Exemple d’utilisation (RSLogix 500)
• Gestion du timeout d’attente de la réponse (T4:1). Tant que la réponse n’est pas arrivée ou que son contenu
est incorrect (bit B3:0/4 = 0), une temporisation de 3 secondes est activée. Sur déclenchement de ce timeout
(T4:1/DN = 1), la temporisation est réinitialisée, l’adresse du paramètre (O:1.14, après inversion LSB / MSB
via la variable de travail N9:0) et une valeur erronée (N9:1 = –1) sont placées dans le tableau des résultats.
Cette copie est effectuée dans deux emplacements successifs du tableau, réservés au départ-moteur
actuellement interrogé. Enfin, le processus d’écriture est stoppé (RAZ du bit B3:0/3).
Les différentes données utilisées par ce sous-programme sont rassemblées dans le tableau suivant :
Adresse
Symbole
B3:0/2
ECRIT_COMMANDE
B3.0/3
ECRIT_RUNNING
B3.0/4
ECRIT_OK
B3.0/6
————
I:1.13
CR_WRPAR_SLAVE_F
CT
I:1.14
CR_WRPAR_ADRPAR
I:1.15
CR_WRPAR_VALUE
N7:12
ECRIT_ESCLAVE
N7:13
ECRIT_ADRESSE
N7:14
ECRIT_VALEUR
N7:15
ECRIT_INDEX
N7:[N7:15]
— [ ECRIT_INDEX ]
N7:37
N9:0
N9:1
————
VAR_EPHEMERE_1
VAR_EPHEMERE_2
O:1.13
WRPAR_SLAVE_FCT
O:1.14
WRPAR_ADRPAR
O:1.15
WRPAR_VALUE
Description
Commande utilisateur : Ecriture d’un paramètre dans un départ-moteur
TeSys U : l’activation de ce bit est effectuée par l’utilisateur et sa remise à
zéro est effectuée par le programme.
Ecriture d’un paramètre dans un départ-moteur TeSys U : En cours
Ecriture d’un paramètre dans un départ-moteur TeSys U : Ecriture OK
(si la réponse est arrivée et qu’elle est correcte)
Mise à jour du « trigger byte » d’émission effectuée : Oui (1) / Non (0)
Résultat de l’écriture de la valeur d’un paramètre : Esclave (de 0x01 à 0x08)
en LSB + Fonction (toujours 0x06) en MSB. Les valeurs de ces champs sont
comparées à celles de la requête.
Résultat de l’écriture de la valeur d’un paramètre : Adresse du paramètre.
La valeur de ce champ est comparée à celle de la requête (inversion du
MSB et du LSB dans le cas de chacun de ces deux champs).
Résultat de l’écriture de la valeur d’un paramètre : Valeur du paramètre écrit.
La valeur de ce champ est comparée à celle de la requête (inversion du
MSB et du LSB dans le cas de chacun de ces deux champs).
Commande utilisateur : Adresse Modbus du départ-moteur auquel la
demande d’écriture doit être envoyée.
Commande utilisateur : Adresse du paramètre
NOTE : N’essayez pas de modifier la valeur du registre 704 (registre de
commande), car celui-ci est déjà commandé par le maître DeviceNet (voir
sous-programme « LAD 3 - CMD_SURV ») !
Commande utilisateur : Nouvelle valeur du paramètre
Index dans le tableau des résultats des écritures de paramètres TeSys U
(départs-moteurs n°1 à 8).
Valeur = 16 + 2 × (n° départ-moteur – 1) = 16 à 30
Tableau des résultats des écritures de paramètres TeSys U (départsmoteurs n°1 à 8). Eléments N7:16 à N7:31 organisés par couple « adresse
du paramètre » / « valeur du paramètre », chaque couple occupant deux
adresses successives.
« Valeur du paramètre » = –1 en cas d’erreur (timeout de l’attente de la
réponse).
Compteur local correspondant au « trigger byte » de la requête d’écriture.
Variables temporaires de travail servant à effectuer des calculs
intermédiaires (principalement des inversions LSB / MSB).
Demande d’écriture de la valeur d’un paramètre : Esclave (recopie de N7:12)
en LSB + Fonction (toujours 0x06) en MSB.
Demande d’écriture de la valeur d’un paramètre : Adresse du paramètre
(recopie de N7:13, avec permutation du LSB et du MSB).
Demande d’écriture de la valeur d’un paramètre : Valeur du paramètre à
écrire (recopie de N7:14, avec permutation du LSB et du MSB).
106
Annexe C : Exemple d’utilisation (RSLogix 500)
Adresse
S:24
Symbole
INDEX_SYS
T4:1
TIMEOUT_ECRIT_PARAM
Description
Registre d’index utilisé dans les adressages indexés (préfixe : ‘#’)
Temporisation du timeout de l’écriture d’un Paramètre (3
secondes)
L’exemple comporte un écran de surveillance personnalisée des données, appelé « CDM 2 - ECRIT_PAR »,
afin d’en simplifier l’utilisation. Le contenu de cet écran est reproduit ci-dessous :
Adresse
N7:12
N7:13
N7:14
B3:0/2
Symbole
ECRIT_ESCLAVE
ECRIT_ADRESSE
ECRIT_VALEUR
ECRIT_COMMANDE
Affichage
Décimal
Décimal
Décimal
Binaire
B3:0/3
B3:0/4
N7:15
N7:16
N7:17
N7:18
N7:19
N7:20
N7:21
N7:22
N7:23
N7:24
ECRIT_RUNNING
ECRIT_OK
ECRIT_INDEX
PARECRIT_1_ADRESSE
PARECRIT_1_VALEUR
PARECRIT_2_ADRESSE
PARECRIT_2_VALEUR
PARECRIT_3_ADRESSE
PARECRIT_3_VALEUR
PARECRIT_4_ADRESSE
PARECRIT_4_VALEUR
PARECRIT_5_ADRESSE
Binaire
Binaire
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Adresse
N7:25
N7:26
N7:27
N7:28
N7:29
N7:30
N7:31
O:1.13
O:1.14
O:1.15
I:1.13
I:1.14
I:1.15
I:1.16
O:1.16
N7:37
B3:0/6
Symbole
PARECRIT_5_VALEUR
PARECRIT_6_ADRESSE
PARECRIT_6_VALEUR
PARECRIT_7_ADRESSE
PARECRIT_7_VALEUR
PARECRIT_8_ADRESSE
PARECRIT_8_VALEUR
WRPAR_SLAVE_FCT
WRPAR_ADRPAR
WRPAR_VALUE
CR_WRPAR_SLAVE_FCT
CR_WRPAR_ADRPAR
CR_WRPAR_VALUE
TRIGGER_IN_RD_WR
TRIGGER_OUT_RD_WR
————
————
Affichage
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Décimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Hexadécimal
Binaire
Restrictions concernant l’exemple RSLogix 500
L’exemple présenté ici n’est pas parfait. Par exemple, en cas de réponse erronée (mauvais numéro d’esclave,
de fonction, etc.), le programme n’effectue aucun traitement particulier et continue d’attendre une réponse
jusqu’au timeout, alors que la passerelle n’a procédé à aucune ré-émission, puisque de son point de vue la
réponse est correcte. En effet, l’ensemble du contenu de la réponse Modbus étant placé dans un champ de
« Data », il ne sera pas vérifié avant d’être recopié dans la mémoire de la passerelle. Seul le Checksum de la
trame est vérifié par la passerelle.
Les deux « trigger bytes » situés dans le mot d’entrée I:1.16 ne sont pas utilisés. Vous devrez vous en servir si
vous souhaitez que votre application soit informée de l’arrivée de chaque réponse associée aux deux
commandes personnalisées « Transactions 1 » et « Transactions 2 ».
La compatibilité avec les différentes options offertes pour le champ « Control/Status Byte » de l’élément « ABC »
(voir chapitre 5 Initialisation et diagnostic de la passerelle) n’est traitée que de manière partielle dans l’exemple
présent. Les évolutions à apporter concernent principalement la gestion des bits 14 et 15 du mot de commande
du maître DeviceNet et du mot d’état de la passerelle (bits 6 et 7 de l’entrée I:1.1 et de la sortie O:1.1
correspondantes). De plus, l’utilisation des diagnostics de la passerelle (champs EC et ED) reste à définir par
l’utilisateur.
107
Appendix D: Objets DeviceNet
Présentation des objets DeviceNet de la passerelle
Le logiciel de la passerelle LUFP9 a été développé conformément à la Modélisation des Objets du protocole
DeviceNet. De ce modèle découle une méthode d’adressage des données de la passerelle, appelées Attributs,
constituée de quatre valeurs distinctes : c l’Adresse du Nœud (MAC ID), d l’Identificateur de la Classe de
l’Objet (Class ID), e le Numéro de l’Instance (Instance ID) et f le Numéro de l’Attribut (Attribute ID). Une
adresse constituée de cette manière est appelée un « Chemin ». La Connexion par Messagerie Explicite, par
exemple, utilise de tels chemins pour échanger des données d’un point à l’autre sur un réseau DeviceNet.
Adresse
Min. – max.
Nœud
0 – 00 063
Classe
1 – 65 535
Instance
0 – 65 535
Description
Ce champ permet d’adresser un abonné parmi l’ensemble des abonnés d’un réseau
DeviceNet grâce à son MAC ID.
Tous les objets partageant les mêmes caractéristiques appartiennent à une même
classe, caractérisée par son Class ID.
Les instances représentent les différents objets d’une même classe. Toutes les instances
d’une même classe partagent les mêmes comportements (1) et les mêmes Attributs,
mais chacune d’entre elles possède son propre jeu de valeurs pour ces attributs. Lors de
la création d’une instance (instanciation) par un abonné, celui-ci lui attribue un Instance ID
unique, ce qui permet aux autres abonnés DeviceNet d’y avoir accès de manière
individuelle.
Attribut
1 – 00 255
Chaque attribut représente l’une des caractéristiques des Instances appartenant à la
même classe. Il se voit affecter une valeur de nature variable (octet, entier non signé,
chaîne de caractères, etc.) dans le but de fournir des renseignements sur l’état de
l’abonné ou pour effectuer des réglages sur les comportements (1) de l’abonné.
NOTE : Pour accéder aux attributs de la Classe même d’un objet, il faut utiliser
l’Instance 0x00 lors de la composition du Chemin complet. Exemple : Pour accéder à
l’attribut « Revision » de la classe « Identity Object » de l’abonné DeviceNet n°4, le
chemin à utiliser est le suivant : « 0x04 • 0x01 • 0x00 • 0x01 ».
(1) Les comportements désignent les actions entreprises par un objet DeviceNet en réponse à des événements
déterminés.
Liste des objets DeviceNet de la passerelle
Classe
Identity object
Message router
DeviceNet object
Assembly object
Connection object
Acknowledge handler object
I/O data input mapping object
I/O data output mapping object
Diagnostic object
ID
0x01
0x02
0x03
0x04
0x05
0x2B
0xA0
0xA1
0xAA
Requis
Oui
Oui
Oui
Non
Oui
Non
Non
Non
Non
Instances
1
1
1
2 (1)
4 (2)
1
1
1
1
Interfaces
Message router
Explicit messages connection
Message router
I/O connections ou Message router
I/O connections ou Explicit messages
I/O connections ou Message router
Message router
Message router
Message router
(1) Une zone d’entrée et une zone de sortie sont créées dans la mémoire de la passerelle.
(2) Les quatre connexions instanciées sont : c Explicit Connection, d Polled Command/Response, d Bit Strobed
Command/Response et d Change-of-State / Cyclic. Les trois dernières connexions sont du type « I/O
Connection ».
108
Annexe D : Objets DeviceNet
Représentation graphique des objets DeviceNet de la passerelle
Mémoire de la passerelle LUFP9
0x0000
0x01FF
Données d’entrée (1)
0x0200
0x03FF
Données de sorties (1)
0x0400
0x07FF
Zone des données Générales
Objets
applicatifs
Diagnostic
Object
I/O Data Output
Mapping Object
I/O Data Input
Mapping Object
Identity
Object
Acknowledge
Handler Object
Message
Router
Assembly
Objects
I/O
Connections
Objets réservés pour
les communications
Explicit
Messages
DeviceNet
Object
Connection Object
Les classes
correspondant aux
objets grisés sont
requises.
Réseau DeviceNet
(1) Les zones des données d’entrée et de sortie peuvent être lues ou écrites soit à l’aide des « I/O
connections », soit à l’aide des « explicit messages ».
Identity Object (classe 0x01)
L’objet « Identity » ne possède qu’une seule instance (Instance ID = 0x01). Cet objet contient des informations
d’ordre général permettant d’identifier la passerelle et d’en diagnostiquer l’état. Cet objet est décrit dans le
chapitre 6-2. du tome II des spécifications DeviceNet sur le site Web ODVA.
Attributs de la classe 0x01
ID
0x01
Accès Nom
Get
Revision
Besoin
Type
Requis
UINT
Valeur Description
1
Indices majeur et mineur de la révision du « Identity
Object ».
Services de la classe 0x01
Code du service
0x0E
Nom du service
Besoin Description
Get_Attribute_Single
Requis Ce service permet de lire la valeur de l’un des attributs de la
classe.
109
Annexe D : Objets DeviceNet
Attributs de l’instance 0x01 de la classe 0x01
ID
Accès
0x01
Get
Nom
Besoin
Type
Valeur
Identifiant du vendeur
Requis
UINT
90
L’ensemble des ID des fabricants de produits DeviceNet sont gérés par l’ODVA. Dans le cas de la passerelle
LUFP9, cet ID est égal à 90 (passerelles HMS Fieldbus Systems AB (Hassbjer Micro Sys)).
0x02
Get
Type composant
Requis
UINT
12
La liste des différents types de produits DeviceNet est gérée par l’ODVA. Cet attribut permet d’identifier le profil
d’un abonné DeviceNet, et d’en déduire les exigences minimales et les options couramment utilisées par les
abonnés de ce profil. La passerelle LUFP9 correspond à un produit de type « Communication Adapter » (voir
chapitre 3-7. du tome II des spécifications DeviceNet).
0x03
Get
Code produit
Requis
UINT
60
Cet attribut est géré par le fabricant du produit afin de caractériser ses propres produits. Il lui sert à identifier
chacun de ses produits au sein de la même famille de produits (attribut « type de produit »). Cela permet de
caractériser des produits présentant des différences au niveau de leur configuration et/ou de leurs options.
0x04
Get
Revision
Requis
USINT , USINT
3,1
Indices de révision majeur et mineur permettant d’identifier le « Identity Object ». La valeur de chacun des deux
membres de cet attribut ne peut pas être nulle. La représentation conventionnelle des indices de la révision est
« majeur.mineur », avec 3 chiffres pour l’indice mineur, complétés à gauche par des zéros si besoin est. L’indice
majeur est limité à 7 bits utiles. Son 8ème bit est réservé est doit être égal à zéro.
0x05
Get
Status
Requis
MOT
(registre de 16 bits)
Cet attribut constitue un résumé de l’état général du produit. Il s’agit d’un registre de 16 bits :
Bit 0 ........... Alloué à un maître
(connexion maître/esclave prédéfinie).
Bit 1 ........... Réservé (valeur = 2#0).
Bit 2 ........... Produit configuré.
Bits 3-7 ...... Réservés (valeur = 2#00000).
0x06
Get
Numéro de série
Bit 8...............Faute mineure réparable.
Bit 9...............Faute mineure irréversible.
Bit 10.............Faute majeure réparable.
Bit 11.............Faute majeure irréversible.
Bits 12-15......Réservés (valeur = 2#0000).
Requis
UDINT
(variable)
Le numéro de série du produit est combiné à l’attribut « ID du fabricant » afin de produire un identificateur
unique pour chacun des produits DeviceNet. Chaque fabricant doit prendre la responsabilité de garantir que
l’ensemble des produits DeviceNet qu’il fabrique dispose d’un numéro de série unique.
Exemple de « numéro de série » : 0x 23 00 DD 20.
0x07
Get
Nom du produit
Requis
SHORT_STRING
« Anybus-C DeviceNet »
Cet attribut fournit une méthode d’identification visuelle et prend la forme d’une chaîne ASCII. Ce texte fournit une
description courte du produit, ou de la famille de produits, équivalente à l’attribut « code du produit » (0x03).
L’octet qui précède cette chaîne ASCII indique la longueur totale de cette chaîne, du premier au dernier
caractère. Dans le cas de la passerelle LUFP9, le nombre total d’octets compris dans l’attribut « nom du
produit » est égal à 24. La chaîne « Anybus-C DeviceNet » comporte 18 caractères (espaces compris).
L’ensemble du contenu de l’attribut « nom du produit », dans le cas de la passerelle LUFP9, est donc égal à :
0x 12 41 6E 79 62 75 73 2D 43 20 44 65 76 69 63 65 4E 65 74 00 00 00 00 00. Les octets qui n’apparaissent pas
en gras constituent le contenu de la chaîne ASCII (longueur = 0x12).
0x09
Get
Valeur de l’intégrité de la configuration
Option
UINT
(variable)
La valeur de cet attribut permet de vérifier la validité de la configuration du produit. Celui-ci modifie cet attribut de
manière automatique lorsque la valeur d’un attribut non volatile est modifiée. Le comportement du produit lors de
la détection d’une erreur d’intégrité de la configuration est spécifique à chaque type de produit. De même, la
méthode de calcul de la valeur de cet attribut dépend entièrement du produit : CRC, compteur unitaire, etc.
Cet attribut permet donc à un maître DeviceNet, par exemple, de vérifier que la configuration du produit
DeviceNet n’a pas été modifiée.
NOTE : En plus de calculer la valeur de cet attribut, la passerelle LUFP9 utilise sa DEL s DEVICE STATUS pour
signaler lorsque sa configuration n’est pas valide (DEL dans un état clignotant rouge/vert).
Services de l’instance 0x01 de la classe 0x01
Code du
service
0x05
0x0E
Nom du service
Reset
Get_Attribute_Single
Exigence
Requis
Requis
Description
Ce service permet de réinitialiser la passerelle.
Ce service permet de lire la valeur de l’un des attributs de
l’instance.
110
Annexe D : Objets DeviceNet
Message Router Object (classe 0x02)
L’objet « Message Router » est l’élément par lequel tous les objets de type « Explicit messages » transitent afin
d’être aiguillés vers les objets auxquels ils sont destinés. Il ne possède qu’une seule instance (Instance ID =
0x01). Cet objet est décrit dans le chapitre 6-3. du tome II des spécifications DeviceNet.
Attributs de la classe 0x02
ID
Accès Nom
0x01
Revision
Get
Besoin
Type
Option
UINT
Valeur Description
Indice de révision de la classe du « Message Router Object ».
1
Services de la classe 0x02
Code du Nom du service
service
0x0E
Get_Attribute_Single
Besoin
Description
Requis
Ce service permet de lire la valeur de l’un des attributs de la classe.
Attributs de l’instance 0x01 de la classe 0x02
Cette instance ne possède aucun attribut.
DeviceNet Object (classe 0x03)
L’objet « DeviceNet » ne possède qu’une seule instance (Instance ID = 0x01). Cet objet contient l’état et la
configuration générale du nœud de la passerelle sur le réseau DeviceNet. Il est décrit dans le chapitre 5-5. du
tome I des spécifications DeviceNet. La passerelle LUFP9 est un abonné du type « Group 2 only server »
(voir chapitre 7-9.du tome I des spécifications DeviceNet).
Attributs de la classe 0x03
ID
Accès Nom
0x01
Get
Revision
Besoin
Type
Requis
UINT
Valeur Description
2
Indice de révision de la définition de la classe du
« DeviceNet
Object »
actuellement
utilisé
pour
l’implémentation des fonctions de communications
DeviceNet de la passerelle. (1)
(1) Cet indice doit être compris entre 1 et 65 535 et sera incrémenté si la définition de la classe est remplacée
par une définition plus récente.
Services de la classe 0x03
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Option
Ce service permet de lire la valeur de l’un des attributs de la classe.
Attributs de l’instance 0x01 de la classe 0x03
ID
0x01
Accès
Get
Nom
Besoin
Type
Valeur
MAC ID
Requis
USINT
0 à 63
La valeur de cet attribut correspond à l’adresse de la passerelle sur le réseau DeviceNet (MAC ID), c’està-dire à l’adresse qui est configurée à l’aide des commutateurs décrits dans le chapitre 2.7.2 Codage de
l’adresse de la passerelle.
0x02
Get
Vitesse de transmission
Option
USINT
0à2
La valeur de cet attribut correspond à la vitesse de communication du réseau DeviceNet, telle qu’elle a été
configurée sur la passerelle à l’aide des commutateurs décrits dans le chapitre 2.7.1 Codage de la vitesse
DeviceNet Cette vitesse doit être la même pour tous les abonnés du réseau DeviceNet. Les différentes
valeurs possibles pour cet attribut sont : 0 (125 kbits/s), 1 (250 kbits/s) et 2 (500 kbits/s).
111
Annexe D : Objets DeviceNet
ID
Accès
0x05
Get
Nom
Besoin
Type
Valeur
Requis
BYTE , USINT
(variable)
Informations sur l’allocation
Cet attribut fournit des renseignements généraux sur la méthode d’allocation DeviceNet actuellement utilisée.
Elle est composée du « choix d’allocation », au format BYTE, et du « MAC ID du maître », au format USINT et
dont la valeur est comprise entre 0 et 63. Si le « MAC ID du maître » est égal à 255 (ce qui est le cas lors de
l’initialisation de la passerelle), cela signifie qu’aucune allocation n’a eu lieu dans le cadre de l’utilisation du
« Jeu Prédéfini des Connexions Maître/Esclave ». Reportez-vous aux chapitres 3-4., 5-5.4.2. et 7. du tome I
des spécifications DeviceNet pour de plus amples détails à ce sujet.
Exemple : 0x03, 0x00.
Services de l’instance 0x01 de la classe 0x03
Code du Nom du service
service
Besoin Description
0x0E
Get_Attribute_Single
Option
0x4B
Allocate Master/Slave
Connection Set
Option
0x4C
Release Master/Slave
Connection Set
Ce service permet de lire la valeur de l’un des attributs de l’instance.
Ce service permet d’allouer la connexion maître/esclave à un maître
DeviceNet, sur demande de ce dernier.
Option Ce service permet de libérer la connexion maître/esclave précédemment
allouée à un maître DeviceNet, sur demande de ce dernier.
Assembly Objects (Classe 0x04)
En règle générale, les objets de la classe « Assembly » servent à regrouper au sein d’un attribut unique des
attributs (données) appartenant à des objets différents. Cela permet d’y avoir accès à l’aide d’un seul message.
Dans le cas de la passerelle LUFP9, cette classe possède seulement 2 instances, chacune d’entre elles étant
affectée à la zone d’entrée (Instance ID = 0x64) ou à la zone de sortie (Instance ID = 0x96) de la passerelle. Cet
objet est décrit dans le chapitre 6-5. du tome II des spécifications DeviceNet.
La première instance (Instance ID = 0x64) est affectée à la zone des données d’entrée de la passerelle. Cette
zone d’entrée couvre l’ensemble des emplacements mémoire recevant une donnée issue d’une réponse
Modbus à transmettre au maître DeviceNet. La seconde instance (Instance ID = 0x96) est affectée à la zone des
données de sortie de la passerelle. Cette zone de sortie couvre l’ensemble des emplacements mémoire
recevant une donnée à placer dans d’une requête Modbus, c’est-à-dire toutes les données qui sont transmises
par le maître DeviceNet.
Attributs de la classe 0x04
ID
Accès Nom
0x01
Get
Revision
Besoin
Type
Requis
UINT
Valeur Description
2
Indice de révision de la classe du « Assembly Object ».
Services de la classe 0x04
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Option
Ce service permet de lire la valeur de l’un des attributs de la classe.
112
Annexe D : Objets DeviceNet
Attributs de l’instance 0x64 de la classe 0x04 (ENTREES MODBUS)
ID
Accès
0x03
Get
Nom
Besoin
Type
Valeur
Données
Requis
USINT […]
(tableau de valeurs)
Les données regroupées au sein de cet attribut correspondent à celles de l’attribut 0x01 de l’instance 0x01 de
l’objet I/O Data Input Mapping.
Dans le cas de la configuration par défaut, la taille de l’instance 0x64 (zone des données d’entrée de la
passerelle) est égale à 32 octets et les données qui sont associées à l’attribut 0x03 de cette instance
correspondent à ce qui est décrit dans l’Appendix C: Exemple d’utilisation (RSLogix 500), Zone mémoire
des données d’entrée.
Attributs de l’instance 0x96 de la classe 0x04 (SORTIES MODBUS)
ID
Accès
Nom
Get/Set Données
0x03
Exigence
Type
Valeur
Requis
USINT […]
(tableau de valeurs)
Les données regroupées au sein de cet attribut correspondent à celles de l’attribut 0x01 de l’instance 0x01 de
l’objet I/O Data Output Mapping.
Dans le cas de la configuration par défaut, la taille de l’instance 0x96 (zone des données de sortie de
la passerelle) est égale à 32 octets et les données qui sont associées à l’attribut 0x03 de cette
instance correspondent à ce qui est décrit dans l’Appendix C: Exemple d’utilisation (RSLogix 500),
Zone mémoire des données de sortie.
Services des instances 0x64 et 0x96 de la classe 0x04
Nom du service
Besoin
Description
0x0E
Get_Attribute_Single
Requis
Ce service permet de lire le tableau de valeurs qui correspond à
l’attribut 0x03 de l’une des instances du « Assembly Object ».
0x10
Get_Attribute_Single
Option
Ce service permet d’écrire un tableau de valeurs dans le tableau
de l’attribut 0x03 de l’une des instances du « Assembly Object ».
Code du
service
Connection Object (Classe 0x05)
Dans le cas de la passerelle LUFP9, l’objet « Connection » possède jusqu’à quatre instances (Instance ID =
0x01 à 0x04). Chacune de ces instances représente l’une des deux extrémités d’une connexion virtuelle établie
entre deux nœuds du réseau DeviceNet, en l’occurrence le nœud du maître DeviceNet et le nœud de la
passerelle. Chaque instance de cet objet appartient à l’un des deux types de connexions suivants : Connexion
explicite, qui permet de faire transiter des Explicit Messages, ou connexion implicite (I/O Connections). Cet objet
est décrit dans le chapitre 5-4. du tome II des spécifications DeviceNet.
Les quatre instances de l’objet « Connection » de la passerelle LUFP9 sont brièvement décrites dans le tableau
suivant, avant d’être détaillées dans la suite de ce chapitre :
Instance ID
0x01
0x02
0x03
0x04
Type de connexion
Explicit Messaging
I/O Connection
I/O Connection
I/O Connection
Nom de la connexion
Explicit Connection
Polled Command/Response Connection
Bit Strobed Command/Response Connection
Change-of-State / Cyclic (Acknowledged) Connection
Chaque message d’une connexion de type « Explicit Messaging » contient l’adressage complet et les valeurs de
l’attribut concerné, ainsi que le Code de Service décrivant l’action à entreprendre.
Chaque message d’une connexion de type « I/O Connection » contient uniquement des données d’E/S.
L’ensemble des informations décrivant l’utilisation de ces données sont situées dans l’instance du « Connection
Object » associée à ce message.
113
Annexe D : Objets DeviceNet
L’objet « Change-of-State / Cyclic Connection » (Instance ID 0x04) permet de sélectionner une connexion
« Change-of-state » (COS) ou une connexion « Cyclic ».
La connexion « Change-of-state » permet à la passerelle de produire ses données uniquement sur changement
de leurs valeurs ou sur expiration d’une temporisation appelée « heartbeat rate ». Une borne temporelle
inférieure permet d’empêcher cette connexion de monopoliser la bande passante du réseau DeviceNet si les
valeurs de ses données produites changent trop souvent.
Le passage en mode « Cyclic » permet de réduire les échanges effectués via cette connexion si la période de
mise à jour (échantillonnage) des données produites est lente. En réglant le temps de cycle de la connexion sur
la valeur de cette période, les données produites correspondent exactement aux échantillons des données, sans
perte ni répétition d’échantillons.
AVERTISSEMENT
FONCTIONNEMENT IMPREVU DU SYSTEME
Vous devez configurer l’objet « Change-of-State / Cyclic Connection » correctement. Dans le cas contraire, il
affectera les communications sur l’ensemble du réseau DeviceNet network, provoquant la saturation du bus et
l’absence de transmission de données depuis les autres esclaves.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
Attributs de la classe 0x05
ID
Accès Nom
Besoin
Type
Valeur Description
Option
UINT
1
Indice de révision de la classe du « Connection Object ».
0x64 Get/Set Polled production
Option
USINT
0
Indice de la zone d’entrée utilisée par la passerelle
pour les productions de sa connexion « Polled
Command/Response ».
0x65 Get/Set Polled consumption
Option
USINT
0
Indice de la zone de sortie utilisée par la passerelle
pour les consommations de sa connexion « Polled
Command/Response ».
0x66 Get/Set Strobed production
Option
USINT
0
Indice de la zone d’entrée utilisée par la passerelle
pour les productions de sa connexion « Bit Strobed
Command/Response ».
0x67 Get/Set Strobed consumption
Option
USINT
0
Indice de la zone de sortie utilisée par la passerelle
pour les consommations de sa connexion « Bit Strobed
Command/Response ».
0x68 Get/Set COS production
Option
USINT
0
Indice de la zone d’entrée utilisée par la passerelle
pour les productions de sa connexion « Bit Strobed
Command/Response ».
0x01
Get
Revision
Services de la classe 0x05
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Requis
Ce service permet de lire la valeur de l’un des attributs de la
classe.
Attributs de l’instance 0x01 de la classe 0x05 : Explicit Connection
ID
0x01
Accès
Nom
Besoin
Type
Valeur
Get
Etat
Requis
USINT
0à5
Cet attribut représente l’état de l’objet « Explicit Connection ». Les valeurs supportées par la passerelle
LUFP9 sont les suivantes : 0 (inexistant), 1 (en cours de configuration), 3 (connexion établie), 4 (en timeout) et
5 (suppression différée). Reportez-vous aux figures 5.16 et 7.4 du tome I des spécifications DeviceNet pour de
plus amples renseignements à ce sujet.
0x02
Get
Type d’instance
Requis
USINT
0
Cet attribut définit le type de connexion de l’instance : Messaging connection (0) ou I/O connection (1).
114
Annexe D : Objets DeviceNet
ID
0x03
Accès
Nom
Besoin
Type
Valeur
Requis
BYTE
0x83
Get/Set Déclencheur de la classe transport
Cet attribut définit le comportement de la connexion. Dans le cas de l’objet « Explicit Connection » de la
passerelle LUFP9, cet attribut prend la valeur 0x83, décomposée de la manière suivante :
Bits 0-3 = 2#0011 .... Classe de transport = Classe 3.
Bits 4-6 = 2#xxx ....... Valeur ignorée dans le cas d’un serveur de données.
Bits 7 = 2#1........... La passerelle se comporte comme un serveur de données répondant aux requêtes d’un
client DeviceNet.
0x04
Get/Set ID des productions de la connexion
Requis
2#11• ••xx xxxx
UINT
La valeur de cet attribut est placée dans le Champ d’Identification du protocole CAN lorsque la connexion passe
en émission (messages du groupe 3). Le terme « xx xxxx » représente les 6 bits de l’adresse du nœud DeviceNet
de la passerelle. Le terme « ••• » représente l’ID du message.
Exemple : 0x070A = 2#111 0000 1010 (messages du groupe 3 ; ID des messages = 4 ; passerelle située à
l’adresse 10).
0x05
Get/Set ID des consommations de la connexion
Requis
2#11• ••xx xxxx
UINT
La valeur de cet attribut correspond au contenu du Champ d’Identification du protocole CAN des messages que
la connexion doit recevoir (messages du groupe 3). Le terme « xx xxxx » représente les 6 bits de l’adresse du
nœud DeviceNet. Le terme « ••• » représente l’ID du message.
Exemple : 0x0601 = 2#110 0000 0001 (messages du groupe 3 ; ID des messages = 0 ; producteur situé à
l’adresse 1).
0x06
Get/Set Caractéristiques initiales de la comm.
Requis
BYTE
0x21
Cet attribut définit le ou les Groupes de Messages par lesquels les productions et les consommations associées à
l’objet « Explicit Connection » sont effectuées. Reportez-vous aux chapitres 3-2. et 5-4.3.6. du tome I des
spécifications DeviceNet pour de plus amples détails à ce sujet.
0x07
Get/Set Taille des productions de la connexion
Requis
UINT
516
Nombre maximum d’octets pouvant être transmis via la connexion de cette instance.
0x08
Get/Set Taille des consommations de la connexion
Requis
UINT
516
Nombre maximum d’octets pouvant être reçus via la connexion de cette instance.
0x09
Get/Set Fréquence prévisionnelle des échanges
(Expected_packet_rate)
Requis
UINT
10 000 (unité = 1 ms,
par pas de 10 ms)
Cet attribut permet à la passerelle de calculer les valeurs de la Temporisation du Déclenchement de l’Emission et
de la Temporisation d’Inactivité / du Chien de Garde pour les échanges effectués à l’aide de l’objet « Explicit
Connection ». Reportez-vous au chapitre 5-4.4. du tome I des spécifications DeviceNet pour de plus amples
renseignements au sujet de ces temporisations.
0x0C Get/Set Action sur déclenchement du chien de garde
Requis
USINT
3
Cet attribut définit l’action entreprise sur déclenchement du chien de garde ou sur inactivité de la connexion. Les
différentes valeurs possibles sont les suivantes : 0 (Passage en timeout), 1 (Suppression Automatique) et 3
(Suppression Différée).
0x0D Get/Set Productions : Longueur du chemin
Requis
UINT
0
Taille du tableau d’USINT de l’attribut 0x0E (chemin des productions de la connexion).
0x0E
Get/Set Productions : Chemin de la connexion
Requis
USINT […]
(chemin vide)
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est utilisé pour
produire les données de la connexion. Dans le cas présent, il n’y a pas de chemin de production pour la
connexion « Explicit Connection ».
0x0F
Get/Set Consommations : Longueur du chemin
Requis
UINT
0
Taille du tableau d’USINT de l’attribut 0x10 (chemin des consommations de la connexion).
0x10
Get/Set Consommations : Chemin de la connexion
Requis
USINT […]
(chemin vide)
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est destiné à
recevoir les données consommées par la connexion. Dans le cas présent, il n’y a pas de chemin de
consommation pour la connexion « Explicit Connection ».
115
Annexe D : Objets DeviceNet
Attributs de l’instance 0x02 de la classe 0x05 : Polled Command/Response Connection
ID
0x01
Accès
Nom
Besoin
Type
Valeur
Get
Etat
Requis
USINT
0à4
Cet attribut représente l’état de l’objet « Polled Command/Response Connection ». Les valeurs supportées par la
passerelle LUFP9 sont les suivantes : 0 (inexistant), 1 (en cours de configuration), 3 (connexion établie) et 4 (en
timeout). Reportez-vous aux figures 5.16 et 7.4 du tome I des spécifications DeviceNet pour de plus amples
renseignements à ce sujet.
0x02
Get
Type d’instance
Requis
USINT
1
Cet attribut définit le type de connexion de l’instance : Messaging connection (0) ou I/O connection (1).
0x03
Get/Set
Déclencheur de la classe transport
Requis
BYTE
0x82
Cet attribut définit le comportement de la connexion. Dans le cas de l’objet « Polled Command/Response
Connection » de la passerelle LUFP9, cet attribut prend la valeur 0x82, décomposée de la manière suivante :
Bits 0-3 = 2#0010..... Classe de transport = Classe 2.
Bits 4-6 = 2#xxx ....... Valeur ignorée dans le cas d’un serveur de données.
Bits 7 = 2#1........... La passerelle se comporte comme un serveur de données répondant aux requêtes d’un
client DeviceNet.
0x04
Get/Set
ID des productions de la connexion
Requis
UINT
2#0•• ••xx xxxx
La valeur de cet attribut est placée dans le Champ d’Identification du protocole CAN lorsque la connexion passe
en émission (messages du groupe 1). Le terme « xx xxxx » représente les 6 bits de l’adresse du nœud DeviceNet
de la passerelle. Le terme « •• •• » représente l’ID du message.
Exemple : 0x03CA = 2#011 1100 1010 (messages du groupe 1 ; ID des messages = 15 ; passerelle située à
l’adresse 10).
0x05
Get/Set
ID des consommations de la connexion
Requis
UINT
2#10x xxxx x•••
La valeur de cet attribut correspond au contenu du Champ d’Identification du protocole CAN des messages que
la connexion doit recevoir (messages du groupe 2). Le terme « x xxxx x » représente les 6 bits de l’adresse du
nœud DeviceNet. Le terme « ••• » représente l’ID du message.
Exemple : 0x0455 = 2#100 0101 0101 (messages du groupe 2 ; ID des messages = 5 ; producteur situé à
l’adresse 10).
0x06
0x07
Get/Set
Requis
BYTE
0x01
Caractéristiques initiales de la comm.
Cet attribut définit le ou les Groupes de Messages par lesquels les productions et les consommations associées à
l’objet « Polled Command/Response Connection » sont effectuées. Reportez-vous aux chapitres 3-2. et 5-4.3.6. du
tome I des spécifications DeviceNet pour de plus amples détails à ce sujet.
Get/Set
Taille des productions de la connexion
Requis
UINT
(taille de la zone
d’entrée)
Nombre maximum d’octets pouvant être transmis via la connexion de cette instance. La valeur de cet attribut doit
être égale à la taille de la zone d’entrée choisie à l’aide de l’attribut 0x0E. Dans le cas de la configuration par
défaut de la passerelle LUFP9, la valeur de cet attribut est égale à 32, c’est-à-dire à la taille de la zone
d’entrée « Input1 ».
0x08
Get/Set
Taille des consommations de la connexion
Requis
UINT
(taille de la zone de
sortie)
Nombre maximum d’octets pouvant être reçus via la connexion de cette instance. La valeur de cet attribut doit
être égale à la taille de la zone de sortie choisie à l’aide de l’attribut 0x10. Dans le cas de la configuration par
défaut de la passerelle LUFP9, la valeur de cet attribut est égale à 32, c’est-à-dire à la taille de la zone
d’entrée « Output1 ».
0x09
Get/Set
Fréquence prévisionnelle des échanges
(Expected_packet_rate)
Requis
UINT
80 (unité = 1 ms,
par pas de 10 ms)
Cet attribut définit la périodicité des échanges effectués via les connexions de cette instance.
0x0C
Get/Set
Action sur déclenchement du chien de garde
Requis
USINT
0
Cet attribut définit l’action entreprise sur déclenchement du chien de garde ou sur inactivité de la connexion. Les
différentes valeurs possibles sont les suivantes : 0 (Passage en timeout), 1 (Suppression Automatique), 2 (RAZ
Automatique) et 3 (Suppression Différée).
0x0D
Get/Set
Requis
UINT
Productions : Longueur du chemin
Taille du tableau d’USINT de l’attribut 0x0E (chemin des productions de la connexion).
6
116
Annexe D : Objets DeviceNet
ID
Accès
Nom
Besoin
Type
Valeur
0x0E
Get/Set Productions : Chemin de la connexion
Requis
USINT […]
0x 20 04 24 64 30 03
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est utilisé pour
produire les données de la connexion. Dans le cas présent, le chemin de production par défaut pour la
connexion « Polled Command/Response Connection » désigne l’attribut 0x03 de l’instance 0x64 de la classe
0x04, c’est-à-dire les données de la zone d’entrée « Input1 ».
NOTE : La modification de la valeur de l’attribut 0x64 de l’instance 0x00 de la classe 0x04 (paramètre EDS
« Polled production ») a une influence directe sur la valeur de l’attribut présenté ici, puisque le chemin de la
connexion correspondante est modifié pour qu’il permette d’avoir accès à la zone d’entrée sélectionnée. Ces
modifications ne doivent avoir lieu qu’au moyen du fichier EDS fourni avec la passerelle.
0x0F
Get/Set Consommations : Longueur du chemin
Requis
UINT
Taille du tableau d’USINT de l’attribut 0x10 (chemin des consommations de la connexion).
0x10
Requis
Get/Set Consommations : Chemin de la connexion
USINT […]
0x 20 04 24 96 30 03
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est destiné à recevoir
les données consommées par la connexion. Dans le cas présent, le chemin de consommation par défaut pour la
connexion « Polled Command/Response Connection » désigne l’attribut 0x03 de l’instance 0x96 de la classe
0x04, c’est-à-dire les données de la zone d’entrée « Output1 ».
NOTE : La modification de la valeur de l’attribut 0x65 de l’instance 0x00 de la classe 0x04 (paramètre EDS
« Polled consumption ») a une influence directe sur la valeur de l’attribut présenté ici, puisque le chemin de la
connexion correspondante est modifié pour qu’il permette d’avoir accès à la zone de sortie sélectionnée. Ces
modifications ne doivent avoir lieu qu’au moyen du fichier EDS fourni avec la passerelle.
6
Attributs de l’instance 0x03 de la classe 0x05 : Bit Strobed Command/Response Connection
ID
Accès
Nom
Besoin
Type
Valeur
0x01
Etat
Get
Requis
USINT
0à4
Cet attribut représente l’état de l’objet « Bit Strobed Command/Response Connection ». Les valeurs supportées
par la passerelle LUFP9 sont les suivantes : 0 (inexistant), 1 (en cours de configuration), 3 (connexion établie) et
4 (en timeout). Reportez-vous aux figures 5.16 et 7.4 du tome I des spécifications DeviceNet pour de plus
amples renseignements à ce sujet.
0x02
Type d’instance
Get
Requis
USINT
1
Cet attribut définit le type de connexion de l’instance : Messaging connection (0) ou I/O connection (1).
0x03
Get/Set Déclencheur de la classe transport
Requis
BYTE
0x83
Cet attribut définit le comportement de la connexion. Dans le cas de l’objet « Bit Strobed Command/Response
Connection » de la passerelle LUFP9, cet attribut prend la valeur 0x83, décomposée de la manière suivante :
Bits 0-3 = 2#0011 .... Classe de transport = Classe 3.
Bits 4-6 = 2#xxx....... Valeur ignorée dans le cas d’un serveur de données.
Bits 7 = 2#1 .......... La passerelle se comporte comme un serveur de données répondant aux requêtes d’un
client DeviceNet.
0x04
Get/Set ID des productions de la connexion
Requis
UINT
2#0•• ••xx xxxx
La valeur de cet attribut est placée dans le Champ d’Identification du protocole CAN lorsque la connexion passe
en émission (messages du groupe 1). Le terme « xx xxxx » représente les 6 bits de l’adresse du nœud
DeviceNet de la passerelle. Le terme « •• •• » représente l’ID du message.
Exemple : 0x038A = 2#011 1000 1010 (messages du groupe 1 ; ID des messages = 14 ; passerelle située à
l’adresse 10).
0x05
Get/Set ID des consommations de la connexion
Requis
UINT
2#10x xxxx x•••
La valeur de cet attribut correspond au contenu du Champ d’Identification du protocole CAN des messages que
la connexion doit recevoir (messages du groupe 2). Le terme « x xxxx x » représente les 6 bits de l’adresse du
nœud DeviceNet. Le terme « ••• » représente l’ID du message.
Exemple : 0x0400 = 2#100 0000 0000 (messages du groupe 2 ; ID des messages = 0 ; producteur situé à
l’adresse 0).
0x06
Get/Set Caractéristiques initiales de la comm.
Requis
BYTE
0x02
Cet attribut définit le ou les Groupes de Messages par lesquels les productions et les consommations associées
à l’objet « Bit Strobed Command/Response Connection » sont effectuées. Reportez-vous aux chapitres 3-2. et 54.3.6. du tome I des spécifications DeviceNet pour de plus amples détails à ce sujet.
117
Annexe D : Objets DeviceNet
ID
0x07
0x08
Accès
Nom
Besoin
Type
Get/Set Taille des productions de la connexion
Requis
UINT
Get/Set Taille des consommations de la
Requis
UINT
Valeur
(taille de la zone
d’entrée)
Nombre maximum d’octets pouvant être transmis via la connexion de cette instance. La valeur de cet attribut doit
être égale à la taille de la zone d’entrée choisie à l’aide de l’attribut 0x0E. Dans le cas de la configuration par
défaut de la passerelle LUFP9, la valeur de cet attribut est égale à 0, car aucune zone d’entrée n’est attribuée à
l’objet « Bit Strobed Command/Response Connection ». Taille maximale = 8 octets.
connexion
(taille de la zone de
sortie)
La valeur de cet attribut n’est pas significative dans le cas de l’objet « Bit Strobed Command/Response
Connection ». Cette valeur est fixée à 8.
0x09
Get/Set Fréquence prévisionnelle des échanges
Requis
UINT
80 (unité = 1 ms,
(Expected_packet_rate)
par pas de 10 ms)
Cet attribut définit la périodicité des échanges effectués via les connexions de cette instance.
0x0C
Get/Set Action sur déclenchement du chien de garde
USINT
0
Requis
Cet attribut définit l’action entreprise sur déclenchement du chien de garde ou sur inactivité de la connexion. Les
différentes valeurs possibles sont les suivantes : 0 (Passage en timeout), 1 (Suppression Automatique), 2 (RAZ
Automatique) et 3 (Suppression Différée).
0x0D
Get/Set Productions : Longueur du chemin
Requis
UINT
Taille du tableau d’USINT de l’attribut 0x0E (chemin des productions de la connexion).
0x0E
Get/Set Productions : Chemin de la connexion
Requis
USINT […]
(chemin de la zone)
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est utilisé pour produire
les données de la connexion. Dans le cas présent, le chemin de production pour la connexion « Bit Strobed
Command/Response Connection » correspond à la zone d’entrée affectée à la connexion « Polled
Command/Response Connection » à l’aide du paramètre EDS « Strobed production ».
0x0F
Get/Set Consommations : Longueur du chemin
Requis
UINT
Taille du tableau d’USINT de l’attribut 0x10 (chemin des consommations de la connexion).
0x10
Get/Set Consommations : Chemin de la connexion
Requis
USINT […]
(chemin de la zone)
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est destiné à recevoir
les données consommées par la connexion. Dans le cas présent, le chemin de consommation pour la connexion
« Bit Strobed Command/Response Connection » correspond à la zone de sortie qui a été affectée à cette connexion
à l’aide du paramètre EDS « Strobed consumption ».
0
0
Attributs de l’instance 0x04 de la classe 0x05 : Change-of-State / Cyclic (Acknowledged) Connection
ID
Accès
Nom
Besoin
Type
Valeur
0x01
Etat
Get
Cet attribut représente l’état de l’objet « Change-of-State /
supportées par la passerelle LUFP9 sont les suivantes :
(connexion établie) et 4 (en timeout). Reportez-vous aux
DeviceNet pour de plus amples renseignements à ce sujet.
0x02
Type d’instance
Get
Requis
USINT
1
Cet attribut définit le type de connexion de l’instance : Messaging connection (0) ou I/O connection (1).
0x03
Get/Set Déclencheur de la classe transport
Requis
BYTE
0x12 ou 0x02
Cet attribut définit le comportement de la connexion. Dans le cas de l’objet « Change-of-State / Cyclic
(Acknowledged) Connection » de la passerelle LUFP9, cet attribut prend la valeur 0x12 ou 0x02, décomposée de
la manière suivante :
Bits 0-3 = 2#0010 ..................... Classe de transport = Classe 2.
Bits 4-6 = 2#001 ou 2#000 ....... Mode « Change-of-State » (2#001) ou mode « Cyclic » (2#000).
Bits 7 = 2#0
Requis
USINT
0à4
Cyclic (Acknowledged) Connection ». Les valeurs
0 (inexistant), 1 (en cours de configuration), 3
figures 5.16 et 7.4 du tome I des spécifications
118
Annexe D : Objets DeviceNet
ID
0x04
0x05
Accès
Nom
Besoin
Type
Valeur
Get/Set ID des productions de la connexion
Requis
UINT
2#0•• ••xx xxxx
La valeur de cet attribut est placée dans le Champ d’Identification du protocole CAN lorsque la connexion passe
en émission (messages du groupe 1). Le terme « xx xxxx » représente les 6 bits de l’adresse du nœud
DeviceNet de la passerelle. Le terme « •• •• » représente l’ID du message.
Exemple : 0x034A = 2#011 0100 1010 (messages du groupe 1 ; ID des messages = 13 ; passerelle située à
l’adresse 10).
Get/Set ID des consommations de la
Requis
UINT
2#10x xxxx x•••
connexion
La valeur de cet attribut correspond au contenu du Champ d’Identification du protocole CAN des messages que
la connexion doit recevoir (messages du groupe 2). Le terme « x xxxx x » représente les 6 bits de l’adresse du
nœud DeviceNet. Le terme « ••• » représente l’ID du message.
Exemple : 0x0452 = 2#100 0101 0010 (messages du groupe 2 ; ID des messages = 2 ; passerelle située à
l’adresse 10).
0x06
0x07
Get/Set Caractéristiques initiales de la
Requis
BYTE
0x01
comm.
Cet attribut définit le ou les Groupes de Messages par lesquels les productions et les consommations associées
à l’objet « Change-of-State / Cyclic (Acknowledged) Connection » sont effectuées. Dans le cas présent, il
désigne les groupes 1 et 2. Reportez-vous aux chapitres 3-2. et 5-4.3.6. du tome I des spécifications DeviceNet
pour de plus amples détails à ce sujet.
Get/Set Taille des productions de la
Requis
UINT
connexion
(taille de la zone
d’entrée)
Nombre maximum d’octets pouvant être transmis via la connexion de cette instance. La valeur de cet attribut doit
être égale à la taille de la zone d’entrée choisie à l’aide de l’attribut 0x0E. Dans le cas de la configuration par
défaut de la passerelle LUFP9, la valeur de cet attribut est égale à 0, car aucune zone d’entrée n’est attribuée à
l’objet « Change-of-State / Cyclic (Acknowledged) Connection ».
0x08
Get/Set Taille des consommations de la
Requis
UINT
0
connexion
Nombre maximum d’octets pouvant être reçus via la connexion de cette instance. Puisque la passerelle LUFP9
ne consomme aucune donnée via cette connexion, la valeur de cet attribut restera égale à 0.
0x09
Get/Set Fréquence prévisionnelle des
Requis
UINT
0 (unité = 1 ms,
échanges (Expected_packet_rate)
par pas de 10 ms)
Cet attribut définit la périodicité des échanges effectués via les connexions de cette instance.
0x0C
Get/Set Action sur déclenchement du chien de
Requis
USINT
0
garde
Cet attribut définit l’action entreprise sur déclenchement du chien de garde ou sur inactivité de la connexion. Les
différentes valeurs possibles sont les suivantes : 0 (Passage en timeout), 1 (Suppression Automatique), 2 (RAZ
Automatique) et 3 (Suppression Différée).
0x0D
Get/Set Productions : Longueur du chemin
Requis
UINT
Taille du tableau d’USINT de l’attribut 0x0E (chemin des productions de la connexion).
0x0E
Get/Set Productions : Chemin de la connexion
USINT […]
(chemin de la zone)
Requis
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est utilisé pour
produire les données de la connexion. Dans le cas présent, le chemin de production pour la connexion
« Change-of-State / Cyclic (Acknowledged) Connection » correspond à la zone de sortie qui a été affectée à
cette connexion à l’aide du paramètre EDS « COS production ».
0x0F
Get/Set Consommations : Longueur du
Requis
UINT
0
4
chemin
Taille du tableau d’USINT de l’attribut 0x10 (chemin des consommations de la connexion).
0x10
Get/Set Consommations : Chemin de la
Requis
USINT […]
(chemin de la zone)
connexion
Cet attribut définit le chemin local (sans MAC ID) de l’objet DeviceNet de la passerelle qui est destiné à recevoir
les données consommées par la connexion. Dans le cas présent, le chemin de consommation pour la connexion
« Change-of-State / Cyclic (Acknowledged) Connection » désigne l’instance 0x01 de la classe 0x2B, c’est-à-dire
l’unique objet de la classe « Acknowledge Handler Object ».
NOTE : Le fichier EDS fourni avec la passerelle ne contient pas de paramètre dont la modification aurait une
quelconque influence sur la valeur de cet attribut.
119
Annexe D : Objets DeviceNet
Attributs des instances 0x01 à 0x04 de la classe 0x05
Nom du service
Besoin
Description
0x0E
Get_Attribute_Single
Requis
0x10
Set_Attribute_Single
Option
Ce service permet de lire la valeur d’un attribut de l’une des
instances du « Connection Object ».
Ce service permet d’écrire la valeur d’un attribut de l’une des
instances du « Connection Object ».
Code du
service
Acknowledge Handler Object (classe 0x2B)
L’objet « Acknowledge Handler » ne possède qu’une seule instance (Instance ID = 0x01). Cet objet est utilisé
par les connexions dont le producteur a besoin de savoir si ses données ont été reçues par son, ou ses,
destinataires (consommateurs). Cet objet est décrit dans le chapitre 6-31. du tome II des spécifications
DeviceNet.
Attributs de la classe 0x2B
Besoin
Type
0x01
ID
Accès Nom
Get
Revision
Option
UINT
Valeur Description
1
0x02
Get
Instance
maximum
Option
UINT
1
Indice de révision de la classe du « Acknowledge
Handler Object ».
Numéro maximum de chacune des instances créées
au sein de la classe « Acknowledge Handler Object ».
Services de la classe 0x2B
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Requis
Ce service permet de lire la valeur de l’un des attributs de la classe.
Attributs de l’instance 0x01 de la classe 0x2B
ID
0x01
0x02
Accès
Nom
Besoin
Type
Valeur
Get/Set Temporisation d’acquittement
Requis
UINT
20 (unité : 1ms)
La valeur de cet attribut détermine la durée de l’attente de l’acquittement du message d’une connexion. Une fois
cette durée écoulée, la passerelle procède à la ré-émission du message qui vient de ne pas être acquitté. La
valeur de cet attribut doit être comprise entre 1 et 65 535, et sa valeur par défaut est égale à 20.
Get/Set Nombre de ré-émissions
Requis
USINT
1
Cet attribut détermine le nombre maximum autorisé de déclenchements successifs du timeout d’acquittement
pour un même message, et donc le nombre de ré-émissions autorisé pour chaque message. La valeur de cet
attribut doit être comprise entre 0 et 255, et sa valeur par défaut est égale à 1.
0x03
0x04
Get/Set Instance de la connexion COS
Requis
UINT
4
productrice
La valeur de cet attribut est égale au numéro de l’instance (Instance ID) de la classe « Connection Object » qui
correspond à la connexion de type « Change-of-State » associée à l’objet « Acknowledge Handler ». Cette
association permet à ce dernier de transmettre les acquittements qu’il reçoit à la connexion correspondante s’ils
sont destinés à celle-ci.
Get
Taille de la liste des acquittements
Option
BYTE
1
Cet attribut représente le nombre maximum de membres qu’il est possible de placer dans la liste des
acquittements. Si la valeur de cet attribut est nulle, la taille de la liste est dynamique, ce qui n’est pas le cas de la
passerelle LUFP9.
0x05
Liste des acquittements
Get
Option
BYTE , USINT […]
0 , (liste vide)
Cet attribut correspond à la liste des instances actives de la classe « Connection Object » pour lesquelles la
réception d’un acquittement est nécessaire. Il est composé de deux éléments : le nombre de membres (BYTE) et
la liste des numéros des instances de la classe « Connection Object » associées (USINT […]). La taille de la liste
est égale à la valeur du premier élément. Par défaut, la liste est vide (absence du terme de type USINT […]) et
seul l’élément BYTE est créé.
Exemple : « 1, 4 » pour une liste ne comportant qu’une seule instance de la classe « Connection Object ». Cette
instance (0x04) correspond à la connexion « Change-of-State / Cyclic (Acknowledged) Connection ».
120
Annexe D : Objets DeviceNet
ID
Accès
0x06
Get
Nom
Besoin
Type
Valeur
Taille de la liste des chemins des
données d’acquittement
Option
BYTE
1
Cet attribut représente le nombre maximum de membres qu’il est possible de placer dans la liste des chemins
des données d’acquittement. Si la valeur de cet attribut est nulle, la taille de la liste est dynamique, ce qui n’est
pas le cas de la passerelle LUFP9.
0x07
Get
Liste des chemins des données
d’acquittement
Option
BYTE , ( UINT , USINT, (liste des chemins des
USINT […] ) […]
données
d’acquittement)
Cet attribut correspond à la liste des associations « instance de connexion / objet applicatif consommateur »
permettant de rediriger les données reçues dans un acquittement. Un acquittement ne contient pas
forcément des données et cet attribut est donc optionnel. Celui-ci est composé des éléments suivants :
• Le nombre de membres de la liste (BYTE).
• La liste des associations « instance de connexion / objet applicatif consommateur » ( UINT , USINT,
USINT […] ) […]. La taille de cette liste est égale à la valeur du premier élément, décrit ci-dessus, et elle
est elle-même composée des éléments suivants :
- Le numéro de l’instance de la connexion COS acquittée (UINT).
- La longueur du chemin de l’objet DeviceNet destiné à recevoir les données de l’acquittement
(USINT).
- Le chemin de l’objet DeviceNet destiné à recevoir les données de l’acquittement (USINT […])
Exemple : 0x 01 00 04 06 20 04 24 98 30 01. La valeur de cet attribut signifie que cette liste ne contient qu’un
seul élément (0x01), celui-ci faisant référence à l’instance 0x0004 et que le chemin des données
d’acquittement (0x06 : longueur de 6 octets) fait référence à l’attribut 0x01 de l’instance 0x98 de la classe
0x04, c’est-à-dire aux données de la zone de sortie n°1, c’est-à-dire « Output1 ».
Services de l’instance 0x01 de la classe 0x2B
Code du service
Nom du service
Besoin Description
0x0E
Get_Attribute_Single
0x10
Set_Attribute_Single
Requis Ce service permet de lire la valeur d’un attribut de l’unique instance
du « Acknowledge Handler Object ».
Requis Ce service permet d’écrire la valeur d’un attribut de l’unique
instance du « Acknowledge Handler Object ».
121
Annexe D : Objets DeviceNet
I/O Data Input Mapping Object (classe 0xA0)
L’objet « I/O Data Input Mapping Object » ne possède qu’une seule instance (Instance ID = 0x01) et est
spécifique à la passerelle LUFP9. Il contient l’ensemble des données de l’unique zone d’entrée de la passerelle.
L’unique attribut (Attribute ID = 0x01) de l’instance de cet objet est associé à la zone d’entrée « Input1 ». Cette
zone d’entrée couvre l’ensemble des emplacements mémoire recevant une donnée issue d’une réponse
Modbus.
Attributs de la classe 0xA0
ID
Accès Nom
0x01
Get
Revision
Besoin
Type
Option
UINT
0x64
Get/Set Input1 offset
Option
USINT
0x6E
Get/Set Input1 length
Option
USINT
Valeur Description
1
Indice de révision de la classe du « I/O Data Input
Mapping Object ».
0x0000 Adresse relative du début de la zone d’entrée n°1. (1)
0x0020 Taille, exprimée en octets, de la zone d’entrée n°1. (1)
(1) Ces 2 attributs correspondent aux paramètres « Param6 » et « Param7 » référencés par le fichier EDS
fourni avec la passerelle. Leur accès en écriture (Accès = Set) est réservé aux outils de configuration
DeviceNet, puisqu’il permet de modifier l’emplacement ou la taille de cette zone de données d’entrée. Le
service « Set_Attribute_Single » ne devra donc pas être utilisé avec ces attributs. La modification de l’un
de ces deux attributs a des conséquences directes sur l’attribut 0x01 de l’instance 0x01 de l’objet « I/O
Data Input Mapping » (taille des données). Cet attribut n’est pas créé si la taille de la zone d’entrée de la
passerelle est nulle. L’attribut « Input1 offset » correspond à un décalage depuis le début de la zone
mémoire réservée aux données d’entrée (0x0000).
Les valeurs situées dans la colonne « Valeur » correspondent à la configuration par défaut de la
passerelle LUFP9 (zone « Input1 » située à l’adresse 0x0000 et comportant 32 octets).
Services de la classe 0xA0
Code du
service
0x0E
Nom du service
Besoin
Get_Attribute_Single
Requis
Description
Ce service permet de lire la valeur de l’un des attributs de la
classe.
Attributs de l’instance 0x01 de la classe 0xA0
ID
Accès
0x01
Get
Nom
Besoin
Type
Valeur
Données
Option
USINT […]
(zone d’entrée n°1)
Cet attribut correspond à la zone d’entrée « Input1 » de la passerelle. Sa lecture permet d’obtenir les valeurs
de l’ensemble des données contenues dans cette zone sous la forme d’un tableau d’octets dont la taille
correspond à celle de la zone. Ce même attribut est également impliqué dans l’utilisation de l’instance Assembly
Object décrite dans l’Appendix E: Commandes Modbus.
NOTE : Dans le cas de la configuration par défaut, l’attribut 0x01 correspond à un tableau de 32 octets dont
le contenu est décrit dans l’Exemple d’utilisation (RSLogix 500), Zone mémoire des données d’entrée.
Services de l’instance 0x01 de la classe 0xA0
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Requis
Ce service permet de lire le tableau de valeurs du seul attribut de
l’unique instance du « I/O Data Input Mapping Object ».
122
Annexe D : Objets DeviceNet
I/O Data Output Mapping Object (classe 0xA1)
L’objet « I/O Data Output Mapping Object » ne possède qu’une seule instance (Instance ID = 0x01) et est
spécifique à la passerelle LUFP9. Il contient l’ensemble des données de l’unique zone de sortie de la passerelle.
L’unique attribut (Attribute ID = 0x01) de l’instance de cet objet est associé à la zone de sortie « Output1 ». Cette
zone de sortie couvre l’ensemble des emplacements mémoire dont les valeurs sont transmises aux esclaves
Modbus via des requêtes Modbus.
Attributs de la classe 0xA1
ID
Accès Nom
0x01
Get
Revision
Besoin
Type
Option
UINT
0x64
Get/Set Output1 offset
Option
USINT
0x6E
Get/Set Output1 length
Option
USINT
Valeur Description
1
Indice de révision de la classe du « I/O Data Output
Mapping Object ».
0x0000 Adresse relative du début de la zone de sortie n°1. (1)
0x0020 Taille, exprimée en octets, de la zone de sortie n°1. (1)
(1) Ces 2 attributs correspondent aux paramètres « Param18 » et « Param19 » référencés par le fichier EDS
fourni avec la passerelle. Leur accès en écriture (Accès = Set) est réservé aux outils de configuration
DeviceNet, puisqu’il permet de modifier l’emplacement ou la taille de cette zone de données de sortie. Le
service « Set_Attribute_Single » ne devra donc pas être utilisé avec ces attributs. La modification de l’un
de ces deux attributs a des conséquences directes sur l’attribut 0x01 de l’instance 0x01 de l’objet « I/O
Data Output Mapping » (taille des données). Cet attribut n’est pas créé si la taille de la zone de sortie de
la passerelle est nulle. L’attribut « Output1 offset » correspond à un décalage depuis le début de la zone
mémoire réservée aux données de sortie (0x0200).
Les valeurs situées dans la colonne « Valeur » correspondent à la configuration par défaut de la
passerelle LUFP9 (zone « Output1 » située à l’adresse 0x0200 et comportant 32 octets).
Services de la classe 0xA1
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Requis
Ce service permet de lire la valeur de l’un des attributs de la
classe.
Attributs de l’instance 0x01 de la classe 0xA1
ID
0x01
Accès
Nom
Get/Set Données
Besoin
Type
Valeur
Option
USINT […]
(zone de sortie n°1)
Cet attribut correspond à la zone d’entrée « Output1 » de la passerelle. Sa lecture permet d’obtenir les
valeurs de l’ensemble des données contenues dans cette zone, et son écriture permet de les modifier. Ces
valeurs prennent la forme d’un tableau d’octets dont la taille correspond à celle de la zone. Ce même attribut
est également impliqué dans l’utilisation de l’instance 0x96 de l’objet « Assembly Object », décrite dans
l’Appendix E: Commandes Modbus.
NOTE : Dans le cas de la configuration par défaut, l’attribut 0x01 correspond à un tableau de 32 octets dont le
contenu est décrit dans l’Exemple d’utilisation (RSLogix 500), Zone mémoire des données de sortie.
Services de l’instance 0x01 de la classe 0xA1
Nom du service
Besoin
Description
0x0E
Get_Attribute_Single
Option
Ce service permet de lire le tableau de valeurs du seul attribut
de l’unique instance du « I/O Data Output Mapping Object ».
0x10
Set_Attribute_Single
Requis
Ce service permet d’écrire / de modifier toutes les valeurs du seul
attribut de l’unique instance du « I/O Data Output Mapping
Code du
service
Object ».
123
Annexe D : Objets DeviceNet
Diagnostic Object (Classe 0xAA)
L’objet « Diagnostic Object » ne possède qu’une seule instance (Instance ID = 0x01) et est spécifique à la
passerelle LUFP9. Il contient un grand nombre de données de diagnostic de tous niveaux. Par conséquent,
certaines d’entre elles ne devront pas être utilisées dans le cadre de la mise en œuvre de la passerelle, car elles
sont réservées aux opérations de maintenance effectuées sur la passerelle ou lors du développement de son
logiciel. Cependant, les attributs auxquels elles correspondent sont tous décrits ci-dessous dans un souci
d’exhaustivité.
Attributs de la classe 0xAA
ID
0x01
Accès Nom
Get
Revision
Besoin
Type
Option
UINT
Valeur Description
1
Indice de révision de la classe de l’objet « Diagnostic Object ».
Services de la classe 0xAA
Code du Nom du service
service
0x0E
Get_Attribute_Single
Besoin
Description
Requis
Ce service permet de lire la valeur de l’un des attributs de la classe.
Attributs de l’instance 0x01 de la classe 0xAA
ID
0x01
0x02
Accès Nom
Besoin
Type
Valeur
Get
Option
UDINT
(variable)
Numéro de série du module DeviceNet
La valeur du « numéro de série du module DeviceNet » correspond au numéro de série de la carte AnyBus-S
DeviceNet de la passerelle, c’est-à-dire la carte sur laquelle sont situés le bloc de commutateurs et le
connecteur DeviceNet. Exemple : 0x 20 DD 00 23.
Get
Identifiant du vendeur
Option
UINT
0x0001
La valeur de cet attribut est égale à 0X0001 dans le cas de la passerelle LUFP9.
Il est impossible d’utiliser la valeur 0x0000 et les valeurs comprises entre 0x0002 et 0xFFFF sont réservées pour
les fournisseurs de la passerelle.
0x03
Get
Type du réseau amont
Option
UINT
0x0025
Dans le cas de la passerelle LUFP9, cet attribut prend toujours la même valeur (0x0025), puisqu’il caractérise
le réseau DeviceNet. Toute autre valeur serait erronée (exemple : 0x0001 pour un réseau Profibus-DP).
0x04
Get
Version du logiciel du module DeviceNet
Option
UINT
0x0105
Cet attribut indique la version du logiciel présent dans la carte AnyBus-S DeviceNet de la passerelle. L’indice
majeur de cette version est donné par l’octet de poids fort et son indice mineur est donné par l’octet de poids
faible, tous deux au format BCD. Exemple : 0x0105 correspond à la version 01.05.
0x05
Get
Compteur d’interruptions
Option
UINT
(compteur)
La valeur du « compteur d’interruptions » est incrémentée d’une unité à chaque fois qu’une interruption liée à la
gestion du réseau aval Modbus se produit.
0x06
Get
Compteur en entrée du chien de garde
Option
UINT
0x0000
Ce compteur n’est pas implémenté. L’utilisation de cet attribut est donc inutile.
La fonction première de ce compteur consiste à assurer un feedback du compteur de vie représenté par
l’attribut 0x07, ce qui permettrait à la carte AnyBus-S DeviceNet de s’assurer que la carte à laquelle elle est
connectée fonctionne correctement en comparant les valeurs de ces deux attributs.
0x07
0x08
Get
Option
UINT
(compteur)
Compteur de sortie du chien de garde
La valeur de ce compteur est incrémentée d’une unité toutes les millisecondes (au minimum une écriture toutes
les 50 ms) et fait fonction de compteur de vie interne, à l’attention de la carte applicative de la passerelle, c’està-dire la carte à laquelle se superpose la carte AnyBus-S DeviceNet.
Get Etat de la méthode d’accès
Option
USINT [4]
0x 40 00 00 80
Ce tableau de 4 éléments de type USINT détermine l’état de la méthode d’accès aux zones générales de la
mémoire de la passerelle. Cet attribut n’est pas utile dans le cadre de la mise en œuvre de la passerelle.
124
Annexe D : Objets DeviceNet
ID
Accès
0x09
Get
Nom
Besoin
Type
Valeur
Etat des DEL
Option
USINT [6]
(variable)
Les valeurs des éléments de cet attribut correspondent à l’état des 6 DEL de la passerelle (1 octet par
DEL). Le premier octet correspond à la DEL c, le deuxième à la DEL d, etc., jusqu’à la DEL h. Chaque
octet prend l’une des valeurs suivantes pour désigner l’état de la DEL à laquelle il correspond : 0x00 (DEL
éteinte), 0x01 (DEL verte) ou 0x02 (DEL rouge).
0x0A
Get
Type de module
Option
UINT
0x0101
La valeur de cet attribut est toujours égale à 0x0101 dans le cas de la passerelle LUFP9, car il s’agit d’un
module de type « AnyBus-S ».
0x0B
Get
Etat du module DeviceNet
Option
USINT
(registre de 8 bits)
La lecture des bits de cet attribut permet de connaître certains renseignements sur l’état de la carte AnyBus-S
DeviceNet de la passerelle. Les quatre bits utiles de ces registres sont décrits ci-dessous :
Bit 0 : Passerelle hors ligne (0) / en ligne (1) sur le réseau DeviceNet.
Bit 1 : Toutes les sorties sont remises à zéro (0) ou maintenues (1) dans la zone mémoire de sortie si la
passerelle est hors ligne sur le réseau DeviceNet.
Bit 8 : Toutes les entrées sont remises à zéro (0) ou maintenues (1) dans la zone mémoire d’entrée si
l’application de la passerelle est arrêtée.
Bit 9 : Registre d’indication de changement d’état des sorties désactivé (0) / activé (1).
0x0C
Get
Changement d’état des sorties
Option
LWORD
—
Chacun des bits de ce registre de 64 bits indique si le contenu de 8 octets consécutifs de la zone mémoire de
sortie a été modifié. Le bit 0 concerne les octets 0x0200 à 0x0207, le bit 1 concerne les octets 0x0208 à
0x0215, etc., jusqu’au bit 63, qui concerne les octets 0x03F8 to 0x03FF.
0x0D
Get
Causes de l’interruption
Option
BYTE
(registre de 8 bits)
Ce registre permet de déterminer la cause de la dernière interruption survenue. Chaque bit est activé lorsque
l’événement associé se produit, puis il est remis à zéro par le gestionnaire d’interruption de la passerelle. Ce
registre n’est donc pas destiné à être utilisé par le maître DeviceNet.
Bit 0 : Passage de la passerelle en ligne sur le réseau DeviceNet.
Bit 1 : Passage de la passerelle hors ligne sur le réseau DeviceNet.
Bit 2 : Modification des données.
0x0E
Get
Notification d’interruption
Option
BYTE
(registre de 8 bits)
Ce registre permet de déterminer quels types d’interruptions sont autorisés (voir description de l’attribut 0x0D).
Sa valeur est fixée lors de l’initialisation de la passerelle, au moyen d’un télégramme spécifique (non décrit
dans ce guide).
Bit 0 : Génération d’une interruption lors du passage en ligne de la passerelle sur le réseau DeviceNet.
Bit 1 : Génération d’une interruption lors du passage hors ligne de la passerelle sur le réseau DeviceNet.
Bit 2 : Génération d’une interruption lors d’une modification des données ; pour cela, le registre de
changement d’état des sorties doit être activé (voir description du bit 9 de l’attribut 0x0B).
0x0F
0x10
Get
Option
UINT
0x0020
Taille des entrées cycliques
Cet attribut indique la taille totale des données d’entrée cycliques (I/O IN data), exprimée en nombre
d’octets. Cette taille couvre l’ensemble de l’espace mémoire de la passerelle occupé par les données
d’entrée Modbus, les emplacements libres étant également comptabilisés. Dans le cas de la configuration par
défaut de la passerelle LUFP9, la valeur de cet attribut correspond à la taille de la zone d’entrée de la
passerelle, c’est-à-dire 32 octets.
Get
Option
UINT
0x0020
Taille des entrées en DPRAM
Cet attribut indique la taille totale des données et des paramètres d’entrée dans la mémoire de la
passerelle (valid IN bytes in DPRAM), exprimée en nombre d’octets. Cette taille couvre l’ensemble de
l’espace mémoire de la passerelle occupé par les données et les paramètres d’entrée Modbus, les
emplacements libres étant également comptabilisés. Puisque aucun paramètre d’entrée n’est défini, les valeurs
des attributs 0x0F et 0x10 sont toutes deux identiques. Dans le cas de la configuration par défaut de la
passerelle LUFP9, la valeur de cet attribut est égale à 32 octets.
125
Annexe D : Objets DeviceNet
ID
Accès
0x11
Get
0x12
Nom
Besoin
Type
Valeur
Option
UINT
0x0020
Taille totale des entrées étendues
Cet attribut indique la taille totale des données d'entrée utilisées dans la mémoire interne étendue de la
passerelle (IN bytes supported), exprimée en nombre d'octets. Cette taille est égale à la valeur de l’attribut
précédent (taille des entrées en DPRAM), car elle ne contient que des données d’entrée. Les valeurs des
attributs 0x0F, 0x10 et 0x11 sont toutes identiques. Dans le cas de la configuration par défaut de la
passerelle LUFP9, la valeur de cet attribut est égale à 32 octets.
NOTE : La mémoire interne étendue de la passerelle est différente de la mémoire DPRAM, dont il est
question dans le reste du présent guide. Par conséquent, vous n’aurez pas à vous en soucier dans le cadre
d’une utilisation normale de la passerelle.
Get
Taille des sorties cycliques
Option
UINT
0x0020
Cet attribut indique la taille totale des données de sortie cycliques (I/O OUT data), exprimée en nombre
d’octets. Cette taille couvre l’ensemble de l’espace mémoire de la passerelle occupé par les données de
sortie Modbus, les emplacements libres étant également comptabilisés. Dans le cas de la configuration par
défaut de la passerelle LUFP9, la valeur de cet attribut correspond à la taille de la zone de sortie de la
passerelle, c’est-à-dire 32 octets.
0x13
0x14
Get
Taille des sorties en DPRAM
Option
UINT
0x0020
Cet attribut indique la taille totale des données et des paramètres de sortie dans la mémoire de la
passerelle (valid OUT bytes in DPRAM), exprimée en nombre d’octets. Cette taille couvre l’ensemble de
l’espace mémoire de la passerelle occupé par les données et les paramètres de sortie Modbus, les
emplacements libres étant également comptabilisés. Puisque aucun paramètre de sortie n’est défini, les valeurs
des attributs 0x12 et 0x13 sont toutes deux identiques. Dans le cas de la configuration par défaut de la
passerelle LUFP9, la valeur de cet attribut est égale à 32 octets.
Get
Option
UINT
0x0020
Taille totale des sorties étendues
Cet attribut indique la taille totale des données de sortie utilisées dans la mémoire interne étendue de la
passerelle (OUT bytes supported), exprimée en nombre d’octets. Cette taille est égale à la valeur de
l’attribut précédent (taille des sorties en DPRAM), car elle ne contient que des données de sortie. Les valeurs
des attributs 0x12, 0x13 et 0x14 sont toutes identiques. Dans le cas de la configuration par défaut de la
passerelle LUFP9, la valeur de cet attribut est égale à 32 octets.
NOTE : La mémoire interne étendue de la passerelle est différente de la mémoire DPRAM, dont il est
question dans le reste du présent guide. Par conséquent, vous n’aurez pas à vous en soucier dans le cadre
d’une utilisation normale de la passerelle.
0x15
Attribut réservé
Cet attribut n’est pas utilisé.
0x16
Option
USINT
(registre de 8 bits)
Indicateurs applicatifs
Ce registre de 8 bits est réservé à la carte applicative de la passerelle, c’est-à-dire à la carte à laquelle se
superpose la carte AnyBus-S DeviceNet. Les différents bits de ce registre sont principalement utilisés lorsque
des commandes internes à la passerelle sont destinées à agir sur la mémoire de la passerelle. Ces bits ne
sont pas destinés à être utilisés par le maître DeviceNet et ne seront pas décrits ici.
Get
Option
USINT
(registre de 8 bits)
Indicateurs AnyBus
Ce registre de 8 bits est réservé pour la carte AnyBus-S DeviceNet de la passerelle. Les différents bits de ce
registre sont principalement utilisés lorsque des commandes internes à la passerelle sont destinées à agir
sur la mémoire de la passerelle. Ces bits ne sont pas destinés à être utilisés par le maître DeviceNet et ne
0x17
Get
Option
UINT
0x0000
Get
seront pas décrits ici, sauf le bit 4 :
Bit 4 : Ce bit est mis à un une fois que la carte AnyBus-S DeviceNet de la passerelle est initialisée.
Services de l’instance 0x01 de la classe 0xAA
Code du
service
0x0E
Nom du service
Besoin
Description
Get_Attribute_Single
Requis
Ce service permet de lire la valeur d’un attribut de l’unique instance
du « Diagnostic Object ».
126
Appendix E: Commandes Modbus
Les seules commandes Modbus
autorisées par la passerelle sont
présentées ci-contre. La structure des
trames de la requête et de la réponse
de chacune d’entre elles est ensuite
décrite dans les chapitres suivants.
Code fonction
Diffusion (1)
Commande Modbus
03
0x03
—
Read Holding Registers
06
0x06
Oui
Preset Single Register
16
0x10
Oui
Preset Multiple Registers
(1) Cette colonne indique si la commande peut être ajoutée (« Oui ») ou non (« — ») dans la liste des
commandes d’un nœud de diffusion, appelé « Broadcaster » dans ABC-LUFP Config Tool.
Dans les chapitres suivants, chacun des octets des
trames de la requête et de la réponse d’une
commande Modbus sont décrits, les uns après les
autres, à l’exception des champs représentés cicontre. Ceux-ci sont systématiquement présents dans
les requêtes et les réponses de toutes les
commandes Modbus.
Les champs « Slave Address » et « Function »
constituent les deux premiers octets de ces trames.
Les deux octets du « Checksum » constituent leurs
deux derniers octets.
Slave Address
Function
… Autres
champs …
Cheksum (Lo)
Cheksum (Hi)
- Valeur non modifiable (adresse
Modbus : 1 à 247 ; adresses 65, 126
et 127 réservées)
- Valeur non modifiable (code de la
commande Modbus)
… Spécificités des
commandes Modbus …
- Type du contrôle d’erreur
- N° du 1er octet contrôlé
Les descriptions des trames Modbus qui figurent dans les chapitres suivants sont principalement destinées à
vous aider à configurer les échanges Modbus de la passerelle à l’aide de ABC-LUFP Config Tool. Reportezvous à la documentation des esclaves Modbus pour prendre connaissance des limites d’utilisation de ces
trames pour chacun d’eux (nombre de registres pouvant être lus ou écrits en une seule commande Modbus, par
exemple).
Il est préférable que vous vous procuriez un document Modbus standard, tel que le guide intitulé Modicon
Modbus Protocol Reference Guide (réf. : PI-MBUS-300 Rev. J), afin de pouvoir faire la correspondance entre les
éléments affichés dans ABC-LUFP Config Tool et le contenu des trames Modbus correspondantes. Voici un
exemple de correspondance pour une trame complète (y compris les champs de début et de fin de trame
présentés ci-dessus), basée sur la commande Read Holding Registers.
Champs des trames Modbus
Requête
Modbus
Slave Address
Function Code
Starting Register Address (Hi, Lo)
Number of points (Hi, Lo)
Checksum
Réponse
Modbus
Slave Address
Function Code
Byte count
Data
Checksum
Eléments sous
ABC-LUFP Config Tool
Slave Address
Function Code
Starting address
Quantity of Registers
CRC16
Taille
1 octet
1 octet
2 octets
2 octets
2 octets
Slave Address
Function Code
Byte Count
First Register Value
…………………………………
Last Register Value
CRC16
1 octet
1 octet
1 octet
2 octets
…………
2 octets
2 octets
127
Annexe E : Commandes Modbus
Le chapitre 6.11 Ajout et paramétrage d’une commande Modbus présente lui aussi quelques exemples de
correspondance entre les éléments affichés dans ABC-LUFP Config Tool et les champs des trames Modbus
correspondantes.
Voir également : Chapitre 6.11.2 Cas d’un esclave Modbus générique, et chapitre 6.11.3 Ajout d’une
commande Modbus spéciale, dans le cas où l'implémentation de l'une de ces commandes serait incompatible
avec son implémentation dans la passerelle, par exemple Il devient alors nécessaire de créer une commande
Modbus spéciale afin de palier cette incompatibilité.
Commande « Read Holding Registers » (0x03)
Trame
Champ ABC-LUFP
Config Tool
Requête Starting Register Address
Number of Registers
Checksum
Réponse Byte Count
Data (premier registre)
………
Data (dernier registre)
Checksum
Valeur ou propriétés
- Adresse du registre
- Nombre de registres
- CRC16
- Nombre d'octets de données = nombre de registres × 2
- Byte swap = « Swap 2 bytes »
- Data length = Valeur du champ « Byte count »
- Data location = Adresse dans la mémoire d'entrée de la passerelle
- CRC16
Commande « Preset Single Register » (0x06)
Trame
Requête
Réponse
Champ ABC-LUFP
Config Tool
Register Address
Valeur ou propriétés
Preset Data
- Byte swap = « Swap 2 bytes »
- Data length = 0x0002
- Data location = Adresse dans la mémoire de sortie de la passerelle
Register Address
Preset Data
Checksum
- Adresse du registre
- Byte swap = « Swap 2 bytes »
- Data length = 0x0002
- Data location = Adresse dans la mémoire d'entrée de la passerelle
- CRC16
NOTE : Etant donné que la réponse de l'esclave fait écho à la requête, vous n'avez pas besoin de la charger au
niveau du scanner DeviceNet.
128
Annexe E : Commandes Modbus
Commande « Preset Multiple Registers » (0x10)
Trame
Champ ABC-LUFP
Config Tool
Requête Starting Register Address
Number of Registers
Byte Count
Data (premier registre)
Valeur ou propriétés
- Adresse du 1er registre
- Nombre de registres
- Nombre d'octets de données = nombre de registres × 2
- Byte swap = « Swap 2 bytes »
………
Data (dernier registre)
- Data length = Valeur du champ « Byte count »
- Data location = Adresse dans la mémoire de sortie de la passerelle
Checksum
- CRC16
Réponse Starting Register Address
- Adresse du 1er registre
Number of Registers
- Nombre de registres
Checksum
- CRC16
Réponses d’exception du protocole Modbus
Lorsqu’il est dans l’impossibilité d’exécuter une commande dictée par une requête Modbus, un esclave envoie
une réponse d’exception à la place de la réponse normale à la requête.
AVERTISSEMENT
FONCTIONNEMENT SANS SURVEILLANCE DU SYSTEME
Dans le cas des commandes Modbus standard, la passerelle LUFP9 considère que toutes les réponses
d’exception qu’elle reçoit de la part des esclaves Modbus sont des réponses erronées. Par conséquent, elle
effectuera les ré-émissions configurées pour les requêtes incriminées.
Si vous désirez que le logiciel applicatif de votre maître DeviceNet puisse gérer les réponses d'exception, vous
avez la possibilité de remplacer la commande Modbus, dans ABC-LUFP Config Tool, par une commande
personnalisée (voir chapitre 6.11.3.2 Commandes Modbus personnalisables) Cela permet alors de remonter
les champs « Slave Address » et « Function » jusqu’au maître DeviceNet.
Le non-respect de ces instructions peut entraîner la mort, de graves blessures ou des dommages
matériels.
La structure d’une réponse d’exception est indépendante de la commande Modbus associée au champ
« Function » de la requête incriminée. L’intégralité de la trame d’une réponse d’exception est présentée cidessous :
Slave Address
Function
Exception Code
Cheksum (Lo)
Cheksum (Hi)
Adresse Modbus (1 à 247 ; adresses 65, 126 et 127 réservées) : La valeur de ce champ est
identique à celle du champ « Slave Address » de la requête incriminée.
Code de la commande, avec indicateur d’exception : La valeur de ce champ est égale à
0x80 + la valeur du champ « Function » de la requête incriminée.
Code indiquant la nature de l’erreur qui est à l’origine de la réponse d’exception (voir
tableau présenté sur la page suivante).
Contrôle d’erreur.
129
Annexe E : Commandes Modbus
Code
0x01
0x02
0x03
0x04
0x05
(1)
0x06
(1)
0x07
(1)
0x08
(1)
Nom de
Description de l’exception
l’exception
ILLEGAL FUNCTION La commande « Function » de la requête n’est pas implémentée dans le logiciel
de l’esclave Modbus, ou bien celui-ci n’est pas en mesure de l’exécuter pour
l’instant.
ILLEGAL DATA
La combinaison des champs « Starting Address » et « No. of Registers » de la
ADDRESS
requête (ou champs assimilés) donne accès à une ou plusieurs adresses non
accessibles sur l’esclave Modbus.
La valeur de l’un des champs de la requête Modbus est hors limites autorisées.
ILLEGAL DATA
Cette erreur ne concerne pas le contenu des champs « Data » (ou assimilés),
VALUE
car cette erreur ne tient compte que des champs utiles à la gestion du protocole
Modbus.
SLAVE DEVICE
Une erreur irrémédiable s’est produite lors de l’exécution de la commande.
FAILURE
ACKNOWLEDGE
L’esclave Modbus informe la passerelle qu’il a pris en compte la commande
(acquittement), mais que son exécution est trop longue pour qu’il puisse se
permettre d’attendre qu’elle soit menée à terme avant de pouvoir émettre une
réponse.
La passerelle devra émettre des requêtes ultérieures afin de déterminer si la
commande est achevée ou non.
L’esclave Modbus informe la passerelle qu’il est déjà en train d’exécuter une
SLAVE DEVICE
BUSY
commande et qu’il ne peut donc pas exécuter celle qui lui est transmise.
La passerelle devra donc ré-émettre la requête ultérieurement.
L’esclave Modbus informe la passerelle qu’il n’est pas en mesure d’exécuter la
NEGATIVE
ACKNOWLEDGE
commande demandée. Cette exception ne concerne que les commandes 13 et
14 (0x0D et 0x0E). Ces fonctions ne font pas partie des commandes Modbus
standard et ne sont pas décrites dans le document présent.
MEMORY PARITY L’esclave Modbus informe la passerelle qu’il a détecté une erreur de parité lors
ERROR
de l’accès à sa propre mémoire. Cette exception ne concerne que les
commandes standard 20 et 21 (0x14 et 0x15). Ces commandes ne sont pas
supportées par la passerelle.
(1) Reportez-vous à la documentation Modbus standard pour de plus amples renseignements au sujet de ces
différents cas de figure.
130
Index
Esclaves Modbus, 9, 10
A
Adresse, 22
Adresse MAC ID, 33
Allen Bradley
SLC500, 38
Architecture, 9, 26
Automate maître DeviceNet, 32
B
Boîtier de dérivation TSXCA50, 19
Boîtier de dérivation VW3 A8 306 TF3, 19
Boîtiers de dérivation, 17
C
Câble Modbus, 19
Câble VW3 A68 306, 17
Communications
apériodiques, 36, 37, 38
périodiques, 36, 37, 38
Commutateur, 21
Connecteur RJ45, 12, 17
F
Fichier EDS, 32
P
Paramètres, 33
Prise abonnés 2 voies TSXSCA62, 19
Protective Earth, 13
R
Rail DIN, 13
Répartiteur LU9GC03, 19
Résistance de ligne, 20
RSLogix 500, 38
RSNetWorx, 36, 37
S
Scanner DeviceNet, 35
SLC500, 38
D
DEL, 24
DEL de diagnostic, 12
Documents associés, 5
Données échangées, 11
Double terminaison VW3 A8 306 RC, 19
E
T
Temps de cycle, 27
Topologie
bus, 16
étoile, 14
V
Vitesse de communication, 21
Esclave DeviceNet, 10
131
Glossaire
0x••••
Valeur exprimée au format hexadécimal, ce qui équivaut aux notations H••••, ••••h et
16#•••• parfois utilisées dans d’autres documents.
NOTE : Le logiciel ABC-LUFP Config Tool utilise la notation 0x•••• notation.
Exemple : 0x0100 = 16#0100 = 256.
02#•••• ••••
Valeur exprimée en binaire. Le nombre de digits ‘•’ dépend de la taille de la donnée
représentée. Chaque quartet (groupe de 4 bits) est séparé des autres quartets par un
espace.
Exemple octet 2#0010 0111 = 39, mot 2#0110 1001 1101 0001 = 0x69D1 = 27089.
ABC-LUFP
Config Tool
Abréviation utilisée pour désigner l'outil AnyBus Communicator utilisé pour configurer et
mettre en œuvre de la passerelle LUFP9. Egalement appelé « ABC-LUFP Configurator ».
Elément « ABC »
Elément de l'outil de configuration ABC-LUFP qui peut être un type de données d'entrée
ou de sortie.
ATS
Abréviation de « Altistart » (démarreur).
ATV
Abréviation de « Altivar » (variateur de vitesse).
Control/Status byte Champ de l'outil de configuration ABC-LUFP.
CRC
Cyclical Redundancy Check.
EDS
Electronic Data Sheet. Désigne le format des fichiers (extension « .eds ») qui permettent
à un outil de configuration et de mise au point de maîtres DeviceNet de configurer leurs
échanges selon ce même protocole.
Fieldbus
Terme désignant le réseau amont DeviceNet dans ABC-LUFP Config Tool.
Handshake
Ancien terme désignant les deux registres d’initialisation et de diagnostic de la passerelle
LUFP9. Ce terme a été remplacé par l’expression « Control/Status Byte ».
Diode
Diode Electro-Luminescente (DEL).
LRC
Longitudinal Redundancy Check.
LSB
Octet de poids faible d’un mot de 16 bits.
MAC ID
Media Access Control ID. Adresse d'un module sur un bus DeviceNet.
MSB
Octet de poids fort d’un mot de 16 bits.
Nœud
Terme désignant le point de connexion d’un esclave Modbus dans ABC-LUFP Config
Tool.
ODVA
Open DeviceNet Vendor Association, Inc.
Sub-Network
Terme désignant le réseau aval DeviceNet dans ABC-LUFP Config Tool.
XML
EXtensible Markup Language. Langage utilisé par ABC-LUFP Config Tool pour
l’import/export de la configuration d’un esclave Modbus.
132
Guide d’exploitation de LUFP9
V1.2
2005-08