Réduire câblage

[Tony04]

Bonjour,
je suis entrain de me saturer ma petite tête avec un projet de réseau utilisant le bus CAN pour l'envoie des commandes et la rétro-signalisation en partant de l'idée de DDEFF dans son article SGDD.
D'après l'architecture du système il semblerait que tout le monde part sur la séparation des tâches pour chaque module (cantons, aiguilles, signaux).
Pourtant on place toujours le décodeur aiguille proche de cette dernière; pourquoi ce décodeur ne pourrait'il pas s'occuper aussi de la détection de présence et du signal, cela réduirait considérablement le câblage je pense ? Est-ce une question d'adressage et de masque ?
Je suis preneur de toutes vos réflexions pour éviter de partir dans une usine à gaz, j'en suis à mon premier réseau et n'ai aucune expérience dans ce domaine (heureusement pour Arduino un peu plus).
Bonne soirée à tous
Antoine

[Dominique]

Bonjour Antoine,

Non ce n’est une tendance de séparer les fonctions (1 Arduino par type de fonction) : c’est le choix que j’ai fait, moi, parce que j’ai développé mon réseau fonctions par fonctions (le TCO d’abord, puis les commandes d’aiguilles et la traction, puis le gestionnaire de Pierre59 et je n’ai pas fini). Cette méthode a des avantages mais elle nécessite beaucoup de câblage et des connexions longues car en étoile. Mais ça fonctionne bien quand même.

Une autre tendance est de regrouper les fonctions les plus proches les unes des autres dans un même Arduino (commande d’aiguille, capteurs de présence et signaux) et de relier tous les Arduino en bus Can, ce qui permet d’avoir des connexions courtes avec ces organes. On peut alors avoir un bus de 6 fils seulement qui courre le long du réseau : 2 pour le DCC, 2 pour le Can et 2 pour l’alimentation des Arduino.

C’est exactement un projet que nous sommes en train de développer à plusieurs sur Locoduino et que nous décrirons quand il sera suffisamment réalisé et testé.

Nous avons l’habitude de ne rien décrire tant que ce n’est pas testé donc il faudra attendre un peu, mais je peux essayer de répondre à tes questions en attendant.

On parle aussi parfois de « un Arduino par canton » mais je ne suis pas convaincu par les regroupements fonctionnels que cela entraîne.

Dominique

[Rob1]

Bonjour à tous
Pour ma part je m'oriente aussi vers une solution d'intelligence répartie plutôt qu'une spécialisation par Arduino. Outre le gain de câblage je pense que cette organisation accompagne mieux les agrandissements du réseau. Je crois également que cela permet une meilleur utilisation des ressources en IO Ana PWM Interruptions ... De plus aujourd'hui la polyvalence ne s'impose-t-elle pas. J'attend donc avec intérêt la publication de vos travaux.

[bobyAndCo]

Bonjour à tous,

Je défend le concept présenté par Dominique que je n'hésite pas à appeler "un Arduino par canton". En réalité, il s'agit bien plus qu'un Arduino puisque cela comprend les servos (dans mon cas) pour les aiguillages, les détecteurs de consommation, la signalisation etc... etc... Donc tout ce qui fait un canton.

Je suis assez avancé sur un prototype où l'ensemble du code est identique sur tous les Arduinos. Seul l'ID de l'Arduino est différent et se paramètre en début de programme. Un certain nombre d'options sont "imposées par défaut" comme par exemple le fait que la classe aiguillage instancie 4 aiguillages ou que par défaut encore, le nombre de capteurs ON/OFF (consommation, effet Hall...) est fixé à 12. Je suis sur des MEGA et cela suffit dans mon cas à couvrir tous mes besoins et les dépasse même.

A partir d'un code standard et pour individualiser le travail de chaque MEGA à son canton, j'ai une méthode dans le setup qui va charger sur un serveur les paramètres spécifiques à ce canton reconnu par l'ID écrite en "dur" au début du programme. Pour cela, j'utilise une liaison Ethernet et un serveur en Node.js (mais cela pourrait aussi être fait en CAN). Le transfert des données est au format Json et j'utilise la bibliothèque "ArduinoJson" qui simplifie grandement l'affectation des valeurs à chaque paramètre.

