Les bases du protocole Modbus Etre capable d’aborder la mise en œuvre du protocole Modbus sur différents supports physiques de type liaison série, Ethernet TCP-IP, ou Modbus Plus D Syntaxe des principales requêtes C Classes d’implémentation B Les principaux codes fonction Merci d’utiliser la formation ON LINE intitulée “Les bases du protocole Modbus”. Cette formation a pour objectif # de vous permettre d’aborder la mise en oeuvre du protocole Modbus sur différents supports physiques de type liaison série, réseau Ethernet, ou Modbus Plus Cette formation est découpée en 4 modules indépendants accessibles directement à partir de cette page. # Le premier module décrit les origines du protocole Modbus et ses principes de fonctionnement # Le second module décrit les différents principaux codes fonction # Le module 3 introduit les classes d’implémentation permettant de garantir l’interopérabilité des produits dans le cadre du projet Transparent Ready # Et le dernier module détaille la syntaxe des principales requêtes A Origines et principes de fonctionnement Durée : 40 min. Expert, Pédagogie : Philippe WARIN Réalisation : Schneider-Electric

ORIGINES ET PRINCIPES DE FONCTIONNEMENT Syntaxe des principales requêtes C Classes d’implémentation B Les principaux codes fonction # Abordons dans un premier temps les origines du protocole Modbus et ses grands principes de fonctionnement. A Origines et principes de fonctionnement Origines et principes de fonctionnement

1978 - Les origines Modbus est un protocole de messagerie Créé en 1978 par Modicon Les origines de Modbus remontent à la fin des années 80. # Modbus est un protocole de messagerie # créé en 1978 par la société MODICON # Son but initial était de pouvoir communiquer en point à point entre une console de programmation et un automate # Ce protocole étant ouvert et simple à mettre en oeuvre a été très rapidement adopté par d’autres constructeurs pour communiquer entre divers équipements # Modbus est maintenant largement diffusé dans les applications industrielles. Ouvert et simple à mettre en oeuvre Largement diffusé dans l’industrie

- Modbus et le modèle OSI Modbus repose sur le modèle de communication client/serveur Couche 7 modèle OSI et autres liaisons: infra-rouge, radio etc… Modbus Plus Anneau à jeton Liaison série Maitre/esclave RS232, RS485 Modbus Ethernet TCP/IP Utilisé sur différents supports Le protocole Modbus repose sur le modèle de communication client/serveur # et se situe par conséquent au niveau de la couche 7 du modèle OSI. Un module de formation intitulé “Introduction aux réseaux locaux industriels” est disponible ON LINE sur Planet pour approfondir éventuellement vos connaissances dans ce domaine. # Modbus peut être utilisé sur différents supports physiques # sur liaison série RS232 ou RS485 suivant le modèle maître/esclave # sur le réseau Modbus Plus fonctionnant sur un principe d’anneau à jeton # transporté par des trames Ethernet TCP/IP # ou encore via divers médiums de type liaison infra-rouge, radio etc....

- Modbus dans les architectures réseaux Modbus peut être utilisé dans plusieurs architectures réseaux Modbus sur Ethernet TCP-IP Modbus Plus Modbus sur RS232 Modbus sur RS485 Le protocole Modbus est utilisable simultanément à plusieurs niveaux dans les architectures réseaux. # sur Ethernet TCP/IP # sur Modbus Plus # en point à point sur liaison série RS232 pour une connexion modem par exemple # sur liaison série RS485 pour communiquer en multi-points entre plusieurs équipements

- Modbus fonctionne suivant le concept Client / Serveur Requête A quelle vitesse le moteur tourne t’il ? Client Serveur Réponse 1000 tour/mn Le Client est une entité demandant un service Le Serveur est une entité qui rend service à un client Modbus fonctionne suivant le concept client/serveur. # Un client est une entité qui demande un service à une autre entité. # Pour cela, il émet une requête au destinataire. # Le serveur est une entité qui rend service à un client. # Ce service est rendu par une réponse.

