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 [email protected]. 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 ">
公開リンクが更新されました
あなたのチャットの公開リンクが更新されました。
