Projet partagé d'un gestionnaire de réseau

[DDEFF]

@ Pierre,

Sur le réseau de Dominique, j'ai bien respecté le fait que les zones impaires se suivent et les zones paires se suivent.
Donc, quand on suit un circuit, on change bien de parité du cote à chaque changement de zone, ce qui est ta condition à laquelle je souscrit parfaitement.
Il ne faut pas dessiner n'importe quoi et, là aussi, je suis bien d'accord.
En fait, nos points de vue sont parfaitement compatibles.

Bretelles : c'est dans le JSON que sont calculées les positions où elles sont en continuité. On n'a donc plus à le faire dans le gestionnaire.
Exemple :

Code: [Sélectionner]

    "a13" : {
        "type" : "aiguilleD",
        "bretelle" : ["droite", "a16"],
        "no" : 13
    }

A vérifier sur le réseau de Dominique : L'aiguille a13 à droite fait face à l'aiguille a16 à droite.

Il est certain que faire marcher un gestionnaire sur un microcontrôleur est extrêmement complexe car ça ajoute de contraintes de place et de temps de calcul. A ma connaissance, ce serait une première.

Choix des itinéraires :

Evidemment, à chaque fois qu'on va choisir deux points, le programme va nous sortir plusieurs itinéraires possibles techniquement.
1°) Il faut d'abord éliminer ceux qui font parcourir une zone paire dans le sens impair (et réciproquement), sauf si c'est une zone à 2 sens.
2°) Il faut éliminer les itinéraires qui font tout le tour du réseau
3°) Il est tentant de calculer le nombre de zones parcourues par chaque itinéraire et de prendre l'itinéraire qui a le plus petit nombre de zones. Mais je crains que cela nuise à la fluidité.
4°) Quand on demande à un programme deux fois le même calcul, il va fournir à chaque fois les même solutions dans le même ordre.
On peut alors numéroter les itinéraires, ce qui évite d'avoir à les décrire et remplacer une liste de zones par un "int".
Et regarder, "à la main" quel itinéraire on veut garder en fonction de l'origine et l'extrémité sélectionnés.

Exemple sur le réseau de Dominique :
Je veux aller de Z25 à Z30 :

Code: [Sélectionner]

Z25 (section) signal1 signal1
Z26 (triple droit) L0 a0 a gauche + a1 a droite TIV
Z27 (section) signal1 signal1 vitesse maxi 60 km/h TIV
Z29 (triple gauche) L0 a11 a droite + a9 a gauche TIV
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 292
Z25 (section) signal1 signal1
Z26 (triple droit) L1 a0 a droite vitesse maxi 60 km/h RR
Z15 (TJD) L0 a2 a droite + a4 a droite vitesse maxi 30 km/h TIV
Z42 (aiguille droite) L1 a5 a droite vitesse maxi 30 km/h RR
Z14 (section) signal0 signal0 vitesse maxi 30 km/h TIV
Z43 (aiguille gauche) L1 a6 a gauche vitesse maxi 30 km/h RR
Z12 (TJD) L1 a7 a gauche + a8 a gauche vitesse maxi 30 km/h TIV
Z29 (triple gauche) L1 a11 a gauche vitesse maxi 60 km/h RR
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 293
Z25 (section) signal1 signal1
Z26 (triple droit) L2 a0 a gauche + a1 a gauche vitesse maxi 60 km/h RR
Z44 (aiguille gauche) L1 a3 a gauche RR
Z28 (section) signal1 signal1 vitesse maxi 30 km/h TIV
Z29 (triple gauche) L2 a11 a droite + a9 a droite vitesse maxi 60 km/h RR
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 294

Il trouve 3 itinéraires qui se trouvent avoir les numéros 292, 293 et 294 dans "_TOUS_ITI____.tsv"
Je décide (au pif, ici) de retenir l'ordre suivant, dans le JSON :
"itinéraires" : ["Z25", "Z30", 2, 1, 3]
Ce qui, dans mon esprit, veut dire :
Quand on demande Z25-Z30, on choisit l'itinéraire n°2. Si c'est incompatible avec un autre itinéraire existant à cet instant ou si une zone de cet itinéraire est occupée, on choisit ensuite le n°1. Et si c'est encore impossible on choisit n°3.

