Messages

16

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

« 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

17

Vos projets / Re : Re : TCO bp + ordi

« le: février 12, 2024, 04:22:29 pm »

Mais tu parles maintenant de te lancer avec Processing qui est beaucoup plus difficile à appréhender encore que la programmation Arduino où tout a été fait pour que ce soit très simple à utiliser. Libre à toi mais tu ne trouveras pas grand monde alors pour t'aider.

Processing c'est comme Arduino, tout a été fait pour que ce soit simple à utiliser, mais pour un autre domaine, celui du dessin et de l'animation 2D et 3D.

Pierre

18

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

« le: février 01, 2024, 10:18:07 am »

@ Denis

La notation   [[NULL,"A3","droite","A1","gauche"],   c'était juste un idée comme cela, pas forcement réaliste.

Dans le cadre du gestionnaire je suis en train de regarder les algos utilisants les voisins.

Pour le suivi des trains on a besoin des deux voisins (en fonction de la position des aiguilles), c'est un cas qui arrive très souvent quand une zone devient occupée.

Pour les itinéraires (prédéfinis ou automatiques) on a besoin des tous les voisins et en plus du "sens" des zones. C'est un cas qui arrive souvent.

Pour trouver automatiquement les précédents et les suivants des signaux, les besoins sont à peu près les mêmes que pour les itinéraires. Ce cas ne se fait qu'une fois (dans le gestionnaire ou dans l'éditeur).

Autres cas ?

Pierre
 

19

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

« le: janvier 31, 2024, 05:57:40 pm »

@ Denis

Pour les points 1 2 3, je ne comprend pas, je ne vois pas ce que c'est une "forme".

Pour le point 4, pour éviter de coder 180 itinéraires, on sait faire des algos récursifs qui fournissent tous les itinéraires possibles, après faut faire un choix, on a déjà parlé de ces problèmes il y a un bon bout de temps. L'algo a juste besoin de tous les voisins des zones (avec les positions d'aiguilles associées).

Pour le point 5, dans le gestionnaire le fichier json est lu d'un coup pour produire un objet json, il faut donc aller dans cet objet json pour avoir les voisins d'une zone, c'est assez facile.

Pierre

20

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

« le: janvier 31, 2024, 02:00:26 pm »

Bonjour

Depuis quelques temps j'essaie de voir les avantages et les inconvénients des "trajets" et des "demi-trajets". Pour cela je vous joins des extraits json du Locoduinodrome dans les deux cas, c'est une partie caractéristique des zones (la version "trajet" est issue de Denis). Je joins aussi le dessin du Locoduinodrome.

Il faut aussi s'intéresser à la facilité des opérations courantes du gestionnaire :

- obtention de la zone voisine d'une zone donnée (d'un coté ou de l'autre) en fonction de la position réelle des aiguilles

- positionnement des aiguilles pour un itinéraire donné par une liste de zones (traité dans un sens ou dans l'autre), un itinéraire est proposé

- recherche automatique des précédents et suivants des signaux

- obtention de toutes les zones voisines d'une zone donnée (d'un coté ou de l'autre)

- autres ?

Pierre

21

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

« le: janvier 30, 2024, 06:06:56 pm »

J'ai beaucoup de mal à comprendre les demi-trajets pour les appareils de voie à base de croisements.
Il faut imaginer un point fictif, partir de ce point et ne parler que d'une aiguille alors qu'il en a deux...

Le point fictif c'est le centre du croisement, et l'aiguille fictive sert à sélectionner  les bons demi-trajets

Les trajets complets sont peut-être un peu plus lourds, mais nettement plus simples à imaginer.

Les trajets sont à mettre dans le json des zones, on ne peut rien faire de clés genre "AB" sauf comme commentaires, il va falloir aussi structurer pour faciliter le traitement par le gestionnaire

Par ailleurs, cette nouvelle notation est beaucoup plus compacte (plus d'accolades), mais j'imagine qu'il faut en mettre, comme avant ?

Non c'est exactement le json qui est utilisé pour le gestionnaire

Pierre

22

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

« le: janvier 30, 2024, 05:01:43 pm »

Voila ma proposition pour des demi-trajets (à mettre dans le json des zones), A0 est l'aiguille simple, A0 et A1 sont les aiguilles doubles :

"vois1":"ZA",
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]] // droite pointe