L'avantage est bien sûr comme souligné déjà la réduction du câblage, mais aussi un code unique pour toutes les cartes donc plus facile à maintenir et à faire évoluer. Par ailleurs, le fait que tous les paramètres spécifiques d'un canon soient stockés dans de simples fichiers textes sur un serveur facilite aussi la maintenance et la mise à jour.

Je cherche à introduire en plus un bus CAN pour profiter d'une spécificité que bizarrement il ne me semble pas encore avoir vu développée sur Locoduino. La possibilité que chaque nœud  a d'intercepter l'ensemble des messages et donc de pouvoir agir dans certains cas sans avoir besoin (ou d'attendre) l'information d'un gestionnaire central. Un certain nombre d'objets locaux pourraient alors interagir sans passer (ou tout passer par le gestionnaire). Le cas le plus évident me semble par exemple l'interaction d'un détecteur de consommation sur le la modification de la signalisation lumineuse.

Cela me semble intéressant là où les questions de sécurité sont critiques (rapidité d'intervention, panne éventuelle du gestionnaire...) ou au contraire très secondaire. La gestion d'un PN n'a en effet probablement pas besoin de passer par un gestionnaire central mais met en œuvre pas mal d'actions qui peuvent être auto-gérées localement. Détection d'un train, feux rouges clignotants, signal sonore, fermeture des barrières...

Le CAN avec son système de filtres et de masques permet cela à merveille. C'est comme cela que je comprends "solution intelligente répartie"  dont parle Rob1.

Par contre, je déconseille vivement, et je ne suis pas le seul, d'envisager la conception d'un réseau aujourd'hui (hors traction bien sûr) sur le bus DCC et décodeurs comme en parle Tony04.

Bien amicalement

Christophe.

[Rob1]

Cela fait du bien de ne pas se sentir seul. J’adhère à l’idée d’Arduino identique mais mon modeste passé d’automaticien me fait craindre que cet objectif, poussé trop loin,  ne conduise à des ‘ usines à gaz ’. 
Il convient de bien modéliser des fonctions de base et de les faire inter-agir. L’intelligence répartie en automatisme est arrivée après les architectures maître-esclaves. Elles ont fortement évoluées avec ce que l’on a appelé les étiquettes mémoires embarquées et les machines transfert où chaque pièce (ou support) transportait les paramètres nécessaires pour chaque poste de travail automatique ou manuel.
C’est de cette manière que j’aimerais pouvoir déployer mon réseau. Ne riez pas tout le monde peut rêver, c’est pas taxer
Idéalement une zone, piloté par un Mega  autonome. Un train se présente à un des points d’entrée, il est équipé d’un récepteur infra-rouge. La motrice héberge un Attiny. Dans sa version la plus simple il émet en permanence le code DCC de la loco, à la détection de ce code l’Arduino demande au gestionnaire vers quel points de sortie il doit pousser le train. Dans une version plus utopiste l’Attiny a pu être programmé il porte son itinéraire.
Bien sûr le Mega informe le gestionnaire de ce passage et de l’état de tous les accessoires pour faire de belles images sur l’écran.
D’ici quelques années je vous donnerai des nouvelles en attendant merci à tous ceux qui défrichent sur le site.

[Jean-Luc]

Bonjour,

Il ne s'agit pas forcément de répartir l'intelligence mais de répartir intelligemment le matériel afin de minimiser le câblage. Effectivement répartir l'intelligence, ce que tu évoques me fait penser aux système multi-agents, est plus compliqué à gérer que lorsqu'elle est centralisée.

Donc dans mon esprit, il s'agirait plutôt de faire un système avec une intelligence hiérarchique plutôt que répartie.

[Tony04]

Ouf, je vois que je ne suis pas seul à me poser ce problème de câblage.
En tous cas merci pour toutes ces réponses, elles vont encore me faire passer des nuits blanches avant d'y voir enfin plus clair.

Dans un post précédent (mon premier sur ce forum) je vous avais parlé d'un essai de reconnaissance de la loco par capteurs Hall. Je viens de tester le principe et c'est un sans faute, aussi bien à vitesse très réduite que de passer la loco à la main 3 fois plus vite que sa vitesse maximale. Avant d'en dire plus j’attends des capteurs CMS qui seront pratiquement invisibles entre les traverses.

A bientôt donc et bonne soirée
Antoine

[Dominique]

Dans un post précédent (mon premier sur ce forum) je vous avais parlé d'un essai de reconnaissance de la loco par capteurs Hall. Je viens de tester le principe et c'est un sans faute, aussi bien à vitesse très réduite que de passer la loco à la main 3 fois plus vite que sa vitesse maximale. Avant d'en dire plus j’attends des capteurs CMS qui seront pratiquement invisibles entre les traverses.

J’en connais qui seront très intéressé !

Dominique

[CATPLUS]

Bonjour à tous

Je suis très intéressé .....

Juste pour polémiquer

Tout ceci c'est bien jolie, les questions y a-t-il des limites à vos projets (nbs d'Arduinos, longueur du développé du réseau, échelle pratiquée, champs magnétiques, perturbations en tout genre - IR - Eclairage, fils blindés, fils souple (section) alimentation générale du system 5Volts, 12volts (à petite distance + de 10 mètres chute de tension) etc....... 

Cordialement
Marcel

[Jean-Luc]

j’ai des exemples d’installations   

Nous réalisons l’électronique avec deux amis, Philippe et Pierre. Philippe a un blog, ici : http://lestrainsdutertre.redheberg.com/TouteVapeur/Les_trains_du_Tertre/Les_trains_du_Tertre.html
Nous sommes en analogique, block system avec asservissement de vitesse. Détection uniquement par consommation. Les logiciels sont mis à jour « over the air » comme on dit

Philippe : échelle H0. 40 cantons, 3 bus CAN, environ 60 micro-contrôleurs. 10 + 20 + 4 nœuds CAN
Pierre : échelle N, 64 cantons, 3 bus CAN, environ 90 micro-contrôleurs 16 + 25 + 4 nœuds CAN

Pour ces deux réseaux, l’électronique est installée et opérationnelle. Pas d’erreurs sur le CAN, et de manière assez surprenante sur le réseau de Philippe, qui a choisi de réunir les cartes canton en un seul point, la mesure de FCEM des locomotives se fait parfaitement au travers de plusieurs mètres de fils.

Moi : échelle N, 38 cantons, 2 bus CAN, environ 60 micro-contrôleurs, installation en cours.

Concernant l’alimentation générale de l’informatique, il faut bien évidemment mettre un régulateur sur chaque noeud. Nous alimentons les nœuds en 9V. Mes fils d’alimentation font 1mm².

Le premier réseau CAN qui relie les cartes traction est à 700kbits/s (un peu plus en fait, la faute au quartz de la carte où tourne le gestionnaire qui est à une fréquence idiote). Le câblage est en RJ45 : CAN + signal de synchro de PWM + signal de synchro de mesure de vitesse). Chez Philippe il est de longueur faible, toutes les cartes canton sont réunies sur 1m2. Chez Pierre, il fait le tour de la pièce, soit une quinzaine de mètres. Chez moi il fait 6m50.

