Messages

181

Vos projets / Re : Re : Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 14, 2024, 09:36:14 am »

Écoute Etienne, tu es dans une entreprise de dénigrement systématique :

Tu affirmes : 1- Tu ne peux pas en déduire si c'est une aiguille gauche ou droite ce qui est indispensable pour les signaux de ralentissement.

Et bien moi je affirme que ça ne change rien et qu'on n'a pas besoin de le connaitre et je le démontre dans l’autre fil que j’ai ouvert.

2- Un canton avec 2 entrées et 2 sorties a plusieurs combinaisons possibles d'aiguillages/tjd/tjs

Et alors Ca se gère de manière logicielle également. Quel est le problème ?

Franchement, je n’ai pas envie de passer plus de temps à répondre à ce type d’entreprise.

Nous avons arreté un réseau de test pour que justement chacun montre ses propositions et ses solutions. Pour l’instant, il me semble que je suis le plus avancé sur ce point et que rien ne cloche dans ce que j’ai présenté jusque là. Alors de grâce, soyons dans la construction et pas dans la démolition de quelque chose qui au bout de 15 pages de forum n’existe pas encore ou si peu.

Donc si ça continue comme cela, je vais quitter définitivement ce fil

182

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 14, 2024, 09:23:29 am »

@ Christophe

Ton raisonnement sur la description du réseau se tient pour le vrai réseau que tu testes.

Mais quid des croisements ?
Comment peux-tu le décrire ? Il n'y a pas de position des lames. D'une carte canton à l'autre, c'est tout droit, tout le temps, dans les 4 cantons qui l'entourent.

Par ailleurs, il faut tenir compte de l'occupation par un itinéraire, même avec rien dessus. Or je ne vois pas de notion d'itinéraire dans ton gestionnaire.
C'est peut être en gestation et tu ne l'as pas encore développé, mais, à un moment, il te faudra des itinéraires.

Denis

Mon cher Denis, tu mets pile le doigt sur une limitation que je connais depuis longtemps : le croisement sans aiguille.

Au stade de la description du réseau, ce n’est pas un problème puisque nous sommes bien en présence de cantons mis en relation.

J’attends que le problème se pose concrètement (ce qui n’est pas le cas du réseau de test) pour cogiter sur la chose et c’est bien pour cela que j’ai anticipé dans un post précédent où je dis qu’il y aura quelques cas où !!!

A mon avis, en temps voulu, ça se traitera de manière logicielle où l’on déterminera qu’une voie est prioritaire sur l’autre. Dit autrement, si deux trains veulent s’engager en même temps, le logiciel en autorisera un, puis attendra que les cantons soient libres pour lancer l’autre. C’est de la machine d’état, pas très compliqué non plus.

Mais il y a sans doute d’autres approches. En tous les cas, ça ne contrarie pas ma démonstration.

Pour les itinéraires, je te l’ai déjà dit, ce n’est pas non plus à ce stade qu’il faut l’appréhender. Il y a d’ailleurs des modélistes (probablement le plus grand nombre) qui pilotent à la mano, dont moi !!!

Que l’on précise au moment de la description qu’une voie ne circule que dans un sens ou dans un autre est nécessaire (Pierre l’a inclus dans son fichier json)  mais les itinéraires, c’est une couche logicielle à venir qui viendra justement s’appuyer sur ce qui a été décrit et donc défini comme possible ou pas.

183

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 14, 2024, 09:03:06 am »

Alors nous dirons que ça va occuper 400 octets et non 200. Ca ne change pas grand chose à la démonstration mais ça a le mérite de l'exactitude. Merci et je vais corriger ci-dessus.

184

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 14, 2024, 08:42:58 am »

Par ailleurs, et excusez moi d'enfoncer le clou, mais je pense que vous vous trompez sur ce que recouvre exactement cette notion de zone qu'à priori on ne retrouve que dans RRTC. Dans ce gestionnaire, la zone existe bien mais ce n'est en rien un appareil de voie mais bien la zone  (à l'intérieur d'un canton) qui précède un ou des appareils de voie, eux même inclus dans le canton.

