Voir les contributions
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: Aujourd'hui à 06:27:04 pm »
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 !!
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 !!
