Projet partagé d'un gestionnaire de réseau

[DDEFF]

@ Pierre et autres

L'éditeur JSON qui rentre les segments et les appareils de voie peut permettre de rentrer n'importe quelle zone.



Si on découpe la zone complexe en morceaux ("pavés"), en utilisant un caractère spécial "/", on a Z1/1, Z1/2, Z1/3, Z1/4, Z1/5.
Chaque zone est décrite comme une autres (les voisins de Z1/3 sont Z1/1 et Z1/4)
Et, à la fin, on regroupe automatiquement tous les morceaux en une seule zone avec les (AC, AD, AE, AF, AG, BC, BD, BE, BF, BG) comme trajets de la zone.

Par ailleurs, dans un trajet, on met ["origine", "extrémité", ["aiguille","position"], ..., ["aiguille","position"] ], avec de zéro (pour les segments et les croisements) à "n" ["aiguille","position"] suivant la complexité de la zone.

Denis

[Pierre59]

Bonjour

Depuis quelques temps j'essaie de voir les avantages et les inconvénients des "trajets" et des "demi-trajets". Pour cela je vous joins des extraits json du Locoduinodrome dans les deux cas, c'est une partie caractéristique des zones (la version "trajet" est issue de Denis). Je joins aussi le dessin du Locoduinodrome.

Il faut aussi s'intéresser à la facilité des opérations courantes du gestionnaire :

- obtention de la zone voisine d'une zone donnée (d'un coté ou de l'autre) en fonction de la position réelle des aiguilles

- positionnement des aiguilles pour un itinéraire donné par une liste de zones (traité dans un sens ou dans l'autre), un itinéraire est proposé

- recherche automatique des précédents et suivants des signaux

- obtention de toutes les zones voisines d'une zone donnée (d'un coté ou de l'autre)

- autres ?

Pierre

[DDEFF]

Quelques éléments de réflexion :

1°) Quelle que soit la méthode employée, on va devoir afficher des formes (que ce soit pour les segments ou les appareils de voie) pour les itinéraires. J'ai bien dit "formes".

2°) Pour les appareils de voie, une seule et unique forme sera affichée dans un itinéraire.

3°) Il faut donc une fonction qui, pour un appareil de voie donné, affiche une seule forme, fonction de la position des lames.
Z3 :
A2 droit + A3 droit -> forme 0
A2 gauche + A3 gauche -> forme 1
A2 droit + A3 gauche -> forme 2

4°) Je ne veux pas rentrer quelque part la suite de zones des 180 itinéraires de ma gare.
Donc, il faut une fonction qui trouve cette suite toute seule, une fois l'origine et la fin de l'itinéraire donnés.

5°) Pour connaitre la zone suivante, dans les 2 sens, j'utilise la méthode suivante :

Au fur et à mesure de la lecture du fichier JSON, je crée une ArrayList des connecteurs.
Un connecteur c'est un point à la limite de 2 formes et, donc, de 2 zones :

ID, Zx, forme Nx, cote_x de la forme (0 ou 1) , Zy, forme Ny, cote_y de la forme (0 ou 1)

Par ailleurs, au fur et à mesure de la lecture du fichier JSON, je mets à jour, dans Zones,
 une variable ligne_connecteur[a1][b1].
a1 = n° de la forme et b1 = coté de la forme (0 ou 1)

Pour dessiner un itinéraire, on part d'un connecteur, du coté de l'avant du train (la loco ou le dernier wagon). Ça nous donne la zone d'origine et le coté origine.
En balayant l'ArrayList des connecteurs, côté Zx ou Zy, je trouve le connecteur origine.

Si c'est Zx, la zone suivante, c'est Zy, et réciproquement.
Supposons qu'on ait Zx. On va chercher dans la même ligne du connecteur Zy, avec le cote_y de la forme y
On va dans Zone y et on cherche ligne_connecteur[forme y][1-cote_y]
On va dans les connecteurs, directement à la ligne indiquée, et y cherche Zy (à gauche ou à droite).
Et on recommence.

Il n'y a qu'un seul balayage, au début, puis on suit par adressage direct. Et ça marche pour la signalisation et les itinéraires et dans les 2 sens.

Denis

[Pierre59]

@ Denis

Pour les points 1 2 3, je ne comprend pas, je ne vois pas ce que c'est une "forme".

Pour le point 4, pour éviter de coder 180 itinéraires, on sait faire des algos récursifs qui fournissent tous les itinéraires possibles, après faut faire un choix, on a déjà parlé de ces problèmes il y a un bon bout de temps. L'algo a juste besoin de tous les voisins des zones (avec les positions d'aiguilles associées).

