13
« le: février 18, 2024, 11:59:52 am »
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