Cette notation est compacte, peut être taillée sur mesure. Si le programme sort 10 itinéraires, on peut n'en garder que 3, ...
A ce moment, on utilise dans mon éditeur JSON le bouton itinéraire qui ne donne que les itinéraires d'un point choisi et un autre point choisi.

La seule contrainte est qu'il faut le même programme de recherche d'itinéraires dans l'éditeur JSON et le gestionnaire.

Denis

[DDEFF]

@ Pierre,

Pour pouvoir faire tourner une recherche d'itinéraires, il faut des connecteurs.
Dans mon éditeur graphique de TCO, je les repère par leur coordonnées X, Y.
Là, n'ayant pas de X, Y, je me suis rendu compte qu'il suffit que chaque connecteur ait un ID.
Le connecteur étant le point unique entre 2 zones mitoyennes, je mets cet ID dans les voisins, par un "int" en premier.

Exemple des zones Z22, Z23, Z24 et Z25 dans le réseau de Dominique :

Code: [Sélectionner]

            "Z22" : {
                    "nom" : "Z22",
                    "sens" : "impair",
                    "signI" : "C1",
                    "balI" : "B17",
                    "voisP" : [36,"Z35"],
                    "voisI" : [37,"Z24"],
                    "no" : 15
            },
            "Z23" : {
                    "nom" : "Z23",
                    "sens" : "impair",
                    "signI" : "C3",
                    "balI" : "B19",
                    "voisP" : [38,"Z35"],
                    "voisI" : [39,"Z24"],
                    "no" : 16
            },
            "Z24" : {
                    "nom" : "Z24",
                    "voisP" : [40,"Z25"],
                    "voisI" : [[37,"Z22","a18","gauche"],[39,"Z23","a18","droite"]],
                    "no" : 17
            },
            "Z25" : {
                    "nom" : "Z25",
                    "sens" : "impair",
                    "signI" : "C5",
                    "balI" : "B21",
                    "voisP" : [40,"Z24"],
                    "voisI" : [44,"Z26"],
                    "no" : 18
            },

Le voisI de Z22 a le connecteur 37 et on retrouve le connecteur 37 dans Z24 quand l'aiguille est à gauche.
Le voisP de Z25 a le connecteur 40 et on retrouve le connecteur 40 dans Z24 à la pointe de l'aiguille

Voilà
Denis

[Pierre59]

@ Denis

Vous prendrez bien un "connecteur", non merci. Le gestionnaire json n'a pas besoin de connecteurs pour faire des recherches d'itinéraires, les informations présentes dans les voisins sont amplement suffisantes.

Accessoirement les noms des zones, des aiguilles, signaux, … ne sont pas utiles, c'était juste pour des mises au point et des essais.

Pierre

[trimarco232]

(...)
3°) Il est tentant de calculer le nombre de zones parcourues par chaque itinéraire et de prendre l'itinéraire qui a le plus petit nombre de zones. Mais je crains que cela nuise à la fluidité.
Denis

bonjour , cette solution me va bien , et je pense que nos figurines , bien que toujours terriblement pressées , peuvent bien s’accommoder d'une milliseconde de traitement supplémentaire

[DDEFF]

@ Pierre,

Quand on cherche des itinéraires, on parcourt un graphe et on va d'un nœud à un autre. Qu'on appelle les nœuds "connecteurs" ou autrement, cela ne change rien.
Après, que tu me dises que ça n'a rien à faire dans le JSON parce qu'on peut les calculer dans le gestionnaire, je l'entend parfaitement.
C'est d'ailleurs aussi le cas des bretelles, facilement calculables à partir des voisins dans le gestionnaire.

Il y a un problème de vases communicants : plus le JSON est petit, plus le setup grossit pour calculer les infos nécessaires au gestionnaire. Et, globalement, la place nécessaire à la description du réseau dans le gestionnaire est la même.

@ Marc,

