Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - DDEFF

Pages: 1 ... 3 4 [5] 6 7 ... 55
61
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 10, 2025, 05:23:06 pm »
POST DU 10/03/25 PARTIE 2/2

BRETELLES :

Les appareils de voie sont commandés par de moteurs, mais, dans certaines configurations, la position d'une aiguille entraîne obligatoirement la position d'une autre aiguille sous peine de déraillement. Ce sont les bretelles. Elles permettent donc des gains en câblage et en sécurité.
Exemple de bretelle :



Contrairement aux apparences, le problème de les détecter automatiquement n'est pas simple.
Les aiguilles, dans une bretelle, sont opposées par leurs talons. C'est obligatoire.
Souvent, elles sont reliées par leurs voies déviées, comme dans l'exemple ci-dessus, mais elles peuvent aussi être voie directe - voie déviée, avec une aiguille droite et une aiguille gauche :



On peut aussi avoir un élément droit dans la bretelle :



Et c'est là qu'on apprécie les joies de l'informatique…
On cherche : "Des aiguilles, opposées par leurs talons, avec la possibilité d'une aiguille droite et d'une aiguille gauche et possibilité d'éléments droits ou courbes entre les talons des aiguilles".
Et on tombe sur ça :


 
Qui est tout, … sauf une bretelle !
Il manque donc un autre paramètre : la longueur des éléments, indispensable ici !

C'est pareil pour une bretelle double.
Il y a tout un monde entre ça :


 
Et ça :


 
Et pourtant, le schéma est le même !
Donc, il faut tenir compte des longueurs dans la détermination automatique des bretelles.
Il y a donc, dans mon programme, une longueur maxi (L_MAXI dans le setup) qui permet de bien définir les bretelles.
A noter que le branchement simple est le seul appareil de voie possible dans une bretelle pour la bonne raison qu'il n'a pas de moteur (cas de la bretelle double).
Dans une bretelle, il ne peut y avoir que 2 aiguilles.
Il s'ensuit que les appareils impliqués sont : les aiguilles, l'une des aiguilles d'une TJS, l'une des aiguilles d'une TJD à 2 moteurs, une aiguille triple.
Il n'est pas possible d'avoir une TJD à un seul moteur dans une bretelle.
Une bretelle, c'est le plus simple des super appareils (voir ci-après).

SUPER APPAREIL :

On a diminué le nombre de zones en créant des zones multiples.
On peut aussi diminuer le nombre de positions à étudier en regroupant les moteurs des appareils de voie des bretelles.

1°) Les bretelles simples :

Deux aiguilles, c'est 2 x 2 positions possibles. Mais comme les deux aiguilles sont liées, il n'y a que 2 positions à étudier : la position "bretelle" et la position "non-bretelle".
On n'a plus qu'un seul super appareil, composé des 2 aiguilles, et seulement 2 positions pour ce super appareil.
On remarquera que, dans une bretelle simple, les deux aiguilles sont dans la même position.


           
Ex : a0 droite et a1 droite pour la bretelle, a0 gauche et a1 gauche pour les voies parallèles, c’est-à-dire "non bretelle".
Donc, la définition d'une bretelle peut se simplifier :
"Br0" : a0, a1, droite.
La position "non-bretelle" peut s'écrire "Br0-" sans qu'on ait besoin de la décrire dans le JSON (Ce serait Br0- : a0, a1, gauche).
Dernière remarque :
Il n'est pas besoin de décrire une section qui serait entre les 2 aiguilles (une section n'a qu'une position)

2°) Les bretelles doubles :


 
Dans une bretelle double, il y a 5 appareils de voie. On n'oublie pas, en effet, la traversée centrale composée d'une "aiguille virtuelle", amenant 2 alimentations potentielles, elles bien réelles, en fonction de la bretelle choisie. Soit 32 positions potentielles et seulement 3 positions possibles.
Br0 : a0, a3, droite, a4
Br1 : a1, a2, gauche, a4
La description de la bretelle reste la même que la bretelle simple, mais, ici, on indique aussi la traversée simple en fin de description, sans donner sa position puisqu'elle est identique à celle des aiguilles.
Les 3 positions sont les suivantes :
- position 0 : Br0, Br1-, a4
- position 1 : Br0-, Br1, a4
- position 2 : Br0-, Br1-
En position 1, a4 est à droite par Br0 et à "non-gauche" = droite par Br1- : il est donc à droite.
En position 2, a4 est à "non droite" = gauche par Br0- et à gauche par Br1- : il est donc à gauche.
En position 3, a4 n'est pas concerné.
 

 
Mais attention, super appareil ne veut pas dire une seule zone : la bretelle double ci-dessus a bien 7 zones de détection de présence.

3°) Aiguilles triples. Exemple dans le réseau de Dominique :


 
Z29 est une aiguille triple, décomposée ici en 2 aiguilles consécutives : a9 et a11.
Dans la pratique, il y a 3 aiguilles à gérer ici, soit, à priori 2 x 2 x 2 = 8 possibilités.
Il y a bien une bretelle Br0 : a8, a11, gauche, mais elle ne fonctionne que si a9 est à gauche.
Donc il n'y a que 3 positions qui aient un sens :
- Position 0 : Br0, a9 gauche.
- Position 1 : Br0-, a9 gauche
- Position 2 : Br0-, a9 droite.
Il peut paraître surprenant, quand a9 est à droite, que la position de la bretelle intervienne, mais c'est nécessaire à la sécurité : si a9 est à droite, on ne peut pas envoyer un train venant de a8 vers la bretelle.
Autre exemple, dans le réseau de Dominique complété pour essais :


 
Z26 est une aiguille triple, décomposée ici en 2 aiguilles consécutives : a0 et a1.
Br0 : a0, a2, droite
Br1 : a1, a51/0, gauche
Les 3 positions sont :
- Position 0 : Br0, Br1-
- Position 1 : Br1, Br0-
- Position 2 : Br0-, Br1-

4°) Toujours dans le réseau de Dominique, une bretelle avec aiguille commune. Ici a16.


 
Il y a 3 aiguilles, donc 8 positions et, en fait, seulement 2 utiles :
- Position 0 : Br0, Br1-
- Position 1 : Br1, Br0-
On a la liste exhaustive de tous les super appareils possibles :
Bretelle, bretelle double, triple 1 et triple 2, aiguille commune.

