Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Problème de communication via modbus

Résolu !
Accéder à la solution
Highlighted

qsub-D a écrit :

Tout d'abord, j'ai bien testé avec les deux baud rate différents et sans plus de succès.

 


Salut, l’histoire du baud rate est une erreur de ma part. Je n’avais pas bien analysé le code d’erreur. Mais c’est bien d’avoir vérifié, cela permet d’écarter la piste.

 

0 Compliments
Message 11 sur 31
2 012 Visites
Highlighted

qsub-D a écrit :

 

Pour ce qui est du code d'erreur, j'ai joint une première image d'un comTester où on peut voir que la communication est, selon le VI, bien établie, et qui illustre le code d'erreur 7298. Cette erreur arrivait généralement au premier VISA read ou write utilisé. 

 


perso je module ta réponse : « on peut voir que la communication est bien établie ».

Je pense que « non ». L’ouverture et la configuration du port série OUI, mais il n’y a pas de communication.

Pour moi la configuration du port série via l’API VISA est opérationnelle, donc la ressource VISA, dont l’ALIAS com est passé en paramètre d’entrée est fonctionnelle.

Fonctionnelle au sens de l’API VISA, donc ressource matérielle détectée par l’OS, configurable par l’API VISA.

Mais il n’y a pas de communication pour le moment.

Dans ton image nous pouvons « voir » le dernier message TX transmit, mais il n’y a pas de Rx réception, donc jamais eu de communication.

 

0 Compliments
Message 12 sur 31
2 012 Visites
Highlighted

qsub-D a écrit :

illustre le code d'erreur 7298. Cette erreur arrivait généralement au premier VISA read ou write utilisé. 

 


j’ai le sentiment que tu as l’erreur sur le « Write » et pas le « Read ».

La fonction modbus « read holding register » commence par une écriture sur la couche transport série d’une trame. La trame est composée de l’ADU.

Pour faire « simple » la fonction logicielle va demander (éciture VISA) au SLAVE modbus de lui fournir des données (tableau U16).

Dans la copie écran l’erreur est sur la fonction Write

 

Message 13 sur 31
2 011 Visites
Highlighted

qsub-D a écrit :

 

En revanche, un code qu'on m'a fournis (et dont j'ai joint un impr-écran) m'a permis de constater que cette erreur n'est pas insolvable 🙂

 

Par ailleurs, j'ai essayé de tester la communication avec le soft OEM et elle ne fonctionne pas (j'ai testé le soft sur 2 pcs différents pour être sûr), alors que cela marchait il y a 2 ans, peut-être le câble est -il endommagé et c'est la raison pour laquelle je vais tester la communication avec le RS232.

 

N'hésitez pas à me reprendre si j'ai dit une bêtise ou si j'ai manqué quelque chose.


J'ai le sentiment que l'erreur peut provenir de

http://digital.ni.com/public.nsf/allkb/60DDFED7EFEFE7188625705700750821

 

The problem comes from the VISA Write IRP_MJ_FLUSH_BUFFER request causing an INVALID DEVICE REQUEST response from the device. By default, each VISA Read and Write is followed by a VISA Flush call when communicating via RS-232. You can change the VISA Buffer setting to keep VISA from executing the flush call to avoid this error.

If you call the VISA Set I/O Buffer function at the beginning of your application (after the VISA Open, before any reads or writes) and set the mask to 48 (16 + 32, where 16 is the mask for receive buffer and 32 is the mask for transmit buffer) and the size to some value between 4k and the largest amount of data you ever expect to read or write, that will cause the flush command to not be executed.
However, if you do not call this function, VISA will segment all writes into 500 millisecond chunks and call flush after every write. By telling VISA that you will never use more than 4k or the value to which you set the size, VISA in turn will not call the flush.

 

par rapport à ton code (celui qui fonctionne) il y a set the mask to 48 

Non??

bufffer.png

Message 14 sur 31
2 009 Visites
Highlighted

Bonjour Monsieur Luc,

 

" je passe toujours régulièrement pour lire tes incroyables posts ! "

 

tu me fais toujours sourire quand tu dis ce genre de chose  ...

mes posts n'ont rien de particuliers .... m'enfin ...  Smiley indifférent    (si, de grosses âneries parfois)

 

