luc desruelle's Blogue

Navigateur communautaire
annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 
Desruelle_luc
15809 Visites
3 Commentaires

1- résumé "simple", avec code toolkit NI

 

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/

 

1.A) Modbus série "ASCII" ou "RTU"

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 :

  • RTU est le protocle le plus utilisé, avec calcul de CRC
  • ASCII avec calcul du LRC

 

configuration serie modbus VISA.png

 

1.A.a) exemple create Modbus serial ASCII master exemple

create Modbus serial ASCII master exemple.png

 

1.A.b) exemple create Modbus serial RTU master exemple

 

create Modbus serial RTU master exemple.png

 

B) Modbus "TCP"

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.

 

1.B.a) exemple create Modbus TCP master exemple

 

create Modbus TCP master exemple.png

 

Il est utilisé, rarement, 2 autres modes:

1.B.b) avec Gateway modbus, besoin d'ajouter le "Unit ID" : exemple create Modbus TCP master with unit_ID exemple

create Modbus TCP master with unit_ID exemple.png

 

1.B.c) le protocole RTU sur couche de transport TCP, sous le nom "modbus RTU over TCP"

( pour le code Modbus RTU over TCP Master with LabVIEW)

exemple create Modbus RTU over TCP master exemple

create Modbus RTU over TCP master exemple.png

 

 

Plus d'information : Modbus RTU over TCP Master with LabVIEW

 

 

2 - résumé PDU, ADU et Frame d'une trame Modbus

 

A) Protocole PDU

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.

 

PDU modbus.png

B) 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).

 

 

Modbus-PDU et Modbus-ADU composent ensemble le message Modbus, également désigné par "Frame" (trame).

 

3 - Introduction à ModBus

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 : http://www.ni.com/white-paper/52135/fr/

 

http://www.ni.com/white-paper/7675/en

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.

 

fig3_modbus_frame_20120316151705.png

 

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

 

4 - Serial Implementation

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

 

5 - TCP Implementation

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.     

 

 

 

6 - Using LabVIEW With Modbus, version gratuite librairie Modbus LabVIEW

L'ancienne : Bibliothèque LabVIEW Modbus le toolkit de NI

 

Nouvelle librairie Modbus utilisant la POO  à partir de  LabVIEW 2011  :  https://decibel.ni.com/content/docs/DOC-30140

 

7 - Exemples codes, tester communication modbus, analyse problèmes

http://www.ni.com/white-paper/3055/en

http://www.ni.com/white-paper/4433/en

http://www.ni.com/white-paper/3982/en

http://forums.ni.com/t5/Discussions-au-sujet-de-NI​/labview-tcp-ip-multi-client/m-p/1999103/highligh...

 

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

 

http://forums.ni.com/t5/Discussions-au-sujet-des-autres/Liaison-TCP-IP-sous-appli-windows-7/td-p/177...

http://forums.ni.com/t5/Discussions-au-sujet-des-autres/Liaison-TCP-IP-sous-appli-windows-7/td-p/177...

 

 

ModBus TCP exemple Mesulog Luc Desruelle.png

 

 

 

 

 

 

Luc Desruelle | avatar_ld.gifVoir mon profil | Mon blog LabVIEW
Co-auteur livre LabVIEW : Programmation et applications
Certified LabVIEW Architect (CLA)
LabVIEW Champion

banniere Luc Livre.png

Contact

Desruelle_luc
3654 Visites
0 Commentaires

pour réaliser des driver LabVIEW (a tester...)

NI LabVIEW Instrument Driver Development Studio 1.1 :  Speed up development time when creating new LabVIEW instrument drivers by building on functional SCPI command templates for common instrument types + Develop consistent instrument drivers by loading the source from an existing driver  as a starting point

Desruelle_luc
6035 Visites
0 Commentaires

Outils de génie logiciel et de validation http://www.ni.com/softwareengineering/f/

 

