Problème RS485

[invite577b6a5c]

Bonjour à tous

Je souhaite concevoir un système utilisant le bus RS485. J'ai à peu près pigé les différentes contraintes liées à ce bus, mais j'ai deux petits soucis auxquels je ne trouve pas de réponse.

primo : j'ai lu quelque part, je n'arrive plus à retrouver où, qu'il pouvait y avoir des contraintes quant aux connecteurs utilisés. Pouvez vous confirmer, si oui, avez vous de la doc à ce sujet ?

secundo : il semble qu'il soit nécessaire d'avoir à chaque bout de la ligne une résistance de terminaison de 120 ohms. Or le problème est qu'il s'agit non pas d'un système mais de deux sous-ensembles qui ne sont pas reliés en permanence. Or je voudrais que ces deux sous ensembles puissent fonctionner indépendamment l'un de l'autre, y compris lorsqu'ils sont déconnectés. J'avais envisagé deux répéteurs entre la séparation mais ce topic me dit que c'est pas forcément une super idée.
Il s'agira d'une seule paire half-duplex bidirectionnelle.

Qu'en pensez vous ?

Merci d'avance
-----

[invite36436748]

Pour le peu que je connais sur le RS-485 et que je l'utilise (DMX 512) c'est du cable 120 ohm avec des connecteurs XLR 3 broches (en général, il existe du 5 broches mais surement pas utile dans ton cas) mais dans les systèmes industriels c'est peut être différent (DB-9 ?).
Effectivement pour l'adaptation d'impédance il faut des résistances 120 ohm en début et fin de ligne.

Pour les sous ensembles je ne comprends pas trop, mais si c'est ce que je pense c'est exactement ce que fait le DMX, c'est a dire que la console de pilotage peut envoyer ses trames à tous les jeux de lumière qui y sont reliés, mais si il y a des jeux de lumière configurés en "mode auto" (pilotage par le rythme de la musique par exemple) ceux-ci ne seront pas affectés par la console même si elle envoie des données à leur adresse

[invite577b6a5c]

Merci de ta réponse.

Pour ce qui est des sous-ensembles en fait c'est pas très compliqué : j'ai un fourgon et une caravane.
J'ai deux jeux de batteries, du gros dans le fourgon, et des plus petites dans la caravane. Je pompe sur les batteries du fourgon quand c'est branché, et je recharge celles de la caravane au passage. Dans le cas contraire ça tire sur celles de la caravane.
De même pour les réserves d'eaux propres et d'eaux usées, je transvase.
L'objectif est de pouvoir surveiller depuis un tableau de contrôle dans la caravane l'état des batteries et des réservoirs, aussi bien de la carlo que du fourgon, et aussi de pouvoir commander les pompes pour le transvasement (exemple : couper la pompe pour transvaser les eaux usées de la carlo si le réservoir du fourgon est plein).

Comme vous l'avez compris, je veux que l'ensemble puisse continuer à fonctionner même lorsque le connecteur est débranché, puisque pour simplifier je pense plutôt utiliser une carte pour l'afficheur, une carte pour les niveaux d'eaux, une carte pour l'état des batteries, etc etc. ça me simplifie pas mal la conception de chacune des cartes, et ça me permet d'y rajouter aisément des fonctionnalités pas prévues au départ. et de m'emmerder à prévoir des trucs qui risquent de ne pas me servir à grand chose.

Donc ça me répond déjà à la première de mes questions. Si tu y parviens avec ton XLR, mon SBX 350 avec deux contacts auxiliaires devraient pouvoir faire l'affaire.

Reste à résoudre le problème d'adaptation d'impédance lorsque l'ensemble est déconnecté.

[invite36436748]

Après tout bien réfléchi il va te falloir deux lignes (peut être que les cables 5 connecteurs iront) car le DMX est half duplex (donc Data+, Data- et masse) alors qu'il te faut du full duplex (Data 1+, Data 1-, Data 2+, Data 2-, Masse). Après jusque là ça va, mais après en ce qui concerne le dialogue propre à ton système ça sort un peu de mes compétences
J'espère que j'aurai pu éclaircir au moins un petit point sur ton problème, désolé de ne pouvoir en faire plus...