Le second réseau CAN qui relie les autres cartes (signaux, aiguillages, son, éclairage, pont tournant, ...) est à 125kbits/s et est câblé en rj11 (câbles téléphoniques). Pas d’erreurs de communication non plus alors que sur ces câbles les paires ne sont pas torsadées.

Le troisième est destiné aux postes de conduites (4 maxi), postes que je n’utilise pas. Il est également à 125kbits/s. Le câblage est également rj11 mais différent car il transporte également l’alimentation du poste qui est connectable à chaud.

[Didier44]

Bonjour à tous,

J'en suis à la finalisation du travail de charpentier qui préside à la réalisation d'un réseau.
Tout comme vous je suis en train de réfléchir aux types de câblages à adopté et mes premières réflexions vont effectivement vers "un Arduino par canton". Je ne'en suis qu'aux prémices mais je rejoins le projet de Christophe, pas forcément avec nodeJS mais je suis sur le même principe avec une description de réseau externe non codée en dur.
Je réfléchis à une piste en Wifi et il me suffirait de quelques unités seulement coté cantons. Bon évidement sur un réseau de 3.4m de long, et assez dense, on peut se poser la question de supprimer un bus d'autant qu'il faudra garder des fils pour les alimentations , mais c'est juste pour le challenge... A voir

