Projet partagé d'un gestionnaire de réseau

[DDEFF]

Re-bonjour,

Je suis inquiet.

J'étais rentré sur ce fil (et je m'y suis investi) pour trouver une solution à mon problème : trouver une interface Processing-CAN pour faire marcher mon gestionnaire et l'améliorer avec des idées nouvelles qui seraient développées dans ce fil.

J'y ai appris l'existence de fichiers JSON qui, à mon avis, permettent d'unifier le passage de la description de réseau au gestionnaire.

Mais si le but est obligatoirement de porter le gestionnaire sur un ESP32, là, je ne trouverai jamais la solution à mon problème.

Denis

[Dominique]

Re-bonjour,

Je suis inquiet.

J'étais rentré sur ce fil (et je m'y suis investi) pour trouver une solution à mon problème : trouver une interface Processing-CAN pour faire marcher mon gestionnaire et l'améliorer avec des idées nouvelles qui seraient développées dans ce fil.

J'y ai appris l'existence de fichiers JSON qui, à mon avis, permettent d'unifier le passage de la description de réseau au gestionnaire.

Mais si le but est obligatoirement de porter le gestionnaire sur un ESP32, là, je ne trouverai jamais la solution à mon problème.

Denis

Il ne s’agit pas du tout de cela, le gestionnaire pouvant être soit dans une appli Processing sur PC (qui devra donc s’interfacer avec le réseau réel en Can ou autre) soit dans une carte Arduino (pas forcément un ESP32, elle même interfacer au réseau réel et cette fois en Can qui est la solution la plus simple et flable).
Je pense qu’il y a d’autres possibilités.

[Pierre59]

Bonjour,

Je n'arrive pas à faire marcher le programme GestTCO2. Quand j'appuie sur un bouton d'itinéraire, il ne se passe rien.
L'autre programme (GestJ2) plante.
Il faut un mobile ?

Denis

Les deux programmes ne peuvent pas marcher l'un sans l'autre. Il faut lancer le TCO en premier, puis le gestionnaire, celui ci se connecte sur le TCO en TCP/IP et les deux programmes fonctionnent alors ensemble.

Pierre

[DDEFF]

Compredo 

Ça marche, effectivement. Merci
Denis

[DDEFF]

Voici la 3ème version de mon programme Processing : JSON_3

Dans le répertoire "data", il y a le réseau Locoduino2.

J'ai fini la partie ZONES, mais pas la partie JSON car j'ai encore quelques questions à vous poser.

Je suis parti sur la version de Pierre, avec "vois1" et "vois2" qui est effectivement plus simple que la version avec des trajets.
Mais elle suppose qu'on raisonne à partir d'un point virtuel au milieu de la zone, ce qui ne pose pas de problème.

Et que tout "vois1 "voit tout "vois2", ce qui est généralement le cas, sauf des zones où certains "vois1" ne voient pas certains "vois2".
C'est le cas des croisement simples et des TJS.

Il faut donc qu'on se mette d'accord sur la façon dont on doit décrire les croisements et les TJS.

Pour information, pour ceux qui vont aller dans le JSON généré, j'ai généré des TJD pour Z3 et Z11, alors que c'est bien une TJS qui est décrite dans ZONES … et dans le locoduinodrome2.

Par ailleurs, je n'ai pas généré la partie "signaux" car je suis persuadé qu'on peut décrire automatiquement les signaux possibles à partir des seules infos de zone.
Je continue mes recherches. Je pense que c'est assez simple. Au moins une question supplémentaire : la zone est-elle une zone de manœuvre ?
Par ailleurs, j'ai trouvé une méthode pour décrire la "zone complexe" des précédents posts.

Et je n'ai pas généré non plus la partie "itinéraires" car je ne pense pas qu'elle soit nécessaire.
En particulier, je ne me vois pas avoir 180 boutons pour ma gare…

Je suis ouvert à toute question sur ce programme.

Voici le programme et le mode d'emploi :
https://www.locoduino.org/IMG/zip/editeur_json_3.zip

Denis

[Etienne66]

Je continue mes recherches. Je pense que c'est assez simple. Au moins une question supplémentaire : la zone est-elle une zone de manœuvre ?

Denis

Pour les manœuvres on n'a pas besoin d'indiquer le sens vu que c'est toujours bidirectionnel.
Par contre il faut ajouter une valeur possible pour le sens des trains normaux : "aucun"
En effet une voie peut être autorisée uniquement pour les manœuvres (tiroir, dépot)

[DDEFF]

Je ne me suis pas fait comprendre. C'est l'inverse :
Dois-je demander si une zone est une zone de manœuvre ?

J'aimerais que tu m'expliques à quoi peut bien servir une voie autorisée dans aucun sens 

Sinon, si tu as fait tourner le programme, tu as vu qu'il y a bien la possibilité de n'avoir aucun feu sur un segment.

Denis

[Etienne66]

Je veux dire qu'une voie peut être autorisée seulement pour les manoeuvres, dans ce cas aucun sens n'est dispo pour une circulation en ligne.
Par contre c'est toujours bidirectionnel pour les manoeuvres.
Donc le sens ne sert que pour les circulations normales.
Avec l'info de sens, l'info de manoeuvre, et les éventuels aiguillages tu peux ensuite déterminer si les feux ont le carré normal et/ou le violet.