heuu ... à moins que tu aies quelque chose à me demander ?  Smiley très heureux  (je te taquine)

 

Belle journée pour toi Luc 

 

(oui, il commence à faire beau ... même en Belgique ... donc il fait beau sur toute la planète)   Smiley clignant de l'œil

0 Compliments
Message 15 sur 31
2 008 Visites
Highlighted

En revoyant mes impr-écrans, je me suis rendu compte que j'avais oublié de lancer "MB slave example" en parallèle de mes VI testé XD

 

ça n'a pas loupé, et ça marche finalement, je peux désormais recevoir et envoyer des informations sur les registres !! 😛

 

Merci à tous pour vos réponses, ça m'a beaucoup aidé et fait progresser 🙂 

0 Compliments
Message 16 sur 31
1 998 Visites
Highlighted

qsub-D a écrit :

En revoyant mes impr-écrans, je me suis rendu compte que j'avais oublié de lancer "MB slave example" en parallèle de mes VI testé XD

 

ça n'a pas loupé, et ça marche finalement, je peux désormais recevoir et envoyer des informations sur les registres !! 😛

 

Merci à tous pour vos réponses, ça m'a beaucoup aidé et fait progresser 🙂 


super! 🙂

mais excuse-moi car j’ai beaucoup bu hier soir, après la défaite de Barcelone, et je ne suis pas sûr de comprendre ta phrase : j'avais oublié de lancer "MB slave example" en parallèle

Tu es en série, donc Maître (PC) – Exclave (ton instrument), si tu lances en parallèle un slave, ce denier va répondre à la place de ton instrument. Si cela fonctionne, c’est bien, cela signifie que tu as fait un simulateur. Non?

Mais en quoi cela solutionne ton problème ?

En plus tu devrais avoir un timeout de communication sur le Read (si pas de device sur le bus) et pas une I/O error sur la fonction Write…

Non?

0 Compliments
Message 17 sur 31
1 995 Visites
Highlighted

Oui, je comprends, surtout que ça laisse le champ libre à Madrid et Munich désormais 😞

 

Ah je pensais qu'il fallait absolument "initialiser" le statut d'esclave du banc avec MB slave example, pour pouvoir ensuite utiliser MB master example.. (-_-)  

 

Du coup, je ne comprends plus pourquoi cela fonctionne maintenant et pas avant, faut croire que ce banc avait besoin de ça ...  En tout cas, c'est sûr à 100% que ça marche car je peux peux lire et écrire des données sur le banc. Ce n'est pas pas un vrai "eureka", mais il me convient 😛

 

 

 

 

Message 18 sur 31
1 981 Visites
Highlighted

perso je suis pour le real... 🙂

 

je pense qu'il faut absoluement faire un mask 48 : VISA Set I/O Buffer function at the beginning of your application (after the VISA Open, before any reads or writes) and set the mask to 48 

c'est pour cela que le code refonctionne

c'est le code de ton exemple N°2 qui est fonctionnel.

dans le code qui ne fnontionne pas, le N°1, tu ajoutes entre l'init port et la lecture des registres (donc les 2 vis modbus- juste après l'init), le mask 48 (donc juste avant de rentrer dans la boucle de lecture)

http://digital.ni.com/public.nsf/allkb/60DDFED7EFE​FE7188625705700750821

 

The problem comes from the VISA Write IRP_MJ_FLUSH_BUFFER request causing an INVALID DEVICE REQUEST response from the device. By default, each VISA Read and Write is followed by a VISA Flush call when communicating via RS-232. You can change the VISA Buffer setting to keep VISA from executing the flush call to avoid this error.

If you call the VISA Set I/O Buffer function at the beginning of your application (after the VISA Open, before any reads or writes) and set the mask to 48 (16 + 32, where 16 is the mask for receive buffer and 32 is the mask for transmit buffer) and the size to some value between 4k and the largest amount of data you ever expect to read or write, that will cause the flush command to not be executed.

 

 

0 Compliments
Message 19 sur 31
1 977 Visites
Highlighted

tu as une erreur I/O que tu corriges via la configuration "I/O receive and transmit Buffer" mask 48

 

bufffer.png

0 Compliments
Message 20 sur 31
1 975 Visites