Projet partagé d'un gestionnaire de réseau

[trimarco232]

il y a différentes approches
dans le réseau analogique que j'ai câblé , dans la partie basse de l'ovale , le sens impair (tu commences par le sens pair , je commence par le sens impair ..) , est de la gauche vers la droite , comme pour ta proposition
mais dans la partie haute de l'ovale aussi ! ceci pour s'éviter des nœuds dans le cerveau , cad. s'obliger à raisonner et dessiner tantôt de la gauche vers la droite , tantôt l'inverse
bien entendu , chaque principe a ses inconvénients : cela m'a obligé , aux extrémités gauche et droite de l'ovale , de définir le nez-à-nez comme étant accepté , et donc d'interdire le passage dans le même sens ; mais cela s'est avéré globalement plus logique , simple , et conforme la réalité

[DDEFF]

@trimarco232,

Tu comprends mieux, maintenant, pourquoi je fais cet éditeur de JSON.

La notion d'aiguille "à gauche"/"à droite", pourtant très simple, comme notion, peut faire faire des nœuds au cerveau, de même que la notion de voisin "côté 0" et "côté 1".
On se tord le coup, on regarde ses doigts en se mettant à la place de l'objet...

Avec mon éditeur, c'est dessiné, à chaque fois, dans le bon sens, et c'est le programme qui gère les "à gauche"/"à droite"...
On a nettement moins d'erreurs.

J'ai un bouton appelé "analyse" qui complète les infos de façon cohérente.
Je suis en train de calculer la signalisation : dire, pour chaque signal, quels feux il est susceptible d'afficher, de façon à prévoir la bonne cible et la bonne appellation.
Et c'est là que connaitre tous les itinéraires possibles va me servir, en retirant ceux qui, bien que techniquement valables, ne sont pas validés (zones à contre-sens).
Je mettrais, après, dans le JSON ceux qui ne concernent que la gare, la zone de manœuvre et les zones d'approche correspondantes.

Denis

[trimarco232]

merci André ,
as-tu édicté des règles , pour la conception d'un réseau susceptible d'être animé par ton gestionnaire ?

[DDEFF]

André ??