A la SNCF, il y a une analyse des possibilités d'un grill de voie d'une gare bien en amont et certains sont choisis et pas d'autres.
En plus, il y a une priorisation dans le cas où plusieurs itinéraires sont possibles d'un point à un autre.

Je distinguerai 2 types de gares :

1°) Les gares "biceps", c'est à dire les gares qui ressemblent à un biceps (par exemple celle de Dominique, voir schéma dans les posts précédents) où les itinéraires sont TOUS INCOMPATIBLES 2 à 2. C'est le cas le plus fréquent sur nos réseaux. C'est très simple à gérer puisqu'il n'y a pas de choix.
Il n'y a qu'une seule façon d'aller de Z25 à Z28. Et c'est pareil pour chaque grill d'entrée.
Ta gare est aussi dans ce cas (c'est un 1/2 biceps).

2°) Les gares qui possèdent plusieurs diagonales et, là, la question se pose de choisir tel itinéraire ou tel autre en priorité. Ma gare est dans ce cas. J'ai une vision particulière de ce cas en mettant des "poids" aux appareils de voie. Je ne souhaite pas développer ici. Je l'ai déjà fait il y a quelques années. J'y reviendrai le moment venu.

Après, on peut parler "d'itinéraires" qui vont d'un point A à un point B quelconques et, en particulier ceux qui traversent des gares.
Mon gestionnaire sera dans ce cas. Mais j'ai bien conscience que ça ne correspond à rien dans la réalité. C'est une extension de la notion d'itinéraire.
Et, là, évidement, il y a plein de priorisations à faire.

@ tous,

Je me pose des questions sur la numérotation des signaux.

Suivant l'auteur, j'ai 2 versions :
1°) les signaux pairs ont un numéro pair et les signaux impairs des numéros impairs.
2°) Les signaux de voies paires ont des numéros pairs et les signaux de voies impaires on des numéros impairs.
La notion de "voie" n'est, pour l'instant, pas dans le JSON.

Le 1°) est très facile à programmer.
La notion de "voie" ne sert pas dans le gestionnaire (à mon avis). Mais chaque signal a un nom (et donc un numéro) et s'il faut connaitre le nom de la voie pour attribuer un nom au signal, ça se complique...

Denis

[Dominique]

@Denis,
Je suis en train de parcourir l'ensemble de mon réseau avec ton éditeur.
D'abord il est facile de passer d'une zone aux voisines en cliquant sur la flèche à une extrémité : c'est un gros progrès de l'interface. Bravo !

J'ai "chargé" le fichier JSON du dossier d'entrée de Dominique (ou fallait-il charger le fichier de sortie ?)

J'ai quelques questions que je pose ci-dessous (si d'autres arrivent, je les ajouterai dans cette même réponse en mode correction):

1) les butoirs ne sont pas matérialisés sauf par le même numéro de zone que la zone concernée. On s'en rend compte en cliquant sur la flèche : ça ce fait rien. Ce qui fait que la flèche représentée à la place du butoir (et le champ de saisie de la zone voisine) ne servent à rien et pourraient être remplacés par un symbole de butoir.

2) la zone Z26 ne semble pas conforme à la réalité, l'aiguille a0 n'est pas représentée entre A et C (en fait elle coïncide avec le point A). Je comprend qu'on est pas dans une forme similaire à une TJD mais là c'est bizarre. Peut-être aurait-il fallu faire partir la pointe un petit peu plus loin du point À ? La matérialisation du “Y” aurait été plus claire.