"vois1":[["ZA","A0","droite"],["ZC","A0","gauche"]], // droite talon
"vois2":"ZB"

"vois1":"ZA",
"vois2":[["ZB","A0","gauche","A1","droite"],["ZD","A0","droite"],["ZE","A0","gauche","A1","gauche"]] //  triple modele Peco

"vois1":[["ZA","A1","gauche"],["ZC","A1","droite"]] // tjd
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]]

"vois1":[[NULL,"A0","droite","A1","gauche"],["ZA","A1","droite"],["ZC","A1","gauche"]] // tjs
"vois2":[[NULL,"A0","droite","A1","gauche"],["ZB","A0","droite"],["ZD","A0","gauche"]]

"vois1":[["ZA","A0","gauche"],["ZC","A0","droite"]], // croisement (vu comme une aiguille sans moteur)
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]]

La tjs est un peu délicate, il faut éliminer un cas.
Pour les tracés continu des itinéraires il est utile de considérer le croisement comme une aiguille (sans moteur)
Il peut rester des erreurs !

Pierre

23

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

« le: janvier 30, 2024, 03:44:43 pm »

Voila une base pour vos propositions, les zones voisines sont toutes nommées.

Pierre

24

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

« le: janvier 30, 2024, 02:49:35 pm »

@ Denis et autres

Plutôt que le terme "forme" je préfèrerais le terme "trajet" (ou autre : parcours, ... idées ).

Je suis assez d'accord avec toi, j'ai déjà envisagé très sérieusement des demi-trajets (demi-formes), à partir du "centre" de la zone, dans l'exemple complexe du dessin c'est le centre de la tjd. Les demi-trajets simplifient un peu le nombre de cas, les trajets donnent 10 cas, tandis que les demi-trajets donnent 2+5=7 cas (2 pour la partie gauche et 5 pour la partie droite), 2*5 donne bien les dix cas réels. Bon dans les cas les plus courants de zones on n'a pas une telle complexité.


Ce qu'il faut regarder, pour choisir, c'est les appareils de voie à problèmes : tjd, tjs et croisement.

Ce qu'il faut regarder, aussi et surtout, c'est l'usage que l'on fera avec ces trajets : suivi des trains, recherche automatique des suivants et précédents des signaux et j'en oublie certainement.

Il faut aussi trouver un codage json qui soit facilement utilisable par le gestionnaire.

Il faut en discuter, pour choisir le meilleur cas.

Pierre

25

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

« le: janvier 29, 2024, 10:11:13 am »

@ Denis

Une tjd ou une tjs c'est équivalent à deux aiguilles en pointe, voila pour la tjs A1-A3 :

    {
      "nom" : "A1",
      "type" : "tjs"
    },
    {
      "nom" : "A2",
      "type" : "droite"
    },
    {
      "nom" : "A3",
      "type" : "tjs"
    },

Les "type" sont des commentaires.

Pierre

26

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

« le: janvier 28, 2024, 06:17:26 pm »

Par contre, là, j'ai vraiment besoin de savoir comment on rentre une tjd, une tjs et ... un croisement (l'éternel vilain canard  ) dans le JSON. J'ai mis quelque chose, mais je ne suis pas sûr de moi.

Pour une TJD ou une TJS on met deux aiguilles (il y a deux noms de prévu), pour un croisement je le considère comme une aiguille sans moteur (c'est utile si on veut des tracés d'itinéraires continus).

Pierre

27

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

« le: janvier 23, 2024, 04:30:41 pm »

@ Denis

Je t'avais promis une version, avec des dialogues, plus élaborée. C'est en fait un peu une boite à outils pour faire des dialogues. Il y a deux sortes de champs de saisie, un champ avec des choix multiples prédéfinis et un champ avec en plus une possibilité d'édition (si les choix prédéfinis ne conviennent pas).