LISTES D'APPAREILS DE VOIE :

C'est le moment de faire le point sur les différentes listes consacrées aux appareils de voie.

1°) On a une liste de tous les appareils de voie :
            "a0" : {
                    "nom" : "a0",
                    "type" : "TripleSDa",
                    "no" : 0
            },
Qui se lit : l'appareil a pour nom "a0", il est du type "aiguille triple symétrique à droite côté A", c'est le 1er appareil de la liste des appareils et a pour identifiant le numéro 0.

Rappel 1 : Une aiguille triple a sa première aiguille en partant de la pointe à droite et la suivante à gauche dans le cas d'une "TripleD" et sa première aiguille en partant de la pointe à gauche et sa suivante à droite dans le cas d'une "TripleG".
Si, en plus, elle est d'apparence symétrique, il y aura TripleSD et TripleSG.
La 1ere aiguille est côté A et la deuxième côté B.

Rappel 2
: Une aiguille ayant toujours 2 positions ("gauche" et "droite"), ce n'est pas la peine de l'indiquer dans le JSON.

2°) Une liste des bretelles :
            "Br0" : {
                    "nom" : "Br0",
                    "position" : ["a0","a2","droite"],
                    "no" : 0
            },
Qui se lit : Bretelle 0, position a0 et a2 à gauche, identifiant numéro 0.
L'autre position n'est pas décrite et s'appellera "Br0-".
Là, les positions sont décrites car spécifiques au réseau. On voit aussi pourquoi le nom d'une aiguille ne doit pas démarrer par "Br".

3°) Une liste des super appareils :
            "Su0" : {
                    "nom" : "Su0",
                    "positions" :  [["Br0", "Br1-"], ["Br0-", "Br1"], ["Br0-", "Br1-"]],
                    "no" : 0
            },
Là, les positions sont décrites car spécifiques au réseau. On voit aussi pourquoi le nom d'une aiguille ne doit pas démarrer par "Su".
 
BALISE :

On a considéré que la détection de présence dans une zone se fait par consommation de courant. C'est le système le plus performant. Mais il suppose de nombreuses coupures de rails.
Il existe aussi des détections de présence ponctuelles (ILS, infra rouge, capteurs à effet Hall…) et on les appellera des balises.
Mon programme ajoute systématiquement une balise (notée Bs) à chaque signal. Ce système sert pour garantir un arrêt devant un signal à un point précis.
Le programme ajoute aussi systématiquement une balise (notée Bb) avant un butoir pour garantir l'arrêt.
Je n'ai pas géré le cas de balises isolées (passage à niveaux, tunnels, panneaux "S", …), mais on pourrait définir une méthode pour en ajouter.

LONGUEURS :

Il est indispensable de connaitre la longueur de chaque zone. Par défaut, la longueur d'une zone sera de 999 mm dans mon programme.
Par ailleurs, il faut que des sections de longueur nulle existent pour "affecter" un signal à un appareil de voie.
De plus, certains signaux (jaune clignotant, rouge clignotant, blanc clignotant) sont liés à la longueur de la zone.
Enfin, dans le gestionnaire, j'aurais besoin de longueur précises les sections et branches des appareils de voies pour calculer la distance qui sépare un train de son signal d'arrêt. J'y reviendrai dans le gestionnaire, c'est fondamental.

FICHIERS :

Pour l'instant, dans Processing, tous mes fichiers sont issus de "Tables" et sont donc des fichiers dont l'extension est obligatoirement ".tsv", c’est-à-dire "Tabulation Separated Values" (valeurs séparées par une tabulation) qui se trouve être le fichier natif des fichiers Excel.
Il s'ensuit que le meilleur moyen d'ouvrir ces fichiers texte est l'application Excel (ou tout autre tableur).
La conséquence, c'est que le fichier JSON sort actuellement en "_JSON________.tsv".
Si on veut un vrai fichier JSON, il suffit de le copier ailleurs et de changer l'extension ".tsv" en ".json" et on obtient le fichier "_JSON________.json".
Le fichier JSON est, ici, un fichier de sortie et le fichier ZONES est le fichier d'entrée. Il ne contient que les informations que le programme ne peut pas deviner.
Le fichier ZONES, quant à lui contient exclusivement les valeurs nécessaires au calcul du fichier JSON. Il n'y a que des valeurs que vous rentrez. Tout le reste est calculé.
Il est fortement déconseillé de modifier des valeurs directement dans le fichier ZONES, tant elles sont liées les unes aux autres. En passant par le programme, tous les liens sont pris en compte et la cohésion est garantie.

Variables du fichier ZONES :
NOM :
Le nom de la zone simple.
PARITE :
La parité de la section, avec une aide dans le programme.
TYPE :
Numérotés de 0 à 11


 
ORIENTATION :

L'orientation est la position du dessin d'une section ou d'un appareil de voie par rapport à la verticale dans un pavé. La "précision" de cette orientation est de 45°. Elle est caractérisée par un nombre entre 0 et 7 dans le fichier zones.

GARE :

L'info de la gare. On a :
g0, g1, … qui sont les zones de gare (on n'en rentre qu'une partie)
ap_g0, ap_g1, … qui sont les zones d'approche des zones de gare (on les rentre toutes)
so_g0, so_g1, … qui sont les zones de sortie des zones de gare (on les rentre toutes)

MANŒUVRE :

L'info de la zone de manœuvres.
m0, m1, … qui sont les zones de manœuvre (on n'en rentre qu'une partie)
ap_m0, ap_m1, … qui sont les zones d'approche des zones de manœuvre (on les rentre toutes)
so_m0, so_m1, … qui sont les zones de sortie des zones de manœuvre (on les rentre toutes)

VITESSES :

L'info de la vitesse limite d'une zone ou, dans un appareil de voie, d'un segment de l'appareil.
X, Y :
Ce sont les coordonnées du centre du "pavé" sur le TCO. Un pavé n'a pas d'orientation. Il est calé sur une grille.
Les X, Y ne sont pas demandés lors de la création des zones simples :
C'est uniquement lors de modifications, c’est-à-dire dans une deuxième étape.

TCO :