Les méthodes dans mon gestionnaire sont actuellement :
Zone* Z26::suivantePaire() { return z25; }
Zone* Z26::suivanteImpaire() { return selonAiguille(a0,selonAiguille(a1,z27,selonAiguille(a3,NULL,z44)),selonAiguille(a2,NULL,z15)); }
à comparer avec :
"vois1" : [["Z25"]],
"vois2" : [["Z27","a0","gauche","a1","droite"],["Z15","a0","droite"],["Z44","a0","gauche","a1","gauche"],
Mais cette notation semble plus intuitive car elle décrit pour chaque voisin la combinaison d'aiguilles à traverser et leur orientation.

... je continue mes explorations...et je vais comparer avec les propriétés des zones codées en C++ dans mon code.
C'est très lent à cause de multiples sollicitations toutes prioritaires, mais je vais y arriver !
Bon courage

[DDEFF]

@ Dominique,

Je viens de sortir la V10 de mon programme qui tient compte des remarques de Pierre et les tiennes.
Il y a des points à éclaircir, visiblement.

Le but de ce programme est de créer un fichier JSON le plus petit possible tout en recueillant toutes les infos nécessaires à un gestionnaire. D'où quelques aller-retour avec Pierre sur les infos vraiment nécessaires et celle qui ne le sont pas.
Donc, le JSON qui était dans "Fichiers d'entrée Dominique" n'est pas le bon et, logiquement, je l'ai carrément supprimé.

Etape 1 : on fait un plan de réseau à la main avec des flèches pour connaitre le sens principal de circulation d'une section de voie.
Ton réseau a déjà été publié et je n'y reviens pas.
A ce moment, on n'a rien, aucun fichier, juste un dessin.

Etape 2 : on utilise mon éditeur graphique pour rentrer les infos descriptives du réseau en se conformant au dessin.
Petit à petit, un objet "Zone" se remplit avec toutes les infos qu'on a rentré.
En phase de développement, je sauve toutes les zones dans une table "Zones", mais elle disparaitra quand j'aurais terminé.
Il est quand même intéressant de comparer la table "Zones" dans les fichiers d'entrée et celle dans les fichiers de sortie.
On voit clairement que la table initiale est quasi vide car elle ne contient que les informations réellement rentrées par l'utilisateur.

Etape 3 : une fois que les infos manuelles sont rentrées, on appuie sur le bouton "Analyse" et, un peu plus d'une seconde après, toutes les cases nécessaires sont automatiquement remplies. La différence est assez impressionnante.

Etape 4 : En appuyant sur le bouton "Sauve", on sauve la table "Zones", celles des itinéraires, toutes choses nécessaires au développement, mais sans intérêt par la suite.
Et c'est aussi à cette étape qu'est généré le fichier JSON qui est, fondamentalement, un fichier texte, mais structuré.

Voyons maintenant tes questions :

J'ai fait un symbole "Butoir" à la place d'une flèche.

La Z26 n'est pas une TJD, mais est dessinée comme 2 aiguilles qui se suivent (il y a 2 moteurs). Il y a 2 versions : tripleG où la première aiguille est à gauche (Z29) et tripleD où la première aiguille est à droite (Z26)

Mais, effectivement, tu es en Fleischmann Picollo et ton aiguille triple est parfaitement symétrique, avec les 2 aiguilles l'une au dessus de l'autre.
Comme il y a 2 moteurs, on va dire que le premier moteur s'appelle a0 et il a 2 positions (gauche et droite) et le deuxième moteur s'appelle a1 et il a, lui aussi, 2 positions (gauche et droite).

Denis

[Dominique]

@Denis,
J'ai chargé cette fois le fichier de sortie "_JSON________.tsv" là je dois dire que j'ai parcouru tout le réseau conformément à ma représentation (image). Les zones s'affichent dans avec la bonne orientation (gauche/droite oui haut/bas). C'est très pratique à suivre.

Je t'envoie des remarques (que j'espère constructives) par mail.

Amitiés
Dominique

[DDEFF]

Voilà la V11

@ Dominique,

J'ai tenu compte de tes remarques :

1°) Quand on modifie quelque chose, l'analyse est plus précise, propose plus de choix, eux-mêmes plus faciles.

2°) Le bouton "Annule" est maintenant efficace et on a plus de 'x' pour sortir.

3°) La recherche d'itinéraires donne les résultats dans une fenêtre (ou plusieurs, si c'est long) et on a plus les cote 0 et 1, mais A et B, comme sur les dessins des sections.
A est l'origine et B l'extrémité. C'est pareil que sur le schéma initial.

Il reste 2 choses importantes à faire :

