Projet partagé d'un gestionnaire de réseau

[laurentr]

Bonsoir


Pierre dans ce que tu définis comme une "zone de manœuvre" sur laquelle entrer avec une occupation cela me semble aussi ressembler aussi à une option de "forçage" du bloc.

Les cas d'usage sont multiples indépendant du concept de manœuvre pure:

mise en tête/queue d une loco sur une rame assurant une détection de présence sur la zone
cas des UM /couplages
refouler /avancer une loco qui "aurait fait des petits" pour raccrocher

Pour toute ces raison le mode manœuvre ouvre une sorte de dérogation permanente sur des section bien précises
Dans le cas du forçage c est une condition externe à caractère "spécifique et temporaire".

La facilite c est aussi de tout déclarer possiblement en manœuvre... mais la sécu du bloc va en prendre un coup!...


Ltr

[Etienne66]

La liste de zones commence à la zone de départ, celle qui contient le signal de départ, puis toutes les zones d'aiguilles, pour finir sur la zone d'arrivée. Un signal doit être rattaché à une zone, dans la réalité le signal est implanté juste avant le changement de zone, avant la coupure physique des rails (si elle existe).

Pierre

Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.
Et comme il a un sens il a une zone amont et une zone aval.

Physiquement il sera généralement un peu avant la coupure.

[Etienne66]

Bonsoir


Pierre dans ce que tu définis comme une "zone de manœuvre" sur laquelle entrer avec une occupation cela me semble aussi ressembler aussi à une option de "forçage" du bloc.

Les cas d'usage sont multiples indépendant du concept de manœuvre pure:

mise en tête/queue d une loco sur une rame assurant une détection de présence sur la zone
cas des UM /couplages
refouler /avancer une loco qui "aurait fait des petits" pour raccrocher

Pour toute ces raison le mode manœuvre ouvre une sorte de dérogation permanente sur des section bien précises
Dans le cas du forçage c est une condition externe à caractère "spécifique et temporaire".

La facilite c est aussi de tout déclarer possiblement en manœuvre... mais la sécu du bloc va en prendre un coup!...


Ltr

C'est plus complexe que çà.