- PDU = Protocol Data Unit Format de message unique et indépendant des couches basses. PDU = Protocol Data Unit Code Fonction Data octet Adresse Contrôle d’erreur Identifie le destinataire = 1 à 127 Action à réaliser Complément d’information dépendant du code fonction Contrôle de la validité Le protocole Modbus utilise un format de message unique appelé PDU : Protocol Data Unit indépendant des couches basses. Ce format de PDU est utilisé pour la requête et pour la réponse. Il se compose de 2 champs : # un champ “code fonction” de format 1 octet indiquant l’action à réaliser par un code compris entre 1 et 127 # un champ “data” dont la longueur et le contenu dépendent de la valeur du code fonction # Ce PDU est encadré par un champ “adresse” et un champ “Contrôle d’erreur” lors de la transmission sur un médium. # Le champ “adresse” sert à identifier le destinataire de la requête. # le champ “Contrôle d’erreur” permet de contrôler la validité de l’ensemble du message. # Le format de ces champs dépend du support réseau utilisé. Le format des champs « Adresse » et « Contrôle d’erreur » dépend du support réseau utilisé

- Déroulement d’une transaction sans erreur Client Requête Serveur Initialise les données 1 Réponse Code Fonction Data requête 2 Transmet la requête 1 à 127 Complément d’information Réalise l’action demandée 3 Initialise la réponse 4 Voyons tout d’abord le déroulement d’une transaction Modbus sans erreur, c’est à dire que le service demandé est supporté et accepté par l’équipement serveur. # L’équipement client initialise au moment où il en a besoin, les données concernant la requête, # puis les transmet à l’équipement serveur destinataire. # L’équipement serveur supportant le service réalise l’action demandée, # initialise les données de la réponse, # et transmet la réponse. Le code fonction transmis est égal au code fonction reçu et est suivi des données demandées. # L’équipement client traite la réponse fournie. Code Fonction Data réponse Transmet la réponse 5 Egal au Code fonction de la requête Données demandées Traite la réponse 6

- Déroulement d’une transaction avec erreur Client Requête Serveur Initialise les données 1 Réponse Code Fonction Data requête 2 Transmet la requête 1 à 127 Complément d’information Détecte une erreur dans l’action demandée 3 Initialise données message d’erreur 4 Analysons maintenant le déroulement d’une transaction Modbus avec une erreur, c’est à dire que le service demandé est refusé par l’équipement serveur. Les raisons de ce refus seront détaillées à la diapositive suivante La transaction débute # par l’initialisation des données par l’équipement client # qui dans un second temps, les transmet à l’équipement serveur destinataire. # L’équipement serveur détecte une impossibilité dans le service demandé, # initialise les données du message d’erreur, # puis transmet la réponse. Dans ce cas le serveur transmet un “code fonction d’exception” égale à la valeur du code fonction reçu plus la valeur Hexadécimal 80. Ce qui revient à positionner le bit de poids fort à 1. Les codes fonction d’exception sont donc compris entre 129 et 255. Ils sont suivis d’un code d’exception explicitant la raison du refus # L’équipement client traite la réponse fournie et réagit en conséquence. Code fonction Exception Code Exception Transmet le message d’erreur 5 Code fonction Exception = Code fonction + 80H Valeur entre 129 et 255 Code Exception indique la raison du refus Traite la réponse 6

- Fonctionnement détaillé coté serveur Attente réception requête Réception Validation code fonction Invalide Code d’exeption = 1 Valide Validation adresse données Invalide Code d’exeption = 2 Valide Validation valeurs données Invalide Code d’exeption = 3 Ce graphe d’état détaille le fonctionnement d’une transaction coté serveur. Après initialisation et à l’état de repos, le serveur est en attente de réception de requête. # Sur réception d’une requête, il analyse le code fonction reçu. # Si le code fonction n’est pas supporté, il transmet immédiatement un message d’exception avec un code d’exception égale à 1 et retourne dans l’état “attente réception requête”. # si le code fonction est supporté, il analyse la validité de l’adresse des données # si l’adresse est invalide un message d’exception est transmis avec un code d’exception égale à 2 # si l’adresse des données est valide le serveur analyse leur valeur # si la valeur des données est invalide, un message d’exception est transmis avec un code d’exception égal à 3 # si la valeur des données est valide, le serveur lance l’exécution de la fonction demandée # si la fonction ne peut être exécutée, un message d’exception est transmis avec un code d’exception égal à 4, 5, ou 6 suivant le type de problème rencontré # si la fonction est entièrement exécutée, le serveur transmet une réponse Modbus positive, c’est à dire que le même code fonction est renvoyé au client # et l’équipement serveur repasse dans l’état attente réception requête. Valide Execution de la fonction Invalide Code d’exeption = 4, 5 ou 6 Valide Envoi de la réponse Exeception Envoi de la réponse Modbus