[Pierre59]

@ Denis

Je pars comme base qu'un itinéraire est une liste de zones, cette liste pouvant être établie manuellement ou automatiquement. Dans les deux cas il faut proscrire les cas inexistants des TJS et les cas impossibles avec les croisements.

Une TJS est alors vue comme une TJD. Le croisement est un petit peu plus délicat, il faut le considérer comme une sorte d'aiguille (sans moteur), par exemple soit A0 son nom cela donne pour les voisins de la zone le contenant quelque chose du genre :
   "vois1":[["ZA","A0","droite"],["ZC","A0","gauche"]]
   "vois2":[["ZB","A0","droite"],["ZD","A0","gauche"]]
si la pseudo aiguille A0 est à droite cela fait ZA<->ZB, sinon ZC<->ZD. De plus le fait de considérer le croisement comme une aiguille facilite grandement les tracés continus sur un TCO.

Pour les itinéraires automatiques, il faut juste une zone de départ et une zone d'arrivée (éventuellement un sens), un algorithme récursif peut produire facilement TOUS les chemins possibles pour aller de la zone de départ à la zone d'arrivée, il conviendra d'éliminer les chemins impossibles à cause des TJD ou des croisements et de faire un choix parmi les cas possibles (le gestionnaire peut fournir tous les voisins d'une zone).

Concernant les signaux leur génération automatique pose pas mal de problèmes :
- il faut trouver où les implanter
- il faut trouver le bon type de signal (un S ou un SR, ...)
- il faut savoir s'il faut des ralentissements RR30 ou RR60 et sur quelles aiguilles ils sont basés (attention aux aiguilles courbes ou symétriques)
- il faut faire la distinction entre les carrés et les carrés violets
- il faut savoir si les carrés supportent le BALs (feu S) ou pas
- il faut savoir si les carrés supportent les manoeuvres (feu M) ou pas
- ...

Concernant les itinéraires je pense qu'il faut mieux les décrire manuellement, s'il y en a beaucoup on peut faire une sélection d'itinéraires par bouton départ, bouton arrivée. Et on peut toujours faire une recherche automatique.

Pierre

[DDEFF]

@ PIerre,

Concernant les signaux leur génération automatique pose pas mal de problèmes :
- il faut trouver où les implanter

Je pose la question de l'emplacement dans le programme

- il faut trouver le bon type de signal (un S ou un SR, ...)
- il faut savoir s'il faut des ralentissements RR30 ou RR60 et sur quelles aiguilles ils sont basés (attention aux aiguilles courbes ou symétriques)

Je demande les vitesses, on doit donc pouvoir en déduire pas mal de choses

- il faut faire la distinction entre les carrés et les carrés violets

Je vais poser une nouvelle question : zone de gare (pour ne pas afficher S) et zone de manœuvre pour les feux spécifiques.

Mon but est de régler les cas les plus fréquents sans avoir de compétences SNCF pointues.
Je n'ai pas dit que j'y arriverai, mais je vais, au moins, essayer.

Denis

[laurentr]

Bonjour

Pour le cas du croisement il faut le considérer comme un aiguillage
Il peut être soit autonome et défini la route prioritaire de traversée, soit coupable avec un autre appareil ( ou une série d appareils)

Ex cas d'une BIF (bifurcation) pour savoir si l itinéraire sécant ( passant sur le croisement) est prioritaire sur celui qui est direct ou non.

Ltr

[laurentr]

@Denis

En fait idéalement il est peut être préférable d avoir une pic liste de signaux possibles que m on affecte manuellement et de disposer des conditions qui activent tel ou tel combinaisons sur le feu est présente.
Si absente alors ces infos ne sont pas exploitées.

Ltr

[DDEFF]

@ Laurent,

Je cherche à faire un programme qui permette de rentrer son réseau quand on n'a pas de connaissances SNCF. Ou vraiment très peu.
La liste existe, Pierre en a fait une avec un magnifique gif pour chaque signal, animé si clignotant.
C'est ce qui va être affiché sur le TCO.
Mais pour faire le JSON, je cherche à déterminer quel type de feu doit être là, quelle cible est nécessaire dans telle situation.

Denis

[laurentr]

@Denis

En fait tu peux aussi considérer fonctionner en inverse et ne laisser dispo que ce qui n'est pas "interdit" à sélectionner.

En effet tu ne peux pas forcement toujours transcrire à 100/100 le réel en miniature d'où ces compromis ( ou libertés)
Il faut aussi distinguer dans l'absolu les combinaisons possibles selon l'implantation sur un même signal car tu peux la aussi avoir des différences. (cas des feux clignotant par exemple, cas des manœuvres, ...)
C est un contexte spécifique qui doit alors être paramétré de façon "externe" qui finalisera la cible et les feux affichages/affichés.

Ltr

[Dominique]

@Laurent : je ne suis pas sûr de te suivre
Je fais confiance à Pierre et Denis pour cette phase importante.