Vous êtes sur la page 1sur 15

ECUE CRI

Communication et Réseaux Industriels


Rapport de TP

Pilotage d'un chariot loguidé


MODBUS et TCP/IP

Ce rapport est une simple aide.

Ne considérez pas que tout ce qui y


Enseignant SIGMA Clermont:
est écrit est juste. De plus, il n'est

pas forcément complet.


Khalid Kouiss
Pôle : MMS
Bon courage !

Un ancien qui vous veut du bien :)

Référence du chier: S9_CRI_RapportTP_Modbus-TCP/IP.pdf

SIGMA CLERMONT
CAMPUS DE CLERMONT-FERRAND  CS 20265  63178 AUBIERE FRANCE
TEL. +33 (0)4 73 28 80 00  FAX +33 (0)4 73 28 81 00 http://www.sigma-clermont.fr/

19 janvier 2019
Table des matières

Table des matières 1


Introduction 2
1 Protocole MODBUS 3
2 TCP/IP 5
2.1 Questions préliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Utilisation des utilitaires de maintenance de TCP/IP . . . . . . . . . . . . 5
2.3 Mise en ÷uvre de communications TCP/IP . . . . . . . . . . . . . . . . . 7

3 Développement d'une application de commande et de pilotage 9


Conclusion 14

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 1/14
Introduction

On souhaite développer une application de commande du chariot mobile par des clients
distants connectés sur le réseau TCP/IP. Le serveur communique avec le robot au travers
un émetteur/récepteur sans l branché sur le port série.

Figure 1
Le fonctionnement de l'application est le suivant :
• L'utilisateur décrit par l'intermédiaire d'une interface proposée par l'application
client la mission du chariot (travail + station).
• Le client envoie les données relatives à la mission au serveur.
• Le serveur génère les trames MODBUS et les envoie au chariot mobile, puis il sur-
veille le déroulement de l'exécution de la mission.
• A la n de l'exécution de la mission ou si une anomalie est détectée, le serveur envoie
une information au client pour lui signaler la réalisation de la mission.
• Le retour sur l'exécution de la mission est aché pour l'utilisateur.

Les objectifs de ce TP sont :


• Découvrir le protocole TCP/IP
• Découvrir le protocole de communication MODBUS
• Développer une application pour le pilotage du chariot mobile à partir de plusieurs
ordinateurs distants. L'utilisation des deux protocoles sera nécessaire.

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 2/14
1 Protocole MODBUS

Le réseau MODBUS est un réseau d'automatisme qui permet la connexion d'automates


