Réemmeteur RS485 bidirectionnel

[thomasalbert1993]

si tu plais ^^
-----

[mat64]

pourquoi des inductances aux lignes RS485 ???

laisse tomber, j'avais mis ça pour la CEM, "au pif", mais comme on a jamais fais d'essais, je ne sais pas si ça a une quelconque utilité...

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)

chacun ses gouts mon code montre juste quelles lignes mettre à 1 ou 0 selon la configuration que l'on veut pour le bus.

pourquoi cette valeur de quartz ?? au pif ?

C'est la valeur qui me permet d'être au plus proche de 115200 bauds avec les diviseurs dont je dispose dans l'UART intégrée à mon micro.

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 ??

puisque l'assembleur du pic te semble compliqué (tu plaisantais la, non ?), je te fais la traduction en français
Les macros de pilotage des ports :

macro "setHard_Rx" : pilote le port 1 en réception avec copie sur le port2 les données reçues sur le 1
signal PORT1_REVERSE à 0
signal PORT2_DE à 1
signal PORT2_RE à 1

macro "setHard_Tx" : pilote le port 1 en émission (et port 2 inactif)
signal PORT1_REVERSE à 1
signal PORT2_DE à 0
signal PORT2_RE à 1

macro "setHard_Bridge" : pilote le port 1 en émission des data reçues sur le port2
signal PORT2_DE à 0
signal PORT2_RE à 0
signal PORT1_REVERSE à 1

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.

Justement non, pas dans le protocole que j'utilise. Dans mon système, un esclave à une certaine fenêtre de temps pour répondre, c'est le temps pendant lequel les autres retournent le bus.

D'ailleurs après réflexion, je te conseille de rester sur le répeteur cablé en hard de la note d'appli que je j'ai posté. c'est plus simple, t'es indépendant des protocoles, etc.

si tu plais ^^

pas le peine de faire des up tout le temps, je ne me connecte qu'en journée...

[invitef26bdcba]

Salut,

Tu dois définir chaque adresse avant de mettre tout le monde en réseau. Je vois pas comment faire autrement.

Ce n'est pas obligatoire, et je trouve cette solution contraignante quand on doit placer plusieurs carte identique sur le bus. Surtout sur des Bus différents dont on ne connaît pas les adresses utilisées par les cartes déjà présentes...

Le plus simple est d'ajouter les composants un à un sur le Bus avec une adresse de configuration identique pour tous les nouveaux composants du Bus lors de la programmation hardware.

Ensuite, une fois le composant connecté au Bus, il suffit d'une simple trame avec l'adresse de config pour donner une nouvelle adresse au composant, sans oublier une lecture des composants présent sur le bus afin de connaître les adresses utilisées.

je te conseille de rester sur le répeteur cablé en hard de la note d'appli que je j'ai posté. c'est plus simple, t'es indépendant des protocoles, etc.

Attention avec cette solution, car elle demande une modification du protocole afin de respecter le temps "mort" fixé de manière hardware et qui en plus est impossible à modifier sans jouer du fer à souder...

David.

[thomasalbert1993]

pas le peine de faire des up tout le temps, je ne me connecte qu'en journée...

oui désolé c'est un de mes défauts, je suis très impatient

sinon je pense que je vais conserver la méthode qui utilise le microcontroleur, vu que ça se gère en software, on veut changer le protocole au cas où on en ai besoin...

pour ce qui est du choix de l'adresse du module, j'ai encore le temps d'y voir, ça se gère en logiciel.

Pour ce qui est des CEM, j'en aurai besoin , il faudra que mon projet soit certifié CEM... mais ça j'ai le temps

enfin, pour l'assembleur, je ne plaisantais pas du tout, je trouve ça très compliqué !!! déjà les instructions je ne comprend pas comment elles sont faites.... Le c est bien plus simple à comprendre, et à "hiérarchiser" (pour que ce soit clair...), du moins c'est mon avis perso

[mat64]

