Auteur Sujet: Projet partagé d'un gestionnaire de réseau  (Lu 108752 fois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #435 le: juin 07, 2024, 09:54:25 am »
@ Denis

Quelques réponses à tes questions :

Citer
1°) Il y a un fichier JSON indépendant qui ne sert pas ?
2°) Tu as 2 onglets Z1 et Z2 j'imagine que Z1 est une ancienne version et que tu utilises Z2 ?
L'onglet Z1 est le json pour l'ancien Locoduinodrome (voie unique en boucle avec évitement), l'onglet Z2 est le json pour le nouveau Locoduinodrome  (voie double en boucle avec évitement)
Citer
3°) Tu utilises maintenant pairETImpair, pairOUImpair. C'est quoi la nuance ?
Pour l'instant il y a quatre cas :
- pair
- impair
- pairOUImpair : pas de changement de sens possible (zones d'aiguilles)
- pairETImpair : changement de sens possible (zones à quai, zones de manoeuvres, ...)
Citer
4°) Comment tu coderais une zone sans feux (dans une zone de manœuvres, par exemple) ?
Comme les autres mais sans signaux
Citer
5°) Plutôt que des 0/1, tu utilises exclusivement les notions de pair/impair, partout ?
Oui c'est beaucoup plus simple pour le gestionnaire
Citer
6°) C'est quoi, les balises ?
Le but ultime c'est d'arrêter les trains, même en pousse, juste devant un signal fermé. Pour cela le gestionnaire pourra mettre en oeuvre une odométrie pour localiser les trains. Les balises sont juste une détection ponctuelle des trains un peu avant le signal, cela permet de corriger les erreurs de l'odométrie. En attendant cela sert à arrêter les trains, même un peu brutalement, pour assurer la sécurité, en évitant les zones d'arrêt avec tous les problèmes que cela pose
Citer
7°) J'ai un peu de mal avec tes aiguilles : tu as 2 aiguilles dans une bretelle, ce qui est logique, mais je ne vois pas de bretelle, vu que ce sont des TJS. Et je ne vois qu'une aiguille dans les TJS ?
Une TJD ou TJS a deux aiguilles indépendantes, on peut avoir une bretelle avec une des aiguille d'une TJD/TJS et une autre aiguille, voire avec une aiguille d'une autre TJD/TJS
Citer
8°) Je vois la valeur des ralentissements dans les signaux (en donnant la position de l'aiguille qui nécessite ce ralentissement). Je trouve ça bizarre. Je pense que ce serait plus logique dans l'aiguille
Un ralentissement peut dépendre de la position de plusieurs aiguilles. De plus c'est plus pratique pour le gestionnaire de traiter cela au niveau du signal
Citer
9°) Dans les itinéraires, il n'y a qu'une liste de zones. Mais j'aurais tendance à y mettre aussi la position des aiguilles, de façon à ne pas avoir à la recalculer quand on appuie sur un bouton.
Oui c'est vrai, mais cela allège le fichier json (pour le nouveau Locoduinodrome il fait déjà plus de 4000 octets)
Citer
10°) C'est quoi "auts" ?
C'est des autorisations. Quand deux postes d'aiguillages partagent des voies sur lesquelles ils peuvent envoyer des trains, voies uniques, voies à quai, ... il faut se prémunir contre les nez à nez. Pour cela on utilise des autorisations, celui qui a l'autorisation peut envoyer un train l'autre pas (exclusivité). Ce mécanisme n'est utilisé que pour l'ancien Locoduinodrome, pour gérer le partage de la voie unique

Concernant les voisins d'une zone, pour l'instant je simplifie des écriture json genre : [[Zx]] assez courantes en Zx, la aussi pour réduire la taille du fichier json. De plus quand il n'y a pas de signaux je met rien toujours pour les mêmes raisons.