LES PRINCIPAUX CODES FONCTION Syntaxe des principales requêtes C Classes d’implémentation B Les principaux codes fonction Les principaux codes fonction # Ce second chapitre introduit les différentes catégories de codes fonction, ainsi que la description des principaux codes. A Origines et principes de fonctionnement

Les 3 catégories de codes fonction Public 127 Public Validés par l’organisation Modbus.org Documentés publiquement 110 Définis par l’utilisateur Avec garantie d’unicité 100 Public Définis par l’utilisateur 72 Définis par l’utilisateur Implémentable sans l’accord de l’organisation Modbus.org 65 Sans garantie d’unicité Public Les codes fonction codés sur un octet se répartissent en 3 catégories : “Public”, “Définis par l’utilisateur”, et “Réservés”. Leur valeur étant comprise entre 1 et 127. # Les codes fonction “Public” ont pour particularités : # d’être validés et gérés par l’organisation Modbus.org qui est une association d’utilisateurs # d’être documentés publiquement sur le site Web de l’association # d’avoir une garantie d’unicité d’utilisation des codes fonctions concernés, afin de garantir l’interopérabilité des produits. # En opposition, les codes “Définis utilisateur” # sont implémentables sur tous produits sans accord de l’association Modbus.org # et sans garantie d’unicité et d’interopérabilité. # La troisième catégorie concerne des codes réservés # déjà utilisés par certaines compagnies, mais non gérés officiellement. Réservés Utilisés par certaines compagnies et non disponibles 1

Les 4 types de variables accessibles Entrées TOR par exemple Discrete Inputs Bit Lecture seule Données modifiables par application Coils Bit Lecture / Ecriture Entrées analogiques par exemple Input Registers Mot Lecture seule Données modifiables par application Le protocole Modbus permet d’accéder à distance à 4 types de variables # Les “Discrete Inputs” # sont des variables au format bit accessibles en lecture uniquement # Ce type de variable est supporté par des produits supportant des entrées TOR par exemple. # Les “Coils” (bobine en anglais) # sont des variables format bit accessibles en lecture et écriture # supportés par des produits supportant des données binaires modifiables par application. # Les “Input Registers” # sont des variables au format mot (16 bits) accessible en lecture uniquement # Ce type de variable est supporté par des produits supportant des entrées analogiques, par exemple # Les “Holding Registers” # sont des variables au format mot (16 bits) accessible en lecture et écriture # Ce type de variable est supporté par des produits supportant des données modifiables par application # Modbus n’impose pas de règle d’organisation des données. Ces différentes tables peuvent se chevaucher si nécessaire. 65 536 variables de chaque type sont accessibles au maximum. Holding Registers Mot Lecture / Ecriture Chevauchement possible des tables. 65 536 variables maximum.

- Codes fonction public d’accès aux variables Ce tableau synthétise l’ensemble des codes fonction “Public” permettant d’accéder aux variables d’un équipement # On distingue les codes fonction permettant d’accéder aux variables de format bit # avec pour les variables accessibles en lecture uniquement le code fonction 02 : “Read Discrete Inputs” # et pour les variables accessibles en lecture et en écriture les codes fonction : 01 : Read Coils, 05 : Write Single Coil, et 15 : Write Multiple Coils # ainsi que les codes fonction permettant aux variables de type mot : # avec pour les variables accessibles en lecture uniquement le code fonction 04 : “Read Input Registers” # et pour les variables accessibles en lecture et en écriture les codes fonction : 03 : Read Holding Registers, 06 : Write Single Coil, 16 : Write Multiple Registers, 23 : Read/Write Multiple Registers 22 : Mask Write Register et 24 : Read FIFO queue