A la SNCF, c'est le "Tableau de Contrôle Optique". Il est, en général, le long d'un mur dans le poste d'aiguillage et représente le tracé de toutes les zones gérées par ce poste d'aiguillage, avec l'occupation par les trains, la position des aiguilles, des itinéraires, ...
C'est purement visuel. Il n'y a pas de boutons sur un TCO à la SNCF.

Les modélistes se sont dit qu'il serait pratique, justement, d'y regrouper tous les boutons et le TCO est devenu le "Tableau de Commande Optique".

Tableau de Commande Optique (TCO)

C'était tentant du fait qu'on a déjà le dessin de tous les éléments…
Mais je n'avais pas envie de le dessiner : c'est le programme qui va se charger de le faire.
On doit quand même positionner les éléments (X, Y) et, le plus simple, c'est de rentrer les noms des zones dans Excel. C'est très souple, on peut déplacer plusieurs éléments d'un coup et avoir un positionnement global satisfaisant. C'est plus simple de se mettre en notation "L1C1" plutôt qu'en ABCD. Attention : Excel démarre à 1 et Processing à 0…
On note le nombre de cellules en horizontal et en vertical. En général, le nombre en horizontal est supérieur au nombre en vertical. C'est celui-là qui compte.
On rentre le nombre de colonnes d'Excel dans le setup "NB_PAVES = xx"
Une fois qu'on a rentré tous les X, Y dans les zones, on peut afficher le TCO.

1°) On appuie sur le bouton "Analyse" pour faire tous les calculs et on est ainsi sûr qu'il n'y a pas d'erreur. Si on oublie d'appuyer sur "Analyse" avant, on n'a pas les calculs des portions intermédiaires…

2°) On appuie sur le bouton "TCO" et on a un "paté" du TCO, coincé dans un carré de 500 x 500.
Il faut alors passer au plein écran et le TCO apparait.
On se rend compte alors que certains positionnements ne sont pas bons et on peut alors les modifier directement sur l'écran en cliquant dans les pavés des zones.
Si vous cliquez à gauche dans un pavé, il avance d'une case vers la gauche et le dessin se met à jour. De même pour droite, haut et bas. Et le dessin se recalcule immédiatement !
Quand vous êtes satisfaits du résultat, n'oubliez pas de sauver les X, Y :
1°) Cliquez sur "Valider" dans le rond en bas à droite
2°) Choisissez "Sauver" dans le menu général.

Composition du TCO :

Ce TCO est volontairement orienté vers la vérification des données, plus que vers un gestionnaire.
Par exemple, il n'affiche pas la position des appareils de voie (les lames).
Il affiche des panneaux de signaux complets avec tous les feux allumés en même temps …
Il y a un code couleur des zones :
Noir pour les gares
Violet pour les zones de manœuvres
Noir large sur Aqua pour les zones d'approche de gare
Noir étroit sur Aqua pour les zones de sortie de gare
Violet large sur Aqua pour les zones d'approche de manœuvres ou Violet large sur Noir si on est en gare.
Ce code couleur n'est utile que pour les vérifications et n'aura pas d'intérêt dans le gestionnaire.

Signaux :

Une particularité des panneaux de signaux SNCF est qu'il est impossible d'avoir, sur le même panneau, à la fois l'affichage du Carré et du Carré violet (les feux sont au même endroit).
J'ai donc décidé que, si l'on doit pouvoir afficher C et Cv au même endroit, il faut deux feux : un sur poteau et un au sol pour le Cv.
Dans les zones de manœuvres, j'ai décidé de faire figurer tous les feux, puisque chaque zone est banalisée. Mais les feux virtuels sont simplement affichés par un rond vide.
J'aimerais bien faire figurer ici les vitesses limites, toujours dans un but de vérification des entrées, mais il n'y a pas beaucoup de place…

Impression :

Il suffit de faire une copie-écran et l'imprimer. Mais comme j'ai pitié des cartouches d'imprimante, on peut mettre un fond blanc avant de faire la copie-écran en appuyant sur la bascule "Fond", en bas à gauche.

62
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 10, 2025, 05:02:29 pm »
POST DU 10/03/25 PARTIE 1/2

Bonjour à tous,

Je reprends le fil après 4 mois de travail. Mon programme est passé de la version 9 à la version 20 ! (et maintenant version 23)
De très nombreuses choses ont évolué et le JSON est complet, zones multiples comprises. C'est cette dernière fonction qui a été la plus complexe.
Il y a même un TCO à partir des éléments actuels. C’est nécessaire pour passer au gestionnaire.
C'est un TCO schématique, type TCO physique avec des boutons et on ne sera pas obligé de représenter tout le réseau à l’échelle, comme avec mon précédent TCO. On pourra mettre les éléments où on veut.
Mes recherches ont porté sur les infos minimales nécessaires pour décrire un réseau. Tout ce qu'un programme ne peut pas deviner seul. Pour le reste, c'est à lui de compléter…
Pour l’instant, ce qui fonctionne, c’est une description du réseau à partir de dessins schématiques et quelques infos demandées à l’utilisateur (le nom de la zone, de ses voisins, de la présence ou non de signaux, de ralentissements, de longueurs, …).
On rentre ces quelques infos, on appuie sur "Sauve" et le JSON est automatiquement créé !!

LEXIQUE :

En informatique, on doit être extrêmement précis dans les libellés et je vais commencer par un lexique, de difficulté croissante, pour qu’on soit sûrs qu’on parle tous de la même chose.
Et ça donnera aussi une idée de tout ce qu'on doit prendre en compte pour créer un gestionnaire.

ELEMENT :

Un élément, c'est ce qu'on achète dans le commerce : un rail, un aiguillage, …

ZONE :

Une zone, c'est le plus petit ensemble d'éléments avec une détection de présence par consommation de courant. Il y a 2 types de zones : les sections et les appareils de voie.

SECTION :

Une section est une zone composée uniquement des éléments suivants : rail droit, rail courbe, rail flexible.
La section est le seul type de zone à pouvoir posséder et gérer des signaux.
APPAREIL DE VOIE :
Un appareil de voie, c'est tout ce qui n'est pas dans une section : aiguillage, TJD, …
Un appareil de voie ne peut pas posséder de signaux.
Mais on verra dans les "zones multiples" une méthode pour leur en affecter quand même.
Les appareils de voie sont à la SNCF de 2 types : les traversées et les branchements.
Pour nommer un appareil de voie, on est libres, mais avec 2 contraintes :
Ne doit pas démarrer par "Br" ou "Su" (voir plus loin pourquoi).