...Le plus simple est d'ajouter les composants un à un sur le Bus avec une adresse de configuration identique pour tous les nouveaux composants du Bus lors de la programmation hardware...

oui, c'est une des solutions que je proposais dans le post #28. Toutes les solutions sont bonnes, il faut voir quelle est la meilleure pour le projet en question.

sinon je pense que je vais conserver la méthode qui utilise le microcontroleur, vu que ça se gère en software, on veut changer le protocole au cas où on en ai besoin...

Alors je te donne quelques détails supplémentaires sur ce que j'ai réalisé. Mais je maintiens que c'est une mauvaise idée, si je devais refaire le produit aujourd'hui je ne ferais pas comme ça.

Il y a donc deux ports, ce qui permet de s'affranchir (en tout cas de réduire) des contraintes de topologie du RS485. Grâce à ces 2 ports, on peut faire des dérivations à chaque nœud (ce qui est en théorie interdit en RS485), et on dispose aussi d'un répéteur à chaque nœud qui permet de repartir pour 1 km de câble.

Seulement attention, les nœuds doivent être un minimum intelligent ; quand un trame arrive sur le port 1, elle est transmise sur le port 2, et le nœud doit se retourner (recopier le message retour du port 2 vers le port 1) mais seulement si le destinataire du message se trouve en aval de ce nœud. Car si 2 nœuds de la même branche se retournent en même temps il y a conflit : chacun essaye d'imposer son message sur la branche.

Cela implique que les nœuds doivent mémoriser une liste des adresses des noeuds situés en aval. Et pour constituer cette liste, il te faut une "phase d'apprentissage", pendant laquelle le bus est scruté branche par branche récursivement. Quand le maitre a scruté une branche il envoie un message au noeud qui est en tête de cette branche pour ajouter les adresses à sa liste.
Bref, une petite usine à gaz (mais faisable).

Pour ce qui est des CEM, j'en aurai besoin , il faudra que mon projet soit certifié CEM... mais ça j'ai le temps

En plus des classiques capas, selfs, plans de masse, etc... tu peux utiliser des transceiver "low slew rate". Leurs temps de montée est limité pour "arroser" un peu moins (valable si on a pas besoin d'un grand débit, à 115200 bauds c'est bon).

[invitef26bdcba]

Seulement attention, les nœuds doivent être un minimum intelligent ; quand un trame arrive sur le port 1, elle est transmise sur le port 2, et le nœud doit se retourner (recopier le message retour du port 2 vers le port 1) mais seulement si le destinataire du message se trouve en aval de ce nœud. Car si 2 nœuds de la même branche se retournent en même temps il y a conflit : chacun essaye d'imposer son message sur la branche.

Cela implique que les nœuds doivent mémoriser une liste des adresses des noeuds situés en aval. Et pour constituer cette liste, il te faut une "phase d'apprentissage", pendant laquelle le bus est scruté branche par branche récursivement. Quand le maitre a scruté une branche il envoie un message au noeud qui est en tête de cette branche pour ajouter les adresses à sa liste.

Salut,

Ta description n'est pas juste...

Il n'est pas nécessaire de mémoriser les adresses du second noeud, car même si le répéteur se retourne et que l'adresse concernée est sur le premier noeud, il n'y aura pas de collision entre les deux noeuds vu que sur le second noeud il n'y aura pas de trafic...

Par contre, en multi-maître ce que tu dis est juste vu que deux composants pourraient émettre au même moment, mais là, c'est à nouveau une simple modification du soft qui doit prendre en compte le temps maximum d'une trame plus le retard dû à la longueur du BUS et du fait, ne concerne pas le répéteur.

Pour moi, la meilleur solution est celle d'un petit composant programmable, car on n'est plus dépendant de composant externe figeant définitivement la vitesse du Bus...

David.

[mat64]

Ta description n'est pas juste...

si si, je t'assure...

Il n'est pas nécessaire de mémoriser les adresses du second noeud, car même si le répéteur se retourne et que l'adresse concernée est sur le premier noeud, il n'y aura pas de collision entre les deux noeuds vu que sur le second noeud il n'y aura pas de trafic...

