Projet partagé d'un gestionnaire de réseau

[DDEFF]

Bonjour à tous,

J'ai avancé sur mon programme d'éditeur de JSON.
Construire un JSON "à la main" est tout à fait faisable, mais il faut bien maîtriser les subtilités de la SNCF et il faut décrire énormément de choses, ce qui est pénible et source d'erreurs.
Grâce à un programme qui automatise un peu les choses, on peut regarder les anomalies, les corriger et minimiser les saisies.

Dans mes premiers jets, les saisies étaient, à mon avis, lourdes.
Quant aux modifications, elles étaient  impossibles : on efface et on réécrit les données de la zone. C'est toujours le cas en ce moment, mais j'ai des pistes prometteuses concernant les modifications. Je verrais bientôt.

La signalisation :

Je m'intéresse à la signalisation depuis des dizaines d'années.
Aussi, automatiser une signalisation pour un réseau est un vrai challenge.
Disons-le tout de suite : on ne peut pas tout automatiser. Il faut quand même donner un minimum d'informations simples qu'un programme ne peut pas deviner tout seul.
Tout le problème consiste à rentrer vraiment très peu d'informations.
A noter que très peu de réseaux ont une signalisation et encore moins une signalisation fonctionnelle. C'est malheureux.
Mais on a aussi des réseaux qui font circuler des locos électriques sans caténaire…

Quelle signalisation ?

Suivant la période et la région concernée, il y a DES signalisations.
Chaque compagnie (avant la SNCF) avait sa signalisation, au départ mécanique puis lumineuse.
En 1936, on passe progressivement au code Verlant.
La création de la SNCF en 1938 entérine cette signalisation.
Je me limiterai donc à la signalisation lumineuse, postérieure à 1936 et antérieure au TGV qui a, lui aussi une signalisation tout à fait spécifique.

En fait, je procède par étapes :
 
Etape 1 : Le Locoduinodrome, même dans sa  version 2, est trop simple.
Je suis passé à un réseau que je connais bien et pour lequel j'ai un plan des zones, avec une signalisation complète, qui plus est, validée par Pierre il y a quelques années : le réseau de Dominique.
C'est d'ailleurs en rentrant toutes les zones dans mon programme que je me suis aperçu de la lourdeur de mon processus initial.
Par exemple, même si, à terme, on a besoin des limites de vitesse de chaque zone, ce n'est pas la peine de les rentrer dès le début. Ce sera donc dans un deuxième temps, en "complément" qu'on rentrera ces infos. Sans compter les incohérences possibles dans la saisie des vitesses.

Etape 2 : Décrire quasi automatiquement ce qu'est une gare et une zone de manœuvres.
C'est absolument nécessaire car il y a dans les gares et le zones de manœuvres une signalisation spécifique. J'en suis à cette étape

Etape 3 : En fait, on ne peut pas trouver quel signal est nécessaire si on n'a pas d'itinéraires.
Et, si on veut trouver les itinéraires dans une gare, il faut définir quels sont les zones qui la composent, avec les zones d'approche et de sortie, bien sûr. Dans un premier temps, on limitera les itinéraires aux gares.

Donc, voici ma démarche globale :

1°) Rentrer toutes les zones d'un réseau (nom des zones et des voisins)
     Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
     Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.
          -> Pour les traversées (croisements, TJS et TJD), on met la parité à "pairimpair"
          -> Pour les autres aiguilles, la parité de l'appareil de voie est la parité de son unique point commun avec un segment dont on connait la parité.
Il faudra peut-être pousser un peu plus loin le raisonnement pour la parité des appareils de voie.

2°) Définir comme "gare" quelques zones pour calculer la gare entière.

3°) Définir comme "manœuvres" une zone pour calculer la zone de manœuvres entière.

4°) Trouver tous les itinéraires de chaque gare.

5°) Rentrer les infos complémentaires de vitesse des segments de la gare, ce qui donnera les vitesses des appareils de voie, branche par branche, en évitant les erreurs et les incohérences.
En déduire la signalisation correspondante.

Démarche pour définir une gare (voir le fichier gare) :

J'ouvre une ArrayList : "zones_gare" qui va collecter toutes les zones d'une seule gare, au fur et à mesure que le programme parcourt toutes les zones.

