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 :
"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.
class Node
{
private:
…
…
public:
Node();
Node *nodePeriph [nodePsize]; // nodePsize = 4, 6, 8 ...
…
…
}
Et dans le constructeur :
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