- Autres codes fonction public Ce tableau présente les autres codes fonction “Public” utilisables # On distingue les codes fonction permettant d’accéder aux fichiers # Les codes fonction dédiés au diagnostic # et un code fonction permettant de transporter d’autres protocoles

CLASSES D’IMPLEMENTATION Syntaxe des principales requêtes C Classes d’implémentation Classes d’implémentation B Les principaux codes fonction # Cette troisième partie aborde les classes d’implémentation initiées par le projet Schneider “Transparent Ready” A Origines et principes de fonctionnement

- Classes d’implémentation Transparent Ready Liste de services à implémenter fonction des applications ciblées pour garantir l’interopérabilité des équipements Le protocole Modbus fait partie de ces services Messagerie Device Management Transparent Ready est une offre d’équipement Schneider basée sur le standard Ethernet TCP/IP utilisant le protocole de messagerie Modbus au niveau de la couche 7 application. # Les classes d’implémentation Transparent Ready définissent une liste de services à implémenter en fonction des application ciblées # dans le but de garantir l’interopérabilité des équipements Transparent Ready Schneider # Le protocole Modbus fait partie de ces services. Sur Modbus, on distingue : # la messagerie permettant d’accéder aux variables et fonctions de l’équipement # et le Device management permettant de l’identifier

- Règles et vocabulaire 3 classes dépendant du niveau des fonctionnaltés implémentée. Imbrication modèle « Poupées russes » Basic Regular Extended Appartenance à une classe si et seulement si toutes les caractéristiques obligatoires sont supportées Un équipement peut aussi supporter des caractéristiques d’une classe supérieure. Commençons par aborder quelques règles et termes propres à l’offre Transparent Ready # Chaque service est divisé en 3 classes dépendant du niveau des fonctionnalités implémentées. # « Basic » # « Regular » englobant les fonctions « Basic » + d’autres fonctions # « Extended » englobant les fonctions « Regular » + d’autres fonction. # Ces 3 classes s’imbriquent sur le modèle des poupées russes. # Un équipement appartient à une classe si et seulement si il supporte toutes les caractéristiques obligatoires liées à cette classe. # et un équipement appartenant à une classe peut aussi supporter des caractéristiques d’une classe supérieure.

- Classes de messagerie Classes de messagerie identiques pour Client et Serveur Accès aux registres uniquement CF 03 : Read Holding Registers CF 16 : Write Multiple Registers Basic Basic + Accès aux bits si nécessaire et au diagnostic si liaison série CF 01 : Read Coils CF 02 : Read discrete inputs CF 15 : Write Multiple Coils CF 08 : Diagnostic Regular Extended # Les classes d’implémentation définies au niveau de la messagerie sont identiques pour les équipements client et serveur. # Un équipement « Basic » ne permet d’accéder qu’aux variables de type registres de format mot. # et doit obligatoirement supporter les codes fonction 03 « Read Holding Register » et 16 « Write Multiple Registers ». # Un équipement de classe « Standard » doit supporter les fonctions basic + l’accès aux variables de format bit si cela est nécessaire ainsi que le diagnostic s’il s’agit d’une liaison série. # Dans ce cas les codes fonction obligatoires sont : 01 « Read Coils », 02 « Read discrete inputs », 15 « Write Multiple Coils », et 08 « Diagnostic » # Enfin, un équipement « Extended » doit supporter les fonctions regular + l’accès aux fichiers. # Les codes fonction obligatoires étant : 20 « Read File Record », et 21 «Write File Record». # Les codes fonction Write Single Register et Write Single Coil sont recommandées pour les équipements serveur afin de garantir l’interopérabilité avec les anciens produits. Regular + Accès aux fichiers CF 20 : Read File Record CF 21 : Write File Record Write Single Register et Write Single Coil sont fortement recommandée pour les serveurs (compatibilité anciens produits).