Une fois les zones rentrées, je déclare Z3 "gare", ce qui met "g0" dans le champ "gare" de la zone Z3.
Puis la recherche systématique commence. Elle est détaillée dans le fichier joint.

En ayant rentré une seule zone, on a décrit toute la gare.

Evidemment, cet exemple est très simple.
Il est basé sur le principe suivant : dans une gare, il n'y a jamais deux segments voisins.

Dans cette gare, il permet, à la fois, d'exclure Z0 et Z7 de la gare et de déclarer Z1 zone d'approche et Z6 zone de sortie.

Dans la gare de Dominique, ce seul principe ne suffit pas. Ça serait trop beau !

Il y a 2 gares : g0 au sud et g1 au nord.
On doit rentrer un segment dans g0 : j'ai choisi Z27
On doit rentrer 2 segments dans g1 (un pour le haut de la gare, un pour le bas car il n'y a pas de communication entre le haut et le bas de la gare g1) : j'ai choisi Z4 et Z22.
On n'a pas à s'occuper de la partie droite du schéma car on y trouve 2 segments consécutifs.
Z11 est une zone d'approche de g0, mais pas Z30
Z34 est une zone d'approche de g1, mais pas Z7
Pour la partie gauche, on ne peut pas utiliser le principe puisqu'il n'y a qu'une zone entre les deux gares et on aboutirait à une seule et unique gare.
Il faut donc préciser "à la main" les informations :
Z25 est la zone d'approche de g0 et Z16 est la zone d'approche de g1.
Les infos rentrées à la main sont prioritaires sur les infos crées par le programme.

Les zones de manœuvre :

Dans le réseau de Dominique, il y a aussi des zones de manœuvre. Et, si on n'y prenait pas garde, elles seraient, elles aussi, ajoutées aux gares, ce qui serait une erreur.
Il faut donc bloquer le processus en rentrant "bloque" dans les zones Z36, Z45, Z46 pour g0 et dans Z2 pour g1.

Maintenant, il faut décrire les zones de manœuvre.

A noter une chose importante : sauf cas particulier, on rentre dans la zone de manœuvre en marche arrière et on en sort en marche avant.

C'est le même principe que pour les gares, à ceci près qu'il n'y a pas besoin de bloquer, la gare s'en charge et, aux autres extrémités, tous les butoirs arrêtent le processus de recherche de zones.
On définit donc Z36 et Z37 où on rentre m0 dans le champ "manœuvres" des zones.
La dernière chose à définir, ce sont les zones d'approche des zones de manœuvres.
Là, je ne vois pas d'automatisation possible : il faut les définir à la main dans Z30 et Z16, champ "manœuvre". A noter, peut-être une piste : Z30 et Z16 sont les zones de sortie de la gare et je pense que ça n'est pas un hasard.

Résumé :

En rentrant 13 informations simples, on remplit 37 cases sans erreurs !

Fichiers joints :

https://www.locoduino.org/IMG/zip/editeur_json4.zip

Dans le .zip, on a ma dernière version du programme Processing, avec la création des gares et des zones de manœuvre. Mais je n'ai pas fait la partie "entrée des infos gare/manœuvre" : je les rentre directement dans le fichier Excel. C'est la prochaine chose que je vais faire. C'était juste pour tester le fonctionnement.
On ne pose plus de questions pour les vitesses dans la première phase, mais il faudra poser les questions dans les "compléments". A réaliser, donc
Je vais aussi ajouter la possibilité de modifier les informations dans une zone.
Les fichiers Excel décrivant les zones (avant et après) sont dans le .zip

Il y a aussi le fichier détaillé du processus de définition d'une gare.
Et, évidement, le plan du réseau de Dominique (toutes mes excuses pour cet oubli)

Denis

[Dominique]

Bonjour Denis et à tous,

Ce travail d'analyse est très interessant et je suis en train d'analyser la nouvelle application (4) et tes explications.

Il y a maintenant la possibilité d'ouvrir un fichier description existant. Ca c'est super ! Le travail est sauvegardé.

Merci pour les 2 réseaux : le Locoduinodrome 2 et mon réseau de Dominique.

Ca tombe bien, je suis en pleine reconstruction de mon TCO graphique-tactile sur écran 7 pouces. Ce TCO reprend exactement les mêmes objets zone et aiguilles que mon gestionnaire. En particulier les méthodes "suivantePaire" et "suivanteImpaire", avec la méthode

Code: [Sélectionner]

inline GZone* GZone::selonAiguille(GAiguille* a,GZone* z1,GZone* z2) { return a->directe()?z1:z2; }
je vais attendre la mise au point avant d'ajouter les signaux.

Toutefois je constate dans mon réseau qu'il y a quelques cas où un voisin passe par les conditions de 3 aiguilles et pas seulement 2  comme dans le fichier JSON :

Code: [Sélectionner]

GZone* GZ6::suivantePaire() {
  return selonAiguille(Ga16, selonAiguille(Ga13, NULL, Gz39), selonAiguille(Ga15, NULL, Gz2));}ou

Code: [Sélectionner]

GZone* GZ26::suivanteImpaire() {
  return selonAiguille(Ga0, selonAiguille(Ga1, Gz27, selonAiguille(Ga3, NULL, Gz44)), selonAiguille(Ga2, NULL, Gz15));}
Je pense qu'il sera possible d'importer aussi le fichier JSON dans le TCO comme dans le gestionnaire. Cela se fera en C++ avec l'IDE Arduino mais je ne vois pas encore comment l'intégration se fera. Patience !

Cela me permet dors et déjà de voir les chemins possibles en fonction des positions des aiguilles à partir de n'importe quelle zone du réseau.
Je vais écrire aussi les calculs d'itinéraire entre 2 zones départ et arrivée qui définira les position d'aiguilles nécessaires.

Ce sera alors un bel outil de tests du travail que tu fais avec Pierre.

Mais le but du gestionnaire reste le suivi des trains et la sécurité (ralentissements, arrêts avant zone occupée) avec des moyens de pilotage soit manuels soit automatiques. Donc la prise en compte des messages Can des détections (présence par consommation de courant, RFID et RailCom, bien que n'ayant pas de Railcom sur mon réseau). L'intégration des réceptions des messages Can dans le gestionnaire est une des tâches les plus intéressantes et délicate, ainsi que les commandes des trains (ralentissements, arrêts et redémarrages automatiques qui donnent un vrai réalisme au réseau).

Je suis cependant un peu étonné du petit nombre de modélistes qui ont déclaré utiliser le gestionnaire de Pierre.
Si un lecteur de ce sujet se sent visé, ce serait très sympa de nous en toucher quelques mots, simplement.

[DDEFF]

Bonjour,

Voici la version 5 de mon éditeur JSON.
De nombreux changements et l'occasion de faire le point, après 25 pages sur ce fil…

Pourquoi un éditeur JSON ?

Le but de ce programme est de simplifier au maximum la saisie d'informations, d'en vérifier la cohérence et d'automatiser tout ce qui peut l'être.

Le fichier important, c'est le fichier JSON puisqu'il fait le lien avec un futur gestionnaire de réseau.
On doit avoir la séquence suivante :
Editeur JSON --> fichier JSON --> gestionnaire de réseau.

Il est tout à fait possible que d'autres réalisent un éditeur JSON, à condition que le résultat soit un fichier identique, quel que soit l'éditeur. En particulier, mon éditeur graphique (en cours de développement) devra fournir un fichier JSON.
De la même manière, tous les gestionnaires de réseau devraient être compatibles JSON.
On évitera ainsi à celui qui veut faire un gestionnaire toute cette phase rébarbative concernant l'entrée des infos du réseau.

Remarque 1 :
Comme l'éditeur et le gestionnaire ne sont pas complets, la version que je vais présenter est encore susceptible d'évolutions.

Remarque 2 :
Ce programme qui décrit un réseau est sensé ne servir qu'une fois…

Un deuxième fichier est généré par le programme, le fichier "Zones". C'est juste en phase de développement, je pense qu'il n'a pas d'avenir. C'est juste un "fourre-tout" qui permet de conserver des infos pendant le déroulement du programme.

Signalisation :

La signalisation SNCF, même réduite aux cas les plus fréquents, reste une partie complexe puisqu'une fois compris le cas de la pleine voie, on doit tenir compte de la position des aiguilles , des vitesses sur les appareils de voie et même de la longueur des zones pour prévenir que le canton suivant est plus court que d'habitude et qu'il faudra en tenir compte pour freiner.
Il s'ensuit que pour calculer tout ce que peut afficher un signal, il faut d'abord avoir défini les itinéraires possibles.

J'en suis donc actuellement à cette étape dans laquelle je vais pouvoir "récupérer" ce que j'avais fait pour mon gestionnaire.

Itinéraires :

En phase de développement, donc, et je propose de n'indiquer dans le JSON que les itinéraires des gares. C'est d'ailleurs pour ça que j'ai passé du temps à définir quelles zones sont des zones de gare. Idem pour les zones de manœuvre.

Les itinéraires vont aussi servir dans le gestionnaire, évidemment, mais avec une contrainte de temps, ce qui n'est pas le cas ici.

Il y a deux fonctions chronophages dans la gestion des itinéraires :
1°) quelle est la zone suivante ?
2°) par quel côté j'aborde la zone suivante ?

