Communication TCP/IP de base dans LabVIEW

Description

L’IP (Internet Protocol), l’UDP (User Datagram Protocol) et le TCP (Transmission Control Protocol) sont les outils de communication de base via réseau. Le nom TCP/IP est dérivé des deux protocoles les plus connus de la suite de protocoles Internet : Transmission Control Protocol et Internet Protocol. Grâce au TCP/IP, vous pouvez communiquer sur un réseau unique ou sur plusieurs réseaux interconnectés (Internet).

La communication TCP/IP fournit une interface utilisateur simple qui cache la complexité d’assurer des communications réseau fiables. Reportez-vous à la note d’application Utilisation de LabVIEW avec TCP/IP et UDP (lien ci-dessous) pour plus d’informations sur le fonctionnement de la communication TCP/IP. Reportez-vous à la spécification TCP (lien ci-dessous) pour des détails techniques sur TCP.

Utilisez les fonctions TCP/IP situées dans la palette Functions»Communication de données»Protocoles»TCP pour la communication TCP dans LabVIEW. Comme pour les communications DAQ, instrument et E/S sur fichiers, le processus comprend l’ouverture de la connexion, la lecture et l’écriture des informations, mais aussi la fermeture de la connexion.

Avec la plupart des communications d’E/S, le processeur est toujours le client qui établit une connexion avec le serveur du lecteur disque, le serveur d’instrument externe ou le serveur de carte DAQ. Avec les connexions TCP/IP, un ordinateur peut fonctionner en tant que client ou serveur. Le diagramme suivant représente une application client qui établit une connexion à un serveur distant avec TCP Ouvrir une connexion (TCP Open Connection). Le serveur, ou démon, écoute les connexions distantes et y répond de manière appropriée.


Les utilisateurs de LabVIEW peuvent développer des applications personnalisées pour la communication TCP/IP. Le programmeur est responsable du développement du client et du serveur. Reportez-vous à la note d’application Utilisation de LabVIEW avec TCP/IP et UDP (lien ci-dessous) pour plus d’informations sur la création d’un client TCP avec LabVIEW.

Puisque n’importe qui peut établir une connexion à un serveur, vous souhaiterez peut-être un contrôle d’accès au serveur. Le diagramme suivant montre comment le serveur utilise la valeur de sortie de l’adresse distante du VI, TCP Écouter (TCP Listen), pour déterminer si un client distant est autorisé à accéder au serveur.





Développement d’applications de communication
La plupart des applications ne se contente pas d’écrire et de lire une valeur. La communication est un processus continu disposant d’un protocole. Par exemple, supposons qu’un client envoie les quatre commandes suivantes par un entier de 8 bits au serveur :
1 = acquérir des données et les confirmer
2 = envoyer des données
3 = obtenir l’état
4 = fermer la connexion

Dans le diagramme suivant, une boucle While entoure le reste du VI. Cette disposition permet au VI de gérer plusieurs connexions séquentielles sans avoir à redémarrer après la fermeture de chaque connexion. Le VI ne peut pas gérer plusieurs connexions simultanées. La structure Cas principal détermine si une connexion valide s’est produite. Sinon, rien ne se passe. Si une connexion valide se produit, le VI entre dans une boucle While qui lit un octet à partir du port TCP/IP. Cet octet contient les commandes 1 à 4 du client. Si aucune commande n’est reçue dans le délai d’expiration de lecture, la condition par défaut de la structure sous-cas envoie une valeur VRAI au terminal de continuation de la boucle While interne pour maintenir la connexion active.




Le diagramme suivant montre les quatre autres cas de l’instruction de sous-cas. Chaque cas gère une commande précise que le serveur peut envoyer. Chaque cas envoie des informations au terminal de continuation, qui détermine s’il faut continuer ou non la boucle. En particulier, le cas Quitter renvoie toujours une valeur FAUX. Après avoir quitté la boucle, le serveur ferme la connexion auprès du client.


 
 


Ce type d’architecture de serveur vous permet de développer des serveurs flexibles pour les procédures de communication réseau plus complexes. Les protocoles que vous développez peuvent être plus complexes que l’exemple précédent.