Projet partagé d'un gestionnaire de réseau

[DDEFF]

Je pense que l'utilisation de JSON permet de créer un fichier suffisamment structuré.

Par contre, jamais un novice n'ira là dedans tout seul.
Or c'est le but de ce fil : avoir un gestionnaire puissant sans être au fait de toutes les subtilités de la SNCF.

Donc, le challenge, c'est d'avoir une interface ordinateur (PC/MAC) simple qui génère le JSON.

Dans ce but, je trouve qu'on devrait s'en tenir, dans un premier temps, au stricts cas utiles dans le Locoduinodrome.

Cela me permettra, au passage, de comprendre un peu mieux ce qu'est vraiment un fichier JSON.

Denis

[Etienne66]

Je pense que l'utilisation de JSON permet de créer un fichier suffisamment structuré.

Par contre, jamais un novice n'ira là dedans tout seul.
Or c'est le but de ce fil : avoir un gestionnaire puissant sans être au fait de toutes les subtilités de la SNCF.

Donc, le challenge, c'est d'avoir une interface ordinateur (PC/MAC) simple qui génère le JSON.

Dans ce but, je trouve qu'on devrait s'en tenir, dans un premier temps, au stricts cas utiles dans le Locoduinodrome.

Cela me permettra, au passage, de comprendre un peu mieux ce qu'est vraiment un fichier JSON.

Denis

Si tu génères la configuration avec le PC en c++ avec la même structure de données que dans l'arduino tu n'as plus
besoin du json et tu dois pouvoir les transfèrer directement en binaire dans le sketch.

[DDEFF]

@ Etienne

Tu as parfaitement raison : le plus simple, c'est de rentrer toutes les données qui vont bien directement dans un programme de PC.
C'est économe en place, ça marche parfaitement, mais c'est le même problème qu'avec JSON : il fait bien connaître le langage utilisé.
C'est ce qu'on voudrait éviter et que ce soit via un "éditeur de JSON".
Par ailleurs le passage par JSON permet plus d'universalité : c'est indépendant de ce qu'on a fait avant.

Je m'explique : on part d'un JSON et on fait un gestionnaire Locoduino le plus complet possible (en démarrant par une phase simple)
Après, c'est au programmeur de se débrouiller pour partir de son programme spécifique pour générer le fichier JSON.
Une fois le JSON produit, ça roule.

Pour quelqu'un qui part de zéro, il faut faire un "éditeur de JSON".

Denis

[Dominique]

Le bus Can est vraiment simple à utiliser (quelques lignes de code en émission) et fiable (je n'ai jamais d'erreurs dans les compteurs).

Voilà un petit exemple de trace dans le moniteur de l'IDE lorsque mon gestionnaire suit un train (le N° 0 en l'occurence)
Toute cette trace se fait dans le décodeur des messages Can reçus par le gestionnaire pour la mise au point.
Il est facile de visualiser (suiffer) les messages Can et de créer des modules séparés comme un écran graphique déporté ou des commandes d'itinéraires. Pour le moment l'écran graphique est intégré au gestionnaire pour visualiser les occupations, itinéraires, positions des aiguilles, suivi des trains...Mais il peut être déporté et alimenté avec des messages Can.

Il commence par détecter la zone où se trouve le train en le faisant bouger ce qui provoque une détection de présence: 0<60 signifie une commande de vitesse du train 0 en marche arrière au cran 60, qui une fois détecté il est stoppé (0>0)
0<60
Train 0 detecte sur z13
 0>0
Puis le train démarre doucement à la manette, le gestionnaire reçoit la commande Can de vitesse
VLoco 0>5
Puis la z13 détecte une présence mais le train 0 y est déjà détecté et le train peut continuer à rouler car voie libre devant
zp est la zone précédente pour la commande du signal (carré)
La zone devant est identifiée et testée pour ralentir ou stopper le train, ou pas.
z13 Occ  zp12 T0 OK  VOIE LIBRE DEVANT 
VLoco 0>7
VLoco 0>20
VLoco 0>18
VLoco 0>12
z13 Occ  zp12 T0 OK  VOIE LIBRE DEVANT 
z15 Occ  zp13 T0 OK  VOIE LIBRE DEVANT 
z16 Occ  zp15 T0 OK  VOIE LIBRE DEVANT 
VLoco 0>23
VLoco 0>30
z17 Occ  zp16 T0 OK  VOIE LIBRE DEVANT 
là il y a une détection RFID du train
EST-ext z16 T0 (BB20158)  Train ok
z5 Occ  zp17 T0 OK  VOIE LIBRE DEVANT 
Une détection de zone d'arrêt est ici, pouvant arrêter le train reconnu
zAR 5 T0
z39 Occ  zp5 T0 OK  VOIE LIBRE DEVANT 

[Dominique]

Pour quelqu'un qui part de zéro, il faut faire un "éditeur de JSON".
Denis

Il y a des tones d'éditeurs Json sur le web, online ou non


Par exemple : https://jsoneditoronline.org

[DDEFF]

Non, je veux quelque chose qui lui pose des questions.
"Quelle zone voulez vous rentrer ?"
"Dans quel sens voulez vous rouler sur cette zone ?"
etc...

