Projet partagé d'un gestionnaire de réseau

[DDEFF]

Bonjour à tous,

Voilà le mode d'emploi.

Denis

[Pierre59]

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

[DDEFF]

@ Pierre,

Peux-tu me donner un JSON avec juste une TJD et un autre avec juste une TJS ?
Pour la TJS, on n'avait que droite-droite et gauche-gauche, mais pas droite-gauche. Comment tu la rentres ?

Denis

[Pierre59]

@ 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

[Dominique]

Bonjour à tous,

Je suis très intéressé de voir le résultat de ces opérations : création/modification du fichier JSON de description du réseau avec une application (Denis offre la première appli sous Processing), puis importation du fichier JSON dans le gestionnaire de référence (non personnalisé que je suppose être celui de Pierre59 décrit dans les articles 154, 167, 172 te 184) pour obtenir un gestionnaire entièrement paramètre dans lequel il faut intégrer la gestion des capteurs et actionneurs.

De mon coté, j'avais fait le paramètrage "à la main" du gestionnaire de mon réseau (avec un peu d'aide de Pierre que je remercie).
J'ai développé et utilisé divers outils de mise au point de ce paramètrage, dont surtout une représentation graphique de mon réseau dans le même Arduino Due équipé d'un écran 5".

Evidemment, je vais faire l'exercice sur mon réseau pour appliquer ce qui sera fait sur le locoduinodrome 2.

Mais en attendant je veux conserver la représentation graphique de mon réseau qui sera déportée cette fois-ci, via le bus Can, sur une carte graphique de 7 pouces équipés d'un Teensy3.6 et du Can. Cette carte est bien plus rapide que le Due.
Vous avez compris que je ne veux pas de PC sur mon réseau et Processing dans un RPi n'est pas aussi cool que mon projet.

Pour ce faire, j'ai dupliqué la liste des objets aiguilles et zones de mon gestionnaire et écrit les méthodes graphiques à partir de simples tracés de rectangles (pour les lignes horizontales et verticales) et d'arcs pour les courbes.

Cela donne les images ci-dessous. Le programme permet aussi de commander les aiguilles et les itinéraires par un simple clic sur celles-ci, avec envoi par Can des commandes au gestionnaire, qui commande les affichages (occupations, libérations, affichage du suivi des trains) sur ce TCO. Il manque encore pas mal de choses à faire comme les signaux et diverses commandes et affichage, façon Méru par exemple.
Mon idée est de rapprocher ce système de ce projet de gestionnaire.

[DDEFF]

@ Pierre,

J'ai compris ce qui me chagrinais dans la première version du JSON.
Comme d'habitude, chez moi, c'est en essayant de régler un cas très complexe que j'ai trouvé la solution (je pense)



L'idée c'est d'ajouter une variable "forme" dans la class "Zone"
Là, il y a 10 formes (AC, AD, AE, AF, AG, BC, BD, BE, BF, BG)

Un segment, c'est 1 forme
Un croisement, c'est 2 formes, comme une aiguille, un enroulé
Un triple, c'est 3 formes, comme une TJS
Une TJD, c'est 4 formes.

Par ailleurs, on décrit un voisin1 comme étant l'origine de la description, et voisin2 comme étant l'extrémité de la description.
On décrit donc, dans le sens correspondant à la parité, voisin1 -> la zone -> voisin2
Si c'est une zone banalisée, on décrit dans un sens, mais on indique que ça peut être pris dans les 2 sens lors de la définition de la parité.

On décrit forme par forme.
Il n'y a ainsi aucune ambiguïté pour définir voisin1 et voisin2 et on donne la liste des aiguilles considérées avec leurs positions pour chaque forme.
Et c'est applicable partout.

Je vais adapter mon éditeur JSON à cette nouvelle vision des choses.

Denis

[Pierre59]

@ 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

[Pierre59]

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

Pierre

[DDEFF]

@ Pierre,

C'est ce que je proposais dans un post et dans mon programme. Pourquoi "E" pour le triple ?

Je suis OK pour le terme "trajet" car on peut dire "trajets" et "trajet", ce qui n'est pas le cas de "parcours" 

Je propose, pour les trajets de Z3 :

Code: [Sélectionner]

"trajets" : [
    {
        "trajet" : "AB",
        "voisin1" : "Z5",
        "voisin2" : "Z1",
        "aigs" : [
            {
                "aig" : "A1",
                "pos" : "droite"
            },
            {
                "aig" : "A3",
                "pos" : "droite"
            }
        ]
    },
    {
        "trajet" : "AD",
        "voisin1" : "Z5",
        "voisin2" : "Z0",
        "aigs" : [
            {
                "aig" : "A1",
                "pos" : "droite"
            },
            {
                "aig" : "A3",
                "pos" : "gauche"
            }
        ]
    },
    {
        "trajet" : "CD",
        "voisin1" : "Z4",
        "voisin2" : "Z0",
        "aigs" : [
            {
                "aig" : "A1",
                "pos" : "gauche"
            },
            {
                "aig" : "A3",
                "pos" : "gauche"
            }
        ]
    }
]

Denis

[Pierre59]

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

[DDEFF]

@ Pierre,

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...
Les trajets complets sont peut-être un peu plus lourds, mais nettement plus simples à imaginer.

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

Denis

[Dominique]

Avec des demi-trajets, j'ai peur que cela devienne plus compliqué que l'avantage à en déduire.

Mais je n'ai sans doute pas encore bien compris pour le moment.

Et l'application éditeur de JSON nécessite un dessin du réseau au préalable.

[Pierre59]

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

[DDEFF]

@ tous,

Sans faire les modifs du JSON (pour l'instant), j'ai corrigé quelques bugs signalés par Dominique.

Voici la nouvelle version, normalement plus ergonomique. Il reste les bugs avec les fenêtres qui ne sont pas toujours au 1er plan (mais je n'ai pas la solution...)

Denis

[DDEFF]

@ Pierre,

Voici une autre proposition, en exemple, pour Z3 et Z4:

Code: [Sélectionner]

"Zone": [
           [
               "nom" : "Z3",
               "sens" : "banalise",
               "trajets" : [["Z5","Z1",["A1","droite","A3","droite"]
                               ["Z5","Z0",["A1","droite","A3","gauche"]
                               ["Z4","Z0",["A1","gauche","A3","gauche"]]
           ]
           [   "nom" : "Z4",
               "sens" : "pair",
               "trajets" : [["Z3","Z6",["A2","gauche"]
                               ["Z2","Z6",["A2","droite"]]
           ]
       ]
Denis