Pour le point 5, dans le gestionnaire le fichier json est lu d'un coup pour produire un objet json, il faut donc aller dans cet objet json pour avoir les voisins d'une zone, c'est assez facile.

Pierre

[DDEFF]

@ Pierre,

Une forme, c'est le dessin d'un segment de droite, d'un arc de cercle, un arc de parabole (dans mon nouvel éditeur graphique).
Pour dessiner une aiguille, il faut dessiner 2 formes : un segment de droite et arc de cercle.
Toutes les formes sont noires et une seule forme est grise, fonction de la position des lames.

Sur le point 5, je ne demande qu'à voir, ça me parait très intéressant. 

Denis

[DDEFF]

@ Pierre

Si je suis les règles que tu as édicté pour les tjs le 30/01, j'obtiens le fichier PierreJson2.xtx joint.
Je me trompe ?

Denis

[Pierre59]

@ Denis

La notation   [[NULL,"A3","droite","A1","gauche"],   c'était juste un idée comme cela, pas forcement réaliste.

Dans le cadre du gestionnaire je suis en train de regarder les algos utilisants les voisins.

Pour le suivi des trains on a besoin des deux voisins (en fonction de la position des aiguilles), c'est un cas qui arrive très souvent quand une zone devient occupée.

Pour les itinéraires (prédéfinis ou automatiques) on a besoin des tous les voisins et en plus du "sens" des zones. C'est un cas qui arrive souvent.

Pour trouver automatiquement les précédents et les suivants des signaux, les besoins sont à peu près les mêmes que pour les itinéraires. Ce cas ne se fait qu'une fois (dans le gestionnaire ou dans l'éditeur).

Autres cas ?

Pierre
 

[DDEFF]

@ Pierre,

OK pour tes remarques, sauf la dernière : pour moi, le "signal suivant" dépend de la position des aiguilles et on ne peut pas le faire dans l'éditeur, sauf en pleine voie.

A part ça, j'ai une notion des itinéraires qui est une version SNCF "élargie", c'est à dire que, quand un train se déplace, il est toujours sur un itinéraire, indépendamment des gares, etc...

Il y a 2 types d'itinéraires :
- les itinéraires "bouclés", c'est à dire qu'ils tournent indéfiniment, jusqu'à ce qu'on les arrête.
- les itinéraires "à la demande" qui vont de la position actuelle du train (connecteur, sens) vers une destination choisie (connecteur, sens). Le train s'arrête quand il a atteint sa destination. On peut (et on doit) alors lui en reprogrammer une autre pour qu'il reparte.

Pour moi, on n'a pas de "bouton" (réel ou virtuel) qui modifie la position d'une aiguille. On n'a donc pas à gérer tout un tas d'enclenchements.

Les itinéraires sont enregistrés, de façon tout à fait indépendante de la position actuelle des aiguilles, des signaux actuels, des occupations actuelles...
On veut aller de là à là, quand ce sera possible, en toute sécurité. Il y a donc des zones "occupées par un itinéraire", mais physiquement vides.
Si le train est arrêté pour des raisons de sécurité, les zones aval ne sont pas (encore) occupées par un itinéraire. Ça se fait au fur et à mesure.

Par ailleurs, un itinéraire est donc une suite orientée de zones, elles aussi orientées une par une.

On peut construire l'itinéraire "par morceaux", c'est à dire qu'on part d'une gare, par exemple, et on demande un itinéraire pour une autre gare, avec une durée d'arrêt choisie dans cette gare intermédiaire. Puis on "ajoute", un autre itinéraire vers une autre gare où, par exemple, on ne s'arrête pas et, enfin, un troisième morceau vers une gare de destination où on s'arrête définitivement. Pour moi, tout ça, c'est UN itinéraire.

Si on entre, pour chaque zone, la longueur de la zone, on peut savoir à quelle distance réelle on est du signal suivant et en tenir compte dans les ralentissements.
En particulier, on peut connaître, pour un itinéraire donné, quel est le prochain feu S ou C et caler le ralentissement non pas sur le A, mais sur le S ou le C, ce que fait un conducteur quand il aperçoit un A.

Denis

[DDEFF]

Bonjour à tous,

Je procède actuellement à une refonte complète de mon éditeur pour pouvoir ajouter et supprimer des questions facilement. Le fonctionnement global sera identique.
Laissez moi quelques jours 

@Pierre,
J'ai compris la description du réseau par 1/2 trajets. Mais je ne vois pas de gain, pour l'instant, à mon niveau. Mais pourquoi pas ?