(API), des calculateurs et des systèmes d'automatismes variés tels des terminaux d'atelier,
des systèmes de lecture-écriture d'étiquettes électroniques, des variateurs, des régulateurs,
etc.
C'est un réseau du type maître-esclave sur une topologie en bus au travers le plus
souvent d'une liaison physique RS232-C, RS422 ou RS485 et à des vitesses de transmission
allant de 50 à 19200 bauds (unité égale à l'inverse de la durée en secondes du plus court
élément du signal, ou de l'intervalle unitaire dans un signal numérique).
1. Il existe deux types de protocoles MODBUS : ASCII (American Standard Code for
Information Interchange) et RTU (Remote Terminal Unit). Le format RTU permet
pour une même vitesse de transmission un plus fort débit de données. Le format
ASCII ore une "souplesse" plus importante sur les timing inter-octet (jusqu'à 1
seconde) et constitue une véritable transmission asynchrone. Le RTU est cependant
plus utilisé dans le contexte industriel pour avoir un fort recouvrement d'erreur de
transmission permis par l'utilisation du CRC16.
2. Pour accéder à la ligne de communication, le protocole MODBUS utilise un mé-
canisme de question/réponse entre un maître et un esclave ou la diusion d'une
demande du maître vers tous les esclaves. Dans ce second cas, les postes esclaves
exécutent la demande sans renvoyer de réponse ensuite.
3. Le protocole MODBUS permet de lire ou d'écrire un ou plusieurs bits, un ou plu-
sieurs mots, le contenu du compteur d'évènements ou celui des compteurs de diag-
nostic. Il permet aussi à ses utilisateurs de pouvoir paramétrer certaines caracté-
ristiques du protocole comme par exemple sa vitesse de transmission, le nombre de
bits de données, son mode de transmission ASCII ou RTU, etc.
• Le mode Question / Réponse (Query / Response) : émission d'une de-
mande à destination du poste esclave. Une seule transaction question-réponse
peut être initiée à la fois. L'esclave répond après exécution.
• Le mode Diusion (Broadcast) : Emission d'un ordre à destination de tous
les esclaves connectés au réseau. La demande exécutée sans attente de réponse.
4. Pour une application de supervision, on désire lire 16 bits consécutifs sur l'esclave
numéro 1 à partir de l'adresse 271 :
• Trame question RTU : 01 01 010F 0010 390C
(numéro poste esclave + fonction lecture de n bits de sortie en RTU + Numéro
du 1er bit lu qui est 271 écrit en hexadécimal + Nombre de bits à lire égal à
16 écrit en hexadécimal + CRC16)
Trame réponse : 01 01 01 00(ou 01) 00(ou 01)...... 00(ou 01) 390C
• Trame question ASCII : 01 01 010F 0010 1E
(numéro poste esclave + fonction lecture de n bits de sortie en RTU + Numéro
du 1er bit lu qui est 271 écrit en hexadécimal + Nombre de bits à lire égal à
16 écrit en hexadécimal + clé LRC)
Calcul de clé LRC : 0101010F0010 => 3410 => 1000102 => 0111102 (complé-
mentaire) => 1E16
5. On désire écrire 2 mots consécutifs sur l'esclave numéro 1 à partir de l'adresse 20 :

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 3/14
• Trame RTU : 01 10 0014 0002 04 0001 0002 5123
(04 : nombre d'octet, 0001 : premier mot, 0002 : deuxième mot)
Réponse de l'esclave : 01 10 0014 0002 CC01
• Trame ASCII : 01 10 0014 0002 04 0001 0002 D2 CR LF
6. On désire mettre le bit 272 (lancement mission) à 1 sur l'esclave numéro 1 :
• Trame RTU : 01 06 0110 FF00 038C
• Réponse possible de l'esclave : 01 05 01 01 89D1

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 4/14
2 TCP/IP

2.1 Questions préliminaires

Il est nécessaire de déterminer quelques éléments préliminaires avant la mise en ÷uvre


du protocole TCP/IP dans notre application de pilotage.
1. L'adresse IP du poste est : 172.16.8.222
2. L'adresse IP est de classe B (Le premier octet a une valeur comprise entre 128 et
191).
3. La passerelle par défaut utilisée est : 172.161.100
4. Autres passerelles congurées : Aucune car il n'y a pas de changement de réseau.
5. Il n'y a pas d'adresses WINS car la gestion des noms se fait ici par DNS (on fonc-
tionne en statique). Depuis Windows 2000, Microsoft recommande d'utiliser Active
Directory et le DNS Dynamique plutôt que WINS.
6. Serveur DNS est un serveur qui permet d'assigner un nom à une adresse IP (et vice
versa) qui est indispensable de pouvoir communiquer sur Internet. DNS est similaire
à un annuaire téléphonique, il eectue un mappage sur la couche application et utilise
UDP et TCP comme protocoles sousjacents.
7. Ordres recherche du service DNS : il cherche d'abord l'extension (.fr,...) puis le nom
du site, et enn le sous domaine (www., nom de machine).
8. Il n'y a pas de routage sur ce poste car il ne possède qu'une carte Ethernet pour
faire la connexion et qu'on ne change pas de réseau.

2.2 Utilisation des utilitaires de maintenance de TCP/IP

