Auteur Sujet: Projet partagé d'un gestionnaire de réseau  (Lu 160685 fois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3045
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #165 le: janvier 11, 2024, 12:35:04 pm »
Quel type cible faudrait-il pour chaque signal ?
Cordialement,
Dominique

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #166 le: janvier 11, 2024, 12:42:20 pm »
- s1 et s3 sémaphores (feux Vl, A, S)                                                                 => type A
- s2 et s4 sémaphores avec ralentissement  (feux Vl, A, S, R)                               => type F
- c1 et c2 carrés (feux Vl, A, C) ajout possible (feux S, M)                                    => type C
- c3 et c6 carrés (feux Vl, A, C) ajout possible (feux S, M)                                    => type C
- c4 et c5 carrés rappel de ralentissement(feux Vl, A, C,RR) ajout possible (feu S)  => type H
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3045
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #167 le: janvier 11, 2024, 02:30:54 pm »
Chouette ça va être beau 🤩
Cordialement,
Dominique

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #168 le: janvier 11, 2024, 05:25:08 pm »
Bonjour

@ Denis

C'est toi qui as parlé de tables pour décrire un réseau, est ce que l'on peut décrire complètement un réseau pour générer un gestionnaire automatiquement, par le biais par exemple d'un ficher .json. Ce format est pris en charge par l'Arduino et aussi par Java.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #169 le: janvier 11, 2024, 06:34:52 pm »
@ Pierre,

Oui, on peut décrire entièrement un réseau à l'aide de tables. Et heureusement... :D

Dans mon éditeur, je fais un dessin et je sauve dans DES tables.
Cela me permet de mémoriser le dessin du réseau pour pouvoir faire une sauvegarde entre deux séances de dessin dans l'éditeur
Mais ces mêmes tables me permettent de récupérer le parcours du réseau dans mon gestionnaire.

Dans ma première version, je sauvais tous les pavés dans une seule table. Ça marchait, mais l'objet Pave() récupérait des infos un peu partout et avait une liste de variables dingue.

Depuis, je fais plusieurs tables :

1°) Une table pavés, nécessaire, mais plus petite.
2°) Une table par type de forme. J'ai trois formes :
  - Une forme D qui est un segment de droite
  - Une forme C qui est une courbe qui ressemble à un C
  - Une forme S qui est une courbe qui ressemble à un S
Je reviendrais sur les détails
3°) Une table qui me dit ce qu'il y a dans la palette et où dans la palette. Evidemment, elle ne sert que pour l'éditeur puisqu'il n'y a pas de palette dans le gestionnaire.
4°) Une table de tous les connecteurs entre les pavés, nécessaire dans l'éditeur
5°) Je ne l'ai pas encore, mais je pense qu'il faut une table des connecteurs entre les zones. Dans un gestionnaire, on ne s'occupe pas des pavés qui constituent les zones. Ce qui sert, ce sont les connecteurs d'extrémité de zones.

