04-14-2016 04:00 AM
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.
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
04-14-2016 04:06 AM
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.
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
04-14-2016 04:10 AM
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
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
04-14-2016 04:20 AM
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??
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
04-14-2016 04:22 AM
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 ... (si, de grosses âneries parfois)
heuu ... à moins que tu aies quelque chose à me demander ? (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)
04-14-2016 04:48 AM
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 🙂
04-14-2016 05:08 AM
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?
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
04-14-2016 07:01 AM
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 😛
04-14-2016 07:25 AM
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/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.
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
04-14-2016 07:28 AM
tu as une erreur I/O que tu corriges via la configuration "I/O receive and transmit Buffer" mask 48
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group