Page 14 du document : http://cdmrail.free.fr/Applis_PDF/cantons_min.pdf

qui dit d'ailleurs : Il n'est pas recommandé de placer des détecteurs de zones sur les zones d'aiguilles.

185

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 14, 2024, 07:29:41 am »

Bonjour,

@tous

Je redis ici ce que je dis depuis le début : Il n’y a pas lieu de retenir le concept de zone dans la description du réseau et de ses liaisons. Cela étant même contre-productif.

Il y a des cantons (et il n’y a que des cantons) avec ou non des appareils de voie (aiguilles, croisements etc…) aux extrémités. Ce qui nous amène à établir une liste de liaisons, point barre.

Vous décrivez une zone comme servant à détecter par consommation de courant la présence ou non d’un convoi. Et alors ? Ca ne justifie pas de la distinguer du canton ou de la traiter sur le même pied d’égalité. Ce que vous appelez zone est un outil de détection, comme d’autres, comme Railcom ou des capteurs IR, ou encore des détecteurs par consommation de courant.

Je ne nie pas l’importance de savoir, par détections de courant ou autres procédés, si un convoi ou une partie de convoi est encore présente sur le canton, bien au contraire. Mais c’est un autre sujet qui n’a pas sa place dans la description des liaisons.

Je pense utile de recopier intégralement le post que j’ai publié hier à 16h03 et qui a sans doute été éclipsé par la discussion très intéressante qui a juste suivie sur les fichiers en json.


" A tous ceux que réfléchissent à la meilleure façon de réaliser la description du réseau, je propose très humblement de regarder le principe que j’ai adopté pour faire cette description. J’en parle car j’ai moi aussi passé beaucoup, beaucoup de temps là-dessus, j’ai moi aussi passé beaucoup de temps à chercher, à regarder ce qui existait (dont le gestionnaire de Pierre). Et puis, j’ai trouvé une méthode qui est simple et surtout qui fonctionne. Alors, pourquoi ne pas la reprendre ?

Je ne parle pas du processus de découverte avec les boutons et les switches dont j’ai parlé dans un autre post mais la méthode et la structure même du fichier de description. Cette structure de description qui a par ailleurs un énorme avantage pour la simplification de la programmation du gestionnaire par la suite.

Il est probable que cette méthode rencontrera un jour des limites (appareils de voies particuliers etc…) mais elle aura fonctionné pour tous les autres cas (nombreux) et je ne doute pas qu’avec de la réflexion, nous arriverons à les résoudre en temps voulu. Comme j’ai pu le dire par avant, commençons par résoudre les cas généraux avant les cas particuliers.

Je précise aussi que ce principe de description vaut tout autant pour des gestionnaires distribués comme j’ai pu le faire que pour des gestionnaires centralisés.

Il faut à la base poser un postulat qui est qu’un canton peut être relié directement à un nombre d’autres cantons que l’on fixe arbitrairement.

Ainsi, pour moi, j’ai fixé à 4 le nombre de cantons auxquels on peut accéder à horaire et le même nombre à anti-horaire. Soit 8 au total. Mais rien n’empêche de dire 10, 12, 16 ou plus. Seules apparaitront sans doute des limites de mémoire du système.

J’ai convenu de préfixer les cantons à horaires avec la lettre « p » pour plus et les cantons à anti horaire avec la lettre « m » pour moins bien sûr.

Voici donc comment sont nommés mes 8 cantons « potentiellement » voisins :

Code: [Sélectionner]

"p00":"null",
"p01":"null",
"p10":"null",
"p11":"null",
"m00":"null",
"m01":"null",
"m10":"null",
"m11":"null",

P00 désigne le canton accessible à horaire s’il n’y a pas d’aiguille ou si la ou les aiguilles sont droites