[A voir en vidéo sur Futura]

[invite577b6a5c]

je ne pense pas que deux paires soient nécessaires. au contraire c'est même contre-productif. Le half-duplex n’empêche pas la communication dans les deux sens. Le seul intérêt du full duplex c'est qu'un périphérique puisse emmètre et recevoir en même temps. ça ne m'est pas nécessaire. En gros mon système est un peu à l'image d'un talkie walkie : on peut avoir autant de personne qu'on veut, mais on parle chacun son tour. le full duplex va encore plus compliquer les choses car il faut que la ligne émission de l'un soit relié à la ligne réception de l'autre. Pour une communication "triangulaire" (imaginons trois périphériques devant communiquer chacun dans les deux sens avec les deux autres), c'est mort !!!

Le hic c'est qu'utiliser deux paires, d'une je vois pas en quoi ça me résout mon problème d'adaptation d'impédance, de deux ça me nécessite un connecteur supplémentaire (avec mon SBX je n'ai que mes deux contacts de puissance de 70mm² et deux contacts auxiliaires, donc une seule paire torsadée). D'autant plus qu'un connecteur comme XLR n'est à ma connaissance pas prévu pour être utilisé sous la pluie.

[invite36436748]

Ah ok autant pour moi, j'ai cru qu'il fallait que les deux puissent communiquer en même temps, donc oui effectivement une seule paire suffit. Par contre en ce qui concerne la communication il faudra que tu gères quand l'un parle à l'autre. Donc au niveau du dialogue le plus simple je pense que c'est d'envoyer à la fin de la transmission des données un caractère de terminaison, et ce pour chaque module, qu'ils puissent savoir quand basculer en maître ou esclave.

Exemple :