1°) Gérer les zones multiples

2°) Ne plus sauver le fichier Zones, ce qui impose de récupérer les infos directement dans le JSON, comme Pierre le fait depuis longtemps. Et ça resservira dans le gestionnaire.

@ Pierre,

Si j'ai bien compris, tu vas mettre le gestionnaire sur un processeur en C++ et continuer à gérer le TCO en Processing.
Et échange des infos via un "tuyau" ?

A suivre
Denis 

[Pierre59]

@ Denis

Si j'ai bien compris, tu vas mettre le gestionnaire sur un processeur en C++ et continuer à gérer le TCO en Processing.
Et échange des infos via un "tuyau" ?

Je préfère, et de loin, écrire et tester le gestionnaire en Processing.
De temps en temps il y aura une version en C++. Pour cette version j'utilise des tubes de communication juste pour communiquer avec le TCO en Processing. Ces tubes seront remplacés à terme par un ou des bus (CAN, …) pour une version sur micro-processeur.

Pierre

[DDEFF]

@ Pierre

Je préfère, et de loin, écrire et tester le gestionnaire en Processing.

Ah oui !! 

[Pierre59]

Dans les versions actuelles du gestionnaire json, lors de son initialisation le gestionnaire envoie un message approprié au TCO et d'un "coup de baguette magique" les aiguilles se retrouvent dans la bonne position et les trains dans leur positions initiales.

Bien évidemment avec un réseau réel cela ne peut pas se passer comme cela. Lors de son initialisation le gestionnaire à besoin de plusieurs informations :
- la position de toutes les aiguilles
- la connaissance de toutes les zones occupées, avec des infos sur les trains dedans
- éventuellement l'état des balises

Concernant la position des aiguilles, pour le gestionnaire, la solution idéale est de pouvoir obtenir leurs positions mais cela nécessite un dispositif approprié sur les moteurs d'aiguille, alternativement le gestionnaire peut positionner systématiquement toutes les aiguilles, mais cela pose problème pour les aiguilles des zones occupées où il y a normalement des trains.

Concernant les zones il est assez facile d'obtenir leurs états (libre ou occupé), mais quasiment impossible d'obtenir des infos sur les trains qui les occupent.

Pour les balises c'est un peu comme les zones.

Une solution partielle à tous ces problèmes consiste à sauvegarder les informations lors de l'arrêt "normal" du gestionnaire et de les reprendre lors de son redémarrage. Il reste quand même quelques problèmes :
- lors d'un arrêt "anormal" du gestionnaire (plantage, coupure de courant, …) les infos sauvegardées ne sont pas à jour
- des trains ont pu êtres enlevés ou ajoutés au réseau entre l'arrêt et le redémarrage du gestionnaire
- il faut pouvoir enlever ou ajouter un train pendant le fonctionnement normal du gestionnaire

Les sauvegardes peuvent se faire de différentes façons :
- avec un ordinateur ou un mini-ordinateur sur un fichier
- avec un micro-contrôleur sur carte SD ou en mémoire non volatile (eeprom) ou autre

Un dispositif de dialogue doit être mis en place pour les cas ne relevant pas des sauvegardes (ajouts de trains, …).

J'attends vos commentaires et vos suggestions.

Pierre

[Dominique]

Bonjour Pierre59,

Voilà un sujet fort intéressant 🤔 que je vais développer ci-dessous en ce qui me concerne.

Juste le temps de trouver le temps avec les petits enfants à la maison …

Donc me revoilà !

Concernant la position des aiguilles, pour le gestionnaire, la solution idéale est de pouvoir obtenir leurs positions mais cela nécessite un dispositif approprié sur les moteurs d'aiguille, alternativement le gestionnaire peut positionner systématiquement toutes les aiguilles, mais cela pose problème pour les aiguilles des zones occupées où il y a normalement des trains.