Concernant le lien sur le site, je le connais depuis pas mal de temps, c'est très intéressant.

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2994
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #436 le: juin 08, 2024, 06:23:10 pm »
Aux vues du fichier Json de Denis, concernant mon réseau, j'ai quelques question préliminaires dont les réponses sont sans doute dans les posts précédents :

z40 et Z41  (zones avec butoir)ont-ils comme voisin eux-même ou rien " "
concernant pair / impair = est-ce le sens de la marche ?
vois1 est-il coté pair ou impair ?
vois2 idem ?
sign1 idem ?
sign2 idem ?

aiguille droite=droite, et gauche=déviée ? ou
aiguille droite=à droite vu de la pointe vers un talon ?
aiguille gauche=à gauche vu de la pointe vers un talon ?
dans les 2 derniers cas, cela ne renseigne pas le gestionnaire sur le coté "dévié" qui peut entrainer un ralentissement.

Je continue à explorer !
merci à tous les deux : on est pas loin du but !
Dominque
Cordialement,
Dominique

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #437 le: juin 08, 2024, 07:12:48 pm »
@ Dominique,

Le fichier JSON va évoluer, suite au dernier post de Pierre.
 
En effet, comme son gestionnaire évolue, il a besoin d'informations supplémentaires et de simplifications.
En particulier, il doit être aussi petit que possible, si on veut le charger dans un processeur avant de lancer le gestionnaire.
Je suis en train de l'adapter pour qu'il réponde aux nouveaux enjeux.

Pour répondre à tes questions :

1°) Oui, le voisin d'une zone avec butoir, c'est elle-même. Et ça fonctionne très bien dans la recherche d'itinéraires.

2°) Pair/impair, c'est le sens de circulation principal d'une zone. C'est une donnée du réseau. Et ça suppose que le train roule à sens unique.
Sauf accident ou problème technique, un train pair roule dans le sens pair et voit les signaux de sens pair.

3°) Concernant les voisins, justement ça va changer : voisP pour voisin pair, voisI pour voisin Impair, pareil pour les signaux. Il va falloir que je change.

4°) Pour moi, il faut que le type des appareils de voie soit clair : une aiguille droite a la voie déviée à droite et une aiguille gauche la voie déviée à gauche.

5°) Je construit le fichier JSON à partir du fichier Zones. Pour l'instant, je sauve le fichier Zones, mais quand on sera d'accords sur le JSON, je ne le sauverai plus.
De la même façon, je sauve les fichiers d'itinéraires, très complets, mais, comme ça finira aussi dans le JSON (en résumé), ils disparaîtrons aussi.
Il y a dans le fichier Zones toutes les infos nécessaires pour construire le JSON.

Le fait de raisonner exclusivement en pair/impair va me poser quelques soucis, car c'est très différent de mon raisonnement, mais j'ai bon espoir  ;)

Denis  :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #438 le: juin 10, 2024, 11:20:29 am »
@ Dominique & Denis

Concernant les notations pair/impair pour les zones :

Les zones ont toutes deux cotés, il faut nommer ces cotés, après avoir fait des essais avec 1/2, je suis (re)venu aux pair/impair, c'est plus cohérent avec les sens des trains, les signaux, … et plus simple pour le gestionnaire.

Pour que ce soit cohérent le choix du coté pair et du coté impair ne peut pas se faire n'importe comment. On choisit une zone quelconque et on décide arbitrairement quel est le coté pair et le coté impair, les cotés de toutes les autres zones sont alors déterminés par la règle suivante : à tous les changements de zones on passe d'un coté pair à un coté impair ou d'un coté impair à un coté pair.
Il y a deux cas où ce n'est pas possible, la raquette et le triangle de retournement (j'en ai déjà parlé dans un post précédent).

Un train qui se déplace vers le coté pair d'une zone est un train pair, un train qui se déplace vers le coté impair d'une zone est un train impair.
Un signal qui est près du coté pair d'une zone est un signal pair et inversement. Donc un train pair ne voit que les signaux pairs et inversement.
Cela permet aussi de donner une sens aux itinéraires, aux balises, …