J'ai décidé de répondre à ces questions directement dans le JSON.
J'ai adapté mon programme pour qu'on ait un traitement unique de tous les éléments de voie.

De la "même" façon que la Marine a pris la règle de "tribord, bâbord" pour qu'il n'y ait pas d'ambiguïté entre la gauche et la droite sur un bateau, la SNCF parle de "pair" et "impair", ce qui permet de gérer "gauche, droite, haut, bas, …" dans les dessins et le sens de circulation.

Pour indiquer les voisins, les "côtés" d'une zone, j'utilise des règles suivantes :

Cas des segments :

Je décrète que l'on parcoure l'octogone au départ (qui permet de définir l'orientation du segment à afficher) dans le sens des aiguilles d'une montre quand on est dans le sens "pair". Et, par conséquent, on est dans le sens impair dans l'autre sens.
Dans les dessins, comme il y a des lettres (A, B), on parcoure toujours un segment en allant de A vers B, de l'origine à l'extrémité.
Quand il n'y a un signal qu'à un bout, il est toujours du côté extrémité, c’est-à-dire B. Dans les boucles, on préfèrera les chiffres : on va de 0 à 1, mais ça, ça n'apparait pas sur le dessin.
Par ailleurs, l'origine est toujours du côté "voisin1" "côté0" du segment et l'extrémité est toujours du côté "voisin2" "cote1" du segment.

Cas des appareils de voie :

Il y a 2 types d'appareils de voie :

1°) ceux où il y a une extrémité commune à tous les trajets :
On part toujours de A, l'extrémité commune, et on va vers B, C, D.
A est côté "voisin1" "cote0" de l'appareil.
B, C et D sont, respectivement côté "voisin2", "cote1", "cote2" et "cote3"

