Protocole ModBus RTU à l'aide des API LabVIEW

[cyprien11]

Bonjour,

Me revoici avec mon problème de de Modbus. J'ai lu tous les tutos, j'ai téléchargé la libraire Modbus mais je n'ai toujours pas compris comment tout cela fonctionne. J'envisage de ne pas utiliser tout ce qui touche au "I/O Server" ou "OPC Server" et veut donc coder à l'aide de la bibliothèque.

Tout d'abord, j'ai un problème avec les modules "maitre" et "esclave". A ce que j'en savais jusque la, le seul fonction d'un "maitre" dans un méthode d'accès par "maitre/esclave" était l'envoie d'ordre, tandis que l'esclave pouvait renvoyer une information ou bien simplement dire que l'ordre à bien été effectué. Ici je n'arrive pas à faire la différence entre le module maitre et le module esclave. Je ne sais donc déjà pas par quoi commencer.

Dans ma tête, mon PC est le maitre, et mon débitmètre, avec qui je cherche à communiquer, est l'esclave. Donc dans mon programme j'ai juste à mettre un module esclave et le configurer (ID, Port, Baud, ...). Ensuite arrive la programmation et lecture/écriture. J'ai donc tenté quelque chose à l'aide de la libraire Modbus. Cependant, je peux écrire n'importe quoi, que ce soit dans la configuration de l'esclave, comme dans les datas à transmettre, je n'ai ni réponse, ni erreur, rien quoi. J'ai l'impression de brasser du vide, et je ne vois aucune piste pour m'en sortir. Je pense vraiment que je n'ai toujours pas compris ce protocole, ou comment il s'effectue sur Labview. 

Pour moi, dans la com., il y a au moins 4 choses à penser :

 - L'adresse, je pense savoir que c'est le "Starting Adress" des modules de la librairie, accompagné du "Number of inputs".

 - La fonction, ici je ne sais pas où elle apparait.

 - Le Data, inutile je suppose en lecture, à rentrer sous forme de tableau pour l'écriture?

 - le CRC, apparemment controlé par la librairie Labview.

Suis-je au moins au point la dessus?

Je mets en pj me programme que j'ai effectué pour tenter ma communication, suis-je sur un piste? Ou bien est-ce que ça ressemble typiquement à un code effectué par un personne qui n'a rien compris au protocole ou son utilisation sur Labview?

Désolé pour ces longs posts, toujours affreux à lire vu mon désespoir ici. Je ne comprends pas que je n'arrive pas à comprendre !

Cordialement,

[Desruelle_luc · Accepted solution]

Salut,

perso je veux bien t’aider, mais je n’ai pas LV2015 sur mon PC, donc il faut descendre ton code en LV2014. Sinon tu peux insérer une copie écran.

c’est étrange, j’ai l’impression que tu as « presque compris » mais que tu bloques. Je me permets de te rajouter un lien vers de la lecture. Rien d’exceptionnel, c’est un post que j’avais fait pour centraliser des questions « modbus » que je retrouve régulièrement sur le forum. La mise en page est très moche depuis la mise à jour de la communauté, il faut que je la corrige.

http://forums.ni.com/t5/luc-desruelle-s-Blogue/ModBus-et-LabVIEW/ba-p/3485385

En Modbus série, le maître (le PC via le code LabVIEW que tu dois écrire) se connecte à l'esclave (ton débitmètre, le code de l’esclave est dans l’esclave et a été codé par le développeur du débitmètre, le module esclave n’est pas ton problème). Dès que la liaison est établie , le maître (par ton code écrit en LabVIEW) envoie des requêtes Modbus à l'esclave. Ces requêtes sont traitées par l'esclave (par le code interne au débitmètre). Le résultat est renvoyé au maître sous forme de réponse Modbus.

En mlodbus il faut distinguer la couche de « transport » (TCP, série,…) et l’encodage des données « protocol », pour faire très simple

1. Le protocole Modbus définit un (Protocol Data Unit) dit PDU. Il qui ne dépend pas de la couche de communication correspondante. Ce PDU se compose des deux champs "Function Code" et "Data". Le PDU restent identiques pour toutes les variantes Modbus. 
2. Transport et ADU : 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). 
3. Modbus-PDU et Modbus-ADU composent ensemble le message Modbus, également désigné par "Frame" (trame).

Tu es en modbus série RTU, avec calcul de CRC. Le calcul de CR est intégré dans la réponse de la trame modbus.

En modbus série, c'est l'API VISA qui est utilisée par le toolkit LabVIEW.