Didier

[DDEFF]

Bonjour,

Étant cité au début de ce post et ayant un peu de temps à consacrer au forum, je me permets de préciser ma position.

1°) Je pense qu'il faut développer un module standard.
C'est à dire un module géré par un Arduino NANO et qui a pour rôle de s'occuper de 4 "machins". Pas plus, surtout.
Parmi les "machins" :
-> La détection de présence d'une seule zone (je n'ai pas dit "canton", qui peut contenir plusieurs zones)
-> la commande d'un appareil de voie (c'est à dire un servo-moteur)
-> la commande d'une LED (et donc des signaux)
On a 8 entrées et 8 sorties et donc, c'est assez.
Tout peut être est mélangé sur le même module.
Le choix est fait par la distance au "machin" (voir 2°)


2°) Un fichier texte qui donne les infos sur ce que fait le module en question (en fonction de ce qu'on y a branché).
3°) Des fiches démontables pour aller vers les "machins" avec des câbles qui ne devraient pas dépasser 30 cm.
4°) D'un module à l'autre, un câble RJ11 et un bus CAN

Donc, si un module tombe en panne, on le retire, on en prend un vierge et grâce au fichier texte spécifique et au programme standard, on régénère ce module spécifique.
On le rebranche et c'est reparti.

Denis

[railyRabbit]

Hello,

Je réfléchis également à passer au CAN pour simplifier le câblage.

J'ai déjà un "bus" RJ45 qui relie mes 9 décodeurs infrarouges (3 brins pour l'alimentation, 1 pour le PWM à 38kHz, 4 brins pour coder en binaire sur 4 bits le détecteur qui se déclenche). Le câble est blindé sur quasiment toute la longueur, mais je commence à avoir des perturbations, il est raide, il ne sert qu'aux décodeurs IR...

Un bus CAN me permettrait de faire passer de l'info pour d'autres besoins : les consignes d'alimentation des cœurs d'aiguilles, des animations, de l'éclairage... avec un seul fil.

Je suis également parti dans l'idée d'avoir 3 arduinos répartis sur le réseau, pour simplifier le câblage : 1 "central" qui portera surtout la liaison avec la TCO (filaire, mais j'aimerais bien radio aussi), et 2 "locaux" qui s'occuperont des "machins" à proximité.

Je fabriquerai peut-être ma carte perso, un peu sur le modèle de la Sodaq Mbili : un ATMEGA 328, un étage CAN (j'ai suivi à distance le fil de Dominique & Jean-Luc), et des prises qui exposent des pins d'alim et les entrées/sorties.

[Dominique]

Je fabriquerai peut-être ma carte perso, un peu sur le modèle de la Sodaq Mbili : un ATMEGA 328, un étage CAN (j'ai suivi à distance le fil de Dominique & Jean-Luc), et des prises qui exposent des pins d'alim et les entrées/sorties.

Bon, ce vœux va être exhaussé et avec un peu de patience nous allons décrire ce que nous présenterons à Orléans, notamment une telle carte et un bus Can (sans fichier texte !).

Comme toujours la description suit le développement et la mise au point pour ne pas écrire de bêtises.

A bientôt donc sur ce sujet 

[railyRabbit]

Bon, ce vœux va être exhaussé et avec un peu de patience nous allons décrire ce que nous présenterons à Orléans, notamment une telle carte et un bus Can (sans fichier texte !).

quel teasing !