2°) ceux qui sont des traversées (croisement, TJD, TJS)
A est côté "voisin1" "cote0",
B est côté "voisin2" "cote1",
C est côté "voisin1" "cote2",
D est côté "voisin2" "cote3".

L'intérêt de cette notation est que quand on rentre dans une zone du côté "voisin1", on en ressort du côté "voisin2". Et réciproquement. Et on peut facilement tester toutes les extrémités en allant de 0 à 4.
Pour être précis, de 0 à "zone.nb_voisins" :
3 pour les aiguilles et les enroulés,
4 pour les croisements, TJD, TJS et triples.

Exemple pour la zone 15 du plan de Dominique :
Je vous conseille d'imprimer le fichier "Z26 et ses voisins" pour mieux suivre.
 
Z26 est impair car Z25 est impair
vois1 est le voisin du côté A du triple. Donc, le vois1 est Z25.
Et, vu de Z25, Z26 est du côté B du segment. Donc vois2, côté 1.
C'est plus compliqué pour vois2 puisque ça dépend de la position des lames :
Côté B, le voisin est Z27, si a0 est à gauche et a1 est à droite
Et, vu de Z27, Z26 est du côté A du segment, soit vois1 côté 0.
Côté C, le voisin est Z15, si a0 est à droite.
Et, vu de Z15, Z26 est côté A de la TJD, soit vois1 côté 0.
Côté D, le voisin est Z44, si a0 est à gauche et a1 à gauche.
Et, vu de Z44, Z26 est du côté C de l'aiguille, soit vois2 cote 2.

