serialport de vb.net contre mscomm de vb6...problème vitesse

Question

Bonjour, 2 soft dialoguent entre eux via port série (ne me dites pas "utilises l'ethernet..." pas possible ici malheureusement...donc port série imposé)

Principe général:

les soft se renvoient des acquittements dès que des données arrivent sur leur port série respectif (évenemnt oncomm)

Le soft 1 suite OnComm lit son port, renvoit un ack au soft 2 qui lui reçoit le ack et renvoit un ack au soft 1 et ainsi de suite.

Ajout d'un timeout maxi d'attente de réponse sur le soft1.

Le soft1 est en vb.net express 2008.

le soft2 lui a 2 versions , une en vb.net express2008 et l'autre en vb6.

Je lance soft1 et je n'y touche plus.
je lance le soft 2, un coup en vb.net et l'autre essais en VB6

Je vois très concrètement qu'en version vb6 je peux envoyer /recevoir des données toutes les 5 ms sans problème, en vb.net j'ai des loupés très aléatoires 

question: 
- le nouveau composant serialport est-il en cause ?
- vb.net en général ?
- comment signaler un éventuel pb à microsoft ou leur demander de l'aide ?

merci pour votre aide

cs_Jack · Answer

Salut
Les ports série ne sont pas asynchrones et nécessitent un réglage de vitesse, ce qui ne garantit pas le temps de transition.
Hors mis ce délai, il ne devrait pas y avoir de loupé, le buffer de chaque liaison devrait faire son office (à concurrence de 8ko ou 16ko de stockage).
Dans les deux cas (.net et VB6), les tailles de buffer sont-elles réglées aux même valeurs ?
(ReadBufferSize en .Net, InBufferSize en VB6)
Ce qui peut faire des effets de loupé, c'est une erreur de paramétrage : je pense que tu les as revérifiés plusieurs fois (vitesse, parité, DataBits, StopBit, Handshake.
En .Net, tu spécifies aussi des TimeOut de lecture et d'écriture : vérifie qu'ils ne sont pas trop faibles.

Type de contrôle de flux (Hanshake) ?
Matériel par cablage + RTS/CTS ou Xon/Xoff (sans cablage autre que les datas 2-3-7) ?

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

cs_jeanmi45 · Answer

merci pour ta réponse.
cablage de base 2-3-5/3-2-5 donc pas de handshake
paramétrage identique bien sur.
Quand je dis "loupés", c'est que le soft2 aurait du m'envoyer une trame, j'aurais du l'intercepter mais il n'en est rien....
J'avais vu sur un site un gars qui avait vu aussi que le serialport était plus lent que mscomm, mais avant d'intégrer ce truc je voulais avoir votre avis. D'autre part g vu qu'on est en SP1...quelles sont les modifs apportées ?

cs_Jack · Answer

Ok
Ma réponse n'est que théorique, je n'ai jamais mis en pratique de port COM en .Net.
Je ne pense pas qu'une tel interface "antique" ait encore des secrets que les équipes de dev auraient loupés, je veux dire par là que je ne pense pas qu'il ait de bug.
Si le port COM ne déclenche pas d'évènement (*), les données restent dans le buffer, même si on les lit plus tard, elles restent là et ne seront vidées que par une réinit du port ou par la lecture du buffer.
(*) Il faut se rappeler qu'il s'agit d'une interface matérielle et que l'interruption de gestion du port ne sera traitée que si le processeur a du temps (surcharge temporaire ?), quitte à refleter l'évènement au système (côté programmation) avec du retard. 

Par acquit de conscience, relit bien les définitions de taille de buffer en lecture, de la quantité de données devant déclencher un demande de lecture, ainsi que la méthode de lecture et de traitement des données lues.

cs_jeanmi45 · Answer

Tu m'as mit le doute et j'ai tout repassé. Y'a un truc qui change un peu entre les 2 composants, c'est la notion de timeout en lecture/ecriture, la taille des buffers par défaut.
J'ai confirmé par plusieurs millions d'échanges entre les 2 softs ce week end. Le même soft avec soit mscomm32, soit serialport. Avec serialport, des retards aléatoires à la réponse. Avec MSComm32, pas un seul loupé sur 2 millions d'échanges.
J'ai cru comprendre un truc important je pense. L'évenemnt oncomm est traité sur un thread secondaire avec le serialport. Avec mscomm, je ne sais pas. La chose que j'avais noté, c'est que la notion de thread n'était pas bien géré sous vb6, et c d'ailleurs bien agréable à utiliser sous vb.net. Y'a t il un truc à creuser en ce sens ? Je me demande si ce fameux thread secondaire est aussi bien fait qu'avec le bon vieux mscomm.

Pour "calculer" le temps de réponse, j'utilise une méthode pas très précise, mais après tout, c la même pour les 2 tests, donc ça me va. Je lance un thread après chq retour oncomm du soft1, et je l'endors pendant 1ms. Là les puristes diront, c pas précis, et ils ont raison à 100%. Mais encore une fois, c le même soft1 que je ne touche pas. C le soft2 avec lequel j'utilise soit mscomm soit serialport. Donc au bout d'une ms, je regarde si g à nouveau une trame. Avec serialport, j'ai souvent des retard et très aléatoire. Avec mscomm, no pb.
G une appli à faire qui utilise 5 port com en même temps et à des cadences importante de 200-300 000 trames / heure, soit 1M5 par heure à gérer par le PC. Les moindres ms perdues, c autant de pb derrière. Voilà le pourquoi du comment je veux comprendre....merci pour votre aide.

BarthOlivier · Answer

Bonjour

Je suis en train de constater ce genre de problème. L'un de mes BETa testeur avec une machine moins véloce que la mienne a détecté des loupés sur les retours de trame (rapatriement de données par voie série). Je n'ai détecté aucun problème. J'ai donc installé un XP en VirtualBox et poussé le vice à utiliser CPU_KILLER. Je sais c'est un peu critique comme test mais bon. Visiblement le rapatriement de la voie série est lié a la surcharge des processus . (vous le saviez surement mais j'avais un doute car je pensais que la gestion COM était de bas niveau comme l'était le MsCOMM ?? ) Cela laisserai supposer qu'une couche logicielle moins dynamique gèrerai la voie série avec .NET ???

j'ai naïvement augmenté le "ReadBufferSize", pensant que cela venait de là mais mon problème persiste. Si vous avez trouvé une solutions à votre problème je suis preneur. Je me pose la question si je ne vais pas finir par implanter directement les fonctions du Kernell pour voir si cela change quelque chose.

MisterMok

cs_jeanmi45 · Answer

je suis content malgrès tout de voir que je ne suis pas tout seul ;o)
PLus sérieusement, g remonté le bug à microsoft qui m'a confirmé le pb il y a 2 jours...j'attends la suite des évenements, une mise à jour ??

la seule solution qui marche bien évidemment mais qui n'est pas "jolie" c d'utiliser le bon vieux mscomm32 !

bon courage

Serialport de vb.net contre mscomm de vb6...problème vitesse

6 réponses

Votre réponse

Discussions similaires