Avec les API LabVIEW, il est possibile d'utiliser le protocole Modbus, sans savoir comment il est codé.
Cela est totalement transparent pour le développeur.
Il est "quand même intéressant" de connaître quelques bases.
autres liens : http://www.developpez.net/forums/blogs/884588-luc-desruelle/b752/protocole-modbus-tcp-labview/
En Modbus série, le maître se connecte à l'esclave. Dès que la liaison est établie, le maître envoie des requêtes Modbus (Requests) à l'esclave. Ces requêtes sont traitées par l'esclave. Le résultat est renvoyé au maître sous forme de réponse Modbus (Response).
Il existe 2 protocoles série :
En Modbus TCP, le client (maître) se connecte au serveur (esclave). Dès que la liaison est établie, le client envoie des requêtes Modbus (Requests) au serveur. Ces requêtes sont traitées par le serveur. Le résultat est renvoyé au client sous forme de réponse Modbus (Response).
Il existe, dans la spécification modbus, uniquement le transport TCP ou IP.
Il est utilisé, rarement, 2 autres modes:
( pour le code Modbus RTU over TCP Master with LabVIEW)
exemple create Modbus RTU over TCP master exemple
Plus d'information : Modbus RTU over TCP Master with LabVIEW
Le protocole Modbus définit un (Protocol Data Unit) Modbus-PDU, qui ne dépend pas de la couche de communication correspondante. Ce Modbus-PDU se compose des deux champs "Function Code" et "Data".
Grâce au blindage de "Function Code" et "Data" dans Modbus-PDU, les services Modbus et le modèle d'objet restent identiques pour toutes les variantes Modbus.
En fonction de la représentation sur les différents protocoles réseau, Modbus-PDU est complété par des champs supplémentaires (MBAP Header) pour le Modbus-ADU (Application Data Unit).
Modbus-PDU et Modbus-ADU composent ensemble le message Modbus, également désigné par "Frame" (trame).
MASTER VS SLAVE
Ethernet TCP/IP VS Serial
Master donne l'ordre de l'action de lire ou écrire au slave qui va réaliser l'action de donner la valeur (lecture) ou sauvegarder la valeur dans sa mémoire (écriture)
En ethernet TCP/IP Master (client) VS Slave (Serveur de données)
Un très bon article, en français, sur le protocole ModBus : https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/applicat...
https://www.ni.com/en/shop/labview/introduction-to-modbus-using-labview.html
The Modbus protocol follows a master/slave architecture where a master will request data from the slave. The master can also ask the slave to perform some action. The master initiates a process by sending a function code that represents the type of transaction to perform. The transaction performed by the Modbus protocol defines the process a controller uses to request access to another device, how it will respond to requests from other devices, and how errors will be detected and reported. The Modbus protocol establishes a common format for the layout and contents of message fields.
The messages exchanged between the master and the slave are called frames. There are two types of Modbus frames: Protocol Data Unit (PDU) and Application Data Unit (ADU). The PDU frames contain a function code followed by data. The function code represents the action to perform and the data represents the information to be used for this action. ADU frames add a little more complexity with an additional address part. ADU frames also provide some error checking. Both the ADU and PDU frames follow Big-Endian encoding.
Primary Tables | Object Type | Type of |
---|---|---|
Discrete Input | Single bit - boolean | Read-Only |
Coils | Single bit - boolean | Read-Write |
Input Registers | 16-bit word | Read-Only |
Holding Registers | 16-bit word | Read-Write |
Table 1: Modbus Data Types1
There are two serial modes that the Modbus application layer can follow: RTU and ASCII.
In RTU, the data is represented in Binary format, whereas the ASCII mode represents the data such that it is human readable.
Figure 8: Modbus ASCII Serial Frame1
Figure 9: Modbus TCP Frame1
Description | Size | Example | |
---|---|---|---|
MBAP Header | Transaction Identifier Hi | 1 | 0x15 |
Transaction Identifier Lo | 1 | 0x01 | |
Protocol Identifier | 2 | 0x0000 | |
Length | 2 | 0x0006 | |
Unit Identifier | 1 | 0xFF |
Figure 10: MBAP Header1
As in many TCP applications, the first requirement is to establish a connection between the master and the slave. When connection has been established, the master can build a request for the slave. The request contains a PDU (Modbus frame described above) followed by a MPAB header, as shown in Figure 9. Figure 10 represents a template for the MPAB header.
L'ancienne : Bibliothèque LabVIEW Modbus le toolkit de NI
Nouvelle librairie Modbus utilisant la POO à partir de LabVIEW 2011 : https://forums.ni.com/t5/Reference-Design-Content/LabVIEW-Modbus-API/ta-p/3524019
http://www.ni.com/white-paper/3055/en
http://www.ni.com/white-paper/4433/en
http://www.ni.com/white-paper/3982/en
Analyse d'un problème ModBus :
> version de l'OS Windows ? + 32bits ou 64?
> test ping
> firewall sur PC serveur (le port modbus utilise le port 502 sur un PC serveur ModBus. Il n'y a pas de firewall sur le PC qui a le serveur? Firewall de Windows le désactiver pour test)
> Faire vi exemple : Open TCP + Read Input register + close avec affichage du code cluster d’erreur
Tester l'EXE sur qui fonctionne avec labVIEW développement : valider que cela fonctionne sans erreur
Tester l'EXE sur le PC sur lequel l'application ne fonctionne et sur plusieurs PC pour comparer
Luc Desruelle | Voir mon profil | Mon blog LabVIEW
Co-auteur livre LabVIEW : Programmation et applications
Certified LabVIEW Architect (CLA)
LabVIEW Champion
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
Pour ajouter un commentaire ici, vous devez être inscrit. Si vous êtes déjà inscrit, connectez-vous. Dans le cas contraire, inscrivez-vous puis connectez-vous.