rs485 et collision
Patrick
J ai déjà utilise le rs 485 en 1 émetteur 1 récepteur
Maintenant je voudrais 10 émetteur et 1 récepteur
Comment gérer les collisions si 2 émetteurs émettent en même temps ?
émetteur géré par PIC (il ne fait que cela) bouton poussoir >>RS485
récepteur Automate ( facilité de programmation moyen)
peut de transfert (bouton poussoir) mais risque de collision car bouton +
et -
Merci de vos idée
Pascal
Jean-Yves
"Patrick" <pat...@free.fr> wrote:
utiliser un truc comme cela :
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4073/ln/en
explications sur un reseau rs485 ici :
http://www.maxim-ic.com/appnotes.cfm/an_pk/1833
--
Jean-Yves.
jj
je te propose deux solutions:
1- (la plus complexe à mon gout) : même principe que Ethernet,
implémenter une détection de collisions, soit en comparant le message
relu sur le bus, soit avec une détection hardware (voir si certains
drivers sont équipés de cette fonction)
si collision => attente un temps aléatoire => répéter
il est important d'avoir un temps aléatoire, sinon les esclaves vont
systématiquement se répéter en même temps !
cela me semble assez fastidieux au niveau programmation, surtout si tu
ne peux pas faire de détection hard des collisions.
inconvénient : le temps de réponse peut être extrêmement variable,
attention si c'est critique dans l'application (boutons poussoirs).
1,1 (variante du 1) : à chaque message émis par un esclave, le maître
répond un accusé de réception, personnalisé bien sûr pour que seul
l'initiateur le traite, si il n'y a pas réponse sous un délai X, alors
il y a eu collision qq part.
inconvénient de cette méthode : la collision peut avoir lieu sur
l'accusé de réception, et comme tu répéteras le message, il sera recu 2
fois, cela peut être gênant.
2- (la plus simple pour moi) : le maitre scrute ses esclaves en les
interrogeant tour à tour, ainsi chaque esclave parle poliment quand on
lui donne la parole, pas de collision possible.
De plus cette méthode permet de contrôler si les esclaves sont actifs.
inconvénient : temps de réponse plus important, mais par contre restera
toujours dans un maximum connu et constant.
JJ
GRENON Loïc
> 1- (la plus complexe à mon gout) : même principe que Ethernet,
> implémenter une détection de collisions, soit en comparant le message
> relu sur le bus, soit avec une détection hardware (voir si certains
> drivers sont équipés de cette fonction)
>
> si collision => attente un temps aléatoire => répéter
>
> il est important d'avoir un temps aléatoire, sinon les esclaves vont
> systématiquement se répéter en même temps !
>
Puisqu'on en parle, j'aimerai savoir si l'ENC28J60 (le controlleur
éthernet de microchip) prend en charge ces collisions ou si la pile
TCP/IP (celle fournie librement par Microchoip) s'en charge.
Merci
Stéphane Santon
Patrick a écrit :
> J ai déjà utilise le rs 485 en 1 émetteur 1 récepteur
> Maintenant je voudrais 10 émetteur et 1 récepteur
> Comment gérer les collisions si 2 émetteurs émettent en même temps ?
Un système à jeton, chaque émetteur envoie régulièrement l'information
vrai/faux quel que soit l'événement. Tous les émetteurs écoutent les
autres émetteurs, connaissent leur place (adresse) dans le réseau, et
émettent dès que le précédent dans la boucle d'émission a terminé, et
passe ainsi le jeton (relais) au suivant.
>
> émetteur géré par PIC (il ne fait que cela) bouton poussoir >>RS485
> récepteur Automate ( facilité de programmation moyen)
>
> peut de transfert (bouton poussoir) mais risque de collision car bouton + et
Peut-être revoir le cahier des charges pour une solution plus adaptée ?
Adrien Gaudel
"Stéphane Santon" <new...@team-santonum.com> a écrit dans le message de
news: mn.69f77d891...@team-santonum.com...
> Un système à jeton, chaque émetteur envoie régulièrement l'information
> vrai/faux quel que soit l'événement. Tous les émetteurs écoutent les
> autres émetteurs, connaissent leur place (adresse) dans le réseau, et
> émettent dès que le précédent dans la boucle d'émission a terminé, et
> passe ainsi le jeton (relais) au suivant.
C'est d'ailleur comme cela que fonctionne la pluspart les liaisons RS485
industrielle (ProfibusDP, etc...)
maioré
"Patrick" <pat...@free.fr> a écrit dans le message de news:
48cac355$0$1403$426a...@news.free.fr...
Je fais cela avec un reseau RF E/R (un µc pour chaque periphérique)
Tous sont en position reception (meme frequence) losque l'un d'eux veut
transmettre, si le reseau est occupé il temporise un temps préréglé avant de
reessayer à nouveau.
Bon apres midi
Patrick
En panachant les réponses je pense partir sur cette solution:
Envoie par automate de 2 bit ETX FFH FEH
A la réception les modules envoie 4 bit FDH, adresse module, valeur ,FCH
pour éviter les collisions chaque module attend (delay x adresse)
Donc à une vitesse de 19200 j ai 1 octet en 0.52ms 1/19200*10bit
Delay=3 ms valeur supérieur au moins a l expédition de 4 octet
1 module 4*.052=2.08 ms
2 module 1xdelay + 2.08 ms=5.08
3 module 2xdelay +2.08ms=8.08ms
......
10 module 9xdelay +2.08ms= 29.08ms
Scan possible toutes les:
2 octets envoyé par automate + réponse module 10 2x0.52 + 29.08ms =
30.12ms + sécurité
Donc je vais scanner toutes les 50ms .20 scan par seconde suffi pour du
bouton poussoir
J espère ne pas voir fait d erreur de calcule
Merci
Reste plus cas....
Pascal
jj
oui c'est astucieux, mais je trouve cela un peu risqué car en cas de
décalage 'tenir compte du temps de scrutation( de 0 à xxms) + temps de
traitement, ça ne marchera pas.
En effet le temps de scrutation est fixe, mais comme la réception du
message peut intervenir à n'importe que moment, le temps du à la
scrutation est variable, et ça m'étonnerait qu'il soit inférieur à 2 ms!
personnellement j'aurai préféré une solution 'synchrone' avec un maitre
qui interroge les esclaves un à un, ainsi, quels que soient les temps de
réponse, tu es sur que chacun parle à son tour, et que toutes les
fonctions sont exécutées en bon ordre, en faisant ainsi, la scrutation
sera toujours au maximum de vitesse possible.
JJ
Patrick a écrit :
Patrick
> Bonsoir,
>
> oui c'est astucieux, mais je trouve cela un peu risqué car en cas de
> décalage 'tenir compte du temps de scrutation( de 0 à xxms) + temps de
> traitement, ça ne marchera pas.
>
> En effet le temps de scrutation est fixe, mais comme la réception du
> message peut intervenir à n'importe que moment, le temps du à la
> scrutation est variable, et ça m'étonnerait qu'il soit inférieur à 2 ms!
>
Bonsoir
Je ne comprend pas trop la réponce le plus simple est encore le shéma
pour l'explication de mon principe
A vos remarques
Pascal
Yvan BOURNE
Bonsoir,
Le plus simple, c'est réellement comme dit JJ : que ce soit le maître qui
interroge tour à tour chaque esclave.
Le timing sera optimisé et si tu rajoutes ou enlèves un esclave, tu n'auras
que le soft du master à changer.
jj
on peut même imaginer une gestion dynamique des esclaves : chaque
esclave a qq ms pour répondre, un esclave muet est retiré au bout de x
temtatives de com.
ceci mis dans des bits permet de connaitre le status des esclaves
(opérationnel ou non) et aussi de sauter les esclaves inactifs.
accessoirement, toutes les x secondes ou minutes, les esclaves peuvent
être scrutés de façon systématique ou aléatoire afin de les "remettre
dans la boucle" si ils redeviennent à nouveau opérationnels...
ça parait compliqué mais en fait c'est assez simple à mettre en place,
il faut considérer chaque tâche comme indépendante, et dialoguer via des
bits...
on est en train de réinventer profibus comme c'est parti là !!
JJ
Rufus Larondelle
> Puisqu'on en parle, j'aimerai savoir si l'ENC28J60 (le controlleur
> éthernet de microchip) prend en charge ces collisions ou si la pile
> TCP/IP (celle fournie librement par Microchoip) s'en charge.
les collisions ne sont pas au niveau IP ou TCP, donc logiquement ca doit
être l'EN28J60 qui doit s'en charger (calcul checksum).
Claude