P01 (lisez cela comme des bits de droite vers la gauche), le canton accessible, 1° aiguille à horaire déviée

P10, canton accessible à horaire 1° aiguille droite (bit 0 à 0), seconde aiguille déviée (bit 1 à 1)

Enfin P11, canton accessible à horaire 1° aiguille déviée (bit 0 à 1), seconde aiguille déviée (bit 1 à 1)

Si j’avais choisi 6 aiguilles, j’aurais eu bien sûr une notation de type P010 par exemple qui fonctionne aussi parfaitement.

Alors, on voit écrit NULL dans le petit tableau ci-dessus extrait de mon fichier json de description. C’est parce que j’ai eu la flemme de modifier cela mais aussi parce que cela va aider à la compréhension de la suite.

TRES IMPORTANT : P00, P01 … P1111 et M00, M01 … M1111 sont toujours créés et « pointent » toujours sur une position constante d’un canton voisin sur le réseau. Ce canton peut exister et auquel cas, dans la programmation, P00 pointera sur une valeur non nulle ou ne pas exister, d’où un pointeur null !

On voit très bien que même si on devait le remplir à la main, il n’est pas très compliqué de renseigner un tel tableau.

Et en procédant ainsi, IL N’Y A RIEN D’AUTRE à renseigner. Les aiguilles sont par exemple créées automatiquement par le logiciel. Si P00 est non nul et P01 est non nul, le logiciel en déduit qu’il y a une aiguille. CQFD mon cher Wattson !

Et il en va de même des signaux et même des cibles à placer.

Et alors, en termes de programmation du gestionnaire maintenant, je peux vous assurer que les économies en temps de programmation et de débug sont considérables.

Les instances de ma classe Node qui représentent les satellites de cantons à l’intérieur du gestionnaire incluent un tableau de pointeurs nodePeriph qui sont aussi de type Node.

Il s’entent que les instances des "voisins" (nodePeriph) sont créées elles aussi automatiquement à l'instanciation de Node et renseignées au moment de l’import du fichier json de description.

Code: [Sélectionner]

class Node
{
private:
  …
…
public:
  Node();
  Node *nodePeriph [nodePsize]; // nodePsize = 4, 6, 8 ...
…
…
}
Et dans le constructeur :

Code: [Sélectionner]

  for (byte i = 0; i < nodePsize; i++)
    this->nodePeriph[i] = nullptr;
nodePsize, c'est le nombre de canton total (maximum) que l'on souhaite avoir.

C’est ensuite que l’on affecte ou non des valeurs à ces pointeurs selon que l’on ait ou non la présence de cantons.

Pour l’avoir expérimenté avec succès depuis plus de 9 mois maintenant, je vous assure que c’est redoutablement simple et puissant.

A votre disposition si vous souhaitez plus d’informations. "

Christophe

186

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 14, 2024, 07:16:31 am »

