Réemmeteur RS485 bidirectionnel

[thomasalbert1993]

Bonjour

Est-il possible de faire un réemetteur RS485 bidirectionnel "automatique" ?

on a par exemple :

[A]---------{REEMETEUR}----------[B]

[B] est en mode récepteur par défaut...
[A] (mode émetteur par défaut) envoie une commande à [B], puis passe en mode récepteur pour recevoir la réponse de [B].
A la fin de la réponse, [B] envoie le caractère de fin (# par exemple, ou retour chariot), et les modules reviennet dans leur mode par défaut...

Ainsi le rémetteur doit être bidirectionnel... Est-ce faisable ??

merci

Thomas
-----

[cherwam07]

Oui bien sur, tout est possible. Le RS-845 est bidirectionnel (comme beaucoup de bus d'ailleur heureusement)

Mais quelle est l'utilité de ce repeteur ? Ton bus est-il très long ?

[thomasalbert1993]

non mais ça me garantie une meilleure "sécurité face aux parasites et tout ...

en fait chaque module chope le signal RS4_5, et le réemmet en même temps pour les autres (principe du DMX, sauf que je ne sais pas s'il est réemis)

[DavidDB]

Salut,

Est-il possible de faire un réemetteur RS485 bidirectionnel "automatique" ?

Oui, c'est possible, mais ce n'est pas aussi simple...

Il faut pouvoir gérer les communications sur les différents Bus, et donc deux simples drivers tête-bêche ne suffissent pas.
Rien que le problème de deux trames émissent en même temps sur chaque tronçon plante le Bus par une collision monumentale...

David.

[A voir en vidéo sur Futura]

[thomasalbert1993]

j'ai ma petite idée sur le sujet, mais il faudrait que je sache s'il est possible, et surtot comment, détecter la présence d'une donnée (1 ou 0) sur la ligne RS485 (en fait il faudrait plutot détecter si la ligne est à haute imédance (tous les modules sont en entrée))

merci

[DavidDB]

Salut,

Une petite explication du problème par Bigonoff :

Au niveau du répétiteur, celui-ci a ses lignes de buffer activées pour que le répétiteur écoute ce qui vient de A vers B (exemple).
A est en réception
B est en émission.

Si B émet un message vers A, la logique (simple logique câblée) voit le start-bit du premier octet arriver, et donc commute les buffers pour que B devienne émetteur et A récepteur.
Mais à un moment donné, il faut que A puisse répondre, et donc il faut revenir à la situation initiale.
Ceci implique que la logique soit capable de voir que le message de B est A est terminé, ce qui peut se voir si on n'a pas reçu un niveau "0" (équivalant au start-bit) depuis un temps suffisant, au moins égal à la longueur d'un octet (qui peut avoir tous ses bits à 1).

Donc, la logique "retourne" la ligne SI durant un temps supérieur au temps mis par un octet pour être émis on n'a pas reçu un seul "0" (plus un temps de sécurité en cas de "ratage" d'un bit).

Evidemment, si le dernier octet envoyé se terminait par "0", alors on ne commence à compter le temps qu'à partir du dernier bit, et donc on "perd" un temps égal au minimum à la durée d'un octet, en plus du temps "de sécurité" s'assurant que plus aucun octet n'arrive.

Ce temps dépend évidemment aussi du débit de la liaison : plus c'est lent, plus il faut attendre longtemps avant d'être certain que plus aucun octet n'arrive.

Moralité, ça se passe comme suit :

- Au repos, A émetteur, B récepteur
- Un octet arrive de B -> le répétiteur s'inverse -> A récepteur, B émetteur
- Tant qu'on reçoit des niveaux "0" de B, on resette un monostable, la situation reste identique
- Si plus de niveau "0" reçu durant un temps suffisant, le monostable fini de compter et remet le répétiteur dans son état d'origine (retournement de la ligne)

Le temps durant lequel on attend avant de retourner la ligne, c'est le temps de retournement.

Si, évidemment, A tente de répondre à B AVANT que la ligne ne soit retournée, alors il y a collision et l'info n'arrive jamais.
Du coup, il faut tenir compte du temps de retournement du répétiteur dans le soft des périphériques RS485 sur la ligne.

Une parade est d'utiliser 2 lignes RS485, une pour l'émission et une pour la réception. Dans ce cas, plus besoin de logique de retournement, le répétiteur se résume à chaîner des drivers RS485. MAIS le revers de la médaille est qu'alors on a un maître et des esclaves, mais que le câblage ne permet plus à deux esclaves de dialoguer (on se retrouve dans la logique du RS232).

En CAN, c'est un peu la même chose (retournement obligatoire), MAIS en bien pire, car la ligne ne doit pas être retournée après l'émission complète d'un octet, mais bel et bien durant l'émission d'un même octet (dialogue dans les deux sens pour l'émission d'un même octet). Bref, c'est beaucoup plus compliqué de faire un répétiteur CAN qu'un répétiteur RS485.
Sans compter que la "réponse" doit intervenir dans des délais prévus par la norme (contrairement au RS485) et que donc plus on "perd" de temps pour retourner le répétiteur, moins on dispose de temps pour que le bit soit véhiculé sur la ligne. Moralité, un répétiteur "consomme" une longueur de ligne virtuelle, son temps de retournement est à déduire du temps disponible pour le transport du bit, qui est lui-même tributaire de la longueur physique du fil.


David.

[thomasalbert1993]

Imaginons [A] le module maître et [b], [c]... [n] des esclaves.


[A] demande une information à [c] (il envoie une trame série contenant le n° de l'esclave dont il souhaite une réponse, puis termine sa chaine par un caractère #). TOUS les escalves reçoivent dont cette chaine de caractères, mais seul [c] la traite, puisqu'il s'agit de lui.
Mais, tous les esclaves vont de toute manière recevoir le caractère de fin de chaine, ici #. suite à la réception de ce caractère, ils "commutent" tous leurs entrée et sortie RS485 afin que celles ci s'inverse. [c] va donc envoyer sa réponse en passant par [B] (qui ne fera que réemettre le signal pour aller vers [A])(j'ai oublié de préciser que [A] est en mode récepteur). Il termine sa réponse avec #, ce qui implique tous les modules entre [A] et [c] à revenir dans leur position initiale. Mais comment dire à [d]...[n] de revenir en position normale puisqu'ils ne recoivent pas le signal (en effet, les entrées et sorties étant inversées, [e] sera "entendu" par [d],[c],[b]... et non pas par [f]...[i]... (ce qui est le cas en position normale, où [A] communqiue avec tout le monde)

comment résoudre ce probleme ??

merci

[DavidDB]

'Simplement' en comptant le temps maximum d'une trame avec un temps de sécurité avant de remettre les drivers dans l'état initial.

David.

[mat64]

Cette note d'app de chez linear est très bien.

[thomasalbert1993]

merci c'est EXACTEMENT ce que je cherchais

Mais en ayant regardé la datasheet du 74HC123, je ne comprend pas son fonctionnement, et la différence entre Trt et Tw...

Voila si quelqu'un peut m'expliquer comment il fonctionne, et m'aider à calculer les valeurs pour 119 200bauds et 57 600bauds, 8 bits de donné, 1 bit start & de stop, pas de parité

merci

[thomasalbert1993]

les résistances de pull up et pull down de 750Ohms sont elles indispensables ?

[thomasalbert1993]

If you please ^^ !!

au fait : ce montage est -il utilisable en tant que tel ?

[DavidDB]

merci c'est EXACTEMENT ce que je cherchais

Salut,

Bien oui...

C'est exactement ce qui est décrit dans le post#6 , à la différence près d'une détection hard de la transition de ligne.
Il faut évidement aussi modifier le soft pour connaître le temps d'une trame afin d'agir en conséquence...

David.

[thomasalbert1993]

pour le "soft" ce n'est pas un soucis, les signaux se font rares...

Mais comment calculer la résistance et le condensateur ?

Dans la doc que tu m'as passé, ces valeurs conviennent pour du 100kbauds.
R = 10kR et C = 10nF

D'après la formule donnée dans la datasheet du 74HC123, Tw = 0,55 (pour 5.0V) * R * C = 0,55 * 10 000 * 0,000 000 010 = 55µs

1 trame 8 bits + 2 bits (stop et start) dure donc 10/100 000 = 100µs

Je ne comprend donc pas pourquoi Tw = 55µs et non pas 100µs (il faudrait d'ailleurs je pense une petite marge de disons 10µs (durée d'un bit) à cuase de la tolérance de la résistance et du condensateur, non ?)

De +, dans la datasheret du monostalb,e ils donnenyt un Trt, dont je ne vois pas à quoi il sert...

MErci de m'éclairer et de m'aider à calculer les valeurs pour 119 200bauds, et pour 57 600bauds

merci beaucoup

ThomasA.

[thomasalbert1993]

autre question : je peux brancher directement mon RXD et TXD du microcontroleur au DataOUT et DataIN du SN75176 (c'est moinscher que les LTC et MAX 485) ? ou alors faut il inverser les données (comme pour le RS232, mais en -12/12V) ?

merci

[thomasalbert1993]

d'après ce que je comprend ce montage se comporte un peu comme une bascule : si une donnée se présente sur l'un des "côtés" , alors le répéteur se met dans le bon sens, de sorte à transmettre ce signal de l'autre côté, et reste dans ce sens jusqu'à réception d'un nouveau signal.

Soit A le côté gauche et B le côté droit
Est-il possible de le configurer pour que par défaut le répéteur se trouve en position : A[réception] et B[retransmission] ?

si A ne recoit rien et B non plus, il est donc dans cette position. Si A reçoit, il e change toujours pas , il transmet à B le signal de A. Si B recoit un signal, il change de sens pour que B soit récepteur et A reemeteur. Il transmet à A les données reçues en B. Tant qu'il y a des données (donc tant qu'il ya des bits de start), rester en position. Revenir en position par défaut lorsque plus de start bit se présent en B durant x µs (ou ms j'en sais rien ^^)

[DavidDB]

pour le "soft" ce n'est pas un soucis, les signaux se font rares...

Si le soft n'est pas un problème, alors gère le répéteur intégralement par soft, ce sera plus simple et surtout pourra s'adapter à tous les cas de figure...

David.

[mat64]

les résistances de pull up et pull down de 750Ohms sont elles indispensables ?

ça dépends de quel transceiver RS485 tu utilises. Avec un transceiver "fail-safe" il ne doit pas y en avoir besoin. C'est une question de mise en oeuvre du RS485, pas du répéteur en lui-même.

If you please ^^ !!

au fait : ce montage est -il utilisable en tant que tel ?

ben il est pas le que pour faire joli....

pour le "soft" ce n'est pas un soucis, les signaux se font rares...

Mais comment calculer la résistance et le condensateur ?

Dans la doc que tu m'as passé, ces valeurs conviennent pour du 100kbauds.
R = 10kR et C = 10nF

D'après la formule donnée dans la datasheet du 74HC123, Tw = 0,55 (pour 5.0V) * R * C = 0,55 * 10 000 * 0,000 000 010 = 55µs

1 trame 8 bits + 2 bits (stop et start) dure donc 10/100 000 = 100µs

Je ne comprend donc pas pourquoi Tw = 55µs et non pas 100µs (il faudrait d'ailleurs je pense une petite marge de disons 10µs (durée d'un bit) à cuase de la tolérance de la résistance et du condensateur, non ?)

De +, dans la datasheret du monostalb,e ils donnenyt un Trt, dont je ne vois pas à quoi il sert...

MErci de m'éclairer et de m'aider à calculer les valeurs pour 119 200bauds, et pour 57 600bauds

merci beaucoup

ThomasA.

le soft si t'as un microcontrolleur dans ton montage, tu fais la détection d'activité et l'inversion de sens du bus par soft....
pour les 55us, je pense qu'ils considèrent que le monostable sera "re-triggué" par un bit à l'intérieur de l'octet. En effet c'est peut être un peu risqué.
pour le Trt, c'est un temps pour que le monostable soit à nouveau prêt. Pas d'inquiétude il est très court. Quand aux valeurs pour 119200 bauds (tu voulais dire 115200 je suppose) et 57600, tu as toutes les cartes en main pour les calculer...

autre question : je peux brancher directement mon RXD et TXD du microcontroleur au DataOUT et DataIN du SN75176 (c'est moinscher que les LTC et MAX 485) ? ou alors faut il inverser les données (comme pour le RS232, mais en -12/12V) ?

merci

j'ai regardé rapidement, ça à l'air de coller, mais t'es vraiment à quelques euros prêts sur ton projet ? je te conseillerais plutôt d'utiliser une puce récente, elles sont maintenant mieux protégées contres les surtensions et ESD, elles ont des récépteurs "fail-safe", etc.

d'après ce que je comprend ce montage se comporte un peu comme une bascule : si une donnée se présente sur l'un des "côtés" , alors le répéteur se met dans le bon sens, de sorte à transmettre ce signal de l'autre côté, et reste dans ce sens jusqu'à réception d'un nouveau signal.

Soit A le côté gauche et B le côté droit
Est-il possible de le configurer pour que par défaut le répéteur se trouve en position : A[réception] et B[retransmission] ?

si A ne recoit rien et B non plus, il est donc dans cette position. Si A reçoit, il e change toujours pas , il transmet à B le signal de A. Si B recoit un signal, il change de sens pour que B soit récepteur et A reemeteur. Il transmet à A les données reçues en B. Tant qu'il y a des données (donc tant qu'il ya des bits de start), rester en position. Revenir en position par défaut lorsque plus de start bit se présent en B durant x µs (ou ms j'en sais rien ^^)

Je vois pas bien comment faire ça simplement, mais bon, il y a peut être une astuce. De toute façon je vois pas l'intérêt ? La tout le monde est en récetion au repos, ça me parait plus sur.

[thomasalbert1993]

La tout le monde est en récetion au repos, ça me parait plus sur.

Oui effectivment c 'est mieux ^^

Mais comment y faire logicielement ??

[thomasalbert1993]

en fait comment déterminer si une donnée est présente sur la ligne ??

[thomasalbert1993]

si je comprend bien les deux résistances de 750Ohms sont là pour fixer un niveau sur la ligne quand tous les modules sont en mode réception ?

[mat64]

Oui effectivment c 'est mieux ^^

Mais comment y faire logicielement ??

en fait comment déterminer si une donnée est présente sur la ligne ??

c'est quoi ton micro ? envoie ton schéma. Et ton schéma est terminé ou peut encore être modifié ?

si je comprend bien les deux résistances de 750Ohms sont là pour fixer un niveau sur la ligne quand tous les modules sont en mode réception ?

oui

[thomasalbert1993]

En utilisant un microcontroleur, je peux faire un truc du genre :

[A] et [b] sont des entrées en mode interruption sur front montant

[A] est la sortie DO du SN75176 côté ligne A et [B] est la sortie DO du SN75176 côté ligne B.

[A] est aussi relié à DI du SN75176 de la ligne côté B, et IDEM pour [B], qui est aussi relié DI côté A.

un front montant de [A] ou [B] provoque une interruption différente selon que le signal soit sur [A] ou [B].

on dirige alors les drivers RS485 dans le bon sens, et on attend 90µs (pour 115 200 bauds, 10bits = 86,788µs)

bien ou pas ?

[mat64]

oui, ça me parait bien. Après faudrait en savoir plus sur ton projet : tu comptes utiliser un protocole ? C'est maitre-esclave je suppose, donc le premier message ne peut venir que d'un coté. Alors ce coté est en réception par défaut, et tu n'as besoin de détecter les data que de ce coté. Ensuite tu retournes le sens des drivers le temps de laisser passer la réponse de l'esclave. (c'est ce que j'ai fait sur un de mes produits)

[thomasalbert1993]

mon protocole est RS232 (en fait pas RS232 mais série sur un microcontroleur)...

oui il y a bien maître esclave, et effectivement c le maitre qui a la priorité, mais je ne sais pas encore, j'aurais peut etre besoin que mes escalves uisses communiquer entre eux, afin par exemple que deux escalves n'aient pas la meme adresse (dans mon projet, chaque ascalve a une adresse entre 0 et F)

[thomasalbert1993]

Est-ce que ce schéma conviendrait ???

[thomasalbert1993]

S. V. P. !!! +*+

[mat64]

mon protocole est RS232

Quand je demandais quel protocole, je voulais savoir au niveau soft. Pour moi RS232 n'est pas un protocole, c'est un support physique. Ce que je veux savoir c'est quelle est la procédure prévue pour une communication : qui prends l'initiative des comm, est ce qu'il y a un acquittement, un contrôle d'erreur...
Un exemple de protocole c'est modbus.

oui il y a bien maître esclave, et effectivement c le maitre qui a la priorité, mais je ne sais pas encore, j'aurais peut etre besoin que mes escalves uisses communiquer entre eux,...

OULA... Si les esclaves communiquent entre eux, c'est plus des esclaves ! Maître / esclave = UN seul (le maitre) est à l'initiative des comm. Les esclaves répondent qui si on leur demande quelque chose. Si tu ne veux pas de ça, c'est détection de collision, ou partage temporel, bref un truc pas trivial ou bien pénalisant. Je te conseille de rester sur du maitre/esclave.

...afin par exemple que deux escalves n'aient pas la meme adresse (dans mon projet, chaque ascalve a une adresse entre 0 et F)

eux... alors la non. Tu dois définir chaque adresse avant de mettre tout le monde en réseau. Je vois pas comment faire autrement.
donc soit :
- dipswitchs
- adresse "en dur" dans le prog ou la flash de ton micro
- un protocole pour fixer l'adresse par le RS485, mais avec seulement cet esclave connecté au maitre, qui lui envoie le message spécial pour fixer l'adresse. après on peut mettre tout le monde en réseau.

Quand à ton schéma, je le trouve bien compliqué... pour faire ce que tu veux, il me semble que ça ça suffit : (c'est ce que j'ai mis dans un de mes produits, ça fonctionne )

[thomasalbert1993]

ok

pour ce qui est de mon schéma, j'ai mis un ATmega32 parce que j'utilise les autres sorties pour d'autres utilisations (afficheurs, boutons...)

pourquoi des inductances aux lignes RS485 ???

sinon je ne comprend pas ton code car je ne connais pas du tout l'assembleur (et je ne veux pas le connaitre, ça a l'air beaucoup trop compliqué, je préfère très largement le c)

pourquoi cette valeur de quartz ?? au pif ?

pourquoi l'un des deux MAS485 a un signal pour RE et un pour DE ??? jamais il ne sera la fois en émission et en réception, si ??



Pour ce qui concerne l'adresse, je viens de trouver une idée qui permet de régler l'adresse via le maître, les escalves étant déja reliés (cela permet d'en rajouter faiclement et rapidement) :

l'émetteur envoie une trame qui contient l'adresse à régler. Sur chaque escalve, on a un bouton poussoir. Le maitre envoie donc en boucle la trame tant qu'il ne reçoit pas de réponse. Si on appuie sur le BP d'un escalve, ça lui attribue l'adresse, et il confirme en répondant à l'émetteur... Comme ça c'est simlple d'emploi, et deux escalves ne peuvent pas avoir la même adresse (ce qui était possible avec ta technique, de configurer un à un...)

[thomasalbert1993]

Bon pour ce qui est du copiage des données 1 vers 2, ok , pour ce qui est de Tx sur 1, ok , mais pour ce qui est du copiage des données 2 vers 1, je ne comprend pas comment se fait la détection s'un signal sur 2. En effet, ce signal peut intervenir à n'importe quel moment, après une demande du maître.