Dans Processing (je ne t'apprends rien, mais c'est pour les autres), on n'a droit qu'à 3 types : Entier (Int), flottant (Float et c'est "nouveau") et Caractères (String). Pas de booléens.
Fort heureusement, le format .tsv (Tabulation Separated Values) et le même que le format natif d'Excel, ce qui fait qu'on peut lire sans problème les .tsv dans Excel. Cela simplifie grandement la mise à jour et les vérifications.

Revenons sur les détails des formes :
Table D :
ID_pave   alpha0   alpha1   baseG0x   baseG0y   baseG0z   baseG1x   baseG1y   baseG1z   cible0   cible1   cib_v0   cib_v1   butoir0   butoir1   meca0   meca1   t_cib0   t_cib1

ID_pave              = identifiant
alpha0 ou 1         = angle de l'extrémité 0 ou 1 du segment de droite
baseG0 x, y ou z = coordonnées absolues de l'extrémité 0 du segment
baseG1 x, y ou z = coordonnées absolues de l'extrémité 1 du segment
cible 0 ou 1         = la valeur donne l'affichage C, S, A, VL...
cib_v0 ou 1         = cible 0 ou 1 visible. Dans un dépôt, on y respecte la sécurité avec des vrais agents. Là, c'est avec une cible invisible.
butoir0 ou 1        = présence d'un butoir à l'extrémité 0 ou 1
meca0 ou 1         = signal mécanique (ou lumineux) à l'extrémité 0 ou 1
t_cib0 ou 1          = type de cible (A, C, F, H, ...) à l'extrémité 0 ou 1

Table C :
Une courbe C peut avoir 2 types :
  - La courbe C "cercle" qui est une courbe en 3 morceaux : un segment de droite, un arc de cercle, un segment de droite. Eventuellement, les segments de droite sont de longueur
    nulle et on a un vrai cercle.
  - La courbe C "parabole" qui est en un seul morceau et qui sert aux raccordement paraboliques, avec affichage simultané de la "parabole" et de "droite + cercle" pour qu'on puisse
    voir ce qu'on choisit

ID_pave   alpha0   alpha1   baseG0x   baseG0y   baseG0z   baseG1x   baseG1y   baseG1z   baseG2x   baseG2y   baseG2z   baseG3x   baseG3y   baseG3z   baseG4x   baseG4y   baseG4z   baseG5x   baseG5y   baseG5z   cercle1   parabo1   rayonc1   ratioc1   centr1x   centr1y   centr1z   cercle2   parabo2   rayonc2   ratioc2   centr2x   centr2y   centr2z   cible0   cible1   cib_v0   cib_v1   butoir0   butoir1   meca0   meca1   t_cib0   t_cib1

Je ne détaille pas tout, simplement qu'il faut 4 paramètres pour dessiner une courbe de Bezier cubique (l'arc de cercle) + 2 points pour les segments de droite, soit 6 points de BaseG0 à baseG5. J'ai aussi l'affichage sur les pupitres des centres des cercles suivant qu'on est coté 1 ou 2 (je ne rentre pas dans les détails).
Mais quand on dessine à l'échelle, il faut tout savoir.

Table S :
Une courbe S est formé de 2 courbes C tête bêche, soit 4 types : cercle - cercle, cercle -parabole, parabole - cercle, parabole - parabole.
Tout est modifiable à la souris : point d'inflexion, centre des cercles.
 
ID_pave   alpha0   alpha1   baseG0x   baseG0y   baseG0z   baseG1x   baseG1y   baseG1z   baseG2x   baseG2y   baseG2z   baseG3x   baseG3y   baseG3z   baseG4x   baseG4y   baseG4z   baseG5x   baseG5y   baseG5z   baseG6x   baseG6y   baseG6z   baseG7x   baseG7y   baseG7z   baseG8x   baseG8y   baseG8z   baseG9x   baseG9y   baseG9z   basG10x   basG10y   basG10z   cercle1   parabo1   rayonc1   ratioc1   centr1x   centr1y   centr1z   cercle2   parabo2   rayonc2   ratioc2   centr2x   centr2y   centr2z   ptBleux   ptBleuy   ptBleuz   cible0   cible1   cib_v0   cib_v1   butoir0   butoir1   meca0   meca1   t_cib0   t_cib1

On voit bien sur ces exemples que, si ces infos sont utiles pour le dessin du TCO dans le gestionnaire, ça ne sert à rien dans le gestionnaire lui-même.

Table des connecteurs :

X0x   X0y   X0z   pave0   cote_p0   form_p0   alpha0   pave1   cote_p1   form_p1   alpha1   atelier   retrait

X0x, y et z = coordonnées absolues du connecteur
pave0        = indice du pavé côté 0
cote0         = côté du pave0 relié au coté 0 du connecteur
forme0       = forme du pave0 reliée au côté 0 du connecteur
alpha0        = angle du côté 0 du pave0 du côté 0 du connecteur (vous suivez  :o)
Pareil pour le côté 1 du connecteur avec le pave1.
atelier         = si ce pavé est dessiné dans l'atelier, sur le TCO ou dans la palette
retrait         = si c'est une coupure de rail

Table Pavé :