L'API modbus de National Instruments (donc le code du toolkit modbus LabVIEW) te "fabrique" cette frame de façon transparente. Le calcul du CRC est « transparent » pour le développeur. Il est effectué « en interne, dans le code de l’API LabVIEW ».

Tu as à spécifier

- transport : serial Master

 - le port de communication : c'est le port com de ton port série de ton PC

 - le unit ID : tu peux avoir plusieurs exclaves, donc c'est l'adresse de l'esclave, configurée dans l'esclave

- type : RTU

 - en lecture : prendre vi de lecture avec add de départ et nombre de U16 à lire

 - le CRC, controlé en interne par la librairie Labview.

 exemple lecture à l'add 10000 de 2U16

[cyprien11]

Bonjour, 

Je vous remercie pour votre réponse rapide. Une fois que j'avais compris que c'est bel et bien le code du maitre que je devais mettre en place (et que celui de l'esclave était effectué par le constructeur), j'ai tout de suite eu les idées plus claires. 

J'arrive finalement à communiquer avec mon débitmètre, la librairie nous permet de traiter ça comme une liaison série simple, le protocole est effectivement invisible ici. Il y a juste un peu de conversion numérique à faire, on a vu pire ^^

Merci bien pour votre aide et certainement à une prochaine.

Bonne journée.

[Desruelle_luc]

super!

[noir_desir_fab]

Bonjour Luc

Je vois ce post qui date un peu mais bon comme j'ai un soucis similaire.

J'ai une station campbell en modbus (liaison série puis adapteur USB). 

J'ai pris la bibliothèque modbus sur le site de ni.

Je n'arrive pas à récupérer d'information sur le modbus de mon appareil, j'ai les informations suivantes concernant l'appareil (ma liaison série est le port com 5).

L'adresse de départ est 40000 ....

---

Example 1:

1:  Modbus Initiate Telecom (Special) (P222)

 1: 51      Calling Mode ;note 1 

 2: 1        Flag 1 ;note 2

 3: 1        Modbus Address of Slave

 4: 3        Number of Retries  ;note 3

 5: 1        Result Code Loc [ inloc1    ] ;note 4

 6: 1        Command  ;note 5

 7: 5       Swath  ;5 IEEE4 FLOATS (10 holding registers)

 8: 2        Local Loc [ inloc_2    ]  ;5 IEEE4 FLOATING point values placed into inloc_2 through inloc_7

 9: 1        Remote Loc  ;holding registers starting at address 40001

note 1: two byte integer map :abcd

where:    (Default TX/RX BAUD rate is 9600 unless parameter one is indexed.)

a=0 8 bit data, no parity 

a=1 8 bit data with odd parity as 9th bit, 

a=2 then 8 bit data even parity as 9th bit.  

a=1 Modbus holding register read/writes as two byte integers

b=1 Modbus holding register read/writes as 2 byte integer

b=0 Modbus holding register read/writes as IEEE4 floating point

c=5 C1 through C8 are used for Modbus packet RX/TX (i.e. not CSIO port)

d=x Cx used to TX modbus packet Cx+1 used to Rx modbus packet (Control Ports)

note 2: enable/disable flag for p222 instruction.  If specifed flag set, the p222  instruction is disabled.  If specfied flag is reset, then the p222 instruction runs (TX  RX modbus packet) and sets the flag hi when completed.  If there are several p222  instructions within a table using the same enable/disable flag they will take turns  (1st come 1st served) using the resourses for Modbus RX/TX and will set the  enable/disable flag back hi after all p222 instructions have completed their specified  tasks.

note 3:  Number of retries.  The retries are based on the interval of the table that  contains the p222 instruction.  After the table runs and the enabled p222 sends the  modbus packet, the next time through the table the p222 instructions checks to see  if a response was received (CRC-16 OK etc) and if not will retry the Modbus Packet  again until the number of retries is exausted.

note 4:  result code location.  The result code of the specfied modbus command is  placed in the specified inloc. 

Where:

01= failed (no repsonse or CRC error)

02= specified flag/port reset

03= specifed flag/port set

04= input location read/write success

note 5: Command

Where:

00=Slave response of logger determined by parameter 1 (see example 2)

01= Request Holding Registers (parameter 1 specifies as  IEEE4 or integers)

02= Send Inloc to Holding Registers (parameter 1 specifies as  IEEE4 or integers)

1x= Set Flag hi 

2x= Set Flag Low

4x= Set Port Low

5x= Set Port hi

8x= Read Flag (see note4)

9x= Read Port (see note4)

---