Que l'utilisateur ne soit pas conscient qu'il est en cours d'écriture d'un fichier JSON.

Denis

[Dominique]

il existe une fonction de conversion CSV ->JSON

Il y a peut-être quelque chose à utiliser en partant d'excel ?

[DDEFF]

Je veux bien essayer de m'occuper de cette phase. (questions -> JSON)
Occupez vous de savoir tout ce qui doit être dans ce fichier pour que le gestionnaire fonctionne

Denis

[Etienne66]

Non, je veux quelque chose qui lui pose des questions.
"Quelle zone voulez vous rentrer ?"
"Dans quel sens voulez vous rouler sur cette zone ?"
etc...

Que l'utilisateur ne soit pas conscient qu'il est en cours d'écriture d'un fichier JSON.

Denis

Et surtout ça élimine les erreurs dans le json et donc du code côté arduino. Le code de validation des données est sur le PC.

[DDEFF]

Validez vous ma vision des choses :

"éditeur de JSON" -> JSON -> Gestionnaire Locoduino
En disant que je m'occupe de la partie "éditeur de JSON", je serai aussi confronté à mon problème : "mon éditeur graphique" -> fichiers textes -> JSON.
Mais c'est mon problème.

Denis

[Dominique]

Validez vous ma vision des choses :

"éditeur de JSON" -> JSON -> Gestionnaire Locoduino
En disant que je m'occupe de la partie "éditeur de JSON", je serai aussi confronté à mon problème : "mon éditeur graphique" -> fichiers textes -> JSON.
Mais c'est mon problème.

Denis

Ma réponse est OUI évidemment pour garantir l'absence d'erreurs ou le minimum.

Mais n'étant pas familier du JSON et espérer participer au développement de ce projet, j'aimerai mieux comprendre la structure du fichier JSON (son contenu) a produire et son interface avec le gestionnaire (comment le programme gestionnaire va "digérer" ce fichier JSON pour créer les objets zones, aiguilles, signaux, et paramétrer leurs méthodes .

D'un coté nous avons un prototype de fichier JSON de Pierre dans sa réponse #173 (page 12) et  la proposition d'Etienne dans sa réponse #237 (page 16)
De l'autre coté nous avons les objets zone, aiguilles (https://www.locoduino.org/spip.php?article154) et signaux (https://www.locoduino.org/spip.php?article167) décrits dans le gestionnaire de Pierre.
Et puis, il y a la méthode utilitaire selonAiguille(Aiguille* a,Zone* z1,Zone* z2) qui définit la topologie du réseau donc les connecteurs entre zones. Et j'en passe.

Le programme non paramètré me semble un point de départ nécessaire. Est-ce qu'il est possible d'en avoir une idée ?

[DDEFF]

@ Pierre,

Je décortique ta proposition de JSON.
Si j'ai bien compris, Voisins1, c'est "en reculant" et Voisins2 c'est "en avançant" ?
Par ailleurs, dans une TJS, pour aller vers z1 en venant de z3, il suffit que A1 soit tout droit. A3 indifférent. (voir PJ)

Me trompe-je ?

Denis

[Pierre59]

@ Pierre,
Je décortique ta proposition de JSON.
Si j'ai bien compris, Voisins1, c'est "en reculant" et Voisins2 c'est "en avançant" ?
Par ailleurs, dans une TJS, pour aller vers z1 en venant de z3, il suffit que A1 soit tout droit. A3 indifférent. (voir PJ)

Pour l'instant voisin1 c'est d'un côté et voisin2 de l'autre coté d'une zone, les sens est c'est à discuter (j'en ai déjà parlé précédemment). Je vais rentrer les voisins dans les zones pour le fichier json. Pour les TJS il faut que je peaufine, mais j'attends que l'on précise le nommage des "lames" (j'en ai déjà parlé aussi).

Pierre

[DDEFF]

Les lames :

Dans mon éditeur graphique, les lames sont les formes qui composent l'appareil de voie.
lames = 1 = AB
lames = 2 = CD
lames = 3 = AD

L'avantage, c'est que c'est extensible à n'importe quel appareil de voie, de n'importe quelle forme. Je trouve ça plus clair.

On peut très facilement avoir un tout petit fichier qui transforme la position réelle des lames réelles en un numéro de lames.
Dans le commerce, il y a quelques disparités :
Par exemple, pour une TJD en voie M chez Märklin, il n'y a qu'un seul moteur et 2 positions : le croisement droit et les 2 arcs de cercle.
Chez Peco, si on veut aller tout droit, il n'y a effectivement qu'une seule lame qui bouge, l'autre étant dans une position quelconque. C'est juste pour tourner qu'il faut préciser la position des 2 lames. C'est très proche de la SNCF.

Denis

[laurentr]

@Denis

Pour la position des lames ce n est pas rigoureusement exact pour la TJD
Il y a toujours à considérer en fonction de l entrée sur la TJD et la sortie de la TJD la position des 2 "moteurs" gérant les groupes de lames.

Sinon tu risques de dérailler car avec des servo ce n est pas talonnable.

Beware donc

Ltr