Quand tu as un simple Cv tu peux définir les blocs permissifs pour pouvoir ouvrir au blanc sur voie occupée.
Mais sur une voie principale avec un signal qui peut afficher vert ou blanc il te faut savoir si le train
manoeuvre pour prendre la décision. (d'où mon idée de voie virtuelle)

Au passage : seul un segment peut être permissif, une zone avec aiguillages ne doit pas l'être.

[Pierre59]

Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.

Dans le programme du gestionnaire il y a des objets informatique zones, entre les zones (jonction de 2 zones) il n'y a rien, aucun objet informatique pour attacher un signal. Il faut bien attacher le signal à quelque chose.

Pierre

[Etienne66]

Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.

Dans le programme du gestionnaire il y a des objets informatique zones, entre les zones (jonction de 2 zones) il n'y a rien, aucun objet informatique pour attacher un signal. Il faut bien attacher le signal à quelque chose.

Pierre

Oui : Une zone amont et une zone aval.
Et ça te donne automatiquement le sens du signal.

[Etienne66]

J'ai trouvé un truc pour les signaux de manoeuvre :

Pour les signaux qui peuvent afficher blanc et vert/jaune, on met au blanc si le signal suivant est un carré violet fermé
et au vert/jaune si c'est un autre feu.
Et on place un carré violet virtuel à chaque butoir.

Pour info, je viens de tester le coup du tiroir virtuel avec JMRI et ça fonctionne.

[Pierre59]

Voici une nouvelle version expérimentale d'un gestionnaire paramètré par un fichier JSON. Par rapport à la version précédente plusieurs choses ont changé :

- des itinéraires permanents ont étés ajoutés, deux conséquences, sur le TCO les boutons d'itinéraires ont étés changés pour ressembler à des vrais boutons d'itinéraires de PRS (voir le PRS de Méru pour les explications de fonctionnement post #160 du 10 janvier 10 2024 sur ce fil), dans le gestionnaire certains carrés peuvent servir de sémaphores pour assurer la continuité du cantonnement. Ces itinéraires permanents permettent de faire rouler un ou deux trains sur la boucle.

- en vue du passage au C/C++, impliquant un changement de bibliothèque JSON, tous les accès au JSON ont étés regroupés dans un seul onglet ("Json"), il reste dans les autres onglets un type (JSONArray) qu'il est difficile d'éliminer Java n'ayant pas de "typedef".

- pour accélérer le programme un certain nombre de valeurs de type chaine de caractères ("String") sont substituées par des valeurs numériques ("int") juste après la lecture du fichier JSON. Ces valeurs sont : "gauche", "droite", "pair", "impair", "pairOUimpair", "pairETimpair".

J'ai fait aussi des essais d'itinéraires spécifiés par une origine et une destination, genre PRG et successeurs.

Pour le fonctionnement du gestionnaire avec le TCO voir la précédente version post #339 du 18 février 2024 sur ce fil.

Il reste encore des bugs dans le gestionnaire, notamment pour les itinéraires. Il faut aussi implémenter une circulation automatique des trains et prendre en compte le nouveau Locoduinodrome (donc modification du TCO, déja bien avancée). Puis envisager des manoeuvres.

Pierre

[Dominique]

Super 
Merci Pierre,

J'ai tout juste fait un petit essai du Locoduinodrome 1 où j'ai lancé le TCO en premier et le gestionnaire en 2ème, puis démarré le train rose en cliquant sur l'itinéraire BX et c'est joli ! Le train fait le tour du circuit et s'arrête au signal à l'entrée de gare en venant de Y. Son curseur de vitesse passe à 0 et il faut le remonter pour redémarrer.

J'avoue que j'ai fait tout cela au pif en me souvenant du précédant Locoduinodrome. J'ai cliqué un peu partout sur les boutons d'itinéraires mais sans succès, faute de mode d'emploi.

J'ai jeté un coup d'oeil au code du gestionnaire et c'est du Java, je ne m'y retrouve pas mais je peux apprécier déjà que ce gestionnaire est plus complet que la version C++, il me semble, notamment sur le suivi des trains.
Ce qui me perturbe le plus c'est l'absence de définition des objets zones, trains, etc par comparaison avec celle du C++.
Mais là encore je ne connais pas le Java.

J'attend donc gentiment la version C++.
Je vais donc me plonger dans l'éditeur de Json en essayant de l'appliquer à mon réseau (en passant pas le Locoduinodrome 2 pour me faire la main).

C'est un travail énorme, bravo !

[Pierre59]

@ Dominique

Concernant les modes d'emploi il y a deux références à des posts précédents, une pour le fonctionnement général et une pour les boutons d'itinéraires qui sont expliqués sur le simulateur du PRS de Méru.

Comme je l'ai déja signalé le gestionnaire n'est pas écrit en programmation objet, mais sous forme de fonctions. Pour chaque message reçu par le gestionnaire il y a une fonction spécifique (voire deux pour les zones) qui traite le message avec l'aide de plein de fonctions annexes. Les variables du gestionnaire (zones, aiguilles signaux, …) sont dans le JSON. Cela devrait permettre de comprendre plus facilement le fonctionnement, plutôt que les objets et l'héritage, mais aussi de faciliter le passage au C/C++. Ce qui est écrit dans le gestionnaire c'est certes du Java, mais c'est quasiment du C/C++, la syntaxe du Java a repris en grande partie celle du C/C++ (il y a un article sur ce sujet : "Processing pour nos trains").

Pierre

[DDEFF]

Bonjour,

J'ai été pas mal occupé à d'autres tâches récemment et je n'ai pas beaucoup pu programmer.
Désolé de n'avoir pas suivi le fil...

Depuis la dernière fois, la partie itinéraire s'est étoffée :

Je ne trouvais, au début qu'un seul itinéraire, le plus court et ça s'arrêtait là…

Maintenant, je trouve tous les itinéraires techniquement possibles entre n'importe quel point A et n'importe quel point B.
J'ai adapté la partie "itinéraires" de mon programme de gestionnaire existant pour que ça marche ici aussi.

Plusieurs questions se posent :

1°) Le programme trouve tous les itinéraires possibles, sans tenir compte de la parité des voies.
Cela peut paraître une aberration, mais il ne faut pas oublier qu'il y a, même à la SNCF, toujours des "solutions de secours" en cas de dérangements.
Bien sûr, dans ces cas extrêmes, il y a des procédures de sécurité spécifiques, des signalisations provisoires, tout ce qu'il faut pour rétablir une circulation normale.

2°) Le temps de calcul d'un itinéraire est minuscule. Doit-on garder les itinéraires en mémoire, par exemple dans le JSON ?
On pourrait très bien envisager de les calculer "à la volée" dans le gestionnaire.

