Discussions au sujet de NI LabVIEW
Problème communication modbus TCP
Résolu !
je vais regarder.
pour info, dans le lien Modbus, dans ma réponse l'autre jour, je n'ai pas copié le bon lien
je pensais à un autre tuto Tuto : LabVIEW et Modbus
ok : MODBUS TCP/IP ADU frames sent on registered port 502
le Mapping me semble simple.
si tu ping bien le device, je ne vois pas le problème.
tu as testé une autre adresse ? 0 par exemple
A+
Merci pour ce tuto, je ne l'avais pas encore lu au contraire des autres (Super boulot au passage 
)
Oui je ping bien le device et je ne vois pas non plus d'où peut venir le problème, je commence à vraiment tourner en rond la...
J'ai pas encore testé avec une autre adresse sur le device. Je vais essayer et je te tiens au courant.
Merci encore pour le temps consacré.
salut
Shuhi a écrit :Bon alors je viens aux nouvelles.
tu viens donner des nouvelles 🙂 mais pas aux nouvelles 🙂
je n'avais pas pensé à te proposer de tester avec un autre device... très bon reflexe!!
merci pour ton retour
tu as même le droit de cliquer sur l'étoile "compliment" si tu veux mettre des compliments à ce post
A+ et bonne fin de journée
Bonjour,
Alors, je reviens à la charge sur ce fameux problème après une petite pause.
Le construteur de mon régulateur m'a gentiment envoyé un remote qui communique en MODBUS TCP depuis le PC vers mon régulateur. Et cela fonctionne.
Donc forcement, cela veut dire que la communication en MODBUS TCP fonctionne.
Ne sachant pas trop que chercher pour essayer de débloquer mon soucis, j'ai utilisé un espionneur de trame, et je me permets de joindre ce qui est observé.
Peut être que quelqu'un pourra m'aider.
J'ai l'impression que mon soucis vient du fait que je reçois de la part du regulateur uniquement des trame de longueur 0.
Est-ce cela?
Je vous remercie d'avance.
Nico
salut le protocole "Modbus/TCP" est le N°5, et je ne vois pas de réponse? c'est via LabVIEW?
les lignes 10 et 11 sont en TCP (pas modbsu TCP), c'est aveec le soft "constructeur"?
Ton idée d’utiliser wireshark, un espion de trame, est une bonne idée.
Surtout par comparaison avec le logiciel du constructeur, tu vas pouvoir comparer les contenus des trames.
Normalement (si je me souviens bien la dernière fois que je l’ai utilisé) tu dois avoir « modbus TCP » dans la colonne « protocol » aussi bien dans la question que dans la réponse.
Salut
La capture écran te démontre que la trame LabVIEW est bien analysée comme une trame Modbus TCP, mais que l'appareil ne répond pas.
Je pense que l’idée est :
- utiliser le logiciel du constructeur pour transmettre une demande. (copie écran)
- Analyser le contenu de la trame (de la question) (double clic sur la ligne, copie écran)
- utiliser le logiciel LabVIEW pour transmettre la même demande
- Analyser le contenu de la trame (de la question)
- différence ? il faut analyser le PDU (fonction et data)
sinon
Shuhi a écrit : Devrais-je essayer de communiquer en TCP plutot que modbus TCP?
modbus TCP est bien un protocol réseau sur couche TCP.
Ton appareil est un serveur modbus, il doit répondre à une question sur "transport" TCP avec un protocol "modbus" (donc modbus TCP)
il faut distinguer la couche de « transport » (TCP, série,…) et l’encodage des données « protocol »
pour faire très simple
- 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.
- 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). L'API modbus de National Instruments te "fabrique" cette frame de façon transparente
- Wireshark te permet de visualiser cette trame, et donc de comprendre la différence
simple, non?
A+
