Un gestionnaire en C++ pour votre réseau (1)
Aiguilles et Zones
. Par :
Vous répondez à :
Bonjour Pierre59,
Excellent travail ! En lisant l’article et en allant faire un tour sur le forum, je me rends compte que j’ai du TAF sur la planche pour rattraper le niveau !
Pourrais-tu expliquer le terme "aubiner des signaux" qui doit être un terme SNCF mais dont on ne dit rien dans le dicco. (C’est dans la deuxième étape : l’héritage)
De plus, je dois dire que j’ai été un peu gêné dans la lecture de cet article par l’absence de figure, sur des choses qui sont certainement simples et pourtant pas toujours clairement établies. Prenons un exemple, celui du canton en analogique. Tout le monde a sa propre définition mais dans la réalité, comment le reconstituer sur le réseau ? Doit-il avoir une zone de pleine voie (ou pleine vitesse) et une zone d’arrêt, ou bien une zone de pleine vitesse, une zone de ralentissement et une zone d’arrêt. Si la voie est à double sens, combien de zones différentes à prévoir, quelle longueur optimale. A partir de là, on peut alors mieux imaginer en quoi consisterait les méthodes liberer() ou occuper().
Je ne sais pas si j’ai été très clair, mais pour moi, le software est fortement lié au hardware, (même si on cherche à obtenir un modèle universel), et la question que je me pose est : Est-ce que ce que tu développes peut fonctionner pour une solution matérielle un peu différente ? Je pense que oui, mais avec un exemple concret, j’en serais sûr.
17 Messages
-
Un gestionnaire en C++ pour votre réseau 10 mars 2016 14:55, par Christian
Bonjour Pierre59,
Excellent travail ! En lisant l’article et en allant faire un tour sur le forum, je me rends compte que j’ai du TAF sur la planche pour rattraper le niveau !
Pourrais-tu expliquer le terme "aubiner des signaux" qui doit être un terme SNCF mais dont on ne dit rien dans le dicco. (C’est dans la deuxième étape : l’héritage)
De plus, je dois dire que j’ai été un peu gêné dans la lecture de cet article par l’absence de figure, sur des choses qui sont certainement simples et pourtant pas toujours clairement établies. Prenons un exemple, celui du canton en analogique. Tout le monde a sa propre définition mais dans la réalité, comment le reconstituer sur le réseau ? Doit-il avoir une zone de pleine voie (ou pleine vitesse) et une zone d’arrêt, ou bien une zone de pleine vitesse, une zone de ralentissement et une zone d’arrêt. Si la voie est à double sens, combien de zones différentes à prévoir, quelle longueur optimale. A partir de là, on peut alors mieux imaginer en quoi consisterait les méthodes liberer() ou occuper().
Je ne sais pas si j’ai été très clair, mais pour moi, le software est fortement lié au hardware, (même si on cherche à obtenir un modèle universel), et la question que je me pose est : Est-ce que ce que tu développes peut fonctionner pour une solution matérielle un peu différente ? Je pense que oui, mais avec un exemple concret, j’en serais sûr.
-
Bonjour
Quelques éléments de réponse :
L’aubinage est la fermeture automatique d’un signal lors de son franchissement par un train ( le nom vient de l’invention, par Mr Aubine, de la pédale mécanique qui fermait les signaux mécaniques au passage d’un train, et le nom est resté pour les signaux lumineux ).
Un "canton" est constitué de une ou plusieurs zones et peut comporter une ou plusieurs aiguilles. Ici on travaille au niveau des zones. Il n’y a pas formellement de "cantons" car ceux ci peuvent être absents et/ou éventuellement volatiles.
Dans la réalité il n’y a des "cantons" que quand il y a du cantonnement c’est essentiellement avec des blocks (BMU, BAL, BAPR, …). Certaines parties des réseaux ne sont pas cantonnées : garages, dépots, petites lignes, petites gares, …
Chaque utilisateur découpe ses "cantons" en zones comme il veut, ici les méthodes liberer() et occuper() font référence à des zones (pas des cantons). L’arrêt des trains sera géré par les signaux (à venir). Ceci pour pouvoir gérer toutes les parties d’un réseau.
Le gestionnaire se veut au maximum indépendant du hardware, et beaucoup de solutions matérielles peuvent être prises en compte. Ce qui est proposé ici, n’est que le noyau d’un gestionnaire de réseau. C’est à l’utilisateur d’écrire du code pour interfacer à son hardware.
Des exemples concrèts sont prévus.
-
-
Un gestionnaire en C++ pour votre réseau 10 mars 2016 16:45, par Christian
Bonjour Pierre,
Merci pour cette réponse rapide, notamment sur l’origine du mot aubinage.
Pour les cantons de ton réseau, quel découpage en zones (pleine voie, arrêt, etc) t’a paru meilleur et pour quelles raisons ?
Si liberer() et occuper() font référence à des zones, que signifie ce terme (par rapport à cantons que je visualise mieux). Quelle différence ?
Tu dis que c’est à l’utilisateur d’écrire son code en fonction de son hardware, n’y a-t-il pas d’incompatibilité, c’est-à-dire des cas de morphologie de réseau qui ne serait pas pris en compte par ce que tu as développé ?
J’attends avec impatience des cas concrets pour mieux me rendre compte, mais je vois déjà la puissance d’une telle approche...
-
Sur mon réseau les "cantons" de pleine voie n’ont qu’une zone, il n’y a pas de zone d’arrêt ni de ralentissement. L’arrêt des trains fait par une détection ponctuelle (cellules photo pour l’instant), le ralentissement se fait dès qu’un signal (avertissement ou ralentissement) fermé est franchi en jouant sur la PWM en analogique ou les crans DCC, les machines sont étalonnées (vitesse versus PWM ou cran) les "cantons" sont mesurés. C’est le gestionnaire qui fait tout cela.
Certains "cantons", ceux qui comportent des aiguilles (j’en ai beaucoup), ont plusieurs zones (mais ce ne sont pas des zones d’arrêt ni de ralentissement), c’est nécessaire pour assurer la sécurité comme dans un vrai poste d’aiguillage.
Une zone sert à gérer la présence d’un train sur une (éventuellement petite) portion de voie. Le gestionnaire fonctionne essentiellement avec l’occupation et la libération des zones (rétrosignalisation).
Les "cantons" ne servent qu’au contrôle de l’espacement des trains.
L’intérêt de la programmation objet est de pouvoir isoler des concepts ne dépendant pas du matériel. Les classes que je fourni sont complètement indépendantes du matériel et du réseau. C’est des briques de base dont le fonctionnement est a peu près le même pour tous les réseaux.
-
-
Un gestionnaire en C++ pour votre réseau 10 mars 2016 17:48, par Christian
Un grand merci pour toutes ces précisions qui me permettent de mieux comprendre.
Je suis d’autant plus intéressé que mon réseau aussi peut être divisé en cantons courts sans zone d’arrêt car je ne pense pas avoir la place pour des cantons longs avec pleine voie et arrêt. J’attends donc la suite avec impatience mais ne te presse pas, je dois déjà bien digérer cela.
Amicalement.
Christian
-
Un gestionnaire en C++ pour votre réseau 14 mars 2016 09:21, par Dominique
J’ai ajouté l’exemple du Locodrome, ici, dans le Forum
-
Un gestionnaire en C++ pour votre réseau 6 avril 2016 23:05, par Dominique
Suite à un remaniement du fil du Forum sur la modélisation, le lien ci-dessus était devenu faux. Maintenant c’est corrigé, il est bon :)
Voir en ligne : http://forum.locoduino.org/index.ph...
-
Un gestionnaire en C++ pour votre réseau 4 janvier 2017 11:10, par Christian
Bonjour Pierre,
N’étant pas moi-même très habitué à la POO, voici quelques questions que je me pose :
- Pourquoi deux méthodes pour savoir si une aiguille est en position directe ou déviée ? Cela me parait redondant ; une seule méthode positionAiguille() renverrait TRUE si directe et FALSE si déviée, non ?
- Par contre, je suis d’accord qu’il faut 2 méthodes directer() et devier() pour manœuvrer l’aiguille, alors pourquoi la méthode manœuvrer() ? Qu’apporte-t-elle de plus ?
- Je me pose les mêmes questions pour la class Zones.
- Enfin, n’y a-t-il pas redondance entre occuper() et actions() ainsi que liberer() et desactions() ? Je ne vois pas l’intérêt d’autant de méthodes pour faire des choses similaires et je suis un peu perdu...
Point positif : je commence à entrevoir la puissance de tout cela sauf que j’aurais envie de simplifier. Mais est-ce possible ?
-
Bonjour
Quelques éléments de réponse :
- pour les méthodes directe() et deviee() c’est juste pour la facilité d’utilisation, avec une méthode positionAiguille() il faut réfléchir sur le résultat attendu (true ou false) et se souvenir du "codage"
- pour les méthodes directer() et devier() on aurait pu avoir une seule méthode avec un paramètre booléen
- pour la méthode manoeuvrer() cela évite la duplication de code elle est appelée dans directer() et devier() et puis elle isole bien la commande physique de l’aiguille
- pour la classe zone c’est en gros les mêmes réponses
- pour la redondance entre les méthodes occuper() et actions() c’est plus subtil c’est des problèmes de POO, la méthode occuper() traite ce qui est général à toutes les zones, la méthode actions() traite ce qui est particulier à une zone particulière, elle doit être redéfinie (par héritage) dans les zones particulières. De même pour liberer() et desactions().
- pour la simplification oui et non, sur la méthodes directe(), deviee() … pourquoi pas, sur les méthodes occuper() , actions(), … c’est plus difficile
Concrètement ce n’est qu’une écriture possible, beaucoup d’autres sont possibles comme pour beaucoup de programmes.
Pierre
-
Merci Pierre pour tes réponses.
Peut-être qu’il va falloir que je m’imprègne encore plus de ce que font les méthodes. Une chose est sûre, tes articles ont éveillé ma curiosité. On a bien compris un sujet quand on est capable de l’adapter à ses propres besoins ; cela me donne donc envie de modéliser mon petit réseau. Si j’arrive à produire un TCO virtuel comme celui que tu nous a fourni pour le locodrome, mais adapté à mon réseau, c’est que j’aurais bien assimilé ce que tu enseignes. J’ai du boulot pour rattraper mon retard.
-
Un gestionnaire en C++ pour votre réseau 4 janvier 2017 22:02, par Dominique
Moi, j’ai modélisé mon réseau avec le système de Pierre dès l’article 1 ou 2, bien avant le TCO en Processing.
J’ai d’abord créé les objets zones et aiguilles comme je l’ai expliqué dans le Forum (fil du système de Pierre), puis j’ai réalisé un premier écran graphique pour le représenter dynamiquement et, enfin, je les ai raccordé au réseau réel par les messages CAN.
J’utilise effectivement les méthodes que tu mentionnes et c’est important d’avoir des noms en français conformes à ceux de la SNCF : j’ai appris et compris plein de choses de cette façon et c’est bien plus pédagogique.
Je vais décrire pas à pas la mise en œuvre du gestionnaire de Pierre dans mon réseau avec l’interface CAN qui n’est pas très éloignée de l’interface série.
Je vais partir cette fois-ci de la version 4.Je crois qu’on peut voir le gestionnaire de Pierre comme une énorme boîte à outils qui couvre tous les besoins d’un réseau complexe. On peut s’en servir de différentes manières comme dans l’exemple du Locodrome. Mais le mieux est de multiplier les exemples.
-
Un gestionnaire en C++ pour votre réseau (1) 19 février 2020 10:32, par Roberto Zuliani
Bonjour
très intéressant ! Si je comprends bien, une telle structure logicielle vous permettrait de gérer les trains automatiquement et simultanément manuellement en toute sécurité.-
Bonjour,
Vous avez raison, et comme je l’ai écrit plus haut, c’est une boite à outils qui permet de faire tout ce que l’on veut à condition de bien l’étudier et d’avancer pas à pas. Nous avons fait une démonstration assez simple à Orléans en 2018 (le Locoduinodrome) et, chez moi cela progresse bien avec un réseau bien plus complexe et des échanges de messages Can entre les modules (gestionnaire avec écran graphique sur Arduino Due, commandes d’aiguilles sur Mega, TCO physique sur Mega et commandes de traction sur Mega aussi).
-
-
Un gestionnaire en C++ pour votre réseau (1) 20 décembre 2022 13:10, par bernard semhoun
Bonjour plus je zappe divers page plus je me rend compte que le site est biens achalander
-
Un gestionnaire en C++ pour votre réseau (1) 20 décembre 2022 17:02, par msport
Merci du compliment.
-
Un gestionnaire en C++ pour votre réseau (1) 18 avril 2023 22:48, par Dominique
Bonjour,
Je découvre ce sujet un peu tard par rapport à sa parution, mais je me pose une question concernant l’état de l’aiguille.
Il n’y a ici que deux états, direct ou dévié. Mais qu’en est-il si l’état est indéterminé, ce qui peut arriver avec une aiguille mal positionnée ou un défaut de rétro-signalisation de la position de l’aiguille ?
Cordialement,
Dominique-
Bonjour
Si on veut gérer un état indéterminé pour les aiguilles, il suffit de remplacer le booléen d’état par un entier en utilisant trois valeurs (directe, déviée, entrebaillée), adapter toutes les utilisations du booléen et adapter le dessin de l’aiguille (deux voies noires par exemple pour indéterminé).
Cordialement
Pierre
-