ID_pave   X0x   X0y   X0z   v_devie   v_limit   ID_zone   manoeuv   type   poids   ligne00   ligne01   ligne10   ligne11   ligne20   ligne21   ligne30   ligne31   ligne40   ligne41   ligne50   ligne51   ligne60   ligne61   ligne70   ligne71

Les premiers sont évidents, les lignes correspondent aux lignes où on retrouve le pavé dans la table des connecteurs. C'est utile pour "remonter" dans la table des connecteurs quand on construit un itinéraire.

Voilà voilà...

Denis

"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1085
  • HO avec DCC++
    • Voir le profil
Re : Re : Projet partagé d'un gestionnaire de réseau
« Réponse #170 le: janvier 11, 2024, 08:49:51 pm »
Chouette ça va être beau 🤩

Oui ça va être beau ! La signalisation lumineuse m'a toujours fasciné sur les réseaux depuis tout gamin.

J'ai hâte de voir comment chacun aura appréhendé le sujet !

Christophe

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #171 le: janvier 12, 2024, 07:44:38 am »
Bonjour

@ Denis

Ce que l'on cherche à mettre en tables c'est la topologie d'un réseau, pas le dessin de ce réseau.

Par ailleurs Processing a tous les types de Java : boolean, char, byte, short, int, long, float et double.

Amicalement

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3045
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #172 le: janvier 12, 2024, 10:51:27 am »
Quels sont les éléments nécessaires qui décrivent la topologie ?
Ces données serait entrées comme paramètres d’initialisation du gestionnaire.

Peut-être qu’un éditeur de topologie simple serait faisable pour fournir ces données dans un fichier json.

Est-ce une bonne approche de la question ?
Cordialement,
Dominique

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #173 le: janvier 12, 2024, 04:21:27 pm »
j'ai fait un essai à la va-vite avec un fichier JSON pour décrire la topologie d'un réseau. Il y a juste trois zones et trois aiguilles, cela n'a rien à voir avec un réseau réel, c'est juste pour essayer certains mécanismes.

Il y a aussi des essais pour définir les précédents et les suivants des zones. Je n'aime pas trop les termes de précédents et suivants car cela oriente d'une certaine façon les zones et pose des problèmes avec les sens des trains et les boucles de retournement. J'ai utilisé le terme de VOISIN, il n'y a que deux voisins pour une zone (notés voisin1 et voisin2).

{
  "zones": [
    { "nom":"Z1","no":1 },
    { "nom":"Z2","no":2 },
    { "nom":"Z3","no":3 }
  ],
  "aiguilles": [
    { "nom":"A1","no":1 },
    { "nom":"A2","no":2 },
    { "nom":"A3","no":3 }
  ],
  "voisins": [
    { "voisin1": { "zone":"Z1","vois":"Z2"}},
    { "voisin2": { "zone":"Z1","cas": [
        { "vois":"Z2","aigs":[ {"aig":"A1","pos":"gauche"}, {"aig":"A2","pos":"droite"} ]},
        { "vois":"Z3","aigs":[ {"aig":"A1","pos":"droite"}, {"aig":"A2","pos":"gauche"} ]}
      ]
    }}
  ]
}

J'ai écrit à l'arrache un programme Processing qui traite ce fichier json. Ce programme crée les objets (instances) nécessaires pour les aiguilles et les zones automatiquement.

A l'aide de la description des voisins il crée des fonctionnelles qui permet aux zones d'obtenir dynamiquement en fonction de la position des aiguilles les voisin1 et les voisins2. On a donc une topologie dynamique du réseau.

Le fichier json donne pour les zones voisines une liste de position d'aiguilles. Exemple pour aller Z1 vers Z2 il faut que l'aiguille A1 soit à gauche et l'aiguille A2 à droite, pour aller de Z1 vers Z3 il y a d'autres contraintes.

Le fichier json est écrit avec un éditeur de texte et c'est plutôt pénible avec les accolades et les crochets. Je pense que l'on doit pouvoir tout coder ainsi.

Le programme Processing est trop mal écrit pour être publié pour l'instant.

