Projet d'utilisation du gestionnaire en C++ de Pierre59

[Bug Killer]

J'ai extrait du code les fichiers les plus impliqués dans la gestion de la circulation. Ils sont dispos ici.

[Dominique]

Merci beaucoup,

J’ai suivi le projet D17 il y a un certain temps, bravo, quel boulot 

Il y a beaucoup de fonctions intéressantes que je vais regarder progressivement. Je te demanderai ensuite comment ces fonctions sont appelées à partir des détections.

Dans mon réseau, le parsing des messages Can fait l’appel à toutes les fonctions de suivi et régulation. J’essaye de faire simple et c’est pas évident !

[Bug Killer]

CentraleD17 est beaucoup plus complexe que SourisD17, la première version de mon projet. Mon cahier des charges était :

- toutes les communications en TCP/IP.
- échanges avec la centrale à base de Wemos D1 mini réduits au strict minimum.
- plusieurs stations gèrent le réseau en simultané.
- les stations affichent des informations synchronisées.

Les stations ne se connectent donc pas au Wemos mais à CentraleD17 qui gère les flux de données entre la centrale, le système de contrôle-régulation et les clients. Il y a 6 modules :

1. Le client interface avec D17 (ClientD17). Protocole à modifier pour s'adapter à une autre centrale.
2. Le serveur de flux ServeurD17. Protocole à modifier pour s'adapter à une autre centrale.
3. Le contrôleur-régulateur
4. Le client interface avec ServeurD17.
5. Le gestionnaire de TCO
6. Le(s) gestionnaire(s) d'interface de conduite. Actuellement 14 "souris". En préparation 4 "cabines".

Tous ces modules sont dans CentraleD17 ainsi que la gestion de la base de données d'état du réseau. CommandeD17 comprend 4, 5 et 6. ConduiteD17 4 et 6. CommandeD17 et ConduiteD17 n'agissent donc pas directement sur la centrale mais envoient des requêtes à CentraleD17. Son module de contrôle-régulation vérifie si elles sont exécutables. Lorsqu'elles le sont, il envoie des requêtes au Wemos et le résultat aux stations concernées.

Exemple : sur un ordinateur exécutant CommandeD17 l'utilisateur clique sur le bouton de construction d'un itinéraire. Localement, CommandeD17 n'a aucune idée de la faisabilité de la construction. Cette requête est envoyée à CentraleD17 qui vérifie si elle est exécutable. Si elle l'est, les appareils de voie et les signaux sont manœuvrés par une requête envoyée au Wemos et les blocs concernés sont marqués. Le changement d'état des ADV et l'état "construit" est envoyé aux stations exécutant le module 5. Le changement d'état des signaux est envoyé aux ordinateurs qui exécutent les modules 5 et 6. Si la requête n'est pas exécutable immédiatement, l'itinéraire est "en attente de construction". Cet état est envoyé aux stations exécutant le module 5.

La centrale ne retourne que très peu d'informations :

- état de l'arrêt d'urgence car un bouton matériel est présent sur son boîtier
- niveau de consommation de courant
- état des détecteurs, 96 bits, nombre ajustable
- état des ADV, 48 bits, nombre ajustable, une fois pour ceux à gauche, une fois pour ceux à droite
- état des variables utilisateur, 96 bits, nombre ajustable
- résultat de la lecture d'un CV
- résultat de l'écriture d'un CV
- résultat de la comparaison d'un CV

ServeurD17 interroge l'état du Wemos à chaque fois qu'il envoie un paquet de requêtes ou au bout de 125ms sans requête.

Actuellement, il n'y a pas de gestion centralisée des fichiers contenant les profils des engins moteurs et la description des TCO. Ces fichiers texte doivent être présent à l'identique sur tous les ordinateurs.

[Dominique]

Effectivement c'est énorme et curieusement la doc de la sourisD17 fait... 17 pages !

J'ai une approche différente de la gestion de mon réseau, voir ici.

J'interconnecte sur un même bus CAN :

