problème de communication série RS232 et Labview

[Mumu0412]

A Oli:

Le code de ton erreur signifie: la référence d'objet spécifié n'est pas initialisée. Je pense qu'il ne trouve pas ton appareil.

[Mumu0412]

A JB:

L'exemple que j'utilise est l'exemple est celui intitulé: Basic Serial Write and Read provenant du dossier Série.

[Olivier_L]

Bonjour,

Par rapport à votre erreur -1073807298, il semblerait qu'elle vienne d'un problème au niveau du buffer de réception.

Ensuite, je suppose que le nombre d'octets lus que vous récupérez est fourni par la fonction VISA Read. Je suis étonné que dans la mesure où cette fonction retourne un nombre d'octets lus, elle ne vous affiche aucune donnée en sortie.

D'autre part, avez-vous essayé de communiquer avec votre appareil à partir de l'hyperterminal? Cela permettrait de s'affranchir des problèmes éventuellement liés à VISA et s'assurer de la bonne communication/configuration de votre appareil.

[oli67]

Je n'ai pas tout compris. Tu veux modifier le nombre d'octets recu par ton pc c'est ça?

Si c'est ça, il faut câbler sur le visa read "nombre d'octets" en entrée, tu n'a cas augmenter cette constante!

Pour moi c'est ok, j'arrive à communiquer avec mon appareil. Il ne me répond pas toujours ce que j'attend mais c'est le temps de le prendre en main.

Mon problème était que j'utilisait un cable croisé alors qu'il m'en fallait un droit (cela n'était pas spécifié dans la doc) et sur la face avant de l'appareil il y a un bouton "remote" qu'il faut enclencher pour le piloter via un pc.

Merci à tous pour votre aide!

[JB]

L'ancienneté de l'appareil ne dit rien du tout par rapport au type de câble à utiliser. Vous devez du moins être en possession d'un document définissant le protocole de communication (nom, format, contenu des commandes à envoyer et des réponses attendues) ! Tenter de communiquer avec un appareil sans connaître le protocole et les paramètres peut en effet rapidement virer au mal de tête.

Comment les paramètres de communication sont-ils définis au niveau de l'appareil lui-même (écran, programme de configuration...) ? Il vous faut vous assurer que cette configuration corresponde à celle que vous définissez dans votre code.

Que voulez-vous dire par "Je n'ai à ce jour obtenu aucune donnée de l'appareil si ce n'est le nombre d'octets réellement lus." ? Votre réponse est contradictoire. Recevez-vous oui ou non une réponse à la commande que vous envoyez ? Le problème se situe-t-il au niveau du décodage des données reçues ou ne recevez vous vraiment rien ? Si deuxième réponse, que voulez-vous alors dire par "nombre d'octets réellement lus" ?

Prière d'indiquer quel exemple LabVIEW vous utilisez. S'agit-il d'un exemple original ou lui avez-vous apporté des modifications ?

Désolé pour toutes ces questions mais je cherche à mettre de l'ordre dans les idées...

[MarcC]

Les TESA envoyent souvent leurs données en ascii. essai ce bout de code.

[JB]

---

MarcC a écrit:
Les TESA envoyent souvent leurs données en ascii. essai ce bout de code.

---

Il suffit d'utiliser la fonction String To Byte Array pour convertir une chaîne de caractères en un tableau de codes ASCII correspondants.

Pour l'heure, mon problème est que je n'ai pas encore réussi à avoir une certitude quant à la source du problème : aucun caractère reçu ou décodage de ce qui a été reçu...

[JB]

---

Mumu0412 a écrit:

A JB:

L'exemple que j'utilise est l'exemple est celui intitulé: Basic Serial Write and Read provenant du dossier Série.

---

Il faut bien comprendre qu'à chaque fois que vous exécutez cet exemple basique, le port est reconfiguré. Ceci efface toute donnée éventuelle et peut donc conduire à des messages incomplets et des erreurs de trame ou autre.

Dans une application "réelle", il faut séparer les opérations :

1. Configuration unique
2. Boucle d'écriture/lecture (par exemple jusqu'à la pression d'un bouton d'arrêt)
3. Libération unique

L'exemple Advanced Serial Write and Read montre une telle structure de programme. Je vous suggère de continuer vos essais avec cet exemple (perfectible mais déjà nettement meilleur) et de vous en inspirer pour votre code personnel.

Message Edité par JB le 05-26-2009 12:21 PM

[JB]

---

Mumu0412 a écrit:

A JB:

J'oubliais de préciser aussi que je reçois bien le nombre d'octets transmis mais je ne sais pas si c'est du Koctets ou simplement des octets. Et je n'arrive pas à décoder le nombre d'octet pour obtenir la valeur que m'affiche l'appareil.

---

koctets ou octets : sans la moindre importance ! Oubliez cette question ! S'il y a beaucoup de données, on parle de k, M, G ou même Toctects pour éviter les multiples 0. Ce qui importe est le contenu et le format des données. Tout cela se trouve dans un protocole de communication sur lequel vous devez mettre la main si vous ne le possédez pas. Sans cela, il sera impossible de décoder les réponses de l'appareil.

[Mumu0412]

A JB:

L'ancienneté de l'appareil ne dit rien du tout par rapport au type de câble à utiliser. Vous devez du moins être en possession d'un document définissant le protocole de communication (nom, format, contenu des commandes à envoyer et des réponses attendues) ! Tenter de communiquer avec un appareil sans connaître le protocole et les paramètres peut en effet rapidement virer au mal de tête.

Comment les paramètres de communication sont-ils définis au niveau de l'appareil lui-même (écran, programme de configuration...) ? Il vous faut vous assurer que cette configuration corresponde à celle que vous définissez dans votre code.

Que voulez-vous dire par "Je n'ai à ce jour obtenu aucune donnée de l'appareil si ce n'est le nombre d'octets réellement lus." ? Votre réponse est contradictoire. Recevez-vous oui ou non une réponse à la commande que vous envoyez ? Le problème se situe-t-il au niveau du décodage des données reçues ou ne recevez vous vraiment rien ? Si deuxième réponse, que voulez-vous alors dire par "nombre d'octets réellement lus" ?

Prière d'indiquer quel exemple LabVIEW vous utilisez. S'agit-il d'un exemple original ou lui avez-vous apporté des modifications ?

Désolé pour toutes ces questions mais je cherche à mettre de l'ordre dans les idées...

Ok d'accord je vois. Je ne suis pas assez clair, je vais essayer de l'être par la suite.

Je ne reçois pas de réponse de la commande que j'envoie mais je reçois le nombre d'octets transférés par mon instrument au PC.

L'exemple que j'ai utilisé est un exemple original auquel je n'ai apporté aucune modification.

Mon problème est que je n'arrive pas à obtenir les données chiffrés de mon instrument dans ma facce-avant qui correspond à la partie Read String, je n'ai aucune réponse à ce niveau là.

Donc il y a bien une communication mais la commande que j'utilise: *IDN? n'est pas approprié à mon appareil.

Il faut que je trouve la commande appropriée pour communiquer avec.

Si le PC détecte bien un transfert d'octet, serait-ce un problème de décodage ? La commande que j'utilise est-elle approprié ?

J'ai déjà essayé de contacter le constructeur mais sans réponse car je n'ai pas les commandes nécessaires.