Projet partagé d'un gestionnaire de réseau

[Pierre59]

Je viens de tester. Ça fonctionne, mais je ne retrouve pas tous les voisins (ou je n'ai pas compris)
z3 et z11 ont plus de 2 voisins et je ne les retrouve pas dans le test, vraisemblablement des choses à rajouter dans le JSON ?

Z3 a deux voisins1 et deux voisins2, cela fait 2x2 quatre voisins ?, pareil pour Z11.

Pierre

[DDEFF]

@Pierre

Moi, j'ai ça en sortie Je n'ai qu'une ligne pour z3

Code: [Sélectionner]

TEST
zone : Z0 voisin1 : Z3 voisin2 : Z11
zone : Z1 voisin1 : Z3 voisin2 : Z11
zone : Z2 voisin1 : Z12 voisin2 : Z4
zone : Z3 voisin1 : Z4 voisin2 : Z0
zone : Z4 voisin1 : Z3 voisin2 : Z6
zone : Z5 voisin1 : Z7 voisin2 : Z3
zone : Z6 voisin1 : Z4 voisin2 : Z8
zone : Z7 voisin1 : Z9 voisin2 : Z5
zone : Z8 voisin1 : Z5 voisin2 : Z10
zone : Z9 voisin1 : Z11 voisin2 : Z7
zone : Z10 voisin1 : Z8 voisin2 : Z12
zone : Z11 voisin1 : Z9 voisin2 : Z9
zone : Z12 voisin1 : Z10 voisin2 : Z2


[Pierre59]

@ Denis

Ce que tu montre ce sont les voisins en tenant compte de la position des aiguilles (toutes gauches), regarde la liste des zones il y a tous les voisins potentiels.

Pierre

[DDEFF]

@ Pierre

Yeah ! J'ai compris !
On a d'une part tous les cas possibles et d'autre part, les zones connectées pour une position d'aiguilles donnée.

OK, ça me va

Denis

[DDEFF]

@Dominique

Oui, c'est du Processing
D'ailleurs, dès que j'aurais bien compris le JSON, je ferai un "éditeur de JSON" en Processing, car je le connais "bien" et qu'on peut y gérer des questions/réponses.
Et, comme mon éditeur graphique est en Processing, je pourrais réutiliser plein de choses pour qu'il génère automatiquement le JSON (dessin -> JSON)

Denis

[DDEFF]

@ Pierre

Finalement, je ne comprends pas tout.
Dans tous les cas possibles, je ne vois pas ce que viens faire A4 dans Z3 ?
Par ailleurs, une TJS n'a que 3 formes possibles :
A1 à droite et, à ce moment là, on se moque de A3 = lien entre z5 et z1
A3 à gauche et, à ce moment là, on se moque de A1 = lien entre z0 et z4
A1 à gauche et A3 à droite = lien entre z5 et z0

Denis

[Pierre59]

@ Denis

Faut pas trop s'inquiéter, le fichier json a encore plein d'erreurs (Z3 c'est une erreur) et je n'ai toujours pas eu de réponses sur le nommage des TJS, mais je pense que pour les TJS (comme les TJD) il faut la position des deux aiguilles, à voir.

Faut plus se focaliser sur la forme du fichier json et sur son traitement.

Pierre

[Dominique]

@ Denis

Faut pas trop s'inquiéter, le fichier json a encore plein d'erreurs (Z3 c'est une erreur) et je n'ai toujours pas eu de réponses sur le nommage des TJS, mais je pense que pour les TJS (comme les TJD) il faut la position des deux aiguilles, à voir.

Faut plus se focaliser sur la forme du fichier json et sur son traitement.

Pierre

Pour le nommage des TJS, nommons A5 côté z0, A7 côté z12, A3 côté z0 et A1 côté z4.
Au moment du câblage on pourra toujours permuter les fils de commande pour obtenir les chemins souhaités. N’ayant pas de TJS sous la main je propose ça comme convention pour démarrer avec les chemins donnés par Denis ci-dessus. Ce ne sera pas la seule erreur à corriger plus tard si erreur il y a.



J’ai bien une TJD dans un tiroir à la maison, mais je ne suis pas chez moi .

[laurentr]

Bonsoir

Pour le nommage des aiguilles je recommande cette approche:

Pour préciser qui est A1 et A3 on prend le sens de circulation anti horaire de la "V1" et on incrémente les appareils de numéros impaires au fur et a mesure de leur introduction sur la "voie principale" dans le sens de circulation nominal (le plus souvent utilisé)

Donc A1 est la première lame de la TJS (la plus à gauche) A3 celle placée à droite

L'itinéraire "voie" principale favorise toujours un positionnement des lames en position directe (non déviée) ou par prise en talon d une aiguille ( pour Vmax)

Par principe sur une voie on ne trouve pas:

• d aiguille triple (au moins en double voie et on évite en VU sauf ligne "secondaire")

• la direction "droite" d une TJS / TJD est toujours celle qui est retenue

Si la géométrie des appareils le permet on peut passer une aiguille  "déviée" à une vitesse nominale (celle de la zone traversée  <= vitesse max de la ligne)  sinon réduite. ( et par principe réduite dans les autres cas)
Plusieurs vitesses sont possibles grâce au TIV (tableau indicateur de vitesse ex 70) sinon à la signalisation lumineuse par défaut ( Ralentissement 160, 60, 30,...)


Ici V1 avec une circulation à gauche type SNCF tourne dans le sens anti horaire.
V2 dans le sens horaire.

Certes il y aura parfois des "trous" ( ex A1 A2 A3 A5 et pas de A4) mais c est un choix assumé.

Ltr

[DDEFF]

@ Pierre,

J'essaie toujours de comprendre le fichier JSON.

Heureusement, dans ton programme, on a une vision plus simple du même fichier.

Moyennant une indentation et quelques couleurs je suis arrivé à l'image en PJ.
C'est beaucoup plus lisible que le fichier JSON.

Ce qui me parait étrange, c'est que, dans cette liste, puisqu'il y a des Voisin1 et Voisin2, et, donc, qu'on tient compte du sens de circulation, on devrait y voir 2 fois les zones banalisées.
Par exemple Z0->Z3•Z11 et Z0->Z11•Z3

Et pour Z11, on ne voit que Z9 et Z12 comme voisins, alors que cette zone a aussi Z0 et Z1 comme voisins.
Dans chaque zone, il faut la liste de tous les voisins.

En particulier, il y a 3 positions pour une TJS : (A1 droite), (A3 droite), (A1gauche et A3 gauche)

Le problème ne vient pas de ton programme, qui fonctionne, mais du fichier JSON originel.

Ou alors, il n'y a pas de problème et c'est moi qui n'ai pas compris.
Mais j'ai besoin de bien comprendre le JSON pour pouvoir faire un éditeur

Merci d'avance.

Denis

[Dominique]

J'ai la même chose semble-t-il avec Processing4

Code: [Sélectionner]

Aigs [A1, A2, A3, A4, A5, A6]
Zones [
Z0->Z3•Z11,
Z1->Z3•Z11,
Z2->Z12•Z4,
Z3->[Z5_si_[A1=droite, A3=droite],
Z4_si_[A1=gauche, A3=gauche]]•[Z1_si_[A4=droite, A3=droite],
Z0_si_[A1=gauche, A5=gauche]],
Z4->[Z2_si_[A2=droite],
Z3_si_[A2=gauche]]•Z6, Z5->Z7•Z3,
Z6->Z4•Z8,
Z7->Z9•Z5,
Z8->Z5•Z10,
Z9->Z11•Z7,
Z10->Z8•Z12,
Z11->[Z9_si_[A5=gauche, A6=gauche],
Z12_si_[A5=droite, A6=droite]]•[Z9_si_[A5=gauche, A6=gauche],
Z12_si_[A5=droite, A6=droite]],
Z12->Z10•[Z2_si_[A4=gauche], Z11_si_[A4=droite]]]

TEST
zone : Z0 voisin1 : Z3 voisin2 : Z11
zone : Z1 voisin1 : Z3 voisin2 : Z11
zone : Z2 voisin1 : Z12 voisin2 : Z4
zone : Z3 voisin1 : Z4 voisin2 : Z0
zone : Z4 voisin1 : Z3 voisin2 : Z6
zone : Z5 voisin1 : Z7 voisin2 : Z3
zone : Z6 voisin1 : Z4 voisin2 : Z8
zone : Z7 voisin1 : Z9 voisin2 : Z5
zone : Z8 voisin1 : Z5 voisin2 : Z10
zone : Z9 voisin1 : Z11 voisin2 : Z7
zone : Z10 voisin1 : Z8 voisin2 : Z12
zone : Z11 voisin1 : Z9 voisin2 : Z9
zone : Z12 voisin1 : Z10 voisin2 : Z2


[Pierre59]

@ Denis

Le fichier jison c'est juste un exemple, inspiré du locoduinodrome, montrant des possibilités d'écriture. Cela ne présage en rien du format json qui sera adopté, notamment pour les voisins qui ne peuvent pas rester comme cela.
Le fichier est aussi une base pour des essais de transformations vers un gestionnaire.
Les erreurs n'ont pas d'importance, mais j'essaierai de les éliminer peu à peu.

Pierre

[Etienne66]

Y'a un problème avec votre définition :
Certes ça décrit le circuit mais c'est inutilisable tel quel par un gestionnaire.
L'important pour le gestionnaire c'est comment aller d'un signal au suivant, c'est à dire la liste des zones
à traverser ainsi que la liste des aiguillages avec leur position droite ou déviée pour ce trajet.
A partir de vos définitions il faut faire une recherche du genre prévoir 5 coups d'avance aux échecs.
D'une part c'est long, surtout sur un grand réseau, et avec nos circuits ça peut virer à la boucle infinie.
Donc la définition des connexions entre zones doit se faire dans la définition des cantons. (un canton étant la voie entre deux signaux consécutifs)
Autrement dit :
-Pour les zones il faut seulement le nom et l'adresse du capteur de courant.
-Pour les aiguilles, il faut le nom, droite/gauche et l'adresse dcc du décodeur.
-Pour les signaux, il faut le type de cible,la zone précédente et suivante et l'adresse dcc du décodeur.
Et enfin il faut définir les cantons :
-nom, zone de départ,signal entrée, signal sortie,zones traversées dans l'ordre, adresse capteur zone d'arrêt, aiguillages avec position déviée ou non,type de canton normal/manoeuvre ou tout,vitesse limite
exemple :
 z3,408
 a2,g,205
 sig1,b,z0,z3,317
 sig5,a,z6,z8,314
 Can1,z0,sig1,sig5,z3,z4,z6,604,a1-,a3-,a2<,n,60

En utilisant la première lettre des noms comme signification du type le gestionnaire s'y retrouve facilement et le fichier texte ou json est assez explicite.

[Pierre59]

Bonjour

J'ai fait une version un peu plus simple du programme qui transforme le fichier json en un gestionnaire, je peux le publier si besoin. cette version utilise des "lambda expression" appelées aussi fermetures ou clôtures.

Plus intéressant j'ai essayé une version complètement différente de la précédente. Le fichier json est lu ce qui donne un objet json recélant toutes les infos pour le gestionnaire. C'est cet objet json qui va mémoriser toutes les constantes : noms des zones et des aiguilles, sens de zones, types de aiguilles ... et les variables : l'état ("libre" ou "occupe") des zones, l'état "("gauche" ou "droite") des aiguilles, ... Les infos fournies par les capteurs pourront mettre à jour ces variables.

L'avantage de cette version est qu'il n'y a plus d'objets à créer, donc plus de programmation objet.

L'inconvénient est que l'exécution est nettement plus lente, Mais elle peut être accélérée en transformant un peu l'objet json issu de la lecture, par exemple en donnant des numéros aux zones et aux aiguilles et en y accédant non plus par leur noms (clés) mais par les numéros (indiçeage des tableaux). D'autre accélérations sont possibles, mais ce sera toujours plus lent que la première version.

Le programme Processing est téléchargeable ci-dessous. Il fait pratiquement la même chose que la première version.

Pierre

[trimarco232]

(...)
- un seul train par canton,
- des signaux positionnés selon ces règles (sémaphores, carrés, avec ralentissement, etc..),
- des commandes des trains pour le respect des ralentissements et arrêts selon la signalisation,
- des détecteurs de présence et/ou d'identification(RFID, RailCom) des trains par canton, zone, aiguille, etc.
(...)
Dominique

Bonjour ,
je n'ai encore rien lu , ça viendra , mais je souhaite (re)(re)préciser mon point de vue concernant les signaux :
en modélisme , ils n'ont aucune influence sur la marche des trains , c'est des éléments de décor , que l'on s'efforce d'animer avec réalisme , mais ce n'est absolument pas obligatoire
les trains n'agissent pas selon la signalisation , mais obéissent à l'automate , lui-même en fonction des ordres et de la situation du réseau