Denis

[Pierre59]

Bonjour

J'ai fait quelques essais de gestionnaire paramètré complètement par un fichier json, dans une version sans programmation objet.

Pour tester un gestionnaire il faut soit un réseau, genre Locoduinodrome, que je n'ai pas, soit un simulateur de réseau. Pour gagner du temps j'ai réutilisé le programme du TCO de l'ancien Locoduinodrome, ce programme fait le dessin du TCO du réseau avec les mises à jour dues aux circulations de trains virtuels, il comporte aussi deux manettes, avec cabsignal, pour commander les trains.

Le gestionnaire communique avec le TCO avec le protocole réseau TCP/IP. Il faut lancer le TCO avant le gestionnaire. Les deux programmes sur la même machine sinon il faut jouer sur l'adresse IP du gestionnaire.

Comme le TCO est prévu pour l'ancien Locoduinodrome, j'ai du écrire le fichier json le décrivant complètement. Le fichier json ne doit pas être vu comme un modèle, il y des redondances (noms), des infos pour des tests ...

Le fichier json est lu entièrement au début du gestionnaire et les variables nécessaires au fonctionnement du gestionnaire (états des zones, positions d'aiguilles, feu de signaux, ...) sont rajoutées automatiquement dans le json au début du programme. Ce qui veut dire que l'état du réseau est quasiment entièrement codé par le json.

Le gestionnaire est essentiellement composé de fonctions qui traitent les différents cas pouvant arriver sur les différents éléments du réseau (zones, aiguillages, signaux, itinéraires, trains, balises, ...)

Ces fonctions doivent traiter tous les cas possibles, elles sont donc moins performantes que des fonctions spécialisées (écriture à la main et/ou programmation objet).

Le gestionnaire comporte deux fichiers json (onglets Z1 et Z2), celui de l'ancien locoduinodrome et celui du nouveau (incomplet). Les deux onglets me servent d'éditeur pour les fichiers json, pour l'instant.

Le gestionnaire a été écrit à l'arrache, c'est juste pour voir si c'est possible. Quand j'aurais un peu de temps j'essairai d'améliorer le gestionnaire et de corriger des bugs, et quand j'aurais beaucoup de temps je retoucherais le TCO pour utiliser le nouveau locoduinodrome et faire des test plus poussés.

Il y a d'autres façons de faire un gestionnaire paramètré par un fichier json, ne pas hésiter à proposer d'autres solutions. Il faudra aussi porter le gestionnaire en C (C++) sur un gros micro-contrôleur (genre ESP32).

Pierre

PS 

quelques commandes possibles : 

- changement de sens d'un train : clic sur la flèche (si le gestionnaire le veut bien)

- arrêt d'urgence d'un train : clic sur le bouton STOP

- changement de vitesse d'un train : drag dans la bande (si le gestionnaire le veut bien)

- établissement d'itinéraire : clic sur bouton correspondant (le bouton clignote si mise en attente)

- destruction d'itinéraire : re-clic sur bouton correspondant

- passer la souris au pied d'un signal permet de voir le signal avec les bons feux


Ne pas avoir peur de faire rouler les trains en pousse, le sens n'a pas d'importance avec ce type de gestionnaire.

L'enclenchement d'approche n'est pas actif pour le moment

[DDEFF]

Bonjour,

A chaque fois que je vois les programmes de Pierre, je mesure tout l'écart qui peut exister entre mon type de programmation, où je me débrouille avec le peu de fonctions de que j'ai comprises, et les siennes, où tout est objet, compact, avec un "vocabulaire" puissant que je ne connais pas. C'est très intimidant.

Bien sûr, je comprends quand même une bonne partie de ce qui est fait, mais heureusement qu'il y a les commentaires...

Ceci étant, j'ai quasiment fini mon éditeur JSON. Je vois qu'il va falloir y a jouter les types de signaux et les itinéraires (mais, là, ça me chagrine).
Il y génèrera les 2 types de JSON (par trajets et par voisins)

Faire un JSON "à la main", c'est tout à fait faisable, c'est même relativement facile (surtout pour un Locoduinodrome).
Mais on peut très facilement se tromper ou corriger dans un coin et ne pas faire la modification correspondante ailleurs.
Je tiens donc à ce que, grâce à un éditeur, on ne puisse pas laisser d'erreurs et que tout soit cohérent.

Denis

[Dominique]

Après une petite semaine de combat contre les virus et microbes je viens de télécharger ce premier gestionnaire paramétré par un fichier Json éditable ici, sous forme d'onglet.

Mes impressions sont le suivantes principalement par rapport à ce que je m'attendais à voir venir.

1) C'est du Processing donc ça ne peut pas tourner dans un Arduino (Due, ArmXX) avec une connexion Can qui permet de récevoir tous les messages des capteurs (occupation, ponctuels, RFID/Railcom) et d'émettre tous les messages vers les actionneurs (aiguilles, signaux et surtout la centrale DCC en l'occurence LaBox).
Bien entendu la connexion existe entre le gestionnaire et le TCO. Mais je n'ai pas pu faire rouler de train virtuel, ce qui n'est pas nécessaire sauf pour tester à fond les paramètres .

2) J'ai eu du mal à retrouver les objets, propriétés et méthodes habituelles du gestionnaire en C++ et comprendre l'intégration des paramètres Json dans ces méthodes (ou fonctions ici, puisque ce n'est pas encore de l'objet)