NI Requirements Gateway

NI Requirements Gateway est une solution de traçabilité des exigences qui relie vos documents de développement et de vérification aux exigences formelles stockées dans les documents et les bases de données. NI Requirements Gateway est une solution idéale pour des applications qui simulent ou testent des composants complexes par rapport aux exigences documentées dans des industries telles que l'automobile, la défense, l'aérospatiale et l'électronique grand public.

 

 

Toolkit LabVIEW VI Analyzer

Le Toolkit VI Analyzer permet d'accroître la qualité et la lisibilité du code graphique développé en LabVIEW. Configurez plus de 60 tests destinés à la révision automatisée et à l'analyse statique du code de tous les VIs d'une application.

List of Community VI Analyzer Tests

 

 

Toolkit LabVIEW Desktop Execution Trace

billet par LD synthèse : Desktop Execution Trace Toolkit : DETT Saves the Day!

 

Le Toolkit LabVIEW Desktop Execution Trace permet de mettre au point et de déboguer des applications LabVIEW en fournissant des détails bas niveau sur l'exécution des VIs et des exécutables. Le code peut être surveillé et vous pourrez facilement identifier la source de problèmes tels que les fuites de référence, les fuites de mémoire, les erreurs non gérées et d'autres problèmes pouvant avoir un impact négatif sur les performances et sur la fiabilité d'une application.

 

 

Toolkit LabVIEW Unit Test Framework

Le Toolkit LabVIEW Unit Test Framework automatise le test et la validation sur la base des exigences des unités logicielles (VIs) développées en LabVIEW. Il permet ainsi le test fonctionnel du logiciel et le test de régression. Les fonctionnalités de création de rapports incluses génèrent automatiquement les documents de validation précieux pour documenter le respect des exigences par une application et pour assurer que son comportement reste situé dans les limites de paramètres définies

 

Prove It Works: Using the Unit Test Framework for Software Testing and Validation : http://www.ni.com/white-paper/8082/en

 

Luc Desruelle | avatar_ld.gif | Voir le profil LinkedIn de Luc DesruelleVoir mon profil

CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW
CLD : Certified LabVIEW Developer / Certifié Développeur LabVIEW

Contact

Desruelle_luc
5342 Visites
0 Commentaires

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Les-interruptions/m-p/2446998/highlight/true#M766...

 

j'ai bcp aimé l'article de Florina Abry - Naity

 

Re : Les interrupti​ons.

Bonjour,

 

Je me permets de rajouter un mot ou deux sur ce qu'a dit Ouadji.

 

Lors de la programmation micro contrôleur, on programme directement en langage machine. Il est donc nécessaire de gérer les interruptions de manière manuelle pour autoriser le contrôleur d’exécuter plusieurs tâches de manière pseudo-parallèle.

 

L’introduction des systèmes d’exploitation à changer la donne. Ces systèmes (type Windows) proposent une surcouche logicielle qui s’occupe, entre-autre, de gérer les exploitations. Cette action est réalisée via un de leur composant nommé « Scheduler » (ou ordonnanceur en français, voir wiki).

 

Ce Scheduler s’occupe, via un algorithme bien définit, de gérer les interruptions des différentes tâches concurrentes tournant sur un même système (on parle de Process (processus) pour els différentes applications tournant en parallèle (par Exemple, Windows en parallèle avec Foobar pour la musique, Opera pour le web et un client Thunderbird pour les mails. Le Scheduler doit faire en sorte que vous puissiez surfer tout en écoutant de la musique) et de Threads pour les tâches parallèle au sein d’un même processus (exemple type : Windows Media Player à un visualizer qui tourne en parallèle avec le lecteur de musique)). Pour que tout ce beau monde tourne d’une manière donnant l’illusion d’être parallèle, le Scheduler doit sans cesse jongler avec ces threads en les interrompant les-uns les autres.

 