- Classes de Device Management Classes de Device Management identiques pour Client et Serveur Accès Vendor Name, product code et version CF 43 : Read Device Identification Sous code 14 – Accès Niveau 1 Basic Basic + Accès Vendor URL, Product Name, Model name, User application name Regular CF 43 : Read Device Identification Sous code 14 – Accès Niveau 2 Extended # Les classes d’implémentation de Device Management sont identiques pour les équipements client et serveur. Elles permettent d’identifier un équipement suivant 3 niveaux de précision. # Un équipement « Basic » permet d’accéder au «Vendor name», «Product code» et à la «Version » de l’équipement # Il supporte obligatoirement le code fonction 43 « Read Device Identification » sous code 14 paramétré avec un accès niveau 1. # Un équipement de classe « Standard » supporte l’identification « Basic » + l’accès à « Vendor URL », « Product Name », Model Name » et « User application name ». # Il supporte obligatoirement le code fonction 43 « Read Device Identification » sous code 14 paramétré avec un accès niveau 2. # Un équipement « Extended » supporte l’identification « Regular » tout en permettant l’accès à des objets privés dépendant du produit. # Il supporte obligatoirement le code fonction 43 « Read Device Identification » sous code 14 paramétré avec un accès niveau 3. Regular + Accès objets privés dépendant du produit CF 43 : Read Device Identification Sous code 14 – Accès Niveau 3

SYNTAXE DES PRINCIPALES REQUETES Syntaxe des principales requêtes Syntaxe des principales requêtes C Classes d’implémentation B Les principaux codes fonction # Ce dernier chapitre décrit la syntaxe des principales requêtes Modbus A Origines et principes de fonctionnement

- Read Holding Registers Requête : 1 octet 2 octets 2 octets Code Fonction 03 Adresse du premier registre 0 à 65 535 Nombre de registres à lire n = 1 à 125 Réponse : 1 octet 2 octets 2 octets 2 octets Code Fonction 03 Nombre d’octets lus 2 x n Valeur du premier registre 0 à 65 535 0 à 65 535 Valeur du dernier registre La requête « Read Holding Registers » permet d’accéder en lecture à plusieurs registres consécutifs. # Elle utilise le code fonction 03 # Un second champ de longueur 2 octets permet de coder l’adresse du premier registre auquel on souhaîte accéder. Cette adresse pouvant varier de 0 à 65 535. # Le troisième champ codé également sur 2 octets permet d’indiquer le nombre de registres que l’on souhaite lire. Le nombre de registres consécutifs peut varier de 1 à 125 Si l’équipement serveur accepte la requête, # il renvoie en écho le même code fonction 03 # suivi d’un champ codé sur 2 octet indiquant le nombre d’octets lus qui suivent. Cette valeur est égale au double du champ « Nombre de registres à lire » codé dans la requête. # Le troisième champ contient la valeur du premier registre lu # suivi des valeurs des registres suivants.

- Write Multiple Registers Requête : 1 octet 2 octets 2 octets 1 octet 2 octets 2 octets Code Fonction 16 0 à 65 535 Adresse du premier registre n = 1 à 123 Nombre de registres à écrire Nombre d’octets à écrire 2 x n 0 à 65 535 Valeur du premier registre 0 à 65 535 Valeur du dernier registre Réponse : 1 octet 2 octets 2 octets Code Fonction 16 Adresse du premier registre 0 à 65 535 Nombre de registres écrits n = 1 à 123 La requête « Write Multiple Registers » permet d’accéder en écriture à plusieurs registres consécutifs. # Elle utilise le code fonction 16 # Un second champ de longueur 2 octets permet de coder l’adresse du premier registre qu’on souhaite écrire. Cette adresse pouvant varier de 0 à 65 535. # Le troisième champ codé également sur 2 octets permet d’indiquer le nombre de registres que l’on souhaite écrire. Le nombre de registres consécutifs peut varier de 1 à 123 # Le quatrième champ codé sur 1 octet permet d’indiquer le nombre d’octets que l’on souhaite écrire. Sa valeur est égale au double du champ précédent. # le cinquième champ codé sur 2 octets contient la valeur à écrire dans le premier registre # les champs suivant contiennent les valeurs à écrire dans les registres suivant. Si l’équipement serveur accepte la requête, # il renvoie en écho le même code fonction 16 # le second champ codé sur 2 octets indique l’adresse du premier registre écrit. # et le troisième champ codé également sur 2 octets indique le nombre de registres écrits