Pierre
« Modifié: janvier 13, 2024, 11:56:53 am par Pierre59 »

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #174 le: janvier 12, 2024, 05:51:14 pm »
Bonjour,
Citer
Par ailleurs Processing a tous les types de Java : boolean, char, byte, short, int, long, float et double.
Bien sûr, Processing possède tous ces types. Mais il n'y a que 3 types pour les Table() : int, float, string.

Je suis d'accord avec le fait que j'ai surtout décrit ce qu'il faut pour dessiner un réseau. D'un autre côté, c'est le cœur de mon système : on dessine et on ne nomme rien.

Je ne suis pas convaincu par la typographie de JSON : c'est lourd et sujet à plein d'erreurs de frappe.

J'arrive, avec Processing aussi, à faire un gestionnaire qui fonctionne à partir d'Excel, qui, à mon avis, est nettement plus souple d'emploi et moins sujet aux fautes de frappe.
Un fichier "zones", un fichier "aiguilles", un fichier "voisins", ...
L'autre avantage pour un utilisateur débutant, c'est qu'il n'y a pas, dans la saisie, à tenir compte d'une structure sous-jacente. Ce sont des données brutes.
Le programme qui va traiter ça va être plus compliqué, évidemment, mais quel plaisir de ne pas avoir à se creuser la tête à la saisie.

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Re : Projet partagé d'un gestionnaire de réseau
« Réponse #175 le: janvier 12, 2024, 06:18:27 pm »
Je ne suis pas convaincu par la typographie de JSON : c'est lourd et sujet à plein d'erreurs de frappe.

Je suis bien d'accord. Tu pourrais donner des idées de ce qu'on pourrait écrire dans le ou les fichiers pour le gestionnaire.

Pierre.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1085
  • HO avec DCC++
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #176 le: janvier 12, 2024, 06:35:34 pm »
Bonsoir à tous,

Perso, j'utilise un fichier json pour stocker toutes les informations concernant les paramètres de mon réseau car je trouve cela pratique. Mon fichier json est stocké en flash de l'ESP32 et ça aussi c'est vraiment pratique.

Il existe une excellente bibliothèque qui fonctionne sur Arduino et ESP32 et qui simplifie grandement le travail : https://arduinojson.org/

Très nombreuses méthodes pour convertir à partir de nombreux standards vers json ou vis et versa.

C'est vrai que la syntaxe de json n'est pas très intuitive mais il existe des éditeurs en ligne qui permettent de valider ou qui soulèvent les erreurs.

Attention toute fois avec json à ne pas être trop verbeux car tout ceci est quand même du texte et chaque caractère un byte, ça peut vite donner des fichier d'1 Mo !!!

Christophe
« Modifié: janvier 12, 2024, 09:19:30 pm par bobyAndCo »

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #177 le: janvier 13, 2024, 08:56:23 am »
Bonjour,

En fait, pour dessiner, j'utilise des formes (c'est d'ailleurs toi qui m'as donné cette brillante idée).

La caractéristique essentielle d'une forme c'est que, quelle qu'elle soit, elle n'a que 2 extrémités. Pas plus, pas moins : pile 2.

Si on raisonne en formes et pas en élément de voie, on est toujours dans la même situation, même dans les appareils de voie.
Autant, pour dessiner, je dois décrire tout un tas de formes dans le détail alors que, là, on peut raisonner par "lignes" qui sera une suite de formes simples.

Les lignes :