Pour la suite, les itinéraires n'étant pas faits, les signaux ne sont pas remplis.

A suivre.
Denis

[Dominique]

Merci Denis, gros travail !

Je vais essayer de comprendre mon réseau et rapprocher le JSON des suivantesPaire et suivanteImpair du programme.

[Etienne66]

@Denis,
Tu dis :
     Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
     Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.

Tu te trompes sur la position des signaux. Un signal n'est pas sur un bloc, qu'il soit segment ou appareil de voie, mais à la jonction de deux blocs.

Il faut décrire ce qui est utile pour le gestionnaire.
Le gestionnaire a besoin d'avoir :
- la liste des blocs avec l'adresse du détecteur de courant.
- la liste des aiguillages avec l'adresse du décodeur et/ou de la rétrosignalisation de position
- la liste des signaux avec le type de cible, la direction pair/impair, le bloc en amont, le bloc en aval, et la ou les adresses de décodeurs

Jusque là c'est une description très simple.
La partie plus complexe ce sont les cantons. Un canton c'est une série ordonnée de 1 ou plusieurs blocs entre un feu de départ et un feu d'arrivée.
Il peut contenir une série ordonnée de un ou plusieurs appareils de voie dont on précisera la position directe ou déviée, et convergente/divergente.

Pour une gestion simplifiée des feux  avec uniquement des feux de type BAL ou des carrés géré comme des BAL on n'a pas besoin de plus d'informations.

Pour une gestion prototypique des feux on a besoin des itinéraires des trains.
En effet dans ce cas on ne doit ouvrir un carré que si on a réservé le canton pour un train, ce qui suppose qu'on sait où il va.

Pour les manoeuvres c'est plus complexe. L'idée qui vient à l'esprit en premier, c'est de définir un canton comme zone de manoeuvre.
Le problème c'est que ça marche pour un tiroir ou toute autre voie sans issue mais pas pour une sortie de gare jusqu'au tableau LM.
Dans ce cas il faudrait définir la marche en manoeuvre dans l'itinéraire d'un train et changer le type de canton à la volée.
Mais on peut utiliser une astuce (géniale ) pour contourner le problème :
Il suffit de définir un tiroir virtuel (donc un nouveau bloc) avec un aiguillage virtuel et le bloc virtuel utilisant le même détecteur de courant que le bloc réel.
Et on rajoute un (ou plusieurs) canton de manoeuvre qui va vers le tiroir virtuel.
On rajoute un carré violet virtuel à chaque butoir et la logique des feux devient simple : si le feu suivant est un violet on ouvre le blanc, sinon c'est vert ou jaune.
Le tiroir virtuel va également résoudre le problème du carré nain de retour qui doit être ignoré par les trains en ligne. Le carré est simplement mis sur le tiroir virtuel.

[DDEFF]

Merci Etienne,

Je reconnais que l'idée du tiroir virtuel me plait, en particulier pour gérer le feu nain et la vitesse à 15 km/h maxi pendant toute la manœuvre.

Je n'en suis pas encore là. Je cherche à calculer les itinéraires car il est hors de question d'en donner la liste à la main.
Je sais le faire dans mon gestionnaire, mais, là, il faut que j'adapte.

Denis

[trimarco232]

