Discussion :

[Simchofiten]

Bonjour,

Je bosse actuellement sur un projet qui demande d'interagir avec un device via une liaison RS232. Les trames à envoyer sont sur 32 bits , les réglages ( 4800 bds , 8 , N ) sont ok mais quelque soit le format de la trame que j'envoie vers mon device , elle me revient , que je respecte le format de la trame ou non. Je précise que la trame me revient instantanément et sans données supplémentaires . Autrement dit la réponse de mon device est à tous les coups de me renvoyer ma trame.
Je précise également que dans ce protocole , le renvoie de la trame ne correspond en aucun cas à une réponse "standard" voulue par le protocole.
J'ai déjà fait les tests sur mon port série PC , sur mon câble , tout est ok.

Si quelqu'un a une idée je suis preneur car cela fait plusieurs jours que je bloque.

merci d'avance

[Bktero]

Salut et bienvenu sur Developpez.com,

Il n'y a pas en soi de réponse à ta question. Si tu n'as pas rebouclé matériellement ta sortie sur ton entrée (mais comme tu travailles sur un PC avec un câble, cela semble peu probable ), alors il faut regarder du côté du matériel avec lequel ton PC communique pourquoi il renvoie ça. Tu n'indiques ni le device ni le protocole, on ne pourra rien dire de plus.

[Aquanum]

Pour moi le problème vient de l'ECHO qui est activé et qui devrait être désactivé. L'echo est le comportement par défaut si je ne m'abuse.

Sur quel système travailles-tu ?
Sous Linux et termios, tu dois désactiver les flags ECHO dans ta config.

Tu as des exemples ici.

[Bktero]

Salut Yoann ! Ca va ?

Tu veux dire par là que l'entrée est rebouclée sur la sortie de manière logicielle ? Ce n'est pas juste un echo dans le terminal, mais bien un echo qui est mis sur l'entrée du port série ?

[Simchofiten]

Merci beaucoup pour vos réponses

Concernant le protocole c'est un protocole propriétaire donc par évident de trouver des infos. Concernant le device il s'agit d'une installation composée de ballastes et d'un boitier "interface" permettant la transition entre le RS232 en entrée et une sortie sur deux fils reliés à chaque ballaste.

Que je branche une ballaste ou que je ne communique qu'avec l'interface seule , la réponse est la même, à savoir le retour de ma trame. Alors que l'interface ne réalise aucun traitement à part cette transition série vers ballastes.

Concernant l'écho local, j'utilise le terminal GTKterm pour mes tests et il y a une option pour désactiver l'écho local mais est ce qu'il s'agit bien de celui dont tu parles ? ou est-ce un autre echo au niveau du terminal lui même ?

Pour l'instant j'essaie de transmettre mes trames via un terminal avant de réaliser une appli JAVA avec RXTX et javaComm donc pas de termios

Et je précise que je travaille sous linux.

[Simchofiten]

Je complète ma réponse précédente.

Si avec mon terminal je transmet en 4800 bds ( norme de mon systeme ) ma trame me revient l'identique. Par contre si je met une vitesse supérieur le retour est 0.

Je pense donc que cela ne vient pas d'un éventuel l'écho local sinon quelques soient les paramètres choisis j'aurais un echo, non ?

Je pense donc que c'est bien mon device qui me retourne cette trame. Je suis débutant avec ce type de protocole mais étant donné que le retour de trame à l'identique ne figure nul part dans le protocole est ce qu'il pourrait s'agit d'un problème matériel type court circuit ou bien est ce qu'un mauvais format de trame (checksum, etc.) pourrait provoquer ce type de retour ?

[Aquanum]

Salut Yoann ! Ca va ?

Salut !

Tu veux dire par là que l'entrée est rebouclée sur la sortie de manière logicielle ? Ce n'est pas juste un echo dans le terminal, mais bien un echo qui est mis sur l'entrée du port série ?

Oui tout à fait. Et tu désactives ça sous Linux de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// No line processing:
// echo off, echo newline off, canonical mode off, 
// extended input processing off, signal chars off
//
config.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);

Concernant l'écho local, j'utilise le terminal GTKterm pour mes tests et il y a une option pour désactiver l'écho local mais est ce qu'il s'agit bien de celui dont tu parles ? ou est-ce un autre echo au niveau du terminal lui même ?

Part défaut, il me semble que les ports série se comportent comme des terminaux. Donc avec un echo de la commande frappée (sauf pour la rentrée d'un mot de passe il me semble). Donc si tu veux discuter avec un port série, et que tu n'es pas un humain, tu dois désactiver cet echo.

Je ne connais pas GTKterm, mais comment envoies-tu ces trames ? En ligne de commande ? Ou bien via un programme en C par exemple ?

Si c'est en ligne de commande, tu dois utiliser stty pour configurer ton port série avant de l'utiliser. Tu as des infos ici par exemple.

[Aquanum]

Je pense donc que c'est bien mon device qui me retourne cette trame. Je suis débutant avec ce type de protocole mais étant donné que le retour de trame à l'identique ne figure nul part dans le protocole est ce qu'il pourrait s'agit d'un problème matériel type court circuit ou bien est ce qu'un mauvais format de trame (checksum, etc.) pourrait provoquer ce type de retour ?

Ah je n'avais pas vu ton second message. As-tu les specs de ce protocole proprio ?
Parce qu'il se peut que ça soit normal de renvoyer la commande reçue. Considéré comme une sorte d'acknowledge.

[Simchofiten]

Alors la doc du protocole est pour le moins sommaire... comme dit précédemment ma config terminale c'est ( 4800 bds , 8bits/paquet , et parité None ).

le format des trames master est le suivante :
- 5 bits pour la commande
- 1 bit de group
- 10 bits d'adresse
- 8 bits de data pour la fct commande
- 0+7 bits de checksum

trames slaves :
- 8 bits de state
- 16 bits de data
- 1+7bits de checksum

Ce qui me dérange le plus concerne le premier bit des bits de checksum qui, comme définit dans le format de la trame, vaut 1 lorsque le master envoi un paquet et qui vaut 0 lorsque le slave répond.

Or moi la trame que je reçoit est exactement la même que celle envoyée , ce bit est donc toujours à 0.
Si le paquet provenait d'un de mes slaves, même si la trame est mal construite, je pense que je devrais au moins avoir ce bit à 1 dans la trame de réponse.

[sevyc64]

concernant le retour de la trame, tu peux faire un test simple, débranche le cable RS232 coté périphérique.
Si tu as toujours le retour, c'est que tu as, soit un problème de court-circuit dans ton câble ou tes prises, soit un problème de configuration de ton PC ou logiciel.

Si tu n'as plus de retour, ça signifie que le retour se fait par la carte, donc soit un problème de court-circuit, soit c'est prévu dans le protocole.

Comme dirait un certain ... "It's not a bug, it's a feature"

[Simchofiten]

En inspectant le device à l'oscilo il semblerait qu'il y ait un premier défaut d'alimentation et un autre au niveau de transceiver RS232...
J'attends donc un nouveau device la semaine prochaine

Je vous remercie tous pour votre aide.

a+