Erreur -1073807360 avec adaptateur USB - RS232 et DMM Keithley 2700

[Gnof]

Bonjour à tous,

J'ai besoin de conseils pour déterminer l'origine de l'erreur -1073807360. J'utilise un VI de test (Private -> _function -> KEITHLEY-2700_TEST.vi) pour tester chaque composant de mon driver, qui sera ensuite digéré soit par une application (LabVIEW) soit par une séquence de test (TestStand). Le VI qui me pose problème - pour l'instant - est KEITHLEY-2700_ReadSingleChannel.vi. Lorsque je l'exécute depuis le VI de test en cliquant sur READ SINGLE CHANNEL je ne rencontre aucun problème, et tout semble fonctionner correctement. J'ai alors intégré ce VI dans une boucle, accessible via le bouton LOOP CHANNELS et au bout d'un certain nombre d'itérations compris entre 30 et 150, j'ai invariablement l'erreur -1073807360 qui apparait. La seule façon de faire disparaitre cette erreur est de "déconnecter" l'appareil, soit en passant par le gestionnaire de périphériques, soit en débranchant la prise USB.

Voici ma configuration :

- Windows 10 32 bits qui s'exécute sur un ACER Aspire 5715Z Pentium Dual Core 64 bits ;

- LabVIEW 2016 version 16.0f5 ;

- un hub USB sur lequel sont connectés le DMM (Keithley-2700) une alimentation programmable et une carte relais. Ces 2 derniers appareils sont éteints pour l'investigation ;

- le DMM est relié au hub via un adaptateur USB-RS232 made in china (budget oblige…) model CH340 ; son driver est fourni par wch.cn et le fichier utilisé est C:\Windows\System32\Drivers\CH341SER.SYS.

Pour les besoins de l'investigation, j'ai posé des tempo de 100ms un peu partout. Je me suis assuré de n'envoyer d'une instruction à la fois au DMM, et je fais une lecture octet par octet. Je me suis également assuré de n'avoir qu'un seul VI VISA Write et le moins possible de VISA Read (la gestion du time out est différente pour une acquisition mono-voie que pour l'acquisition de plusieurs voies).

J'ai tenté de faire plusieurs manipulations sous le gestionnaire de périphériques (désactiver / activer l'appareil, mettre à jour le driver…). J'ai également tenté des actions sous MAX, et il ne me donne pas d'information en cas de dysfonctionnement. Ces manipulation étaient parfois couronnées de succès, souvent c'était un échec.

J'ai également eu un écran bleu mentionnant explicitement le driver CH341SER.SYS.

Je peux également, si nécessaire, fournir un log généré par Serial Port Monitor 7.0 (Eltima Sortware). Hélas, je ne dispose pas d'oscilloscope pour espionner la liaison physique en RS232.

J'ai également exécuté les VI SendCommand et ReadSCBuffer en mode Animer l'exécution, et l'erreur est survenu malgré tout à plusieurs reprise à la sortie de VISA Write. Tantôt le phénomène se manifestait par un timeout sur VISA Read suivi d'une erreur indiquant le manque d'information pour localiser la ressource matériel.

Je n'ai plus d'idée, et je me tourne vers vous. You are my only hope.

En vous remerciant d'avance.

[Jun']

   Bonjour Gnof,

Cette erreur semble assez liée au fait d'appeler plusieurs fois la même resources VISA ou bien de ne pas avoir fermé sa référence proprement; Peux-tu investiguer en ce sens?

Error 1073807360 Using VISA and LabVIEW Real-Time

Bonne journée,

[Gnof]

Merci beaucoup pour cette information.

Je vais reprendre mon driver et poser explicitement des visa open et visa close avant et après chaque read / write dans le même diagramme.

Cela m'impose de reprendre ma bibliothèque en supprimant les vi INIT et CLOSE.

J'ai fait quelques campagnes avec plusieurs pc (dont l'un dédié à l'espionnage du Tx et du Rx sur la liaison RS232) et tout me laisse croire que c'est mon adaptateur USB-RS232 et son driver qui posent problème.

Je vous tiens au courant, merci.

[PhilB58]

Un vi serait le bienvenu, c'est peut-être juste pas grand chose finalement, mais en aveugle, on a un peu de mal

[Gnof]

En effet, le zip n'a pas suivi le copy-paste de la version anglaise du post.

[ben64]

Pas très bien codé ce driver, l'utilisation de FGV en rend la lecture difficile mais le pire est l'utilisation d'une structure CASE d'erreur dans KEITHLEY-2700_Close.vi et l'utilisation de la fonction Clear Error à plusieurs endroits (incluant la fonction Read Single Channel). Donc s'il y a une erreur la ressource VISA ne sera pas fermée! La particularité des fonctions Close (File Close, VISA Close) est que ces fonctions puissent s'exécuter même en cas d'erreur. Une recommendation (qui ne règlera probablement ton problème mais pourrait en éviter certains serait d'enlever la structure CASE du vi KEITHLEY-2700_Close.vi.

La boucle LOOP_Channel n'est pas temporisée et celui crée probablement un problème au niveau de l'instrument. Ce type d'instrument n'est pas conçu pour gérer des lectures rapides, j'utiliserai un temps d'attente minimum de 200 ms (encore là c'est probablement très limite).

Ben64

[Gnof]

Merci pour ce retour ben64, je vais essayer d'ajouter la tempo de 200ms, voire plus.

Je ne savais pas que visa close avait la propriété de s'exécuter même en cas d'erreur, je vais faire ça un peu plus proprement. J'ai essayé de rajouter des clear error et des tempo à des fins d'investigations, mais je crois en effet que je vais commencer par reprendre ce driver proprement, en essayant d'appliquer les différents conseils.

Pour répondre à Jun', je suis en train de mettre mon driver à l'épreuve en faisant un open write read close dans le même vi, l'écriture n'est pas très propre, et j'essaye de monitorer les lignes Rx et Tx avec un autre ordinateur.

To be continued.

[ben64]

Tu as vérifié sur le panneau avant du DMM s'il y avait un message d'erreur?

Ben64