Concernant les aiguilles :

On m'a déjà reproché, a juste titre, l'appellation directe/déviée pour la position des aiguilles qui est ambiguë notamment pour les aiguilles symétriques. J'ai donc adopté l'appellation droite/gauche (c'est la direction en regardant l'aiguille en pointe). Certes cela ne permet plus de prévoir un ralentissement quand l'aiguille est déviée (et quelle est prise en pointe), mais je pense que le problème des ralentissements est plus complexe et peut dépendre de la position de plusieurs aiguilles et de leur sens de parcours (pointe ou talon); pour le gestionnaire il est pratique d'avoir l'information liée au signal, pour cela j'ajoute (pour l'instant) aux signaux, dans le fichier json, une vitesse et des positions d'aiguilles, genre "ral": [30,"A1","gauche","A2","gauche"], on pourrait même envisager des vitesses multiples genre "ral": [[30,"A1","gauche","A2","gauche"],[60,"A1","droite"]]

Pierre

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #439 le: juin 10, 2024, 01:12:47 pm »
J'ai oublié de parler des butoirs.

Les voisins d'une zone sont normalement des zones, éventuellement conditionnées par la position d'aiguilles. Quand il y a un butoir il n'y a pas de zone voisine, il n'y a rien. En informatique rien peut se coder par null ou l'absence d'information, je préfère la deuxième solution, on ne met rien dans le fichier json.
Le fait de mettre la zone elle même comme voisin me semble plutôt absurde.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #440 le: juin 10, 2024, 04:08:29 pm »
@Pierre,

Pour répondre à ta dernière remarque sur les butoirs.
C'est une chose de ne rien mettre dans le JSON. Ça gagne de la place et c'est logique. OK.
Mais pour gérer les itinéraires, il faut que toutes les zones aient un voisin et le plus facile, comme il faut bien mettre quelque chose, j'ai pris le parti de mettre le nom de la zone.
En plus, quand on recherche des itinéraires, on change de sens de parcours aux butoirs. Il n'y a même pas besoin d'avoir un cas particulier, l'inversion se fait d'elle même.

Par ailleurs, j'ai beaucoup de mal à dire qu'une zone est paire ou impaire. Je conçois, par contre, très bien qu'une zone ait un côté pair et un côté impair. Ça me va parfaitement.

Je supprimerai bien l'info "sens" dans le JSON :

Une zone a un feu (coté pair ou impair), deux feux ou pas de feux.
Si une zone a un feu "signP", elle est "paire" et l'info "sens" est redondante. Si une zone a un feu signI, elle est "impaire" et l'info "sens" est redondante.
Si une zone a deux feux, elle est banalisée et n'a donc pas vraiment de sens.
Si elle n'a pas de feu, elle est aussi banalisée et n'a donc pas vraiment de sens.

Dans les itinéraires, on a une liste de zones. L'ordre de cette liste donne le sens de parcours. Là encore, l'info "sens" est redondante.

Concernant les ralentissements, je propose que cette info soit au niveau des feux R et pas de feux RR, comme ça le train a directement l'info quand il en a besoin.

Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2994
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #441 le: juin 10, 2024, 04:39:59 pm »
Mais le fait de ne mettre "rien" soit " ", un blanc, ce n'est pas rien comme dirait Raymond Devos !
Donc "un blanc" peut signifier un butoir !
Logique ?

..et s'il n'y a pas de butoir, le trains continue sur le ballast !
Cordialement,
Dominique

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #442 le: juin 10, 2024, 04:59:41 pm »

@ Denis

J'ai mis un post il y a quelques temps pour discuter de tous les problèmes de sens.

Citer
Mais pour gérer les itinéraires, il faut que toutes les zones aient un voisin et le plus facile, comme il faut bien mettre quelque chose, j'ai pris le parti de mettre le nom de la zone.
En plus, quand on recherche des itinéraires, on change de sens de parcours aux butoirs. Il n'y a même pas besoin d'avoir un cas particulier, l'inversion se fait d'elle même.
Tu peux aussi mettre null, mais tant que cela reste dans ton éditeur cela n'a pas d'importance.
Citer
Par ailleurs, j'ai beaucoup de mal à dire qu'une zone est paire ou impaire. Je conçois, par contre, très bien qu'une zone ait un côté pair et un côté impair. Ça me va parfaitement.
Il n'y a pas de sens des zones dans le fichier json, les "sens" c'est des sens de parcours autorisés pour les trains
Citer
Dans les itinéraires, on a une liste de zones. L'ordre de cette liste donne le sens de parcours. Là encore, l'info "sens" est redondante.
C'est vrai, mais le sens est dur à extraire de la liste des zones de l'itinéraire.
Citer
Concernant les ralentissements, je propose que cette info soit au niveau des feux R et pas de feux RR, comme ça le train a directement l'info quand il en a besoin.
Les trains n'ont pas besoin des infos de ralentissement issues du json, c'est le gestionnaire qui gère.
Les infos de ralentissement sont utilisées dans le calcul des feux d'un signal lors de son ouverture, pour faire ce calcul on a besoin du feu du signal suivant, à la fin du calcul le nouveau feu du signal est transmis au signal précédent pour une éventuelle mise à jour. Ce qui implique que les infos de ralentissement soient avec le signal de RR.

Pierre

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #443 le: juin 10, 2024, 05:05:32 pm »
@ Dominique

Citer
Mais le fait de ne mettre "rien" soit " ", un blanc…
Donc "un blanc" peut signifier un butoir !
Rien c'est rien, même pas un blanc, pour le fichier json.
Le butoir c'est juste de la décoration !

Pierre

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #444 le: juin 19, 2024, 10:02:34 am »
@ Dominique

Voila, j'ai réussi à faire tourner une première version (alpha) du gestionnaire json en C/C++. Je suis parti de la version 3 du gestionnaire en Processing et je l'ai traduite en C/C++.

Comme je l'ai dit précédemment elle tourne sur ordinateur (basé sur Unix : MacOs, Linux, ...) pour pouvoir faire des tests avec le TCO en Processing (la communication des messages se faisant par des tubes de communication Unix).

J'ai fait le maximum pour que cette version (et les suivantes) puisse tourner sur Arduino, pour cela j'utilise comme bibliothèque json : "AduinoJson".

J'ai transformé les onglets un à un, en commençant pas l'onglet "json". La transformation des onglets  été faite à coup de substitutions globales et d'adaptations. Le plus dur a été de trouver un remplaçant pour les "Strings" de Processing, j'ai essayé "string" de C/C++ mais j'ai eu du mal avec les pointeurs, finalement je suis parti sur des "const char *" qui conviennent bien et qui sont des pointeurs.

Le plus dur a été l'onglet "json", il a fallu presque tout réécrire et tester à cause du changement de bibliothèque json.

L'organisation générale du programme C/C++ n'est pas très jolie, il n'y a que des ".h". Mais devant le tas de problèmes j'ai fait au plus facile.

Le programme C/C++ n'est qu'une version "alpha", il y plein de bugs, mais cela ne se plante pas, et j'ai réussi à faire correctement certains itinéraires et même à envoyer un train en ligne avec des signaux corrects ainsi que le cabsignal.

Quand il y aura moins de bug je publierai une version pouvant être essayée.


Il va aussi falloir commencer à réfléchir à une version sur Arduino. Je verrai bien un micro-contrôleur bi-coeur plutôt costaud (avec éventuellement du calcul flottant pour l'odométrie), un coeur pour le gestionnaire et un coeur pour les communications.

Il y a aussi le problème du fichier json, il y a trois solutions :
- une carte SD
- une constante (const char* Z2=…;), c'est le cas ici pour le gestionnaire C/C++ (mais plus de 4000 octets pour le json du nouveau Locoduinodrome)
- une constante dans la partie mémoire flash (PROGMEM).

Le fichier accompagné contient un sketch Arduino avec tous les fichiers du gestionnaire en C/C++, mais ce n'est pas (encore) un vrai sketch Arduino compilable et flashable, c'est juste un moyen de visualiser les fichiers avec un IDE connu.

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2994
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #445 le: juin 19, 2024, 05:53:06 pm »
@pierre59

Merci Pierre 🙏, pour ce gros travail d’adaptation : on rentre dans but visé et je vais m’empresser de regarder tout cela de très près, demain .

Je viens de récupérer cette version que je découvre dans cette réponse :

Je suis conscient que c'est un premier jet d'une conversion du programme Processing (Java) en C/C++ et, par conséquent tout ce qui suit N'EST PAS une critique.

1) A première vue, je cherche où est le programme principal qui n'est pas dans GestJC.ino (qui est vide). Je cherche donc le Setup() (que je n'ai pas trouvé, et la Loop() qui semble être dans GestJC.cpp (qui contient un main).

Peut-être faut-il tout simplement recopier le main() du cpp dans la loop() du ino ?
Je vais essayer.
Pour le moment en choisissant mon Arduino Due habituel, la compilation échoue et fournit une longue lecture !

2) L'onglet ArduinoJson-v7.0.3.h n'est peut-être pas nécessaire puisque la bibliothèque ArduinoJson-v7.0.4 est disponible sur IDE 2.3.2
Il y a une document très exhaustive sur https://arduinojson.org/?utm_source=meta&utm_medium=library.properties