J'ai essayé ces deux méthodes :
1) mon circuit de commandes d'aiguilles reçoit les commandes du gestionnaire et envoie les positions des aiguilles  au gestionnaire du réseau via le bus Can. Il représente une seule entité sur le bus Can (une carte Mega). Au démarrage il peut envoyer toutes des positions des aiguilles qui correspondent alors aux positions des boutons de commande sur le TCO car il ne connait pas les positions réelles des aiguilles. Le TCO positionne alors toutes les aiguilles conformément aux positions des boutons à son initialisation. L’inconvénient comme le dit Pierre est qu’un train peut occuper une aiguilles à ce moment là et provoquer un court-circuit ou une déraillement. J’ai donc abandonné cette méthode.
2) mon gestionnaire de réseau définit une position de départ de toutes les aiguilles selon un état de départ du réseau idéal (les trains bien arrêtés dans les gares ou les voies de garage). Et il commande les aiguilles en conséquence via le bus Can et le Mega de commande d’aiguilles. En général ça correspond à la position des trains et des aiguilles quand on arrête le réseau, mais rien n’est garanti. En général les petits enfants aiment bien cette rêgle.

Concernant les zones il est assez facile d'obtenir leurs états (libre ou occupé), mais quasiment impossible d'obtenir des infos sur les trains qui les occupent.

En effet mon TCO manuel (leds d'occupations et de positions d'aiguilles) reflète les états des zones et transmet ces états au gestionnaire via Can.
Pour les identifications des trains c'est plus délicat.
Avec le recul et sachant maintenant qu'il est facile d'utiliser Railcom avec Labox (grâce à Lebelge2 et nous allons tester et valider cela), à condition de posséder des décodeurs compatibles ce qui devient le cas général, et de capteurs Railcom dans les zones les plus importantes (gares et certains zones importantes), la solution Railcom est la meilleure solution pour identifier les trains en association avec une description des trains (type, longueur, etc..).

En ce qui me concerne, n'ayant pas d'équipements Railcom, j'ai placé quelques détecteurs RFID dans les zones proches des gares et les trains équipés d'un timbre RFID (tous) sont détectés à leur passage.
Mais ce n'est pas aussi universel que Railcom car le RFID est un peu plus lent et certains trains ne sont pas détectés au démarrage du réseau.
J'avais essayé une technique de détection automatique des trains au démarrage qui reposait sur des détecteurs de présence peu sensibles (de telle sorte qu'un train à l'arrêt ne soit plus détecté, seuls les trains en mouvement étant vus). Cette technique consistait à faire bouger chaque trains, l'un après l'autre, en envoyant une commande de vitesse en avant ou plutôt en arrière, le temps de récupérer la détection de zone où il est, puis de l'arrêter, voire le faire repartir en sens inverse avec la même vitesse et le même temps de roulement.
En fait ça marche bien mais cela change beaucoup la gestion des occupations dans le gestionnaire et le suivi des trains.

En définitive, je me contente maintenant de faire rouler mes trains en mode manuel jusqu'à ce qu'ils soient détectés par une capteur RFID, ce qui initialise ou réinitialise le suivi du train. Je le vois lorsque le train s'arrête bien en gare ! Sinon je le laisse rouler encore un peu, il finit par être bien suivi. Mais mon algorithme de suivi des trains est plus compliqué.
Cette méthode s'applique aussi à la pose d'un nouveau trains. Le problème dans ce cas est que le nouveau train n'a pas de suivi correct avant son identification et son initialisation, ce qui perturbe un peu le reste du réseau. Je laisse les trains arrêtés en gare en attente par sécurité.
Pour le retrait, je n'ai pas de solution. Sauf a prévoir une interface quelque part.

Les sauvegardes peuvent se faire de différentes façons :
- avec un ordinateur ou un mini-ordinateur sur un fichier
- avec un micro-contrôleur sur carte SD ou en mémoire non volatile (eeprom) ou autre

En ce qui me concerne, j'ai banni l'ordinateur et je n'ai que des modules sur le bus Can.
Le plus simple serait l'enregistrement sur carte SD (quand elle est usée on en met une autre !).
Dans la foulée il est possible d'enregistrer d'autres données de suivi, de statistiques, de débugging qui peuvent être exploitées sur ordinateur par la suite.
Avec le bus Can, il y a plein d'autres possibilités.

