Ayant pas mal avancé sur la gestion des trains, je vais vous exposer ma vision des choses :
I°) On doit dès le début choisir entre 3 options :1°) Réseau complètement géré par Arduino, en analogique pur
2°) Réseau complètement géré par Arduino en DCC, y compris la centrale DCC en Arduino
3°) Réseau géré par Arduino et centrale DCC du commerce, pour ceux qui ont acheté un starter kit et qui hésitent à agrandir leurs gestion en voyant le prix des boîtiers DCC du commerce. C'est le cas le plus complexe.
La centrale du commerce ne s'adresse qu'aux trains, le reste (aiguilles, signaux, etc) étant géré par l'Arduino.
II°) On ne peut pas gérer ET en analogique ET en DCC.C'est certainement techniquement possible, mais très dangereux : imaginez une loco qui, par erreur, serait à cheval sur un canton analogique et un canton DCC : le moteur n'y survivrait pas. On ne peut pas se le permettre.
Donc, on choisit au départ une technique et on s'y tient.
III°) Utilisation du bus CAN pour les échanges sous le réseau.C'est le meilleur, le plus fiable et il sait tout faire.
IV°) L'Arduino DUE, avec 2 bus CAN natifs, est le candidat idéal pour gérer deux bus : un "rapide" pour la gestion des trains et un "lent" pour les accessoires.
De plus, il a 64+32 k de SRAM et donc plus aucun problème de mémoire.
Et processeur 32 bits...
V°) Je conserve la répartition des tâches (mail de Jean-Luc du 15/04) entre différentes cartes :A) cartes de commande / détection de canton
B) cartes de commande d’aiguillages
C) cartes de commande de signaux
D) carte de pilotage du réseau
E) carte TCO
VI°) Cartes canton "A" :En analogique, elle existe déjà (voir sur le forum "alimentation traction de canton")
En DCC, comme on en demande moins à la carte, on pourra en avoir une pour plusieurs cantons.
En DCC, la carte détecte la présence des trains sur les 3 zones (zone d'arrêt gauche, pleine voie et zone d'arrêt droite).
On peut avantageusement profiter qu'on gère 3 zones pour en déduire finement et localement le sens de déplacement du train, sans pour cela avoir à décoder la trame DCC.
A noter une chose importante : la gestion des boucles de retournement.
C'est par des échanges entre A et D qu'on peut inverser l'alimentation en sortie de boucle.
Je suis contre le système qui consiste à détecter un court circuit (type LK200 de Lenz)
VII°) Cartes de commande d'aiguille "B" :Dans ma logique (type PRS), je détecte la présence d'un train sur chaque aiguille indépendamment.
Ce qui m'oblige à une carte qui contient un détecteur de présence et de sens de circulation.
Sur un grill complexe (le mien a 180 itinéraires), il y a des aiguilles qui peuvent être alimentées de multiples façons et dans les 2 sens.
J'ai besoin d'un relai de sens (2RT) et d'un relais d'alimentation (1RT) suivant la position.
En prenant 2 x 2RT, je gère la pointe de cœur.
Mais un seul Nano peut gérer plusieurs cartes. Il aura à gérer la communication bus CAN.
De D vers B, le sens de circulation et la position demandée.
De B vers D, la présence et la position du fin de course.
VIII°) Carte de commande des signaux "C" :Non nécessaires au fonctionnement, mais ça fait tellement joli ...
IX°) Carte de pilotage du réseau "D" :C'est évidemment la plus complexe.
Il faut trouver un moyen compact d'emmagasiner les informations :
Un objet "canton" définit pour chaque canton l'élément précédent et l’élément suivant.
Je dis bien "élément" car il peut s'agir soit d'un autre canton, soit d'une aiguille.
Un objet "aiguille" définit pour chaque aiguille l'élément précédent et l’élément suivant.
Périodiquement, le réseau envoie via le bus CAN lent des infos sur les occupations des cantons et aiguilles, des positions des aiguilles.
Pour ne pas saturer le bus CAN, les infos ne sont envoyées par les cartes A et B que quand elles ont évolué.
Il ne servirait à rien d'envoyer toutes les 10 ms "l'aiguille est tout droit" quand aucun train n'est dans les parages.
C'est au niveau des cartes A et B que l'opportunité d'envoi d'infos est jugée.
Ces infos mettent à jour les objets "canton " et "aiguille".
Périodiquement, mais, là, c'est la carte D qui décide, les infos calculées des objets "canton" et "aiguille" sont calculées.
Sur un réseau de 60 cantons et 60 aiguilles, ces calculs prennent ... 6 ms seulement.
Et dans ces 6 ms, je calcule les itinéraires (180, je le rappelle), ce qui me permet, cette fois, de calculer quel est le canton suivant un canton donné, en tenant compte de la position réelle des aiguilles (pas l'élément suivant, mais bien le canton).
En ayant les cantons suivant et les occupations, je peux calculer tous les feux.
Et en ayant les positions d'aiguilles, je peux même gérer les R et RR, 30, 60 et 160.
Mais pourquoi donc calculer tous les feux, si c'est seulement pour faire joli ?
Mais parce que le feu donne au train sa vitesse maxi.
Et ça, la carte D en a vraiment besoin, de cette information.
Je mets à jour un autre objet, "train", cette fois qui gère tous les trains et leur assigne une vitesse dans le bus CAN rapide.
X°) Cartes TCO "E" :En lisant les objets "train" et les objets "canton", la carte D peut envoyer à la carte E les LED à allumer