Bonjour,
Denis , il y a peut-être une chose qu'il convient également de prendre en considération , suffisamment en amont , c'est les voyants du TCO , je pense notamment à ceux qui montrent l'itinéraire , et l'occupation des zones (il me semble que tu sais bien ce que c'est) : pourquoi ?
je finalise actuellement le 4ème poste d'aiguillage analogique & TCO pour le club ; sur le TCO il y a des boutons poussoirs et des LEDs ; pour simplifier le travail de l'arduino (PRO MICRO = uno , faible puissance) , tout est fait par des tableaux , saisis manuellement ;
il y a 16 boutons et 18 aiguillages , (TCO de taille moyenne) , cela fait quand-même 35 itinéraires , dont certains peuvent comporter jusqu'à 14 LEDs , parmi les 72 LEDs des voies du TCO ; cela oblige à saisir un tableau de 35 * 14 =  490 items , qui sont soit 0 , soit une des 72 LEDs : c'est fastidieux , donc je pense qu'il serait bien que cette tâche puisse également être automatisée , si tu vois ce que je veux dire ...

[DDEFF]

@trimarco232,

Quand on me pose une telle question, c'est un réflexe : peux-tu donner le plan de ta gare ?

Bon, quand le programme calcule les itinéraires, il fournit évidemment la liste des zones concernées et la position des aiguilles.
La mettre sous forme d'un tableau est tout à fait envisageable, ça n'est pas le plus dur, et de loin.

Cela dit, il va bien falloir rentrer toutes les zones dans mon programme : c'est un peu fastidieux aussi 
Pour information, rentrer le Locoduinodrome 2 me prenait 4 minutes (je l'ai fait plein de fois, pour le développement)
Pour la gare de Dominique, ça m'a pris un peu moins d'une heure.
L'intérêt d'un programme, c'est d'automatiser certaines choses et, surtout, de vérifier les incohérences.

Denis

[trimarco232]

pour illustrer , le tableau des LEDs en fonction de l'itinéraire :

Code: [Sélectionner]

#define leds_iti  (1 + 14)// 1 + nombre max de leds dans l'itinéraire
// la 1ère colonne donne le nombre de leds dans le chenillard
// les leds hors chenillard (aiguilles protégeante) sont à ajouter à la fin
const uint8_t led_iti[itis * leds_iti] PROGMEM = { /// protégeantes à revoir /// problématique du sas ?
  // ↓ iti       ↓nb   1       2       3       4       5       6       7       8       9       /*-*/   10      11      12      13      14 <- led
  /*  h6_sa  */  5,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_n,  /*-*/   d_h3n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  0
  /*  h5_sa  */  5,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_n,  /*-*/   d_h3n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  1
  /*  h4_sa  */  4,  d_h4,    d_h4a,   d_h4n,  d_s_n,  /*-*/   d_h3n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  2
  /*  sa_th  */  3,  d_s_n,   d_t_n,   d_th,   /*-*/   d_s2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  3
  /*  h6_th  */  9,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_h3n,  d_s3n,  d_e1n,  o_,     o_,     //  4
  /*  h5_th  */  9,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_h3n,  d_s3n,  d_e1n,  o_,     o_,     //  5
  /*  h4_th  */  8,  d_h4,    d_h4a,   d_h4n,  d_s_r,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_h3n,  d_s3n,  d_e1n,  o_,     o_,     o_,     //  6
  /*  h3_th  */  8,  d_h3,    d_b3n,   d_h3a,  d_h3n,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_b2n,  d_s_n,  d_s3n,  d_e1n,  o_,     o_,     //  7
  /*  h2_th  */  7,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3r,  d_s2r,  d_th,   /*-*/   d_b3n,  d_p_r,  o_,     o_,     o_,     o_,     o_,     //  8
  /*  h1_th  */  8,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3r,  d_s2r,  d_th,   /*-*/   d_p_r,  o_,     o_,     o_,     o_,     o_,     //  9
  /*  tp_th  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3r,  d_s2r,  d_th,   /*-*/   o_,     o_,     o_,     o_,     o_,     o_,     //  10
  /*  h6_hd  */ 10,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  d_s3n,  d_e1n,  o_,     //  11
  /*  h5_hd  */ 10,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  d_s3n,  d_e1n,  o_,     //  12
  /*  h4_hd  */  9,  d_h4,    d_h4a,   d_h4n,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  d_s3n,  d_e1n,  o_,     o_,     //  13
  /*  h3_hd  */  9,  d_h3,    d_b3n,   d_h3a,  d_h3n,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_b2n,  d_s_n,  d_t_n,  d_s3n,  d_e1n,  //  14
  /*  h2_hd  */  8,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3r,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_b3n,  d_p_r,  d_t_n,  o_,     o_,     o_,     //  15
  /*  h1_hd  */  9,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3r,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_p_r,  d_t_n,  o_,     o_,     o_,     //  16
  /*  tp_hd  */  9,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3r,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  o_,     o_,     o_,     o_,     //  17
  /*  h6_hm  */ 10,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,  /*-*/    d_p_r,  d_t_n,  o_,     o_,     //  18
  /*  h5_hm  */ 10,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,  /*-*/    d_p_r,  d_t_n,  o_,     o_,     //  19
  /*  h4_hm  */ 10,  d_h4,    d_h4a,   d_h4n,  d_s_r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,  /*-*/    d_p_r,  d_t_n,  o_,     o_,     //  20
  /*  h3_hm  */  9,  d_h3,    d_b3n,   d_h3a,  d_h3n,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_b2n,  d_s_n,  d_p_r,  d_t_n,  o_,     //  21
  /*  h2_hm  */  8,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3r,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_b3n,  d_p_r,  d_e2n,  d_s1n,  o_,     o_,     //  22
  /*  h1_hm  */  9,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3r,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_p_r,  d_e2n,  d_s1n,  o_,     o_,     //  23

  /*  tp_hm  */  9,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3r,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_e2n,  d_s1n,  o_,     o_,     o_,     //  24
  /*  h3_se  */  5,  d_h3,    d_b3r,   d_h2a,  d_h2r,  d_s3n,  /*-*/   d_p_r,  d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  25
  /*  h2_se  */  5,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3n,  /*-*/   d_p_r,  d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  26
  /*  h1_se  */  6,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3n,  /*-*/   d_p_r,  d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     //  27
  /*  tp_se  */  6,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3n,  /*-*/   d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  28
  /*  se_hm  */  2,  d_e1n,   d_hm,    /*-*/   d_s1n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  29

  /*  tp_p1  */  7,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1n,  d_p1a,  d_p1,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     o_,     //  30
  /*  tp_p2  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1r,  d_p2a,  d_p2r,  d_p2,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     //  31
  /*  tp_p3  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1r,  d_p2a,  d_p4n,  d_p3,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     //  32
  /*  tp_p4  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1r,  d_p2a,  d_p4r,  d_p4,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     //  33
  /*  h3_h2  */  3,  d_h3,    d_b3r,   d_h2a,  /*-*/   o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_      //  34

} ;

et le dessin :

[DDEFF]

Waouhh !
Voilà une gare comme je les aime : commandée de façon "géographique", avec quelques itinéraires compatibles.

J'en suis à refaire marcher mes itinéraires dans le nouveau contexte. Chaque chose en son temps. Mais je testerai ta gare, c'est sûr.
C'est une gare terminus, apparemment ?

Denis

[trimarco232]

oui , c'est une gare terminus , mais c'est en analogique , donc à priori , il n'y a pas d'itinéraires compatibles , sauf cas particuliers : par exemple la voie TEP est commutable par relais , soit sur l'alim analogique du reste de la gare , soit sur l'alim des voies EP1 à EP4 ; c'est en fonction des itinéraires formés que l'arduino commute par relais , les alims analogiques , et également coupe l'alim des voies non prises dans un itinéraire ; ce dernier point permet de garer des trains sans avoir à utiliser d'interrupteur

[DDEFF]

@trimarco232

La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.

Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.

Denis

[CATPLUS]

Bonsoir,

Ci-joint une photo de mon TCO (juste pour le fun) aucun rapport avec votre sujet 
A droite j'ai fait un affichage (avec un UNO) via un écran tactile avec les directions (rien d'automatique sur les voies)
Face 1 affichage des directions, après le choix, sur la face 2 affichage des inters à bouger (voir photo)
J'ai affiché une lettre sur le TCO, je clique sur la direction choisie de l'afficheur, ensuite je bouge les interrupteurs (c'est ma façon de m'amuser)

Cordialement
Marcel

[DDEFF]

Merci Marcel,

Il est clair que tu aimes les trains américains : ton TCO est vraiment typique des USA.
On s'éloigne un peu du sujet, mais on pourra y revenir un peu plus tard.

Denis

[trimarco232]

@trimarco232

La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
certes , mais en analogique , il faut une alim traction dédiée à chaque itinéraire compatible , j'ai restreint pour éviter ça
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.
c'est pour cela que je planche sur ça https://forum.locoduino.org/index.php?topic=1601.0
et donc pour ça que je suis ce que tu fais , car il me faudra quelque chose pour le piloter , tout en haut

Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.
mon principe perso , c'est de banaliser tout le réseau , et d'ailleurs d'avoir tout en VU , pour économiser de la place

Denis