Mais il ne faut pas voir mes premières impressions comme négatives car je sors d'une période d'invasion microbienne et de grande fatigue dont je ne suis pas rétabli.

Je serais donc très intéressé de savoir un peu à l'avance quel sera le chemin d'évolution et la cible visée du gestionnaire parametrable et je me rend compte du travail important que cela représente.

Actuellement je travaille sur mon nouveau TCO graphique sur bus Can qui est donc maintenant séparé du gestionnaire et je me prépare à tester cette évolution majeure du gestionnaire centralisé.

Bravo à Pierre et Denis pour le travail important déjà fourni .

[Pierre59]

Mes impressions sont le suivantes principalement par rapport à ce que je m'attendais à voir venir.

1) C'est du Processing donc ça ne peut pas tourner dans un Arduino (Due, ArmXX) avec une connexion Can qui permet de récevoir tous les messages des capteurs (occupation, ponctuels, RFID/Railcom) et d'émettre tous les messages vers les actionneurs (aiguilles, signaux et surtout la centrale DCC en l'occurence LaBox).

Oui c'est du Processing, car pour moi c'est beaucoup plus rapide à écrire et à tester, une version du gestionnaire pourra rester comme cela. Mais une version C/C++ pourra aussi être portée sur Arduino.

Bien entendu la connexion existe entre le gestionnaire et le TCO. Mais je n'ai pas pu faire rouler de train virtuel, ce qui n'est pas nécessaire sauf pour tester à fond les paramètres .

Tu dois pouvoir faire rouler les trains virtuels, il suffit de faire avec la souris un drag vers le haut (déplacement de la souris avec le bouton enfoncé) dans une des bandes verticales à droite de l'écran. Les trais s'arrêtent automatiquement aux signaux fermés.

2) J'ai eu du mal à retrouver les objets, propriétés et méthodes habituelles du gestionnaire en C++ et comprendre l'intégration des paramètres Json dans ces méthodes (ou fonctions ici, puisque ce n'est pas encore de l'objet)

Il n'est pas vraiment prévu d'objets. Tout le gestionnaire est écrit avec des fonctions, dans le but de faciliter la réécriture en C/C++.

Je serais donc très intéressé de savoir un peu à l'avance quel sera le chemin d'évolution et la cible visée du gestionnaire parametrable et je me rend compte du travail important que cela représente.

Petit à petit je vais améliorer le gestionnaire en Processing, et passer au nouveau Locoduinodrome (gros travail avec le tco).
J'ai commencé à regarder le portage en C/C++ sur un ESP32 bi-coeur, mais j'ai plein de problèmes avec IDE Arduino au niveau des cartes et des bibliothèques (json).

Pierre

[Dominique]

J'ai commencé à regarder le portage en C/C++ sur un ESP32 bi-coeur, mais j'ai plein de problèmes avec IDE Arduino au niveau des cartes et des bibliothèques (json).

Je n’avais pas bien lu le mode d’emploi du TCO, donc je vais y retourner, perturbé par mes microbes !

Pour l’IDE je me demande s’il ne serait pas profitable d’embrayer sur PlatformIO, au moins pour les projets les plus complexes comme celui-là, les dernières versions de l’IDE Arduino se révélant moins stables.
Mais honnêtement il faudra présenter PlateformIO dans un article, ce à quoi je songe actuellement.

[DDEFF]

Bonjour,

Je n'arrive pas à faire marcher le programme GestTCO2. Quand j'appuie sur un bouton d'itinéraire, il ne se passe rien.
L'autre programme (GestJ2) plante.
Il faut un mobile ?

Denis