J'ai un réseau LGB qui fait 6.35m sur 3.20m qui fonctionne à l'ancienne càd six blocs commutés à la main sur deux alimentations 10A, et quelques voies de garage.
J'aimerais automatiser la commutation des blocs et simplifier le câblage.
Je commence à maîtriser l'Arduino pour les commandes de base.
Vu la taille, et ce n'est pas encore le jardin, un seul Arduino ne conviendra pas, il en faudra un certain nombre qui se parlent entre eux.
Après étude j'ai constaté que la plupart des réseaux proposés sur Arduino (Série, SPI, I²C) sont de type maître/esclave càd qu'ils ne peuvent pas parler entre eux, mais seulement avec le maître...
En creusant davantage, je me suis intéressé au réseau CAN, similaire à celui que l'on trouve dans les voitures les plus récentes. D'abord horrifié par le prix, j'ai trouvé un shield à 15€...
Le réseau CAN travaille naturellement en Multi-Master...
En m'inspirant de ce que j'ai découvert sur la toile, j'envisage de faire un essai tout simple avec deux cartes... d'une part deux boutons éclairés... d'autre part une aiguille LGB avec son inverseur...
Quatre commandes partent en "broadcast" sur le réseau (qui dans ce cas est tout petit) :
1: je presse le bouton pour basculer l'aiguille à gauche... l'aiguille bascule à gauche
2: je presse le bouton pour basculer l'aiguille à droite... l'aiguille bascule à droite
3: l'inverseur de l'aiguille indique que l'aiguile est à gauche... le témoin gauche s'allume
4: l'inverseur de l'aiguille indique que l'aiguile est à droite... le témoin droit s'allume
A priori il n'y a pas de limite contraignante au nombre de commandes que l'on peut envoyer sur le réseau.
Quelle serait votre réaction à cette idée ?
Bonjour
Je ne connais le bus CAN que de nom, mais il y a aussi le RS485 qui pourrais je pense t'aller. Et ça ne coûte presque rien, moins 1.5€ pour 10 "MAX485" en chine.
Après, ce n'est que du "Serial". Un protocole qui lie en écrivant pour savoir s'il n'y a pas conflit.
Je doit tester ça aussi, mais pas pour de suite.
A+
Bonjour,
Le bus CAN répond bien à ce que tu veux faire. Il permet tout à fait de faire ce que tu envisages c'est à dire à un actionneur de communiquer directement avec un afficheur. Le câblage en bus simplifie (généralement) le câblage.
Tu peux aussi utiliser un réseau ethernet avec les inconvénients d'avoir un timing moins déterministe et un câblage en étoile.
Est ce que tu as vraiment besoin d'avoir un réseau multi-maitre? Tu as un maître de fait qui est ton boitier de commande. Le maître peux recevoir l'état de l'aiguille et commander le voyant.
Je pense que le rs485 ne permet pas le multi-maitre, il n'y a pas de détection de collision et il faut obligatoirement un maitre pour arbitrer les échanges.
Dans sa spécification (ANSI/TIE/EIA-485-A) le RS485 est décrit comme un bus supportant plusieurs émetteurs et plusieurs émetteurs.
Le contrôle de collision est réalisé par l'écoute des message émis. L'émetteur peut écouter ses propres messages et déterminer s'il y a eu carambolage ou non. Cela impose la mise en place d'un protocole que ne décrit pas la norme.
Mais le multi-maitres n'est pas toujours la solution. S'il y a trop de maitres sur le bus la gestion du carambolage peut devenir complexe. Dans le cas exposé, un maitre qui interroge l'ensemble du réseau régulièrement semble plus pertinent.
Le choix du bus repose aussi sur l'architecture finale envisagée.
Si la gestion est centralisée, il n'y a aucune raison à priori de mettre en place un protocole complexe supportant le multi-maitres.
Si la gestion est décentralisée, il vaudrait mieux avoir des bus locaux et un bus particulier remontant de l'information filtrée (plus synthétique) vers un panneau d'information central.
fdufnews:
Dans sa spécification (ANSI/TIE/EIA-485-A) le RS485 est décrit comme un bus supportant plusieurs émetteurs et plusieurs émetteurs.
C'est un des intérêts du RS485
Le contrôle de collision est réalisé par l'écoute des message émis. L'émetteur peut écouter ses propres messages et déterminer s'il y a eu carambolage ou non. Cela impose la mise en place d'un protocole que ne décrit pas la norme.
Ca me parait compliqué à gérer. De plus ça ne me parait pas très fiable si il n'y a pas la notion de bit recessif/dominant comme dans le CAN.
A mon avis la meilleure façon de gérer un semblant de multi maitre est de faire circuler un token qui autorise à parler. Ca demande quand même un superviseur au cas ou un des noeuds ne répondrait pas.
Mais le multi-maitres n'est pas toujours la solution. S'il y a trop de maitres sur le bus la gestion du carambolage peut devenir complexe. Dans le cas exposé, un maitre qui interroge l'ensemble du réseau régulièrement semble plus pertinent.
D'accord avec toi.
Bonjour,
et pourquoi pas du sans fil ?
cela te permettrait de contrôler tes aiguillages et tes engins (qui pourraient alors aussi fonctionner sur batterie)