Discussion :

[Chekov]

Bonjour,

je commence un programme qui va gérer plusieurs ports COM (RS232) pour diriger plusieurs équipements avec plusieurs protocoles différents (VISCA, SC601, PELCO, etc.).

Je vais utiliser le controle MSCOMM 6.0 (10 plus exactement).

Je n'ai pas l'habitude d'utiliser ce genre de communication, aussi j'essaie de trouver des exemples, voire mieux: des tutoriaux, guides ou autres livres en ligne décrivant les meilleures pratiques pour programmer le port COM.
J'aimerais avoir un programme stable et je manque de retour d'expérience en la matière.

Donc s'il y a des avis éclairés en la matière, n'hésitez pas à me répondre...

Plus précisément (merci de m'avoir lu jusque là ), mes interrogations sont sur les événements à gérer pour que mon programme soit fiable, et la manière dont il émet et reçoit tout en étant stable (et restant fiable )...

Merci d'avance
Bon week end

[ProgElecT]

Ton titre: guide de bonnes pratiques, un peu subjectif, mais ....

Plus précisément (merci de m'avoir lu jusque là ), mes interrogations sont sur les événements à gérer pour que mon programme soit fiable, et la manière dont il émet et reçoit tout en étant stable (et restant fiable )...

En utilisant "recherche dans ce forum" avec les mots "port com"(en haut à droite de cette page), tu peux lire, entres autres, cette discussion, cela peut être une premiére approche

[Chekov]

Merci progElect, j'avais déjà lu ce post effectivement intéressant pour une première approche.

J'ai également lu le tutoriel sur ce site (http://grafikm.developpez.com/portcomm/), bien fait également pour une première approche.

Cependant, malgré avoir cherché (pendant un certain temps), je n'ai trouvé nul part de tutoriel plus poussé et plus abouti sur la (voire plutôt les) méthodes de programmation avec le port série. L'utilisation d'un timer ou pas, les cas à gérer, etc...
Je sais que l'expérience y fait beaucoup, mais je n'ai tout simplement pas cette expérience pour le programme que je vais commencer et il me parait donc tout à fait légitime de chercher un tel guide.

S'il existe de bons livres couvrant ce domaine en VB, ça m'intéresse aussi mais en second lieu.

Bonne fin de week-end.

[OhMonBato]

A mon avis ne te fais pas tout un monde pour ça

L'utilisation d'un timer peut se faire si tu veux lire le buffer du port com à intervale régulier (ça m'arrive pour certaines applications), sinon tu peux intercepter la réception des données dès leur arrivée avec l'événement OnComm. Les tutos sont une base de départ bien entendu si tu veux mais rien ne remplacera quelques tests avec tes périphériques. Si j'ai bien compris, il s'agit de caméras ? Quel est le but du programme si ce n'est pas indiscret ? (Simple curiosité personnelle).

En dehors de la lecture/écriture du buffer du port com, généralement dans mes programmes, je ne mets que quelques détections d'erreur sur les ports déjà ouverts/fermés (selon ce que tu fais), les ports inexistants, etc.. ce genre de choses et, je croise les doigts, je n'ai aucun soucis jusqu'ici.

[Chekov]

Bonjour,

L'utilisation d'un timer peut se faire si tu veux lire le buffer du port com à intervale régulier (ça m'arrive pour certaines applications), sinon tu peux intercepter la réception des données dès leur arrivée avec l'événement OnComm.

Justement, je ne comprend pas l'utilité d'utiliser le Timer plutôt que l'événement OnComm. Peux-tu me donner un exemple de cas concret ?

Si j'ai bien compris, il s'agit de caméras ? Quel est le but du programme si ce n'est pas indiscret ? (Simple curiosité personnelle).

Il s'agit d'un programme de supervision qui va diriger plusieurs caméras sur plusieurs ports COM. L'air de rien, il y aura beaucoup de communications. C'est pour cela que je m'inquiète de bien penser la méthode avant de commencer, car les caméras ne sont qu'une partie des équipements dirigés (pour te donner une idée, j'utilise au total une dizaine de ports COM).

Merci pour ta réponse.

Bon dimanche

[ProgElecT]

Salut

Utilisation d’un Timer ou de l’événement OnCom.

Pour ma part, tout dépend si tes périphériques(camera, zoom, rotor …) te renvois d’eux même une information (je pense a une reconnaissance de forme, positionnement du/des axes du/des rotors), si c’est le cas, l’analyse des trames reçues par l’événement OnCom semble suffisant pour maîtriser l’ensemble du processus.
Si par contre les périphériques ne font que recevoir des ordres (hors mis purement la vidéo), tu devras sans doute interroger le system dans son entier, à des intervalles régulier, donc là le Timer deviendra une nécessité.

Même si tes périphériques conversent dans les deux sens, un Timer qui les interroges tous les xx Sc, permet dans certain cas de détècter s’ils sont toujours bien accessibles par le programme qui est sensé les piloter, perte de liaison matériel, coupure d’un câble, vandalisme sur partie ou l’ensemble de capture d’événement …..
L’avis d’autres forumeurs (salut OhMonBato) pourront apporter une autre analyse, ou tout dut moins un complément utile.

[OhMonBato]

En dehors des remarques judicieuces de ProgElect (Salut l'ami ) j'utilise parfois un timer pour lire un port com quand au contraire le périphérique "crache" des données à une cadence 'infernale'.
Par exemple je m'interface parfois sur des gyrocompas qui sortent des messages à 10 ou 20 Hz alors que je n'ai besoin de connaitre le cap que toutes les secondes, je lis donc le buffer à l'intervale voulu et ne décode que le dernier message valide.

N'ayant jamais interfacé de caméras sur RS232, je ne sais pas trop quel type d'informations tu récupères ou envois, let ype de gestion des ports com dépend en grande partie de ça, mais en me relisant je ne fais que répéter ce qui est dit plus haut...

[Chekov]

Pour ma part, tout dépend si tes périphériques(camera, zoom, rotor …) te renvois d’eux même une information (je pense a une reconnaissance de forme, positionnement du/des axes du/des rotors), si c’est le cas, l’analyse des trames reçues par l’événement OnCom semble suffisant pour maîtriser l’ensemble du processus.
Si par contre les périphériques ne font que recevoir des ordres (hors mis purement la vidéo), tu devras sans doute interroger le system dans son entier, à des intervalles régulier, donc là le Timer deviendra une nécessité.

j'utilise parfois un timer pour lire un port com quand au contraire le périphérique "crache" des données à une cadence 'infernale'.

aaah :-). Effectivement, c'est simple mais je n'y pensais pas.

Dans mon cas, je n'ai à recevoir d'informations de mes équipements que si je leur envoie des requêtes. Sauf à quelques exceptions près où je reçois aussi des événements (que je récupérerai via OnComm).

En ce qui concerne le test de la liaison (coupure du signal CTS ou au contraire, reprise du signal), j'utilise déjà l'événement OnComm en testant la valeur de MSComm.CommEvent = comEventBreak.


Dans mon cas, a priori du moins, je ne pense donc pas utiliser de Timer.
Merci pour vos explications .

Si d'autres connaisseurs en la matière ont d'autres remarques, conseils, précisions, n'hésitez pas ;-)

Bonne semaine.