3) En ce qui concerne l'emplacement du fichier Json, il est possible en effet de le stocker sur une carte SD, comme l'illustre l'exemple JsonConfigFile. La carte SD permet de faire le lien facile avec l'éditeur de Denis.

Il peut-être aussi enregistré en mémoire flash (progmem) selon le processeur choisi (ESP32 par exemple) avec un téléchargement sans fil.

Je continuerai ma découverte un peu plus tard...
« Modifié: juin 21, 2024, 08:10:57 am par Dominique »
Cordialement,
Dominique

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #446 le: juin 21, 2024, 08:57:58 am »
@ Dominique

C'est juste une traduction en C/C++ du gestionnaire json, pas encore adaptée à Arduino, mais cela viendra.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #447 le: juin 23, 2024, 11:44:50 am »
@Pierre,

Bravo pour tes efforts pour faire entrer un gestionnaire dans un microcontrôleur. 8)

@ tous,

J'ai bien avancé sur mon éditeur, bien clarifié certains points et corrigé quelques bugs. :P

Voyons dans le détail :

1°) La parité :

Quand on trace un trait sur une feuille, on a une origine et une extrémité.
Cette information ne doit jamais être perdue.

Quand un train va de l'origine vers l'extrémité, je décrète arbitrairement qu'il va dans le sens pair.
Comme, par ailleurs, on circule à gauche à la SNCF (hors AL pour des raisons historiques), il s'ensuit que les trains pairs vont dans le sens des aiguilles d'une montre. C'est une conséquence du choix précédent.