je comprends pas ce que ça veut dire, mais je t'ai mis un dessin pour être sur qu'on parle de la même chose. Dans l'exemple de mon dessin, quand le nœud à l'adresse 160 répond, il ne faut pas que @12 se retourne lui aussi, sinon @12 et @60 essayent d'émettre sur le même fil (celui qui va sur le port 2 de @51).

... c'est à nouveau une simple modification du soft qui doit prendre en compte le temps maximum d'une trame plus le retard dû à la longueur du BUS et du fait, ne concerne pas le répéteur.

Pour moi, la meilleur solution est celle d'un petit composant programmable, car on n'est plus dépendant de composant externe figeant définitivement la vitesse du Bus...

il y a quand même pas mal de cas ou changer un protocole (ou la vitesse bus...) est tout aussi emm.... en soft qu'en hard. D'accord au labo, tant qu'on a pas fini le développement, c'est agréable d'avoir juste un soft à mettre à jour. Mais une fois qu'on est chez le client, et qu'il y a 50 modules disséminés dans l'usine...

[invitef26bdcba]

Ton dessin est en attente de valid mais :

Si dans ton cas précis, tu as une collision sur le bus dû au répéteur, c'est qu'il est très mal conçu...

Un répéteur, c'est un répéteur:
Il n'a pas besoin d'interpréter les trames, il se contente 'simplement' de transmettre les trames entre noeud.
Partant de là, il est impossible d'avoir une collision entre noeud dû au répéteur même si la trame est destinée au même noeud.

Dit autrement, quand le maître envoie une trame sur le noeud1 à destination d'un composant du noeud1, le répéteur ne fait que transmettre la trame sur le noeud2 et, il se retourne pour écouter le noeud2.
Ensuite, le composant du noeud1 répond au maître présent sur le noeud1, MAIS c'est transparent pour le répéteur vu qu'il n'écoute plus le noeud1.

Au final, pas de trame en réception sur le noeud2 et donc collision impossible entre le répéteur et le composant répondant au maître.

P.S. par noeud, j'entends bus réseau séparé par un répéteur et non la connexion d'un composant sur le bus.

il y a quand même pas mal de cas ou changer un protocole (ou la vitesse bus...) est tout aussi emm.... en soft qu'en hard.

Oui, seulement la grande différence est qu'avec la méthode soft, on ne bloque la production que quelques minutes(pour reprendre l'exemple de l'industrie), alors qu'en hard il faudra une personne compétente pour modifier les répéteurs et le temps d'arrêt est tout autre...

David.

[mat64]

on est bien d'accords dans le cas d'un simple répéteur. Le circuit que je décris consiste non seulement en un répéteur, mais aussi en un "dérivateur" (je ne sais pas si il y a un terme approprié), qui permet de dédoubler les branches du bus, ce qui est une topologie en principe proscrite en RS485.

En résumé tu as raison : si on se contente de ce répéteur, la solution soft est souple et pas trop compliquée à mettre en place. Mais attention : pas de blague... le bus arrive sur un port et stop, on ne repart pas vers un autre nœud autrement que via le second port.

[mat64]

autre avantage : comme on a que des liaisons point à point entre 2 transceiver RS485, on peut mettre les résistances d'adaptation directement sur les cartes.

[invitef26bdcba]

Ton image est disponible...

l ne faut pas que @12 se retourne lui aussi, sinon @12 et @60 essayent d'émettre sur le même fil (celui qui va sur le port 2 de @51).