TRAVERSEE :

A la SNCF, on appelle "traversée" ce que les modélistes appellent "croisement".
Et, ainsi, on comprend mieux pourquoi une TJS s'appelle "Traversée Jonction Simple" puisque composée d'une traversée et d'une jonction et la TJD, une "Traversée Jonction Double" puisque composée d'une traversé et de 2 jonctions.
Bien plus qu'un problème de vocabulaire, la traversée pose en gestion des trains des problèmes tout à fait spécifiques.
Je garderai donc le terme de "traversée" pour la suite pour désigner ces 3 éléments liés.
Il y a un cas particulier lié à la traversée simple.
Elle n'a aucun moteur, tout est fixe, mais il y a quand même 2 positions liées à l'alimentation des rails. Il y aura donc une position "gauche" et "droite", par analogie aux aiguilles.

BRANCHEMENT / AIGUILLAGE / AIGUILLE :

Le "branchement", c'est le terme SNCF pour ce que les modélistes appellent "aiguillage"
Je garderai le terme "aiguillage" ou "aiguille", ce qui ne pose pas de difficulté ici.
Une aiguille peut être prise "en pointe", c’est-à-dire que, dans ce cas, on peut lui affecter plusieurs directions ou "en talon" où il n'y a qu'une seule direction possible : vers la pointe.
Une aiguille a une position "gauche" ou "droite" dans le JSON et pour le gestionnaire. Cette position est indépendante du fait qu'il puisse y avoir une position "tout droit" ou "dévié".
Les termes "gauche" et "droite" sont universels, même dans des aiguilles symétriques, enroulées et même pour la traversée simple (voir ci-avant).
LAMES :
Les appareils de voie ont des éléments mobiles appelés "lames".
J'utiliserai ce terme pour designer les différentes positions des appareils de voie.
Une aiguille a "lames = 0" quand on va à la première position (en général "tout droit")
Une aiguille a "lames = 1" quand on va à la deuxième position (en général "dévié")
Sur le TCO, c'est la valeur de "lames" qui permettra de dessiner la position effective des lames de l'appareil de voies.
Pour une TJD, on aura 4 positions, de 0 à 4, pour une TJS, 3 positions, etc…

CANTON :

Un canton, c'est une ou plusieurs zones qui commencent et/ou terminent par un signal.
Il peut y avoir des cantons unidirectionnels qui n'ont qu'un signal à une extrémité et des cantons bidirectionnels avec un signal à chaque extrémité.
Il faut bien distinguer les zones et les cantons. Ils ne sont pas du tout synonymes.
Par exemple, une aiguille peut être une zone, avec sa détection de présence spécifique, mais ne peut pas être un canton car il n'y a pas de signal.
Un canton peut être constitué de 3 zones. L'inverse n'a pas de sens.
L'ambiguïté vient du fait que, très souvent, on explique le cantonnement par un exemple en pleine voie où le canton n'a qu'une zone.

CANTONNEMENT :

Le cantonnement est un système de gestion des trains qui permet l'espacement de 2 trains qui se suivent de façon à leur éviter un rattrapage ou une "prise en écharpe" (2 trains arrivant en talon simultanément sur chaque branche d'une aiguille).
Un système de signalisation complexe à respecter scrupuleusement pour éviter tout problème.

ZONE SIMPLE :

C'est ce que vous aurez à décrire dans ce programme. Soit une section, soit un appareil de voie.
Le nom d'une zone simple peut être quelconque, à une exception près : il ne doit pas comporter de "/", caractéristique des zones multiples (voir plus loin).

PARITE :

La parité est une donnée intrinsèque de la zone.
Quand on trace un trait sur une feuille, il y a une origine et une extrémité.
Dans mon programme, l'origine s'appelle "A" et l'extrémité "B".
Pour une section, le côté pair est du côté "A" et le côté impair du côté "B".
Pour une aiguille, le côté pair est du côté "A" (la pointe) et les côtés impairs les côtés "B", "C", "D" (les talons).
Pour une traversée, les côtés "A" et "C" sont du côté pair et "B" et "D" les côtés impairs.
Pour une section, il y a toujours une parité : c'est la direction principale de déplacement lorsque la section peut être parcourue dans les 2 sens.
A noter que, pour une section unidirectionnelle, le signal éventuel sera toujours côté "B".
La parité permet de définir des voisins pairs et des voisins impairs.

VOISINS PAIRS / IMPAIRS :

Cette caractéristique a été proposée par Pierre au début de ce fil et elle est d'une puissance que je n'imaginais pas au départ. C'est vraiment une excellente idée.

CONNECTEUR :

Un connecteur est l'unique point commun entre 2 zones voisines.
Je les utilise dans la recherche des itinéraires. Mais Pierre a dit qu'on n'en avait pas besoin et, au début, ça m'a rendu perplexe, tant ils me paraissaient nécessaires.
Puis j'ai remarqué qu'on pouvait effectivement s'en passer grâce à la puissance de la notion de voisins. Quand j'en serai à la phase optimisation, je reverrais ma recherche d'itinéraires en utilisant les voisins.
La recherche d'itinéraires étant la partie la plus complexe de mon programme, je démarrerai prudemment…
En développant le TCO (voir plus loin), j'ai, à nouveau eu besoin des connecteurs pour localiser les coupures de rail. C'est donc plus compliqué que prévu de s'en passer.

ZONE MULTIPLE :

C'est un ensemble de zones simples dont le nom comporte un "/".
Exemple : 3 zones simples "Z1/0", "Z1/1" et "Z1/3" deviendront la zone multiple "Z1".
Le côté pair d'une zone multiple est le côté de "/0" ("Z1/0" dans l'exemple précédent).
On peut mélanger des sections et des appareils de voie, sans limite.
En ajoutant une section de longueur nulle à un appareil de voie, on peut ajouter un signal à un appareil de voie dans la zone multiple ainsi créée.
Mais il doit exister une caractéristique essentielle dans une zone multiple : un pivot unique.

PIVOT :