Un train pair voit des signaux pairs à l'extrémité d'une zone paire.
Un train impair voit des signaux impairs à l'extrémité d'une zone impaire.

Si une zone paire peut être parcourue dans les 2 sens, les trains pairs voient les signaux pairs à l'extrémité et les trains impairs des signaux impairs à l'origine de la zone.
Si une zone impaire peut être parcourue dans les 2 sens, les trains impairs voient les signaux impairs à l'extrémité et les trains pairs des signaux pairs à l'origine de la zone.

Donc, dans la ligne "sens" de la zone, je ne peux avoir que "pair" ou "impair".

Le voisin pair d'une zone paire est à l'extrémité et le voisin impair d'une zone paire est à l'origine.
Le voisin impair d'une zone impaire est à l'extrémité et le voisin pair d'une zone impaire est à l'origine.

Par ailleurs, il peut y avoir 0, 1 ou 2 signaux pour une zone.
On traitera plus tard le cas de 0 signaux, en particulier dans les zones multiples.
Pour 1 signal, si la zone est paire, il y aura un seul signal pair et un seul signal impair si la zone est impaire.
Pour 2 signaux, il y aura un signal pair et un signal impair. Et la parité nous dira à quel bout il est.
Si on veut garder à la fois l'information de parité et l'information du nombre de signaux dans la ligne "sens", je propose de mettre "pair0"/"impair0", "pair1"/"impair1" ou "pair2"/"impair2"