En principe, 12(qu'il soit répéteur ou composant) ne peut pas émettre sur le bus, car la trame ne le concerne pas (ou ne concernait pas un de ces composants).
Donc il est obligé de rester muet le temps de la réponse (ou le temps du retournement)

Sinon, je ne comprends pas ce que tu veux dire par dérivateur/répéteur car ton schéma donne l'exemple de plusieurs répéteurs.

David.

[thomasalbert1993]

ton schéma de répéteur hard, pourrait - on l'adapter pour qu'il y aie une entrée et 4 sorties par exemple (toujours bidirectionnel, mais 1 est maître et les 4 autres sont escalves) ?

Merci

[mat64]

DavidDB : je crois que tu as raison, je me suis fourvoyé dans mon usine à gaz. Avec les deux ports en écoute tout le temps, et qui passent en émission pour refléter un message arrivant sur l'autre, ça marche.

[mat64]

ton schéma de répéteur hard, pourrait - on l'adapter pour qu'il y aie une entrée et 4 sorties par exemple (toujours bidirectionnel, mais 1 est maître et les 4 autres sont escalves) ?

je ne sais pas, sans doute... mais je ne vois pas l'intérêt ? en combinant des répéteurs à deux ports tu peux tout faire.

[thomasalbert1993]

?? comment ça ??

si je souhaite qu'une ligne parte à gache par exemple, et qu'une autre à droite je met un répéteur au croisement en Y à deux sorties, une entrée, cette dernière tant reliée au maitre...

[mat64]

dans ce cas (Y) tu mets deux répéteurs simples. Dis donc, c'est quoi cette lubie des répéteurs ? tu veux faire des réseaux sur plusieurs kilomètres ?

[thomasalbert1993]

non je veux être très securitaire et je peux avoir jusqua 255 esclaves répartis sur 500 -1000m

Voulu voilà

De plus, ne pas utiliser des répéteurs oblige a utiliser des raccorda xlr avec la résistance de fin de 120ohms alors qu'elles sont intégrés dans les modules quand on utilise les repeteeurs

[invitef26bdcba]

non je veux être très securitaire et je peux avoir jusqua 255 esclaves répartis sur 500 -1000m

Salut,

Dans ce cas, nul besoin d'un répéteur!

Utilise simplement une driver de ligne qui accepte ces 256 composants, Maxim (comme d'autres) font ce genre de driver.

David.

[thomasalbert1993]

et là tu es sur qu'il n'y aurait pas de problème de parasitage ?

un probleme aussi est qu'il faille mettre une resistance de fin de ligne dans un connecteur XLR à brancher sur le dernier (?) esclave.

Mais si j pars en Y ? je dois mettre une résistance à chaque branche du Y ??

[mat64]

Mon expérience perso : sur 500-1000 m sans répéteur, à 115200 bauds, sans respecter les préconisations RS485 (pas de résistance de terminaison, topologie "rock n' roll" avec des étoiles partout....et pourtant j'en ai mis des mises en garde dans la doc !), ça marche. Si tu veux être "très sécuritaire", mets un protocole avec CRC et retransmission en cas d'erreur. Et tu conçois un petit répéteur simple, que tu utilisera seulement quand c'est nécessaire (dans les cas ou tu as vraiment de la distance).
Mais ne lésine pas sur la qualité des transceiver (il y en a de très robustes maintenant...).

[thomasalbert1993]

ah bon ?? sans résistances de 120Ohms ça marchait ? tu n'étais pas perturbé ?

bon bien si tu le dis, c'est vrai que c'est beaucoup plus simple de ne pas utiliser de répeteurs !

pourrais-tu me conseiller sur un driver RS485 pouvant aller jusqu'à 256 esclaves ? le MAX485 ? SN75176 ?

[mat64]

ah bon ?? sans résistances de 120Ohms ça marchait ? tu n'étais pas perturbé ?

Attention, je dis pas qu'il faut se mettre à câbler n'importe comment. Ce que je dis c'est que lorsque je vais voir mes installations sur le terrain, les électriciens qui pourtant ont eu ma doc ont cablé n'importe comment 9 fois sur 10, et que c'est pas les sites aux câblages les plus loufoques ou j'ai les plus gros taux d'erreurs. Conclusion : à cette vitesse (115200 bds), on doit pas trop être dérangé par les réflexions et tout ce genre de choses....
Quand aux résistances 120 ohms, en général, quand j'en mets, c'est pire. (au passage, si quelqu'un a une explication...)
Attention : des erreurs, il y en a toujours, donc CRC + retransmissions.
Pour te donner une idée, avec grosso modo 10 trames échangées par seconde, j'ai environ de 1 erreur par mois à 10 erreurs par jour (encore une fois, sans rapport avec l'orthodoxie du câblage).

bon bien si tu le dis, c'est vrai que c'est beaucoup plus simple de ne pas utiliser de répeteurs !

Contentes-toi d'en utiliser quand ils sont nécessaires ! Après tout moins y'a de composants, moins y'a de probabilité de panne....

pourrais-tu me conseiller sur un driver RS485 pouvant aller jusqu'à 256 esclaves ? le MAX485 ? SN75176 ?

MAX458 pas bon pour le nombre d'esclaves que tu veux. Il faut voir ce que te proposent tes fournisseurs, en tout cas je prendrais une puce récente : elles sont maintenant plus résistantes aux ESD, et certaines sont même tolérantes aux surtensions accidentelles jusqu'à 80 V.

[invitef26bdcba]

Mais si j pars en Y ? je dois mettre une résistance à chaque branche du Y ??

Salut,

Bonjour l'écho sur le Bus si tu câbles en Y...

Il faut un minimum respecter la norme, car câblage en étoile, pas de résistances sur le bus,... ; c'est le cocktail détonant menant à un système totalement instable.

un probleme aussi est qu'il faille mettre une resistance de fin de ligne dans un connecteur XLR à brancher sur le dernier (?) esclave.

Non, pas sur l'esclave, mais bien sur le câble du Bus, comme cela plus de problème de gestion des deux résistances de terminaison.

David.

[thomasalbert1993]

quel echo ???

c'est donc mission impossible ce que je souhaite faire ?

[mat64]

Mais non, c'est pas mission impossible.

l'echo c'est la réflexion des ondes électriques lorsqu'elles rencontrent un changement d'impédance (même phénomène avec les ondes acoustiques ou autre). C'est pour supprimer cet écho que l'on place des résistances de terminaison de 120 ohms aux extrémités du bus. Le risque avec l'echo c'est qu'une portion du signal soit réfléchi à l'extrémité du câble, et vienne se mélanger au signal en cours d'émission sur le bus.

Soyons clairs : si tu veux être réglo (respect des normes), en RS485, IL FAUT une résistance de terminaison à chaque extrémité du bus, IL EST INTERDIT de dédoubler le bus (pas de Y, encore moins d'étoiles). Ce qui signifie que si tu dois faire un Y, tu dois créer un second bus. (voir schéma joint)

Mon expérience personnelle, c'est que jusqu'à 115200 bds, je n'ai trouvé aucune corrélation entre le taux d'erreur, et l'orthodoxie du câblage. Si tu veux être irréprochable, contentes - toi de respecter la norme. Mais n'en fait pas plus : mettre un répéteur à chaque nœud comme tu voulais le faire au début c'est complètement inutile.

[invitef26bdcba]

Salut,

J'ajoute en complément de Mat :
Sans résistance de terminaison, la 'raideur' des signaux sera moins bonne et donc on réduit la vitesse maximum autorisée sur le bus.
Ces résistances servent aussi à respecter la symétrie entre les lignes A et B.

David.

[thomasalbert1993]

et bien avec mes répéteurs a chaque nozus je peux faire exactement ce que je souhaite faire ! J'ai le schéma en tête , et merci encore de m'avoir aide !

++ thomas

[mat64]

Un petit complément à mes propos qui prétendaient que je n'avais jamais rencontré de cas ou les résistances d'adaptations étaient nécessaires. Et ben ça y est, j'en ais rencontré un hier ! Je pense que la longueur de câblage doit être sensiblement plus importante que dans les installations que nous avons faites jusqu'à présent.

Donc à l'oscillo, les réflexions se sont matérialisées par une lente redescente du signal à la fin des trames. Ce qui rajoutait des bits erronés en queue de trame. Avec les résistances d'adaptation, nickel, taux d'erreur 0%.