Enfin, il reste le cas des itinéraires qu'il faut commander quelque part, sur le TCO en principe. Ces commandes peuvent résoudre quelques un des problèmes cités au dessus (pose et retrait de trains).

J'aurai d'autres commentaires plus tard...

[DDEFF]

@Pierre,

Beaucoup de questions très intéressantes.

Je distinguerai le cas normal du cas "plantage".

Il faut mettre en place une procédure simple de description d'un train :
- quelle loco (son ID dans une base locale) et son CV3 si on utilise le DCC.
- quels wagons/voitures. Un ID aussi qui, entre autres, donne la longueur qui sera nécessaire si on utilise des trains virtuels.
- La ou les zones occupées quand on pose un train.

On doit pouvoir mémoriser cette composition dans une base locale. C'est utile si on utilise souvent la même composition ou suite à un plantage.
En particulier, dans ce dernier cas, on doit pouvoir simplement dire "Composition ID xx sur les zones Zxx et Zyy".

Je pense qu'il n'est pas nécessaire de mémoriser sur un support externe la position des trains, ni en temps réel, ni à la fin d'une session où on retire les trains pour ne pas qu'ils se couvrent de poussière.

Concernant la position des aiguilles, il peut être utile de la mémoriser, à la fin d'une session, sur un support externe. Mais pas en temps réel.
On a ainsi, à l'allumage d'une nouvelle session, une position "plausible" des aiguilles au TCO.

Si on commande les aiguilles avec un moteur et une vis sans fin, la position reste stable et ne va pas bouger "toute seule". C'est aussi vrai pour une commande par servo.
Mais avec une commande par solénoïde, on n'a aucune garantie que la position mémorisée sera vraiment celle du terrain.

Dans mon gestionnaire, je raisonne comme dans les vrais trains, c’est-à-dire que le conducteur monte dans son train avec une feuille de route : il a toutes les étapes et sa destination.
J'impose à chaque train de choisir un parcours précis qu'il choisit au départ. Il y a donc la position de toutes les aiguilles.
Donc, soit au démarrage, soit suite à une panne, il faudra choisir un itinéraire, ce qui mettra les aiguilles dans la bonne position, même si elle est fausse au départ au TCO. On commencera évidemment, suite à une panne, par le train qui est à cheval sur des aiguilles.

En fait, ce qui pose problème, c'est de lancer un train sans destination précise et de modifier les aiguilles "à la volée". En effet, on se fie alors à la position affichée au TCO qui peut être fausse.
Et comme le gestionnaire raisonne sur la position au TCO, on ne peut pas éviter les accidents.

Denis 
PS : j'ai trouvé une solution pour le problème que tu as soulevé concernant les limites de garage franc.

[Dominique]

au cas où vous ne l'ayez pas vue, j'ai complété ma réponse plus haut !

J'ajouterai simplement que j'ai toujours privilégié les conduites manuelle en priorité sur les conduites automatiques :
- les commandes manuelles des aiguilles vs les commandes via les itinéraires
- les commandes individuelles des trains par potentiomètre vs les commandes d'arrêt et de ralentissements par le gestionnaire (le fait de toucher le potentiomètre relance le train à la consigne du potentiomètre - mais cela peut changer grâce à un paramètre de configuration).

rappel de mes modules :
Centrale DCC :

Commandes aiguilles et états zones et aiguilles :

Gestionnaire réseau : une simple carte DUE avec interface Can et le TCO graphique est encore en chantier (suite à la panne de l'écran graphique 5", l'occasion de passer en 7" - mais je rêve de trouver un superbe et grand écran OLED, provenant d'un tableau de bord de voiture).


En ce qui concerne la poussière, j'utilise du papier de soie (comme celui qui sert aux bouquets de fleurs) qui est très léger, pour couvrir mon réseau pendant les arrêts prolongés.
Une partie de mon réseau (devant la gare) se trouve au dessous d’un velux qui génère un grand nombre de cadavres d’insectes volants. L’aspirateur sert souvent.