• une centrale DCCpp à commandes manuelles par 12 potentiomètres (récupérés sur une table de mixage) qui permet donc le pilotage manuel de 12 trains (dont un parametrable). Chaque train peut être configuré (adresse, crans aux vitesses caractéristiques 15, 30 60, 90, sens inverse ou non, cran max, etc..) La centrale peut-être pilotée via Can (DCC on/off, mesure de courant, commande de chaque machine et les commandes de conduite sont envoyées sur le Can vers le gestionnaire, ainsi que les DCC on/off.
• une carte de commandes des aiguilles à bobine, par messages Can émis par le gestionnaire avec retour de messages d'état des aiguilles ou interrogation
• une carte TCO qui représente le dessin du réseau avec un voyant d'occupation par zone, un inverseur pour positionner les aiguilles et 2 leds de position pour chaque aiguille. Cette carte est connectée aux détecteurs d'occupation et c'est elle qui envoie les messages d'occupation au gestionnaire
• quelques satellites V1 adaptés pour des détections RFID (4 pour le moment de chaque coté de la gare principale, pour récupérer les numéros des trains qui passent à ces endroits) et des détections ponctuelles genre zone d'arrêt devant les signaux (j'en ai mis 4 dans la gare principale et 4 dans la gare cachée pour le moment). Ces satellites envoient des messages Can pour les détections et reçoivent des commandes de signaux
• Une centrale de va et vient qui peut fonctionner de façon autonome
• Une centrale de configuration de CVs qui, pour le moment est autonome
• Un gestionnaire de réseau comprenant un Arduino Due, une interface CAN et un écran graphique et tactile 5 pouces (bientôt 7 pouces). C'est lui qui doit assurer le suivi, la régulation, l'affichage sur son propre écran et permettre un certain nombre de commandes de scenarii de circulation
• J'ai prévu d'ajouter plus tard des commandes du gestionnaire et de la centrale avec une passerelle Wi-Fi- Can

Ce projet se veut de rester simple (si on peut dire !) sans PC ni tablette (jusqu'au moment ou la passerelle WiFI-Can existera, bien que je n'envisage pas de développer de soft sur PC/Tablette.

Donc le fonctionnement général s'articule autour de la messagerie Can, avec un identifiant par type d'événement. Le gestionnaire est basé sur celui de Pierre59 : tous les objets zone, aiguilles, signaux, itinéraires et trains sont adaptés pour mon réseau et un "double" graphique réprésente chaque objet sur l'écran, ce qui permet une mise au point facile et pratique.

Il y a donc dans la loop du gestionnaire un Parser qui analyse chaque message Can et fait ce qu'il y a à faire.

Je n'ai pas fini de développer le suivi et la régulation pour tous les trains, en m'attachant d'abord de ne traiter que les trains automatiques (avec des horaires) et en laissant les manoeuvres en manuel (ce qui peut arrêter un train automatique pendant une manoeuvre).

Pierre59 constatera que je n'avance pas vite, mais je fais durer le plaisir 
Et je pense que ton projet va m'aider à avancer et à découvrir ce que j'ai oublié. Cependant je fais des hypothèses simplificatrices qui vont probablement poser problème dans des cas particuliers, mais j'adapterai en conséquence.

En tout cas merci pour ton partage.

[Bug Killer]

SourisD17 est un programme simple qui confie toute la régulation au croquis embarqué dans le Wemos. Le contrôleur à écrire n'utilise pas d'objets, seulement des évènements à traiter dans des fonctions. Il convient bien à un petit réseau avec un seul poste de commande et une ou deux souris sous Android. La mise au point du contrôle et de la régulation est très difficile car tout se passe dans le Wemos.

CentraleD17 et ses satellites sont plus complexes mais, avec le simulateur intégré, la mise au point est facile. Je déplace les trains pas à pas et j'examine ce qui se passe avec les outils de mise au point de l'IDE. L'utilisation des objets dérivés de ceux de Pierre59 permet de traiter chaque cas complexe isolément et, pour les cas simples, sans voies de service, son BAL fonctionne tout seul.

J'envisage d'utiliser un Raspberry Pi 400 avec un écran tactile pour faire tourner au moins un des postes de commande. Pour le fun.

[Dominique]

J'ai extrait du code les fichiers les plus impliqués dans la gestion de la circulation. Ils sont dispos ici.

En effet c'est trapu !
Le plus difficile ce sont les occupations (comment retrouver l'adresse DCC du train qui entre ou qui sort) et les libérations.

De mon coté, je note dans chaque train les enchainements de zones concernées par le train, partant qu'un train tient en entier dans une zone : la zone prévue (la suivante c+1 dans le sens de la marche), la courante (c), la précédente (c-1 - en général occupée en même temps que la courante c et qui impose un arrêt d'un train suiveur), la c-2 qui impose un ralentissement et la c-3 qui peut être libérée. Avec ce principe je n'ai plus besoin de traiter les libérations, sauf en cas de perte de wagon si les essieux sont graphités. Un train prévu est écrit dans c+1 pour le reconnaitre rapidement. Et dans c aussi pour les cas de détections multiples.

En cas de perte de train, je me sers des messages de traction qui me disent qu'un train roule donc va provoquer une détection de présence en arrivant dans une zone : l'événement d'occupation qui suit est pour lui en général, à condition qu'il n'y ait qu'un seul train qui roule à la fois. C'est un moyen de localiser les trains posés ou arrêtés n'importe où au démarrage et ça peut s'automatiser en pilotant les trains un par un par le gestionnaire. Et en plus le RFID recale les trains automatiquement au passage. Il n'y a pas besoin d'en mettre partout, ni du Railcom (que je n'ai pas).