- Write Single Register Requête : 1 octet 2 octets 2 octets Code Fonction 06 0 à 65 535 Adresse du registre 0 à 65 535 Valeur du registre Réponse : 1 octet 2 octets 2 octets Code Fonction 06 0 à 65 535 Adresse du registre Valeur du registre La requête « Write Single Register » permet d’accéder en écriture à un seul registre. Son implémentation est fortement recommandée pour les équipements serveur afin de garantir l’interopérabilité avec d’anciens produits. # Elle utilise le code fonction 06 # Un second champ de longueur 2 octets permet de coder l’adresse du registre qu’on souhaite écrire. Cette adresse pouvant varier de 0 à 65 535. # Le troisième champ codé également sur 2 octets contient la valeur à écrire. Si l’équipement serveur accepte la requête, # il renvoie en écho les 3 champs de la requête

- Read Coils Requête : Réponse : 1 octet 2 octets 2 octets 1 octet Code Fonction 01 Adresse de la première sortie digitale 0 à 65 535 Nombre de sorties digitales à lire n =1 à 2000 Réponse : 1 octet 1 octet 1 octet 1 octet Code Fonction 01 Nombre d’octets lus n/8 + 1 si R Valeur du premier octet 0 à 255 0 à 255 Valeur du dernier octet La requête « Read Coils » permet d’accéder en lecture à plusieurs sorties digitales consécutives. # Elle utilise le code fonction 01 # Un second champ de longueur 2 octets permet de coder l’adresse de la première sortie digitale à laquelle on souhaite accéder. Cette adresse pouvant varier de 0 à 65 535. # Le troisième champ codé également sur 2 octets permet d’indiquer le nombre de sorties digitales que l’on souhaite lire. Le nombre de sorties consécutives peut varier de 1 à 2000 Si l’équipement serveur accepte la requête, # il renvoie en écho le même code fonction 01 # suivi d’un champ codé sur 2 octet indiquant le nombre d’octets lus qui suivent. Cette valeur est égale à la valeur du troisième champ de la requête divisée par 8 auquel on ajoute 1 si le reste de la division n’est pas nul. # puis la valeur du premier octet lu correspondant aux 8 premières sorties # suivie des valeurs suivantes.

- Read Discrete inputs Requête : Réponse : 1 octet 2 octets 2 octets Code Fonction 02 Adresse de la première entrée digitale 0 à 65 535 Nombre d’entrées digitales à lire n =1 à 2000 Réponse : 1 octet 1 octet 1 octet 1 octet Code Fonction 02 Nombre d’octets lus n/8 + 1 si R Valeur du premier octet 0 à 255 0 à 255 Valeur du dernier octet La requête « Read Discrete inputs » permet d’accéder en lecture à plusieurs entrées digitales consécutives. # Elle utilise le code fonction 02 # Un second champ de longueur 2 octets permet de coder l’adresse de la première entrée digitale à laquelle on souhaite accéder. Cette adresse pouvant varier de 0 à 65 535. # Le troisième champ codé également sur 2 octets permet d’indiquer le nombre d’entrées digitales que l’on souhaite lire. Le nombre d’entrées consécutives peut varier de 1 à 2000 Si l’équipement serveur accepte la requête, # il renvoie en écho le même code fonction 02 # suivi d’un champ codé sur 2 octets indiquant le nombre d’octets lus qui suivent. Cette valeur est égale à la valeur du troisième champ de la requête divisée par 8 auquel on ajoute 1 si le reste de la division n’est pas nul. # puis la valeur du premier octet lu correspondant aux 8 premières sorties # suivie des valeurs suivantes.