C'est un point réel ou virtuel unique qui sépare en deux une zone multiple.
Une zone multiple peut être vue comme une étoile, avec le pivot en son centre.
La zone multiple a des voisins pairs et des voisins impairs.
Il doit n'y avoir qu'un seul chemin entre un voisin pair et le pivot.
Il doit n'y avoir qu'un seul chemin entre un voisin impair et le pivot.
Le pivot est le point de passage obligé entre un voisin pair et un voisin impair.
Quand il y a une traversée dans une zone multiple, le pivot est virtuel et est en son centre.
Quand il n'y a pas de traversée, le pivot est réel (c'est un connecteur) et se trouve là où 2 aiguilles se touchent par leurs pointes (à une section intermédiaire près).

ITINERAIRE :

C'est la ou les façons de transiter d'une section à une autre section.
Un itinéraire démarre et finit obligatoirement par une section parce qu'il va d'un signal à un autre signal.
A la SNCF, les itinéraires sont gérés par des postes d'aiguillages.
Un poste d'aiguillage a une zone d'action qui lui est propre dans laquelle il gère tous les appareils de voie, les occupations et la signalisation.
Une gare peut avoir plusieurs postes d'aiguillages si elle est très grande.
Et donc plusieurs gestions d'itinéraires possibles pour une seule gare.
Mais l'inverse peut être vrai aussi.
Un poste d'aiguillage peut aussi gérer plusieurs petites gares.
Par exemple, à Reims, on a longtemps géré, en conduite centralisée, les 7 gares entre Reims et Epernay en voie unique sur 23 km.
Cette caractéristique m'a incité à étendre la gestion d'itinéraire à tout le réseau. C'est un choix.
Mon programme calcule tous les itinéraires possibles d'un réseau. C'est nécessaire pour la définition automatique des zones multiples. Il sort même la liste dans un fichier.
A part en développement, afficher ce fichier n'a qu'un intérêt anecdotique.
On doit pouvoir enregistrer les itinéraires, même si, au moment de l'enregistrement, ils ne sont pas réalisables. C'est le déplacement des trains qui, en libérant des zones, permettra alors de débloquer les itinéraires automatiquement.
Pour moi, l'itinéraire, c'est bien plus que le simple fait de faire bouger plusieurs appareils de voie avec un seul bouton. Il y a, en plus de la gestion des occupations, des priorités, des enregistrements, …
Les itinéraires sont très rapides à calculer. Je propose de les faire "à la volée" dans le gestionnaire plutôt que de prendre de la place dans le JSON.

ZONE DE GARE :
 
La définition des zones de gare est du ressort de l'utilisateur, aidé par le programme.
Il faut définit les zones d'approche, les zones de sortie et au moins une zone dans la gare. Le programme se charge d'attribuer la caractéristique de "gare" aux zones intermédiaires.
Dans le cas d'une grande gare, c'est appréciable de ne pas avoir à spécifier "fait partie de la gare" à toutes les zones.
En particulier, il existe des zones d'approche, des zones de gare et des zones de sortie.

ZONE D'APPROCHE :

Ce sont les zones par les quelles débutent les itinéraires allant vers la gare. Elles sont caractérisées par un signal carré en allant vers la gare, jusqu'à ce que l'aiguilleur donne un itinéraire.

ZONE DE SORTIE :

C'est la dernière zone d'un itinéraire.

ENCLENCHEMENT :

C'est la partie la plus complexe de la gestion des itinéraires.
Quand un itinéraire est enclenché, on ne peut plus le modifier d'une part et, d'autre part, tous les itinéraires avec lesquels il est incompatible ne sont plus réalisables.
La présence dans la zone d'approche est la méthode la plus basique de la gestion des enclenchements. Mais il y en a d'autres, qu'on verra quand on en sera à la gestion des trains.
Evidemment, l'enclenchement se termine quand on quitte la zone de sortie.

ZONE DE MANŒUVRES :

La définition des zones de manœuvres est du ressort de l'utilisateur, aidé par le programme.
Il faut définit les zones d'approche, les zones de sortie et au moins une zone dans la zone de manœuvres. Le programme se charge d'attribuer la caractéristique de "manœuvre" au zones intermédiaires. Dans le cas d'une grande zone de manœuvres, c'est appréciable de ne pas avoir à spécifier "fait partie de la zone de manœuvres" à toutes les zones.
Dans la réalité (et surtout aux débuts de la SNCF), il n'y avait quasiment aucun signal dans une zone de manœuvres, la sécurité était assurée par des hommes et une vitesse limitée à 15 km/h.
Dans un réseau miniature, il n'y a pas d'hommes pour faire la sécurité et encore moins des mécaniciens qui marchent "à vue".
La zone de manœuvres sera donc gérée comme le reste, avec des zones toutes bidirectionnelles et des feux virtuels et quelques-uns réels (des carrés violets).
Les carrés violets apparaitront au TCO et, pour les carrés violets virtuels, il y aura simplement un cercle vide indiquant leur emplacement. La vitesse est limitée à 15 km/h et les feux sont seulement des carrés violets.

TRANSIT SOUPLE :

On part d'un constat simple : plus les zones sont courtes, plus elles sont libérées rapidement et plus elles peuvent être affectées à un autre train avec un délai minimal.
Cela favorise la fluidité du trafic.
Mais cela suppose plus de zones, plus de câblage et, évidemment, un coût beaucoup plus élevé. Il faudra donc faire une analyse du réseau et optimiser le nombre de zones (via les zones multiples) et la densité du trafic. Il y a un équilibre à trouver.
Les premiers postes à relais ont été les PRA (Postes tous Relais à destruction Automatique) en 1939 au poste 5 d'Argenteuil. Le principe est qu'un itinéraire est détruit automatiquement quand le train a franchi le tout dernier appareil de voie. C'est presque toujours ce genre de fonctionnement sur les réseaux miniatures.
Puis sont venus les PRS (Postes tous Relais à transit Souple) en 1950 à Gagny-Montereau.
Au lieu d'attendre que tout l'itinéraire soit franchi, on libère les aiguillages au fur et à mesure de l'avancée du train. On perd ainsi beaucoup moins de temps et on peut faire passer plus de trains sur le même grill de voies. C'est plus fluide.
Puis vinrent les PRG (Postes tous Relais Géographiques) en 1971 à Montargis.
Identiques aux PRS dans le transit souple, mais on n'a plus de bouton d'itinéraire : on choisit un point d'entrée et un point de sortie. Ce sera le type d'itinéraires de mon futur gestionnaire.
Le PRG a pour lui d'avoir besoin de moins de boutons : un bouton par voie d'entrée ou sortie au lieu d'un bouton par itinéraire.
A noter que cette idée de commande géographique date de 1909 (Poste Descubes de Nancy) en choisissant d'abord la sortie puis l'entrée. Bien avant les relais…