Les premiers scheduler (celui de Windows 3 par exemple, si je ne dis pas de bêtises) se contentaient de laisser un temps défini à chaque thread, sans notion de priorité. C’est ce que l’on appelle le « Round-Robin Scheduling » (wiki). Plus tard, un autre type de scheduling à fait son apparition, plus proche des possibilités données par els interruptions de Microcontrôleur : Le « Preemptive Scheduling » (wiki). Cet algorithme d’ordonancement permet d’allouer des niveaux de priorité aux tâches pour qu’une tâche de priorité plus importante interrompe toutes tâches de prioroité moindre lorsque celle-ci doit être exécutée.

 

 

Oui mais LabVIEW dans tout ca ?

 

 

Il y a d’autres types d’ordonnancement, mais ces deux là représentent de mon point de vue la base nécessaire à comprendre les systèmes d’interruptions des systèmes d’exploitation sur lesquels LabVIEW tourne.

 

Je me focaliserais sur deux d’entre-eux :

 

Windows 7 :

Je ne suis pas extrêmement familier avec le Scheduler de Windows 7. De ce que j’en ai compris, il fonctionne comme un mix de Scheduling Round-Robin et de Preemptive Scheduling. Les différentes tâches ont des niveaux de priorité. Les tâches de haute priorité interrompent les tâches de basses priorités. Cependant, il me semble que le scheduler peut aussi interrompre les tâches de haute priorité si celles-ci prennent trop de temps d’exécution pour garantir une exécution minimale pour els tâches de basse priorité. La plupart des niveaux de priorité ne sont utilisables que par le Système d’exploitation.

 

 

Cela signifie qu’un programme labVIEW peut avoir différent niveaux de priorité, mais jamais les plus haut et qu’une tâche exécutée sous labVIEW peut être à tout moment interrompue par Windows.

 

Pour changer le niveau de priorité, il y a 3 méthodes :

 

* Définir le processus LabVIEW.exe comme processus de haute priorité dans le gestionnaire des tâches de Windows.

* Utiliser une « Timed Loop ». Ce faisant, vous réduirez l’algorithme dans la boucle à un thread et ce thread sera d’une plus haute priorité que les autres threads du processus en cours. Attention donc, la réduction de l’algorithme à un thread peut entrainer des Race Conditions assez dramatiques et cette priorité n’est que relative au programme. Les autres programmes et processus (dont ceux de windows) peuvent interrompre ce thread à tout moment.

* Dans les propriétés ‘exécution d’un VI, il est possible de configurer la priorité de ce VI. Encore une fois, cette priorité est relative aux autres Vis.

 

Conclusion : il n’est pas possible de créer de « vrais » mécanismes d’interruption pour un programme LanVIEW sous Windows.

 

 

 

LabVIEW Real-Time OS :

 

Le Scheduler de LabVIEW Real-Time OS fonctionne de manière quasi purement préemptive. Toute tâche de priorité supérieure interrompra une tâche de priorité inférieure et toute tâche de priorité inférieure ne pourra être exécutée qu’une fois toutes les tâches de priorité supérieures finies. En cas de tâches de priorité équivalente, c’est la règle de « Round Robin » qui s’applique. LabVIEW Real-Time autorise LabVIEW à utiliser tous les niveaux de priorité.

 

Les moyens de définir cette priorité est équivalente aux deux derniers points soulevés dans le paragraphe sur Windows, avec la particularité que cette fois, la priorité d’une tâche est absolue.

 

Conclusion : Même si les interruptions processeur sont prise en charge par la surcouche logicielle du système d’exploitation, il est possible d’avoir un contrôle quasi-total sur les interruptions (avec la seule limite que LabVIEW n’autorise pas à donner une priorité telle à un processus que celui-ci pourrait interrompre le scheduler).

 

J’espère que cette petite explication sera utile à tous. N’hésitez pas à donner des Kudos si c’est le cas.

 

Cordialement