Projet partagé d'un gestionnaire de réseau

[Pierre59]

@ Denis

Quelques réponses à tes questions :

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)

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, ...)

4°) Comment tu coderais une zone sans feux (dans une zone de manœuvres, par exemple) ?

Comme les autres mais sans signaux

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

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

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

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

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)

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]

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

[DDEFF]

@ 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 

[Pierre59]

@ 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]

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]

@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

[Dominique]

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 !

[Pierre59]

@ Denis

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

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.

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

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.

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]

@ Dominique

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]

@ 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]

@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...

[Pierre59]

@ Dominique

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

Pierre