Pour les appareils de voie, je ne m'occupe pas de la parité. L'origine est toujours du côté de la pointe et l'extrémité côté talon.

Pour les traversées (croisement, TJS, TJD), je définis arbitrairement un sens puisque tout est symétrique.

Enfin, pour les zones qui ont un butoir, celui-ci est toujours à l'extrémité. La parité de la zone désignant cette extrémité.

J'ai abandonné la notion de "pairimpair" car elle fait perdre la notion d'origine/extrémité.

2°) Pierre a eu l'excellente idée d'ajouter des balises dans les zones, paires ou impaires évidemment, ce qui permet de récupérer plus souvent une information de position du train réel (odométrie) et de s'assurer d'un arrêt au pied du signal.
On évite ainsi de découper les rails pour des "zones d'arrêt" dans les zones et un seul capteur à effet hall suffit pour détecter le train à l'endroit d'une balise.

Pour l'instant j'ai défini 2 types de balises :
- avant un signal
- avant un butoir
Mais on pourrait définir d'autres types. Par exemple une balise quand un train doit siffler (entrée de tunnel, passage à niveau, …).

3°) Autre excellente idée de Pierre : les bretelles.

Effectivement, la position de certains appareils de voie implique la position d'un autre appareil sous peine de déraillement.
Dans une bretelle, il y a deux positions :

L'une ou les tracés sont parallèles où il ne peut rien se passer du point de vue du gestionnaire (pas de rattrapage, de face à face, …) et l'autre position où des zones sont dans la continuité l'une de l'autre. C'est pour ça que j'ai ajouté à la ligne "bretelles" du JSON la position des 2 appareils de voie qui amène un problème à gérer au gestionnaire.

On remarque, au passage, que les 2 appareils de voie sont soit tous les 2 à droite ou tous les 2 à gauche dans une bretelle.
Il ne peut y avoir de bretelles qu'entre 2 appareils de voie ayant des lames mobiles. Donc, on serait tenté d'exclure, à priori, les sections et les croisements.
En fait c'est plus compliqué :

Cas de la section :

Il peut très bien y avoir une section entre les 2 appareils de voie et cela constituera quand même une bretelle si cette section est "courte".
Si une section est suffisamment courte pour qu'on ne puisse pas y mettre un wagon, cela ne pose pas de problème.
Si la section est plus longue, il faut pouvoir détecter un wagon sur cette section.
Si la section est suffisamment longue pour contenir un train complet, est-ce encore une bretelle ?

Cas du croisement :

Il est très fréquent qu'un petit croisement soit associé à 2 bretelles successives, permettant ainsi de passer d'une voie à l'autre dans les 2 sens.
La difficulté, en recherche automatique, c'est que, là, il faut chercher le voisin du voisin.
C'est une récursivité à un seul étage.
4°) Pour la partie aiguilles, j'ai précisé quelle était l'aiguille concernée dans les appareils ayant 2 aiguilles (TJS, TJD, triples).
"TJDa" et "TJDb" pour une TJD. "TJSa" et "TJSb" pour une TJS
"TripleGa" et "TripleGb" et "TripleDa" et "Tripleb" pour les triples.