Voir le schéma (il vaut mieux l'imprimer pour pouvoir comprendre et vérifier :

Les zones (en dehors de z3, z4, z11 et z12) sont constituées d'une seule ligne.

Je donne comme nom de ligne un entier (ça prend peu de place) qui démarre par 1, non significatif.

Il est composé du numéro de zone, puis du numéro de ligne dans la zone.
soit 100000+10*z+l
La ligne 0 (= z0) s'appelle 100000
La ligne 1 (= z1) s'appelle 100010
La ligne 2 (= z2) s'appelle 100020

La ligne 10 (= z10) s'appelle 100100
Passons maintenant aux appareils de voie :
z3 est composé de 3 lignes :
100031, 100032, 100033
z4 est composé de 2 lignes :
100041, 100042
z11 est composé de 3 lignes :
100111, 100112, 100113
z12 est composé de 2 lignes :
100121, 100122

Comme on le voit, j'ai volontairement mis un 0 comme numéro de ligne quand il n'y avait qu'une ligne dans la zone. Ainsi, quand on lit le nom de la ligne, on sait immédiatement qu'il n'y a pas à chercher d'autre numéro de ligne dans cette zone.

Dans les appareils de voie, les lames donnent une seule direction pour une position donnée.
Donc, la position des lames donne une et une seule ligne.
Le dernier chiffre de la ligne donne donc la position des lames.

Remarque importante :

Les lignes sont orientées et j'ai mis (en rouge sur le schéma) un 0 au début de la ligne et un 1 en fin de ligne.
 
La notion SNCF de pair-impair est difficilement applicable strictement aux réseaux miniatures à cause des boucles de retournement et, dans la pratique, on pourra toujours trouver des cas où ça n'est pas applicable. Il suffit donc de mettre des 0 et des 1 pour le sens de la ligne ET DE S'Y TENIR.

Il va y avoir une table des lignes avec la longueur des lignes comme premier critère.

Les connecteurs :

Un connecteur, c'est un point entre 2 lignes (dans un carré rouge sur le schéma).

Pour construire la table des connecteurs, je procède en 2 étapes :
Dans Excel, pour simplifier la saisie, on a :



En gain de place dans la table, on crée le nombre ZLC précédé d'un 1 non significatif.
soit 100000+100*z+10*l+c



Remarque 1 : un connecteur n'est pas orienté. Vous pouvez choisir de construire la ligne dans le sens qu'on veut. C'est souvent plus simple de partir de l'aiguille en pointe.

Remarque 2 : cette table est statique : l'identifiant d'un connecteur peut générer plusieurs lignes A CE STADE. Ce ne sera plus vrai après, quand on aura la position de toutes les lames.

On a donc atteint 2 objectifs :
1°) Une saisie brute simple dans Excel
2°) Description du réseau économe en place

Dans la description des lignes, il sera utile de savoir à quelle ligne des connecteurs est situé la ligne coté 0 et la ligne côté 1
Pour cela, il faut d'abord connaitre la table des connecteurs dynamique, c’est-à-dire tenant compte de la position des lames. Quand on a la position des lames, on n'a qu'une et une seule ligne côté 0 et côté 1 pour chaque zone.

Connaître la position des lames c'est la toute première chose à faire à chaque tour.

Puis on calcule l'ArrayList des connecteurs dynamiques.
Puis on a une procédure qui cherche pour chaque ligne la ligne suivante côté 0 et côté 1.
On en déduit quelles lignes n'ont pas de suivante et, donc, où il faut afficher le carré.

Remarque :

Un train est toujours sur la dernière zone d'un itinéraire (un itinéraire est orienté) et il s'ensuit que la première zone d'un itinéraire n'a pas de suivante et affiche donc le carré.
Avant que je continue, dites-moi ce que vous pensez de cette première partie.

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #178 le: janvier 13, 2024, 12:04:23 pm »
Bonjour

Sur les conseils de Christophe, j'ai regardé les éditeurs de fichiers json. C'est beaucoup plus pratique.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #179 le: janvier 13, 2024, 01:04:12 pm »
@Pierre

C'est sûr que, moi, je pars d'un dessin et que je n'ai rien à rentrer pour arriver au même résultat.
D'ailleurs, sur le schéma, j'ai dû tout rentrer à la main sur le dessin issu de mon éditeur (qui ne comporte aucun texte parce que je ne m'en sers pas)
Mais il faut faire le dessin dans un éditeur spécifique...

Ce que je crains, c'est qu'on s'achemine vers une méthode totalement incompatible avec mon gestionnaire, bien qu'elle ait, elle aussi, besoin d'un bus CAN pour passer des trains virtuels aux trains réels.

Denis
« Modifié: janvier 13, 2024, 01:08:04 pm par DDEFF »
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)