@Christophe: tu indiquais que si le nombre d éléments augmente ( tu en as retenus on peut s orienter vers des saturation de mémoire. Si je ne me trompe pas les plus gros ESP32 disposent de 16Mo soit 4 fois ceux que tu a retenus pour tes satellites autonomes ( mais peut être pas dispo avec USB etc. en module?) Donc jusqu' à cette saturation on a encore un peu de marge.

@ Laurent

Merci d'aborder ce point. J'ai écrit ceci pour me prémunir des scuds qui ne vont pas tarder à me tomber dessus, aussitôt qu’il y aura (peut-être) un consensus sur la description du réseau.

Je te rassure, en pratique, il n'y a aucune crainte à avoir concernant la mémoire. Je m'explique : Je recommande de modéliser les classes Nodes (ou Cantons, peu importe comment on les appelle à ce stade), avec un nombre de liaisons potentielles (de voisins comme dit Pierre) qui est fixé à l'avance. 4, 6, 8 voisins pour un canton, à chacun de choisir selon l’importance de son réseau.

Cela se traduit dans la classe par un membre qui va avoir cette forme là :  Node * nodePeriph[4]; ou ça Node * nodePeriph[6]; ou encore ça Node * nodePeriph[8];

Je m’attends donc à ce que l'on me dise qu'il est stupide de créer des instances dont beaucoup ne serviront jamais. Après tout, il existe le « new » en c++ qui permet de créer dynamiquement des instances à la demande et selon les besoins. Ce qui est totalement vrai sur le principe.

Mais en pratique, j’expliquerai cela en particulier dans le fil dédié que j’ai ouvert sur les satellites autonomes, nous verrons que ça présente de très nombreux avantages de ne pas, pour cette fois, respecter la règle canonique.

Le seul inconvénient (relatif) de créer des instances qui ne serviront peut-être jamais est que cela consomme de la mémoire !

Mais livrons-nous à un petit calcul, nous parlons ici de pointeur comme nous l’indique l’astérisque ( Node * nodePeriph[4]), un pointeur, quelque soit l’objet sur lequel il pointe, c’est toujours 32 bits en mémoire.

Imaginons que nous ayons que nous ayons 25 cantons avec chacun 4 pointeurs cela donne :
25 x 4 X 32 bits = 3200 bits ou /8 = 400 octets. Bon ça commence à faire mais pas de quoi perturber un ESP32 même à 4Mo de mémoire flash.

L’ambiance quelque peu tendu sur le sujet m’oblige à des circonvolutions très chronophages dont je me dispenserais bien sois en assuré.

Christophe

187

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 10:31:42 pm »

L'idée est sympathique mais il y a plus efficace et plus simple à mon avis.

188

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 09:29:25 pm »

A la sncf on parle de canton, je ne vois pas de zones ? : https://www.sncf.com/fr/groupe/coulisses/regulation-trafic

189

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 09:00:26 pm »

Et pourquoi ne serait-ce pas la même détection de présence que sur la voie qui est avant par exemple ?

190

Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 08:59:13 pm »

Zone = là où il y a une détection électrique

Je ne comprends pas bien pourquoi parler d'une détection électrique ? Détection de présence ? Détection par consommation de courant ?

191

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 07:26:53 pm »

quelle que chose dans ce gout là est même mieux : (peut être faux écrit comme cela mais c'est l'idée)

"zones" : [
    {
      "nom" : "Z0",
      "sens" : "pairimpair",
      "aigs" : [
            {
              "id" : "A1",
              "pos" : "droite",
              "vois" : "ZX"
            },
            {
              "id" : "A3",
              "pos" : "gauche",
               "vois" : "ZY"
            }
          ]
    },

192

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 07:17:00 pm »

Oui c'est bien à cela que je pensais mais je crois (je pense !) que c'est dans zones qu'il faut apporter cette information :

"zones" : [
    {
      "nom" : "Z0",
      "sens" : "pairimpair",
      "voisin1" : ZX,
      "voisin2" : ZY
    },

193

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 07:02:28 pm »

@Pierre, la seconde question ne s'est pas fait attendre.

Je ne vois pas comment se fait le cantonnement, j'entends par là quels sont les zones qui appartiennent au même canton ?

Christophe

194

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 06:57:05 pm »

@Pierre,

J’aime bien ce fichier et cette présentation. Bien sûr, sur de grands réseaux, il faudra automatiser la génération de ce type de fichier, mais pour des ajustements ou pour de petits réseaux comme ici, c’est tout à fait réaliste d’intervenir dessus à la mano.

Je vais avoir d’autres questions mais dans un premier temps, pourquoi la distinction voisin1, voisin2 ?

PS : Intervenir à la mano dans un fichier reste toujours délicat (ligne 332 drpite au lieu de droite !)

195

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 13, 2024, 06:12:49 pm »

Je pense par ailleurs que tu abordes trop vite la notion d'itinéraire. Elle est importante mais vient après dans l'analyse