SIGNALISATION :

Mon programme gère la signalisation lumineuse de type BAL (voir plus loin).
On a juste à définir l'emplacement des feux sur les sections et le programme calcule tous les feux affichables pour un signal donné. Là aussi, le fait d'avoir calculé tous les itinéraires possibles était nécessaire.
En regardant simplement le JSON, on saura combien de signaux il faut acheter et quel devra être leur type (Panneau A à panneau H), y compris les feux vers les voies de manœuvres au sol.


 
BAL :

Block Automatique Lumineux.
C'est un système de gestion SNCF basé sur des cantons, avec une signalisation lumineuse permettant d'assurer la sécurité du réseau.

MOTEURS :

Par la suite, j'appellerai "moteur" tout système permettant de changer la position des aiguilles. Il peut s'agir de solénoïdes, de servos ou de moteurs à mouvement lent.
A ce sujet, une traversée simple aura un "moteur virtuel" pour identifier les deux possibilités de traverser l'appareil de voie. C'est obligatoire pour gérer l'alimentation des voies de la traversée.
Les TJS et TJD seront considérées comme deux aiguilles tête-bêche par leurs pointes et, donc, auront 2 moteurs.
Mais j'ai aussi considéré le cas de Märklin qui, pour ses TJD, n'utilise qu'un seul moteur et un astucieux système de renvois.




Les aiguilles triples ont, eux aussi 2 moteurs, même chez Märklin, et il existe des aiguilles triples dites "symétriques" où le dessin semble symétrique, mais, en fait ne l'est pas vis-à-vis des moteurs. Il y aura donc un moteur plus "en avant" que l'autre, d'où des aiguilles triples gauche ou droite.

Suite dans le post suivant

63
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 07, 2025, 06:22:03 pm »
Bonjour,

Et encore, tu es gentil, moi, je n'ai plus écrit depuis le 23 juillet... ;)

Je n'ai pas abandonné, loin de là.
 
Depuis le mois d'août, j'ai développé, quand j'avais le temps, testé, re-testé, modifié, simplifié, dans le but de générer un fichier JSON et un TCO avec le minimum d'information au départ.
J'estime avoir passé 4 mois de temps plein sur ce programme depuis le mois d'août.
Aujourd'hui, j'ai encore supprimé un bug qui m'avait échappé.
Je préfère n'écrire que quand je n'en trouverais plus.
Après, il faudra qu'on se mette d'accord avec Pierre sur le contenu définitif du JSON qui deviendra le JSON Locoduino.

Pierre, de son côté, s'est occupé de "l'autre côté du JSON", c'est à dire du gestionnaire.

J'ai quasiment fini le topo qui présentera ça.

Pour faire patienter, voici le TCO que mon programme calcule tout seul à partir de, finalement, très peu d'infos demandées au modéliste.
En PJ :
1°) le TCO avec toutes la signalisation calculées en fonction du réseau
2°) le fichier de départ, celui qui recense la totalité des infos que le programme ne peut pas deviner (le nom des zones, des aiguilles, de la présence ou non d'un signal, ...) 6 Ko !
Pour info, il faut l'ouvrir avec Excel (ou un tableur), comme tout fichier .tsv (Tabulation Separated Variables)

Denis

64
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 23, 2024, 07:47:51 am »
@ Pierre,

Dans ton post #411 du 05/05/24, tu soulèves l'intéressant problème du garage franc.

J'avoue qu'à la SNCF, je ne sais pas comment c'est géré électriquement.
La seule chose visible, c'est une marque blanche au sol (une traverse peinte en blanc, un bloc béton peint en blanc, …). Avec du personnel sur le terrain, c'est jouable. On voit si on dépasse ou pas.
Mais nos petits trains n'ont pas de personnel au sol…

Je propose donc de faire la coupure plus loin, suivant le schéma  :



Les véhicules dessinés sont à bogie car c'est ceux-là qui "dépassent" le plus.
J'entends par "dépassement" la distance entre le bogie côté tampon et le bout du tampon. En gros, 3 cm, à vue de nez.
Donc, on ne fait pas la coupure à l'extrémité de l'aiguille, mais 3 cm plus loin.

Ainsi, si le véhicule avance un peu, il se trouve électriquement sur la zone de l'aiguille et empêche la création d'un itinéraire sur l'autre voie ou empêchant la destruction de l'itinéraire si on ne va pas assez loin sur la zone hors aiguille.

Jusque-là, c'était évident.

Mais on ne peut pas raisonner ainsi si plusieurs aiguilles se suivent.
La dernière zone d'un itinéraire est à la fois occupée électriquement et occupée par l'itinéraire.
Lorsque le train avance, elle devient à la fois inoccupée électriquement et disparait de la liste des zones de l'itinéraire.

Ce que je propose, c'est d'agir en 2 temps :

La zone devient inoccupée électriquement, tout en restant occupée par l'itinéraire.
Elle ne quittera la liste des zones de l'itinéraire que quand on aura 2 zones d'appareils de voie consécutives inoccupées électriquement.
On a ainsi un décalage d'une aiguille entre l'occupation électrique et l'occupation par un itinéraire. Comme l'occupation par un itinéraire bloque la création d'un autre itinéraire utilisant cette aiguille, on a bien une distance supérieure à 3 cm tout le temps, même si on perd un wagon.

Denis :P

65
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 22, 2024, 11:28:47 am »
@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  :P
PS : j'ai trouvé une solution pour le problème que tu as soulevé concernant les limites de garage franc.

66
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 10, 2024, 06:47:34 pm »
@ Pierre

Citer
Je préfère, et de loin, écrire et tester le gestionnaire en Processing.
Ah oui !!  ;D

67
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 10, 2024, 04:40:51 pm »
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  :P

68
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 02, 2024, 11:08:12 am »
@ 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 :P

69
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 26, 2024, 09:05:13 am »
@ 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... :o

Denis :P

70
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 25, 2024, 10:55:14 am »
@ 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 :

            "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 :P

71
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 24, 2024, 10:58:06 am »
@ 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 :

    "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 :

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 :P

72
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 23, 2024, 11:44:50 am »
@Pierre,

Bravo pour tes efforts pour faire entrer un gestionnaire dans un microcontrôleur. 8)

