Messages

1

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: septembre 19, 2024, 10:44:52 am »

Voici une nouvelle version du gestionnaire expérimental json en C/C++. Beaucoup de bugs ont étés éliminés, mais il en reste encore. Comme la précédente version, cette version est prévue pour tourner sur un ORDINATEUR, elle fonctionne comme la version en Processing (Java) en utilisant un TCO en Processing pour faire les tests.

La version Processing et cette version C/C++ sont quasiment équivalentes, mais il y a quelques différences entre la version Processing et la version C/C++ (dans le but de préparer la version tournant sur Arduino), voici les changements de la version C/C++ :

- le transit souple n'est pas encore mis en oeuvre (il faut juste traduire le code de Java vers C/C++ et tester)

- des "bus" ont étés introduits, le gestionnaire communique avec le réseau, le TCO, les manettes, la centrale (box), … par un ou plusieurs "bus", ces bus peuvent êtres très variés : ethernet, wifi, I2C, USB/série, CAN, … . Pour l'instant les messages comportent tous trois octets et ne sont pas répétés (on peut envisager des codes de détection d'erreurs comme un CRC, voire un numéro de message).

Pour passer à une version Arduino il va falloir faire quelques adaptations :

- la bibliothèque json utilisée existe sur Arduino (c'est pour cela quelle a été choisie) on pourra supprimer l'onglet et utiliser un "include" à la place (le changement de bibliothèque a représenté le plus gros du travail pour passer de Processing à C/C++)

- remplacer les structures de données, genre "vector", par des versions adaptée à l'Arduino et faire attention à la gestion mémoire

- choisir le ou les bus et les implémenter

- régler les problèmes d'initialisation du gestionnaire comme il a été discuté dans le post n° #461 et les suivants de ce fil

- prévoir un moyen de dialogue avec le gestionnaire pour l'affichage de ses messages et l'obtention des informations sur les trains, voir aussi le post n° #461 à ce sujet

- choisir où mettre le "fichier" json, sur carte SD ou en mémoire RAM ou FLASH (PROGMEM)


Les fichiers joints sont tout à fait fonctionnels, mais assez difficiles à mettre en oeuvre, c'est juste une version avant de passer à l'Arduino.

Pierre

2

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: juillet 21, 2024, 06:30:21 pm »

Dans les versions actuelles du gestionnaire json, lors de son initialisation le gestionnaire envoie un message approprié au TCO et d'un "coup de baguette magique" les aiguilles se retrouvent dans la bonne position et les trains dans leur positions initiales.

Bien évidemment avec un réseau réel cela ne peut pas se passer comme cela. Lors de son initialisation le gestionnaire à besoin de plusieurs informations :
- la position de toutes les aiguilles
- la connaissance de toutes les zones occupées, avec des infos sur les trains dedans
- éventuellement l'état des balises

Concernant la position des aiguilles, pour le gestionnaire, la solution idéale est de pouvoir obtenir leurs positions mais cela nécessite un dispositif approprié sur les moteurs d'aiguille, alternativement le gestionnaire peut positionner systématiquement toutes les aiguilles, mais cela pose problème pour les aiguilles des zones occupées où il y a normalement des trains.

Concernant les zones il est assez facile d'obtenir leurs états (libre ou occupé), mais quasiment impossible d'obtenir des infos sur les trains qui les occupent.

Pour les balises c'est un peu comme les zones.

Une solution partielle à tous ces problèmes consiste à sauvegarder les informations lors de l'arrêt "normal" du gestionnaire et de les reprendre lors de son redémarrage. Il reste quand même quelques problèmes :
- lors d'un arrêt "anormal" du gestionnaire (plantage, coupure de courant, …) les infos sauvegardées ne sont pas à jour
- des trains ont pu êtres enlevés ou ajoutés au réseau entre l'arrêt et le redémarrage du gestionnaire
- il faut pouvoir enlever ou ajouter un train pendant le fonctionnement normal du gestionnaire

Les sauvegardes peuvent se faire de différentes façons :
- avec un ordinateur ou un mini-ordinateur sur un fichier
- avec un micro-contrôleur sur carte SD ou en mémoire non volatile (eeprom) ou autre

Un dispositif de dialogue doit être mis en place pour les cas ne relevant pas des sauvegardes (ajouts de trains, …).

J'attends vos commentaires et vos suggestions.

Pierre

3

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: juillet 10, 2024, 05:14:33 pm »

@ Denis

Si j'ai bien compris, tu vas mettre le gestionnaire sur un processeur en C++ et continuer à gérer le TCO en Processing.
Et échange des infos via un "tuyau" ?

Je préfère, et de loin, écrire et tester le gestionnaire en Processing.
De temps en temps il y aura une version en C++. Pour cette version j'utilise des tubes de communication juste pour communiquer avec le TCO en Processing. Ces tubes seront remplacés à terme par un ou des bus (CAN, …) pour une version sur micro-processeur.

Pierre

4

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: juin 25, 2024, 01:34:53 pm »

@ Denis

Vous prendrez bien un "connecteur", non merci. Le gestionnaire json n'a pas besoin de connecteurs pour faire des recherches d'itinéraires, les informations présentes dans les voisins sont amplement suffisantes.

Accessoirement les noms des zones, des aiguilles, signaux, … ne sont pas utiles, c'était juste pour des mises au point et des essais.

Pierre

5

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« 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

6

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« 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

7

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« 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

8

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« 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

9

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: juin 10, 2024, 05:05:32 pm »

@ 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

10

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

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

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

11

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« 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

12

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« 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

13

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: juin 07, 2024, 09:54:25 am »

@ 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

14

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: juin 06, 2024, 11:30:32 am »

Nouvelle version du gestionnaire expérimental json.

Dans le fichier json une partie paramètres ("params") a été ajoutée. Pour l'instant il y a trois paramètres, le choix du transit (souple ou rigide), le nombre maximum de zones entre deux signaux et la présence d'itinéraires permanents ou pas. L'appairage des aiguilles d'une bretelle a aussi été rajoutée (pour le transit souple).

Le TCO a été revu pour utiliser le nouveau locoduinodrome et le gestionnaire utilise en conséquence le fichier json de l'onglet "Z2".

Il a été discuté dans des posts précédents du problème que posent certaines bretelle en transit souple. En pratique le gestionnaire a besoin d'informations complémentaires dans certains itinéraires pour gérer. Ces informations sont rajoutées automatiquement par le gestionnaire, lors de son initialisation, elles sont calculées à partir des informations d'appairage des aiguilles des bretelles qui se trouvent dans le fichier json. En pratique les deux aiguilles d'une bretelle sont toujours manoeuvrées simultanément.

Le fonctionnement des deux applications est toujours le même, lancer le tco PUIS le gestionnaire sur la même machine. L'enclenchement d'approche est toujours désactivé et il y a encore des bugs dans les itinéraires.

En vue de faire des essais en C/C++ du gestionnaire, un mode de communication entre le TCO et le gestionnaire a été ajouté avec utilisation des tubes de communication Unix comme alternative au réseau TCP/IP. Ces tubes de communication existent dans tous les systèmes basés sur Unix (MacOsX, Linux, Ubuntu, ...). Je vais continuer les essais en C/C++ sur Mac pour bénéficier du TCO existant en Processing, je ne peut pas utiliser la bibliothèque réseau Arduino, par contre la bibliothèque ArduinoJson va très bien.

Pierre

15

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: mai 23, 2024, 04:24:15 pm »

@ Denis

Quelques remarques sur ton deuxième post

Auparavant, on a permis l'affichage de S, A, VL (Sémaphore, Avertissement, Voie Libre) sur tous les signaux.

- a propos de Vl, les carrées d'entrée des gares terminus n'affichent jamais Vl
- a propos de S, ce feu n'est utilisé que pour le cantonnement (BMU,BAL,BAPR, ...), sur un réseau il peut avoir de parties sans cantonnement (donc avec des signaux sans S)

Remarque : (on l'a déjà dit dans un précédent post) un signal de gare gérée par itinéraires n'affiche pas le S. Donc, quand je donnerai à toutes les voies de gare la possibilité d'afficher le C, il faudra effacer le S.

- dans les postes avec des itinéraires permanent, s'il y a du cantonnement, certains carrés peuvent présenter le S, pour assurer la continuité du cantonnement à la traversée d'un gare, d'une bifurcation , ...
- dans les postes avec du transit souple, s'il y a du cantonnement, les carrés peuvent s'ouvrir au sémaphore (S)

Il n'y a qu'un signal de manœuvre : le Cv (Carré Violet). C'est le seul qui ne soit pas un signal de cantonnement.

- il peut avoir d'autres signaux qui ne soient pas des signaux de cantonnement (avertissement, carré, ...)
- il y a un autre signal de manoeuvre, dans les grandes gares un feu de manoeuvre (M : blanc) peut être utilisé pour les départs en manoeuvre sur les carrés (compter les feux des signaux de grande gares : 5 feux (A, S, Vl, M, C)

Pierre