5°) Pour la partie signaux, j'ai ajouté la liste des signaux affichables par un signal donné.
J'ai ajouté, pour ceux susceptibles d'afficher "RR", la liste et la position des aiguilles concernées dans ce cas.

Quant à la numérotation des signaux, il y a une lettre et un nombre.
- La lettre correspond au nom du signal hiérarchiquement le plus élevé (C, Cv, S)
- Le nombre est un incrément. Il y a 2 incréments : un pair et un impair.
Suivant la parité de la zone, on incrémente de 2 le bon incrément.

Au passage, comme un signal ne peut afficher C et Cv en même temps du fait que la deuxième ampoule du carré est l'ampoule du Cv (voir ci-dessous), j'ai tenu compte de cette particularité.



Dans le gestionnaire, il faudra également gérer le feu blanc (M) qui peut être clignotant.
Le feu M à l'origine de Z28 ne peut être que clignotant, de même que les deux feux de Z37.



Je terminerai sur les signaux en disant qu'ils peuvent être visibles ou invisibles.
Un signal invisible est un signal qui est nécessaire au fonctionnement du gestionnaire, mais qui n'est pas forcément implanté sur le terrain, en particulier en zone de manœuvre où ce sont souvent des hommes qui, sur place, manipulent des drapeaux ou des lanternes.

J'ai mis un cercle vide pour les signaux qui, à mon avis, sont invisibles.
Le feu visible en Z46 sera traité avec les zones multiples, encore à faire.

6°) Je n'ai pas mis les trains dans le JSON. Pour l'instant, je ne sais pas quoi mettre.

7°) Concernant les itinéraires, c'est tellement rapide à calculer que je ne suis pas absolument convaincu que ce soit nécessaire de les calculer d'avance.
Il faut trouver une méthode qui permette de choisir un seul itinéraire quand il y en a plusieurs d'un point A à un point B.
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #448 le: juin 23, 2024, 06:34:53 pm »
@ Denis

Tu fais des choix, de parité entre autre, avec une arrière pensée dessin du réseau. Je suis pas sur que cela soit la bonne façon.

Pour l'instant les zones du gestionnaire n'ont pas de sens, la clé "sens" qui apparait dans les zones  ne sert qu'a contrôler les changements de sens des trains sur la zone, c'est tout.

Les zones ont deux cotés, un coté pair et un coté impair. La seule contrainte est que lors d'un changement de zone, on passe d'un coté pair à un coté impair ou d'un coté impair à un coté pair. Ce nommage des cotés induit le nommage (pair/impair) des voisins, des signaux, des balises, … .

Pierre

Pierre59

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #449 le: juin 24, 2024, 10:05:05 am »
@ Denis

Concernant les "parités", j'en ai parlé dans le post précédent.

Concernant les balises, oui il faut ajouter un type ("signal", "butoir", …).

Concernant les bretelles, les deux aiguilles d'une bretelle sont forcément dans deux zones distinctes, et ces deux zones sont contigues. La distance entre les deux aiguilles n'est pas trop grande. Le gestionnaire a besoin de savoir quelles sont les deux aiguilles d'une bretelle, et la position des aiguilles quand elles sont en continuité (ou l'inverse), dans la dernière version du gestionnaire (en Processing) c'est calculé automatiquement à l'initialisation du gestionnaire (mais c'est un peu compliqué).

Concernant les trains on ne devrait rien mettre dans le fichier json (j'en ai juste besoin pour les essais), cela doit se faire à l'initialisation du gestionnaire, comment? le problème reste ouvert.

Concernant les itinéraires, le calcul automatique des itinéraires à partir du point de départ et du point d'arrivé est tout à fait envisageable, mais cela nécessite des ressources (par exemple des structures de données) pas toujours facile à mettre en oeuvre sur un micro-contrôleur et il reste le choix à faire quand il y a plusieurs itinéraires possibles (un algorithme à proposer?).

Pierre