3°) Si on ne garde que certains itinéraires, sur quels critères ?

Dans mon programme JSON, j'ai un bouton "itinéraires" qui demande le nom de la zone de départ, le coté du départ, le nom de la zone d'arrivée, le côté de la zone d'arrivée.
Exemple dans le réseau de Dominique : Z25, côté 1, Z30, côté 1.

Premier problème, très simple :
Le "côté 0", c'est le côté du "voisin1", le "côté 1", c'est le côté du "voisin2". On voit tout de suite où est le problème…
Soit j'appelle "côte 1" et "côté 2", en ajoutant simplement 1, soit on appelle les voisins "vois0" et "vois1". Il faut juste se mettre d'accords.

Voilà le résultat littéral (il trouve 4 itinéraires) :
Z25 segment
signal1 signal
Z26 triple droit : a0 à gauche + a1 à droite
Z27 segment
signal1 signal
Z29 triple gauche : a11 à droite + a9 à gauche
Z30 segment
signal1 signal
 ------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
Z25 segment
signal1 signal
Z26 triple droit : a0 à droite
Z15 TJD : a2 à droite + a4 à droite
Z42 aiguille droite : a5 à droite
Z14 segment
signal0 -
Z43 aiguille gauche : a6 à gauche
Z12 TJD : a7 à gauche + a8 à gauche
Z29 triple gauche : a11 à gauche
Z30 segment
signal1 signal
 ------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
Z25 segment
signal1 signal
Z26 triple droit : a0 à droite
Z15 TJD : a2 à droite + a4 à gauche
Z13 segment
signal0 -
Z12 TJD : a7 à droite + a8 à gauche
Z29 triple gauche : a11 à gauche
Z30 segment
signal1 signal
 ------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
Z25 segment
signal1 signal
Z26 triple droit : a0 à gauche + a1 à gauche
Z44 aiguille gauche : a3 à gauche
Z28 segment
signal1 signal
Z29 triple gauche : a11 à droite + a9 à droite
Z30 segment
signal1 signal
 ------------------------------------- FIN DE L'ITINERAIRE -----------------------------------

On note :
- que les signaux ne sont pas (encore) calculés
- que on prend bien Z13 et Z14 "à rebrousse-poil" en regardant quel signal (0 ou 1) voit le conducteur
- que si on trouve une appellation meilleure que "segment", je suis preneur ("tronçon" ?)

Je pars en vacances une semaine et je ne pourrais pas programmer.

Denis

[Pierre59]

@ Denis

Trouver tous les itinéraires possibles entre n'importe quel point A et n'importe quel point B, n'a pas grande utilité, je pense qu'il faut plutôt définir des points d'origine d'itinéraires avec un sens et des points de destination d'itinéraires, ces points pouvant de façon plus générale être des zones.

Normalement les points d'origine sont devant un signal (ou sont des zones avec un signal) et il n'y a qu'un signal par itinéraire (sauf Cv bas).

