LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: Dominique le janvier 03, 2024, 02:55:42 pm
-
Nous sommes quelques uns à nous intéresser à la réalisation d'un gestionnaire de réseau qui soit capable de détecter les positions des trains qui circulent sur un réseau et qui soit capable de les commander pour respecter les règles de circulation ferroviaire :
- un seul train par canton,
- des signaux positionnés selon ces règles (sémaphores, carrés, avec ralentissement, etc..),
- des commandes des trains pour le respect des ralentissements et arrêts selon la signalisation,
- des détecteurs de présence et/ou d'identification(RFID, RailCom) des trains par canton, zone, aiguille, etc.
- une représentation du réseau sous forme de TCO ou écran graphique,
- une centrale DCC pour commander les trains aussi bien automatiquement (par le gestionnaire) que manuellement (par des manettes, smartphone ou TCO),
- des possibilités de réaliser des itinéraires avec commande des appareils de voie, aussi bien manuels qu'automatiques.
- des animations contextuelles (sons, lumières, etc..)
Le sujet a été très bien expliqué par Pierre59 dans sa série d'articles : Un gestionnaire en C++ pour votre réseau.
https://www.locoduino.org/spip.php?article154 (https://www.locoduino.org/spip.php?article154)
https://www.locoduino.org/spip.php?article167 (https://www.locoduino.org/spip.php?article167)
https://www.locoduino.org/spip.php?article172 (https://www.locoduino.org/spip.php?article172)
https://www.locoduino.org/spip.php?article184 (https://www.locoduino.org/spip.php?article184)
Il offre une boite à outils très complète pour réaliser un gestionnaire, que j'ai eu le plaisir de mettre en oeuvre sur mon réseau.
DDEF a également exposé ses principes dans la série : SGDD : Système de Gestion DD
https://www.locoduino.org/spip.php?article132 (https://www.locoduino.org/spip.php?article132)
https://www.locoduino.org/spip.php?article134 (https://www.locoduino.org/spip.php?article134)
https://www.locoduino.org/spip.php?article151 (https://www.locoduino.org/spip.php?article151)
Des réalisations partielles ont été décrites comme : Gestion d’une gare cachée
https://www.locoduino.org/spip.php?article155 (https://www.locoduino.org/spip.php?article155)
https://www.locoduino.org/spip.php?article156 (https://www.locoduino.org/spip.php?article156)
https://www.locoduino.org/spip.php?article157 (https://www.locoduino.org/spip.php?article157)
Sans oublier les solutions commerciales ou de l'open source comme JMRI, RocRail, iTrain et autres RRTC qui tournent sur PC/MAC et nécessitent des interfaces avec la centrale DCC et la rétrosignatisation, entraînant souvent des coûts importants.
Depuis pas mal de temps, Locoduino recommande le bus CAN pour les communications. entre les diverses entités du réseau. LaBox est l'exemple de centrale DCC pilotable par Bus CAN et en même temps par logiciel JMRI, RocRail via l'USB.
Le but de ce sujet est de recueillir vos souhaits et préférences dans le but de concevoir un système de gestion de réseau architecturé autour d'un bus CAN.
Suite à l'expression des divers desiderata, nous établieront un cahier des charges puis démarrera une réalisation.
Le tracé du réseau à équiper se trouve en page 11 :
https://forum.locoduino.org/index.php?topic=1645.msg17785#msg17785 (https://forum.locoduino.org/index.php?topic=1645.msg17785#msg17785)
A vous maintenant.
Cordialement
Dominique
-
Pour démarrer, j'appuie la proposition de BobyAndCo qui propose de commencer par résoudre les points les plus généraux pour s’attaquer ensuite au particulier.
Parmi les principaux points auxquels il faut trouver des réponses :
La Topographie : Décrire précisément toutes les liaisons des cantons entre eux, préciser si ces liaisons sont directes, par l’intermédiaires d’aiguilles (droites ou déviées), de TJD etc… C’est je crois le travail le plus fastidieux et aussi, c’est assez compliqué à modifier quand on fait des modifications sur le réseau. Il n’y a pas qu’un seul procédé pour ce faire. Soit on propose les boutons et les switches sur des satellites, soit un outil graphique. Pourquoi pas ? Si celui-ci peut générer un document formaté ou toutes les liaisons sont décrites et qui pourraient être importé tel quel dans le gestionnaire ; fichier json par exemple.
La sécurité : Lorsque l’on cherche à faire avancer un convoi dans un sens donné, on recherche si le canton suivant, en fonction de la position d’aiguille éventuelle est libre ou occupé. Si libre, la loco peut avancer, doit s'arrêter ou ralentir. Si elle s’engage sur le canton C+1, on cherchera maintenant à connaitre l’état d’occupation de C+2. Si occupé, on donne l’ordre à la loco de ralentir au franchissement du premier capteur et de stopper au franchissement du second capteur.
La gestion d’itinéraire. On a un point A de départ et un point B d’arrivée. On a aussi des options comme je l’ai déjà dit : Itinéraire le plus court en distance, itinéraire où aucun canton n’est occupé au moment du lancement, itinéraire qui se modifie de lui-même en cas de modifications. Mais la recherche automatique d'itinéraire n'est pas souvent nécessaire sauf dans les réseaux compliqués cet les cas d'école. Bien souvent un petit jeu d'itinéraires prévus à l'avance suffira. Il sera capable de tester la non-occupation des éléments de voie à emprunter, positionner les aiguilles nécessaires et libérer tout ou partie du tracé au fur et à mesure de l'avancement du train.
L'architecture matérielle : Il est trop tôt pour la décrire et la limiter tant que les principes ci-dessus ne sont pas clairs.
Mais il apparait tout de même dans cette réflexion qu'il s'agit d'un gestionnaire qui diffère des logiciels existants comme JMRI, RocRail, iTrain ou autres RRTC qui existent déjà et dont la mise en oeuvre et l'utilisation font l'objet d'autres sujets sur ce forum.
Comme dans mon propre réseau, une carte Arduino un peu puissante et connectée au bus CAN peut faire office de gestionnaire avec une interface homme-machine qui peut prendre diverses formes : (écran graphique tactile associé, PC/Mac connecté avec application ad hoc, etc..
Tout autour du bus Can on trouvera des détecteurs et des actionneurs comme la carte Satellite V1 proposée il y a quelques lustres ou les cartes Satellite de BobyAndCo de type "Canton" qui seront décrites dans de prochains articles.
-
Bonjour
Pour le gestionnaire je pense qu'il ne faut pas le limiter au seul bus CAN, mais l'ouvrir à tous les bus possibles : CAN, WIFi, Ethernet, BlueTooth, Série, ... Avec une messagerie qui fonctionne de la même façon sur tous les bus (même API).
On parle toujours de "canton", mais faudrait bien se mettre d'accord sur ce que c'est. Pour moi ce qui est important c'est la zone : une portion de voie avec ou sans appareil de voie sur laquelle il y a une détection de présence de matériel roulant. Un canton c'est une ou plusieurs zones consécutives (pas forcément toujours les mêmes) qui se trouvent entre deux signaux pouvant présenter le sémaphore (sémaphores, carrés, ...). Les cantons servent à l'espacement des trains avec un mécanisme de cantonnement (BAL, BAPR, BMU, ...). Sur un réseau il y a des parties qui ne sont pas cantonnées : dépôts, partie marchandises, petites lignes, ... donc sans cantons mais avec éventuellement des zones.
Les zones sont essentielles dans le gestionnaire, ce sont leur occupations/libérations qui rythment son fonctionnement.
Fondamentalement un gestionnaire peut être centralisé ou repartit (dans les satellites par exemple). Un gestionnaire repartit est beaucoup plus difficile à écrire et à mettre au point qu'un gestionnaire centralisé (j'ai longuement travaillé dans des équipes CNRS de programmation répartie). Le langage à utiliser reste ouvert : Java ou C++ il faudra en discuter.
J'en reste la pour l'instant, dites ce que vous en pensez.
Pierre
-
Bonjour à tous,
Le système SGDD était un tout premier essai, vraiment mes tout débuts.
J'ai, depuis développé des programmes en Processing, nettement plus évolués.
Ma dernière contribution pour Locoduino était ce gestionnaire qui sert d'exemple de réalisation.
Il n'est pas parfait, loin de là, mais le but est de donner une idée d'un gestionnaire maison, sur mesure.
https://www.locoduino.org/IMG/zip/train_tco_v1_9_1.zip (https://www.locoduino.org/IMG/zip/train_tco_v1_9_1.zip)
Mode d'emploi :
Après avoir installé la dernière version de Processing, vous pouvez extraire le fichier zip.
Vous lancez n'importe quel programme et quand la fenêtre s'ouvre, vous selectionnez "circuit d'essai.tsv" puis "ouvrir".
S'affiche alors un circuit biscornu qui regroupe quasi tous les pièges dans lesquels on peut tomber sur son réseau.
Pour lancer un train, on doit créer un itinéraire :
Vous sélectionnez (souris vers le bas de l'écran) la "fourche" (icone de l'itinéraire point à point) et vous cliquez avec la flèche verte un point de départ (sur n'importe quel signal), puis un point d'arrivée (là aussi sur un signal).
Le premier itinéraire possible s'affiche en orange.
En cliquant GAUCHE, un autre itinéraire s'affiche, toujours avec les mêmes points de départ et d'arrivée.
En cliquant GAUCHE, on voit donc défiler, à chaque fois un nouvel itinéraire possible, jusqu'à "plus d'itinéraire" (retour à l'afficha des rails en gris)
Si vous recliquez GAUCHE, vous reprenez le cycle.
En cliquant DROIT, vous choisissez cet itinéraire.
Un train apparait au début de l'itinéraire et la souris devient, cette fois, une horloge.
Apparait aussi une manette et, en faisant glisser le curseur, vous décidez du temps d'arrêt au bout de cet itinéraire.
Un clic DROIT met fin aux choix.
Maintenant, en bougeant le curseur, vous faites partir le train qui va jusqu'au bout de l'itinéraire et s'arrête.
Remarque : vous pouvez "chaîner" les itinéraires et décider, pour chaque fin d'itinéraire, du temps d'arrêt (ou non).
Si vous voulez plusieurs trains, il suffit de les programmer à partir d'une zone vide. Il se crée un nouveau train.
Si vous voulez un circuit bouclé, choisissez l'icone en forme d'anneau. Vous chaînez les itinéraires jusqu'à revenir au point de départ.
Bon, je m'arrête là pour aujourd'hui. J'ai présenté UNE possibilité. Il y aura, bien sûr, d'autres propositions.
Pour l'instant, ce ne sont que des trains virtuels. Il y a encore du boulot avant que ça fasse bouger des trains réels. 8)
Denis
-
Bonsoir à tous,
@Dominique. Excellente initiative. Je constate avec satisfaction que les réactions et propositions n’ont pas tardées.
Alors quels seraient pour ma part mes souhaits prioritaires ?
Eh bien, avant tout que mes trains puissent rouler en toute sécurité, c’est la base. Je voudrais donc qu’un train qui entre dans un canton dont le canton +1 est occupé soit automatiquement ralenti puis stoppé.
De plus, J’aimerais une simplification maximale du paramétrage et de la description des liaisons entre zones ou cantons. Par exemple, lorsque trois extrémités de cantons convergent en un seul point, l'application devrait automatiquement déduire la présence d'une aiguille et créer l'objet logiciel correspondant. Il est essentiel que toute modification physique du réseau ne devienne pas un casse-tête lors de la mise à jour du gestionnaire. J’aimerais me dispenser de passer de longs moments à saisir les identifiants des cantons, des aiguilles ou des capteurs.
Je remercie Denis pour sa présentation très détaillé mais c’est justement cela que je souhaite éviter, glisser-déposer, clic gauche, clic droit et encore clic droit !!!
Et comme la signalisation ferroviaire française est complexe et que je n’y comprends pas grand-chose, je souhaiterais que le logiciel indique les cibles nécessaires sur le canton et que je n’ai pas à m’en occuper car je vais y passer beaucoup de temps et probablement me tromper.
Je voudrais aussi bien sûr que le gestionnaire sélectionne lui-même les signaux à allumer sans que j’ai besoin de lui préciser au préalable.
En résumé, j'aspire à ce que les trois aspects évoqués par Dominique - topographie, sécurité, et gestion d'itinéraire - deviennent pratiquement transparents pour l'utilisateur.
Enfin, pour faire court, je suis d’accord avec Pierre sur l’ensemble de ce qu’il aborde. Et je suis particulièrement d’accord qu’il vaudrait mieux un gestionnaire répartit qu’un gestionnaire centralisé. Chaque satellite assurant toutes les fonctions d’un gestionnaire mais de manière locale en se « nourrissant » des informations échangées avec tous les autres satellites sur le bus.
Cette architecture offre en premier lieu l’avantage d’être beaucoup moins sollicitée qu’un gestionnaire central. L’évolutivité peut se faire plus facilement sans perturber l'ensemble du réseau.
Mais quand j’ai dit tout cela, je me dis que ce type de gestionnaire existe déjà avec les satellites autonomes.
(https://www.locoduino.org/local/cache-vignettes/L610xH386/_dsc1036-386f0.jpg?1700554652)
Alors je me dis qu’il serait nécessaire de publier au moins les trois premiers articles sur les satellites autonomes pour que cela puisse aussi servir de base de réflexion pour la suite.
Bien amicalement
Christophe
-
Pierre a écrit qu’ « Un gestionnaire repartit est beaucoup plus difficile à écrire et à mettre au point qu'un gestionnaire centralisé .
Par contre des éléments répartis par cantons comme le suggère Christophe pourraient-ils être réunis dans un gestionnaire centralisé ? J’imagine que les communications entre objets canton seraient équivalentes aux échanges via Can.
Cela me faciliterait la tâche vu que mon gestionnaire est actuellement centralisé.
Dominique
-
des éléments répartis par cantons comme le suggère Christophe pourraient-ils être réunis dans un gestionnaire centralisé ?
Oui, en théorie, chaque satellite autonome étant en lui-même un gestionnaire, le code peut assez facilement s’adapter ! Mais l'un des intérêts avec une solution en répartit est que la charge de calcul est divisée entre les différents microcontrôleurs des satellites.
Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !
-
Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !
C’est étonnant car j’utilise un Due avec un seul cœur ARM Cortex M3 a 84mhz, il affiche le réseau à jour sur un écran 5 pouces en même temps et il ne semble pas perdre de messages !
-
Ce que vient de dire Christophe m'inquiète aussi quant à la capacité de calcul des ESP32.
Pour moi, ce que fait sa "carte de canton" est très simple : enregistrer qui est le canton suivant dans chaque sens en fonction de la position des aiguilles en utilisant le bus CAN.
J'ai peine à croire que ça suffise à saturer les 2 cœurs d'un ESP32.
Mais si on veut se passer d'un ordinateur, il faut, au moins, un TCO physique avec des LED et des boutons. Donc une carte LED et une carte boutons reliées au bus CAN.
Je pense qu'on devrait parler de cartes de zones et pas de carte de canton. C’est-à-dire des cartes qui ne gèrent pas les signaux. Et avoir des cartes spécifiques pour les signaux.
Il est d'ailleurs intéressant de constater qu'il faut exactement le même nombre de boutons sur le TCO que ceux qui se trouvent sur les cartes de zone : un bouton par sens et par zone.
Au point de se demander si on ne pourrait pas utiliser les boutons du TCO pour décrire le réseau.
Je m'explique :
On définit un identifiant pour chaque carte de zone.
Chaque bouton du TCO génère un identifiant, le même que celui de la zone qu'il gère.
A un endroit du TCO, on a un switch (un octet)
A un autre endroit, on a un bouton "programmation"
On appuie sur le bouton de programmation sur le TCO : on entre dans le mode "programmation"
On affiche sur le switch la position des aiguilles entre les 2 cartes de zone à programmer.
On appuie sur le bouton de zone départ sur le TCO : c'est enregistré.
On appuie sur le bouton de la zone arrivée sur le TCO : c'est enregistré.
On appuie sur le bouton de programmation, ce qui envoie dans le bus CAN le message qui va bien vers les 2 cartes de zone.
Dit autrement, je centralise les boutons qui sont sur la carte de zone sur le TCO.
L'avantage, c'est qu'on n'est pas obligé d'avoir accès aux cartes de zone qui peuvent alors être sous le réseau.
Cartes qui peuvent alors être plus petites, débarrassées des boutons et de la signalisation.
-
Revenons d’abord aux préoccupations principales :
- la topographie : comment obtenir le graphe complet du réseau, par exemple pour l’afficher sur un TCO ?
- comment assurer la sécurité : le suivi des trains, la mise à jour du graphe, de la signalisation et l’application a la conduite des trains.
-les itinéraires : on y reviendra plus tard, l’algorithme de choix étant une option.
-
Bonjour à tous,
Je viens de lire avec grand intérêt ce lancement de projet, d'autant plus grand que j'ai en projet un nouveau réseau.
Il y a eu beaucoup de remarques pertinentes et mes connaissances "limitées" dans ce domaine ne me permettent pas de commenter.
Le seul point pour lequel j'interviens est qu'on a parlé de PC et Mac, mais il ne faut pas oublier qu'il y a PC-Windows et PC-Linux (qui est mon cas).
Je pense que s'il y a une interface sur ordinateur, elle doit être "universelle", comme un navigateur web.
-
Revenons d’abord aux préoccupations principales :
- la topographie : comment obtenir le graphe complet du réseau, par exemple pour l’afficher sur un TCO ?
Le graphe du réseau (avec beaucoup d'annotations) peut peut être suffire au gestionnaire, mais ne permet pas d'afficher correctement un TCO (ils faut d'autres informations). Ce ne sont pas les mêmes informations qui sont nécessaires dans les deux cas.
Je ne vois que que deux possibilités pour obtenir le graphe, un éditeur graphique ou un codage en mode texte avec un éditeur de texte.
Un éditeur graphique c'est un très gros programme. J'ai fais pas mal d'essais pour un éditeur graphique de TCO, il reste encore pas mal de petits bugs; voir aussi les travaux de Denis.
Un codage en mode texte est peu être plus abordable (json,XML, ...) mais faut pouvoir coder toutes les informations nécessaires.
Il faut remarquer que les classes proposées dans la série d'articles constituent en fait "un" codage du graphe d'un réseau.
- comment assurer la sécurité : le suivi des trains, la mise à jour du graphe, de la signalisation et l’application a la conduite des trains.
La sécurité se fait essentiellement avec les enclenchements (voir l'article 3). La SNCF assure cette sécurité surtout avec des relais (peut être aussi avec des programmes à logique majoritaire), mais il reste encore pas mal d'enclenchements mécaniques. Les relais changent leurs états en fonction des infos d'occupation des zones, des appuis sur des pédales par des essieux et des demandes d'itinéraires.
Clairement cette sécurité sur nos réseaux on la fait avec des programmes qui ont comme données variables des occupations/libérations de zones, des détections de train ponctuelles et demandes de trajets ou itinéraires de trains.
-les itinéraires : on y reviendra plus tard, l’algorithme de choix étant une option.
Je suis tout à fait d'accord avec toi.
Pierre
-
Le seul point pour lequel j'interviens est qu'on a parlé de PC et Mac, mais il ne faut pas oublier qu'il y a PC-Windows et PC-Linux (qui est mon cas).
Je pense que s'il y a une interface sur ordinateur, elle doit être "universelle", comme un navigateur web.
Ty as tout à fait raison, il faut être compatible à tous les OS.
Mais pour cela il faut savoir ce que l’on veut faire avec un PC :
- y faire tourner le gestionnaire ? Ça existe déjà avec JMRI et d’autres compatibles linux. Ce n’est pas notre objectif.
- développer une interface avec le gestionnaire : oui bien sûr mais il faut décrire ce qu’elle doit faire.
-
Ce que vient de dire Christophe m'inquiète aussi quant à la capacité de calcul des ESP32.
Pour moi, ce que fait sa "carte de canton" est très simple : enregistrer qui est le canton suivant dans chaque sens en fonction de la position des aiguilles en utilisant le bus CAN.
J'ai peine à croire que ça suffise à saturer les 2 cœurs d'un ESP32.
Mais non mon cher Denis, le satellite ne fait pas que cela. Par exemple, il émet sur le bus toutes les 100ms un message CAN sur 8 octets dans lequel on trouve l’adresse de la loco (s’il y en a une), et en fonction de la position de ses différentes aiguilles, quel est son C+1 et son C+2 ainsi que son C-1 et son C-2.
Mais surtout, il reçoit de tous les autres satellites ce même message, je rappelle toutes les 100 ms, prend en compte les messages qui le concerne et adapte son comportement en conséquence : Arrêt de sa propre loco, adaptation de signalisation et quelques autres opérations.
Il doit également s’occuper toutes les 100ms de lire l’état de ses différents capteurs et aussi assurer la lecture de Railcom.
Ici un apperçu de la principale méthode qui s’occupe de toutes ces mises à jour : https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/src/GestionReseau.cpp
Crois moi, répété toutes les 100ms, c'est déjà pas mal.
-
Le graphe du réseau (avec beaucoup d'annotations) peut peut être suffire au gestionnaire, mais ne permet pas d'afficher correctement un TCO (ils faut d'autres informations). Ce ne sont pas les mêmes informations qui sont nécessaires dans les deux cas.
Selon moi, Pierre soulève judicieusement la distinction qu’il faut faire entre gestionnaire et TCO (d’une manière générale) ou tout ce qui permet d’agir sur l’état du réseau ou de visualiser l'état du réseau.
Même si souvent ces deux fonctions sont rassemblées en un seul appareil (logiciel), ce sont pourtant deux choses à bien distinguer au risque de tout mélanger et de n’arriver à rien.
Au risque de se répéter, le gestionnaire doit en priorité assurer la sécurité et afficher la bonne signalisation. Qu’on lui demande de faire de la gestion d’itinéraires n’est finalement qu’une extension des précédentes fonctions.
De fait, le gestionnaire au sens strict n’a pas d’interface graphique, il n’en a pas besoin. Il fonctionne essentiellement en boucle et agit en fonction des informations qu'il reçoit.
C’est pour cela que l’on peut imaginer toutes sortes de périphériques, logiciels (HTML, Processing…) ou simplement matériels, boutons poussoirs, manettes de gaz etc…
Ces périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.
De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.
Ainsi, le gestionnaire, développé pour se concentrer sur ses fonctions de base est indépendant de tout autres systèmes de commande.
J’espère que j’explique bien ce point et que ce que je dis est partagé.
Christophe
-
Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !
C’est étonnant car j’utilise un Due avec un seul cœur ARM Cortex M3 a 84mhz, il affiche le réseau à jour sur un écran 5 pouces en même temps et il ne semble pas perdre de messages !
@Dominique. Ce n'est pas la messagerie CAN qui est à taquet. Sur les satellites autonomes, pour 50 satellites sur le bus, à raison d'un message par satellite toutes les 100 ms, à 1Mbps et sur une longueur de bus de 30 mètres, la charge du bus CAN est de 7,15% de sa capacité théorique !!!
Dans la réponse que j'ai faite à Denis, tu constateras que je demande au microcontrolleur de faire beaucoup de choses en 100 ms et que toute la puissance de l'ESP32 n'est pas superflue.
Tu me disais sur ton DUE perdre, non pas des messages mais des trains !!! N'est-ce pas là le problème ?
-
Tu me disais sur ton DUE perdre, non pas des messages mais des trains !!! N'est-ce pas là le problème ?
Non ce n’est pas une question de performance mais d’analyse et de codage : des cas d’erreur mal traités.
C’est pour ça que cette discussion m’intéresse ;D
-
Ces périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.
De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.
Si le gestionnaire assure la sécurité, est-ce qu'il ne doit pas filtrer toute commande manuelle, par exemple interdire d'accélérer sur un canton au ralenti, ou interdire d'actionner une aiguille occupée par un train ?
-
Ces périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.
De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.
Si le gestionnaire assure la sécurité, est-ce qu'il ne doit pas filtrer toute commande manuelle, par exemple interdire d'accélérer sur un canton au ralenti, ou interdire d'actionner une aiguille occupée par un train ?
Oui effectivement dans le cas d'un gestionnaire centralisé, c'est la solution "économique". J'ai un peu de mal à me détacher du satellite autonome car je baigne complètement dedans. Pour la commande d'aiguillage sur le satellite autonome, celle-ci est adressée à un satellite X qui connait la présence ou non d'un convoi mais qui devra aussi s'assurer que le convoi n'est pas à cheval sur deux cantons.
Pour la traction, la commande doit en effet "transiter" par le gestionnaire qui la laisse passer, la bloque ou la modifie (limitation de vitesse par exemple) selon la topologie du réseau à l'instant.
Bien vu et merci !
Christophe
-
@ Christophe
Si tu sais, à tout moment, pour un canton C donné, quel est son C+1 en fonction de la position des aiguilles, tu peux gérer une première information : pas de C+1 => afficher le C (Carré) du canton C.
Si C+1 existe, tu regardes si C+1 est occupé.
Si oui, tu affiche S (Sémaphore), sinon tu ne changes pas le signal.
La question, après, consiste à connaitre quel est le signal affiché au bout de C+1. Il y a plusieurs cas à gérer.
Si le signal de C+1 est S ou C, afficher A (Avertissement) pour le cas le plus simple.
Evidemment, pareil côté C-1. L'identité d'un train n'a aucune incidence sur la signalisation… dans un premier temps.
Connaître C+2 et C-2 est moins utile, bien que je m'en serve dans mon gestionnaire :
J'estime, en ligne droite et avec une bonne visibilité, que le conducteur voyant un signal A sait qu'il va bientôt voir S et devoir s'arrêter et que, dans ces conditions, il ne va pas accélérer à fond pour freiner juste avant le signal A. Et qu'il va maintenir sa vitesse actuelle en espérant que le A devienne VL (Voie Libre) et que, là, il a presque 2 cantons libres devant lui.
Si on n'est pas en ligne droite, si le canton est court, etc… il y a d'autres cas à gérer.
A mon avis, dans un premier temps, sur un circuit sans piège, gérer C+1, C-1 et C, S, A, VL est plausible. Par contre, il est nécessaire qu'un canton connaisse, via le CAN, le signal de C+1 et C-1.
De même, il doit faire respecter les signaux de son canton par "son" train, une fois qu'il a fait les calculs.
Denis
-
On voit que Denis a décortiqué des tas de choses.
J’en déduit qu’il y a, dans un gestionnaire sérieux, toute une suites de traitements à faire les uns avant ou après les autres et dont l’ordre est très important ,
-1- détections des occupations et libérations zone par zone comme le dit Pierre et mise à jour des signaux
-2- suivi des trains pour identifier a tout moment ceux qui sont détectés, afin d’être capable de leur appliquer :
-3- les consignes de conduite locales : ralentissement (15, 30, 60, 90), arrêt et redémarrage
Sans empêcher toutes sortes de cas particuliers : ralentissement dans les virages et aiguilles déviées par exemple, coup de klaxon avant sortie de tunnel et passages à niveau, ..et un mélange de conduite manuelle et automatique.
La difficulté est l’ordre dans lequel faire ces traitements. Par exemple des qu’un train entre dans un canton C le C-1 est fermé et il ne faut arrêter le train qui y est encore (j’ai eu ce cas avec le Locoduinodrome).
Donc il faut ajouter et manipuler des variables d’état pour conditionner les comportements.
La boîte à outils de Pierre (Un gestionnaire en C++) est très intéressante mais il faut ajouter les traitements ci-dessus.
C’est ça qui est amusant 🤩 et ça plante parfois.
J’espère trouver la potion magique dans ce sujet !
-
Selon moi, Pierre soulève judicieusement la distinction qu’il faut faire entre gestionnaire et TCO (d’une manière générale) ou tout ce qui permet d’agir sur l’état du réseau ou de visualiser l'état du réseau.
Même si souvent ces deux fonctions sont rassemblées en un seul appareil (logiciel), ce sont pourtant deux choses à bien distinguer au risque de tout mélanger et de n’arriver à rien.
Au risque de se répéter, le gestionnaire doit en priorité assurer la sécurité et afficher la bonne signalisation. Qu’on lui demande de faire de la gestion d’itinéraires n’est finalement qu’une extension des précédentes fonctions.
De fait, le gestionnaire au sens strict n’a pas d’interface graphique, il n’en a pas besoin. Il fonctionne essentiellement en boucle et agit en fonction des informations qu'il reçoit.
@ Christophe
Très bonne analyse, je suis tout à fait d'accord.
@ Tous
Par contre pour les aiguilles, comme d'autres l'on déjà dit, seul le gestionnaire peut manoeuvrer les aiguilles. Sinon risque de manoeuvrer une aiguille avec un train dessus, risque de manoeuver une aiguille d'un itinéraire formé dirigeant un train n'importe où, ...
Pour "l'accélérateur" c'est un peu pareil le gestionnaire doit filtrer les commandes pour traiter les arrêts aux signaux, les limitations de vitesse, ... Je préconise aussi l'usage d'un encodeur en quadrature plutôt qu'un potentiomètre, la position du potentiomètre de reflétant pas toujours la vitesse effective du train et il peut y avoir des mouvements mal controlés du train.
Pierre
-
Bon, ça avance bien je trouve.
Je repose une question pour laquelle je n’ai pas eu vos réponses et elle m’intéresse car je trouve qu’elle est à résoudre avant toutes les autres.
Comment faites-vous pour associer une locomotive à un canton-zone à la mise sous tension du réseau ou en posant la locomotive sur les rails ?
Les gestionnaires graphiques le font avec la souris à l’endroit où est la loco, mais si pas d’interface graphique ?
Et pour le suivi des trains d'un canton à l'autre, j’ai bien ma petite idée de l’algorithme de suivi lors du passage d’un canton-zone à un autre, mais j’aimerais savoir comment d’autres voient la chose.
Autre question dans le même registre, comment déterminez-vous qu’un convoi à totalement quitté un canton-zone ?
Cela me conduit à demander à Pierre "quand le gestionnaire sait il qu’il n’y a pas de train qui chevauche ?"
Par contre pour les aiguilles, comme d'autres l'on déjà dit, seul le gestionnaire peut manoeuvrer les aiguilles. Sinon risque de manoeuvrer une aiguille avec un train dessus
Christophe
-
Je reviens également sur la capacité de calcul pour un gestionnaire centralisé qui serait basé sur un microcontrôleur et qui aurait, disons 20 satellites à superviser.
Est-on d’accord que la fréquence moyenne d’envoi par chaque satellite de ses informations d’états est d’environ 100 ms ?
Partant de là, on est d’accord je pense pour considérer que le gestionnaire centralisé devra recevoir et traiter un message toutes les 5ms et donc avoir fait ce qu’il a à faire pour ce satellite donné dans ce laps de temps : Mise à jour des données variables, capteurs ponctuels, arrêt ou ralentissement de la locomotive au besoin, modification de la signalisation.
Sachant que par ailleurs il doit ponctuellement modifier les aiguilles, assurer le suivi des convois !
Je pose vraiment cette question sans arrière-pensée.
Christophe
-
Bonsoir
Je suis un peu débordé par toutes les questions, mais je vais répondre, demain vraissemblablement.
Pierre
-
Je peux donner des éléments de réponse
1°) On détecte la présence d'un train par consommation de courant.
C'est évident pour une loco, et pour un wagon ou une voiture isolée, il faut souder une résistance CMS (10 kOhm) entre la roue isolée et l'essieu.
Toute autre méthode n'est pas sûre (en particulier les ILS/ Effet Hall, ... qui sont ponctuels)
Pour être franc, il existe une autre méthode fiable : le comptage d'essieu. Mais, pour la mettre sur un réseau, bonjour...
2°) Le vocabulaire est très clair :
Une ZONE correspond à une détection de présence. Ce peut être un rail avec des coupures, une aiguille seule, plusieurs aiguilles.
Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls car on ne peut pas les relier à un canton.
Un CANTON, c'est un ensemble de zones avec des signaux à chaque extrémité. Ou à une seule extrémité si c'est une voie à sens unique, évidemment.
Donc, faire une "carte canton" est ambigu : cela correspond à un cas très particulier : une seule zone avec un signal à chaque bout. C'est très réducteur.
Maintenant, c'est clair : un canton est libre quand TOUTES les zones qui le composent sont vides
3°) Personnellement je pense qu'il faut réserver les boutons qui commandent des aiguilles aux cas très simples (une ou 2 aiguilles isolées). Sinon, on passe par un itinéraire.
Dans tous les cas, un bouton ne commande pas directement une aiguille. Un bouton demande au gestionnaire de changer la position de l'aiguille et le gestionnaire le fait quand les conditions de sécurité sont remplies
Comme je l'ai déjà dit, il existe un état "occupé par un itinéraire", complètement distinct d'une occupation physique d'une zone.
A la SNCF, les zones correspondant à un itinéraire sont affichées au TCO (par exemple en blanc clignotant) et l'occupation physique (par exemple en rouge). Pas seulement la position des aiguilles. Et on voit les zones s'effacer derrière le train au fur et à mesure que le train avance sur l'itinéraire.
Il faut pouvoir enregistrer des itinéraires, sans tenir compte des occupations (physiques et par un autre itinéraire).
Après, le gestionnaire libère les trains quand c'est possible en toute sécurité.
On voit que Denis a décortiqué des tas de choses
Entre autres, j'ai lu la "Bible" de la signalisation : "La signalisation ferroviaire" de Roger Rétiveau (639 pages !!)
-
l faut souder une résistance CMS (10 kOhm) entre la roue isolée et l'essieu.
Merci pour cette info.
Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls car on ne peut pas les relier à un canton.
Un CANTON, c'est un ensemble de zones avec des signaux à chaque extrémité.
Je ne te suis pas, tu dis que "Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls", là je suis OK mais tu dis "on ne peut pas les relier à un canton." alors que tu dis plus loin : Un CANTON, c'est un ensemble de zones
Merci pour la réponse
Christophe
-
Simplement, dans ta carte, tu englobes jusqu'à 2 aiguilles. Tu peux parce que tu prends les aiguilles "en talon" (pas "en pied", d'ailleurs).
Si un train est en phase de quitter le canton du côté des aiguilles et qu'il soit uniquement sur les aiguilles, le fait que le canton reste occupé n'a pas d'incidence, ça ne gêne pas les autres trains.
Et s'il n'est que sur la partie sans aiguilles, de toutes façons aucun train ne pourrait venir sur les aiguilles. C'est "un tout".
Par contre, un croisement doit être géré tout seul, on ne peut pas le relier à un voisin. Voir le schéma.
J'ai supposé qu'on reliait le croisement au canton 1.
Si un train est sur le canton 1, sans être sur le croisement, même à l'arrêt, on empêche un train qui va du canton 2 au canton 3 de passer à cause de l'occupation du croisement.
Et pareil pour les autres extrémités. Il doit être géré tout seul.
Mais ça n'est pas un canton car il n'y a pas de signaux
-
Quand l'une des zones d'un canton est occupée, TOUT le canton est occupé
-
Pour info sur les résistances CMS pour détection de présence :
Le "Petit Train du Tertre", le site d'une bande d'amis (dont notre Jean Luc 8) à ses débuts, avec un certain Pierre Molinaro)
https://lestrainsdutertre.redheberg.com/TouteVapeur/Les_trains_du_Tertre/Articles_Trains_du_Tertre/C03_La_detection_de_presence.html (https://lestrainsdutertre.redheberg.com/TouteVapeur/Les_trains_du_Tertre/Articles_Trains_du_Tertre/C03_La_detection_de_presence.html)
Plein d'idées sur plein de sujets
ou
http://rouge-et-creme.over-blog.com/2014/08/detection-facile-de-vos-wagon-et-voitures-en-ho.html (http://rouge-et-creme.over-blog.com/2014/08/detection-facile-de-vos-wagon-et-voitures-en-ho.html)
-
Bonsoir
Je m ajoute aux contributeurs de ce fil
Je voudrais aussi apporter quelques éléments de topographie à intégrer aux réflexions/propositions en cours.
Entre deux cantons ( là où on peut arrêter un train par cantonnement) on rencontre souvent sur nos réseaux des grills d entrées/sorties plus ou moins complexes.( ex double bretelle, TJD,...)
Ce sont des zones à monitorer mais sur lesquelles le cantonnement est "INTERDIT".
On peut associer l'enchainement par construction mais les distances sont parfois de l ordre d un ou deux appareil...
Par ailleurs on peut avoir un enjambement du convoi sur plusieurs zones dont à minima 2 cantons ( car loco en tête assurant une détection, véhicule non consommateur en milieu, et véhicule de fin consommateur)
Autre alternative renseigner les longueurs des convois et zones (cantons, zone grills, ...) et suivre les mappings associés... (nœuds au cerveau garantis!)
Autre cas à considérer:
Circulation en sens inverse des segments de voie parcourus
Circulation en "pousse" ( engin moteur en queue dans le sens de déplacement)
Il n y a surement de solution "toute faite" mais il faudra configurer par un moyen une initialisation avant de pouvoir s'offrir une exploitation.
Laurent
-
Je reviens également sur la capacité de calcul pour un gestionnaire centralisé qui serait basé sur un microcontrôleur et qui aurait, disons 20 satellites à superviser.
Est-on d’accord que la fréquence moyenne d’envoi par chaque satellite de ses informations d’états est d’environ 100 ms ?
Partant de là, on est d’accord je pense pour considérer que le gestionnaire centralisé devra recevoir et traiter un message toutes les 5ms et donc avoir fait ce qu’il a à faire pour ce satellite donné dans ce laps de temps : Mise à jour des données variables, capteurs ponctuels, arrêt ou ralentissement de la locomotive au besoin, modification de la signalisation.
Sachant que par ailleurs il doit ponctuellement modifier les aiguilles, assurer le suivi des convois !
Je pose vraiment cette question sans arrière-pensée.
Christophe
Tous les messages n’ont pas besoin d’être répétés. Un accusé de réception évite les répétitions (cas des commandes de signaux et aiguilles). Les détections ponctuelles aussi.
100ms est arbitraire . Ça peut se déterminer par calcul des temps dans le programme. J’ai souvent mesuré des traitements compliqués de moins de 5ms.
Je pense que cette question n’est pas primordiale pour le moment. C’est du reglage.
-
Bonjour Dominique, bonjour à tous,
Ce n’est pas aux commandes d’aiguilles ni de signaux auxquelles je pense qui doivent effectivement arrêter d’être envoyées dès que l’on a l’accusé de réception.
Par contre, je ne suis pas sûr de bien comprendre pour les détections ponctuelles.
Est-ce que tu veux dire que tu limites la fréquence de messages envoyés par les satellites ?
Personnellement, je ne jouerai pas là mais à la réception dans le gestionnaire, en recherchant si, pour un identifiant donné les datas du message sont différentes du précédent envoi.
Certes 100ms c’est arbitraire, toute autre fréquence aussi d’ailleurs. Mais par expérience, on constate que c’est à peu près ce qui est nécessaire pour détecter des capteurs ponctuels comme des IR ou encore des capteurs RFID.
La question est-elle primordiale ? Oui sans doute car je pense qu’elle doit être omni présente au moment de l’écriture du code pour rechercher tous les mécanismes d’économie de calcul.
-
Comment faites-vous pour associer une locomotive à un canton-zone à la mise sous tension du réseau ou en posant la locomotive sur les rails ?
Les gestionnaires graphiques le font avec la souris à l’endroit où est la loco, mais si pas d’interface graphique ?
On aborde ici une question dont on ne parle pas souvent qui est l'initialisation du gestionnaire.
A son initialisation le gestionnaire à besoin de connaitre toutes les zones qui sont réellement occupées ainsi que les références des l'engins moteurs qui sont dessus (nom, adresse DCC,icone, ...). Pour faciliter ceci on peut lors de l'arrêt normal du gestionnaire sauvegarder ces informations dans un fichier (ou autre) pour les reprendre lors de l'initialisation. Mais quelques cas (crash du gestionnaire, déraillement, ajout d'engin moteur, ...) nécessitent un moyen de dialogue avec le gestionnaire (pas forcement par le biais d'un TCO graphique). De toute façon le gestionnaire a besoin de signaler des infos sur son fonctionnement (des anomalies, des erreurs, ...).
A son initialisation le gestionnaire à besoin aussi de connaitre la position de toutes les aiguilles. Soit on peut obtenir ces positions en questionnant les satellites, soit on peut les sauvegarder dans un fichier lors d'un arrêt normal du gestionnaire, sinon (dont le cas du crash) il faut mettre une par une toutes les aiguilles dans une position connue par manoeuvre.
Pour finir sur l'initialisation tous les signaux carrés sont fermés, les sémaphores présentent les feux voulus et aucun itinéraire n'est formé.
Pierre
-
Quand l'une des zones d'un canton est occupée, TOUT le canton est occupé
Bonjour Denis,
Eh bien oui je suis d’accord avec toi et c’est comme cela que je raisonne pour les satellites autonomes. Certes, je n’ai pas encore voulu inclure le cas de croisement mais comme je te le disais je préfère partir du général et terminer par le particulier qui finira par trouver sa solution.
D’ailleurs, tu prenais aussi le cas de la boucle de retournement. A la réflexion, ce n’est rien d’autres que deux cantons reliés chacun à l’une des extrémités de l’aiguille, non ?
-
Et pour le suivi des trains d'un canton à l'autre, j’ai bien ma petite idée de l’algorithme de suivi lors du passage d’un canton-zone à un autre, mais j’aimerais savoir comment d’autres voient la chose.
C'est un problème épineux et je suis preneur de solutions originales. Quand une zone passe de l'état libre à occupé on a besoin de savoir quel train rentre dessus. Pour cela on examine les deux zones avoisinantes en fonction de la position des aiguilles, il ni en a au maximum que deux car un train ne peut venir sur une zone que si les aiguilles sont bien positionnées. Si une seule de ces zone est occupée on connait le train (il faut vérifier que c'est possible avec son sens, et sa vitesse), sinon il y a ambiguïté on a deux trains candidats et il faut jouer sur le sens des trains, leur vitesse (arrêt) , le sens des zones, l'état des itinéraires ou des autorisations, ...
On peut très bien ne pas trouver quel est le train (aucune des deux zones voisines occupées ou trains des zones voisines ne convenant pas), cela arrive normalement quand on pose un nouvel engin moteur sur le réseau, le gestionnaire signale alors une anomalie et il faut un dialogue pour le renseigner.
Pierre
-
Autre question dans le même registre, comment déterminez-vous qu’un convoi à totalement quitté un canton-zone ?
Cela me conduit à demander à Pierre "quand le gestionnaire sait il qu’il n’y a pas de train qui chevauche ?"
Bonjour
On fait habituellement une détection de présence sur une zone par consommation de courant. Les engins moteurs consomment du courant (mais problème avec les engins moteurs à l'arrêt en analogique), les véhicules éclairés ou les fourgons (avec les feux arrières) aussi. Les autres véhicules non, Denis nous a indiqué ci-dessus que l'on peut rendre détectables des véhicules avec une petite résistance sur les essieux. Il existe un autre système équivalent le graphitage, il s'agit mettre une sorte de verni sur les bagues isolantes des essieux, ce verni contient du graphite qui conduit un peu le courant.
Idéalement tous les essieux ne prenant pas le courant devraient êtres traités (resistance ou graphite). Pratiquement si on a beaucoup de véhicules c'est un peu fastidieux. Pour palier cela on peut transformer un peu le gestionnaire, à chaque train est associé une liste de zones, quand le train occupe une nouvelle zone elle est ajoutée en tête de liste, quand le train libère une zone si c'est la dernière de la liste on procède à la libération normale de la zone sinon ou "oublie" cette libération (on ne fait rien).
La taille de cette liste peut être bornée en fonction de la topologie du réseau. Mais attention aux ruptures d'attelages qui peuvent faire exploser la taille, des tests et des messages du gestionnaire sont les bienvenus.
Pierre
-
Bonjour
Comme je l'indiquais précédemment tu as aussi le cas ou le convoi et à cheval entre 2 cantons mais avec entre ces 2 éléments principaux une "occupation" d'une zone ( ou plusieurs) (cas des aiguillages).
Si il y a un élément consommateur sur le segment en question pas de sujet il y a association et application des règles de détection.
Dans le cas contraire je ne vois que 2 solutions
La pré réservation d itinéraire qui n est "détruite" que lors de la libration du canton le plus haut de la liste (ici N+1) ou changement d itinéraire ( par forçage)
ex: N+1 -- ZONE AIGUILLAGEA -- ZONE AIGUILLAGEB -- N -- N-1
Une comparaison parallèle avec les tailles des convois et celle des cantons et de leur déplacement.
Pour illustration la système Pégase réalisait une pré allocation en cas de succession de zone(s) sans arrêt (zone d aiguillage) et avec arrêt(canton) initialement "enjambement" sur 4 segments contigus.
Ce mécanisme est aussi à la base d autres produits ou de trains réel par verrouillage des itinéraires notamment. Je pense entre autre à RRTC
Laurent
-
@BobynCo
Christophe, je crois me souvenir que dans ton projet de satellites autonomes l'identification est portée par RAILCOM qui une fois établie ( l Identification) va générer les instructions de freinage pour l'engin moteur concerné.
L indentification au démarrage du système en conception peut s'appuyer sur un mécanisme analogue (AUTO ENROLLING) ( mais il manquera des info sur par exemple le type de convoi, sa longueur…) qui influent sur le bloc, à défaut on fixera a la longueur maxi permise comme taille de convoi sur le réseau.( par ex 3m20)
Je crois qu'il y a une restriction "forte" pour le cas des UM.
En effet en mode "CONSIST MODE" (UM) en principe l'émission RAILCOM du channel1 est désactivée et on se reporte alors à l émission de l adresse active du "couplage" sur le channel2 si la configuration est faite pour cela.
Dans le cas contraire on va avoir deux émissions de la même info ( une par chaque engin moteur) ( avec un risque de parasitage mutuel)( il est peu probable que chacun soit synchro avec son voisin!) soit il faut filtrer pour que par exemple seul l'engin de tête émette et sur le canal 2 dans ce cas. ( je pense mon interprétation conforme)
Chose inédite je n'ai jamais vu de système ayant plusieurs véhicules émetteur en RAILCOM sur une même section. ( plus par restriction que par non réalisation?) Mais peut être y a t il une magie qui le permettrait...
Laurent
-
Bonjour
Je connais bien le train français et je cherche toujours à rester très proche des techniques utilisée par celui-ci. Je crois que l'on est d'accord sur le fait que le gestionnaire doit assurer la sécurité. La sécurité des vrais trains est assurée par beaucoup de règlements et par la signalisation. Ce qui nous réunit ici c'est plus la signalisation et tout ce qu'il y a derrière. La signalisation est gérée par des postes d'aiguillage et des dispositifs de cantonnement.
Le cantonnement n'assure que l'espacement des trains (anti rattrapage) avec signalisation (BAL,BAPR,BMU, …) ou pas (cantonnement téléphonique, ). Les postes d'aiguillages utilisent des enclenchements (mécaniques ou électriques) pour assurer la sécurité : prise en écharpe, aiguilles mal positionnées, tête à tête, … La signalisation du cantonnement et des postes d'aiguillages peut être commune (BAL,BAPR, …) ou séparée (BMU, …) ce qui complique un peu les choses.
Le cantonnement et les postes d'aiguillages peuvent utiliser des zones pour leurs fonctionnement.
Une zone est un ensemble contigu de voies et d'appareils de voie (aiguille, TJD, TJS, croisement), sur lequel il y a une détection de présence d'un ou plusieurs essieux, par un dispositif électrique ou électronique.
Ces zones sont essentielles dans les cantonnements et les postes d'aiguillages modernes.
Les contraintes sur les zones dépendent un peu de leur utilisation :
- pour les zones dans les bifurcations ou les entrées/sorties de gare on fait en sorte qu'il ne puisse avoir qu'un seul train en circulation dessus, ce qui exclu la présence de plusieurs TJD,TJS ou croisement dans ces zone.
- pour certaines zones, comme celles des voies à quai, on peut avoir plusieurs trains dessus, pour créer des unités multiples ou mettre des motrices en tête. Généralement ces zones n'ont pas ou peu d'appareils de voie.
- pour certaines zones constituant des cantons le cantonnement "permissif" permet à un train d'entrer sur une zone occupé. Généralement ces zones de pleine voie n'ont pas ou peu d'appareils de voie.
Un canton est un ensemble contigu de voies et d'appareils de voie en général plutôt long (quelques kms). L'entrée dans un canton est habituellement protégée par un sémaphore ou un signal pouvant présenter le sémaphore (carré), situé juste avant le début du canton. Si le canton est à double sens il y a un signal des deux côtés. Certains cantonnements utilisent une zone ou plusieurs zones pour assurer le fonctionnement du cantonnement.
Le cantonnement se fait surtout en pleine voie, mais certaines bifurcations et certaines entrées/sorties de gare et leurs voies à quai assurent aussi la continuité du cantonnement. Le sémaphore est alors affiché sur les carrés et les zones servent simultanément au cantonnement et au postes d'aiguillages.
En résumé, on parle trop de canton et pas assez de zone. Une zone peut comporter une TJD ou une TJS ou un croisement ou pas et/ou d'autres aiguilles (ces aiguilles étant disposées de façon à respecter les contraintes précédentes). Il peut y avoir du cantonnement dans une gare.
Pierre
-
Moi je suis d’accord avec Pierre : il faut s’occuper des zones en premier, chacune d’elle ayant un capteur de présence qui permet de détecter l’entrée d’une loco en tire (en pousse il faut faire consommer le wagon de tête).
Chaque zone doit connaître les zones adjacentes pour permettre la propagation du no de train donc le suivi des trains en recopiant son numéro dès le début de la détection. C’est le mécanisme de base à réaliser avant tout.
Lors d'une détection en entrée de zone, un train est toujours à cheval sur 2 zones. Je marque ainsi la tête de train dans la zone nouvelle,t détectée et la queue du trains dans la zone précédente.
Le train contient les zones occupées et lorsque la tête entre dans une nouvelle zone, en général, la queue libère sa zone. Lorsque la zone de queue est une aiguille, la zone avant aiguille est aussi occupée par la queue.
On pourrait aussi connaitre la longueur du train et celle des zones pour marquer les zones effectivement occupées.
La zone peut faire partie d’un canton qui va définir les signaux à fermer juste après la détection en tenant compte des zones incluses dans le canton. La présence d'aiguille(s) complique un peu les règles de marquage des zones.
La libération des zones dépend donc de la composition du canton, donc des signaux concernés
-
En ce qui concerne l'initialisation du gestionnaire, la position des trains au départ, j'utilise une méthode assez infaillible et amusante au démarrage du réseau :
Comme la centrale peut piloter 12 trains dans mon réseau, tous les trains sont arrêtés et j'en bouge un et un seul uniquement jusqu'à ce que les détections de présence le détectent. Cela se produit à un changement de zone. J'en déduit la position et le sens du train. Puis je le recule à la même vitesse pendant la même durée pour qu'il retrouve sa place initiale.
Ensuite je recommence pour un autre train et ainsi de suite.
S'il ne se passe rien, soit le train n'est pas présent sur le réseau, soit il y a un mauvais contact.
Le risque est que le train percute un autre situé sur la zone adjacente mais ce cas est impossible si l'espacement des trains a été conservé à la session précédente.
J'ai modifié mes détecteurs sur mon réseau pour qu'il ne soient sensibles que lorsque les moteurs tournent. Ainsi il n'est plus nécessaire de rouler jusqu'à la zone suivante, la détection est immédiatement faite et cela ne dure qu'une fraction de seconde.
L'inconvénient est que je gestionnaire ne voit plus les trains à l'arrêt.
En cas d'erreurs dans le gestionnaire, un mode "panique" peut stopper tous les trains et relancer la détection de position.
-
Bonsoir
La méthode d indentification via RAILCOM est rapide et efficace mais elle n'est que partielle.
En effet il n'y a que l'engin moteur sans autre forme d'info de donner.
Si dans le gestionnaire un fait un mapping avec une référence de composition connue et que celle ci n a pas changé alors on a un convoi dont on connait les caractéristiques.
Sinon l'info est erronée: ex la loco est "haut le pieds" et donc il faut modifier/actualiser le mapping pour que les caractéristiques jouent à plein ensuite et soient exploitées.
Ltr
-
Bonjour à tous,
Le train miniature est sensé représenter le train réel.
Mais dans le train réel, des ingénieurs ont analysé le réseau pendant longtemps, en implantant les signaux en respectant des règles strictes, en prenant en compte de nombreux paramètres.
Dans les trains, il y a un conducteur qui a été formé, à qui on donne toutes les caractéristiques de son train, qui connait à l'avance les passages dangereux.
Et nous, on voudrait faire pareil avec 2 bouts de ficelle ! :o
On ne peut pas travailler correctement sans connaître la longueur des zones (et donc des cantons), sans connaître la longueur des trains et à suivre cette longueur.
Dans mon système, comme je pose des éléments de réseau (les pavés), je connais exactement leur longueur à l'écran et comme, maintenant, je dessine à l'échelle, je connais la longueur réelle des zones (à environ 1 mm près), y compris avec des rails flexibles.
Par ailleurs, vous vous en souvenez peut-être, dans "Decodunino", je décris les locos, les wagons, … et donc, leur longueur. Là, c'est dans l'autre sens, la longueur réelle donne la longueur à l'écran puisque c'est à l'échelle.
Aussi, le réseau est constellé de "points" équidistants (merci Pierre pour cette idée géniale) et, donc, à tout moment, je connais la longueur des trains (en points), je sais à quelle distance (en points) je suis du signal qui me commande l'arrêt. Avouez que c'est pratique.
Je sais qu'un train a perdu un wagon car sa longueur (la distance entre le point avant et le point arrière) est plus grande que la longueur initiale du train.
Evidemment, on ne perd pas de wagons sur un train virtuel ! ;D
Parce que, finalement, ce que je fais sur mes trains virtuels, on peut évidemment le faire sur les trains réels. Je m'explique :
-> Vous entrez dans une table la longueur de toutes les zones
-> Vous mesurez vos locos et wagons dans une autre table et vous indiquez lesquels vous choisissez lorsque vous posez un train sur le réseau.
-> Vous connaissez la position du train dans un canton car vous connaissez sa vitesse (Voir la vidéo de Renaud Yver et son réseau Luzy avec RRTC pour faire klaxonner un train juste avant un passage à niveau sans mettre d'ILS) et sur quelle zone il est.
Avec la position de l'avant du train et sa longueur, si un wagon reste planté, au bout d'un (court) moment, vous vous rendrez compte que le canton C-1 ne devrait pas être occupé : vous avez perdu un wagon.
J'ai donc un objet "train" qui enregistre tout ça. En particulier la liste des zones occupées, les longueurs, …
Remarque :
Il faut sauvegarder la composition des trains en cas de plantage complet, ainsi que la longueur des zones.
Identification :
Dans ma solution, un train est OBLIGATOIREMENT sur un "itinéraire" qui peut être réduit à un seul canton quand il est arrivé au bout de l'itinéraire.
Donc, quand on pose un train, c'est le seul qui n'est pas sur un itinéraire. Cela l'identifie.
Denis
-
Tout ca c’est très intéressant et c’est bon de le savoir : ce sujet est une mine d’information.
Mais j’aime bien des choses faisables : par exemple pour connaître la longueur d’un train, il suffit de le faire traverser une zone de longueur connue et de connaître sa vitesse.
C’est ce que je fais sur une zone de parade. La distance est connue et le temps de traversée du train entre les 2 détecteurs de présence donne la vitesse. Ensuite le temps de présence dans la zone donne la longueur du train !
Ça me sert aussi à étalonner les vitesses des trains.
Simple et pratique
A chaque passage des trains le processus recommence et la perte d’un wagon se détecte 🚂🚉
Après. Il vaut mieux de bons attelages et éviter de perdre des wagons. C’est la qu’on s’aperçoit de la qualité des petits trains réels. En N ce n’est pas si simple !
Denis, combien de locos et de wagons réels as-tu ?
-
8 locos et 40 voitures et 8 wagons
-
Bonsoir Denis
Limpide.
L'objet" itinéraire est donc un "LOT CONSOLIDE " de toutes les zones d'une extrémité (entrée) d un canton à un autre (sortie)
Tout ce qui est "entre" ces points distincts doit être associé par logique à cette réservation et rien ne peut y être sécant (sécurité des itinéraires)
En BAL ( Bloc Automatique Lumineux) Les combos de signaux ne sont que 3 états principaux enrichi de contextes spécifiques:
ROUGE = ARRET
JAUNE = RALENTIR
VERT = VOIE LIBRE
On a 3 types de "ROUGE" : carré, sémaphore et carre violet
Au niveau "JAUNE" on a: le rouge clignotant ( sous réserve de franchissement possible, sinon le remettre au dessus) Avertissement, Ralentissement 30, Ralentissement 60, Rappel de ralentissement30, rappel de ralentissement 60 et en combo je jaune en sus
On peut y associer le vert clignotant par extension.
en "VERT" Enfin el voie libre et ou le blanc ( départ en Manœuvre) et ou le blanc clignotant ( départ en manœuvre réduite)
Les carrés( rouge et violet) assurent des protections.
Les autres feux hors manœuvre assurent le cantonnement
Quel facteur fait que le "JAUNE" est l'un ou l'autre?
La construction d un arbre de conditions qui conduisent par combinaison(s) à préciser le contexte pour l'affichage de l un des cas si applicable à un cas JAUNE.= principalement des positions d aiguilles, et ou de bloc.
Idem pour différencier vert et blanc.
On peut choisir de faire influer ou pas les vitesses aux états ( en étant K proportionnel) ce n'est pas obligatoire des lors que le rouge est bien un contexte d arrêt absolu;, que le "JAUNE" produit une vitesse inferieure ou égale à la vitesse nominale, le "fine tunning" des vitesses intermédiaires est affaire de choix.
Pour résumer on a donc besoin de 3 blocs fonctionnelles pour piloter:
un bloc pour les segments de voie et leur caractéristiques (gestion de l infra)
un bloc pour la gestion des matériels et leur association( gestion convoi)
un "hyperbloc" qui établit un mapping entre les deux premiers, interagit et assure les fonctions désirées.
Si on pose une loco inconnue en base alors on actualise des éléments ( a minima) . ( on peut au mieux juste récupérer son adresse DCC via RAILCOM en automatique)
On associe un "convoi" dont on précise les caractéristiques ( longueur, …)
Si le convoi a évolué ou changé( loco sur un autre convoi) on actualise ses caractéristiques. Par défaut on applique une règle de sécurité qui force aux conditions les plus défavorables l'attribution des caractéristiques "max" au nouveau convoi ( ex longueur la plus longue admise sur le réseau avec une marge de sécurité.)
On voit donc que le mode 100/100 autonome exclusif va être contraint de disposer à minima en sus d'une IHM pour traiter les caractéristiques sur les ambitions indiquées.
On passe alors sur une réalisation plus ambitieuse avec des parties bien identifiées.
Laurent
-
Mais j’aime bien des choses faisables : par exemple pour connaître la longueur d’un train, il suffit de le faire traverser une zone de longueur connue et de connaître sa vitesse.
C’est ce que je fais sur une zone de parade. La distance est connue et le temps de traversée du train entre les 2 détecteurs de présence donne la vitesse. Ensuite le temps de présence dans la zone donne la longueur du train !
Ça me sert aussi à étalonner les vitesses des trains.
Super méthode en effet mais je pense que tu ne peux pas prendre en compte dans ce cas un train qui est plus long que ta section de mesure. Donc cette zone est au plus court la longueur max d un convoi.
On est OK la dessus?
Ltr
-
@ Dominique
Ta méthode marche, bien sûr, mais il faut repasser par la zone de test pour identifier un problème.
Avec ma méthode (plus complexe à gérer, bien sûr) on le sait très rapidement après qu'on a perdu un wagon.
Prenons un exemple :
Soit 3 cantons de 10 unités de long C1, C2 et C3 et un train de 8 unités de long
Dès que le train a parcouru 8 unités du canton 2, on ne devrait plus rien avoir sur le canton 1. S'il reste une présence sur C1, c'est un wagon perdu.
Une autre méthode, moins précise :
Si le train est présent sur C1 et C2 et C3, c'est qu'on a perdu quelque chose.
Denis
-
Mais j’aime bien des choses faisables : par exemple pour connaître la longueur d’un train, il suffit de le faire traverser une zone de longueur connue et de connaître sa vitesse.
C’est ce que je fais sur une zone de parade. La distance est connue et le temps de traversée du train entre les 2 détecteurs de présence donne la vitesse. Ensuite le temps de présence dans la zone donne la longueur du train !
Ça me sert aussi à étalonner les vitesses des trains.
Super méthode en effet mais je pense que tu ne peux pas prendre en compte dans ce cas un train qui est plus long que ta section de mesure. Donc cette zone est au plus court la longueur max d un convoi.
On est OK la dessus?
Ltr
Tout à fait d’accord. On fait un réseau dans le but que ça marche et on accepte un peu de contraintes. Je ne compose pas de trains avec 12 voitures, d’ailleurs je n’en ai pas tant que ça !
-
@ Dominique
Ta méthode marche, bien sûr, mais il faut repasser par la zone de test pour identifier un problème.
Avec ma méthode (plus complexe à gérer, bien sûr) on le sait très rapidement après qu'on a perdu un wagon.
Prenons un exemple :
Soit 3 cantons de 10 unités de long C1, C2 et C3 et un train de 8 unités de long
Dès que le train a parcouru 8 unités du canton 2, on ne devrait plus rien avoir sur le canton 1. S'il reste une présence sur C1, c'est un wagon perdu.
Une autre méthode, moins précise :
Si le train est présent sur C1 et C2 et C3, c'est qu'on a perdu quelque chose.
Denis
Je suis aussi d’accord avec toi Denis. J
Je ne recherche pas la perfection maximale mais aussi le plaisir de voir tourner mes trains.
Parfois je dois crapahuter pour récupérer un wagon renversé dans un tunnel inaccessible, mais je m’arrange ensuite pour éviter ça.
On devrait d’abord converger vers un gestionnaire pratique, faisable, compréhensible et fonctionnel dans un grand nombre de cas. Puis le perfectionner ensuite.
Plutôt que se limiter à l’impossible !
Plus concrètement, si le bus Can transmet des messages de détection de présence (donc avec un numéro de zone tout simplement), que doit faire le gestionnaire:
- dans le cas d’un gestionnaire centralisé ?
- dans le cas d’un gestionnaire de canton autonome?
Vous avez 1 heure.
-
@ Dominique
Moi je sais, moi je sais:
Tout bien faire comme il faut!
Fastoche hein ;)! 8)
@Denis
Qui d un convoi qui se "morcèlerait"( rupture d attelage) il serait pour partie sur des zones non contiguës ce qui génère une "anomalie"/"alerting?
C est bien la libération de la dernière "zone active" ( avec présence détectée) ( par rapport à la tête et du nombre d unités occupées par un convoi) qui est à suivre pour actualiser l itinéraire, ce qui est entre les deux dans ce cas reste simplement à surveiller ( sinon morceaux multiples!)
Ltr
-
@Laurent,
En effet on traite la tête du train avec l’occupation et la queue du train avec la libération.
Puis on compare.
-
@BobynCo
Christophe, je crois me souvenir que dans ton projet de satellites autonomes l'identification est portée par RAILCOM qui une fois établie ( l Identification) va générer les instructions de freinage pour l'engin moteur concerné.
L indentification au démarrage du système en conception peut s'appuyer sur un mécanisme analogue (AUTO ENROLLING) ( mais il manquera des info sur par exemple le type de convoi, sa longueur…) qui influent sur le bloc, à défaut on fixera a la longueur maxi permise comme taille de convoi sur le réseau.( par ex 3m20)
Je crois qu'il y a une restriction "forte" pour le cas des UM.
En effet en mode "CONSIST MODE" (UM) en principe l'émission RAILCOM du channel1 est désactivée et on se reporte alors à l émission de l adresse active du "couplage" sur le channel2 si la configuration est faite pour cela.
Dans le cas contraire on va avoir deux émissions de la même info ( une par chaque engin moteur) ( avec un risque de parasitage mutuel)( il est peu probable que chacun soit synchro avec son voisin!) soit il faut filtrer pour que par exemple seul l'engin de tête émette et sur le canal 2 dans ce cas. ( je pense mon interprétation conforme)
Chose inédite je n'ai jamais vu de système ayant plusieurs véhicules émetteur en RAILCOM sur une même section. ( plus par restriction que par non réalisation?) Mais peut être y a t il une magie qui le permettrait...
Laurent
Bonjour Laurent,
En effet, c'est Railcom qui est utilisé pour la détection sur les satellites autonomes, mais il s'agit dans ce sujet de rechercher des solutions "plus universelle".
Railcom est très intéressant et permet de contourner pas mal de problème pour lesquels on se casse la tête ici mais !!! Mais tout le monde n'est pas équipé en Railcom, et comme tu le soulèves il y a peut être des problèmes non vus encore comme les UM.
Les satellites autonomes sont bien adaptés pour des les petits et moyens réseaux et les dioramas ce qui représente déjà bon nombres de besoins. Mais sur des réseaux complexes comme présente par exemple Denis avec plus de 2 ou 3 aiguilles en successions, des croisements, des TDJ et je ne sais quoi encore ou des UM pourquoi pas comme comme tu le dis il ne seront pas adaptés.
Christophe
-
Bonjour
@ Laurent
Je ne suis pas trop d'accord avec ton "analyse" des feux des signaux. Si on exclut pour simplifier les feux clignotants, il y a trois sortes de feux : les feux de block, les feux de protection et les feux de limitation de vitesse.
Il y a trois feux de block : voie libre (Vl), avertissement (A) et sémaphore (S).
Pour les feux de protection il y a deux sous-sortes, les feux de manoeuvre carré violet (Cv) et manoeuvre (M), et les "normaux" carré (C), avertissement (A) et voie libre (Vl).
Les feux de ralentissement sont le ralentissement (R) et le rappel de ralentissement (RR).
En pratique il y a souvent un mélange des trois sortes de feux, exemples un sémaphore avec un feu ralentissement, un carré avec un feu sémaphore, un carré avec un feu manoeuvre, un carré avec un feu rappel de ralentissement, ...
Pierre
-
Voici comment je raisonne pour mes trains virtuels.
Mais c'est en l'appliquant aux trains réels que ça va devenir intéressant.
(https://www.locoduino.org/local/cache-vignettes/L150xH39/20240106_094237-3fc41-c8e6f.jpg?1704533400)
Sur l'image, on voit 4 cantons à une zone qui se suivent. On est dans un cas hyper simple.
Dans l'étape 1 (1ère ligne) le C1 a 70 points de longueur, C2 a 40 points, C3 a 90 points et C4 a 80 points.
Le train 1 est sur C4. Il est en automatique. Son itinéraire fait 80 points et comme il est arrivé à la fin de son itinéraire, il y a le C (carré). Il est à 30 points du C et finit son arrêt.
Le train 2 est sur C1. C'est moi qui le conduis. Mon itinéraire fait 280 points car je souhaite aussi m'arrêter en gare en C4.
Mon prochain signal est à 20 points et c'est VL que j'affiche sur ma manette.
Dans l'étape 2 (2ème ligne), le train 1 est arrêté à 10 points du C.
Le train 2 a toujours un itinéraire de 280 points, mais mon prochain signal est à 30 points et c'est A (Avertissement) que j'affiche sur ma manette.
Mais ce que je sais, c'est que je suis à 130 points du S (sémaphore) quand j'entre dans le C2. Je vais donc devoir m'arrêter en 130 points.
Pour l'instant, j'ai commencé à freiner et il me reste 120 points pour m'arrêter.
Ce qui me parait intéressant dans cette démarche, c'est que je ne raisonne plus en cantons, mais en longueur à parcourir jusqu'au prochain signal qui va m'obliger à m'arrêter.
Ça prend donc en compte la longueur des cantons, la distance de freinage, de façon tout à fait automatique sur un itinéraire sur lequel je sais tout ce qui va m'arriver.
La signalisation est mise à jour indépendamment des itinéraires, en fonction des positions des aiguilles et des occupations.
Puis, une fois la signalisation mise à jour globalement, on l'intègre dans les itinéraires et ça agit sur les trains.
Dernière remarque :
Mes trains virtuels n'ont pas le DCC, évidemment.
Donc, c'est dans le programme que je calcule le ralentissement, via une courbe de ralentissement (semblable à une décharge de condensateur) que je mets à jour suivant 2 paramètres : la vitesse initiale et la durée de ralentissement (= le nombre de points). Je suis alors CERTAIN que le train s'arrêtera au bon endroit puisque la courbe tient compte de la longueur d'arrêt.
Si on fait confiance au DCC pour gérer le freinage, on prend un risque de ne pas arrêter au bon endroit.
Denis
-
Bon et si on se mettait au travail, commencer à écrire du programme.
Faut choisir un langage, personnellement le préconiserais d'en utiliser deux C++ et Java (Processing). Les deux langages sont très proches, des grandes parties de la syntaxe son strictement les mêmes, il y a un article sur le site qui explique les petites différences entre les deux. Le programme en C++ est plutôt destiné aux micro-controleurs et le programme en Java plutôt destiné au ordinateurs ou micro-ordinateurs (genre Raspberry).
Celui qui écrit un bout de programme le fait dans son langage préféré et après mise au point on le transcrit facilement dans l'autre langage.
Bien évidemment il faut utiliser la programmation objet. Donc un bout de programme est une classe (un objet).
Personnellement je n'écrirais rien, je ne veux pas orienter vos choix. Mais je peux vous aider pour la programmation objet. Par ailleurs j'ai déjà écrit pour mon propre réseau un très gros gestionnaire.
Pierre
-
Pour compléter mon message précédent, un bout de code du traitement des messages CAN reçus par le gestionnaire dans le cas des occupations et libération par un détecteurs de présence.
Il y a effectivement des objets zone, et des objets train qu'il faut adresser à travers des tables d'objets renseignées juste après la création des objets. Il faut aussi des objets canton portant la signalisation.
Le structure du message Can sera a adapter à celle qui sera retenue. Ici c'est l'exemple de mon réseau.
// reception d'un message CAN
data = frame.data.bytes[0]; // bit 6 occupation + no de zone
occupation = bitRead(data, 6); // masque occupation 0x40 = bit 6 : True=occupé, False=libre
nzc = data & 0x3F; // No de ZONE detectée
zone* zc; // = zone ou a lieu la detection
zc = tableZones[nzc];
zone* zp; // = zone precedente à trouver
train* tt;
switch (frame.id) { // type de message
case 0x10: // OCCUPATION ou LIBERATION de zone zc venant des détecteurs
if (occupation) {
zc->occuper();
zp = zc->provenance(); // zone précédente
if (zp != NULL) {
tt = zp->train;
zc->train = tt; // marquage du train dans la zone zc de détection
// ensuite il faut mettre à jour les signaux, celui de zp si c'est une limite de canton
}
} else { // liberation de la zone zc
zc->liberer();
zc->train = NULL;
// et mise a jour ds signaux
}
break;
Evidemment c'est le cas le plus simple et la plus grande partie du code sert à traiter les erreurs !
Les détections de présence, d'identité (RFID ou Railcom) et d'arrêt ont des traitement particuliers qui leur sont associés grâce aux identifiants différents des messages Can.
De plus, les changement de régime des locos sous l'action manuelle du conducteur donnent lieu à des messages Can pour enregistrer la consigne voulue par le conducteur dans les objets train, afin qu'il reprenne la vitesse demandée lorsque les contraintes ont disparu.
Dans une autre tâche du processeur, se fait la régulation des trains : Pour chaque train le signal présent à la fin du canton détermine un ralentissement (30, 60..) avec arrêt en fin de zone si c'est un carré ou sémaphore. Le ralentissement se fait par palier de 30 ou 15 km/h (60, puis 30, puis 15 pour un arrêt), j'ai trouvé que ça suffit et qu'il n'est pas nécessaire d'inonder le bus Can de commandes intermédiaires. Par contre c'est la centrale sui gère les vitesses intermédiaires un peu comme le slowmotion servo.
Dans cette tâche, les trains redémarrent quand le signal le libère.
Au sujet des graphiques (représentation de type TCO, faite par le même processeur du DUE) , pour chaque zone il y a une fonction d'affichage, par exemple :
void GA3::tracer(int c) {
if (etat) {//droit
myGLCD.setColor(K_ferme);
geo.drawArc(196, 336, 38, 315, 360, 5); //a3
myGLCD.setColor(c);
drawbarreH(196, 298, -27); // z28
}
else { // devié
myGLCD.setColor(K_ferme);
drawbarreH(196, 298, -27); // z28
myGLCD.setColor(c);
geo.drawArc(196, 336, 38, 315, 360, 5); //a3
}
}
GAiguille* Ga3 = new GA3( 3,44 ); // a3 est dans la zone z44
Le numéro de zone est le même que celui de sa représentation graphique
J'ajouterai dès que possible une petite vidéo montrant ce qui se passe sur l'écran graphique du gestionnaire.
Plus de détails ici :
https://forum.locoduino.org/index.php?topic=290.120 (https://forum.locoduino.org/index.php?topic=290.120)
-
Bonjour
@Denis
Tu peux confier au DCC le freinage. Il te faudra toutefois étalonner ton matériel pour cela.
En effet tu dois garder une vitesse mini avant l'arrêt, cette valeur est propre à chaque matériel avec sa vitesse mini et éventuellement les coef de passage entre les seuils hauts et bas ( décélération) et inversement ( accélération)
Pour confirmer la bonne exécution une détection devant la fin du canton confirme bien l'arrivée de la tête de train dans la zone d'arrêt devant le signal. Si cet éventement ne se produit pas alors le train s'est arrêté "trop tôt". A défaut de cette zone de détection avant le signal on peut avoir quelques surprises. Mais on peut s'en passer des lors que pour chaque entrée dans une nouvelle zone il y a re synchro distance/vitesse/position. ( et donc re calculs)
Tu peux aussi penser à utiliser l'ABC LENZ cote HARD pour générer ce freinage mais il y aura moins de progressivité dans le mouvement.
Ltr
-
Bonjour,
Une ZONE correspond à une détection de présence. Ce peut être un rail avec des coupures, une aiguille seule, plusieurs aiguilles.
Comment fait-on pour détecter une présence sur une aiguille ?
Faut-il isoler l'aiguille complètement ?
Faut-il un ou deux capteurs ?
...?
-
Comment fait-on pour détecter une présence sur une aiguille ?
Faut-il isoler l'aiguille complètement ?
Faut-il un ou deux capteurs ?
...?
Oui,
Moi je le relie à un petit coupon de voie qui supporte l’éclisse isolante car l’aiguillage est fragile et il est souvent difficile de mettre une éclisse isolante. C’est plus facile aussi de souder les fils d’alim sur ce bout de voie.
-
Bonjour
Je vais essayer d expliquer le traitement des aiguillages, TJD et croisements.
On en déduira les attributions à faire avec.
Partons d un cas simple: une AIGUILLE A prise en pointe depuis un CANTON N-1 qui va de façon directe sur le CANTON N et en itinéraire dévié sur N bis
L'AIGUILLE A appartient géographiquement à une ZAP ( Zone d appareil(s)/zone d aiguille(s))
En mode directe on a
C N-1 <>ZAP<> C N
En mode dévié on a
C N-1 <>ZAP <> C N bis
Dans ce cas simple on peut ajouter au canton N l'alimentation et la détection de la ZAP car tout mouvement de N-1 vers ou depuis ou N ou N Bis transite exclusivement par la ZAP
On devra toutefois arrêter nos trains avant l AIGUILLE A dans le sens N-1 vers N ou N bis.
Attribuer une détection sur une section aussi courte qu'une seule aiguille n'est pas optimum ( en terme de conso de ressources)
Passons au cas ou toujours sur ce modèle nous avons non plus une mais 2 ou plusieurs aiguilles qui adressent les cantons N Ter N Quatro ...
La longueur de la ZAP a augmenté. Tout mouvement de N-1 vers un canton N-x et réciproquement transite par la ZAP.
Il n y a pas de trajet sécant possible traversant la ZAP puis que nous avons une succession simple d aiguillese. Si une aiguille n est pas dans une position qui desserre le canton N-x alors la sécurité verrouille les mouvements.
On peut traiter le cas de deux façons:
Soit comme précédemment ( association à la dernière zone du canton précèdent)
Soit si la longueur est étalée ajouter une détection spécifique.
Cette configuration devient utile et nécessaire dans le cas d itinéraire(s) sécant sur la ZAP ou d'entrées/sorties multiples
Ex aiguilles montées pointe contre pointe
On vient alors soit de
N-1 ou N-1bis <> ZAP<>N ou N bis ou Nx
La ZAP devient alors une section "autonome". Elle est logiquement la continuité des directions qu'elle relie mais électriquement elle est autonome ( sauf à la basculer d une section vers un autre ce qui complexifie le câblage du fait des combinaisons possibles!)
Cela devient un "cauchemar" si on a un grill d'entrée/sortie de gare qui est complexe et offre de multiples combinaisons
En effet en cas de GRILL il faut en fait pour fluidifier le trafic "paralléliser les ZAP" et les relier entre elles en cas d itinéraire sécant. ( Bretelles, TJD, TJS...)
On voit très vite qu'une ZAP et un objet LOGIQUE et PHYSIQUE
Rm: on ne cantonne pas sur une ZAP ( pas d arrêt commande par le BLOC)
En principe on n'y stationne pas non plus ( sauf si le canton qui reçoit le train est plus court que le train à recevoir)( doit il dans ce cas le recevoir?) on ne fait qu'y transiter . Pourquoi cette précision? et bien par ce que si notre convoi a une détection en tête et une en queue uniquement alors il est possible que la ZAP ne porte pas de détection ... on pourrait interpréter la ZAP comme libre... ce qui est un erreur de diagnostic. ( le train est a cheval entre N-1 et N et au dessus de la ZAP!
On voit alors que l'objet ITINERAIRE de réservation de ressource et ses conditions de libération sont très importantes.
Le système proposé par Denis couvre ce cas de figure et nous exempte d anomalie à ce niveau.
Le cas des TJD TJS et bretelle est donc la combinaison optimale de découpage des ZAP pour assurer un trafic fluide selon les combinaisons d itinéraires.
Laurent
-
Bonjour
Voila ci-dessous un exemple d'une zone complexe tout à fait possible pour un gestionnaire. Elle comporte une TJD et trois aiguilles, c'est une partie d'une image d'un ancien TCO.
Pierre
-
Je m'inquiete un peu ! >:(: qui va coder un gestionnaire concret, utilisable dans la plupart des réseaux de nos amis modélistes, si on cherche d'emblée tous les cas difficiles que la plupart d'entre nous n'envisage pas de construire.
Va-t-on faire fuir nos lecteurs qui espèrent trouver un gestionnaire centralisé ou non mais surtout accessible au plus grand nombre ? :o
Au contraire, il faudrait plutôt réaliser un noyau simple de gestionnaire, compréhensible, qui puisse être étendu et complexifié par la suite.
Donc procéder par étape. Pierre vient de prouver :D
Ne serait-il pas raisonnable de partir d'un exemple concret comme un Locoduinodrome (peut-être un peu plus large avec 2 voies en parallèle et en sens contraire) ?
On verrait mieux dès le départ les différents propositions de définition, d'organisation, de spécification et de réalisation avec les pour et les contres.
Je prend l'exemple de mon réseau, le gestionnaire est basé sur les articles de Pierre (un Gestionnaire en C++ pour votre réseau - voir les liens sur la première page).
Tous les objets qui le composent (zones, aiguilles, signaux, itinéraires, ..) sont hérités d'une classe de base qui est personnalisée (réécrite) pour chacun des objets réels afin d'y introduire les propriétés et méthodes réelles qu'elles doivent exposer. La topographie du réseau s'exprime au travers de ces personnalisations des classes.
Le gestionnaire de mon réseau est basé sur le même principe et je n'ai pas particulièrement souffert de ces personnalisations des objets, d'autant qu'il a été trés simple d'écrire des petits programmes de tests pour vérifier les bons enchainements des zones dans les itinéraires en fonction des positions des aiguilles et de tester tous les organes du réseau. De plus, je ne modifie pas mon réseau tous les jours et si c'était le cas, seuls quelques objets sont modifiés/ajoutés/supprimés.
Mais combien en ont fait autant ?
Est-il possible de réitérer un exercice semblable au Locoduinodrome, qui présente des alternatives à la construction de la topographie du réseau pour faire coopérer tous les objets qui le composent ?
Vos propositions seront les points de départ du ou des projets partagés.
-
@Dominique
En fait si tu analyses bien un objet ZAP à un instant T 2 éléments clés
un élément prédécesseur( ZAP ou canton ou zone
un élément successeur ( zone ou canton ou autre ZAP)
C est la position des aiguilles qui route les combinaisons entée/sortie.
Il faut alors me semble il juste déclarer à quelle zone appartient une aiguille lors de design du reseau.
Pour ce qui est du nouveau LOCODUINODROME je suggere comme tu l indiques
1 double voie
1 boucle de retournement
1 double bretelle
1 croisement( type bif par exemple)
1 aiguille triple ( symétrique ou asymétrique)
1 bretelle ou tjd
1 voie en impasse
1 évitement ( pourquoi pas faisant la liaison entre 2 boucle et servant de "garage actif")
Ca fait un peu de monde à caser mais la plus grande partie des cas est présente sur un réseau de circulation
A vos crayon pour assembler le tout.
Et comme dit si bien Dominique vous avez 1 heure! 8)
Ltr
-
@ Laurent
Le locoduinodrome que tu propose est beaucoup trop compliqué. Le locoduinodrome d'origine est déjà assez compliqué comme ça. L'idée d'un locoduinodrome à double voie de Dominique est séduisante, mais avec une voie d'évitement. Cela fait deux aiguilles et deux TJS (bien lire Traversée Jonction Simple).
Pierre
-
Je suis d'accord avec Pierre : démarrons simple !
et en HO et Peco, c'est 60 à 70€ !
en N je ne trouve pas grand chose.
-
@ Dominique
Il y a des TJS Peco en N : SL-E380F Crossing, Single Slip
Pierre
-
Un tracé dans ce genre là (en mieux) ?
-
Je verrai bien quelques chose de ce genre.
Ltr
-
Un tracé dans ce genre là (en mieux) ?
Ok pour l'exercice mais il faudrait tout de même définir les zones de cantonnement. Je suppose que les deux rails 6001 après les aiguilles 6080 et 6081 et avant le TJS SL80 ne suffisent pas pour cantonner un train.
-
Bon, voici un réseau qui existe vraiment, il est dans un tiroir sous un lit IKEA.
Aucun cantonnement, il est piloté en manuel.
-
@ Dominique
Je pensais à quelque chose comme cela (image ci-dessous), cela ressemble un peu à une petite gare de double voie.
Pierre
-
@Pierre,
Oui c’est beaucoup mieux, on reste dans l’esprit du premier Locoduinodrome avec une gare entre les aiguilles, une TJS et une aiguille simple de chaque côté.
Cela permet 2 circulations en parallèle avec échange possible.
Ça fait pas mal de signaux et d’itinéraires possibles.
- 3 zones de gare
- 4 zones d’aiguilles
- 2 ou 4 zones de boucle (avec un sémaphore au milieu).
Je propose qu l’on parte sur ce dessin
Je regarde ce que cela fait avec des rails en N.
Maintenant comment modéliser ce tracé ?
-
il y a des travaux préparatoires :
- faire le découpage en zones
- choisir des signaux et leurs implantations
- donner des noms à tout
A titre d'exemple le PRS de Méru, structurellement très semblable. Tout est nommé, zones, signaux, voies, aiguilles, origines, destinations, ...
Pierre
-
Bonjour
@Dpminique
Ajoute une diagonale pour traiter une boucle de retournement, c est un cas de figure très présent sur de nombreux réseaux et il serait dommage de s'en priver sur ce labo. ( ou pourra toujours ne la traiter que plus tardivement mais elle est déjà dans l équation de départ.)
Laurent
-
@ Laurent
Les boucles de retournement sont rares dans les réseaux réels. Dans nos réseaux miniature elles sont plus courantes, mais elles posent juste des problèmes électriques, pas spécialement des problèmes de sécurité.
Pierre
-
@Pierre
L ambition est bien de couvrir des cas d'exploitation extrapolables au réseau ( avec bloc pour circulation) de chacun.
On aura bien 2 aspects à traiter derrière: la partie soft et la partie hardware.
Tu peux aussi avoir un cas de figure présent sur nos réseaux: ( et souvent fort peu pris en considération)
Imagine une "antenne" qui desserre une boucle ( ou une gare terminus) à l une de ses extrémités
Tu ne peux envoyer vers la boucle qu'un nombre de trains limité ( au nombre d évitements/garages max dispo) pour assurer les mouvements sinon tu auras un face à face ( bloc à bloc) et un carre permanent et donc un "blocage d'exploitation. ( pas toujours simple à résoudre)
Pour neutraliser ce cas de figure on compte ... et si le nombre max est atteint alors on retient d envoyer vers l'antenne.
C est le cas typique des gares type BOURG St MAURICE ou ST GERVAIS desservies par des lignes en voie unique et en impasse. ( ou boucle dans notre cas c est une problématique analogue)
On ne peut y envoyer plus que le potentiel max de la ligne.
Ltr
-
En essayant le simulateur de la gare de Méru :
https://www.utc.fr/~wschon/sr06/Simulateur-PRS/index_dev.html (https://www.utc.fr/~wschon/sr06/Simulateur-PRS/index_dev.html),
On se fait une idée des circulations dans la gare et c’est déjà pas mal.
Je vois mal ce qu’apporterai une boucle de retournement.
Je ne comprends pas bien les explications de Laurent, mon grand-père était chef de gare mais ne m’a rien appris, pas comme vous !
-
@ Dominique
Super le simulateur, je ne connaissait que l'image.
@ Laurent
Je connais très bien la ligne de Tarentaise. Avant les TGVs il arrivait une flopée de trains de nuit à Bourg Saint Maurice le matin, ces trains ne repartaient que le soir, bien évidemment la gare n'avait pas assez de voies et on redescendait les trains à Moutiers, Alberville, voire plus loin et on les remontaient le soir. C'est un problème de régulation donc de régulateur.
Pierre
-
Ce simulateur pourrait être un exemple pour faire un TCO de notre Locoduinodrome.
Les grandes boucles de retour ne sont pas forcément à afficher. Une ville à gauche, une vile à droite suffirait!
Un autre exemple ci dessous, marrant mais trop compliqué pour cet exercice !
-
J'ai fait un dessin avec RailModeler, pour travailler dessus.
-
Voilà ma proposition pour les coupures de zones, les zones, les aiguilles et les signaux.
-
Bonsoir
@Dominique
Pour faciliter le nommage je t'invite à conserver une norme avec par exemple pour la voie intérieure ( disons impaire V1 ) uniquement des nombres impaires pour tout ce qui s y rapporte et réciproquement des nombres paires sur tout ce qui touche a la voie extérieure (V2)
Cela facilite le repérage ensuite ainsi les signaux, zones, aiguilles paires sont uniquement pour la voie extérieure et réciproquement.
Pour le sens un suffixe en .0 ou .1 pour indiquer l orientation pourra convenir si nécessaire
Ltr
-
Pour les TJD tu vas aussi avoir 2 moteurs donc soit on suffixe .0 .1 voir .2 si aig triple soit on nomme avec itération chaque élément
Ltr
-
Merci Laurent,
comment représenterais-tu tout cela ?
(il faut bien que tout le monde travaille un peu !)
-
Je pense que l on peut s accorder sur quelques terminologies communes
Pour la voie:
La "maille" plus petite est la zone. Z
Une zone peut être inclue dans un ensemble "sans zone d arrêt" ( typiquement une zone d aiguillage "ZAP") ou un canton ( banalise ou non qui inclue une ou plusieurs zone d arret).
Si on appel les cantons Cn et Zn les zones, on aura ZAPn pour zone d appareils.
Il faut au minima 1 zone par canton C ou ZAP si les aiguilles ne sont pas des extensions des cantons prédécesseurs ou suiveurs.
Sur le même modèle AIG 1 devient soit AIG1 et AIG3 soit AIG1.0 et AIG 1.1 ce qui identifiera les moteurs lié à la TJD et leur implantation
Dans le decoupage on peu aussi considerer que l AIG4 est une extensnion du futur canton 6 et que AIG4 ( future AIG2) est la fin du canton 2.
Electriquement en tous les cas cela tient la route comem cela.
Laurent
Dans ton exemple on part de la gauche avec C1 puis ZAP1 C3 et C5( en haut voie de biffurcation) avant de revenir vers ZAP3 puis C7
cote sud on a de droite a gauche C2 puisi ZAP 2 puis C4 puis ZAP4 puis C6
SI on prend un signal par exempel celui au dos de l entree dans C4 alors il sera appellé S4.0 et celui au bout avant la ZAP4 sera appelé S4.1 ainsi on sait que ces signaux sont attaches au canton 4 et leur position dans le sens de circulation "habituel" de la voie
-
Bonjour,
J'ai lu vos échanges sur les cantons, zones, N+1, N-2, etc... et vous essayez d'inventer le bogie avant d'avoir inventé la roue.
Il y a deux choses distinctes dans la sécurité des trains : le cantonnement et l'interconnexion (interlocking en anglais)
Et il y a un grand principe : un conducteur ne doit jamais se voir présenter un feu rouge avant d'avoir passé un avertissement.
Pour les signaux de cantonnement pas de souci : on regarde l'occupation de n+1 et le feu n+1 et ça peut se faire localement sans
passer par la centrale.
Mais pour les carrés c'est totalement différent et ça ne peut se faire que par une gestion d'itinéraire.
Un carré ne doit passer au vert (ou jaune) que si un train a demandé le passage vers une destination, que son trajet ne rentre
pas en conflit avec celui d'un autre train et que les aiguilles ont été positionnées pour ce trajet. Et il faut souvent pouvoir gèrer
le feu en avance, alors que le train n'a pas encore passé le signal précédent.
Pourquoi ne pas mettre un carré au vert en l'absence de train si les aiguillages offrent un trajet libre? Parce que si un train arrive
et qu'un autre train demande le passage le feu va passer au rouge devant son nez.
Donc il faut une gestion d'itinéraire qui va gérer des réservations au moins à deux cantons devant un train.
La définition de cantons ne suffit pas pour la gestion des carrés. Il faut définir des trajets constitués de plusieurs cantons,
avec des sens de circulation pour chaque canton avec la possibilité de réserver un trajet pour plusieurs trains si ils vont dans le même sens.
Il faut aussi définir les trajets incompatibles entre eux. Par exemple les trajets utilisant un groupe d'aiguillages ou deux trajets
avec un croisement.
La boucle de retournement pose également un problème particulier (le train en N est aussi en N+2 mais dans l'autre sens!)
La gestion du carré violet impose également le système d'itinéraire car il faut savoir si le train est en manoeuvre ou pas et
ça ne peut pas se faire automatiquement.
Enfin il y a les conflits à longue distance. Par exemple il ne faut peut-être pas engager un train sur une voie unique si il n'y a pas
de voie libre dans la gare suivante.
-
Bonjour,
J'ai lu vos échanges sur les cantons, zones, N+1, N-2, etc... et vous essayez d'inventer le bogie avant d'avoir inventé la roue.
Il y a deux choses distinctes dans la sécurité des trains : le cantonnement et l'interconnexion (interlocking en anglais)
Et il y a un grand principe : un conducteur ne doit jamais se voir présenter un feu rouge avant d'avoir passé un avertissement.
Pour les signaux de cantonnement pas de souci : on regarde l'occupation de n+1 et le feu n+1 et ça peut se faire localement sans
passer par la centrale.
Mais pour les carrés c'est totalement différent et ça ne peut se faire que par une gestion d'itinéraire.
Un carré ne doit passer au vert (ou jaune) que si un train a demandé le passage vers une destination, que son trajet ne rentre
pas en conflit avec celui d'un autre train et que les aiguilles ont été positionnées pour ce trajet. Et il faut souvent pouvoir gèrer
le feu en avance, alors que le train n'a pas encore passé le signal précédent.
Pourquoi ne pas mettre un carré au vert en l'absence de train si les aiguillages offrent un trajet libre? Parce que si un train arrive
et qu'un autre train demande le passage le feu va passer au rouge devant son nez.
Donc il faut une gestion d'itinéraire qui va gérer des réservations au moins à deux cantons devant un train.
La définition de cantons ne suffit pas pour la gestion des carrés. Il faut définir des trajets constitués de plusieurs cantons,
avec des sens de circulation pour chaque canton avec la possibilité de réserver un trajet pour plusieurs trains si ils vont dans le même sens.
Il faut aussi définir les trajets incompatibles entre eux. Par exemple les trajets utilisant un groupe d'aiguillages ou deux trajets
avec un croisement.
La boucle de retournement pose également un problème particulier (le train en N est aussi en N+2 mais dans l'autre sens!)
La gestion du carré violet impose également le système d'itinéraire car il faut savoir si le train est en manoeuvre ou pas et
ça ne peut pas se faire automatiquement.
Enfin il y a les conflits à longue distance. Par exemple il ne faut peut-être pas engager un train sur une voie unique si il n'y a pas
de voie libre dans la gare suivante.
Bonjour Etienne66
Je suis désolé de te contredire, mais ce que tu affirmes est faux, tout au moins sur nos petits réseaux miniatures. J’ai démontré le contraire avec les satellites autonomes.
Rapidement, je rappelle le concept. Sur chaque canton est disposé un satellite et chaque satellite dispose d’un gestionnaire qui est rigoureusement identique sur chaque satellite. Il n’y a donc aucune gestion centralisée du réseau. C’est ce que Pierre a qualifié de gestion répartie.
Chaque satellite autonome connait ses liaisons avec ses voisins (rien de nouveau), et comme il connait ses voisins, il connait aussi les voisins de ses voisins.
Aussi, le satellite à C0 connait l’état des aiguilles de C+1 et aussi l’état d’occupation de C+1.
Il en est de même pour C+2 et ainsi C0 connait l’état d’occupation C+2 et l'état de ses aiguilles et peut alors afficher un ralentissement ou toute signalisation adéquate comme C+1 sait aussi afficher la bonne signalisation.
On voit donc qu’il n’y a aucune notion d’itinéraire, je ne l’utilise d’ailleurs pas sur mon réseau, tout est simplement déterminé en fonction de l’état du réseau à un instant t, état connu par chacun des satellites qui reçoit des autres ces informations toutes les 100 ms au travers du bus CAN et qui adapte son comportement en fonction des informations reçues.
Vitesse et direction des trains sont aussi des informations connues des satellites.
Je précise cependant que la détection est faite avec Railcom, ce qui permet aussi aux satellites de connaitre en temps réel chaque train, sa position, sa vitesse et sa direction et chaque satellite si nécessaire, sait envoyer une commande à la centrale pour ralentir ou encore arrêter un train.
A ta disposition pour discuter de cela au besoin.
Christophe
-
Voilà ma proposition pour les coupures de zones, les zones, les aiguilles et les signaux.
Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?
(https://forum.locoduino.org/index.php?action=dlattach;topic=1645.0;attach=5567;image)
Et comme tu n'as pas remis les références des appareils, est-on bien d'accord que AIG1 et AIG2 sont bien ce que tu as présenté précédement :
(https://forum.locoduino.org/index.php?action=dlattach;topic=1645.0;attach=5545;image)
Serait-il possible d'avoir la représentation du réseau dans son ensemble et en haute definition ?
Merci par avance.
Christophe
-
Bonjour Christophe,
La notion d'itinéraire est INDISPENSABLE. Regarde la gare pourtant assez simple de MERU : c'est même un PRS (Poste tout Relais à transit Souple), le top des itinéraires
D'autre part, le Carré est fondamentalement différent des autres signaux car il peut être commandé manuellement, indépendamment des positions des trains et des aiguilles.
C'est l'Aiguilleur, un métier complexe qui décide (ou non) de lancer un train en fonction de tout un tas de critères.
C'est Etienne66 qui a raison.
Denis
-
Bonjour Christophe,
La notion d'itinéraire est INDISPENSABLE. Regarde la gare pourtant assez simple de MERU : c'est même un PRS (Poste tout Relais à transit Souple), le top des itinéraires
D'autre part, le Carré est fondamentalement différent des autres signaux car il peut être commandé manuellement, indépendamment des positions des trains et des aiguilles.
C'est l'Aiguilleur, un métier complexe qui décide (ou non) de lancer un train en fonction de tout un tas de critères.
C'est Etienne66 qui a raison.
Denis
Messieurs, répondez au cahier des charges proposé par Dominique et l'on verra qui a raison !
Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.
Christophe
-
Le cahier des charges n’est pas défini tant que tout le monde n’est pas d’accord.
La gestion d’itinéraires me semble essentielle pour commander les aiguilles (enclenchements) et pour le plaisir du modéliste avec un representation active sur un TCO.
-
Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.
Un billet n’est-il pas un itinéraire à une heure donnée et à un prix donné ?
-
"Deus ex machina" :D
Je trouve que la définition des zones et l'implantation des signaux est parfaite.
Il y a bien une voie banalisée dans la gare qui permet à chaque origine - destination d'avoir une voie principale et une voie de déviation.
Ce que j'aimerais bien, c'est qu'il n'y ait pas de définition "en dur" du réseau dans le programme et qu'il soit "neutre".
La définition structurelle du réseau serait externe, via les boutons de Christophe (sur cartes ou au TCO).
Denis
-
Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?
Non il y a des erreurs et des manques.
Pierre
-
J'avais réalisé un gestionnaire dans TrainZ que j'ai du abandonner car Auran refusait un patch de leur moteur de jeu sans lequel ça ne pouvait pas marcher.
Sans itinéraire le gestionaire ne sait pas où va un train et ne peut donc pas commander les aiguilles.
Si Christophe bouge les aiguilles lui-même c'est que c'est lui le gestionnaire du réseau. Il sait où vont ses trains (donc il connait les itinéraires) et il prend des décisions connaissant ces itinéraires. Et la signalisation est ajustée à ses désirs sans tenir compte de la règle d'or de l'avertissement avant un arrêt.
Et ça peut fonctionner parceque nos trains ont des distances d'arrêt très courtes comparées aux trains réels et n'ont donc pas toujours besoin d'un avertissement.
-
Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.
Un billet n’est-il pas un itinéraire à une heure donnée et à un prix donné ?
N’inversons pas les choses, j’ai dit que la signalisation et la sécurité totale du réseau était possible sans aucune notion d’itinéraire mais je n’ai pas dit que la gestion d’itinéraire n’était pas possible avec les satellites autonomes.
-
J'avais réalisé un gestionnaire dans TrainZ que j'ai du abandonner car Auran refusait un patch de leur moteur de jeu sans lequel ça ne pouvait pas marcher.
Sans itinéraire le gestionaire ne sait pas où va un train et ne peut donc pas commander les aiguilles.
Si Christophe bouge les aiguilles lui-même c'est que c'est lui le gestionnaire du réseau. Il sait où vont ses trains (donc il connait les itinéraires) et il prend des décisions connaissant ces itinéraires. Et la signalisation est ajustée à ses désirs sans tenir compte de la règle d'or de l'avertissement avant un arrêt.
Et ça peut fonctionner parceque nos trains ont des distances d'arrêt très courtes comparées aux trains réels et n'ont donc pas toujours besoin d'un avertissement.
Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel de ralentissement au besoin !
-
Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?
Non il y a des erreurs et des manques.
Pierre
C'est un peu con, car j'avais commencé à bosser ! Et pourquoi y aurait-il des erreurs et des manques, ne peut-on pas choisir ce que l'on veut ? Mais pourquoi ne pas choisir Méru après tout, moi plus c'est complexe plus ça me va. Et oui d'abord, pourquoi pas Méru ???
-
Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel de ralentissement au besoin !
Si tu as le contrôle manuel des aiguillages tu peux bloquer un train au dernier moment avec un feu qui passe du vert au carré devant son nez. Ce n'est pas sensé arriver.
-
Bonjour
@Christophe
Le plan a besoin d être actualise au niveau des dénominations des éléments.
Pour le design on est en phase même si on peut ajouter ci ou la une ou deux bricoles pour traiter des cas plus riches ( boucle de retournement, aiguille pointe contre pointe,...)
Ltr
-
Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel de ralentissement au besoin !
Si tu as le contrôle manuel des aiguillages tu peux bloquer un train au dernier moment avec un feu qui passe du vert au carré devant son nez. Ce n'est pas sensé arriver.
Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
-
Concernant le schéma du Locoduinidrome il y a quelques problèmes :
Je suppose que les trains roulent à gauche, mais ne pas oublier que les trains roulent à droite en Alsace-Lorraine.
Concernant les zones il manque les zones des boucles, du moins c'est flou
Concernant les signaux, je ne vois pas l'utilité de s3, par contre un signal à gauche de Z3 serait bien utile, il manque aussi les avertissements de s1 et de s4 (cela influe sur les zones)
Je suis d'accord avec Laurent avec les choix de numéros pairs pour un sens et impair pour l'autre (voir Méru)
Je suis aussi d'accord avec Laurent sur le fait qu'il faille deux numéros pour les TJS.
Vous pouvez remarquer que certaines aiguilles de Méru vont par paires n° 103a et 103b elles seront toujours manoeuvrées ensemble pour des soucis de sécurité. La SNCF fait comme cela mais ce n'est pas une obligation pour nous.
Il faut aussi penser que les noms finirons inévitablement comme identificateurs dans les programmes.
Pour répondre à Christophe on fait ce que l'on veut mais si on veut assurer la sécurité il faut que le réseau soit cohérent. Méru est fonctionnellement très proche du Locoduinodrome et pourrait être aussi choisi, mais le trouve un peu moins intéressant car il y est plus difficile de faire des extensions.
Pierre
-
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
Si on veut un gestionnaire c'est justement pour faire le boulot à la place de l'utilisateur. Ce sont les programmeurs qui vont un peu se prendre la tête.
Le principe d'un gestionnaire pour la gestion des aiguillages est en réalité assez simple :
1- On ne change pas un aiguillage avant d'avoir un train qui demande le passage.
2- On réserve la voie ou le groupe de voies pour ce train si un autre train ne l'a pas déjà réservée.
3- On positionne la ou les aiguilles.
4- On ouvre le carré.
5- Après libération des voies par le train on annule la réservation pour libérer l'aiguille.
Dans le cas des trains gérés par l'IA on le fait en suivant des itinéraires que l'utilisateur aura définis à l'avance.
Dans le cas d'un train piloté en manuel il y a plusieurs solutions :
- On donne un accès indirect aux aiguilles au moyen d'un TCO ou d'une interface graphique en passant par le gestionnaire qui va considèrer l'ordre
comme une demande de passage de l'aiguillage. Mais c'est difficile à gèrer car on ne connait pas la destination.
- On donne un accès aux itinéraires soit par un menu soit par une sélection de voie dans le TCO
- On définit à l'avance l'itinéraire que devra suivre le train manuel et le pilote devra obéir aux signaux.
- Pour les zones de manoeuvre on peut donner le contrôle direct de certaines aiguilles en réservant d'office ces aiguilles aux seuls trains manuels.
Il n'y a rien de compliqué pour l'utilisateur. La grosse différence va être au niveau du cablage des commandes d'aiguillages :
Au lieu d'avoir un bouton connecté à l'aiguille et l'aiguille qui renvoie sa position à la centrale avec un relais sur le moteur, le bouton est relié à la centrale qui
va positionner l'aiguille après avoir obtenu le permis et qui n'a pas besoin de retour de la part de l'aiguille puisqu'elle garde sa position en mémoire et qu'elle
est la seule à pouvoir la changer.
-
La notion d'itinéraire est INDISPENSABLE. Regarde la gare pourtant assez simple de MERU : c'est même un PRS (Poste tout Relais à transit Souple), le top des itinéraires
D'autre part, le Carré est fondamentalement différent des autres signaux car il peut être commandé manuellement, indépendamment des positions des trains et des aiguilles.
Il existe encore à la SNCF beaucoup de postes d'aiguillages sans itinéraires, par exemple les MU (Mécaniques Unifiés) et le EMU (ElectroMécaniques Unifiés). Dans ces postes une bonne partie de la sécurité se fait avec des tables d'enclenchements mécaniques, mais il y a aussi des enclenchements électriques. Pour faire passer un train l'aiguilleur manoeuvre les bonnes aiguilles avec des leviers si les enclenchements le permettent, puis ouvre le bon signal avec un levier si les enclenchements le permettent. Pas besoin d'itinéraires.
L'ouverture d'un carré est toujours soumise aux enclenchements, bonne occupation des zones, bonne position des aiguilles, conflit avec d'autres itinéraires, autorisations, ...
Pierre
-
Je suis d'accord avec Pierre, mais j'aimerais bien qu'il y ait une voie banalisée.
Dans Meru, il y a bien une voie banalisée au milieu, avec un emplacement logique pour qu'elle serve de voie d'évitement dans les 2 sens.
Là, il faudrait qu'il y a ait aussi une voie banalisée (celle du haut), mais c'est plus complexe puisque certains itinéraires se couperaient.
Ok aussi sur le fait qu'il faut des enclenchements, ce qui interdit de commander directement une aiguille avec un bouton.
Faire des itinéraires est quand même une belle chose et quand je vois que Meru a un PRS, je me dis que c'est ça qu'il faut qu'on fasse.
Denis
-
Pas besoin d'itinéraires.
L'ouverture d'un carré est toujours soumise aux enclenchements, bonne occupation des zones, bonne position des aiguilles, conflit avec d'autres itinéraires, autorisations, ...
Pierre
"bonne position des aiguilles" donc connaissance de la destination et donc d'un itinéraire.
Que ce soit en automatique ou en manuel on ne change pas un aiguillage si on n'a pas besoin de le faire par rapport à un itinéraire.
Et pour l'ouverture du carré il faut là encore connaitre l'itinéraire pour savoir si tous les aiguillages concernés sont dans la bonne position.
-
Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
@Christophe,
Le mieux serait que tu proposes sur mon plan initial, les zones, signaux, les noms et les circulations que tu envisageraient pour servir de base à tes satellites autonomes.
Je joins le dessin sur lequel tu vas ajouter ces éléments.
Il faut bien que nous partions d'une même référence pour que la discussion soit constructive.
-
@ Denis
La voie d'évitement (troisième voie) du locoduinodrome doit être banalisée, on est alors dans le même cas que Méru mais effectivement un peu plus compliqué.
@ Etienne
Tu joue un peu sur les mots. Dans un poste sans itinéraires l'aiguilleur sait quelle est la destination du train pour manoeuvrer ses aiguilles. Dans un poste à itinéraire l'aiguilleur sait toujours quelle est la destination du train mais ne manoeuvre qu'un levier ou n'appuie que sur un bouton (voire deux), c'est un mécanisme appelé d'itinéraire qui fait tout le travail et la sécurité. C'est juste du confort et du travail en moins pour l'aiguilleur.
Pierre
-
Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
@Christophe,
Le mieux serait que tu proposes sur mon plan initial, les zones, signaux, les noms et les circulations que tu envisageraient pour servir de base à tes satellites autonomes.
Je joins le dessin sur lequel tu vas ajouter ces éléments.
Il faut bien que nous partions d'une même référence pour que la discussion soit constructive.
Nono, non, donne le même cahier des charges à tout le monde et quand vous serez d'accord vous me faites signe.
-
Hello
Pour la voie banalisée "simple" voir mon dessin initial et la mettre au "nord" du dessin de Dominique me parait simple à faire.
Je pense aussi qu on peut ajouter une voie en impasse. Cela enrichira bien les scenarios d exploitation...
Ltr
-
Pour la voie banalisée "simple" voir mon dessin initial et la mettre au "nord" du dessin de Dominique me parait simple à faire.
Je pense aussi qu on peut ajouter une voie en impasse. Cela enrichira bien les scenarios d exploitation...
Je ne vois pas bien sur ton schéma un peu trop raturé ! Le nord c'est où, en haut ? Je pensais que l'essentiel est la gare et les boucles servent seulement à faire les retours. Il faut évidemment un sémaphore au milieu des boucles. et comme le sens de circulation peut s'inverser ce sera interessant.
Pour une voie de garage en impasse, à part garer un train, qu'est-ce que ça apporte de plus ?
-
Nono, non, donne le même cahier des charges à tout le monde et quand vous serez d'accord vous me faites signe.
Dommage, ce serait interessant de connaitre ta vision
-
@Dominique
Oui le nord c est bien le haut. ( suivre la boussole :) ) Donc une voie banalisée entre la voie extérieure et la voie intérieure accessible par chacune d elle. ( Si on est "riche" ou pourrait même doubler ce nombre) Ce qui aurait aussi un impacte sur les ZAP qui bordent ces voies.
La voie en impasse va enrichir avec les mécanismes d'itinéraire, de réservation de "ressources" les contraintes applicables ( ralentissement forcé par exemple, condition pour le mode Manœuvre (feux blanc et violet)
De plus cela peut permettre de voir à gérer une séquence autonome de mouvement entre 2 points dont un en impasse. Si on y adjoint une boucle de retournement cela devient luxueux ;) ! Mais très complet.
Idéalement il ne reste plus que l'aiguille triple pour compléter le tableau de base.
Laurent
-
@Laurent,
Mon point de vue perso est que le nord est une simple bouche de retour non décorée et pas visible du public en expo. Au mieux il pourrait y avoir une gare cachée pour stocker des trains mais je n'en suis pas favorable car devient trop complexe.
Le projet doit rester quand même assez simple pour encourager tout le monde à comprendre un gestionnaire et avoir envie d'en faire un.
Pour la voie en impasse, ça ajoute une aiguille et quelques signaux et il faut que tu expliques les circulations (séquences de mouvement) avec les états des signaux correspondants pour en apprécier l'intérêt.
@tous, j'attends vos corrections à apporter au dessin initial qui n'est pas encore un cahier des charges pour le moment.
Pour être complet, il faudra le compléter par une description des circulations envisagées, les états des zones et des signaux, combien de trains possibles, les itinéraires qui leur sont prévus , etc.. j'en oublie sans doute.
-
L intérêt de la voie en impasse va être de traiter selon l endroit choisi pour l implanter un cas d aiguille "pointe contre pointe".
C est un cas ou comme pour les TJD la zone n' appartient pas à un canton "en dure" ( y compris pour la détection ( sauf pontage selon l'itineraire tracé))
Pour la signalisation, tracer l itinéraire vers cette impasse " tiroir" va permettre de gérer la bascule sur la signalisation de manœuvre et remplacer "le vert" par le blanc pour autoriser le mouvement par exemple ou le limiter (cas du blanc clignotant). Cela peut aussi "fermer" toute nouvelle entree sur la zone concernée par la manœuvre en cours.
Ex si tu mets "au sud est" ce tiroir, tu ira vers C6 en nominal ou vers T1 en cas de manœuvre via A8.
La position de A8 peut avoir pour incidence de ne pas laisser entrer sur C2 de nouveaux trains et donc de forcer un "rouge" pour cela ( type carré) sur le signal qui précède A2.
Ltr
-
L intérêt de la voie banalisée de "stockage" au nord va etre de doubler le développé ( c est à dire un enchainement de zones pour un itinéraire à parcourir) et donc permettre dans un volume compact de réaliser des enchainements qui permettraient d accueillir plus de trains ou d afficher plus d états "cohérant" sur la signalisation.
En effet on peut avec ce mode lancer une séquence "poursuite" de 2 trains l un à la suite de l autre avec un nombre de canton limité mais avec un developpé d un nombre de cantons parcouru toujours identiques par itinéraire.
Cela fonctionne alors bien pour les 2 sens de circulations
Cela permet entre autre de laisser une voie profiter du développé maximal et sur l autre de réaliser des évolutions en manœuvre.
Ltr
-
@ laurent
Je ne comprends pas où tu veux mettre ta voie de stockage.
Explique et je mets à jour si vous êtes d'accord
Denis
-
@Denis
Merci
Elle se place "géographiquement" entre les voies de tes signaux S1 et S2 et est desservie pas les Z3 et Z6 a droite (EST) et Z2 Z5 à gauche ( OUEST)
Idem pour l impasse je la vois bien au niveau de l aiguille à gauche de C5.
On pourrait être tenté de mettre une aiguille triple mais en principe il n'y en a pas en "voie principale"
Toutefois par confort on pourra s autoriser cette solution en lieu et place de doubler le tiroir par ajout d une aiguille supplémentaire en enfilade.
Ltr
-
@Denis
Idéalement une diagonale entre C1 et la zone devant C1 serait top aussi...
-
En gros, tu fais la gare de Meru au Nord et la gare du locoduinodrome au sud.
A mon avis, ça fait beaucoup. C'est quand même une démo, pas un vrai réseau.
Denis
-
@Denis
Pas trop le choix si tu veux être confronté a des mises en œuvre concrète d implémentation présente sur les réseaux.
-
Je suis d'accord avec Denis. Restons simple pour obtenir l'adhésion du plus grand nombre.
Rien n'empêchera d'autres projets plus ambitieux mais après.
J'aimerai l'avis de Pierre, Laurent, Etienne et Christophe pour s'arrêter là.
Le dessin de Denis est à compléter avec les zones, les noms, etc..
-
Je suis d'accord pour l'ovale à double voie avec une voie d'évitement.
Pierre
-
Nouvelle version à partir de mon éditeur ancienne version.
Ce qui est marrant, c'est que les feux ont déjà la bonne couleur ;D
Cela vous sied-il ?
Denis
-
Voici ma version sur fond clair, normalement identique à celle de Denis.
Nous avons conservé les sémaphores en haut quand le cantonnement sera prévu.
Il manque les trajets possibles au travers des TJS (ce qu'on voit sur le dessin de Denis)
Et une description textuelle pour clarifier le projet sans ambiguïté.
On approche !!
-
Pas mal du tout
Pierre
-
V3
-
@Denis, apparemment T3-T4 a l’air d’être une TJD, ce qui n’est pas le cas de T1-T2.
Quels sont les chemins possibles :
Avec T1-T2: Z3 vers V1, Z3 vers VA, V2 vers Z6 et VA vers Z6
Avec T3-T4: Z8 vers V2, V1vers Z5, z8 vers VA et VA vers Z5
Mais pas Z8 vers V1 !?!
-
Oui, pas Z8 vers V1 ni V1 vers Z6
-
SUPER !
On peut partir sur ce plan !
Qui a des questions ?
Bonne soirée ! ;D
-
Hello
Désolé de passer pour un empêcheur de tourner en rond mais il faudrait garder les appellations impaires et paires pour chaque voie principales et zones reliées sans les mélanger
Idem pour les aiguilles, signaux...
Ltr
-
OK : numérote les bien pour que ce soit correct.
Fais à la main, je mettrai en forme. Merci
-
Le voici
-
Avec une chouille d évolution qui permettra de gérer le feu blanc pour des manouvres
la V1.1
-
Enfin la version la plus poussée V1.2
-
Cette dernière version offre plus de possibilités ( trop?)
Elle impacte le découpage électrique de certaines zones (avec aiguillages)
Elle offre la possibilité avec le tiroir d impasse de traiter des départs en manœuvre et des remises en tête sur la voie d évitement banalisée via entre autre la boucle de retournement.
Ltr
-
@Laurent,
Partant sur le tracé N01 sans diagonale ni impasse, nous pourrons ensuite étudier comment modifier le ou les gestionnaires développés pour juger de la facilité de réaliser ces modifications.
-
Parfait pour débuter.
Y a plus qu'a!
Ltr
-
Bonjour à tous,
Je suis occupé ce matin.
Je refais au propre le 1er réseau de Laurent cet AM et on part là dessus.
Concernant le langage, est-ce possible d'utiliser Java pour avoir des ArrayList ?
Denis
-
@ Denis Dominique Laurent
Bonjour
Je suis reparti des dessins de Denis et/ou Dominique !!!
On ne peut rien faire de plus avec une TJD en T3-T4, une TJS suffit
Il manque les zones de voies V1 V2 VA
On n'a pas besoin de noms de cantons
Comme le propose Laurent c'est peut être pas mal de d'avoir les noms d'aiguilles de forme Ax et les noms de signaux de forme Sx (pas de . dans les noms)
Comme le dit Laurent c'est mieux de tout numéroter avec de numéros pairs une des boucles et des numéros impairs l'autre (voir Méru), pour la voie d'évitement (VA) pas de contraintes.
Pierre
-
Bonjour
@Pierre
Dans le cas de réseaux plus étendus tu vas avoir un soucis sur les appellations des signaux sur les cantons banalisés car il faut idéalement un moyen pour
identifier le canton d attache du signal
indiquer son orientation ( entrée ou sortie de canton dans le sens nominal de circulation)
Au niveau programmation un bit dédié fera très bien l'affaire...
Il y adonc une astuce à trouver pour garder ces points qui facilitent beaucoup repérage et appels
A vos avis.
Ltr
-
@ tout ceux qui ont la connaissance SNCF :
Pourriez-vous expliquer les fonctions des boutons situés en dessous de la représentation graphique de la gare de Méru ?
-
Il manque les manoeuvres sur ligne.
Découpez C4 en deux avec un tableau LM (limite de manoeuvre) entre les deux et le violet pour rebrousser, pour manoeuvres sur ligne sortante.
Découpez C8 en deux avec LM et le carré S8 entre les deux et violet nain devant l'aiguille, pour manoeuvres sur voie entrante.
Dans l'idéal il faudrait une voie unique qui est plus complexe à gérer qu'une double voie.
Et je doublerais la voie C3, avec une voie pour les voyageurs et l'autre pour le fret histoire de gérer les types de trains et les priorités.
Je mettrais également des TJD à la place des TJS et des carrés violets sur C1 à gauche et C2 à droite pour la gestion des voies à sens unique sauf manoeuvres.
-
@Etienne
Tu as une autre alternative plus simple:
Mettre voie d évitement entre A2 et A4.
Mais l'ambition V0 initiale étant plus restreinte cela sera pour les evols à venir.
Idéalement les redécoupage pour les feux de manœuvre est valable, la aussi pour de futures evols...
Ltr
-
En attendant Denis avec son éditeur, voici une nouvelle version avec les noms de zone, les aiguilles. J'ai laissé les noms de signaux comme avant. J'ai ajouté les sens de circulation nominaux.
Autour des TJS les sens de circulation possibles sont :
z5 -> z1
z5 -> z0
z1 -> z6
z0 -> z6
z0 -> z9
z1 -> z9
z10 -> z2
z10 -> z0
@Etienne, oui il sera interessant de tester les facilités d'évolution du réseau et de ses appareils de voie. Ce sera possible dans des sujets séparés comme des fork sous Git
-
Bonjour
@Dominique et Denis
Dans cette version V0 les zones Z4 et Z12 sont non utiles car elles sont a attacher aux zones Z6 et Z10 ( électriquement, fonctionnellement aussi)
Le pourquoi est simple pour déterminer une "indépendance" ou une "dépendance" d une aiguille ou d un groupe d aiguille.
Si un mouvement de circulation ne peut passer que par 1 seul endroit alors il y a dépendance ( et donc enclise), si à l inverse on à une ou plusieurs alternative de passage alors on est indépendant et donc des zones séparées.
Rm si on met des à présent des zones séparées alors on se facilite les évolutions futures... ( dont notamment les sections isolées ( éclisse(s) coupure de rail, ...)
Ltr
-
Bonjour
@Dominique et Denis
Dans cette version V0 les zones Z4 et Z12 sont non utiles car elles sont a attacher aux zones Z6 et Z10 ( électriquement, fonctionnellement aussi)
Le pourquoi est simple pour déterminer une "indépendance" ou une "dépendance" d une aiguille ou d un groupe d aiguille.
Si un mouvement de circulation ne peut passer que par 1 seul endroit alors il y a dépendance ( et donc enclise), si à l inverse on à une ou plusieurs alternative de passage alors on est indépendant et donc des zones séparées.
Rm si on met des à présent des zones séparées alors on se facilite les évolutions futures... ( dont notamment les sections isolées ( éclisse(s) coupure de rail, ...)
Ltr
J'ai compris: 2 solutions
- suppression des z4 et z12 et renumérotation des z6 et suivantes.
- les garder pour évolution futures mais je ne vois pas bien lesquelles
-
@Dominique
Z4 pour implanter une aiguille et traiter une impasse tiroir. Cas des aiguilles pointe contre pointe qui se gère comme une TJD à peu de chose pret. (et donc autonomie comme zone de détection différenciée
Z12 par analogie si l impasse est de ce coté là sinon suppression pure et simple.
Ltr
-
@ Laurent
Je suis tout à fait d'accord que les zones z4 et z12 ne sont pas nécessaires, elles sont là pour faciliter des extensions comme des manoeuvres de locomotives sur les voies 1 et 2, avec ou sans tiroir (je vois plus un tiroir coté z12).
La sncf met ces zones assez systématiquement, voir le PRS de Méru, pour bien séparer les zones des postes de celles de pleine voie.
Pierre
-
Donc on garde z12 et z4 ce qui nécessite les coupures de voies correspondantes.
et le schéma reste inchangé
Chacun maintenant peut proposer son gestionnaire en précisant l'architecture matérielle qui est supportée, les liaisons vers capteurs, actionneurs, signaux, l'unité centrale supportant le gestionnaire (si centralisé) et les éléments d'interface utilisateurs (TCO ou pas, commandes et réglages).
La centrale DCC sera de préférence pilotée par le bus CAN, pour innover avec la centrale LaBox. Sinon, il faudra l'expliquer.
-
Vision type Méru
Denis
-
Hello
Je suggère que l on renomme les Cx en Sx car ces signaux peuvent être des carres mais pas que...
Une appellation "neutre" permettra ensuite de préciser le type désiré
Ltr
-
Bon est-il possible de considérer que la version fournie par Denis ci-dessus est définitive ??? Si oui, est-il possible de l'avoir sur fond blanc, c'est plus pratique pour ajouter des infos (graphiques, textes...).
On est bien d'accord que maintenant ce sont des aiguilles entre A, 1, et 2 ???
Cela fait donc 6 aiguilles (bien qu'il n'y ait pas de A6. Je ne me trompe pas ?
-
@ Dominique Denis
Il y a des anomalies dans vos dessins
Pierre
-
D'autres erreurs ?
Pour passer en fond blanc, il faut changer plein de choses : les noms en blanc, ...
-
En négatif ?
-
Génial !
les couleurs de feux à changer, mais c'est facile
-
C'est beau et on ne change plus.
C'est le plan officiel pour démarrer votre gestionnaire.
avec cette précision : on ne peut pas passer de la voie intérieure à la voie extérieure (et vice versa) sans passer par la voie de dégagement.
Autour des TJS les circulations possibles sont :
z5 -> z1
z5 -> z0
z1 -> z6
z0 -> z6
z0 -> z9
z1 -> z9
z10 -> z2
z10 -> z0
Hâte de voir vos propositions en commençant pas une schéma d'architecture générale pour comprendre les "où" et "quoi" et comment sont reliés les éléments entre eux (Can avec LaBox par exemple si possible).
-
Le petit poste PRS de Méru est intéressant, c'est un poste à itinéraires, URL : https://www.utc.fr/~wschon/sr06/Simulateur-PRS/index_dev.html .
Le TCO affiche les choses classiques : numéros de zones, de signaux, d'aiguilles. Il y a un voyant pour les zones d'approche des carrés (ZAp), des voyants pour l'annonce des trains, …
Il faut remarquer les ronds blancs avec des lettres et des chiffres dedans, ce sont les points d'origine et/ou de destinations d'itinéraires que l'on va retrouver en dessous. :
- AE Arrivée Epinay
- DE Départ Epinay
- AT Arrivée Tréport
- DT Départ Tréport
- 1 2 A Arrivée et/ou Départ des voies correspondantes
Il faut remarquer aussi qu'il n'y a pas de numéros de cantons, bien que le poste fasse effectivement du cantonnement.
Passons au panneau de commande, les deux lignes du haut comportent des commutateurs de fermeture des signaux (ronds avec une flèche) pour urgence, travaux … ainsi que d'autres dispositifs plus difficiles à expliquer.
Tout le reste en dessous c'est les commandes d'itinéraires. Il y a des repères ce sont les cases noires et des boutons gris ou marron. Les boutons gris sont pour les itinéraires à destruction automatique, les boutons marrons pour les itinéraires permanents. Les boutons sont à juste droite d'un repère pour les itinéraires de gauche à droite et à gauche dans le cas contraire.
Pour faire un itinéraire on commence à rechercher le repère de départ désiré (case noire), en tenant compte du sens désiré (ici il n'y a de choix de sens que pour A) puis on appuie sur le bouton destination voulu. Si l'itinéraire peut s'établir le bouton passe en blanc, l'itinéraire est affiché en jaune en tracé continu sur le TCO, sinon il est mis en mémoire et le bouton passe en blanc clignotant. L'itinéraire est normalement détruit progressivement par le passage d'un train, le TCO mis à jour et bouton s'éteint. On peut détruire manuellement l'itinéraire s'il n'est pas pris par l'enclenchement d'approche (petite lampe témoin sur le TCO).
Si on a choisit un itinéraire permanent le bouton passe en marron pale et l'itinéraire est tracé en vert sur le TCO. Si l'itinéraire ne peut être établit il est mis en mémoire. L'itinéraire n'est pas détruit au passage d'un train, d'autres trains peuvent suivre en étant soumis au cantonnement (ici BAL). Si on ré-appuie sur le bouton l'itinéraire repasse en mode normal (le bouton redevient marron et le bouton à coté devient blanc et le tracé sur le TCO dévient jaune).
Si on clique sur certaines cases noires (AE,AT,DT) une fenêtre popup apparait pour paramètrer un train qui va effectivement passer en mettant les zones au rouge et détruisant les itinéraires. Remarquer le voyant d'annonce et celui de l'enclenchement d'approche (qui empêche normalement de détruire manuellement un itinéraire quand le conducteur à vu l'avertissement du carré ouvert).
L'itinéraire au départ du repère DT est un itinéraire de manoeuvre associé à l'aiguille marquée 5.
Jouez bien.
Pierre
-
C'est beau un PRS, hein ? ;D
Moi qui milite depuis des années pour qu'on fasse un PRS (que j'ai dans mon système), je ne peux qu'être ravi.
Et c'est aussi une bonne raison qui valident la création de Z4 et Z12.
Je joins le plan en négatif, mais avec des feux de la bonne couleur.
En particulier C5 est à Carré car aucun itinéraire n'est fait, alors que les aiguilles A4, A5-A7 sont dans une position qui permettrait au train qui viendrait de Z10 d'avancer ... si l'aiguilleur le décidait.
Denis
-
Bonjour
Je vous propose une possibilité pour les signaux, avec des extensions possibles :
- s1 et s3 sémaphores (feux Vl, A, S)
- s2 et s4 sémaphores avec ralentissement (feux Vl, A, S, R)
- c1 et c2 carrés (feux Vl, A, C) ajout possible (feux S, M)
- c3 et c6 carrés (feux Vl, A, C) ajout possible (feux S, M)
- c4 et c5 carrés rappel de ralentissement(feux Vl, A, C,RR) ajout possible (feu S)
Pierre
-
Bonjour,
Tout à fait d'accord.
Je précise, pour ceux qui ne connaissent pas complètement la signalisation SNCF, c'est que tu n'as pas mis de S (Sémaphore) aux signaux C (carré).
En effet, comme on est en approche d'une gare ou dans une gare, c'est l'aiguilleur qui donne aux trains le signal de départ.
Prenons un exemple : un train est en z6 et s'éloigne de la gare.
Un autre train est en z2 et attend le départ.
Pour l'instant il a le C sur c6 car l'aiguille A2 n'est pas dans la bonne position (pour des raisons historiques le train sur z6 vient de la voie A).
Puis l'aiguilleur met l'aiguille A2 en position tout droit, et on pourrait penser que, cette fois, on va pouvoir mettre le c6 à S.
Mais ça serait une drôle de décision car, en fait, le train ne peut pas avancer à cause du train sur z6.
Donc l'aiguilleur supprimera le C uniquement quand z6 sera libre.
Tout ça pour dire que c6 ne sera jamais à S.
La signalisation (surtout le carré) est faite de subtilités et n'est aussi "automatique" que ça.
Denis
-
Je suis aussi d’accord.
J’apprends. Merci pour les explications :D.
On ajoute cela au cahier des charges.
-
Quel type cible faudrait-il pour chaque signal ?
-
- 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
-
Chouette ça va être beau 🤩
-
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
-
@ 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
-
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
-
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
-
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 ?
-
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
-
Bonjour,
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
-
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.
-
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/ (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
-
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 :
(https://www.locoduino.org/local/cache-vignettes/L150xH123/capture_d_ecran_2024-01-13_084434-cebde-8ddb5.png?1705132048)
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
(https://www.locoduino.org/local/cache-vignettes/L78xH150/capture_d_ecran_2024-01-13_084616-259bb-85d9e.png?1705132065)
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
-
Bonjour
Sur les conseils de Christophe, j'ai regardé les éditeurs de fichiers json. C'est beaucoup plus pratique.
Pierre
-
@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
-
@Denis Excuse-moi je ne comprends pas bien ce que tu as voulu dire. Tu dis « je n'ai rien à rentrer pour arriver au même résultat » et tu dis ensuite « j'ai dû tout rentrer à la main ».
Pour moi, quel que soit la méthode initiale utilisée, il faut bien arriver à un fichier de description des liaisons. Très simplement, il faut bien dire par exemple que c1 est relié à c2 quand l’aiguille A1 est droite (ou qu’il n’y a pas d’aiguille) et à c3 quand A1 est déviée. Et ainsi de suite. A vrai dire, on s'en fout que ce soit des droites, courbes ou des virages. Ce sont simplement des liaisons.
Que tu utilises un processus de découverte comme le mien, un graphe comme toi ou toute autre méthode, (pourquoi pas renseigner à la main un fichier, un peu fastidieux mais réaliste), il faut bien que cela soit concrètement traduit dans un fichier, non ? Que ce fichier soit json ou autre ?
L’avantage du fichier json, c’est que l’on a un couple clef/valeur, et que les valeurs d’une clef peuvent aussi tenir dans des tableaux auxquels on peut accéder avec leur index. On est déjà en présence d’une structure de bases de données qui se conjugue bien avec le c++ et aussi le javascript dont on pressent bien qu’ils seront présents dans un gestionnaire et dans sa représentation graphique, le TCO. C’est Etienne je crois qui en a parlé encore récemment. Json est un format de stockage mais aussi et surtout un format d'échange qui est né avec et pour la programmation objet.
Ou alors, dois-je comprendre que ton gestionnaire et ton outil graphique ne font qu'un ?
Sinon, il ne doit pas y avoir de problème à ce que ton outil graphique exporte les liaisons sous forme clefs/valeurs, soit directement en json, soit dans un autre format qui sera alors traduit par programmation en json ! Ca ouvre quand même beaucoup plus d'horizons et de choix possibles pour les gestionnaires et le langage de programmation.
Mais peut-être n'ai-je rien compris à ton projet ?
-
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.
Mais comme le gestionnaire de Pierre est totalement compatible avec le Can si on l’installe dans une carte LaBox par exemple, qui tourne sur ESP32, une configuration du réseau en utilisant le wifi ou BLE devrait être possible.
Est-il possible de faire un petit éditeur wifi pour générer le json ?
Sans avoir besoin de l’échelle exacte.
Mais je n’irai pas jusqu’à y faire tourner aussi la centrale DCC, ni le TCO sur carte graphique. Avec la Can rien de plus simple que de répartir dans des cartes séparées.
-
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 comment sont nommé donc 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 (bit 0 à 0) droite, seconde aiguille déviée (bit 1 à 1)
Enfin P11, canton accessible à horaire 1° aiguille (bit 0 à 1) dévié, 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 que cela va aussi 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.
Il s’entent que les instances sont créées elles aussi automatiquement par exemple au moment de l’import du fichier json de description.
class Node
{
private:
…
…
public:
Node();
Node *nodePeriph [nodePsize];
Aig *aig[aigSize];
Loco loco;
Sensor sensor[sensorSize];
Signal *signal[signalSize];
…
…
}
Et dans le constructeur :
for (byte i = 0; i < nodePsize; i++)
this->nodeP[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
-
@ Christophe
Ou alors, dois-je comprendre que ton gestionnaire et ton outil graphique ne font qu'un ?
Oui, justement, le gestionnaire et l'outil graphique ne font qu'un.
Je dessine dans un éditeur graphique, ce qui génère un fichier lisible dans Excel qui sert à mémoriser le dessin ET comme entrée au gestionnaire.
A part en développement du programme lui-même, on n'a pas à intervenir dans le fichier. On n'a même pas besoin de regarder quelle tête il a (sauf si on est curieux)
Je ne rentre aucun numéro d'aiguille, je ne nomme aucun signal, je ne décris pas le réseau (à part que je le dessine), ça se fait tout seul et ça abonde un fichier.
Alors, pour apparaitre dans ce fil sur les gestionnaires, j'ai dû mettre du texte partout, remplir moi même avec mes petites mimines un fichier Excel effectivement lourd à rentrer à la main. Mais le vrai fichier que j'utilise avec mon gestionnaire, c'est celui-là. Il n'y a pas de texte, pas parce que je l'ai effacé, mais parce que je ne l'ai jamais rentré.
Denis
-
Ma méthode est tellement atypique que j'en viens à me demander ce que je fais sur ce fil. :-[
Je ne peux pas vous aider (je me pose des questions que vous ne vous posez pas)
Et vous ne pouvez pas m'aider non plus (vous vous posez des questions que je ne me pose pas)
Denis
-
Mais ça fonctionne au moins ce que tu as fait ? C'est ça l'essentiel ! Au moins pour toi.
Après, ce serait bien que ça crache un fichier où il n'y aurait que les liaisons et les positions comme je l'explique plus haut P00, P01 etc..., qu'il soit en json ou autres peu importe.
A partir de la description, ça entre dans n'importe quel gestionnaire "maison"
-
Comme je l'ai dit, ça fonctionne avec des trains virtuels ... sur un PC.
Donc, il me faut une interface PC/CAN pour que ça marche avec des trains réels.
Mon (gros) problème sera de les synchroniser en position entre le terrain et l'écran (comme dans CDMRail)
Mais je ne vois pas de solution pour passer d'un texte brut avec un fichier JSON dont vous semblez tous avoir besoin.
D'autre part, vous pensez "gestionnaire pur" qui, c'est vrai, n'a pas besoin de TCO.
Or, pour moi, c'est le TCO sur PC qui commande les trains.
On n'a pas du tout la même façon de voir le problème.
Voilà
Denis
-
@Denis,
J'ai regardé ton tableau, il y a moyen de faire quelque chose à partir de cela :
(https://forum.locoduino.org/index.php?action=dlattach;topic=1645.0;attach=5630;image)
je m'y retrouve à peu près sauf, qu'est-ce que tu appelles "ligne" ?
Comment arrives-tu à déterminer pair et impaire (je suppose que c'est ce que ça veut dire dans cote0 ou coté1).
Où est pair (gauche ? droite ?) où est impaire ?
-
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.
En gérant les "côtés", c'est comme gérer pair/impair.
La problématique, c'est qu'il y a, de façon sous-jacente, une structure dans JSON (et c'est tout l'intérêt, d'ailleurs) et que le fichier Excel n'a aucune structure. C'est du texte brut.
Remarque : dans mon système, c'est le programme qui remplit le fichier Excel. Là, je l'ai fait à la main pour montrer ce qu'on peut obtenir.
-
Comme je l'ai dit, ça fonctionne avec des trains virtuels ... sur un PC.
Donc, il me faut une interface PC/CAN pour que ça marche avec des trains réels.
Mon (gros) problème sera de les synchroniser en position entre le terrain et l'écran (comme dans CDMRail)
Mais je ne vois pas de solution pour passer d'un texte brut avec un fichier JSON dont vous semblez tous avoir besoin.
D'autre part, vous pensez "gestionnaire pur" qui, c'est vrai, n'a pas besoin de TCO.
Or, pour moi, c'est le TCO sur PC qui commande les trains.
On n'a pas du tout la même façon de voir le problème.
Voilà
Denis
Bon ça une interface Serial (PC) vers CAN c'est que dalle, j'en ai fait une qui est sur le Git de Locoduino.
Pour passer de texte brut à json, le mieux est encore d'écrire son propre programme en c++ qui ouvre et lit le fichier brut qui sera de toutes façons structuré (séparateur de champs, séparateur de lignes) et d'ajouter par programmation la syntaxe pour json, ça aussi c'est que dalle. Surtout si c'est un fichier comme j'ai mis ci-dessus.
Je préfère aussi quand c'est séparé. Ton éditeur graphique peut être une bonne solution. Export, traitement json, puis import dans un ESP32 par exemple et un gestionnaire en C++ assez universel, où l'on peut travailler à plusieurs et où chacun peut ensuite adapter à sa sauce.
Et puis un TCO, chacun fait comme il veut, physique ou HTML ou autre qui communique lui aussi avec une passerelle CAN.
-
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.
En gérant les "côtés", c'est comme gérer pair/impair.
La problématique, c'est qu'il y a, de façon sous-jacente, une structure dans JSON (et c'est tout l'intérêt, d'ailleurs) et que le fichier Excel n'a aucune structure. C'est du texte brut.
Remarque : dans mon système, c'est le programme qui remplit le fichier Excel. Là, je l'ai fait à la main pour montrer ce qu'on peut obtenir.
Bon je n'ai toujours pas compris l'intérêt de "ligne" mais je vais chercher.
Franchement, "horaire ou anti horaire" n'est il pas plus explicite ?
-
Je construit des itinéraires (nécessaires, pour moi, dans le fonctionnement de mon gestionnaire).
Un itinéraire est une grande ligne, composée de lignes du réseau aboutées.
On a besoin de connaître l'orientation de chaque ligne, avant de les abouter, pour qu'elles soient toujours orientées dans le bon sens (cas des boucles de retournement, par ex) et je connais l'orientation (locale) de chaque ligne parce qu'elle a un côté 0 et un côté 1.
-
Ouais, je pense comprendre à peu près ce que tu veux dire, mais effectivement tu vas finir bien seul !
-
C'est dommage car du fichier ci-dessus, il y a moyen de faire quelque chose
(https://forum.locoduino.org/index.php?action=dlattach;topic=1645.0;attach=5630;image)
Mais pour cela il faut que tu me dises ce que tu penses de horaire et anti horaire ?
-
Je pense par ailleurs que tu abordes trop vite la notion d'itinéraire. Elle est importante mais vient après dans l'analyse
-
@ Denis
Je suis venu aussi à séparer le gestionnaire du TCO, c'était déjà le cas avec l 'ancien Locoduinodrome.
Un programme pour le gestionnaire et un programme pour le TCO. Cela permet d'avoir le TCO que l'on veut.
Les deux programmes peuvent être sur la même machine en communicant par le réseau (il y a une adresse IP pour cela). Les biens heureux qui sont sous Unix ou un dérivé d'Unix (MacOS, Linux, ...) peuvent utiliser les tubes de communication d'Unix (pipes) très performants.
Pierre
-
En utilisant un éditeur de fichier json, j'ai saisi toutes les zones, toutes les aiguilles et les suivants et précédents des zones en fonction de la position des aiguilles, nommés "voisins1" et "voisins2".
Je me suis permis de changer A7 en A6. Il doit encore avoir des erreurs dans le fichier. Pour les TJS c'est flou, il faudrait préciser à quelle aiguille (lames, moteur) s'adressent les noms(A1-A3, ...).
Je joint le fichier json pour se faire une idée. Le fichier décrit complètement la topologie du réseau (le graphe des voies).
Pierre
-
@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 !)
-
@ Pierre
C'est sûr qu'il faut détailler la méthode que tu utilises.
D'un autre côté, ça ne parait pas si impossible que ça de partir de mon (vrai) fichier pour arriver à ça en Processing.
Denis
-
@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
-
Je suis venu aussi à séparer le gestionnaire du TCO, c'était déjà le cas avec l 'ancien Locoduinodrome.
C'est dur, avec des trains virtuels...
Denis
-
Je vais avoir d’autres questions mais dans un premier temps, pourquoi la distinction voisin1, voisin2 ?
Une zone a deux cotés on entre par un coté et on ressort par l'autre ou inversement. Comme je l'ai déjà dit les appellations précédente et suivante induisent un peu un sens pour la zone, cela me gène avec les zones parcourues dans les deux sens. d'ou mon appellation voisins (1 et 2).
Mais c'est peut être provisoire.
Pierre
-
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
},
-
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"
}
]
},
-
@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
Il faut deux niveaux de définition :
Les cantons electriques définis par les coupures et les capteurs de courant. Ces cantons peuvent être connectés à plus de 2 autres canton.
Et des blocs logiques qui vont d'un feu à un autre. Ces blocs ont une seule entrée et une seule sortie et sont constitués d'un ou plusieurs cantons qui se suivent.
C'est au niveau des blocs logiques qu'il faut définir les directions.
Le bloc est considéré comme occupé si l'un de ses cantons est occupé ou réservé par un autre train. On n'autorise un train sur un bloc qu'après avoir réservé tous les cantons du bloc et on libère le bloc et ses cantons quand le train quitte le bloc.
-
Zone, Bloc, Canton 8)
Le canton d'Etienne ressemble-t-il à la zone de Pierre ?
Selon Wikipedia : "Le canton est une section de voie, généralement délimitée par des signaux, dont la longueur est fonction de la distance d'arrêt ou de ralentissement d'un train, dans les conditions les plus défavorables sur la portion de ligne considérée."
En plus on lit souvent les zones d'arrêt, zones de ralentissement.
Est-il possible de donner une définition reconnue et acceptée par tous pour la suite des discussions ?
-
Dans les vrais trains le canton est défini entre 2 signaux.
Mais dans les nôtres c'est plutôt les découpages électriques avec les capteurs de courant.
Après, peu importe comment on les nomme, le fait est qu'il faut les deux sur nos réseaux.
-
Le problème, c'est qu'à la SNCF, ils doivent gérer TOUS les cas, TOUTES les situations. Et des cas particulier, il y en a plein.
Je propose de considérer les cas les plus fréquents à la SNCF sur nos réseaux. Et ne pas considérer les cas les plus particuliers de la SNCF.
Zone = là où il y a une détection électrique
Canton = constitué d'une ou plusieurs zones, mais qui ont un signal à chaque extrémité (ou à une seule si le canton est unidirectionnel).
Bloc = c'est un système de gestion de l'espacement des trains qui, entre autres, utilise des cantons.
Denis
-
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 ?
-
Et pourquoi ne serait-ce pas la même détection de présence que sur la voie qui est avant par exemple ?
-
A la sncf on parle de canton, je ne vois pas de zones ? : https://www.sncf.com/fr/groupe/coulisses/regulation-trafic
-
On est obligé à cause de la détection par courant. Si tu comptes les essieux au passage des feux et que tu as
des conducteurs qui savent gérer un freinage et un arrêt tu n'as pas besoin des zones.
Avec la détection par courant, quand les feux dans un sens de circulation ne sont pas au même endroit que ceux de l'autre sens tu as
obligatoirement des cantons avec plusieurs zones car tu dois avoir une coupure à chaque feu.
-
Je vais peut-être écrire une c.. Bêtise :
Ne serait-il pas possible d'apprendre à notre gestionnaire toutes les connexions et toutes les possibilités de circulation en faisant simplement rouler un train partout dans le réseau après avoir déclaré toutes les zones et les emplacements des signaux (autour de certaines coupures) de façon banalisée.
Ne sommes nous pas entrés dans l'IA et l'apprentissage ?
Mais pas forcément avec de gros moyens.
Apprendre les connexions me semble assez facile, pour les signaux je pense qu'il faudra l'aider.
-
L'idée est sympathique mais il y a plus efficace et plus simple à mon avis.
-
Bonsoir
1/2 journée en expo et j'arrive lire vos progressions importantes dans le même temps! Ca turbine!!
Je reviens sur quelques info qui ont retenu des questionnement
@Christophe: tu indiquais que si le nombre d éléments augmente ( tu en as retenus 8) 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.
Sur les terminologies... il y a aussi des "cantons" sans zone d arrêt. Le terme section serait même plus juste puisque une section aura pour but de relie via des positions d appareil des cantons. Un canton étant une ou un ensemble de zones sur lesquelles entre une entrée et une sortie bordées par un signal on peut circuler ou stationner ce qui par principe ne doit pas exister sur une section sauf de façon transitoire ou par débordement ( un trin plus long qui ne rentre pas en entier dans le canton suivant déborde alors sur la section d appareils qui le précède.
Pour ceux qui ont connu DRIVING RAILWAY ces notions étaient définies comme CANTON ( banalise avec 2 ZA au extrémités ou a sens unique avec 1 ZA en extrémité)
Chaque canton était "fléché" dans sa représentation comme un vecteur.( idem pour les appareils)
Les appareils dans les cas de grill complexes étaient attribués à des cantons sans ZA
La fluidité des trafic s'opérait avec un découpage optimal des différents cantons avec et sans ZA.
Le produit disposait d un éditeur pour réaliser le dessin et de menus dans cet éditeur pour paramétrer les éléments.( Mode conception)
Le mode RUN était dédié aux circulations/exploitations…
Christophe a utilisé une méthode de découpage différente à priori avec ses satellites autonomes ( et semble un des plus avancé avec Pierre sur ces sujets)
L'expérience parle! On le sent bien. C est appréciable.( même si on ne sait pas encore "tout" des arcanes qui sont dessous)
Sur CDM RAIL son concepteur JP PILLOU m'avait expliqué qu'il effectuait une re synchro pour chaque train lorsque celui ci était détecté en entrée dans une zone de détection. Il effectuait alors un comparo entre position réel et théorique et actualisait en conséquence. Je pense qu'on aura possiblement le même genre de mécanisme sous jacent.
Ce mécanisme doit aussi être présent sur plusieurs produits existants.
Ltr
-
@Christophe: tu indiquais que si le nombre d éléments augmente ( tu en as retenus 8) 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
-
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
-
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 (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.
-
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 16 bits en mémoire.
Imaginons que nous ayons que nous ayons 25 cantons avec chacun 4 pointeurs cela donne :
25 x 4 X 16 bits = 1600 bits ou /8 = 200 octets. Bon ça commence à faire mais pas de quoi perturber un ESP32 même à 4Mo de mémoire flash.
Christophe
Dans un système avec 4Mo de mémoire les pointeurs sont en 32 bits. Tu peux avoir des pointeurs 16bits sur les UNO mais pas sur les esp32.
-
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.
-
@ 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
-
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.
Christophe
Oh que non!
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.
2- Un canton avec 2 entrées et 2 sorties a plusieurs combinaisons possibles d'aiguillages/tjd/tjs
3- Et même si tu arrivais à trouver la bonne combinaison il reste à savoir comment ils sont reliés à ton module.
4- Idem pour les signaux. Il faut connaitre les sens de circulation autorisés et les voies permettant les manoeuvres.
-
@ 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.
-
É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
-
N'y a t'il personne sur ce fil pour faire un peu de modération ?
-
Je pense qu'il faut faire les choses dans l'ordre.
Pour l'instant, on se cadre sur la description du réseau. On n'en est pas encore à la signalisation.
On a juste mis des signaux pour le schéma et pour savoir quel type de signal il fallait et où il fallait en mettre.
On fait une première description du réseau, ne serait-ce que pour savoir si on la rentre sous forme de texte brut ou de texte un peu plus structuré (JSON)
Après, il faudra faire circuler UN train pour voir comment les infos circulent dans le bus CAN (localisation, retour vers le gestionnaire, gestionnaire centralisé ou décentralisé ...)
Il est évident qu'il faudra d'autres infos dans le JSON de la description du réseau, liées à la vitesse maxi, par exemple.
Dernière remarque : on a volontairement écarté la zone de manœuvre dans le Locoduinodrome. Ça ne veut pas dire qu'on n'en parlera jamais, mais pas pour l'instant.
Je pense que la gestion de la zone de manœuvre sera très simple une fois que le système général fonctionnera.
Denis
-
On était parti dans la définition de certains termes.
Je propose qu'on indique dans le cahier des charges qu'on a une signalisation type BAL (Bloc Automatique Lumineux).
Il existe à la SNCF de nombreux types de blocs correspondant à différents types de situations. Mais on se limitera ici au BAL qui est le plus utilisé aujourd'hui.
-
Bonjour
Bon j'en ai plus qu'assez de cette guéguerre entre cantons et zones qui pollue complètement ce fil. Je propose la solution suivante, on parle de gestionnaires basés sur des cantons dans le fil de Christophe et de gestionnaires basés sur des zones dans ce fil.
Ce qui veut dire que dans ce fil on ne parle plus (ou presque plus de cantons) mais cela viendra comme pour les itinéraires.
Qu'en pensez vous.
Pour les indécis allez trainer dans une gare pour voir comment sont réellement découpées les voies.
Pierre
-
Sans apporter plus d'argumentation, alors ce sera sans moi et je vais effectivement me concentrer sur mon projet.
Bonne chance à vous et l'on se retrouve quand les projets respectifs seront bouclés.
Christophe
-
N'y a t'il personne sur ce fil pour faire un peu de modération ?
Si !
Tu fais partie du staf de Locoduino donc tu as un rôle de modérateur, mais dans ce cas si tu es à la fois juge et partie, c’est compliqué.
1) il n’y a eu AUCUN dénigrement dans ce fil.
Aucun produit ni aucune entreprise n’est dénigré.
Mais la contradiction est permise, surtout si les ouvrages que tu cites sont conformes à ce que le modélisme fait habituellement.
2) ton système est sans doute très différent des concepts de gestionnaire classiques qui se basent sur les pratiques de la sncf et qu’on retrouve dans cdmRail, RRTC, etc.
Je crois comprendre que tu réalises des cantons intelligents mais ce ne sont pas des gestionnaires répartis. La détection globale du canton est Railcom et elle peut être globale (ne pas regarder l’état des aiguilles) car un train et un seul peut occuper le canton. De plus, la conduite à la main ne nécessite pas d’itinéraires (commande manuelle des aiguilles, les enclenchements ne sont que inter-canton.
3) mais je me trompe peut-être tant que tu ne présentes pas ton projet plus globalement.
C’est sans doute la raison pour laquelle tu n’acceptes pas les terminologies et les définitions que nous cherchons à utiliser d’un commun accord.
4) il y a des points de convergence à creuser, comme le fichier de description du réseau et les outils pour le faire et l’exploiter
-
Écoute Etienne, tu es dans une entreprise de dénigrement systématique :
Christophe,
J'ai réalisé pour le logitiel TrainZ un gestionnaire complet avec la signalisation SNCF, la circulation automatique des trains avec gestion des priorités,
des voies réservées aux différents types de trains (voyageurs, fret, express, ommnibus...) ainsi que la gestion des manoeuvres avec la possibilité
pour le joueur de contrôler un train en manuel.
Je sais ce qui marche ou peut marcher mais surtout je sais ce qui ne marchera pas pour y avoir passé des mois.
Je comprends ta démarche de vouloir simplifier le système pour l'utilisateur mais plus on veut faire simple pour l'utilisateur et plus c'est
complexe pour le programmeur.
Ton système ne peut pas faire seul la différence entre une TJD et une TJS, c'est un fait. Le logiciel devra demander l'information à l'utilisateur.
De même il devra demander sur quelles broches tu as branché tes aiguilles et tes feux.
Donc tu vas avoir besoin d'une interface utilisateur pour les questions et les réponses.
J'ai suggéré de mettre des voies de manoeuvre et une portion de voie unique sur le réseau de test. Il y a une raison à çà : la gestion de ces
cas de figure demande une autre structure de données, et donc une description différente du réseau.
Par exemple une voie peut être en sens unique pour un train en ligne mais à double sens pour les manoeuvres. Donc ton système horaire/antihoraire
doit être dupliqué.
Je sais aussi par expérience qu'il faut savoir si une manoeuvre est une manoeuvre de couplage, auquel cas il faut savoir quelle est la voie de destination
vu qu'on devra autoriser l'entrée sur cette voie qui est un canton occupé. (et qui dit connaitre la destination dit itinéraires)
Maintenant tu fais ce que tu veux de mes conseils et tu peux tester des solutions par toi-même mais tu gagnerais du temps à m'écouter.
-
Parmi les innombrables message d'hier, il y a un message de Christophe disant que ce serait bien que les liens entre les zones du fichier json soient dans les zones. Je suis tout à fait d'accord.
Il y a beaucoup de liens croisés entre les zones (une zone A a un lien sur une zone B, et B à un lien sur A). Quand on traite le fichier json on crée des objets (instances) pour chaque zone mais on ne peut traiter les liens (quand on traite une zone A, la zone B peut ne pas encore traitée).
Quand toutes les zones sont crées on peut alors traiter les liens. C'est pour cela que les liens sont sortis des zones dans le fichier json.
Mais on peut les mettre dans les zones, en traitant deux fois la partie zones du fichier json, une fois pour créer les zones et une deuxième fois pour ajouter les liens.
Pierre
-
Ok, c'est vrai qu'il faut des choses claires.
Si on revenait au JSON de Pierre ?
Parce que je suis tout à fait novice sur ce format de données qui m'a l'air intéressant.
Qu'est ce qui doit être entre crochets [...] et qu'est ce qui doit être entre accolades ? {...}
Denis
-
On était parti dans la définition de certains termes.
Je propose qu'on indique dans le cahier des charges qu'on a une signalisation type BAL (Bloc Automatique Lumineux).
Il existe à la SNCF de nombreux types de blocs correspondant à différents types de situations. Mais on se limitera ici au BAL qui est le plus utilisé aujourd'hui.
On n'a pas de permissivité possible vu qu'on n'a aucun moyen de gèrer la présence de 2 trains sur un même canton (ce n'est possible qu'avec un comptage d'essieux)
donc on peut utiliser des cibles BAL,BM ou BAPR pour le réalisme vu qu'en réalité on sera toujours informatiquement sur du BAPR.
-
Je suis tout à fait d'accord avec Etienne, j'ai aussi déjà beaucoup travaillé sur les gestionnaires et je connais les problèmes des manoeuvres. Il faudra y venir en rajoutant ce qu'il faut (tiroirs, signalisation, ...), j'ai déjà timidement ajouté des "sens" aux zones, mais cela sera insuffisant.
Pierre
-
On n'a pas de permissivité possible vu qu'on n'a aucun moyen de gèrer la présence de 2 trains sur un même canton (ce n'est possible qu'avec un comptage d'essieux)
donc on peut utiliser des cibles BAL,BM ou BAPR pour le réalisme vu qu'en réalité on sera toujours informatiquement sur du BAPR.
On a effectivement pas de permissivité possible mais on peut envoyer une machine sur un canton occupé (pour faire une mise en tête par exemple) avec des itinéraires en manoeuvre, signal carré présentant le feu blanc (M), cela se fait à l'a SNCF dans les grandes gares.
Pierre
-
Si on revenait au JSON de Pierre ?
Parce que je suis tout à fait novice sur ce format de données qui m'a l'air intéressant.
Qu'est ce qui doit être entre crochets [...] et qu'est ce qui doit être entre accolades ? {...}
En json on regroupe tout avec des accolades et on y accède avec des "clés", sauf les tableaux dont les éléments sont entre crochets et on y accède avec des indices.
Pierre
-
Je pense qu'il faut faire les choses dans l'ordre.
Pour l'instant, on se cadre sur la description du réseau.
Denis
Description minimale :
- Aiguillages :
--- gauche/droite
--- adresse DCC
- Signaux :
--- type de cible
--- adresse DCC
- Blocs de présence (détection par courant) :
--- adresse du détecteur sur le bus de retrosignalisation
--- liste des aiguillages faisant partie du bloc
--- Interconnexions possibles : bloc de début, bloc de fin, position des aiguilles
- Cantons (d'un signal à un autre avec la même direction que les signaux) :
--- Bloc de départ
--- Signal de départ
--- Blocs traversés dans l'ordre
--- Interconnexions utilisées (peut être déduit des interconnexions possibles)
--- Signal de fin
--- Bloc de fin (après le signal)
--- Autorisé normal
--- Autorisé manoeuvres
--- Optionnel : détecteur IR de zone d'arrêt, adresse sur le bus de rétrosignalisation
Tout çà c'est le minimum pour la description du réseau.
Ensuite il faut rajouter des variables :
- aiguilles :
--- position actuelle
- Signaux :
--- aspect
--- canton suivant
--- feu suivant
- blocs :
--- libre/occupé (donné directement par le capteur)
--- réservé par un train (numero du train)
- cantons :
--- réservé
--- occupé
--- numéro du train (attention : on peut avoir un canton occupé par des wagons mais pas de loco donc pas de numéro de train)
-
Bonjour Etienne
Sur les aiguillages je pense que tu peux ajouter quelques rubriques utiles:
- position par défaut: droite/déviée
- type de moteur ( servo; solénoïdes, moteur lent,...)
- orientation du moteur ( pour les servo)
On peut peut être aussi évaluer si cet aiguillage doit être couplé à d autres (cas de "bretelles")
Enfin on peut envisager aussi une vitesse de circulation selon les directions( MAX, 70, 60, 30,...)
Ltr
-
@ Etienne
Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr :P
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?
Denis
-
Ce que j'ai décrit dans mon précédent message c'est le minimum avec un dispatcher humain.
Pour un dispacher automatisé on a besoin d'itinéraires.
3 possibilités :
- On donne juste le point de départ et le point d'arrivée et on laisse l'IA décider. Dans la réalité ça pourrait marcher
mais avec nos circuits qui tournent en boucle avec également des retournements l'IA va rentrer rapidement dans
des boucles sans fin.
- On donne le trajet précis en tant que suite de cantons avec des arrêts éventuels en gare. Le problème c'est que si il y a
un conflit à un moment donné ça va coincer.
- On introduit une couche supplémentaire en définissant des gares avec les trajets possibles pour traverser la gare (ainsi
que des priorités pour l'arrêt, le passage sans arrêt, voyageurs ou fret...) et des lignes pour aller d'une gare à l'autre.
L'itinéraire peut alors comporter une succession de lignes et de gares et l'IA pourra gérer les conflits.
-
@ Etienne
Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr :P
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?
Denis
Tu as raison.
-
Bonjour Etienne
Sur les aiguillages je pense que tu peux ajouter quelques rubriques utiles:
- position par défaut: droite/déviée
- type de moteur ( servo; solénoïdes, moteur lent,...)
- orientation du moteur ( pour les servo)
On peut peut être aussi évaluer si cet aiguillage doit être couplé à d autres (cas de "bretelles")
Enfin on peut envisager aussi une vitesse de circulation selon les directions( MAX, 70, 60, 30,...)
Ltr
D'accord pour la position par défaut et la vitesse.
Pour les moteurs c'est plus un problème à régler au niveau du décodeur. Et il suffit d'une temposisation entre le moment où
on change les aiguilles et l'ouverture du signal pour tenir compte des moteurs lents.
-
Je suis d'accord qu'il manque plein de choses dans le fichier, mais il ne faut pas aller trop vite, tout ce qui est matériel sera pris en compte plus tard (mais il faudra prendre en compte tous les cas : analogique ou digital, commande des aiguilles DCC ou autre, ...)
Mon fichier jison n'est qu'une proposition, j'espère que d'autre formats de fichier seront proposés. Mais on peut et même on doit discuter du format du fichier json.
Concernant les positions des aiguilles, on m'a reproché à juste titre (pour les TCOs) que deviée/directe posait des problèmes notamment avec les aiguilles symétriques, et on m'a proposé gauche/droite.
Pour les itinéraires, comme pour le BAL, ou verra plus tard.
Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.
Pierre
-
Concernant les positions des aiguilles, on m'a reproché à juste titre (pour les TCOs) que deviée/directe posait des problèmes notamment avec les aiguilles symétriques, et on m'a proposé gauche/droite.
Pour les itinéraires, comme pour le BAL, ou verra plus tard.
Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.
Pierre
Donc pour les aiguillages il faudra gauche/droite/symetrique, et pour le canton on a la position droite ou déviée donc on peut en déduire la direction.
Pour les aiguilles appairées c'est tout simple : un seul décodeur mais 2 aiguilles dans le logiciel avec la même adresse DCC.
-
Je voudrais ici faire le point sur la manière d'écrire un gestionnaire.
Deux grandes manières :
- écrire du programme comme dans la série d'articles que j'avais proposés
• avantages on peut faire absolument tout ce que l'on veut, c'est la solution la plus performante et la plus souple
• inconvénients c'est généralement un gros programme et il faut avoir de bonnes compétences en programmation (object)
- écrire un fichier qui décrit tout ce qu'il faut, avantages : l'utilisateur n'a pas à écrire de programme juste saisir un fichier, inconvénients : difficultées à saisir le fichier en respectant les règles et limitations à ce qui est prévu. Il faut derrière un programme qui prends en compte ce fichier, plusieurs solutions sont possibles :
• le programme créée des objects en fonction de modèles préétablis, avantages : bonne efficacité, programme assez facile à écrire, inconvenients : le programme qui crée les objects ne sert qu'une fois mais après encombre la mémoire
• le programme élabore du code (lignes de programme) qui sera ensuite compilé pour produire le gestionnaire, avantage meilleure efficacité si le programme fait des optimisations et non présence du programme qui élabore le code dans le gestionnaire, inconvénients : programme qui élabore le code beaucoup plus laborieux à écrire
Pierre
-
Attention avec ce raccourci
Sauf à avoir un décodeur qui permettra des réglages séparés ( distincts) de chaque moteur( cas de servo notamment mais pas que… !) cette topologie est à rejeter.
1 appareil ( simple) = 1 moteur = 1 adresse
1 appareil complexe (TJD TJS Triple,..) = 2 moteurs (ou plus) = n adresses (1 par moteur)
Ce n'est pas économique en adresses j'en convient mais on a une maille unitaire.( surement plus universelle à traiter)
1 commande peut adresser plusieurs adresses ou une seule.
Ltr
-
Dans ma proposition précédente j'avais écrit :
- blocs :
--- libre/occupé (donné directement par le capteur)
--- réservé par un train (numero du train)
En fait il faut autoriser plusieurs trains à réserver un bloc pour pouvoir gérer les voies uniques.
En effet dans le cas d'une voie unique un train doit réserver le dernier canton pour éviter q'un autre train vienne à contresens.
Et si plusieurs trains se suivent sur cette voie unique il faut compter le nombre de trains entrés et sortis avant de libèrer la voie.
Donc on aura le nombre de trains ayant réservé le bloc et non pas un numéro de train.
Et il faut ajouter le dernier bloc de voie unique dans la définition du ou des premier(s) canton(s) de ce sens de circulation
et faire la même chose dans l'autre sens.
-
Donc pour les aiguillages il faudra gauche/droite/symetrique, et pour le canton on a la position droite ou déviée donc on peut en déduire la direction.
Pour les aiguilles appairées c'est tout simple : un seul décodeur mais 2 aiguilles dans le logiciel avec la même adresse DCC.
Non c'est gauche/droite dans tous les cas (même pour les cantons).
Je tiens à signaler que tout le monde ne commande pas ses aiguilles en DCC, et qu'il faudrait mieux ne pas parler, pour l'instant, de matériel ni de canton.
Pierre
-
@Pierre
Attention pour être efficace si la commande des appareils n'est pas pilotée via DCC ( ce qui respe une implémentation possible) il faudra à minima que leurs positions soient reçues et connues pour assurer les sécurités.
Sinon... boom!
8)
-
Je voudrais ici faire le point sur la manière d'écrire un gestionnaire.
Deux grandes manières :
- écrire du programme comme dans la série d'articles que j'avais proposés
• avantages on peut faire absolument tout ce que l'on veut, c'est la solution la plus performante et la plus souple
• inconvénients c'est généralement un gros programme et il faut avoir de bonnes compétences en programmation (object)
- écrire un fichier qui décrit tout ce qu'il faut, avantages : l'utilisateur n'a pas à écrire de programme juste saisir un fichier, inconvénients : difficultées à saisir le fichier en respectant les règles et limitations à ce qui est prévu. Il faut derrière un programme qui prends en compte ce fichier, plusieurs solutions sont possibles :
• le programme créée des objects en fonction de modèles préétablis, avantages : bonne efficacité, programme assez facile à écrire, inconvenients : le programme qui crée les objects ne sert qu'une fois mais après encombre la mémoire
• le programme élabore du code (lignes de programme) qui sera ensuite compilé pour produire le gestionnaire, avantage meilleure efficacité si le programme fait des optimisations et non présence du programme qui élabore le code dans le gestionnaire, inconvénients : programme qui élabore le code beaucoup plus laborieux à écrire
Pierre
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.
-
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.
Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).
Pierre
-
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.
Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).
Pierre
Si le gestionnaire est sur PC (ou miniPC) il commande la centrale DCC (trains et accessoires en DCC) comme d'habitude via USB/Ethernet et il récupère la rétrosignalisation comme d'habitude en S88, Loconet, etc. On continue avec JMRI, RocRail, etc.. C'est juste un gestionnaire de plus avec un mode d'emploi comme les autres.
Alors qu'est-ce que ça change de ne pas utiliser le Can ?
Si le gestionnaire est sur une carte Arduino connectée au CAN, comme les aiguilles, détecteurs, signaux avec un satellite V1 ou V2, alors il y a une innovation réelle par rapport aux solutions courantes et des possibilités de modules distribués sur le Can (TCO, manettes, configurateurs).
Je ne cherche pas d'influencer vos choix, mais je préfère la 2ème solution.
-
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.
Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).
Pierre
Perso je ne vais pas utiliser un gestionnaire sur Arduino.(J'ai choisi JMRI) je suis juste là pour les conseils.
Objectivement, je pense que la décision de chacun dépend de la disponibilité d'un PC dédié au réseau ou pas.
L'avantage du gestionnaire PC c'est l'interface graphique mais les solutions existent déja gratuites ou payantes donc inutile de réinventer la roue.
Par contre le gestionnaire tout arduino on n'a pas. Donc si vous décidez de vous lancer c'est du tout arduino qu'il faut faire.
Celà dit il faut de toute façon un PC (ou MAC) pour charger les sketches donc pourquoi ne pas utiliser ce PC pour la configuration?
Quant au language, il est clair pour moi qu'il faut utiliser le C++. De cette façon tu définis tes structures de données une seule fois pour
le programme de saisie sur PC et leur utilisation sur arduino. Le PC sera donc utilisé pour toutes les saisies y compris les itinéraires et
une fois que les données sont chargées (USB, Ethernet, Wifi) ton arduino devient autonome.
Et si au bout du compte tu te rends compte que ton réseau est trop lourd à gérer pour un arduino tu pourra faire tourner tout ou partie
du même code sur PC sans avoir à tout refaire.
-
Si le gestionnaire est sur PC (ou miniPC) il commande la centrale DCC (trains et accessoires en DCC) comme d'habitude via USB/Ethernet et il récupère la rétrosignalisation comme d'habitude en S88, Loconet, etc. On continue avec JMRI, RocRail, etc.. C'est juste un gestionnaire de plus avec un mode d'emploi comme les autres.
Alors qu'est-ce que ça change de ne pas utiliser le Can ?
Si le gestionnaire est sur une carte Arduino connectée au CAN, comme les aiguilles, détecteurs, signaux avec un satellite V1 ou V2, alors il y a une innovation réelle par rapport aux solutions courantes et des possibilités de modules distribués sur le Can (TCO, manettes, configurateurs).
Je ne cherche pas d'influencer vos choix, mais je préfère la 2ème solution.
En fait dans un gestionnaire tout arduino on n'a plus la liaison USB donc il faut un lien bidirectionnel. Avec loconet et autres on n'a que le sens retrosignalisation. L'autre sens doit passer par la voie avec la limite de débit que ça impose.
Le CAN étant bidirectionnel il s'impose comme la solution idéale.
-
Je pense que l'utilisation de JSON permet de créer un fichier suffisamment structuré.
Par contre, jamais un novice n'ira là dedans tout seul.
Or c'est le but de ce fil : avoir un gestionnaire puissant sans être au fait de toutes les subtilités de la SNCF.
Donc, le challenge, c'est d'avoir une interface ordinateur (PC/MAC) simple qui génère le JSON.
Dans ce but, je trouve qu'on devrait s'en tenir, dans un premier temps, au stricts cas utiles dans le Locoduinodrome.
Cela me permettra, au passage, de comprendre un peu mieux ce qu'est vraiment un fichier JSON.
Denis
-
Je pense que l'utilisation de JSON permet de créer un fichier suffisamment structuré.
Par contre, jamais un novice n'ira là dedans tout seul.
Or c'est le but de ce fil : avoir un gestionnaire puissant sans être au fait de toutes les subtilités de la SNCF.
Donc, le challenge, c'est d'avoir une interface ordinateur (PC/MAC) simple qui génère le JSON.
Dans ce but, je trouve qu'on devrait s'en tenir, dans un premier temps, au stricts cas utiles dans le Locoduinodrome.
Cela me permettra, au passage, de comprendre un peu mieux ce qu'est vraiment un fichier JSON.
Denis
Si tu génères la configuration avec le PC en c++ avec la même structure de données que dans l'arduino tu n'as plus
besoin du json et tu dois pouvoir les transfèrer directement en binaire dans le sketch.
-
@ Etienne
Tu as parfaitement raison : le plus simple, c'est de rentrer toutes les données qui vont bien directement dans un programme de PC.
C'est économe en place, ça marche parfaitement, mais c'est le même problème qu'avec JSON : il fait bien connaître le langage utilisé.
C'est ce qu'on voudrait éviter et que ce soit via un "éditeur de JSON".
Par ailleurs le passage par JSON permet plus d'universalité : c'est indépendant de ce qu'on a fait avant.
Je m'explique : on part d'un JSON et on fait un gestionnaire Locoduino le plus complet possible (en démarrant par une phase simple)
Après, c'est au programmeur de se débrouiller pour partir de son programme spécifique pour générer le fichier JSON.
Une fois le JSON produit, ça roule.
Pour quelqu'un qui part de zéro, il faut faire un "éditeur de JSON".
Denis
-
Le bus Can est vraiment simple à utiliser (quelques lignes de code en émission) et fiable (je n'ai jamais d'erreurs dans les compteurs).
Voilà un petit exemple de trace dans le moniteur de l'IDE lorsque mon gestionnaire suit un train (le N° 0 en l'occurence)
Toute cette trace se fait dans le décodeur des messages Can reçus par le gestionnaire pour la mise au point.
Il est facile de visualiser (suiffer) les messages Can et de créer des modules séparés comme un écran graphique déporté ou des commandes d'itinéraires. Pour le moment l'écran graphique est intégré au gestionnaire pour visualiser les occupations, itinéraires, positions des aiguilles, suivi des trains...Mais il peut être déporté et alimenté avec des messages Can.
Il commence par détecter la zone où se trouve le train en le faisant bouger ce qui provoque une détection de présence: 0<60 signifie une commande de vitesse du train 0 en marche arrière au cran 60, qui une fois détecté il est stoppé (0>0)
0<60
Train 0 detecte sur z13
0>0
Puis le train démarre doucement à la manette, le gestionnaire reçoit la commande Can de vitesse
VLoco 0>5
Puis la z13 détecte une présence mais le train 0 y est déjà détecté et le train peut continuer à rouler car voie libre devant
zp est la zone précédente pour la commande du signal (carré)
La zone devant est identifiée et testée pour ralentir ou stopper le train, ou pas.
z13 Occ zp12 T0 OK VOIE LIBRE DEVANT
VLoco 0>7
VLoco 0>20
VLoco 0>18
VLoco 0>12
z13 Occ zp12 T0 OK VOIE LIBRE DEVANT
z15 Occ zp13 T0 OK VOIE LIBRE DEVANT
z16 Occ zp15 T0 OK VOIE LIBRE DEVANT
VLoco 0>23
VLoco 0>30
z17 Occ zp16 T0 OK VOIE LIBRE DEVANT
là il y a une détection RFID du train
EST-ext z16 T0 (BB20158) Train ok
z5 Occ zp17 T0 OK VOIE LIBRE DEVANT
Une détection de zone d'arrêt est ici, pouvant arrêter le train reconnu
zAR 5 T0
z39 Occ zp5 T0 OK VOIE LIBRE DEVANT
-
Pour quelqu'un qui part de zéro, il faut faire un "éditeur de JSON".
Denis
Il y a des tones d'éditeurs Json sur le web, online ou non
Par exemple : https://jsoneditoronline.org (https://jsoneditoronline.org)
-
Non, je veux quelque chose qui lui pose des questions.
"Quelle zone voulez vous rentrer ?"
"Dans quel sens voulez vous rouler sur cette zone ?"
etc...
Que l'utilisateur ne soit pas conscient qu'il est en cours d'écriture d'un fichier JSON.
Denis
-
il existe une fonction de conversion CSV ->JSON
Il y a peut-être quelque chose à utiliser en partant d'excel ?
-
Je veux bien essayer de m'occuper de cette phase. (questions -> JSON)
Occupez vous de savoir tout ce qui doit être dans ce fichier pour que le gestionnaire fonctionne
Denis
-
Non, je veux quelque chose qui lui pose des questions.
"Quelle zone voulez vous rentrer ?"
"Dans quel sens voulez vous rouler sur cette zone ?"
etc...
Que l'utilisateur ne soit pas conscient qu'il est en cours d'écriture d'un fichier JSON.
Denis
Et surtout ça élimine les erreurs dans le json et donc du code côté arduino. Le code de validation des données est sur le PC.
-
Validez vous ma vision des choses :
"éditeur de JSON" -> JSON -> Gestionnaire Locoduino
En disant que je m'occupe de la partie "éditeur de JSON", je serai aussi confronté à mon problème : "mon éditeur graphique" -> fichiers textes -> JSON.
Mais c'est mon problème.
Denis
-
Validez vous ma vision des choses :
"éditeur de JSON" -> JSON -> Gestionnaire Locoduino
En disant que je m'occupe de la partie "éditeur de JSON", je serai aussi confronté à mon problème : "mon éditeur graphique" -> fichiers textes -> JSON.
Mais c'est mon problème.
Denis
Ma réponse est OUI évidemment pour garantir l'absence d'erreurs ou le minimum.
Mais n'étant pas familier du JSON et espérer participer au développement de ce projet, j'aimerai mieux comprendre la structure du fichier JSON (son contenu) a produire et son interface avec le gestionnaire (comment le programme gestionnaire va "digérer" ce fichier JSON pour créer les objets zones, aiguilles, signaux, et paramétrer leurs méthodes .
D'un coté nous avons un prototype de fichier JSON de Pierre dans sa réponse #173 (page 12) et la proposition d'Etienne dans sa réponse #237 (page 16)
De l'autre coté nous avons les objets zone, aiguilles (https://www.locoduino.org/spip.php?article154 (https://www.locoduino.org/spip.php?article154)) et signaux (https://www.locoduino.org/spip.php?article167 (https://www.locoduino.org/spip.php?article167)) décrits dans le gestionnaire de Pierre.
Et puis, il y a la méthode utilitaire selonAiguille(Aiguille* a,Zone* z1,Zone* z2) qui définit la topologie du réseau donc les connecteurs entre zones. Et j'en passe.
Le programme non paramètré me semble un point de départ nécessaire. Est-ce qu'il est possible d'en avoir une idée ?
-
@ Pierre,
Je décortique ta proposition de JSON.
Si j'ai bien compris, Voisins1, c'est "en reculant" et Voisins2 c'est "en avançant" ?
Par ailleurs, dans une TJS, pour aller vers z1 en venant de z3, il suffit que A1 soit tout droit. A3 indifférent. (voir PJ)
Me trompe-je ?
Denis
-
@ Pierre,
Je décortique ta proposition de JSON.
Si j'ai bien compris, Voisins1, c'est "en reculant" et Voisins2 c'est "en avançant" ?
Par ailleurs, dans une TJS, pour aller vers z1 en venant de z3, il suffit que A1 soit tout droit. A3 indifférent. (voir PJ)
Pour l'instant voisin1 c'est d'un côté et voisin2 de l'autre coté d'une zone, les sens est c'est à discuter (j'en ai déjà parlé précédemment). Je vais rentrer les voisins dans les zones pour le fichier json. Pour les TJS il faut que je peaufine, mais j'attends que l'on précise le nommage des "lames" (j'en ai déjà parlé aussi).
Pierre
-
Les lames :
Dans mon éditeur graphique, les lames sont les formes qui composent l'appareil de voie.
lames = 1 = AB
lames = 2 = CD
lames = 3 = AD
L'avantage, c'est que c'est extensible à n'importe quel appareil de voie, de n'importe quelle forme. Je trouve ça plus clair.
On peut très facilement avoir un tout petit fichier qui transforme la position réelle des lames réelles en un numéro de lames.
Dans le commerce, il y a quelques disparités :
Par exemple, pour une TJD en voie M chez Märklin, il n'y a qu'un seul moteur et 2 positions : le croisement droit et les 2 arcs de cercle.
Chez Peco, si on veut aller tout droit, il n'y a effectivement qu'une seule lame qui bouge, l'autre étant dans une position quelconque. C'est juste pour tourner qu'il faut préciser la position des 2 lames. C'est très proche de la SNCF.
Denis
-
@Denis
Pour la position des lames ce n est pas rigoureusement exact pour la TJD
Il y a toujours à considérer en fonction de l entrée sur la TJD et la sortie de la TJD la position des 2 "moteurs" gérant les groupes de lames.
Sinon tu risques de dérailler car avec des servo ce n est pas talonnable.
Beware donc :)
Ltr
-
Merci, je vais "bewarer" ;D
-
Bonjour
Voila une nouvelle version du fichier json, j'ai intégré les voisins dans les zones. Les TJS sont vraisemblablement fausses (toujours besoin de précision de nommage A1 c'est laquelle, A3 c'est laquelle, ...)
@ Dominique
Les choses compliquées dans les voisins sont une interprétation json des méthodes selonAiguille(Aiguille* a,Zone* z1,Zone* z2) du gestionnaire.
Pierre
-
@ Pierre
Je trouve cette version beaucoup plus claire comme ça.
Pour la TJS z3, dans le sens vois1, je comprendrai qu'elle ait comme voisins z0 et z1 et dans le sens vois2 z5 et z4
Pour la TJS z11, dans le sens vois1, je comprendrais qu'elle ait comme voisins z9 et z12 et dans le sens vois2 z0 et z1
Si je réfléchis à partir de la SNCF (et donc comme Peco), je mettrais bien pour z3:
{
"nom" : "Z3",
"sens" : "pairimpair",
"aiguilles": [
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A3"
"pos2" : "droite"
"vois1" : "Z5"
"vois2" : "Z0"
}
{
"aig1" : "A1"
"pos1" : "droite"
"vois1" : "Z5"
"vois2" : "Z1"
}
{
"aig2" : "A3"
"pos2" : "gauche"
"vois1" : "Z4"
"vois2" : "Z0"
}
]
},
Mais je ne sais pas si ça a un sens ?
Denis
-
@ Denis
Faut que cela soit décodable. Quid des cas compliqués, voir image.
Pierre
-
@ Pierre,
Pour une zone donnée, je décris les positions des différentes aiguilles de la zone, ce qui me donne, pour une position de chaque aiguille donnée, le vois1 et le vois2 suivant le sens de circulation sur la zone.
Pour une position d'aiguilles donnée d'une zone donnée, il n'y a qu'un seul chemin de vois1 à vois2.
Après, si j'ai ma gare à décrire, il ne faut pas être pressé... mais c'est facile pour une zone donnée.
Est-ce que ce que j'ai écrit est syntaxiquement correct ?
Denis
-
@ Denis
Comment tu écrit un cas compliqué comme celui de l'image que j'ai donné.
Pierre
-
Etudions le cas de la zone z0
Si on l'étudie en PRS, c'est facile, on prend les aiguilles une à une.
Sinon, on retrousse ses manches...
{
"nom" : "Z0",
"sens" : "pairimpair",
"aiguilles": [
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "gauche"
"vois1" : "Z2"
"vois2" : "Z3"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "droite"
"vois1" : "Z2"
"vois2" : "Z4"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "gauche"
"vois1" : "Z2"
"vois2" : "Z7"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "droite"
"vois1" : "Z2"
"vois2" : "Z5"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "droite"
"vois1" : "Z2"
"vois2" : "Z6"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "gauche"
"vois1" : "Z1"
"vois2" : "Z3"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "droite"
"vois1" : "Z2"
"vois2" : "Z4"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "gauche"
"vois1" : "Z1"
"vois2" : "Z7"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "droite"
"vois1" : "Z1"
"vois2" : "Z5"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "droite"
"vois1" : "Z1"
"vois2" : "Z6"
}
]
},
-
@ Denis
Oui cela a l'air équivalent, mais plus difficile à exploiter à cause des numéros, bien penser que c'est un système clé-valeur, dans ton cas il faut fabriquer les clés, on sait pas trop combien il y en a.
Une autre remarque, dans certains cas (aiguille simple par exemple) vois1 peut être simple et vois2 compliqué ou vice versa. Pour une aiguille prise en talon il n'y a qu'un voisin possible.
Pierre
-
@ Pierre
Ce qui m'embête, surtout, c'est qu'il faut décrire TOUS les cas possibles. Avec ma gare et ses 180 itinéraires, 16 TJD, 14 aiguilles, c'est pas possible : on devient fou.
En PRS, ça simplifie puisque chaque appareil de voie est une zone, mais, c'est pas facile quand même.
Denis
-
En PRS, ça simplifie puisque chaque appareil de voie est une zone, mais, c'est pas facile quand même.
En PRS, comme tu dis, on peut avoir plusieurs aiguilles dans une zone !!!
Pierre
-
Oui, bien sûr, mais plus on met d'appareils de voie dans la zone, plus on attend longtemps sa libération. On gagne des zones, mais on perd en fluidité.
Il faut équilibrer
-
@ Denis
En sur-découpant les zones on ne gagne rien en temps de libération (assez souvent on retarde volontairement la libération pour palier les micro-coupures de prise de courant des engins de traction), et on ne gagne rien en fluidité (le découpage des zones est fait de telle sorte qu'il ne puisse avoir qu'un train sur une zone, si on sur-découpe, cela reste vrai sur l'ensemble des zones issues de la découpe).
Pierre
-
@ Dominique Denis
Voila une exemple restreint de traitement d'un fichier json, pour générer automatiquement un gestionnaire.
Le programme est écrit en Java (Processing), mais serait très semblable en C++. Le programme traite le fichier json (sans test d'erreur !) et génère des objets "zone" et des objets "aiguilles". Les objets zone contiennent un codage (Java) des liens entre les zones (voisins).
Le programme (voir fichier accompagnant) comporte quatre onglets :
- un onglet qui appelle le traitement et qui affiche la liste des zones (avec le code des liens) et des aiguilles, puis qui affiche pour chaque zone les suivants réels en fonction de la position effectives des aiguilles.
- un onglet comportant deux classes : Zone et Aiguille. Ce sont des "modèles" qui seront instanciées par le traitement.
- un onglet traitement du fichier json. Il y a trois phases : le traitement des zones sans celui des voisins (infaisable pendant la première phase), une instance de "Zone" est crée pour chaque zone. La deuxième phase traite les aiguilles. La troisième phase traite des liens entre les zones. il y a deux cas, un cas simple et un cas compliqué. Le cas simple est quand le voisin ne dépend pas de la position d'aiguilles (zone sans aiguille, aiguille en talon, ...), une fonctionnelle simple est élaborée, un fonctionnelle c'est une méthode que l'on appellera dans le gestionnaire lors de son fonctionnement effectif sur le réseau pour connaitre un voisin d'une zone. Le cas compliqué est quand un voisin dépend de la position d'une ou plusieurs aiguilles, il faut transformer en objets Java la description json de la chose et élaborer une fonctionnelle(comme pour le cas simple), cette fonctionnelle ayant une forme beaucoup plus compliquée.
- le dernier onglet contient les classes Java nécessaires pour coder en Java les descriptions json des voisins dépendants d'aiguilles.
Pierre
-
@ Pierre
Ça avance drôlement ;D
Je viens de tester. Ça fonctionne, mais je ne retrouve pas tous les voisins (ou je n'ai pas compris)
z3 et z11 ont plus de 2 voisins et je ne les retrouve pas dans le test, vraisemblablement des choses à rajouter dans le JSON ?
Denis
-
Avec quoi tester ? Processing ?
-
Je viens de tester. Ça fonctionne, mais je ne retrouve pas tous les voisins (ou je n'ai pas compris)
z3 et z11 ont plus de 2 voisins et je ne les retrouve pas dans le test, vraisemblablement des choses à rajouter dans le JSON ?
Z3 a deux voisins1 et deux voisins2, cela fait 2x2 quatre voisins ?, pareil pour Z11.
Pierre
-
@Pierre
Moi, j'ai ça en sortie Je n'ai qu'une ligne pour z3
TEST
zone : Z0 voisin1 : Z3 voisin2 : Z11
zone : Z1 voisin1 : Z3 voisin2 : Z11
zone : Z2 voisin1 : Z12 voisin2 : Z4
zone : Z3 voisin1 : Z4 voisin2 : Z0
zone : Z4 voisin1 : Z3 voisin2 : Z6
zone : Z5 voisin1 : Z7 voisin2 : Z3
zone : Z6 voisin1 : Z4 voisin2 : Z8
zone : Z7 voisin1 : Z9 voisin2 : Z5
zone : Z8 voisin1 : Z5 voisin2 : Z10
zone : Z9 voisin1 : Z11 voisin2 : Z7
zone : Z10 voisin1 : Z8 voisin2 : Z12
zone : Z11 voisin1 : Z9 voisin2 : Z9
zone : Z12 voisin1 : Z10 voisin2 : Z2
-
@ Denis
Ce que tu montre ce sont les voisins en tenant compte de la position des aiguilles (toutes gauches), regarde la liste des zones il y a tous les voisins potentiels.
Pierre
-
@ Pierre
Yeah ! J'ai compris !
On a d'une part tous les cas possibles et d'autre part, les zones connectées pour une position d'aiguilles donnée.
OK, ça me va
Denis
-
@Dominique
Oui, c'est du Processing
D'ailleurs, dès que j'aurais bien compris le JSON, je ferai un "éditeur de JSON" en Processing, car je le connais "bien" et qu'on peut y gérer des questions/réponses.
Et, comme mon éditeur graphique est en Processing, je pourrais réutiliser plein de choses pour qu'il génère automatiquement le JSON (dessin -> JSON)
Denis
-
@ Pierre
Finalement, je ne comprends pas tout.
Dans tous les cas possibles, je ne vois pas ce que viens faire A4 dans Z3 ?
Par ailleurs, une TJS n'a que 3 formes possibles :
A1 à droite et, à ce moment là, on se moque de A3 = lien entre z5 et z1
A3 à gauche et, à ce moment là, on se moque de A1 = lien entre z0 et z4
A1 à gauche et A3 à droite = lien entre z5 et z0
Denis
-
@ Denis
Faut pas trop s'inquiéter, le fichier json a encore plein d'erreurs (Z3 c'est une erreur) et je n'ai toujours pas eu de réponses sur le nommage des TJS, mais je pense que pour les TJS (comme les TJD) il faut la position des deux aiguilles, à voir.
Faut plus se focaliser sur la forme du fichier json et sur son traitement.
Pierre
-
@ Denis
Faut pas trop s'inquiéter, le fichier json a encore plein d'erreurs (Z3 c'est une erreur) et je n'ai toujours pas eu de réponses sur le nommage des TJS, mais je pense que pour les TJS (comme les TJD) il faut la position des deux aiguilles, à voir.
Faut plus se focaliser sur la forme du fichier json et sur son traitement.
Pierre
Pour le nommage des TJS, nommons A5 côté z0, A7 côté z12, A3 côté z0 et A1 côté z4.
Au moment du câblage on pourra toujours permuter les fils de commande pour obtenir les chemins souhaités. N’ayant pas de TJS sous la main je propose ça comme convention pour démarrer avec les chemins donnés par Denis ci-dessus. Ce ne sera pas la seule erreur à corriger plus tard si erreur il y a. ???
(http://forum.locoduino.org/index.php?action=dlattach;topic=1645.0;attach=5628;image)
J’ai bien une TJD dans un tiroir à la maison, mais je ne suis pas chez moi .
-
Bonsoir
Pour le nommage des aiguilles je recommande cette approche:
Pour préciser qui est A1 et A3 on prend le sens de circulation anti horaire de la "V1" et on incrémente les appareils de numéros impaires au fur et a mesure de leur introduction sur la "voie principale" dans le sens de circulation nominal (le plus souvent utilisé)
Donc A1 est la première lame de la TJS (la plus à gauche) A3 celle placée à droite
L'itinéraire "voie" principale favorise toujours un positionnement des lames en position directe (non déviée) ou par prise en talon d une aiguille ( pour Vmax)
Par principe sur une voie on ne trouve pas:
- d aiguille triple (au moins en double voie et on évite en VU sauf ligne "secondaire")
- la direction "droite" d une TJS / TJD est toujours celle qui est retenue
Si la géométrie des appareils le permet on peut passer une aiguille "déviée" à une vitesse nominale (celle de la zone traversée <= vitesse max de la ligne) sinon réduite. ( et par principe réduite dans les autres cas)
Plusieurs vitesses sont possibles grâce au TIV (tableau indicateur de vitesse ex 70) sinon à la signalisation lumineuse par défaut ( Ralentissement 160, 60, 30,...)
Ici V1 avec une circulation à gauche type SNCF tourne dans le sens anti horaire.
V2 dans le sens horaire.
Certes il y aura parfois des "trous" ( ex A1 A2 A3 A5 et pas de A4) mais c est un choix assumé.
Ltr
-
@ Pierre,
J'essaie toujours de comprendre le fichier JSON.
Heureusement, dans ton programme, on a une vision plus simple du même fichier.
Moyennant une indentation et quelques couleurs je suis arrivé à l'image en PJ.
C'est beaucoup plus lisible que le fichier JSON.
Ce qui me parait étrange, c'est que, dans cette liste, puisqu'il y a des Voisin1 et Voisin2, et, donc, qu'on tient compte du sens de circulation, on devrait y voir 2 fois les zones banalisées.
Par exemple Z0->Z3•Z11 et Z0->Z11•Z3
Et pour Z11, on ne voit que Z9 et Z12 comme voisins, alors que cette zone a aussi Z0 et Z1 comme voisins.
Dans chaque zone, il faut la liste de tous les voisins.
En particulier, il y a 3 positions pour une TJS : (A1 droite), (A3 droite), (A1gauche et A3 gauche)
Le problème ne vient pas de ton programme, qui fonctionne, mais du fichier JSON originel.
Ou alors, il n'y a pas de problème et c'est moi qui n'ai pas compris.
Mais j'ai besoin de bien comprendre le JSON pour pouvoir faire un éditeur
Merci d'avance.
Denis
-
J'ai la même chose semble-t-il avec Processing4
Aigs [A1, A2, A3, A4, A5, A6]
Zones [
Z0->Z3•Z11,
Z1->Z3•Z11,
Z2->Z12•Z4,
Z3->[Z5_si_[A1=droite, A3=droite],
Z4_si_[A1=gauche, A3=gauche]]•[Z1_si_[A4=droite, A3=droite],
Z0_si_[A1=gauche, A5=gauche]],
Z4->[Z2_si_[A2=droite],
Z3_si_[A2=gauche]]•Z6, Z5->Z7•Z3,
Z6->Z4•Z8,
Z7->Z9•Z5,
Z8->Z5•Z10,
Z9->Z11•Z7,
Z10->Z8•Z12,
Z11->[Z9_si_[A5=gauche, A6=gauche],
Z12_si_[A5=droite, A6=droite]]•[Z9_si_[A5=gauche, A6=gauche],
Z12_si_[A5=droite, A6=droite]],
Z12->Z10•[Z2_si_[A4=gauche], Z11_si_[A4=droite]]]
TEST
zone : Z0 voisin1 : Z3 voisin2 : Z11
zone : Z1 voisin1 : Z3 voisin2 : Z11
zone : Z2 voisin1 : Z12 voisin2 : Z4
zone : Z3 voisin1 : Z4 voisin2 : Z0
zone : Z4 voisin1 : Z3 voisin2 : Z6
zone : Z5 voisin1 : Z7 voisin2 : Z3
zone : Z6 voisin1 : Z4 voisin2 : Z8
zone : Z7 voisin1 : Z9 voisin2 : Z5
zone : Z8 voisin1 : Z5 voisin2 : Z10
zone : Z9 voisin1 : Z11 voisin2 : Z7
zone : Z10 voisin1 : Z8 voisin2 : Z12
zone : Z11 voisin1 : Z9 voisin2 : Z9
zone : Z12 voisin1 : Z10 voisin2 : Z2
-
@ Denis
Le fichier jison c'est juste un exemple, inspiré du locoduinodrome, montrant des possibilités d'écriture. Cela ne présage en rien du format json qui sera adopté, notamment pour les voisins qui ne peuvent pas rester comme cela.
Le fichier est aussi une base pour des essais de transformations vers un gestionnaire.
Les erreurs n'ont pas d'importance, mais j'essaierai de les éliminer peu à peu.
Pierre
-
Y'a un problème avec votre définition :
Certes ça décrit le circuit mais c'est inutilisable tel quel par un gestionnaire.
L'important pour le gestionnaire c'est comment aller d'un signal au suivant, c'est à dire la liste des zones
à traverser ainsi que la liste des aiguillages avec leur position droite ou déviée pour ce trajet.
A partir de vos définitions il faut faire une recherche du genre prévoir 5 coups d'avance aux échecs.
D'une part c'est long, surtout sur un grand réseau, et avec nos circuits ça peut virer à la boucle infinie.
Donc la définition des connexions entre zones doit se faire dans la définition des cantons. (un canton étant la voie entre deux signaux consécutifs)
Autrement dit :
-Pour les zones il faut seulement le nom et l'adresse du capteur de courant.
-Pour les aiguilles, il faut le nom, droite/gauche et l'adresse dcc du décodeur.
-Pour les signaux, il faut le type de cible,la zone précédente et suivante et l'adresse dcc du décodeur.
Et enfin il faut définir les cantons :
-nom, zone de départ,signal entrée, signal sortie,zones traversées dans l'ordre, adresse capteur zone d'arrêt, aiguillages avec position déviée ou non,type de canton normal/manoeuvre ou tout,vitesse limite
exemple :
z3,408
a2,g,205
sig1,b,z0,z3,317
sig5,a,z6,z8,314
Can1,z0,sig1,sig5,z3,z4,z6,604,a1-,a3-,a2<,n,60
En utilisant la première lettre des noms comme signification du type le gestionnaire s'y retrouve facilement et le fichier texte ou json est assez explicite.
-
Bonjour
J'ai fait une version un peu plus simple du programme qui transforme le fichier json en un gestionnaire, je peux le publier si besoin. cette version utilise des "lambda expression" appelées aussi fermetures ou clôtures.
Plus intéressant j'ai essayé une version complètement différente de la précédente. Le fichier json est lu ce qui donne un objet json recélant toutes les infos pour le gestionnaire. C'est cet objet json qui va mémoriser toutes les constantes : noms des zones et des aiguilles, sens de zones, types de aiguilles ... et les variables : l'état ("libre" ou "occupe") des zones, l'état "("gauche" ou "droite") des aiguilles, ... Les infos fournies par les capteurs pourront mettre à jour ces variables.
L'avantage de cette version est qu'il n'y a plus d'objets à créer, donc plus de programmation objet.
L'inconvénient est que l'exécution est nettement plus lente, Mais elle peut être accélérée en transformant un peu l'objet json issu de la lecture, par exemple en donnant des numéros aux zones et aux aiguilles et en y accédant non plus par leur noms (clés) mais par les numéros (indiçeage des tableaux). D'autre accélérations sont possibles, mais ce sera toujours plus lent que la première version.
Le programme Processing est téléchargeable ci-dessous. Il fait pratiquement la même chose que la première version.
Pierre
-
(...)
- un seul train par canton,
- des signaux positionnés selon ces règles (sémaphores, carrés, avec ralentissement, etc..),
- des commandes des trains pour le respect des ralentissements et arrêts selon la signalisation,
- des détecteurs de présence et/ou d'identification(RFID, RailCom) des trains par canton, zone, aiguille, etc.
(...)
Dominique
Bonjour ,
je n'ai encore rien lu , ça viendra , mais je souhaite (re)(re)préciser mon point de vue concernant les signaux :
en modélisme , ils n'ont aucune influence sur la marche des trains , c'est des éléments de décor , que l'on s'efforce d'animer avec réalisme , mais ce n'est absolument pas obligatoire
les trains n'agissent pas selon la signalisation , mais obéissent à l'automate , lui-même en fonction des ordres et de la situation du réseau
-
@Pierre
J'ai fait un premier essai très simple pour créer les zones simples en JSON à partir de rien.
Pour l'instant on peut rentrer n'importe quoi comme texte. Il faut bien un début.
Il faut ouvrir dans le bloc notes.
Denis
-
petit essai :
Colonne
{
"zones" : [
{
"nom" : "Z1",
"sens" : "Pair",
"vois1" : "Z2",
"vois2" : "Z3",
}
]
}
c'est bien parti ! Courage ::)
-
@ Etienne
Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr :P
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?
Denis
Tu as raison.
ben non , gauche/droite est clair pour toutes les aiguilles , y compris les symétriques
-
(...)
D'accord pour la position par défaut et la vitesse.
Pour les moteurs c'est plus un problème à régler au niveau du décodeur. Et il suffit d'une temposisation entre le moment où
on change les aiguilles et l'ouverture du signal pour tenir compte des moteurs lents.
suffit pas : si tu fais une commande segmentée des moteurs , il faut (tout simplement) attendre le moment où le dernier moteur a terminé sa course
-
(...)
Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.
Pierre
amha , on n'est pas obligé ... mois je le fais ... le petit inconvénient , si on a des moteurs lents commandés à tour de rôle , cela rallonge le temps de formation de l'itinéraire ...
-
Avec loconet et autres on n'a que le sens retrosignalisation. L'autre sens doit passer par la voie avec la limite de débit que ça impose.
Le CAN étant bidirectionnel il s'impose comme la solution idéale.
à priori non , les messages de commande transitent par loconet , donc ils peuvent être utilisés par les décodeurs ; cela a d'ailleurs été vendu comme moyen d'alléger le traffic des packets dans le DCC
(en réalité cela passe effectivement , très généralement , dans le DCC , la bande passante n'étant critique que pour les très grands réseaux ... ou pour les réseaux les + automatisés)
-
@ Denis
Je t'ai fabriqué un "dialogue" sur mesure pour les zones. Il permet de saisir les noms de zones, les sens et les voisins. Pour les sens il n'y a que deux choix possibles (pour l'instant), pour le reste on peut saisir un nom de zone ou choisir parmi celles qui sont déjà saisies pour les modifier, les compléter, les supprimer, .... Pour les voisins "cas" devra pouvoir saisir un nom de zone et une liste de paires (aiguille,position).
Pour l'instant les modifications s'affichent dans la console.
Pierre
-
@ Pierre,
Merci pour ce programme bien sympa.
@tous
Je suis en train de développer un petit programme qui doit permettre de rentrer les données JSON sans erreurs, avec vérifications et avec un peu de graphiques très simples qui permettrons d'éviter les erreur de saisie.
Je ne suis pas vraiment dispo avant mardi.
Je propose qu'on arrête (pour un temps) de parler de la phase avant JSON et qu'on s'intéresse à l'après JSON en partant d'un JSON supposé parfait.
Terminologies :
Je propose d'employer TD pour tout droit et DV pour dévié.
Pour les aiguilles enroulées, TD sera la voie à grand rayon et DV celle à petit rayon
J'appelle AB la première diagonale d'une TJD (TJS, croisement) et CD la deuxième diagonale pour les TD
J'appelle AD et CB les deux courbes d'une TJD (en DV)
Pour une aiguille simple, AB pour TD et AC pour DV
Pour un triple, AB pour TD et AC pour la gauche et AD pour la droite
Je ferai le JSON avec, en plus, les données vitesses limites.
Dans les zones, cela correspondra aux TIV, pour les aiguilles, sur voie DV (30, 60 et 160)
Je ne sais pas s'il y a des limites de vitesse en TD sur TJD.
Je propose de mettre "banalise" au lieu de "pairimpair"
Je sortirai deux ArrayList "Zones" et "Aiguilles" et, éventuellement, un 3ème ArrayList pour les connecteurs, si c'est utile.
Denis
-
Terminologies :
Je propose d'employer TD pour tout droit et DV pour dévié.
Pour les aiguilles enroulées, TD sera la voie à grand rayon et DV celle à petit rayon
gauche/droite cela marche des tous les cas
J'appelle AB la première diagonale d'une TJD (TJS, croisement) et CD la deuxième diagonale pour les TD
J'appelle AD et CB les deux courbes d'une TJD (en DV)
Pour une aiguille simple, AB pour TD et AC pour DV
Pour un triple, AB pour TD et AC pour la gauche et AD pour la droite
je vois pas trop l'utilité dans le fichier json
Je ferai le JSON avec, en plus, les données vitesses limites.
Dans les zones, cela correspondra aux TIV, pour les aiguilles, sur voie DV (30, 60 et 160)
Je ne sais pas s'il y a des limites de vitesse en TD sur TJD.
oui on peut associer des vitesses, mais où les mettre, ce n'est pas urgent
Je propose de mettre "banalise" au lieu de "pairimpair"
pourquoi pas mais dans mon esprit il pourra avoir des variantes avec les manoeuvres , du
genre pair_et_impair_manoeuvre
Je sortirai deux ArrayList "Zones" et "Aiguilles" et, éventuellement, un 3ème ArrayList pour les connecteurs, si c'est utile.
dans mon esprit les voisins sont les connecteurs, mais à revoir
Pierre
-
@ Pierre,
Ou là... Non, je ne change rien au JSON.
Et je ne connaissais pas pair_et_impair_manoeuvre. On garde donc pairimpair.
Non, ce que je voulais simplement, c'est pour faciliter les posts.
Mais on ne change pas le JSON.
Denis
-
Bonjour à tous,
Voici une version plus évoluée de mon éditeur de fichier JSON pour les trains.
Je suis parti de l'idée que plutôt que de rentrer les données très rapidement et de corriger les erreurs après, il valait mieux prendre un peu plus de temps et bien se mettre en situation pour pouvoir valider en ayant une vue claire de ce qu'on fait.
En particulier, je ne rentre pas directement pair ou impair. J'utilise une méthode "visuelle".
Pour l'instant, ça ne rentre que les zones simples, mais je vais m'occuper des aiguilles très rapidement.
Il manque encore la vérification qu'on n'a pas déjà rentré une zone, de vérifier que si voisin1 = voisin2, c'est que c'est une boucle de retournement et deux – trois bricoles.
Dans les data, il y a le JSON, qu'on peut ouvrir simplement avec le bloc note.
Denis
-
@ Denis
Je t'avais promis une version, avec des dialogues, plus élaborée. C'est en fait un peu une boite à outils pour faire des dialogues. Il y a deux sortes de champs de saisie, un champ avec des choix multiples prédéfinis et un champ avec en plus une possibilité d'édition (si les choix prédéfinis ne conviennent pas).
Plusieurs dialogues permettent de saisir des zones, des aiguilles ou des signaux avec des paramètres. Ce sont des dialogues dits "modal", un seul dialogue n'est affiché à la fois, mais on pourrait en afficher plusieurs à la fois.
Les dialogues comportent une série de boutons, pour l'instant deux seulement sont actifs, un bouton "X" qui ferme le dialogue, puis le dialogue suivant est affiché, et un bouton "S" qui affiche dans la console le code json fabriqué par le dialogue.
Cela montre juste ce que l'on peut faire avec les dialogues, toute la partie édition globale du fichier json est absente.
Les champs de saisie des voisins (1 et 2) des zones sont assez particuliers, on peut utiliser un nom de zone déjà existante ou saisir un nouveau nom. Mais si le "nom" de la zone est déjà renseigné et que l'on a choisi "cas" pour le voisin, un coup de molette (wheel) sur le champ fait apparaitre un nouveau dialogue pour saisir des voisins conditionnels (suivant la position d'aiguilles).
Le programme ne fonctionne qu'avec Processing 4.
Pierre
-
@Pierre,
Merci, je vais décortiquer ton programme.
@tous,
J'ai oublié de dire une chose essentielle dans mon programme : il faut décaler la fenêtre qui s'ouvre pour voir les dialogues derrière !
D'habitude, les dialogues sont au premier plan, mais pas là.
Donc, la première fois qu'on lance le programme, il faut décaler la fenêtre qui s'ouvre (par exemple à gauche) et ainsi voir les questions posées qui, elles sont toujours au milieu.
Après, plus besoin de décaler le fenêtre, elle s'ouvre au bon endroit et on voit les dialogues.
Denis
-
Bonjour à tous,
J'ai bien avancé sur l'éditeur JSON.
On peut maintenant rentrer tous les segments et les appareils de voie.
C'est à base de schémas qui permettent de se représenter la situation des différents éléments, avec leur orientation.
On évite ainsi de savoir si on est dans le sens "pair" ou "impair" et de se tourdre le cou et de se représenter avec les doigts ;D pour savoir si c'est "gauche" ou "droite".
Je ferai, évidemment, la modification pour que "0" s'écrive "gauche" et "1" s'écrive "droite".
De même, je n'ai pas (encore) donné de "sens" aux appareils de voie car il y a des situations ambigües (j'ai des exemples).
Ce sera automatique, par consultation des éléments simples voisins, de proche en proche :
Exemple, sur le Locoduinodrome :
Z4 a comme voisins Z6 (pair), Z2 (pair) et Z3 (banalisé, donc, entre autres, pair) => Z4 est pair
Z3 a comme voisins Z5 (impair), Z1 (impair), Z4 qu'on vient de définir pair et Z0 (banalisé) => Z3 banalisé
Par ailleurs, grâce aux schémas, on doit faire moins d'erreurs de saisie et je vais ajouter des couleurs dans les cases des voisins :
Vert : on retrouve bien la zone voisine dans les zones déjà saisies et chacune est voisine de l'autre.
Orange : on ne retrouve pas (encore) la zone saisie comme voisine dans les zones existantes
Rouge : on retrouve bien la zone saisie dans les zones existantes, mais pas avec une parité compatible (pair d'un côté et impair de l'autre)
Par contre, là, j'ai vraiment besoin de savoir comment on rentre une tjd, une tjs et ... un croisement (l'éternel vilain canard :() dans le JSON. J'ai mis quelque chose, mais je ne suis pas sûr de moi.
Denis
PS : Il faut décaler l'image pour voir les questions. Ça m'embête aussi
-
Bonjour Denis,
Aurais-tu le mode d'emploi de cet éditeur ?
Merci d'avance
-
Bonjour à tous,
Voilà le mode d'emploi.
Denis
-
Par contre, là, j'ai vraiment besoin de savoir comment on rentre une tjd, une tjs et ... un croisement (l'éternel vilain canard :() dans le JSON. J'ai mis quelque chose, mais je ne suis pas sûr de moi.
Pour une TJD ou une TJS on met deux aiguilles (il y a deux noms de prévu), pour un croisement je le considère comme une aiguille sans moteur (c'est utile si on veut des tracés d'itinéraires continus).
Pierre
-
@ Pierre,
Peux-tu me donner un JSON avec juste une TJD et un autre avec juste une TJS ?
Pour la TJS, on n'avait que droite-droite et gauche-gauche, mais pas droite-gauche. Comment tu la rentres ?
Denis
-
@ Denis
Une tjd ou une tjs c'est équivalent à deux aiguilles en pointe, voila pour la tjs A1-A3 :
{
"nom" : "A1",
"type" : "tjs"
},
{
"nom" : "A2",
"type" : "droite"
},
{
"nom" : "A3",
"type" : "tjs"
},
Les "type" sont des commentaires.
Pierre
-
Bonjour à tous,
Je suis très intéressé de voir le résultat de ces opérations : création/modification du fichier JSON de description du réseau avec une application (Denis offre la première appli sous Processing), puis importation du fichier JSON dans le gestionnaire de référence (non personnalisé que je suppose être celui de Pierre59 décrit dans les articles 154, 167, 172 te 184) pour obtenir un gestionnaire entièrement paramètre dans lequel il faut intégrer la gestion des capteurs et actionneurs.
De mon coté, j'avais fait le paramètrage "à la main" du gestionnaire de mon réseau (avec un peu d'aide de Pierre que je remercie).
J'ai développé et utilisé divers outils de mise au point de ce paramètrage, dont surtout une représentation graphique de mon réseau dans le même Arduino Due équipé d'un écran 5".
Evidemment, je vais faire l'exercice sur mon réseau pour appliquer ce qui sera fait sur le locoduinodrome 2.
Mais en attendant je veux conserver la représentation graphique de mon réseau qui sera déportée cette fois-ci, via le bus Can, sur une carte graphique de 7 pouces équipés d'un Teensy3.6 et du Can. Cette carte est bien plus rapide que le Due.
Vous avez compris que je ne veux pas de PC sur mon réseau et Processing dans un RPi n'est pas aussi cool que mon projet.
Pour ce faire, j'ai dupliqué la liste des objets aiguilles et zones de mon gestionnaire et écrit les méthodes graphiques à partir de simples tracés de rectangles (pour les lignes horizontales et verticales) et d'arcs pour les courbes.
Cela donne les images ci-dessous. Le programme permet aussi de commander les aiguilles et les itinéraires par un simple clic sur celles-ci, avec envoi par Can des commandes au gestionnaire, qui commande les affichages (occupations, libérations, affichage du suivi des trains) sur ce TCO. Il manque encore pas mal de choses à faire comme les signaux et diverses commandes et affichage, façon Méru par exemple.
Mon idée est de rapprocher ce système de ce projet de gestionnaire.
-
@ Pierre,
J'ai compris ce qui me chagrinais dans la première version du JSON.
Comme d'habitude, chez moi, c'est en essayant de régler un cas très complexe que j'ai trouvé la solution (je pense)
(https://www.locoduino.org/local/cache-vignettes/L150xH67/zone_multiple-923e5-f08da.png?1706604389)
L'idée c'est d'ajouter une variable "forme" dans la class "Zone"
Là, il y a 10 formes (AC, AD, AE, AF, AG, BC, BD, BE, BF, BG)
Un segment, c'est 1 forme
Un croisement, c'est 2 formes, comme une aiguille, un enroulé
Un triple, c'est 3 formes, comme une TJS
Une TJD, c'est 4 formes.
Par ailleurs, on décrit un voisin1 comme étant l'origine de la description, et voisin2 comme étant l'extrémité de la description.
On décrit donc, dans le sens correspondant à la parité, voisin1 -> la zone -> voisin2
Si c'est une zone banalisée, on décrit dans un sens, mais on indique que ça peut être pris dans les 2 sens lors de la définition de la parité.
On décrit forme par forme.
Il n'y a ainsi aucune ambiguïté pour définir voisin1 et voisin2 et on donne la liste des aiguilles considérées avec leurs positions pour chaque forme.
Et c'est applicable partout.
Je vais adapter mon éditeur JSON à cette nouvelle vision des choses.
Denis
-
@ Denis et autres
Plutôt que le terme "forme" je préfèrerais le terme "trajet" (ou autre : parcours, ... idées ???).
Je suis assez d'accord avec toi, j'ai déjà envisagé très sérieusement des demi-trajets (demi-formes), à partir du "centre" de la zone, dans l'exemple complexe du dessin c'est le centre de la tjd. Les demi-trajets simplifient un peu le nombre de cas, les trajets donnent 10 cas, tandis que les demi-trajets donnent 2+5=7 cas (2 pour la partie gauche et 5 pour la partie droite), 2*5 donne bien les dix cas réels. Bon dans les cas les plus courants de zones on n'a pas une telle complexité.
Ce qu'il faut regarder, pour choisir, c'est les appareils de voie à problèmes : tjd, tjs et croisement.
Ce qu'il faut regarder, aussi et surtout, c'est l'usage que l'on fera avec ces trajets : suivi des trains, recherche automatique des suivants et précédents des signaux et j'en oublie certainement.
Il faut aussi trouver un codage json qui soit facilement utilisable par le gestionnaire.
Il faut en discuter, pour choisir le meilleur cas.
Pierre
-
Voila une base pour vos propositions, les zones voisines sont toutes nommées.
Pierre
-
@ Pierre,
C'est ce que je proposais dans un post et dans mon programme. Pourquoi "E" pour le triple ?
Je suis OK pour le terme "trajet" car on peut dire "trajets" et "trajet", ce qui n'est pas le cas de "parcours" ;)
Je propose, pour les trajets de Z3 :
"trajets" : [
{
"trajet" : "AB",
"voisin1" : "Z5",
"voisin2" : "Z1",
"aigs" : [
{
"aig" : "A1",
"pos" : "droite"
},
{
"aig" : "A3",
"pos" : "droite"
}
]
},
{
"trajet" : "AD",
"voisin1" : "Z5",
"voisin2" : "Z0",
"aigs" : [
{
"aig" : "A1",
"pos" : "droite"
},
{
"aig" : "A3",
"pos" : "gauche"
}
]
},
{
"trajet" : "CD",
"voisin1" : "Z4",
"voisin2" : "Z0",
"aigs" : [
{
"aig" : "A1",
"pos" : "gauche"
},
{
"aig" : "A3",
"pos" : "gauche"
}
]
}
]
Denis
-
Voila ma proposition pour des demi-trajets (à mettre dans le json des zones), A0 est l'aiguille simple, A0 et A1 sont les aiguilles doubles :
"vois1":"ZA",
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]] // droite pointe
"vois1":[["ZA","A0","droite"],["ZC","A0","gauche"]], // droite talon
"vois2":"ZB"
"vois1":"ZA",
"vois2":[["ZB","A0","gauche","A1","droite"],["ZD","A0","droite"],["ZE","A0","gauche","A1","gauche"]] // triple modele Peco
"vois1":[["ZA","A1","gauche"],["ZC","A1","droite"]] // tjd
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]]
"vois1":[[NULL,"A0","droite","A1","gauche"],["ZA","A1","droite"],["ZC","A1","gauche"]] // tjs
"vois2":[[NULL,"A0","droite","A1","gauche"],["ZB","A0","droite"],["ZD","A0","gauche"]]
"vois1":[["ZA","A0","gauche"],["ZC","A0","droite"]], // croisement (vu comme une aiguille sans moteur)
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]]
La tjs est un peu délicate, il faut éliminer un cas.
Pour les tracés continu des itinéraires il est utile de considérer le croisement comme une aiguille (sans moteur)
Il peut rester des erreurs !
Pierre
-
@ Pierre,
J'ai beaucoup de mal à comprendre les demi-trajets pour les appareils de voie à base de croisements.
Il faut imaginer un point fictif, partir de ce point et ne parler que d'une aiguille alors qu'il en a deux...
Les trajets complets sont peut-être un peu plus lourds, mais nettement plus simples à imaginer.
Par ailleurs, cette nouvelle notation est beaucoup plus compacte (plus d'accolades), mais j'imagine qu'il faut en mettre, comme avant ?
Denis
-
Avec des demi-trajets, j'ai peur que cela devienne plus compliqué que l'avantage à en déduire.
Mais je n'ai sans doute pas encore bien compris pour le moment.
Et l'application éditeur de JSON nécessite un dessin du réseau au préalable.
-
J'ai beaucoup de mal à comprendre les demi-trajets pour les appareils de voie à base de croisements.
Il faut imaginer un point fictif, partir de ce point et ne parler que d'une aiguille alors qu'il en a deux...
Le point fictif c'est le centre du croisement, et l'aiguille fictive sert à sélectionner les bons demi-trajets
Les trajets complets sont peut-être un peu plus lourds, mais nettement plus simples à imaginer.
Les trajets sont à mettre dans le json des zones, on ne peut rien faire de clés genre "AB" sauf comme commentaires, il va falloir aussi structurer pour faciliter le traitement par le gestionnaire
Par ailleurs, cette nouvelle notation est beaucoup plus compacte (plus d'accolades), mais j'imagine qu'il faut en mettre, comme avant ?
Non c'est exactement le json qui est utilisé pour le gestionnaire
Pierre
-
@ tous,
Sans faire les modifs du JSON (pour l'instant), j'ai corrigé quelques bugs signalés par Dominique.
Voici la nouvelle version, normalement plus ergonomique. Il reste les bugs avec les fenêtres qui ne sont pas toujours au 1er plan (mais je n'ai pas la solution...)
Denis
-
@ Pierre,
Voici une autre proposition, en exemple, pour Z3 et Z4:
"Zone": [
[
"nom" : "Z3",
"sens" : "banalise",
"trajets" : [["Z5","Z1",["A1","droite","A3","droite"]
["Z5","Z0",["A1","droite","A3","gauche"]
["Z4","Z0",["A1","gauche","A3","gauche"]]
]
[ "nom" : "Z4",
"sens" : "pair",
"trajets" : [["Z3","Z6",["A2","gauche"]
["Z2","Z6",["A2","droite"]]
]
]
Denis
-
@ Pierre et autres
L'éditeur JSON qui rentre les segments et les appareils de voie peut permettre de rentrer n'importe quelle zone.
(https://www.locoduino.org/local/cache-vignettes/L150xH67/zone_multiple-2-787ef-fc6a2.png?1706696048)
Si on découpe la zone complexe en morceaux ("pavés"), en utilisant un caractère spécial "/", on a Z1/1, Z1/2, Z1/3, Z1/4, Z1/5.
Chaque zone est décrite comme une autres (les voisins de Z1/3 sont Z1/1 et Z1/4)
Et, à la fin, on regroupe automatiquement tous les morceaux en une seule zone avec les (AC, AD, AE, AF, AG, BC, BD, BE, BF, BG) comme trajets de la zone.
Par ailleurs, dans un trajet, on met ["origine", "extrémité", ["aiguille","position"], ..., ["aiguille","position"] ], avec de zéro (pour les segments et les croisements) à "n" ["aiguille","position"] suivant la complexité de la zone.
Denis
-
Bonjour
Depuis quelques temps j'essaie de voir les avantages et les inconvénients des "trajets" et des "demi-trajets". Pour cela je vous joins des extraits json du Locoduinodrome dans les deux cas, c'est une partie caractéristique des zones (la version "trajet" est issue de Denis). Je joins aussi le dessin du Locoduinodrome.
Il faut aussi s'intéresser à la facilité des opérations courantes du gestionnaire :
- obtention de la zone voisine d'une zone donnée (d'un coté ou de l'autre) en fonction de la position réelle des aiguilles
- positionnement des aiguilles pour un itinéraire donné par une liste de zones (traité dans un sens ou dans l'autre), un itinéraire est proposé
- recherche automatique des précédents et suivants des signaux
- obtention de toutes les zones voisines d'une zone donnée (d'un coté ou de l'autre)
- autres ?
Pierre
-
Quelques éléments de réflexion :
1°) Quelle que soit la méthode employée, on va devoir afficher des formes (que ce soit pour les segments ou les appareils de voie) pour les itinéraires. J'ai bien dit "formes".
2°) Pour les appareils de voie, une seule et unique forme sera affichée dans un itinéraire.
3°) Il faut donc une fonction qui, pour un appareil de voie donné, affiche une seule forme, fonction de la position des lames.
Z3 :
A2 droit + A3 droit -> forme 0
A2 gauche + A3 gauche -> forme 1
A2 droit + A3 gauche -> forme 2
4°) Je ne veux pas rentrer quelque part la suite de zones des 180 itinéraires de ma gare.
Donc, il faut une fonction qui trouve cette suite toute seule, une fois l'origine et la fin de l'itinéraire donnés.
5°) Pour connaitre la zone suivante, dans les 2 sens, j'utilise la méthode suivante :
Au fur et à mesure de la lecture du fichier JSON, je crée une ArrayList des connecteurs.
Un connecteur c'est un point à la limite de 2 formes et, donc, de 2 zones :
ID, Zx, forme Nx, cote_x de la forme (0 ou 1) , Zy, forme Ny, cote_y de la forme (0 ou 1)
Par ailleurs, au fur et à mesure de la lecture du fichier JSON, je mets à jour, dans Zones,
une variable ligne_connecteur[a1][b1].
a1 = n° de la forme et b1 = coté de la forme (0 ou 1)
Pour dessiner un itinéraire, on part d'un connecteur, du coté de l'avant du train (la loco ou le dernier wagon). Ça nous donne la zone d'origine et le coté origine.
En balayant l'ArrayList des connecteurs, côté Zx ou Zy, je trouve le connecteur origine.
Si c'est Zx, la zone suivante, c'est Zy, et réciproquement.
Supposons qu'on ait Zx. On va chercher dans la même ligne du connecteur Zy, avec le cote_y de la forme y
On va dans Zone y et on cherche ligne_connecteur[forme y][1-cote_y]
On va dans les connecteurs, directement à la ligne indiquée, et y cherche Zy (à gauche ou à droite).
Et on recommence.
Il n'y a qu'un seul balayage, au début, puis on suit par adressage direct. Et ça marche pour la signalisation et les itinéraires et dans les 2 sens.
Denis
-
@ Denis
Pour les points 1 2 3, je ne comprend pas, je ne vois pas ce que c'est une "forme".
Pour le point 4, pour éviter de coder 180 itinéraires, on sait faire des algos récursifs qui fournissent tous les itinéraires possibles, après faut faire un choix, on a déjà parlé de ces problèmes il y a un bon bout de temps. L'algo a juste besoin de tous les voisins des zones (avec les positions d'aiguilles associées).
Pour le point 5, dans le gestionnaire le fichier json est lu d'un coup pour produire un objet json, il faut donc aller dans cet objet json pour avoir les voisins d'une zone, c'est assez facile.
Pierre
-
@ Pierre,
Une forme, c'est le dessin d'un segment de droite, d'un arc de cercle, un arc de parabole (dans mon nouvel éditeur graphique).
Pour dessiner une aiguille, il faut dessiner 2 formes : un segment de droite et arc de cercle.
Toutes les formes sont noires et une seule forme est grise, fonction de la position des lames.
Sur le point 5, je ne demande qu'à voir, ça me parait très intéressant. ;D
Denis
-
@ Pierre
Si je suis les règles que tu as édicté pour les tjs le 30/01, j'obtiens le fichier PierreJson2.xtx joint.
Je me trompe ?
Denis
-
@ Denis
La notation [[NULL,"A3","droite","A1","gauche"], c'était juste un idée comme cela, pas forcement réaliste.
Dans le cadre du gestionnaire je suis en train de regarder les algos utilisants les voisins.
Pour le suivi des trains on a besoin des deux voisins (en fonction de la position des aiguilles), c'est un cas qui arrive très souvent quand une zone devient occupée.
Pour les itinéraires (prédéfinis ou automatiques) on a besoin des tous les voisins et en plus du "sens" des zones. C'est un cas qui arrive souvent.
Pour trouver automatiquement les précédents et les suivants des signaux, les besoins sont à peu près les mêmes que pour les itinéraires. Ce cas ne se fait qu'une fois (dans le gestionnaire ou dans l'éditeur).
Autres cas ?
Pierre
-
@ Pierre,
OK pour tes remarques, sauf la dernière : pour moi, le "signal suivant" dépend de la position des aiguilles et on ne peut pas le faire dans l'éditeur, sauf en pleine voie.
A part ça, j'ai une notion des itinéraires qui est une version SNCF "élargie", c'est à dire que, quand un train se déplace, il est toujours sur un itinéraire, indépendamment des gares, etc...
Il y a 2 types d'itinéraires :
- les itinéraires "bouclés", c'est à dire qu'ils tournent indéfiniment, jusqu'à ce qu'on les arrête.
- les itinéraires "à la demande" qui vont de la position actuelle du train (connecteur, sens) vers une destination choisie (connecteur, sens). Le train s'arrête quand il a atteint sa destination. On peut (et on doit) alors lui en reprogrammer une autre pour qu'il reparte.
Pour moi, on n'a pas de "bouton" (réel ou virtuel) qui modifie la position d'une aiguille. On n'a donc pas à gérer tout un tas d'enclenchements.
Les itinéraires sont enregistrés, de façon tout à fait indépendante de la position actuelle des aiguilles, des signaux actuels, des occupations actuelles...
On veut aller de là à là, quand ce sera possible, en toute sécurité. Il y a donc des zones "occupées par un itinéraire", mais physiquement vides.
Si le train est arrêté pour des raisons de sécurité, les zones aval ne sont pas (encore) occupées par un itinéraire. Ça se fait au fur et à mesure.
Par ailleurs, un itinéraire est donc une suite orientée de zones, elles aussi orientées une par une.
On peut construire l'itinéraire "par morceaux", c'est à dire qu'on part d'une gare, par exemple, et on demande un itinéraire pour une autre gare, avec une durée d'arrêt choisie dans cette gare intermédiaire. Puis on "ajoute", un autre itinéraire vers une autre gare où, par exemple, on ne s'arrête pas et, enfin, un troisième morceau vers une gare de destination où on s'arrête définitivement. Pour moi, tout ça, c'est UN itinéraire.
Si on entre, pour chaque zone, la longueur de la zone, on peut savoir à quelle distance réelle on est du signal suivant et en tenir compte dans les ralentissements.
En particulier, on peut connaître, pour un itinéraire donné, quel est le prochain feu S ou C et caler le ralentissement non pas sur le A, mais sur le S ou le C, ce que fait un conducteur quand il aperçoit un A.
Denis
-
Bonjour à tous,
Je procède actuellement à une refonte complète de mon éditeur pour pouvoir ajouter et supprimer des questions facilement. Le fonctionnement global sera identique.
Laissez moi quelques jours ;)
@Pierre,
J'ai compris la description du réseau par 1/2 trajets. Mais je ne vois pas de gain, pour l'instant, à mon niveau. Mais pourquoi pas ?
Denis
-
Bonjour
J'ai fait quelques essais de gestionnaire paramètré complètement par un fichier json, dans une version sans programmation objet.
Pour tester un gestionnaire il faut soit un réseau, genre Locoduinodrome, que je n'ai pas, soit un simulateur de réseau. Pour gagner du temps j'ai réutilisé le programme du TCO de l'ancien Locoduinodrome, ce programme fait le dessin du TCO du réseau avec les mises à jour dues aux circulations de trains virtuels, il comporte aussi deux manettes, avec cabsignal, pour commander les trains.
Le gestionnaire communique avec le TCO avec le protocole réseau TCP/IP. Il faut lancer le TCO avant le gestionnaire. Les deux programmes sur la même machine sinon il faut jouer sur l'adresse IP du gestionnaire.
Comme le TCO est prévu pour l'ancien Locoduinodrome, j'ai du écrire le fichier json le décrivant complètement. Le fichier json ne doit pas être vu comme un modèle, il y des redondances (noms), des infos pour des tests ...
Le fichier json est lu entièrement au début du gestionnaire et les variables nécessaires au fonctionnement du gestionnaire (états des zones, positions d'aiguilles, feu de signaux, ...) sont rajoutées automatiquement dans le json au début du programme. Ce qui veut dire que l'état du réseau est quasiment entièrement codé par le json.
Le gestionnaire est essentiellement composé de fonctions qui traitent les différents cas pouvant arriver sur les différents éléments du réseau (zones, aiguillages, signaux, itinéraires, trains, balises, ...)
Ces fonctions doivent traiter tous les cas possibles, elles sont donc moins performantes que des fonctions spécialisées (écriture à la main et/ou programmation objet).
Le gestionnaire comporte deux fichiers json (onglets Z1 et Z2), celui de l'ancien locoduinodrome et celui du nouveau (incomplet). Les deux onglets me servent d'éditeur pour les fichiers json, pour l'instant.
Le gestionnaire a été écrit à l'arrache, c'est juste pour voir si c'est possible. Quand j'aurais un peu de temps j'essairai d'améliorer le gestionnaire et de corriger des bugs, et quand j'aurais beaucoup de temps je retoucherais le TCO pour utiliser le nouveau locoduinodrome et faire des test plus poussés.
Il y a d'autres façons de faire un gestionnaire paramètré par un fichier json, ne pas hésiter à proposer d'autres solutions. Il faudra aussi porter le gestionnaire en C (C++) sur un gros micro-contrôleur (genre ESP32).
Pierre
PS
quelques commandes possibles :
- changement de sens d'un train : clic sur la flèche (si le gestionnaire le veut bien)
- arrêt d'urgence d'un train : clic sur le bouton STOP
- changement de vitesse d'un train : drag dans la bande (si le gestionnaire le veut bien)
- établissement d'itinéraire : clic sur bouton correspondant (le bouton clignote si mise en attente)
- destruction d'itinéraire : re-clic sur bouton correspondant
- passer la souris au pied d'un signal permet de voir le signal avec les bons feux
Ne pas avoir peur de faire rouler les trains en pousse, le sens n'a pas d'importance avec ce type de gestionnaire.
L'enclenchement d'approche n'est pas actif pour le moment
-
Bonjour,
A chaque fois que je vois les programmes de Pierre, je mesure tout l'écart qui peut exister entre mon type de programmation, où je me débrouille avec le peu de fonctions de que j'ai comprises, et les siennes, où tout est objet, compact, avec un "vocabulaire" puissant que je ne connais pas. C'est très intimidant.
Bien sûr, je comprends quand même une bonne partie de ce qui est fait, mais heureusement qu'il y a les commentaires...
Ceci étant, j'ai quasiment fini mon éditeur JSON. Je vois qu'il va falloir y a jouter les types de signaux et les itinéraires (mais, là, ça me chagrine).
Il y génèrera les 2 types de JSON (par trajets et par voisins)
Faire un JSON "à la main", c'est tout à fait faisable, c'est même relativement facile (surtout pour un Locoduinodrome).
Mais on peut très facilement se tromper ou corriger dans un coin et ne pas faire la modification correspondante ailleurs.
Je tiens donc à ce que, grâce à un éditeur, on ne puisse pas laisser d'erreurs et que tout soit cohérent.
Denis
-
Après une petite semaine de combat contre les virus et microbes je viens de télécharger ce premier gestionnaire paramétré par un fichier Json éditable ici, sous forme d'onglet.
Mes impressions sont le suivantes principalement par rapport à ce que je m'attendais à voir venir.
1) C'est du Processing donc ça ne peut pas tourner dans un Arduino (Due, ArmXX) avec une connexion Can qui permet de récevoir tous les messages des capteurs (occupation, ponctuels, RFID/Railcom) et d'émettre tous les messages vers les actionneurs (aiguilles, signaux et surtout la centrale DCC en l'occurence LaBox).
Bien entendu la connexion existe entre le gestionnaire et le TCO. Mais je n'ai pas pu faire rouler de train virtuel, ce qui n'est pas nécessaire sauf pour tester à fond les paramètres .
2) J'ai eu du mal à retrouver les objets, propriétés et méthodes habituelles du gestionnaire en C++ et comprendre l'intégration des paramètres Json dans ces méthodes (ou fonctions ici, puisque ce n'est pas encore de l'objet)
Mais il ne faut pas voir mes premières impressions comme négatives car je sors d'une période d'invasion microbienne et de grande fatigue dont je ne suis pas rétabli.
Je serais donc très intéressé de savoir un peu à l'avance quel sera le chemin d'évolution et la cible visée du gestionnaire parametrable et je me rend compte du travail important que cela représente.
Actuellement je travaille sur mon nouveau TCO graphique sur bus Can qui est donc maintenant séparé du gestionnaire et je me prépare à tester cette évolution majeure du gestionnaire centralisé.
Bravo à Pierre et Denis pour le travail important déjà fourni .
-
Mes impressions sont le suivantes principalement par rapport à ce que je m'attendais à voir venir.
1) C'est du Processing donc ça ne peut pas tourner dans un Arduino (Due, ArmXX) avec une connexion Can qui permet de récevoir tous les messages des capteurs (occupation, ponctuels, RFID/Railcom) et d'émettre tous les messages vers les actionneurs (aiguilles, signaux et surtout la centrale DCC en l'occurence LaBox).
Oui c'est du Processing, car pour moi c'est beaucoup plus rapide à écrire et à tester, une version du gestionnaire pourra rester comme cela. Mais une version C/C++ pourra aussi être portée sur Arduino.
Bien entendu la connexion existe entre le gestionnaire et le TCO. Mais je n'ai pas pu faire rouler de train virtuel, ce qui n'est pas nécessaire sauf pour tester à fond les paramètres .
Tu dois pouvoir faire rouler les trains virtuels, il suffit de faire avec la souris un drag vers le haut (déplacement de la souris avec le bouton enfoncé) dans une des bandes verticales à droite de l'écran. Les trais s'arrêtent automatiquement aux signaux fermés.
2) J'ai eu du mal à retrouver les objets, propriétés et méthodes habituelles du gestionnaire en C++ et comprendre l'intégration des paramètres Json dans ces méthodes (ou fonctions ici, puisque ce n'est pas encore de l'objet)
Il n'est pas vraiment prévu d'objets. Tout le gestionnaire est écrit avec des fonctions, dans le but de faciliter la réécriture en C/C++.
Je serais donc très intéressé de savoir un peu à l'avance quel sera le chemin d'évolution et la cible visée du gestionnaire parametrable et je me rend compte du travail important que cela représente.
Petit à petit je vais améliorer le gestionnaire en Processing, et passer au nouveau Locoduinodrome (gros travail avec le tco).
J'ai commencé à regarder le portage en C/C++ sur un ESP32 bi-coeur, mais j'ai plein de problèmes avec IDE Arduino au niveau des cartes et des bibliothèques (json).
Pierre
-
J'ai commencé à regarder le portage en C/C++ sur un ESP32 bi-coeur, mais j'ai plein de problèmes avec IDE Arduino au niveau des cartes et des bibliothèques (json).
Je n’avais pas bien lu le mode d’emploi du TCO, donc je vais y retourner, perturbé par mes microbes !
Pour l’IDE je me demande s’il ne serait pas profitable d’embrayer sur PlatformIO, au moins pour les projets les plus complexes comme celui-là, les dernières versions de l’IDE Arduino se révélant moins stables.
Mais honnêtement il faudra présenter PlateformIO dans un article, ce à quoi je songe actuellement.
-
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
-
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
-
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.
-
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
-
Compredo ;D
Ça marche, effectivement. Merci
Denis
-
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 (https://www.locoduino.org/IMG/zip/editeur_json_3.zip)
Denis
-
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)
-
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 :D
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
-
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.
-
@ 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
-
@ 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. 8)
Denis
-
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
-
@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
-
@ 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
-
@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
-
@Laurent : je ne suis pas sûr de te suivre :(
Je fais confiance à Pierre et Denis pour cette phase importante.
-
Bonjour à tous,
J'ai avancé sur mon programme d'éditeur de JSON.
Construire un JSON "à la main" est tout à fait faisable, mais il faut bien maîtriser les subtilités de la SNCF et il faut décrire énormément de choses, ce qui est pénible et source d'erreurs.
Grâce à un programme qui automatise un peu les choses, on peut regarder les anomalies, les corriger et minimiser les saisies.
Dans mes premiers jets, les saisies étaient, à mon avis, lourdes.
Quant aux modifications, elles étaient impossibles : on efface et on réécrit les données de la zone. C'est toujours le cas en ce moment, mais j'ai des pistes prometteuses concernant les modifications. Je verrais bientôt.
La signalisation :
Je m'intéresse à la signalisation depuis des dizaines d'années.
Aussi, automatiser une signalisation pour un réseau est un vrai challenge.
Disons-le tout de suite : on ne peut pas tout automatiser. Il faut quand même donner un minimum d'informations simples qu'un programme ne peut pas deviner tout seul.
Tout le problème consiste à rentrer vraiment très peu d'informations.
A noter que très peu de réseaux ont une signalisation et encore moins une signalisation fonctionnelle. C'est malheureux.
Mais on a aussi des réseaux qui font circuler des locos électriques sans caténaire… ::)
Quelle signalisation ?
Suivant la période et la région concernée, il y a DES signalisations.
Chaque compagnie (avant la SNCF) avait sa signalisation, au départ mécanique puis lumineuse.
En 1936, on passe progressivement au code Verlant.
La création de la SNCF en 1938 entérine cette signalisation.
Je me limiterai donc à la signalisation lumineuse, postérieure à 1936 et antérieure au TGV qui a, lui aussi une signalisation tout à fait spécifique.
En fait, je procède par étapes :
Etape 1 : Le Locoduinodrome, même dans sa version 2, est trop simple.
Je suis passé à un réseau que je connais bien et pour lequel j'ai un plan des zones, avec une signalisation complète, qui plus est, validée par Pierre il y a quelques années : le réseau de Dominique.
C'est d'ailleurs en rentrant toutes les zones dans mon programme que je me suis aperçu de la lourdeur de mon processus initial.
Par exemple, même si, à terme, on a besoin des limites de vitesse de chaque zone, ce n'est pas la peine de les rentrer dès le début. Ce sera donc dans un deuxième temps, en "complément" qu'on rentrera ces infos. Sans compter les incohérences possibles dans la saisie des vitesses.
Etape 2 : Décrire quasi automatiquement ce qu'est une gare et une zone de manœuvres.
C'est absolument nécessaire car il y a dans les gares et le zones de manœuvres une signalisation spécifique. J'en suis à cette étape
Etape 3 : En fait, on ne peut pas trouver quel signal est nécessaire si on n'a pas d'itinéraires.
Et, si on veut trouver les itinéraires dans une gare, il faut définir quels sont les zones qui la composent, avec les zones d'approche et de sortie, bien sûr. Dans un premier temps, on limitera les itinéraires aux gares.
Donc, voici ma démarche globale :
1°) Rentrer toutes les zones d'un réseau (nom des zones et des voisins)
Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.
-> Pour les traversées (croisements, TJS et TJD), on met la parité à "pairimpair"
-> Pour les autres aiguilles, la parité de l'appareil de voie est la parité de son unique point commun avec un segment dont on connait la parité.
Il faudra peut-être pousser un peu plus loin le raisonnement pour la parité des appareils de voie.
2°) Définir comme "gare" quelques zones pour calculer la gare entière.
3°) Définir comme "manœuvres" une zone pour calculer la zone de manœuvres entière.
4°) Trouver tous les itinéraires de chaque gare.
5°) Rentrer les infos complémentaires de vitesse des segments de la gare, ce qui donnera les vitesses des appareils de voie, branche par branche, en évitant les erreurs et les incohérences.
En déduire la signalisation correspondante.
Démarche pour définir une gare (voir le fichier gare) :
J'ouvre une ArrayList : "zones_gare" qui va collecter toutes les zones d'une seule gare, au fur et à mesure que le programme parcourt toutes les zones.
Une fois les zones rentrées, je déclare Z3 "gare", ce qui met "g0" dans le champ "gare" de la zone Z3.
Puis la recherche systématique commence. Elle est détaillée dans le fichier joint.
En ayant rentré une seule zone, on a décrit toute la gare.
Evidemment, cet exemple est très simple.
Il est basé sur le principe suivant : dans une gare, il n'y a jamais deux segments voisins.
Dans cette gare, il permet, à la fois, d'exclure Z0 et Z7 de la gare et de déclarer Z1 zone d'approche et Z6 zone de sortie.
Dans la gare de Dominique, ce seul principe ne suffit pas. Ça serait trop beau ! :P
Il y a 2 gares : g0 au sud et g1 au nord.
On doit rentrer un segment dans g0 : j'ai choisi Z27
On doit rentrer 2 segments dans g1 (un pour le haut de la gare, un pour le bas car il n'y a pas de communication entre le haut et le bas de la gare g1) : j'ai choisi Z4 et Z22.
On n'a pas à s'occuper de la partie droite du schéma car on y trouve 2 segments consécutifs.
Z11 est une zone d'approche de g0, mais pas Z30
Z34 est une zone d'approche de g1, mais pas Z7
Pour la partie gauche, on ne peut pas utiliser le principe puisqu'il n'y a qu'une zone entre les deux gares et on aboutirait à une seule et unique gare.
Il faut donc préciser "à la main" les informations :
Z25 est la zone d'approche de g0 et Z16 est la zone d'approche de g1.
Les infos rentrées à la main sont prioritaires sur les infos crées par le programme.
Les zones de manœuvre :
Dans le réseau de Dominique, il y a aussi des zones de manœuvre. Et, si on n'y prenait pas garde, elles seraient, elles aussi, ajoutées aux gares, ce qui serait une erreur.
Il faut donc bloquer le processus en rentrant "bloque" dans les zones Z36, Z45, Z46 pour g0 et dans Z2 pour g1.
Maintenant, il faut décrire les zones de manœuvre.
A noter une chose importante : sauf cas particulier, on rentre dans la zone de manœuvre en marche arrière et on en sort en marche avant.
C'est le même principe que pour les gares, à ceci près qu'il n'y a pas besoin de bloquer, la gare s'en charge et, aux autres extrémités, tous les butoirs arrêtent le processus de recherche de zones.
On définit donc Z36 et Z37 où on rentre m0 dans le champ "manœuvres" des zones.
La dernière chose à définir, ce sont les zones d'approche des zones de manœuvres.
Là, je ne vois pas d'automatisation possible : il faut les définir à la main dans Z30 et Z16, champ "manœuvre". A noter, peut-être une piste : Z30 et Z16 sont les zones de sortie de la gare et je pense que ça n'est pas un hasard.
Résumé :
En rentrant 13 informations simples, on remplit 37 cases sans erreurs !
Fichiers joints :
https://www.locoduino.org/IMG/zip/editeur_json4.zip (https://www.locoduino.org/IMG/zip/editeur_json4.zip)
Dans le .zip, on a ma dernière version du programme Processing, avec la création des gares et des zones de manœuvre. Mais je n'ai pas fait la partie "entrée des infos gare/manœuvre" : je les rentre directement dans le fichier Excel. C'est la prochaine chose que je vais faire. C'était juste pour tester le fonctionnement.
On ne pose plus de questions pour les vitesses dans la première phase, mais il faudra poser les questions dans les "compléments". A réaliser, donc
Je vais aussi ajouter la possibilité de modifier les informations dans une zone.
Les fichiers Excel décrivant les zones (avant et après) sont dans le .zip
Il y a aussi le fichier détaillé du processus de définition d'une gare.
Et, évidement, le plan du réseau de Dominique (toutes mes excuses pour cet oubli)
Denis
-
Bonjour Denis et à tous,
Ce travail d'analyse est très interessant et je suis en train d'analyser la nouvelle application (4) et tes explications.
Il y a maintenant la possibilité d'ouvrir un fichier description existant. Ca c'est super ! Le travail est sauvegardé.
Merci pour les 2 réseaux : le Locoduinodrome 2 et mon réseau de Dominique.
Ca tombe bien, je suis en pleine reconstruction de mon TCO graphique-tactile sur écran 7 pouces. Ce TCO reprend exactement les mêmes objets zone et aiguilles que mon gestionnaire. En particulier les méthodes "suivantePaire" et "suivanteImpaire", avec la méthode inline GZone* GZone::selonAiguille(GAiguille* a,GZone* z1,GZone* z2) { return a->directe()?z1:z2; }
je vais attendre la mise au point avant d'ajouter les signaux.
Toutefois je constate dans mon réseau qu'il y a quelques cas où un voisin passe par les conditions de 3 aiguilles et pas seulement 2 comme dans le fichier JSON :
GZone* GZ6::suivantePaire() {
return selonAiguille(Ga16, selonAiguille(Ga13, NULL, Gz39), selonAiguille(Ga15, NULL, Gz2));}ou
GZone* GZ26::suivanteImpaire() {
return selonAiguille(Ga0, selonAiguille(Ga1, Gz27, selonAiguille(Ga3, NULL, Gz44)), selonAiguille(Ga2, NULL, Gz15));}
Je pense qu'il sera possible d'importer aussi le fichier JSON dans le TCO comme dans le gestionnaire. Cela se fera en C++ avec l'IDE Arduino mais je ne vois pas encore comment l'intégration se fera. Patience !
Cela me permet dors et déjà de voir les chemins possibles en fonction des positions des aiguilles à partir de n'importe quelle zone du réseau.
Je vais écrire aussi les calculs d'itinéraire entre 2 zones départ et arrivée qui définira les position d'aiguilles nécessaires.
Ce sera alors un bel outil de tests du travail que tu fais avec Pierre.
Mais le but du gestionnaire reste le suivi des trains et la sécurité (ralentissements, arrêts avant zone occupée) avec des moyens de pilotage soit manuels soit automatiques. Donc la prise en compte des messages Can des détections (présence par consommation de courant, RFID et RailCom, bien que n'ayant pas de Railcom sur mon réseau). L'intégration des réceptions des messages Can dans le gestionnaire est une des tâches les plus intéressantes et délicate, ainsi que les commandes des trains (ralentissements, arrêts et redémarrages automatiques qui donnent un vrai réalisme au réseau).
Je suis cependant un peu étonné du petit nombre de modélistes qui ont déclaré utiliser le gestionnaire de Pierre.
Si un lecteur de ce sujet se sent visé, ce serait très sympa de nous en toucher quelques mots, simplement.
-
Bonjour,
Voici la version 5 de mon éditeur JSON.
De nombreux changements et l'occasion de faire le point, après 25 pages sur ce fil…
Pourquoi un éditeur JSON ?
Le but de ce programme est de simplifier au maximum la saisie d'informations, d'en vérifier la cohérence et d'automatiser tout ce qui peut l'être.
Le fichier important, c'est le fichier JSON puisqu'il fait le lien avec un futur gestionnaire de réseau.
On doit avoir la séquence suivante :
Editeur JSON --> fichier JSON --> gestionnaire de réseau.
Il est tout à fait possible que d'autres réalisent un éditeur JSON, à condition que le résultat soit un fichier identique, quel que soit l'éditeur. En particulier, mon éditeur graphique (en cours de développement) devra fournir un fichier JSON.
De la même manière, tous les gestionnaires de réseau devraient être compatibles JSON.
On évitera ainsi à celui qui veut faire un gestionnaire toute cette phase rébarbative concernant l'entrée des infos du réseau.
Remarque 1 :
Comme l'éditeur et le gestionnaire ne sont pas complets, la version que je vais présenter est encore susceptible d'évolutions.
Remarque 2 :
Ce programme qui décrit un réseau est sensé ne servir qu'une fois… ;D
Un deuxième fichier est généré par le programme, le fichier "Zones". C'est juste en phase de développement, je pense qu'il n'a pas d'avenir. C'est juste un "fourre-tout" qui permet de conserver des infos pendant le déroulement du programme.
Signalisation :
La signalisation SNCF, même réduite aux cas les plus fréquents, reste une partie complexe puisqu'une fois compris le cas de la pleine voie, on doit tenir compte de la position des aiguilles , des vitesses sur les appareils de voie et même de la longueur des zones pour prévenir que le canton suivant est plus court que d'habitude et qu'il faudra en tenir compte pour freiner.
Il s'ensuit que pour calculer tout ce que peut afficher un signal, il faut d'abord avoir défini les itinéraires possibles.
J'en suis donc actuellement à cette étape dans laquelle je vais pouvoir "récupérer" ce que j'avais fait pour mon gestionnaire.
Itinéraires :
En phase de développement, donc, et je propose de n'indiquer dans le JSON que les itinéraires des gares. C'est d'ailleurs pour ça que j'ai passé du temps à définir quelles zones sont des zones de gare. Idem pour les zones de manœuvre.
Les itinéraires vont aussi servir dans le gestionnaire, évidemment, mais avec une contrainte de temps, ce qui n'est pas le cas ici.
Il y a deux fonctions chronophages dans la gestion des itinéraires :
1°) quelle est la zone suivante ?
2°) par quel côté j'aborde la zone suivante ?
J'ai décidé de répondre à ces questions directement dans le JSON.
J'ai adapté mon programme pour qu'on ait un traitement unique de tous les éléments de voie.
De la "même" façon que la Marine a pris la règle de "tribord, bâbord" pour qu'il n'y ait pas d'ambiguïté entre la gauche et la droite sur un bateau, la SNCF parle de "pair" et "impair", ce qui permet de gérer "gauche, droite, haut, bas, …" dans les dessins et le sens de circulation.
Pour indiquer les voisins, les "côtés" d'une zone, j'utilise des règles suivantes :
Cas des segments :
Je décrète que l'on parcoure l'octogone au départ (qui permet de définir l'orientation du segment à afficher) dans le sens des aiguilles d'une montre quand on est dans le sens "pair". Et, par conséquent, on est dans le sens impair dans l'autre sens.
Dans les dessins, comme il y a des lettres (A, B), on parcoure toujours un segment en allant de A vers B, de l'origine à l'extrémité.
Quand il n'y a un signal qu'à un bout, il est toujours du côté extrémité, c’est-à-dire B. Dans les boucles, on préfèrera les chiffres : on va de 0 à 1, mais ça, ça n'apparait pas sur le dessin.
Par ailleurs, l'origine est toujours du côté "voisin1" "côté0" du segment et l'extrémité est toujours du côté "voisin2" "cote1" du segment.
Cas des appareils de voie :
Il y a 2 types d'appareils de voie :
1°) ceux où il y a une extrémité commune à tous les trajets :
On part toujours de A, l'extrémité commune, et on va vers B, C, D.
A est côté "voisin1" "cote0" de l'appareil.
B, C et D sont, respectivement côté "voisin2", "cote1", "cote2" et "cote3"
2°) ceux qui sont des traversées (croisement, TJD, TJS)
A est côté "voisin1" "cote0",
B est côté "voisin2" "cote1",
C est côté "voisin1" "cote2",
D est côté "voisin2" "cote3".
L'intérêt de cette notation est que quand on rentre dans une zone du côté "voisin1", on en ressort du côté "voisin2". Et réciproquement. Et on peut facilement tester toutes les extrémités en allant de 0 à 4.
Pour être précis, de 0 à "zone.nb_voisins" :
3 pour les aiguilles et les enroulés,
4 pour les croisements, TJD, TJS et triples.
Exemple pour la zone 15 du plan de Dominique :
Je vous conseille d'imprimer le fichier "Z26 et ses voisins" pour mieux suivre.
Z26 est impair car Z25 est impair
vois1 est le voisin du côté A du triple. Donc, le vois1 est Z25.
Et, vu de Z25, Z26 est du côté B du segment. Donc vois2, côté 1.
C'est plus compliqué pour vois2 puisque ça dépend de la position des lames :
Côté B, le voisin est Z27, si a0 est à gauche et a1 est à droite
Et, vu de Z27, Z26 est du côté A du segment, soit vois1 côté 0.
Côté C, le voisin est Z15, si a0 est à droite.
Et, vu de Z15, Z26 est côté A de la TJD, soit vois1 côté 0.
Côté D, le voisin est Z44, si a0 est à gauche et a1 à gauche.
Et, vu de Z44, Z26 est du côté C de l'aiguille, soit vois2 cote 2.
Pour la suite, les itinéraires n'étant pas faits, les signaux ne sont pas remplis.
A suivre.
Denis
-
Merci Denis, gros travail !
Je vais essayer de comprendre mon réseau et rapprocher le JSON des suivantesPaire et suivanteImpair du programme.
-
@Denis,
Tu dis :
Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.
Tu te trompes sur la position des signaux. Un signal n'est pas sur un bloc, qu'il soit segment ou appareil de voie, mais à la jonction de deux blocs.
Il faut décrire ce qui est utile pour le gestionnaire.
Le gestionnaire a besoin d'avoir :
- la liste des blocs avec l'adresse du détecteur de courant.
- la liste des aiguillages avec l'adresse du décodeur et/ou de la rétrosignalisation de position
- la liste des signaux avec le type de cible, la direction pair/impair, le bloc en amont, le bloc en aval, et la ou les adresses de décodeurs
Jusque là c'est une description très simple.
La partie plus complexe ce sont les cantons. Un canton c'est une série ordonnée de 1 ou plusieurs blocs entre un feu de départ et un feu d'arrivée.
Il peut contenir une série ordonnée de un ou plusieurs appareils de voie dont on précisera la position directe ou déviée, et convergente/divergente.
Pour une gestion simplifiée des feux avec uniquement des feux de type BAL ou des carrés géré comme des BAL on n'a pas besoin de plus d'informations.
Pour une gestion prototypique des feux on a besoin des itinéraires des trains.
En effet dans ce cas on ne doit ouvrir un carré que si on a réservé le canton pour un train, ce qui suppose qu'on sait où il va.
Pour les manoeuvres c'est plus complexe. L'idée qui vient à l'esprit en premier, c'est de définir un canton comme zone de manoeuvre.
Le problème c'est que ça marche pour un tiroir ou toute autre voie sans issue mais pas pour une sortie de gare jusqu'au tableau LM.
Dans ce cas il faudrait définir la marche en manoeuvre dans l'itinéraire d'un train et changer le type de canton à la volée.
Mais on peut utiliser une astuce (géniale 8) ) pour contourner le problème :
Il suffit de définir un tiroir virtuel (donc un nouveau bloc) avec un aiguillage virtuel et le bloc virtuel utilisant le même détecteur de courant que le bloc réel.
Et on rajoute un (ou plusieurs) canton de manoeuvre qui va vers le tiroir virtuel.
On rajoute un carré violet virtuel à chaque butoir et la logique des feux devient simple : si le feu suivant est un violet on ouvre le blanc, sinon c'est vert ou jaune.
Le tiroir virtuel va également résoudre le problème du carré nain de retour qui doit être ignoré par les trains en ligne. Le carré est simplement mis sur le tiroir virtuel.
-
Merci Etienne,
Je reconnais que l'idée du tiroir virtuel me plait, en particulier pour gérer le feu nain et la vitesse à 15 km/h maxi pendant toute la manœuvre.
Je n'en suis pas encore là. Je cherche à calculer les itinéraires car il est hors de question d'en donner la liste à la main.
Je sais le faire dans mon gestionnaire, mais, là, il faut que j'adapte.
Denis
-
Bonjour,
Denis , il y a peut-être une chose qu'il convient également de prendre en considération , suffisamment en amont , c'est les voyants du TCO , je pense notamment à ceux qui montrent l'itinéraire , et l'occupation des zones (il me semble que tu sais bien ce que c'est) : pourquoi ?
je finalise actuellement le 4ème poste d'aiguillage analogique & TCO pour le club ; sur le TCO il y a des boutons poussoirs et des LEDs ; pour simplifier le travail de l'arduino (PRO MICRO = uno , faible puissance) , tout est fait par des tableaux , saisis manuellement ;
il y a 16 boutons et 18 aiguillages , (TCO de taille moyenne) , cela fait quand-même 35 itinéraires , dont certains peuvent comporter jusqu'à 14 LEDs , parmi les 72 LEDs des voies du TCO ; cela oblige à saisir un tableau de 35 * 14 = 490 items , qui sont soit 0 , soit une des 72 LEDs : c'est fastidieux , donc je pense qu'il serait bien que cette tâche puisse également être automatisée , si tu vois ce que je veux dire ...
-
@trimarco232,
Quand on me pose une telle question, c'est un réflexe : peux-tu donner le plan de ta gare ?
Bon, quand le programme calcule les itinéraires, il fournit évidemment la liste des zones concernées et la position des aiguilles.
La mettre sous forme d'un tableau est tout à fait envisageable, ça n'est pas le plus dur, et de loin.
Cela dit, il va bien falloir rentrer toutes les zones dans mon programme : c'est un peu fastidieux aussi :)
Pour information, rentrer le Locoduinodrome 2 me prenait 4 minutes (je l'ai fait plein de fois, pour le développement)
Pour la gare de Dominique, ça m'a pris un peu moins d'une heure.
L'intérêt d'un programme, c'est d'automatiser certaines choses et, surtout, de vérifier les incohérences.
Denis
-
pour illustrer , le tableau des LEDs en fonction de l'itinéraire :
#define leds_iti (1 + 14)// 1 + nombre max de leds dans l'itinéraire
// la 1ère colonne donne le nombre de leds dans le chenillard
// les leds hors chenillard (aiguilles protégeante) sont à ajouter à la fin
const uint8_t led_iti[itis * leds_iti] PROGMEM = { /// protégeantes à revoir /// problématique du sas ?
// ↓ iti ↓nb 1 2 3 4 5 6 7 8 9 /*-*/ 10 11 12 13 14 <- led
/* h6_sa */ 5, d_h6, d_h6a, d_h5r, d_h4r, d_s_n, /*-*/ d_h3n, o_, o_, o_, o_, o_, o_, o_, o_, // 0
/* h5_sa */ 5, d_h5, d_h5a, d_h5n, d_h4r, d_s_n, /*-*/ d_h3n, o_, o_, o_, o_, o_, o_, o_, o_, // 1
/* h4_sa */ 4, d_h4, d_h4a, d_h4n, d_s_n, /*-*/ d_h3n, o_, o_, o_, o_, o_, o_, o_, o_, o_, // 2
/* sa_th */ 3, d_s_n, d_t_n, d_th, /*-*/ d_s2n, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, // 3
/* h6_th */ 9, d_h6, d_h6a, d_h5r, d_h4r, d_s_r, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_h3n, d_s3n, d_e1n, o_, o_, // 4
/* h5_th */ 9, d_h5, d_h5a, d_h5n, d_h4r, d_s_r, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_h3n, d_s3n, d_e1n, o_, o_, // 5
/* h4_th */ 8, d_h4, d_h4a, d_h4n, d_s_r, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_h3n, d_s3n, d_e1n, o_, o_, o_, // 6
/* h3_th */ 8, d_h3, d_b3n, d_h3a, d_h3n, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_b2n, d_s_n, d_s3n, d_e1n, o_, o_, // 7
/* h2_th */ 7, d_h2, d_b2n, d_h2a, d_h2r, d_s3r, d_s2r, d_th, /*-*/ d_b3n, d_p_r, o_, o_, o_, o_, o_, // 8
/* h1_th */ 8, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3r, d_s2r, d_th, /*-*/ d_p_r, o_, o_, o_, o_, o_, // 9
/* tp_th */ 8, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3r, d_s2r, d_th, /*-*/ o_, o_, o_, o_, o_, o_, // 10
/* h6_hd */ 10, d_h6, d_h6a, d_h5r, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, d_s3n, d_e1n, o_, // 11
/* h5_hd */ 10, d_h5, d_h5a, d_h5n, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, d_s3n, d_e1n, o_, // 12
/* h4_hd */ 9, d_h4, d_h4a, d_h4n, d_s_r, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, d_s3n, d_e1n, o_, o_, // 13
/* h3_hd */ 9, d_h3, d_b3n, d_h3a, d_h3n, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_b2n, d_s_n, d_t_n, d_s3n, d_e1n, // 14
/* h2_hd */ 8, d_h2, d_b2n, d_h2a, d_h2r, d_s3r, d_s2n, d_s1n, d_hd, /*-*/ d_b3n, d_p_r, d_t_n, o_, o_, o_, // 15
/* h1_hd */ 9, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3r, d_s2n, d_s1n, d_hd, /*-*/ d_p_r, d_t_n, o_, o_, o_, // 16
/* tp_hd */ 9, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3r, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, o_, o_, o_, o_, // 17
/* h6_hm */ 10, d_h6, d_h6a, d_h5r, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_t_n, o_, o_, // 18
/* h5_hm */ 10, d_h5, d_h5a, d_h5n, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_t_n, o_, o_, // 19
/* h4_hm */ 10, d_h4, d_h4a, d_h4n, d_s_r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_t_n, o_, o_, // 20
/* h3_hm */ 9, d_h3, d_b3n, d_h3a, d_h3n, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_b2n, d_s_n, d_p_r, d_t_n, o_, // 21
/* h2_hm */ 8, d_h2, d_b2n, d_h2a, d_h2r, d_s3r, d_s2n, d_s1r, d_hm, /*-*/ d_b3n, d_p_r, d_e2n, d_s1n, o_, o_, // 22
/* h1_hm */ 9, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3r, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_e2n, d_s1n, o_, o_, // 23
/* tp_hm */ 9, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3r, d_s2n, d_s1r, d_hm, /*-*/ d_e2n, d_s1n, o_, o_, o_, // 24
/* h3_se */ 5, d_h3, d_b3r, d_h2a, d_h2r, d_s3n, /*-*/ d_p_r, d_e2n, o_, o_, o_, o_, o_, o_, o_, // 25
/* h2_se */ 5, d_h2, d_b2n, d_h2a, d_h2r, d_s3n, /*-*/ d_p_r, d_e2n, o_, o_, o_, o_, o_, o_, o_, // 26
/* h1_se */ 6, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3n, /*-*/ d_p_r, d_e2n, o_, o_, o_, o_, o_, o_, // 27
/* tp_se */ 6, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3n, /*-*/ d_e2n, o_, o_, o_, o_, o_, o_, o_, // 28
/* se_hm */ 2, d_e1n, d_hm, /*-*/ d_s1n, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, // 29
/* tp_p1 */ 7, d_tp, d_tp1, d_tp2, d_p_r, d_p1n, d_p1a, d_p1, /*-*/ d_h1r, o_, o_, o_, o_, o_, o_, // 30
/* tp_p2 */ 8, d_tp, d_tp1, d_tp2, d_p_r, d_p1r, d_p2a, d_p2r, d_p2, /*-*/ d_h1r, o_, o_, o_, o_, o_, // 31
/* tp_p3 */ 8, d_tp, d_tp1, d_tp2, d_p_r, d_p1r, d_p2a, d_p4n, d_p3, /*-*/ d_h1r, o_, o_, o_, o_, o_, // 32
/* tp_p4 */ 8, d_tp, d_tp1, d_tp2, d_p_r, d_p1r, d_p2a, d_p4r, d_p4, /*-*/ d_h1r, o_, o_, o_, o_, o_, // 33
/* h3_h2 */ 3, d_h3, d_b3r, d_h2a, /*-*/ o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_ // 34
} ;
et le dessin :
-
Waouhh !
Voilà une gare comme je les aime : commandée de façon "géographique", avec quelques itinéraires compatibles.
J'en suis à refaire marcher mes itinéraires dans le nouveau contexte. Chaque chose en son temps. Mais je testerai ta gare, c'est sûr.
C'est une gare terminus, apparemment ?
Denis
-
oui , c'est une gare terminus , mais c'est en analogique , donc à priori , il n'y a pas d'itinéraires compatibles , sauf cas particuliers : par exemple la voie TEP est commutable par relais , soit sur l'alim analogique du reste de la gare , soit sur l'alim des voies EP1 à EP4 ; c'est en fonction des itinéraires formés que l'arduino commute par relais , les alims analogiques , et également coupe l'alim des voies non prises dans un itinéraire ; ce dernier point permet de garer des trains sans avoir à utiliser d'interrupteur
-
@trimarco232
La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.
Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.
Denis
-
Bonsoir,
Ci-joint une photo de mon TCO (juste pour le fun) aucun rapport avec votre sujet :D
A droite j'ai fait un affichage (avec un UNO) via un écran tactile avec les directions (rien d'automatique sur les voies)
Face 1 affichage des directions, après le choix, sur la face 2 affichage des inters à bouger (voir photo)
J'ai affiché une lettre sur le TCO, je clique sur la direction choisie de l'afficheur, ensuite je bouge les interrupteurs (c'est ma façon de m'amuser)
Cordialement
Marcel
-
Merci Marcel,
Il est clair que tu aimes les trains américains : ton TCO est vraiment typique des USA.
On s'éloigne un peu du sujet, mais on pourra y revenir un peu plus tard.
Denis
-
@trimarco232
La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
certes , mais en analogique , il faut une alim traction dédiée à chaque itinéraire compatible , j'ai restreint pour éviter ça
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.
c'est pour cela que je planche sur ça https://forum.locoduino.org/index.php?topic=1601.0 (https://forum.locoduino.org/index.php?topic=1601.0)
et donc pour ça que je suis ce que tu fais , car il me faudra quelque chose pour le piloter , tout en haut
Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.
mon principe perso , c'est de banaliser tout le réseau , et d'ailleurs d'avoir tout en VU , pour économiser de la place
Denis
-
Après quelques semaines consacrées à la Savoie, je me remets au train. J'ai lu tous les post en retard. Je vais commencer par refaire une petite mise au point, dans ce fil on s'intéresse aux gestionnaires basés sur les ZONES, les cantons sont marginaux dans ce type de gestionnaire, ils ne servent qu'a l'espacement des trains. Pour les amateurs de cantons il y a d'autres fils sur ce forum.
Mon séjour en Savoie a du priver mon cerveau d'oxygène, car en lisant les post je suis tombé sur des mots et des idées que je ne comprends pas : segments, blocs, cantons virtuels et j'en passe.
Le but n'est pas de mettre dans le fichier JSON tout et n'importe quoi pour se faire plaisir, mais de mettre ce qui est nécessaire au gestionnaire pour faire son job efficacement, c'est à dire la sécurité, puis les améliorations : itinéraires, cantonnement, manoeuvres, conduite automatique, … . Tout ceci en essayant de rester le plus général possible : support de l'analogique et du digital, support de différents modes de rétro-signalisation, support de différents modes de commande des aiguilles et de signaux, … .
Il va falloir discuter séparément sur plusieurs sujets : les manoeuvres, les itinéraires, les sens des zones et voies, analogique/numérique, … .
Je vais aussi publier une nouvelle proposition de gestionnaire, cette version corrige quelques bugs, introduit des itinéraires permanents, mais surtout facilite la transition vers le C/C++ et l'Arduino qui impliqueront un changement inéluctable de la bibliothèque JSON.
Pierre
-
Pour commencer la discussion sur les manoeuvres, quelques précisions :
Concernant les manoeuvres certaines gares, généralement moyennes ou grandes, ont de voies spécialisées appelées "tiroir", ce sont souvent des voies courtes destinées à accueillir une locomotive pour des mises en tête de train ou des retraits. Une signalisation particulière est utilisée avec des carrés violets, mais aussi des feux blanc (M) sur des carrés normaux.
Dans certaines gares les manoeuvres se font sur voie principale, une pancarte LM (Limite de Manoeuvre)
indique jusqu'où la locomotive peut aller en manoeuvre, il y a généralement la place pour manoeuvrer un train complet. La signalisation est la même que pour les tiroirs (carrés violets). Dans les gares sur des doubles voies les manoeuvres se font toujours sur la voie "sortante", cela implique que le conducteur d'un train en ligne (pas en manoeuvre) ne rencontre pas de carrés violets (sauf IPCS). Bien souvent il n'y a pas de place pour implanter un carré violet "haut" dans l'entrevoie, un carré violet bas est alors implanté. Il n'y a pas de différences entre les carrés violets haut et bas. Par contre dans les gares sur voie unique les trains en ligne peuvent rencontrer des carrés violets, ceux-ci présentent alors un feu blanc (M).
Dans les grandes gares il y a souvent un mélange de manoeuvres avec des tiroirs et des manoeuvres sur voie principales.
Pierre
-
Pour commencer la discussion sur les manoeuvres, quelques précisions :
Il n'y a pas de différences entre les carrés violets haut et bas.
Pierre
Au contraire, il y a une grosse différence : le violet bas ne concerne que les trains en marche à vue.
Un train en marche normale qui franchit un carré violet bas ouvert reste en marche normale.
Un train en marche normale qui franchit un carré violet haut ouvert passe en marche à vue. (par exemple vers un dépot)
Dans le cas des manoeuvres jusqu'au tableau LM sur voie unique on utilisera un violet bas pour le retour en gare des trains en manoeuvre
qui sera ignoré par les trains en marche normale.
-
@ Etienne
OK après vérification dans les doc SNCF, il y a bien une différence (petite) entre les carrés violets hauts et bas.
Pierre
-
Cette (petite) différence complique sensiblement les gestionnaires.
Dans la logique de BAL un signal fixe son aspect ouvert d'après le signal suivant, mais il faut qu'il ignore le cv bas.
Et pour le train il faut savoir si il est en marche à vue.
Les cibles C, F, G, H peuvent afficher le vert ou le blanc et doivent donc savoir si c'est pour une manoeuvre.
Il y a 2 solutions :
- soit on a une variable booléenne associée au train gèrée par le gestionnaire et une fonction permettant au signal d'y accèder.
- soit on marque la voie comme voie de manoeuvre de manière fixe (pour un tiroir par exemple) ou dynamique aussi gèrée par le gestionnaire.
Si on utilise un gestionnaire existant (comme JMRI) qui ne gère ni l'un ni l'autre on a besoin d'une autre solution.
Cette solution c'est mon idée du tiroir virtuel:
Physiquement il y a une voie qui sort jusqu'au tableau LM et continue plus loin, mais logiquement il y a deux voies superposées avec une seule
détection de présence. Le violet bas se trouve sur la voie déviée et cette voie s'arrête au niveau du tableau LM.
Sur une cible C, F, G, H on affichera le blanc si l'aiguille virtuelle est déviée.
(Je suis en train de modifier le système de signalisation SNCF2015 dans JMRI pour obtenir ce résultat.)
-
Bonjour,
Moi, je veux bien qu'on ait ce genre de discussion, mais je pense qu'on a perdu tout le monde.
La signalisation SNCF est très complexe, elle permet de résoudre tous les cas, c'est vrai. Mais, là, je pense qu'on va trop loin dans le détail.
Je vais bientôt fêter l'anniversaire des 50 ans que je lis Loco-Revue. J'ai tous les numéros depuis le numéro 338, en 1974. Je lis aussi d'autres revues, y compris étrangères.
Eh bien, on ne voit quasiment jamais de signalisation sur les réseaux. Et le peu qu'on voit, c'est de la décoration, la signalisation n'est pas fonctionnelle.
Il y a de magnifiques contre-exemples (Soumagnac, Luzy, …), mais ils sont rares.
La plupart des gens utilisent le DCC, justement pour pouvoir arrêter un train sans avoir à gérer cette signalisation.
DRIM3D a fermé, faute de débouchés. Ils faisaient pourtant de magnifiques signaux.
Donc, il faut que les gens ne craignent plus d'avoir une signalisation fonctionnelle.
Mais il faut qu'on les aide et qu'UN PROGRAMME leur dise quel signal il faut mettre et où.
C’est-à-dire utiliser des règles simples, poser des questions dans un langage accessible pour qu'on puisse avoir une signalisation la plus complète possible sans connaissances pointues de la SNCF. Les situations rencontrées sur un réseau sont nettement plus simples.
Concernant la zone de manœuvre, je n'ai jamais vu sur un réseau de modéliste qui ait un signal blanc ou violet sur un mat dans la direction de la zone.
C'est déjà un grand pas si on a le signal au sol.
Pour moi, si les aiguilles sont tournées vers la zone de manœuvre, on tient compte du signal bas, sinon, on n'en tient pas compte.
Il y a des Cv en sortie de zone, la vitesse en zone de manœuvre est limitée à 15 km/h et on considère le panneau LM comme non franchissable.
L'itinéraire qui sort de la zone de manœuvre a un "carré virtuel" à l'emplacement du panneau LM et il s'arrête donc à ce point.
Denis
-
Pour que les gens sachent comment implanter les signaux, ce n'est pas un programme qu'il faut.
Il faut un forum ou un sous-forum dédié à la signalisation.
Si tu cherches sur internet ou sur les revues tu trouveras 1000 explications sur le principe d'un BAL,
150 explications pour l'implanter sur ton réseau et une grosse poignée de logiciels qui le gèrent (y compris gratuits).
Tu trouveras aussi des jolis dessins des différentes cibles sans savoir quoi en faire.
Mais comment créer le plan d'une gare en fonction de ce qu'on veut y faire, comment y implanter les signaux,
comment les relier électriquement et comment utiliser un logiciel pour les faire fonctionner?
ZERO résultats!
Les anciens sont restés sur le système tricolore de leur enfance et ont rarement les connaissances en électronique et informatique
pour aller plus loin.
Les jeunes sont plus ouverts à l'informatique mais ils n'ont pas le niveau d'éducation leur permettant de créer quoi que ce soit
sans suivre à la lettre (ou plutôt au son pour les 90% d'illettrés) un tutoriel sur youtube.
Si tu cherches à faire un gestionnaire simplifié tu perds ton temps : on en a déjà plein.
Il existe un logiciel qui peut être modifié pour la gestion prototypique des signaux SNCF : c'est JMRI parce qu'il est ouvert.
J'y travaille.
Mais pour que ça marche il faura un forum où les gens qui veulent faire un réseau puissent rencontrer des gens connaissant
la signalisation et d'autres connaissant l'électronique et/ou l'informatique.
-
@Etienne66
Je te propose de créer le sujet ad hoc que tu voudrais animer dans la catégorie Projets.
Tu pourrais décrire les principes et les réalisations, notamment avec JMRI.
Si le projet est assez abouti, tu peux aussi publier un article sur le site éditorial : on t'aidera ;D
Moi je pense que le gestionnaire de Pierre est assez complet pour ce que je veux faire. J'ai bien des cv mais en conduite manuelle devant la gare.
Je suis même peiné d'apprendre la disparition de Drim3D. Je suis en N et je ne trouve pas de signaux pas trop chers à installer sur mon réseau (j'ai quelques trucs moches et chinois).
-
Je posterai sur mon projet en temps voulu.
Pour l'instant j'ai la centrale multisecteurs qui fonctionne bien.
La partie détection de courant fonctionne en utilisant les 16 entrées analogiques d'un ou plusieurs mega2560.
Chaque mega va aussi gèrer 52 I/O digitales comprenant des nombres variables de servos, aiguillages, feux, accessoires et capteurs digitaux (infrarouge).
Le UNO de la centrale et les megas sont branchès au travers d'un hub USB.
L'interface avec JMRI (en direct USB, sans can ni c-mri ni autres bus préhistoriques) va générer automatiquement les objets avec des noms parlants.
Le sketch du mega et le script python pour JMRI sont inspirés des scripts de Geoff Bunza mais fortement améliorés.
J'en suis au test des feux et aiguillages.
Je vais ensuite faire une modification du système SNCF2015 de JMRI en ajoutant les cibles manquantes et en ajustant leur fonctionnement.
Après il faudra des tutos et ça risque d'être long.
-
Je posterai sur mon projet en temps voulu.
…
Après il faudra des tutos et ça risque d'être long.
C’est la bonne méthode : realiser d’abord et mettre au point et publier ensuite.
Notre patience sera récompensée par ce projet très intéressant.
-
Bonjour,
L'interface avec JMRI (en direct USB, sans can ni c-mri ni autres bus préhistoriques) va générer automatiquement les objets avec des noms parlants.
Peux-tu nous en dire plus ?
-
Bonjour,
L'interface avec JMRI (en direct USB, sans can ni c-mri ni autres bus préhistoriques) va générer automatiquement les objets avec des noms parlants.
Peux-tu nous en dire plus ?
Dans un autre sujet svp !
-
Ok, j'ouvre un sujet dans la section dédiée à JMRI.
https://forum.locoduino.org/index.php?topic=1691.msg18820#msg18820 (https://forum.locoduino.org/index.php?topic=1691.msg18820#msg18820)
-
@Pierre,
Ma recherche d'itinéraires marche. ;D
Je n'ai plus besoin de "polluer" la partie "zones" du JSON avec des zones suivantes et côté suivant.
Je reviens donc à la partie "zones" originale.
En revanche, pour les itinéraires, je crée une partie "connecteurs" indépendante.
Donc, en indiquant (manuellement) dans les appareils de voie des vitesses à voie déviée, en ayant défini les zones de gare et de manœuvre, je peux CALCULER les cibles des signaux pour C, S, A, VL, R30, RR30, R60, RR60, Cv au sol.
Je remplirai donc la partie "signaux", "aiguilles" et "itinéraires" (uniquement pour les gares)
J'ai encore besoin d'un peu de temps pour faire tout ça, mais je vois le bout du tunnel.
Denis
-
Voici où j'en suis concernant les itinéraires dans le gestionnaire, il va peut être falloir harmoniser les choses :
Le gestionnaire a besoin pour un itinéraire d'une liste de zones, à partir de cette liste il peut positionner les aiguilles et gérer les signaux. Il peut aussi être nécessaire d'avoir une autorisation pour partager des voies entre postes d'aiguillage.
La liste de zones commence à la zone de départ, celle qui contient le signal de départ, puis toutes les zones d'aiguilles, pour finir sur la zone d'arrivée. Un signal doit être rattaché à une zone, dans la réalité le signal est implanté juste avant le changement de zone, avant la coupure physique des rails (si elle existe).
Au niveau du fichier JSON pour chaque itinéraire il faudra une liste de zones et éventuellement une autorisation. Pour les gares comportant beaucoup d'itinéraires cela peut devenir fastidieux à saisir. Dans ce cas on peut envisager de fonctionner avec un point de départ et un point d'arrivée. Il faudra alors, peut être, dans le fichier JSON coder ces points de départ et d'arrivée avec des sens, vraisemblablement dans les zones.
Avec une zone de départ et une zone d'arrivée (et des sens) le gestionnaire peut calculer tout seul la liste des zones. On utilise pour cela un algorithme récursif assez simple. Mais cet algorithme a quelques défauts, il peut boucler indéfiniment, on peut palier ce problème par marquage des zones ou en limitant la taille de la liste de zones, il peut aussi produire plusieurs listes de zones, il faut alors choisir la "bonne" liste, pas si évident que cela. Il y a aussi le problème des autorisations.
Quelque soit la version des itinéraires, il va falloir spécifier les itinéraires de manoeuvre. Les itinéraires de manoeuvre ouvrent les signaux avec un feu blanc (carrées ou carrés violet), et il permettent d'envoyer une locomotive sur une zone d'arrivée occupée, ce qui implique un traitement spécifique dans le gestionnaire.
Plus généralement il va falloir dans le fichier JSON une partie "paramètres", par exemple : pour dire quelle version des itinéraires on utilise, pour dire si on alimente en analogique ou en numérique, … .
Pierre
-
Bonsoir
Pierre dans ce que tu définis comme une "zone de manœuvre" sur laquelle entrer avec une occupation cela me semble aussi ressembler aussi à une option de "forçage" du bloc.
Les cas d'usage sont multiples indépendant du concept de manœuvre pure:
mise en tête/queue d une loco sur une rame assurant une détection de présence sur la zone
cas des UM /couplages
refouler /avancer une loco qui "aurait fait des petits" pour raccrocher
Pour toute ces raison le mode manœuvre ouvre une sorte de dérogation permanente sur des section bien précises
Dans le cas du forçage c est une condition externe à caractère "spécifique et temporaire".
La facilite c est aussi de tout déclarer possiblement en manœuvre... mais la sécu du bloc va en prendre un coup!...
Ltr
-
La liste de zones commence à la zone de départ, celle qui contient le signal de départ, puis toutes les zones d'aiguilles, pour finir sur la zone d'arrivée. Un signal doit être rattaché à une zone, dans la réalité le signal est implanté juste avant le changement de zone, avant la coupure physique des rails (si elle existe).
Pierre
Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.
Et comme il a un sens il a une zone amont et une zone aval.
Physiquement il sera généralement un peu avant la coupure.
-
Bonsoir
Pierre dans ce que tu définis comme une "zone de manœuvre" sur laquelle entrer avec une occupation cela me semble aussi ressembler aussi à une option de "forçage" du bloc.
Les cas d'usage sont multiples indépendant du concept de manœuvre pure:
mise en tête/queue d une loco sur une rame assurant une détection de présence sur la zone
cas des UM /couplages
refouler /avancer une loco qui "aurait fait des petits" pour raccrocher
Pour toute ces raison le mode manœuvre ouvre une sorte de dérogation permanente sur des section bien précises
Dans le cas du forçage c est une condition externe à caractère "spécifique et temporaire".
La facilite c est aussi de tout déclarer possiblement en manœuvre... mais la sécu du bloc va en prendre un coup!...
Ltr
C'est plus complexe que çà.
Quand tu as un simple Cv tu peux définir les blocs permissifs pour pouvoir ouvrir au blanc sur voie occupée.
Mais sur une voie principale avec un signal qui peut afficher vert ou blanc il te faut savoir si le train
manoeuvre pour prendre la décision. (d'où mon idée de voie virtuelle)
Au passage : seul un segment peut être permissif, une zone avec aiguillages ne doit pas l'être.
-
Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.
Dans le programme du gestionnaire il y a des objets informatique zones, entre les zones (jonction de 2 zones) il n'y a rien, aucun objet informatique pour attacher un signal. Il faut bien attacher le signal à quelque chose.
Pierre
-
Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.
Dans le programme du gestionnaire il y a des objets informatique zones, entre les zones (jonction de 2 zones) il n'y a rien, aucun objet informatique pour attacher un signal. Il faut bien attacher le signal à quelque chose.
Pierre
Oui : Une zone amont et une zone aval.
Et ça te donne automatiquement le sens du signal.
-
J'ai trouvé un truc pour les signaux de manoeuvre :
Pour les signaux qui peuvent afficher blanc et vert/jaune, on met au blanc si le signal suivant est un carré violet fermé
et au vert/jaune si c'est un autre feu.
Et on place un carré violet virtuel à chaque butoir.
Pour info, je viens de tester le coup du tiroir virtuel avec JMRI et ça fonctionne.
-
Voici une nouvelle version expérimentale d'un gestionnaire paramètré par un fichier JSON. Par rapport à la version précédente plusieurs choses ont changé :
- des itinéraires permanents ont étés ajoutés, deux conséquences, sur le TCO les boutons d'itinéraires ont étés changés pour ressembler à des vrais boutons d'itinéraires de PRS (voir le PRS de Méru pour les explications de fonctionnement post #160 du 10 janvier 10 2024 sur ce fil), dans le gestionnaire certains carrés peuvent servir de sémaphores pour assurer la continuité du cantonnement. Ces itinéraires permanents permettent de faire rouler un ou deux trains sur la boucle.
- en vue du passage au C/C++, impliquant un changement de bibliothèque JSON, tous les accès au JSON ont étés regroupés dans un seul onglet ("Json"), il reste dans les autres onglets un type (JSONArray) qu'il est difficile d'éliminer Java n'ayant pas de "typedef".
- pour accélérer le programme un certain nombre de valeurs de type chaine de caractères ("String") sont substituées par des valeurs numériques ("int") juste après la lecture du fichier JSON. Ces valeurs sont : "gauche", "droite", "pair", "impair", "pairOUimpair", "pairETimpair".
J'ai fait aussi des essais d'itinéraires spécifiés par une origine et une destination, genre PRG et successeurs.
Pour le fonctionnement du gestionnaire avec le TCO voir la précédente version post #339 du 18 février 2024 sur ce fil.
Il reste encore des bugs dans le gestionnaire, notamment pour les itinéraires. Il faut aussi implémenter une circulation automatique des trains et prendre en compte le nouveau Locoduinodrome (donc modification du TCO, déja bien avancée). Puis envisager des manoeuvres.
Pierre
-
Super ;D
Merci Pierre,
J'ai tout juste fait un petit essai du Locoduinodrome 1 où j'ai lancé le TCO en premier et le gestionnaire en 2ème, puis démarré le train rose en cliquant sur l'itinéraire BX et c'est joli ! Le train fait le tour du circuit et s'arrête au signal à l'entrée de gare en venant de Y. Son curseur de vitesse passe à 0 et il faut le remonter pour redémarrer.
J'avoue que j'ai fait tout cela au pif en me souvenant du précédant Locoduinodrome. J'ai cliqué un peu partout sur les boutons d'itinéraires mais sans succès, faute de mode d'emploi.
J'ai jeté un coup d'oeil au code du gestionnaire et c'est du Java, je ne m'y retrouve pas mais je peux apprécier déjà que ce gestionnaire est plus complet que la version C++, il me semble, notamment sur le suivi des trains.
Ce qui me perturbe le plus c'est l'absence de définition des objets zones, trains, etc par comparaison avec celle du C++.
Mais là encore je ne connais pas le Java.
J'attend donc gentiment la version C++.
Je vais donc me plonger dans l'éditeur de Json en essayant de l'appliquer à mon réseau (en passant pas le Locoduinodrome 2 pour me faire la main).
C'est un travail énorme, bravo !
-
@ Dominique
Concernant les modes d'emploi il y a deux références à des posts précédents, une pour le fonctionnement général et une pour les boutons d'itinéraires qui sont expliqués sur le simulateur du PRS de Méru.
Comme je l'ai déja signalé le gestionnaire n'est pas écrit en programmation objet, mais sous forme de fonctions. Pour chaque message reçu par le gestionnaire il y a une fonction spécifique (voire deux pour les zones) qui traite le message avec l'aide de plein de fonctions annexes. Les variables du gestionnaire (zones, aiguilles signaux, …) sont dans le JSON. Cela devrait permettre de comprendre plus facilement le fonctionnement, plutôt que les objets et l'héritage, mais aussi de faciliter le passage au C/C++. Ce qui est écrit dans le gestionnaire c'est certes du Java, mais c'est quasiment du C/C++, la syntaxe du Java a repris en grande partie celle du C/C++ (il y a un article sur ce sujet : "Processing pour nos trains").
Pierre
-
Bonjour,
J'ai été pas mal occupé à d'autres tâches récemment et je n'ai pas beaucoup pu programmer.
Désolé de n'avoir pas suivi le fil...
Depuis la dernière fois, la partie itinéraire s'est étoffée :
Je ne trouvais, au début qu'un seul itinéraire, le plus court et ça s'arrêtait là…
Maintenant, je trouve tous les itinéraires techniquement possibles entre n'importe quel point A et n'importe quel point B.
J'ai adapté la partie "itinéraires" de mon programme de gestionnaire existant pour que ça marche ici aussi.
Plusieurs questions se posent :
1°) Le programme trouve tous les itinéraires possibles, sans tenir compte de la parité des voies.
Cela peut paraître une aberration, mais il ne faut pas oublier qu'il y a, même à la SNCF, toujours des "solutions de secours" en cas de dérangements.
Bien sûr, dans ces cas extrêmes, il y a des procédures de sécurité spécifiques, des signalisations provisoires, tout ce qu'il faut pour rétablir une circulation normale.
2°) Le temps de calcul d'un itinéraire est minuscule. Doit-on garder les itinéraires en mémoire, par exemple dans le JSON ?
On pourrait très bien envisager de les calculer "à la volée" dans le gestionnaire.
3°) Si on ne garde que certains itinéraires, sur quels critères ?
Dans mon programme JSON, j'ai un bouton "itinéraires" qui demande le nom de la zone de départ, le coté du départ, le nom de la zone d'arrivée, le côté de la zone d'arrivée.
Exemple dans le réseau de Dominique : Z25, côté 1, Z30, côté 1.
Premier problème, très simple :
Le "côté 0", c'est le côté du "voisin1", le "côté 1", c'est le côté du "voisin2". On voit tout de suite où est le problème…
Soit j'appelle "côte 1" et "côté 2", en ajoutant simplement 1, soit on appelle les voisins "vois0" et "vois1". Il faut juste se mettre d'accords.
Voilà le résultat littéral (il trouve 4 itinéraires) :
Z25 segment
signal1 signal
Z26 triple droit : a0 à gauche + a1 à droite
Z27 segment
signal1 signal
Z29 triple gauche : a11 à droite + a9 à gauche
Z30 segment
signal1 signal
------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
Z25 segment
signal1 signal
Z26 triple droit : a0 à droite
Z15 TJD : a2 à droite + a4 à droite
Z42 aiguille droite : a5 à droite
Z14 segment
signal0 -
Z43 aiguille gauche : a6 à gauche
Z12 TJD : a7 à gauche + a8 à gauche
Z29 triple gauche : a11 à gauche
Z30 segment
signal1 signal
------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
Z25 segment
signal1 signal
Z26 triple droit : a0 à droite
Z15 TJD : a2 à droite + a4 à gauche
Z13 segment
signal0 -
Z12 TJD : a7 à droite + a8 à gauche
Z29 triple gauche : a11 à gauche
Z30 segment
signal1 signal
------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
Z25 segment
signal1 signal
Z26 triple droit : a0 à gauche + a1 à gauche
Z44 aiguille gauche : a3 à gauche
Z28 segment
signal1 signal
Z29 triple gauche : a11 à droite + a9 à droite
Z30 segment
signal1 signal
------------------------------------- FIN DE L'ITINERAIRE -----------------------------------
On note :
- que les signaux ne sont pas (encore) calculés
- que on prend bien Z13 et Z14 "à rebrousse-poil" en regardant quel signal (0 ou 1) voit le conducteur
- que si on trouve une appellation meilleure que "segment", je suis preneur ("tronçon" ?)
Je pars en vacances une semaine et je ne pourrais pas programmer.
Denis
-
@ Denis
Trouver tous les itinéraires possibles entre n'importe quel point A et n'importe quel point B, n'a pas grande utilité, je pense qu'il faut plutôt définir des points d'origine d'itinéraires avec un sens et des points de destination d'itinéraires, ces points pouvant de façon plus générale être des zones.
Normalement les points d'origine sont devant un signal (ou sont des zones avec un signal) et il n'y a qu'un signal par itinéraire (sauf Cv bas).
Dans les grandes gares il peut y avoir plusieurs itinéraires possibles, mais en pratique en respectant les contraintes précédents je n'ai pas de souvenir d'avoir rencontré de problème avec des sens des voies (pair/impair). Par contre quand il y a plusieurs itinéraires possibles il faut absolument choisir, on a déja évoqué ce problème jadis et j'avais proposé de choisir l'itinéraire avec le moins de zones, tu n'étais pas d'accord alors, as tu un meilleur critère à proposer (faut que cela reste réaliste).
Le gestionnaire peut très bien rechercher les itinéraires à partir d'un point d'origine et d'un point de destination. Dans le gestionnaire JSON publié, il y a depuis le début dans l'onglet "Zones" deux fonctions "voiss1(String z)" et "voiss2(String z)" qui donnent tous les voisins (1 et 2) d'une zone, ces fonctions étant prévues pour la recherche automatique des itinéraires. Dans la dernière version publiée il y a dans l'onglet "Itineraires" une fonction expérimentale "itineraire(String zo,int c,String zd)" qui recherche un itinéraire d'origine "zo" en partant du coté "c" avec pour destination "zd" (le résultat est une liste de zones). Cette fonction est bridée pour s'arrêter au premier itinéraire trouvé, mais elle peut tous les trouver (reste à trouver un moyen de choisir).
Concernant les appellations des cotés (1/2, 0/1, pair/impair, … ), le problème est plus vaste que cela et je compte lancer une discussion sur le sujet (les "sens" en général).
Pierre
-
Je suis aussi bien occupé avec la famille/amis (ce sont les vacances des enfants) ;D
-
Je me remets dans le bain après une longue interruption et je vois le fichier JSON d'entrée du gestionnaire 2.2 de Pierre.
Il concerne le locoduinodrome 1 et contient les zones Z0 à Z6, les aiguilles A0 et A1, les signaux S1 à C6, les itinéraires XA à YB et une autorisation.
Je ne retrouve pas tout cela dans l'éditeur de Denis, version 5 qui concerne le locoduinodrome 2 et n'inclut pour le moment que les zones Z1 à Z7.
Est-ce que je me trompe ? Ai-je oublié une version ?
Donc, si je ne me trompe pas, le fichier JSON du gestionnaire de Pierre doit être la cible à atteindre pour l'éditeur de Denis et les deux cotés concerneront le locoduinodrome 2.
Cela permettra de passer au Locoduinodrome 2 coté gestionnaire, ce qui entrainera une évolution du TCO chez Pierre.
De mon coté je n'ai pas prévu de m'engager dans un TCO en Processing, restant en C/C++ pour le gestionnaire et un TCO graphique adressé en CAN.
En regardant le code du gestionnaire, j'ai un peu peur que le passage en C/C++ soit un énorme travail !
Bon courage à vous deux. ;D
-
Je voudrais discuter des "sens" dans un gestionnaire. Je sais, par expérience, que les sens dans un gestionnaire posent des problèmes. C'est pour cela que dans le gestionnaire JSON expérimental j'ai essayé de ne pas expliciter dans le fichier JSON, les sens des voisins, des signaux et des balises avec des pair/impair, mais avec quelque chose de plus neutre, des nombres 1 ou 2.
Pour le gestionnaire appliqué à l'ancien Locoduinodrome cela n'a pas posé trop de problèmes. Mais pour le nouveau Locoduinodrome c'est plus compliqué, car plus de mal à retrouver le sens des signaux et des balises entre autre. J'ai donc remplacé les sens neutres (1 ou 2) par des sens plus explicites (pair/impair) et conformes à la circulation des trains, en fait dans le fichier JSON les 1 ou 2 sont replacés par P (pair) ou I (impair). Cela implique qu'il faille soigneusement déterminer les sens de circulation des trains sur chaque zone.
Les sens concernent beaucoup de choses dans un gestionnaire :
- les sens des trains, c'est ce qui est le plus consensuel, on a naturellement de trains pairs et des trains impairs (éventuellement on pourrait avoir des train sans sens);
- les sens des signaux, les trains pairs voient les signaux pairs et trains impairs voient les signaux impairs, ce qui induit le sens des signaux, sur voie double les train roulent à gauche, sauf en Alsace-Lorraine;
- les sens des balises, elles sont liés aux signaux, donc à leurs sens (mais d'autres balises que celles des signaux peuvent exister);
- les sens possibles de parcours des zones par les trains, c'est plus compliqué on peut avoir par exemple des sens pair, impair, pair-ou-impair (sans changement de sens possible), pair-et-impair (avec changement de sens possible), … ; on peut envisager aussi des manoeuvres avec ou sans sens (genre : "pair-ou-impair-manoeuvre" ). Ces informations servent pour le suivi des trains, pour contrôler les changements de sens des trains, … ;
- les sens liés à la désignation des voisins des zones, par homogénéité avec les cas précédents pair/impair convient bien;
- les sens de zones, est ce que l'on peut donner un sens aux zones et est ce que cela peut servir au gestionnaire.
Il n'y a pas de problème de sens avec les boucles de retournement à double voie, mais il y a problème avec les boucles de retournement à voie unique, appelées raquettes, un train arrive sur une raquette avec un sens disons pair et en ressort avec un sens impair et vice versa. Il faut que le gestionnaire soit prévenu, par exemple avec une ou des balises dédiées (de toute façon il faut faire quelque chose au niveau alimentation électrique). Même problème avec les triangles de retournement et les plaques tournantes.
Pierre
-
Bonjour,
Post intéressant sur les sens. Cela pourrait paraitre ésotérique, mais c'est fondamental et pas aussi évident qu'on pourrait le croire.
Pour moi, il y a le sens lorsqu'on dessine le réseau :
Quand on trace un trait, on va de l'origine à l'extrémité, ce qui, chez moi, se traduit par aller du "côté 0" au "côté 1". Une fois dessiné, le "côté" est définitif.
Il s'ensuit que, pour les voisins, je verrais mieux "voisin 0" et "voisin 1", d'ailleurs.
Une fois décidé lors de la création du plan du réseau, c'est, là aussi, définitif.
Après, la notion de "pair/impair" me parait s'imposer.
Sur un réseau miniature, on est très souvent confronté à un ovale de voie, ce qui n'est quasiment jamais le cas dans la réalité.
Je propose de définir le sens "pair" pour le sens des aiguilles d'une montre et le sens "impair" pour l'autre sens, mais c'est parfaitement arbitraire.
Il en découlera des signaux "pairs" ou "impairs", des noms de voies "pairs" ou "impairs", des trains "pairs" ou "impairs".
Les zones qui pourront être parcourues dans les 2 sens seront "pairimpair".
Il faudra bien dessiner les signaux au bon endroit et ils seront "côté 0" ou "côté 1" de la zone, quelle que soit sa parité.
Dans le cas général, les signaux seront donc à l'extrémité de la zone, dans le sens normal de circulation, donc du "côté 1".
Après, il y a le sens de circulation. Là, on est dans le gestionnaire.
On se déplace sur des zones qu'on aborde en général par le "côté 0", mais qu'on peut aborder du "côté 1" suivant l'itinéraire, en particulier dans les zones "pairimpair". Le sens de circulation est donné par l'ordre des zones dans le déplacement.
Dans le JSON, on ne fera apparaitre que les itinéraires qui sont dans les gares et uniquement ceux qui ne vont jamais à contre-sens.
J'entend par "contre-sens" les déplacements de trains lors d'un accident, par exemple, et qui nécessitent une signalisation temporaire.
Les IPCS seront traitées comme "pairimpair", même si un sens est prioritaire.
Pour moi, un itinéraire en gare est constitué de 2 choses : une liste de zones et une liste de position d'aiguilles pour aller d'une zone à l'autre.
Denis
-
il y a différentes approches
dans le réseau analogique que j'ai câblé , dans la partie basse de l'ovale , le sens impair (tu commences par le sens pair , je commence par le sens impair ..) , est de la gauche vers la droite , comme pour ta proposition
mais dans la partie haute de l'ovale aussi ! ceci pour s'éviter des nœuds dans le cerveau , cad. s'obliger à raisonner et dessiner tantôt de la gauche vers la droite , tantôt l'inverse
bien entendu , chaque principe a ses inconvénients : cela m'a obligé , aux extrémités gauche et droite de l'ovale , de définir le nez-à-nez comme étant accepté , et donc d'interdire le passage dans le même sens ; mais cela s'est avéré globalement plus logique , simple , et conforme la réalité
-
@trimarco232,
Tu comprends mieux, maintenant, pourquoi je fais cet éditeur de JSON.
La notion d'aiguille "à gauche"/"à droite", pourtant très simple, comme notion, peut faire faire des nœuds au cerveau, de même que la notion de voisin "côté 0" et "côté 1".
On se tord le coup, on regarde ses doigts en se mettant à la place de l'objet...
Avec mon éditeur, c'est dessiné, à chaque fois, dans le bon sens, et c'est le programme qui gère les "à gauche"/"à droite"...
On a nettement moins d'erreurs.
J'ai un bouton appelé "analyse" qui complète les infos de façon cohérente.
Je suis en train de calculer la signalisation : dire, pour chaque signal, quels feux il est susceptible d'afficher, de façon à prévoir la bonne cible et la bonne appellation.
Et c'est là que connaitre tous les itinéraires possibles va me servir, en retirant ceux qui, bien que techniquement valables, ne sont pas validés (zones à contre-sens).
Je mettrais, après, dans le JSON ceux qui ne concernent que la gare, la zone de manœuvre et les zones d'approche correspondantes.
Denis
-
merci André ,
as-tu édicté des règles , pour la conception d'un réseau susceptible d'être animé par ton gestionnaire ?
-
André ??
Non, pas encore, j'en suis à l'éditeur de JSON. Et c'est déjà du boulot.
Par contre, Pierre en a proposé un en processing (post #396 du 06/04/24)
Denis
-
Après quelque temps occupé par divers travaux et événements familiaux, de retour à la montagne, je plonge dans les derniers programmes Processing de Pierre : GestJ2 et GestTCO2.
Celui qui m'intéresse le plus est GestJ2 car c'est le gestionnaire pur et dur. Il est écrit en Java (ou Processing, c'est pareil ?) et j'arrive a faire des analogies avec les objets C++ comme dans la version C++ que j'utilise.
Les grandes différences avec mon gestionnaire C++ sont :
- la description des objets (zones, aiguilles, signaux, trains, ..) est issue d'un fichier JSON qui serait préalablement construit avec l'éditeur de Denis (je vais en reparler plus loin).
- les événements de rétrosignalisation (occupations, libérations, commandes des trains et des itinéraires, ..) sont générés sous forme de messages TCP en provenance de GestTCO2 : c'est donc de la simulation et non du réel, mais j'imagine bien qu'on pourrait détacher ce TCO et le remplacer par les événements réels d'un réseau.
Première remarque : le but est théoriquement bien atteint pour le gestionnaire paramètrable qui est le point de départ de ce fil du forum. Bravo !
Un tel gestionnaire pourrait donc être réalisé sous forme d'une carte Arduino "connectée". En gros, on aurait ainsi l'équivalent d'un JMRI, RocRail ou CDMRail sans PC !!
- connectée à un éditeur de réseau JSON qui servirait à paramétrer le gestionnaire en fonction du réseau du modélistes.
- connectée aux capteurs d'occupation/libération et autres capteurs (ponctuels, RFID, RailCom, etc..) du réseau réel.
- connectée à la centrale DCC pour les commandes des trains (régulation, automatismes, ..) et récupérer les états de mouvement des trains (direction, vitesse), ainsi que les incidents éventuels.
- connectée à un TCO graphique qui permet de visualiser ce qui se passe sur le réseau réel (ou simulé) - dans ce cas la description du réseau JSON du gestionnaire est à dupliquer en liaison avec des rendus graphiques pour une interface humaine sympathique.
Dans l'exemple GestTCO2, le TCO permet de commander les trains, les itinéraires, voire les aiguillages. Ce TCO simule les déplacements des trains et génère automatiquement,ent les occupation et libération. Il fait tout ce qui est décrit plus haut, sauf l'éditeur de fichier JSON qui est développé séparément par Denis.
Si on met tous ces éléments bout à bout, on obtient un gestionnaire complet comme JMRI, RocRail ou etc. qui ne tourne que sur PC/Mac, voire Rpi (mais ça rame peut-être)
Deuxième remarque : ce TCO GestTCO2 est beaucoup plus compliqué que le gestionnaire GestJ2
Mais on en a besoin pour voir et commander les trains et le réseau. Du moins en mode simulation.
Troisième remarque : si je dois appliquer tout ce travail à mon réseau Dominique, que dois-je faire ?
C'est mon avis évidemment et je peux me tromper :
1) traduire en C++ le gestionnaire GestJ2 pour l'installer dans un Arduino (Due en ce moment ou à base d'ARM, avec assez de mémoire et de CPU, mais cela ne semble pas critique)
2) la description en fichier JSON n'a besoin d'être faite qu'une seule fois donc inutile de construire un éditeur connecté au gestionnaire, l'intégration à la compilation est suffisante.
3) connecter toute la rétrosignalisation via un bus CAN ce qui est déjà fait ou très simple à faire la plupart des microcontrôleurs sont capables de communiquer en CAN : libérations, occupations, signalisation, aiguillages, et bien plus si affinité.
Toutefois, passer du mode simulation au mode réel en remplaçant les messages "parfaits" du TCO GestTCO2 par des messages Can qui ne seront pas forcément parfaits, nécessitera (comme actuellement) des travaux de mise au point et du monitoring des événements et états pour la mise au point.
Sans oublier la centrale DCC déjà reliée au CAN (Mega+DCCpp ou LaBox).
4) connecter un TCO graphique pour visualiser ce qui se passe, ce que j'ai déjà en chantier sur un écran 7" piloté par un Teensy3.6 (en passant, je regarde le développement des tableaux de bord de voitures qui ont des écran superbes dont les prix finiront par devenir abordables, mais seront-il accessibles aux programmeurs ferroviaires ??).
5) connecter éventuellement des organes de commandes des trains (les applications smartphone comme Z21 font l'affaire), des itinéraires et horaires, etc.. sur le TCO graphique en principe.
En ce qui concerne l'éditeur de Denis, pour obtenir le fichier JSON de description du réseau pour le gestionnaire, cela représente un développement important qui serait mieux valorisé s'il faisait partie d'un éditeur de réseau : pour le gestionnaire ET pour le TCO.
Je sais que ce n'est pas l'objectif initial de ce projet mais Denis a déjà plus ou moins cela dans son PC.
Donc l'avenir va être interessant !!
-
Merci Dominique !
J'admire ton optimisme ... mais ton expérience est biaisée.
Ton réseau a été présenté dans Locoduino et a servi de modèle.
A l'époque, Pierre, qui maîtrise parfaitement les subtilités de la signalisation de la SNCF, a réalisé des articles très complets sur ce que doit être un gestionnaire.
Ces articles sont toujours d'actualité, d'ailleurs.
Puis tu lui a demandé de t'expliquer où mettre des signaux et de quels signaux il s'agissait sur ton réseau, ce qu'il a fait.
Dans son programme, la description des signaux (et du réseau) est intégrée et ça fonctionne chez toi parfaitement.
En lisant le programme, tu as compris comment cela avait été fait. Mais aurais tu pu le trouver tout seul ? On ne le saura jamais...
En refaisant ce nouveau fil de discussion, on a décidé d'extraire les infos descriptives du réseau dans un fichier JSON.
L'idée était que l'on puisse avoir un point de passage clair, précis, adapté à n'importe quel réseau SANS CONNAISSANCES SNCF.
Donc, lorsque ce fichier aura subi tous les tests, il sera labellisé Locoduino.
A ce moment, n'importe qui pourra faire un éditeur dont le fichier de sortie sera le JSON Locoduino et il pourra dès lors utiliser le gestionnaire que Pierre est en train tel quel pour commander ses trains.
Le gestionnaire doit être "neutre", c'est à dire qu'il doit fonctionner à partir du fichier JSON (et rien d'autre).
De la même façon, si quelqu'un sait faire un gestionnaire qui fonctionne à partir du fichier JSON Locoduino de son réseau, il pourra utiliser mon éditeur pour générer le fichier JSON.
J'ai fini la partie "générer tous les itinéraires possibles d'un réseau", itinéraires qui contiennent la position des signaux.
Moyennant une partie de programme à faire, je vais calculer quel signaux doivent être affichés pour un signal donné, ce qui permettra de définir la cible (A,B...H) à acheter pour ce signal.
Les itinéraires de la gare seront extraits de la liste complète et intégrés dans le JSON, de façon à ne plus avoir à les calculer dans le gestionnaire.
Donc : je ne connais pas la signalisation SNCF, je sais juste qu'il doit y avoir un signal là, là et là. J'appuie sur un bouton et le programme me dit:
Là, il doit y avoir VL, A, S et RR, là C, A, R, etc...
Pour info (c'est totalement anecdotique) mon programme trouve et affiche en détail en 6 secondes la liste des 2 572 itinéraires possibles de ton réseau, parmi 3 582 couples départ/arrivée testés :P
Denis
-
Bonjour
Je suis tombé récemment sur un petit problème avec le gestionnaire json, ce gestionnaire utilise un transit souple. Dans un transit souple dès qu'une zone d'un itinéraire est libéré après le passage d'un train, elle peut être utilisée par un nouvel itinéraire.
Prenons un cas concret, illustré par le bout de tco ci dessous, le train bleu parcours l'itinéraire de A vers X, le train rose est en attente de l'itinéraire de X vers 1 qui est en mémoire. Dès que le dernier essieu du train bleu libère la zone de la tjs, l'itinéraire en attente se forme et le train rose peut passer sur la tjs. Cela parait tout à fait normal et cela l'est.
Mais en pratique avec un réseau réel, sncf ou miniature (j'ai fait des essais sur mon réseau HO), quand le dernier essieu du train bleu quitte la zone de la tjs, le bout de la caisse du dernier véhicule engage encore le gabarit de la zone tjs et se ferait percuter par le train rose si le train bleu s'arrêtait.
Ce problème est assez général et peut se produire avec toutes les traversées entre deux voies à l'entrevoie minimum.
Des idées, des solutions ?
Pierre
-
Ne serait-il pas opportun d’inscrire et d’utiliser la longueur des trains dans leur objet et la comparer à celle des zones traversées et l’outil “provenance” ?
Évidemment cela ne nous met pas à l’abri d’une perte de wagon mais la détection de présence dudit wagon peut générer une erreur par rapport au passage du train complet.
Il faudrait donc compléter l’initialisation des trains avec des données plus larges, ce qui implique de préparer des compositions de trains à l’avance. Il y a longtemps que je ne suis rendu compte qu’on ne peut pas mettre n’importe quel wagon derrière une machine ou un wagon, à cause de la fiabilité aléatoire des attelages dans les courbes et les zones d’aiguille, surtout en N.
Quand les enfants viennent jouer, des trains non initialisés fichent la pagaille et je ne demande si on peut réduire cet inconvénient (zones pas libérées entre autres).
-
Le gestionnaire json comporte déjà un compteur du nombre de zones occupées par un train, une borne max permettrait de détecter les ruptures d'attelage.
On peut aussi, lors d'une libération d'une zone par un train vérifier que la (ou les) précédente(s) ne contient plus ce train, ce doit être la dernière zone du train.
Pierre
-
Bonjour,
subordonner , dans ce cas , la libération de la tjd. à celle de l'aiguille du bas ...
ou ne pas faire de transit souple , c'est pas indispensable en MF ...
-
@pierre,
J’ai cherché l’équivalent des initializations des objets zone, aiguille, signaux, trains, etc à partir du fichier JSON (Z1.osé) en C++ pour Arduino.
Mais je n’ai rien trouvé de simple et compréhensible même dans les projets Arduinojson de Blachon et d’Arduino.
En Java, l'objet "doc" peut être décomposé simplement en objets "zone", "aigullle", etc.. directement utilisables ensuite par le programme.
En C++ ça semble bien plus compliqué.
J’ai peur que la version C++ du gestionnaire représente un gros boulot !
-
@ Dominique
Pas d'inquiétude, la bibliothèque "Arduinojson" a tout ce qu'il faut. C'est un peu déconcertant car l'opérateur [] du C++ est redéfini pour accéder aux éléments du fichier json, mais en définitive l'écriture est plus compacte et plus lisible. J'ai déjà fait des essais.
Pierre
-
Merci Pierre, mon optimisme se confirme donc.
Je vais pouvoir refaire complètement mon gestionnaire sur cette nouvelle mouture, même si la configuration est déjà faite sans le json car la version actuelle a été tellement modifiée qu’il vaut mieux repartir sur un bon pied.