@ tous,

J'ai bien avancé sur mon éditeur, bien clarifié certains points et corrigé quelques bugs. :P

Voyons dans le détail :

1°) La parité :

Quand on trace un trait sur une feuille, on a une origine et une extrémité.
Cette information ne doit jamais être perdue.

Quand un train va de l'origine vers l'extrémité, je décrète arbitrairement qu'il va dans le sens pair.
Comme, par ailleurs, on circule à gauche à la SNCF (hors AL pour des raisons historiques), il s'ensuit que les trains pairs vont dans le sens des aiguilles d'une montre. C'est une conséquence du choix précédent.

Un train pair voit des signaux pairs à l'extrémité d'une zone paire.
Un train impair voit des signaux impairs à l'extrémité d'une zone impaire.

Si une zone paire peut être parcourue dans les 2 sens, les trains pairs voient les signaux pairs à l'extrémité et les trains impairs des signaux impairs à l'origine de la zone.
Si une zone impaire peut être parcourue dans les 2 sens, les trains impairs voient les signaux impairs à l'extrémité et les trains pairs des signaux pairs à l'origine de la zone.

Donc, dans la ligne "sens" de la zone, je ne peux avoir que "pair" ou "impair".

Le voisin pair d'une zone paire est à l'extrémité et le voisin impair d'une zone paire est à l'origine.
Le voisin impair d'une zone impaire est à l'extrémité et le voisin pair d'une zone impaire est à l'origine.

Par ailleurs, il peut y avoir 0, 1 ou 2 signaux pour une zone.
On traitera plus tard le cas de 0 signaux, en particulier dans les zones multiples.
Pour 1 signal, si la zone est paire, il y aura un seul signal pair et un seul signal impair si la zone est impaire.
Pour 2 signaux, il y aura un signal pair et un signal impair. Et la parité nous dira à quel bout il est.
Si on veut garder à la fois l'information de parité et l'information du nombre de signaux dans la ligne "sens", je propose de mettre "pair0"/"impair0", "pair1"/"impair1" ou "pair2"/"impair2"

Pour les appareils de voie, je ne m'occupe pas de la parité. L'origine est toujours du côté de la pointe et l'extrémité côté talon.

Pour les traversées (croisement, TJS, TJD), je définis arbitrairement un sens puisque tout est symétrique.

Enfin, pour les zones qui ont un butoir, celui-ci est toujours à l'extrémité. La parité de la zone désignant cette extrémité.

J'ai abandonné la notion de "pairimpair" car elle fait perdre la notion d'origine/extrémité.

2°) Pierre a eu l'excellente idée d'ajouter des balises dans les zones, paires ou impaires évidemment, ce qui permet de récupérer plus souvent une information de position du train réel (odométrie) et de s'assurer d'un arrêt au pied du signal.
On évite ainsi de découper les rails pour des "zones d'arrêt" dans les zones et un seul capteur à effet hall suffit pour détecter le train à l'endroit d'une balise.

Pour l'instant j'ai défini 2 types de balises :
- avant un signal
- avant un butoir
Mais on pourrait définir d'autres types. Par exemple une balise quand un train doit siffler (entrée de tunnel, passage à niveau, …).

3°) Autre excellente idée de Pierre : les bretelles.

Effectivement, la position de certains appareils de voie implique la position d'un autre appareil sous peine de déraillement.
Dans une bretelle, il y a deux positions :

L'une ou les tracés sont parallèles où il ne peut rien se passer du point de vue du gestionnaire (pas de rattrapage, de face à face, …) et l'autre position où des zones sont dans la continuité l'une de l'autre. C'est pour ça que j'ai ajouté à la ligne "bretelles" du JSON la position des 2 appareils de voie qui amène un problème à gérer au gestionnaire.

On remarque, au passage, que les 2 appareils de voie sont soit tous les 2 à droite ou tous les 2 à gauche dans une bretelle.
Il ne peut y avoir de bretelles qu'entre 2 appareils de voie ayant des lames mobiles. Donc, on serait tenté d'exclure, à priori, les sections et les croisements.
En fait c'est plus compliqué :

Cas de la section :

Il peut très bien y avoir une section entre les 2 appareils de voie et cela constituera quand même une bretelle si cette section est "courte".
Si une section est suffisamment courte pour qu'on ne puisse pas y mettre un wagon, cela ne pose pas de problème.
Si la section est plus longue, il faut pouvoir détecter un wagon sur cette section.
Si la section est suffisamment longue pour contenir un train complet, est-ce encore une bretelle ?

Cas du croisement :

Il est très fréquent qu'un petit croisement soit associé à 2 bretelles successives, permettant ainsi de passer d'une voie à l'autre dans les 2 sens.
La difficulté, en recherche automatique, c'est que, là, il faut chercher le voisin du voisin.
C'est une récursivité à un seul étage.
4°) Pour la partie aiguilles, j'ai précisé quelle était l'aiguille concernée dans les appareils ayant 2 aiguilles (TJS, TJD, triples).
"TJDa" et "TJDb" pour une TJD. "TJSa" et "TJSb" pour une TJS
"TripleGa" et "TripleGb" et "TripleDa" et "Tripleb" pour les triples.

5°) Pour la partie signaux, j'ai ajouté la liste des signaux affichables par un signal donné.
J'ai ajouté, pour ceux susceptibles d'afficher "RR", la liste et la position des aiguilles concernées dans ce cas.

Quant à la numérotation des signaux, il y a une lettre et un nombre.
- La lettre correspond au nom du signal hiérarchiquement le plus élevé (C, Cv, S)
- Le nombre est un incrément. Il y a 2 incréments : un pair et un impair.
Suivant la parité de la zone, on incrémente de 2 le bon incrément.

Au passage, comme un signal ne peut afficher C et Cv en même temps du fait que la deuxième ampoule du carré est l'ampoule du Cv (voir ci-dessous), j'ai tenu compte de cette particularité.