Dans les grandes gares il peut y avoir plusieurs itinéraires possibles, mais en pratique en respectant les contraintes précédents je n'ai pas de souvenir d'avoir rencontré de problème avec des sens des voies (pair/impair). Par contre quand il y a plusieurs itinéraires possibles il faut absolument choisir, on a déja évoqué ce problème jadis et j'avais proposé de choisir l'itinéraire avec le moins de zones, tu n'étais pas d'accord alors, as tu un meilleur critère à proposer (faut que cela reste réaliste).

Le gestionnaire peut très bien rechercher les itinéraires à partir d'un point d'origine et d'un point de destination. Dans le gestionnaire JSON publié, il y a depuis le début dans l'onglet "Zones" deux fonctions "voiss1(String z)" et "voiss2(String z)" qui donnent tous les voisins (1 et 2) d'une zone, ces fonctions étant prévues pour la recherche automatique des itinéraires. Dans la dernière version publiée il y a dans l'onglet "Itineraires" une fonction expérimentale "itineraire(String zo,int c,String zd)" qui recherche un itinéraire d'origine "zo" en partant du coté "c" avec pour destination "zd" (le résultat est une liste de zones). Cette fonction est bridée pour s'arrêter au premier itinéraire trouvé, mais elle peut tous les trouver (reste à trouver un moyen de choisir).

Concernant les appellations des cotés (1/2, 0/1, pair/impair, … ), le problème est plus vaste que cela et je compte lancer une discussion sur le sujet (les "sens" en général).

Pierre

[Dominique]

Je suis aussi bien occupé avec la famille/amis (ce sont les vacances des enfants) 

[Dominique]

Je me remets dans le bain après une longue interruption et je vois le fichier JSON d'entrée du gestionnaire 2.2 de Pierre.
Il concerne le locoduinodrome 1 et contient les zones Z0 à Z6, les aiguilles A0 et A1, les signaux S1 à C6, les itinéraires XA à YB et une autorisation.

Je ne retrouve pas tout cela dans l'éditeur de Denis, version 5 qui concerne le locoduinodrome 2 et n'inclut pour le moment que les zones Z1 à Z7.

Est-ce que je me trompe ? Ai-je oublié une version ?

Donc, si je ne me trompe pas, le fichier JSON du gestionnaire de Pierre doit être la cible à atteindre pour l'éditeur de Denis et les deux cotés concerneront le locoduinodrome 2.

Cela permettra de passer au Locoduinodrome 2 coté gestionnaire, ce qui entrainera une évolution du TCO chez Pierre.

De mon coté je n'ai pas prévu de m'engager dans un TCO en Processing, restant en C/C++ pour le gestionnaire et un TCO graphique adressé en CAN.

En regardant le code du gestionnaire, j'ai un peu peur que le passage en C/C++ soit un énorme travail !

Bon courage à vous deux.

[Pierre59]

Je voudrais discuter des "sens" dans un gestionnaire. Je sais, par expérience, que les sens dans un gestionnaire posent des problèmes. C'est pour cela que dans le gestionnaire JSON expérimental j'ai essayé de ne pas expliciter dans le fichier JSON, les sens des voisins, des signaux et des balises avec des pair/impair, mais avec quelque chose de plus neutre, des nombres 1 ou 2.

Pour le gestionnaire appliqué à l'ancien Locoduinodrome cela n'a pas posé trop de problèmes. Mais pour le nouveau Locoduinodrome c'est plus compliqué, car plus de mal à retrouver le sens des signaux et des balises entre autre. J'ai donc remplacé les sens neutres (1 ou 2) par des sens plus explicites (pair/impair) et conformes à la circulation des trains, en fait dans le fichier JSON les 1 ou 2 sont replacés par P (pair) ou I (impair). Cela implique qu'il faille soigneusement déterminer les sens de circulation des trains sur chaque zone.
 
Les sens concernent beaucoup de choses dans un gestionnaire :

