Accélérer la communication avec un port série ?

Bonjour à tous !
Je souhaite programmer un générateur électrique (celui-ci : http://cp.literature.agilent.com/lit...3250-90002.pdf ), et pour cela j'utilise un script Python qui génère une liste de points avant de l'envoyer à l'appareil par un port série.

Pour l'instant j'utilise ce code :

Code:

---

ser = serial.Serial(port='COM1', baudrate=115200, bytesize=8, parity='N', stopbits=2, timeout=1, xonxoff=0,dsrdtr=1, rtscts=0)

---

pour ouvrir le port

J'ai mis le baudrate maximum supporté par le générateur, et je transmets mes données sous forme de listes d'entiers entre -2047 et 2047 (cela double la vitesse de transfert par rapport à une liste en ASCII) , mais le transfert dure quand même plus de 10 minutes contre les 23s "optimales" annoncées par le constructeur...

Auriez-vous des suggestions pour améliorer la vitesse de transfert?
Merci !

Bonjour,

Peux-tu nous montrer un extrait minimaliste de ton code pour comprendre quelle quantité de données tu envoies et de quelle manière tu envoies tout ça ?

Malheureusement je n'ai que mon téléphone actuellement, je ne pourrais envoyer le code que plus tard...

Cependant si cela peut t'aider j'utilise un ser.write("data:dac... ") avec à la place des trois petits points une suite de nombres séparés par des virgules, le tout en string. Ils sont sur une même ligne et on termine par un \r\n pour indiquer que c'est fini
Il y a 32k entiers à transférer
S'il te faut d'autres détails j'essaierai de les retrouver

(et encore merci pour ton aide)

Bonsoir,

Le contrôle de flux joue beaucoup sur la vitesse de transfert.

Est-ce que vous êtes certain qu'il est bien réglé sur l'AWG ?

Handshake Mode: DTR/DSR (factory setting)

À défaut d'avoir un oscilloscope pour s'assurer qu'il est bien supporté par le port et la librairie serial, il faudrait essayer en mode RTS/CTS. xonxoff=0, dsrdtr=0, rtscts=1

Et si le problème est le même, problème de câble par exemple il est possible d'utiliser le contrôle de flux directement en données avec le mode XON/XOFF, mais dans ce mode on ne peut plus utiliser la communication en binaire étant donné que les valeurs 0x11 (XON) et 0x13 (XOFF) sont réservées. xonxoff=1, dsrdtr=0, rtscts=0

Les différents protocoles sont très bien expliqués dans le manuel en page 221 : RS-232 Handshake Methods

Bonjour !
Merci pour ces éléments de réponse, malheureusement cela ne change pas grand chose : j'ai beau changer le baudrate et les protocoles, le temps de transfert reste quasi inchangé (52 +-1s pour 8192 points)


Le cable qui fait la communication a le schéma suivant, si ce n'est que les broches 1 ne sont reliées à rien :
https://en.wikipedia.org/wiki/Null_m...dem_Wiring.png
Le problème pourrait-il venir de là?

Edit : Deux détails : la modification du baudrate du port peut quand même influer si l'on descend en dessous des 9600. J'ai changé le baudrate du port dans le panneau de configuration pour le mettre à 115200 mais cela n'a rien changé.
Le fait de changer le "stopbits entre 1 et 2 ne semble avoir aucun effet, alors que le manuel stipule que c'est important et qu'il y a toujours "un startbit et un stopbit".

Salut,

Votre sujet est tellement spécifique au matériel qu'il serait sage de poster ces questions dans un forum d'utilisateurs de ces générateurs de signaux.
A vous de voir.

- W

Citation:

---

Envoyé par Afanthommme

Bonjour !

Edit : Deux détails : la modification du baudrate du port peut quand même influer si l'on descend en dessous des 9600.

---

Bonsoir,

Ça ressemble fortement au cas d'un contrôle de flux absent.

Vous devriez essayer avec un logiciel dédié à la validation de port série, quelque chose de plus complet que l'hyperterminal, exemple ci-dessous qui permet de tester à la volé plusieurs confs changer et voir les status de la ligne.

Est-ce que le signal transféré est bien valide une fois chargé sur l'AWG? Aucune perte ? Il faudrait essayer de le récupérer pour vérifier.

Pièce jointe 181829

Salut YCL-1!
Je vais essayer de trouver quelque chose dans ce goût là, ça sera en effet plus pratique !

Sinon le signal reçu sur l'awg est tout à fait convenable, je n'ai pas vérifié à un niveau suffisamment fin pour détecter des erreurs sur un point mais l'allure globale est très fidèle à ce qui est attendu

Edit: en fait c'était une fonction appelée dans la ligne de l'envoi qui faisait tout ralentir.