- Write Multiple Coils Requête : Réponse : 1 octet 2 octets 2 octets Code Fonction 15 0 à 65 535 Adresse de la première sortie digitale n =1 à 1968 Nombre de sortie digitales à écrire Nombre d’octets à écrire n/8 + 1 si R 0 à 255 Valeur du premier octet 0 à 255 Valeur du dernier octet Réponse : 1 octet 2 octets 2 octets Code Fonction 15 Adresse de la première sortie digitale 0 à 65 535 Nombre de sortie digitales écrites n =1 à 1968 La requête « Write Multiple Coils » permet d’accéder en écriture à plusieurs sorties digitales consécutives. # Elle utilise le code fonction 15 # Un second champ de longueur 2 octets permet de coder l’adresse de la première sortie digitale qu’on souhaite écrire. Cette adresse pouvant varier de 0 à 65 535. # Le troisième champ codé également sur 2 octets permet d’indiquer le nombre de sorties digitales qu’on souhaite écrire. Le nombre de sorties digitales peut varier de 1 à 1968 # Le quatrième champ codé sur 1 octet permet d’indiquer le nombre d’octets que l’on souhaite écrire. Cette valeur est égale à la valeur du champ précédent divisé par 8 auquel on ajoute 1 si le reste de la division n’est pas nul. # le cinquième champ codé sur 1 octet contient la valeur à écrire dans les 8 premières sorties digitales # les champs suivant contiennent les valeurs à écrire dans les sorties digitales suivantes. Si l’équipement serveur accepte la requête, # il renvoie en écho le même code fonction 15 # le second champ codé sur 2 octets indique l’adresse de la première sortie digitale écrite. # et le troisième champ codé également sur 2 octets le nombre de sorties digitales écrites

- Read Device Identification Requête : 1 octet 1 octet 1 octet 1 octet Niveaux d’accès : 1 : Basic 2 : Regular 3 : Extended 4 : Individual Code Fonction 43 Sous code fonction 14 Niveau d’accès 1 à 4 Adresse de objet identification m =0 à 255 Réponse : 1 octet 1 octet 1 octet 1 octet 1 octet 1 octet 1 octet Code Fonction 43 Sous code fonction 14 Niveau d’accès 1 à 4 Classe d’implémentation dupportée 1 à 3 Réponse fractionnée 0 = non 255 = oui Si fractionné adresse prochain objet 1 à 255 Nombre d’objets identification 1 à 255 La requête « Read Device Identification » fait partie des services « Device management » et permet d’identifier un produit avec une plus ou moins grande précision. # Elle utilise le code fonction 43 # Sous code 14 # Le troisième champ codé sur 1 octet permet de préciser le niveau d’accès à l’identification. Sa valeur comprise entre 1 et 4 correspond aux classes Basic, Regular, Extended ou Individual. # Le quatrième champ codé également sur 1 octet permet d’indiquer l’adresse du premier objet qu’on souhaite lire Si l’équipement serveur accepte la requête, # il renvoie en écho le même code fonction 43 # le même sous code 14 # le troisième champ codé sur 1 octet renvoie le niveau d’accès demandé dans la requête. # le quatrième champ codé sur 1 octet précise le niveau de classe d’implémentation supporté par l’équipement # le cinquième champ précise si la réponse est frationnée valeur 255 ou pas valeur 0 # le sixième champ codé sur un octet précise dans le cas d’une réponse fractionnée l’adresse du prochain objet qui devra être demandé lors de la requête suivante. # le septième champ codé sur un octet indique le nombre d’objets qui suivent dans la réponse # le huitième champ codé sur un octet indique l’adresse du premier objet qui suit dans la réponse # le neuvième champ la longueur m en octet de l’objet # le dixième champ codé sur m octets contient la valeur de l’objet # et ainsi de suite pour les objets suivants… 1 octet 1 octet n octets 1 octet Adresse objet m+1 Longueur objet m+1 Valeur de l’objet m+1 n’ octets Adresse objet m m = 0 à 255 n = 1 à 255 Longueur objet m Valeur de l’objet m