Dans le gestionnaire, il faudra également gérer le feu blanc (M) qui peut être clignotant.
Le feu M à l'origine de Z28 ne peut être que clignotant, de même que les deux feux de Z37.



Je terminerai sur les signaux en disant qu'ils peuvent être visibles ou invisibles.
Un signal invisible est un signal qui est nécessaire au fonctionnement du gestionnaire, mais qui n'est pas forcément implanté sur le terrain, en particulier en zone de manœuvre où ce sont souvent des hommes qui, sur place, manipulent des drapeaux ou des lanternes.

J'ai mis un cercle vide pour les signaux qui, à mon avis, sont invisibles.
Le feu visible en Z46 sera traité avec les zones multiples, encore à faire.

6°) Je n'ai pas mis les trains dans le JSON. Pour l'instant, je ne sais pas quoi mettre.

7°) Concernant les itinéraires, c'est tellement rapide à calculer que je ne suis pas absolument convaincu que ce soit nécessaire de les calculer d'avance.
Il faut trouver une méthode qui permette de choisir un seul itinéraire quand il y en a plusieurs d'un point A à un point B.

73
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 10, 2024, 04:08:29 pm »
@Pierre,

Pour répondre à ta dernière remarque sur les butoirs.
C'est une chose de ne rien mettre dans le JSON. Ça gagne de la place et c'est logique. OK.
Mais pour gérer les itinéraires, il faut que toutes les zones aient un voisin et le plus facile, comme il faut bien mettre quelque chose, j'ai pris le parti de mettre le nom de la zone.
En plus, quand on recherche des itinéraires, on change de sens de parcours aux butoirs. Il n'y a même pas besoin d'avoir un cas particulier, l'inversion se fait d'elle même.

Par ailleurs, j'ai beaucoup de mal à dire qu'une zone est paire ou impaire. Je conçois, par contre, très bien qu'une zone ait un côté pair et un côté impair. Ça me va parfaitement.

Je supprimerai bien l'info "sens" dans le JSON :

Une zone a un feu (coté pair ou impair), deux feux ou pas de feux.
Si une zone a un feu "signP", elle est "paire" et l'info "sens" est redondante. Si une zone a un feu signI, elle est "impaire" et l'info "sens" est redondante.
Si une zone a deux feux, elle est banalisée et n'a donc pas vraiment de sens.
Si elle n'a pas de feu, elle est aussi banalisée et n'a donc pas vraiment de sens.

Dans les itinéraires, on a une liste de zones. L'ordre de cette liste donne le sens de parcours. Là encore, l'info "sens" est redondante.

Concernant les ralentissements, je propose que cette info soit au niveau des feux R et pas de feux RR, comme ça le train a directement l'info quand il en a besoin.

Denis :P

74
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 08, 2024, 07:12:48 pm »
@ Dominique,

Le fichier JSON va évoluer, suite au dernier post de Pierre.
 
En effet, comme son gestionnaire évolue, il a besoin d'informations supplémentaires et de simplifications.
En particulier, il doit être aussi petit que possible, si on veut le charger dans un processeur avant de lancer le gestionnaire.
Je suis en train de l'adapter pour qu'il réponde aux nouveaux enjeux.

Pour répondre à tes questions :

1°) Oui, le voisin d'une zone avec butoir, c'est elle-même. Et ça fonctionne très bien dans la recherche d'itinéraires.

2°) Pair/impair, c'est le sens de circulation principal d'une zone. C'est une donnée du réseau. Et ça suppose que le train roule à sens unique.
Sauf accident ou problème technique, un train pair roule dans le sens pair et voit les signaux de sens pair.

3°) Concernant les voisins, justement ça va changer : voisP pour voisin pair, voisI pour voisin Impair, pareil pour les signaux. Il va falloir que je change.

4°) Pour moi, il faut que le type des appareils de voie soit clair : une aiguille droite a la voie déviée à droite et une aiguille gauche la voie déviée à gauche.

5°) Je construit le fichier JSON à partir du fichier Zones. Pour l'instant, je sauve le fichier Zones, mais quand on sera d'accords sur le JSON, je ne le sauverai plus.
De la même façon, je sauve les fichiers d'itinéraires, très complets, mais, comme ça finira aussi dans le JSON (en résumé), ils disparaîtrons aussi.
Il y a dans le fichier Zones toutes les infos nécessaires pour construire le JSON.

Le fait de raisonner exclusivement en pair/impair va me poser quelques soucis, car c'est très différent de mon raisonnement, mais j'ai bon espoir  ;)

Denis  :P

75
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 06, 2024, 06:03:52 pm »
Bonjour Pierre,

Je décortique ton fichier JSON et je me pose des questions :

1°) Il y a un fichier JSON indépendant qui ne sert pas ?
2°) Tu as 2 onglets Z1 et Z2 j'imagine que Z1 est une ancienne version et que tu utilises Z2 ?
3°) Tu utilises maintenant pairETImpair, pairOUImpair. C'est quoi la nuance ?
4°) Comment tu coderais une zone sans feux (dans une zone de manœuvres, par exemple) ?
5°) Plutôt que des 0/1, tu utilises exclusivement les notions de pair/impair, partout ?
6°) C'est quoi, les balises ?
7°) J'ai un peu de mal avec tes aiguilles : tu as 2 aiguilles dans une bretelle, ce qui est logique, mais je ne vois pas de bretelle, vu que ce sont des TJS.
Et je ne vois qu'une aiguille dans les TJS ?
8°) Je vois la valeur des ralentissements dans les signaux (en donnant la position de l'aiguille qui nécessite ce ralentissement). Je trouve ça bizarre. Je pense que ce serait plus logique dans l'aiguille
9°) Dans les itinéraires, il n'y a qu'une liste de zones. Mais j'aurais tendance à y mettre aussi la position des aiguilles, de façon à ne pas avoir à la recalculer quand on appuie sur un bouton.
10°) C'est quoi "auts" ?

Je devrai être capable de traduire mon fichier Zones en un JSON de ton type, mais il faut que je comprenne tout.
Je joins ma version 8 où on trouve un fichier JSON du réseau de Dominique, pas complètement en phase avec le tien...

Par ailleurs, ça n'a rien à voir avec ce post : un PRS expliqué :
https://roverch.net/modelisme/PostePRS.htm

Denis :P
 

Pages: 1 ... 3 4 [5] 6 7 ... 55