Discussions Générales > Bus CAN

Réduire câblage

(1/7) > >>

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.

Navigation

[0] Index des messages

[#] Page suivante