- les sens des trains, c'est ce qui est le plus consensuel, on a naturellement de trains pairs et des trains impairs (éventuellement on pourrait avoir des train sans sens);

- les sens des signaux, les trains pairs voient les signaux pairs et trains impairs voient les signaux impairs, ce qui induit le sens des signaux, sur voie double les train roulent à gauche, sauf en Alsace-Lorraine;

- les sens des balises, elles sont liés aux signaux, donc à leurs sens (mais d'autres balises que celles des signaux peuvent exister);

- les sens possibles de parcours des zones par les trains, c'est plus compliqué on peut avoir par exemple des sens pair, impair, pair-ou-impair (sans changement de sens possible), pair-et-impair (avec changement de sens possible), … ; on peut envisager aussi des manoeuvres avec ou sans sens (genre : "pair-ou-impair-manoeuvre" ). Ces informations servent pour le suivi des trains, pour contrôler les changements de sens des trains, … ;

- les sens liés à la désignation des voisins des zones, par homogénéité avec les cas précédents pair/impair convient bien;

- les sens de zones, est ce que l'on peut donner un sens aux zones et est ce que cela peut servir au gestionnaire.     


Il n'y a pas de problème de sens avec les boucles de retournement à double voie, mais il y a problème avec les boucles de retournement à voie unique, appelées raquettes, un train arrive sur une raquette avec un sens disons pair et en ressort avec un sens impair et vice versa. Il faut que le gestionnaire soit prévenu, par exemple avec une ou des balises dédiées (de toute façon il faut faire quelque chose au niveau alimentation électrique). Même problème avec les triangles de retournement et les plaques tournantes.

Pierre

[DDEFF]

Bonjour,

Post intéressant sur les sens. Cela pourrait paraitre ésotérique, mais c'est fondamental et pas aussi évident qu'on pourrait le croire.

Pour moi, il y a le sens lorsqu'on dessine le réseau :

Quand on trace un trait, on va de l'origine à l'extrémité, ce qui, chez moi, se traduit par aller du "côté 0" au "côté 1". Une fois dessiné, le "côté" est définitif.
Il s'ensuit que, pour les voisins, je verrais mieux "voisin 0" et "voisin 1", d'ailleurs.
Une fois décidé lors de la création du plan du réseau, c'est, là aussi, définitif.

Après, la notion de "pair/impair" me parait s'imposer.

Sur un réseau miniature, on est très souvent confronté à un ovale de voie, ce qui n'est quasiment jamais le cas dans la réalité.

Je propose de définir le sens "pair" pour le sens des aiguilles d'une montre et le sens "impair" pour l'autre sens, mais c'est parfaitement arbitraire.
 
Il en découlera des signaux "pairs" ou "impairs", des noms de voies "pairs" ou "impairs", des trains "pairs" ou "impairs".
Les zones qui pourront être parcourues dans les 2 sens seront "pairimpair".

Il faudra bien dessiner les signaux au bon endroit et ils seront "côté 0" ou "côté 1" de la zone, quelle que soit sa parité.
 
Dans le cas général, les signaux seront donc à l'extrémité de la zone, dans le sens normal de circulation, donc du "côté 1".

Après, il y a le sens de circulation. Là, on est dans le gestionnaire.

On se déplace sur des zones qu'on aborde en général par le "côté 0", mais qu'on peut aborder du "côté 1" suivant l'itinéraire, en particulier dans les zones "pairimpair". Le sens de circulation est donné par l'ordre des zones dans le déplacement.

Dans le JSON, on ne fera apparaitre que les itinéraires qui sont dans les gares et uniquement ceux qui ne vont jamais à contre-sens.

J'entend par "contre-sens" les déplacements de trains lors d'un accident, par exemple, et qui nécessitent une signalisation temporaire.
Les IPCS seront traitées comme "pairimpair", même si un sens est prioritaire.

Pour moi, un itinéraire en gare est constitué de 2 choses : une liste de zones et une liste de position d'aiguilles pour aller d'une zone à l'autre.

Denis