C'est la partie la plus interessante et la plus compliquée du développement, avec beaucoup de sorties moniteur pour comprendre ce qu'il se passe (d'où le choix du Due qui encaisse bien, mais plante facilement en cas de pointeur erroné).

Avec la possibilité de 2 trains par zone, tu t'es bien compliqué la vie.

[Bug Killer]

Si un train doit toujours tenir en entier dans un canton, il ne peut pas toujours tenir entièrement dans une zone. A l'entrée ou la sortie de ma gare principale, un train peut occuper jusqu'à 6 zones consécutives dont la liste varie en fonction de la direction des appareils de voie. Il peut être à cheval sur une zone de BAL (ralentissement ou arrêt), une zone d'ADV et une zone de service.  Ce n'est cependant pas le plus compliqué à gérer. Ce qui a beaucoup compliqué, c'est ma fixette sur la possibilité de scinder et joindre deux trains dans une zone.

[Bug Killer]

J'ai modifié les objets pour obtenir un affichage des signaux dans les postes de conduite plus réaliste. Désormais, au lieu d'afficher le signal de sortie de bloc dès que le train entre dedans, il n'est affiché que lorsqu'il entre dans la dernière zone avant la sortie. J'ai mis à jour les fichiers disponibles ici. J'ai inclus les objets de mon projet de réseau avec le code des boucles de retournement et des tables tournantes.

[Bug Killer]

Améliorations et corrections, notamment du traitement de la séparation de deux trains dont l'un quitte la zone en circulant en sens impair.

[Dominique]

C’est un très beau développement et on comprend bien la définition du réseau en lisant le fichier SchemaBK.h où se trouvent tous les objets dérivés.

Le simulateur pour la mise au point est une excellente idée.

Merci pour ce partage. Je m’en inspire 

[Bug Killer]

Depuis la publication précédente j'ai ajouté l'affichage d'une cabine et celui des pancartes et tableaux, une seule pancarte ou tableau par cabine ou mini cabine de conduite.

[Dominique]

C’est splendide 

Il ne manque plus que la caméra à l’avant de la loco et l’image à droite du panneau !! 😜

Ca va me pousser a ajouter des postes de conduite sur le bus Can. J’y pense en version individuelle (et sans caméra car en N c’est dur).