[A] est configuré en maître, et [B] en esclave. (c'est l'état initial, il faut qu'à chaque allumage il y ait cette configuration)

[A] envoie X données à [B] puis envoie "FIN_A" et se positionne en esclave (le caractère "FIN_A" est défini et toujours le même)

[B] reçoit les données dans l'ordre où elles ont été émises, puis il reçoit "FIN_A"

[B] se met alors en maître et envoie à son tour des données, puis "FIN_B" et repasse en esclave ("FIN_B" lui aussi défini)

Il ne te restera qu'à définir les données émises et les interpréter lorsqu'elles sont reçues par chacun des modules

[invite577b6a5c]

pour le protocole c'est pas un problème, j'ai même encore plus simple. ça va être plutôt quelque chose du style

• les cartes 100% capteurs en maître permanent qui balancent sur le bus leurs données à intervalles réguliers
• tout le reste en esclave quasi permanent qui ne bascule en maître que lorsque il y a quelque chose à envoyer, c'est à dire pas plus d'un seul maître à la fois, hormis les capteurs.
• Question protocole en lui même, j'envisage plutôt des trames de longueur fixe du genre un octet de start, deux "adresses" (type de donnée), deux données, et un stop. un octet d'adresse et un donnée devraient me suffire mais bon je préfère voir large dès le départ

Par contre je vais éviter les trucs du style requête/réponse. Chaque capteur balancera ses infos sur le bus à intervalle régulier, sans qu'on lui demande quoi que ce soit, ça va simplifier. De même pour chaque actionneur, qui répondra "spontanément" après une requête, mais pas forcément immédiatement.

Après avoir bien réfléchi, je crois que je vais partir sur le répétiteur selon la note d'application de Linear. Vu les faibles longueurs et les faibles taux de transferts, ça me parait pas mal.

[invite5637435c]

Bonsoir,

Deja il faut eviter de propager des inepties concernant ce reseau de communication.
Pour ce qui est des connecteurs: AUCUNE contrainte, le 485 est un bus differentiel pas sensible du tout aux types de connecteurs auxquels on le raccorde.
Borniers a vis, borniers type mini KK, etc ca fonctionne tres bien, meme un vulgaire domino conviendrait.
La resistance de terminaison est necessaire au dela d'une distance de cable de plusieurs metres (>10m), tout depend du transceiver utilise, de la vitesse, c'est uniquement ca qui conditionne cette resistance.
Il n'y a pas de protocole proprement dit pour le RS485, ce terme est utilise de maniere abusive pour ce bus.
Le CAN par exemple utilise un protocole, l'I2C egalement, pas le RS485 car c'est vous qui le definissez.
Les seules contraintes sont la vitesse, le nombre de bits, la parite ou non, le bit de stop.

Dans une application tel que l'amenagement d'un fourgon la vitesse importe peu, 9600 bauds suffit, half duplex egalement.
Un module -> une adresse et le maitre envoie ses octets en precisant juste le numero du satellite concerne, si c'est un ordre ou une requete le satellite le saura dans la suite des trames pouvant comporter des ordres que seul celui-ci saura reconnaitre, necessitant au module concerne de retransmettre au maitre les infos demandees ou non.
Inutile de transmettre en permanence, un ETX permet de terminer et de liberer la ligne donc de moins consommer.

Une methode consiste a creer des octets identifies par type d'info (courant, tension, temperature, etc), le module concerne sait d'office si il est concerne ou pas et ce qu'il doit faire.
La encore ca evite de surconsommer pour rien.
Dans une application embarquee c'est le plus important quand la source d'energie est une batterie.

Un exemple fonctionnel de protocole maison:

Question: STX # DATA ETX
Avec : STX : 02 = début de message (début texte ASCII) pour la version réseau,
# : N° du destinataire du message sur 1 chiffres ASCII :
'"0" = message général
"1" à "9" = identité du satellite
DATA : Zone de données variable suivant les messages.
ETX : 03 = fin de message

Tous les messages reçoivent une réponse sauf le message à usage général avec adresse « 0 ».

Réponse des satellites :
STX # ACQUIT CR

Avec # : N° du destinataire du message reçu sur 1 chiffres ASCII,
ACK = 06 : commande bien reçue, bien comprise, et exécutable
NAK = 15H : commande inconnue du destinataire
CAN = 18H : commande comprise mais impossible à exécuter.
EOT = 04 : Fin de Table, ou R.A.S.


@+

[invite5637435c]

Et puis pour le cable jusqu'a 20m aucune importance la encore, inutile de mettre une paire torsadee ou du blindage, c'est au-dela que ca peut devenir utile, pour ma part j'utilise regulierement du cable 3 conducteurs non blinde sur plus de 20m sans aucun probleme.
Tant que vous etes dans une application loisirs et sur des applications qui ne necessitent pas de commander des modules lies a des organes reclamant une certain niveau de securite il ne faut pas vous angoisser avec ca.
C'est tout l'avantage de ce bus differentiel de communication particulierement solide.
Contentez-vous d'un ACK et d'un CRC associe a vos datas pour mesurer vos reservoirs et vos batteries ou commander vos eclairages.
Faites l'essai et vous le constaterez par vous meme.

[invite5637435c]

pour le protocole c'est pas un problème, j'ai même encore plus simple. ça va être plutôt quelque chose du style

• les cartes 100% capteurs en maître permanent qui balancent sur le bus leurs données à intervalles réguliers
• tout le reste en esclave quasi permanent qui ne bascule en maître que lorsque il y a quelque chose à envoyer, c'est à dire pas plus d'un seul maître à la fois, hormis les capteurs.
• Question protocole en lui même, j'envisage plutôt des trames de longueur fixe du genre un octet de start, deux "adresses" (type de donnée), deux données, et un stop. un octet d'adresse et un donnée devraient me suffire mais bon je préfère voir large dès le départ

• C'est vous qui voyez mais l'idee de mettre en maitre des capteurs n'est pas judicieux.
  Je vous conseillerai plutot de mettre votre afficheur en maitre et tout le reste en esclave, le maitre interroge et les esclaves repondent, dans la pratique c'est comme ca que l'on procede.
  Encore une fois un reservoir ou une batterie ne se vident pas en un quart de seconde, dans votre application rien ne necessite de la vitesse, une simple interrogation ne serait-ce que chaque seconde c'est deja du grand luxe.
  Le micro va passer son temps a attendre... la recolte d'infos va prendre quelques ms.
  

[invite577b6a5c]

Pour le protocole, ça me parait plus simple de procéder façon "interruption", c'est à dire de la façon dont j'ai parlé. Étant donné qu'à terme il y aura deux afficheurs (un dans le fourgon, l'autre dans la carlo), ça me parait plus pratique que chaque carte envoie ses infos dès qu'il y a une évolution. Sinon chacun des deux doit interroger chaque capteur.
Pour la "surconsommation", pour le peu que ça consomme, mais bon puisque tu en parles, ça me parait plus judicieux de prodéder ainsi. Sinon l'afficheur passe son temps à interroger tout le monde à tout bout de champ, ce qui n'est pas d'une grande utilité si y'a rien de nouveau. Répondre à une requête ne résout pas ce faux problème. C'est peut-être de cette façon qu'on procède habituellement, ça me parait pas forcément être la plus intelligente. Le seul "gros" consommateur de l'installation c'est l'écran pour l'affichage, ou plutôt le rétro-éclairage. Déjà pour vider une batterie de 230Ah, faut y aller. Alors deux