Non, pas encore, j'en suis à l'éditeur de JSON. Et c'est déjà du boulot.
Par contre, Pierre en a proposé un en processing (post #396 du 06/04/24)

Denis

[Dominique]

Après quelque temps occupé par divers travaux et événements familiaux, de retour à la montagne, je plonge dans les derniers programmes Processing de Pierre : GestJ2 et GestTCO2.

Celui qui m'intéresse le plus est GestJ2 car c'est le gestionnaire pur et dur. Il est écrit en Java (ou Processing, c'est pareil ?) et j'arrive a faire des analogies avec les objets C++ comme dans la version C++ que j'utilise.

Les grandes différences avec mon gestionnaire C++ sont :
- la description des objets (zones, aiguilles, signaux, trains, ..) est issue d'un fichier JSON qui serait préalablement construit avec l'éditeur de Denis (je vais en reparler plus loin).
- les événements de rétrosignalisation (occupations, libérations, commandes des trains et des itinéraires, ..) sont générés sous forme de messages TCP en provenance de GestTCO2 : c'est donc de la simulation et non du réel, mais j'imagine bien qu'on pourrait détacher ce TCO et le remplacer par les événements réels d'un réseau.

Première remarque : le but est théoriquement bien atteint pour le gestionnaire paramètrable qui est le point de départ de ce fil du forum. Bravo !

Un tel gestionnaire pourrait donc être réalisé sous forme d'une carte Arduino "connectée". En gros, on aurait ainsi l'équivalent d'un JMRI, RocRail ou CDMRail sans PC !!

- connectée à un éditeur de réseau JSON qui servirait à paramétrer le gestionnaire en fonction du réseau du modélistes.

- connectée aux capteurs d'occupation/libération et autres capteurs (ponctuels, RFID, RailCom, etc..) du réseau réel.

- connectée à la centrale DCC pour les commandes des trains (régulation, automatismes, ..) et récupérer les états de mouvement des trains (direction, vitesse), ainsi que les incidents éventuels.

- connectée à un TCO graphique qui permet de visualiser ce qui se passe sur le réseau réel (ou simulé) - dans ce cas la description du réseau JSON du gestionnaire est à dupliquer en liaison avec des rendus graphiques pour une interface humaine sympathique.
Dans l'exemple GestTCO2, le TCO permet de commander les trains, les itinéraires, voire les aiguillages. Ce TCO simule les déplacements des trains et génère automatiquement,ent les occupation et libération. Il fait tout ce qui est décrit plus haut, sauf l'éditeur de fichier JSON qui est développé séparément par Denis.

Si on met tous ces éléments bout à bout, on obtient un gestionnaire complet comme JMRI, RocRail ou etc. qui ne tourne que sur PC/Mac, voire Rpi (mais ça rame peut-être)

Deuxième remarque : ce TCO GestTCO2 est beaucoup plus compliqué que le gestionnaire GestJ2

Mais on en a besoin pour voir et commander les trains et le réseau. Du moins en mode simulation.

Troisième remarque : si je dois appliquer tout ce travail à mon réseau Dominique, que dois-je faire ?


C'est mon avis évidemment et je peux me tromper :

1) traduire en C++ le gestionnaire GestJ2 pour l'installer dans un Arduino (Due en ce moment ou à base d'ARM, avec assez de mémoire et de CPU, mais cela ne semble pas critique)
2) la description en fichier JSON n'a besoin d'être faite qu'une seule fois donc inutile de construire un éditeur connecté au gestionnaire, l'intégration à la compilation est suffisante.
3) connecter toute la rétrosignalisation via un bus CAN ce qui est déjà fait ou très simple à faire la plupart des microcontrôleurs sont capables de communiquer en CAN : libérations, occupations, signalisation, aiguillages, et bien plus si affinité.
Toutefois, passer du mode simulation au mode réel en remplaçant les messages "parfaits" du TCO GestTCO2 par des messages Can qui ne seront pas forcément parfaits, nécessitera (comme actuellement) des travaux de mise au point et du monitoring des événements et états pour la mise au point.
Sans oublier la centrale DCC déjà reliée au CAN (Mega+DCCpp ou LaBox).
4) connecter un TCO graphique pour visualiser ce qui se passe, ce que j'ai déjà en chantier sur un écran 7" piloté par un Teensy3.6 (en passant, je regarde le développement des tableaux de bord de voitures qui ont des écran superbes dont les prix finiront par devenir abordables, mais seront-il accessibles aux programmeurs ferroviaires ??).
5) connecter éventuellement des organes de commandes des trains (les applications smartphone comme Z21 font l'affaire), des itinéraires et horaires, etc.. sur le TCO graphique en principe.

En ce qui concerne l'éditeur de Denis, pour obtenir le fichier JSON de description du réseau pour le gestionnaire, cela représente un développement important qui serait mieux valorisé s'il faisait partie d'un éditeur de réseau : pour le gestionnaire ET pour le TCO.
Je sais que ce n'est pas l'objectif initial de ce projet mais Denis a déjà plus ou moins cela dans son PC.
Donc l'avenir va être interessant !!

[DDEFF]

Merci Dominique !

J'admire ton optimisme ... mais ton expérience est biaisée.

Ton réseau a été présenté dans Locoduino et a servi de modèle.
A l'époque, Pierre, qui maîtrise parfaitement les subtilités de la signalisation de la SNCF, a réalisé des articles très complets sur ce que doit être un gestionnaire.
Ces articles sont toujours d'actualité, d'ailleurs.
Puis tu lui a demandé de t'expliquer où mettre des signaux et de quels signaux il s'agissait sur ton réseau, ce qu'il a fait.
Dans son programme, la description des signaux (et du réseau) est intégrée et ça fonctionne chez toi parfaitement.
En lisant le programme, tu as compris comment cela avait été fait. Mais aurais tu pu le trouver tout seul ? On ne le saura jamais...

En refaisant ce nouveau fil de discussion, on a décidé d'extraire les infos descriptives du réseau dans un fichier JSON.
L'idée était que l'on puisse avoir un point de passage clair, précis, adapté à n'importe quel réseau SANS CONNAISSANCES SNCF.
Donc, lorsque ce fichier aura subi tous les tests, il sera labellisé Locoduino.

A ce moment, n'importe qui pourra faire un éditeur dont le fichier de sortie sera le JSON Locoduino et il pourra dès lors utiliser le gestionnaire que Pierre est en train tel quel pour commander ses trains.
Le gestionnaire doit être "neutre", c'est à dire qu'il doit fonctionner à partir du fichier JSON (et rien d'autre).
De la même façon, si quelqu'un sait faire un gestionnaire qui fonctionne à partir du fichier JSON Locoduino de son réseau, il pourra utiliser mon éditeur pour générer le fichier JSON.

J'ai fini la partie "générer tous les itinéraires possibles d'un réseau", itinéraires qui contiennent la position des signaux.
Moyennant une partie de programme à faire, je vais calculer quel signaux doivent être affichés pour un signal donné, ce qui permettra de définir la cible (A,B...H) à acheter pour ce signal.
Les itinéraires de la gare seront extraits de la liste complète et intégrés dans le JSON, de façon à ne plus avoir à les calculer dans le gestionnaire.

Donc : je ne connais pas la signalisation SNCF, je sais juste qu'il doit y avoir un signal là, là et là. J'appuie sur un bouton et le programme me dit:
Là, il doit y avoir VL, A, S et RR, là C, A, R, etc...

Pour info (c'est totalement anecdotique) mon programme trouve et affiche en détail en 6 secondes la liste des 2 572 itinéraires possibles de ton réseau, parmi 3 582 couples départ/arrivée testés 

Denis

[Pierre59]

Bonjour

Je suis tombé récemment sur un petit problème avec le gestionnaire json, ce gestionnaire utilise un transit souple. Dans un transit souple dès qu'une zone d'un itinéraire est libéré après le passage d'un train, elle peut être utilisée par un nouvel itinéraire.

Prenons un cas concret, illustré par le bout de tco ci dessous, le train bleu parcours l'itinéraire de A vers X, le train rose est en attente de l'itinéraire de X vers 1 qui est en mémoire. Dès que le dernier essieu du train bleu libère la zone de la tjs, l'itinéraire en attente se forme et le train rose peut passer sur la tjs. Cela parait tout à fait normal et cela l'est.

Mais en pratique avec un réseau réel, sncf ou miniature (j'ai fait des essais sur mon réseau HO), quand le dernier essieu du train bleu quitte la zone de la tjs, le bout de la caisse du dernier véhicule engage encore le gabarit de la zone tjs et se ferait percuter par le train rose si le train bleu s'arrêtait.

Ce problème est assez général et peut se produire avec toutes les traversées entre deux voies à l'entrevoie minimum.

Des idées, des solutions ?

Pierre

[Dominique]

Ne serait-il pas opportun d’inscrire et d’utiliser la longueur des trains dans leur objet et la comparer à celle des zones traversées et l’outil “provenance” ?

Évidemment cela ne nous met pas à l’abri d’une perte de wagon mais la détection de présence dudit wagon peut générer une erreur par rapport au passage du train complet.

Il faudrait donc compléter l’initialisation des trains avec des données plus larges, ce qui implique de préparer des compositions de trains à l’avance. Il y a longtemps que je ne suis rendu compte qu’on ne peut pas mettre n’importe quel wagon derrière une machine ou un wagon, à cause de la fiabilité aléatoire des attelages dans les courbes et les zones d’aiguille, surtout en N.

Quand les enfants viennent jouer, des trains non initialisés fichent la pagaille et je ne demande si on peut réduire cet inconvénient (zones pas libérées entre autres).

[Pierre59]

Le gestionnaire json comporte déjà un compteur du nombre de zones occupées par un train, une borne max permettrait de détecter les ruptures d'attelage.

On peut aussi, lors d'une libération d'une zone par un train vérifier que la (ou les) précédente(s) ne contient plus ce train, ce doit être la dernière zone du train.

Pierre

[trimarco232]

Bonjour,
subordonner , dans ce cas , la libération de la tjd. à celle de l'aiguille du bas ...
ou ne pas faire de transit souple , c'est pas indispensable en MF ...

[Dominique]

@pierre,

J’ai cherché l’équivalent des initializations des objets zone, aiguille, signaux, trains, etc à partir du fichier JSON (Z1.osé) en C++ pour Arduino.
Mais je n’ai rien trouvé de simple et compréhensible même dans les projets Arduinojson de Blachon et d’Arduino.
En Java, l'objet "doc" peut être décomposé simplement en objets "zone", "aigullle", etc.. directement utilisables ensuite par le programme.

En C++ ça semble bien plus compliqué.

J’ai peur que la version C++ du gestionnaire représente un gros boulot !

[Pierre59]

@ Dominique

Pas d'inquiétude, la bibliothèque "Arduinojson" a tout ce qu'il faut. C'est un peu déconcertant car l'opérateur [] du C++ est redéfini pour accéder aux éléments du fichier json, mais en définitive l'écriture est plus compacte et plus lisible. J'ai déjà fait des essais.

Pierre

[Dominique]

Merci Pierre, mon optimisme se confirme donc.

Je vais pouvoir refaire complètement mon gestionnaire sur cette nouvelle mouture, même si la configuration est déjà faite sans le json car la version actuelle a été tellement modifiée qu’il vaut mieux repartir sur un bon pied.