Cette partie à pour but de prendre en main des commandes utilitaires utilisable dans
une fenêtre MS/DOS.
IPCONFIG : Vérie les paramètres de conguration TCP/IP sur un hôte, notamment
l'adresse IP, le masque de sous-réseau et la passerelle par défaut. Il permet no-
tamment de déterminer si la conguration est initialisée ou si une adresse IP est
congurée en double.
L'adresse physique associée à la machine est : 90-B1-1C-5F-6C-29

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 5/14
Figure 2  IPCONFIG

PING : (Packet InterNet Groper) programme utilisé par les utilisateurs TCP/IP pour
tester l'accessibilité d'une certaine destination en lui envoyant une demande d'écho
ICMP et en attendant sa réponse.

Figure 3  PING

ARP : Utilisé pour faire le lien entre une adresse de haut niveau IP et une adresse phy-
sique. ARP n'opère que sur un même réseau physique et son usage est limité aux
réseaux qui permettent la diusion.

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 6/14
Figure 4  ARP

NSLOOKUP : Examine dans la base de données DNS les entrées relatives à un hôte ou
à un domaine particulier. On teste cet utilitaire pour connaître l'adresse IP d'autres
PC connectés à notre réseau.

Figure 5  NSLOOKUP

2.3 Mise en ÷uvre de communications TCP/IP

Le  contrôle  WinSock de Visual Basic permet de mettre en ÷uvre des communica-


tions en utilisant le protocole TCP ou UDP.
On développe alors, dans un premier temps, deux applications qui s'échangent des
données au travers d'une liaison WINSOCK sur une connexion TCP. Le protocole TCP
étant orienté connexion, pour que deux applications s'échangent des données, il faut que
l'une soit "client" et l'autre "serveur". Nous développons d'abord les deux programmes
("client" et "serveur") sur la même machine. Nous installons ensuite les programmes sur
deux machines distantes pour vérier leur fonctionnement. Les deux programmes ne sont
pas entièrement débuggés mais ils le seront dans l'application suivante (ex : transmission
de message alors que non connecté...).

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 7/14
Figure 6  Interface côté client Figure 7  Interface côté serveur

Figure 8  Code côté client

Figure 9  Code côté serveur

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 8/14
3 Développement d'une application de commande et de

pilotage

L'objectif de cette partie est développer une application qui permet de piloter le chariot
loguidé à partir de plusieurs ordinateurs distants tel que présenté dans l'introduction du
TP.

Figure 10  Composants de la cellule


Nous développons donc deux parties : l'application qui communique entre le client et
le serveur, puis l'application qui communique entre le chariot et le serveur et qui reçoit
les ordres du client.
Le client crée sa commande en appuyant sur les boutons successivement en choisis-
sant d'abord le poste puis l'action à faire. A chaque étape, l'utilisateur peut annuler sa
commande et reprendre à zéro. Il y a une textBox pour visualiser la commande qui sera
envoyée au serveur avant d'être envoyé. Une fois que le message à été reçu, le serveur
communique la bonne trame au chariot et envoie un message au client annonçant que la
commande a bien été envoyée.

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 9/14
Figure 12  Interface côté serveur
Figure 11  Interface côté client

Figure 13  Code côté client 1/4

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 10/14
Figure 14  Code côté client 2/4

Figure 15  Code côté client 3/4

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 11/14
Figure 16  Code côté client 4/4

Figure 17  Code côté serveur 1/2

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 12/14
Figure 18  Code côté serveur 2/2

Figure 19  Application en cours de fonctionnement

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 13/14
Conclusion

Ce TP nous a permis de mettre en pratique les protocoles MODBUS et TCP/IP, par


l'intermédiaire de la programmation d'applications sous Visual Basic 6.0, pour le pilotage
d'un chariot loguidé.

S9_CRI_RapportTP_Modbus-TCP/IP.pdf 14/14

Vous aimerez peut-être aussi