En revanche concernant les 9600bauds half duplex, je suis entièrement d'accord avec toi. ça suffit amplement.

Pour la paire tordadée blindée, à partir de quelle longueur de cable faut-il commencer à envisager une paire torsadée ou blindée ? Mon ensemble atteint quand même les 15,5m de long, donc avec les tours et détours dans le cable, les 25 mètres seront allègrement dépassés. Et je tiens même pas compte du fait qu'il pourra y aura une rallonge lorsque je ne peux pas m'approcher très près.

[invite5637435c]

On peut en parler des jours entiers des systemes embarques, j'ai developpe pendant 10 ans des systemes multiplexes qui equipent aujourd'hui par exemple les camping-cars.
A l'epoque ce fut une vraie passion, puis l'imbecilite de ce milieu de carrossiers qui ne pensent qu'au fric m'a totalement degoute.
Du coup j'ai vendu mes etudes aux fabricants Allemands et Italiens, bien plus a l'ecoute de solutions techniques evoluees, qui ne se contentent pas de faire une evolution en implantant un ecran plat.... Bref une page de tournee pour moi il y a plus 15 ans maintenant.
Depuis les Allemands ont impose a tous le bus CAN dans la carrosserie industrielle, il faut bien leur reconnaitre leur legendaire pugnacite industrielle qui nous manque cruellement ici, nos bons commerciaux trop preoccupe par vendre tout et n'importe quoi sans s'arreter 2 secondes et reflechir a comment faire mieux que les concurrents ou industriellement plus coherent.

J'ai commence a poster en forum projet une realisation d'une centrale de gestion qui fut le premier systeme multiplexe a etre implante dans un vehicule industriel.
L'exemple que j'ai poste est un bus I2C, et oui ca peut paraitre etrange ce choix et pourtant ca fonctionnait tres bien sur 20m avec 3 satellites esclaves.
Si tu recherches une solution RS485 ou CAN, je peux te tuyauter sur ce sujet.

L'exemple de protocole que je t'ai montre est un exemple de base, il est evidemment possible de deporter de l'intelligence dans chacun des modules esclaves de facon a ce qu'ils n'emettent que dans des cas bien definis.
L'usage multi-maitres est a mon avis du luxe pour des accessoires qui ne necessitent pas une quelconque urgence a traiter les infos, savoir que la tension passe de 13,3v A 13,2V n'exige pas que le module qui mesure soit maitre a un moment donne.
Idem pour la mesure des reservoirs d'eaux, si tu appuies sur la pompe alors le capteur emet en permanence, des que tu stoppes la pompe une interrogation toutes les 10s est plus que suffisante ensuite, le niveau ne bougera plus de toute facon.

Les avantages des systemes multiplexes sont avant tout la reduction des faisceaux de cablages et la reduction drastique des consommations.
Depuis c'est devenu un reflexe, 10mAh c'est toujours bon a prendre ca fait 240mAjour et represente en une semaine la consommation moyenne d'une pompe par jour.
@+