Plusieurs dialogues permettent de saisir des zones, des aiguilles ou des signaux avec des paramètres. Ce sont des dialogues dits "modal", un seul dialogue n'est affiché à la fois, mais on pourrait en afficher plusieurs à la fois.

Les dialogues comportent une série de boutons, pour l'instant deux seulement sont actifs, un bouton "X" qui ferme le dialogue, puis le dialogue suivant est affiché, et un bouton "S" qui affiche dans la console le code json fabriqué par le dialogue.

Cela montre juste ce que l'on peut faire avec les dialogues, toute la partie édition globale du fichier json est absente.

Les champs de saisie des voisins (1 et 2) des zones sont assez particuliers, on peut utiliser un nom de zone déjà existante ou saisir un nouveau nom. Mais si le "nom" de la zone est déjà renseigné et que l'on a choisi "cas" pour le voisin, un coup de molette (wheel) sur le champ fait apparaitre un nouveau dialogue pour saisir des voisins conditionnels (suivant la position d'aiguilles).

Le programme ne fonctionne qu'avec Processing 4.

Pierre

28

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

« le: janvier 19, 2024, 11:32:53 am »

Terminologies :

Je propose d'employer TD pour tout droit et DV pour dévié.
Pour les aiguilles enroulées, TD sera la voie à grand rayon et DV celle à petit rayon

gauche/droite cela marche des tous les cas

J'appelle AB la première diagonale d'une TJD (TJS, croisement) et CD la deuxième diagonale pour les TD
J'appelle AD et CB les deux courbes d'une TJD (en DV)
Pour une aiguille simple, AB pour TD et AC pour DV
Pour un triple, AB pour TD et AC pour la gauche et AD pour la droite

je vois pas trop l'utilité dans le fichier json

Je ferai le JSON avec, en plus, les données vitesses limites.
Dans les zones, cela correspondra aux TIV, pour les aiguilles, sur voie DV (30, 60 et 160)
Je ne sais pas s'il y a des limites de vitesse en TD sur TJD.

oui on peut associer des vitesses, mais où les mettre, ce n'est pas urgent

Je propose de mettre "banalise" au lieu de "pairimpair"

pourquoi pas mais dans mon esprit il pourra avoir des variantes avec les manoeuvres , du
genre pair_et_impair_manoeuvre

Je sortirai deux ArrayList "Zones" et "Aiguilles" et, éventuellement, un 3ème ArrayList pour les connecteurs, si c'est utile.

dans mon esprit les voisins sont les connecteurs, mais à revoir

Pierre

29

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

« le: janvier 18, 2024, 05:25:26 pm »

@ Denis

Je t'ai fabriqué un "dialogue" sur mesure pour les zones. Il permet de saisir les noms de zones, les sens et les voisins. Pour les sens il n'y a que deux choix possibles (pour l'instant), pour le reste on peut saisir un nom de zone ou choisir parmi celles qui sont déjà saisies pour les modifier, les compléter, les supprimer, .... Pour les voisins "cas" devra pouvoir saisir un nom de zone et une liste de paires (aiguille,position).

Pour l'instant les modifications s'affichent dans la console.

Pierre

30

Vos projets / Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: janvier 18, 2024, 05:01:22 pm »

GRILLS D APPAREILS:

Un grill de gare est par défaut une zone composée à minima d'un appareil de voie ( aiguillage simple, ou multiple ( triple, TJS, TJD)) Il dessert 2 sections du réseau ( cantons, zones, ...)
Il y a donc toujours une entrée unique et une sortie unique qui permet de circuler entre l entrée et la sortie à un instant T.

Il y a des gares (Creil par exemple) où deux doubles voies arrivent dans le grill d'entrée, pour desservir plusieurs voies à quai. Quatre trains peuvent circuler simultanément sur le grill.

Par ailleurs dans pas mal de gares le cantonnement se fait (normalement sur les carrés) sur toute la traversée de la gare, on a donc des cantons dans le grill d'entrée (et sur les voies à quai).

Pierre