Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - DDEFF

Pages: [1] 2 3 ... 52
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 29, 2025, 07:29:02 pm »
Bonjour à tous,

Pourquoi j'ai choisi "Luzy" ?

"Luzy" est, à ma connaissance, le plus grand réseau français installé chez un particulier (à part, peut-être "Soumagnac" ?). En tout cas, le plus célèbre, animé par quelqu'un de fort sympathique (Renaud Yver) qui diffuse son savoir avec entrain ( ;D). Le fil consacré au réseau fait … 1048 pages !!
En particulier, il utilise RRTC (Trains Controller), version gold et on a le plan.
En entrant les infos de "Luzy" dans mon programme, je m'attendais à trouver des problèmes nouveaux et c'est effectivement le cas.
J'ai donc passé 10 h en tout pour le rentrer (8 h de saisie pure et 2 h à déplacer à la souris les pavés pour que ce soit joli).
A la fin, j'ai 138 zones (le réseau fait 50 m²).

Il n'y a plus de problèmes "plantatoires", mais il reste des problèmes "dessinatoires", comme vous allez le voir sur le TCO.

Explication :

J'ai deux (!) TCO car le premier se calcule en dessinant les zones, puis les "connecteurs", c’est-à-dire toutes les lignes qui vont d'une zone à une autre. Là, ça marche.
Mais le calcul est long car il y a trop de calculs à faire. Ce n'est pas un problème dans un éditeur, mais c'est rédhibitoire dans un gestionnaire.
En effet, je vais prendre comme exemple la Z37 dans le réseau de Dominique.

Elle est constituée de 5 droites :
Droite 0 : c'est la droite de la section "Z37".
Droite 1 et droite 2 : le programme calcule les coordonnées du coude de trace les deux droites avec les points qu'il a déjà : la point à gauche de Z37 et le point à droite de Z45 (ce sont des points de zone).
Droite 3 et droite 4 : le programme calcule les coordonnées du coude de trace les deux droites avec les points qu'il a déjà : la point à droite de Z37 et le point à droite de Z46/0 (ce sont des points de zone).
Donc des calculs de points à faire et 5 droites à tracer.
Hors de question de faire pareil dans le gestionnaire !

Je garde donc les coordonnées de tous les points du réseau dans une table imprimable (TOUS_PTS, 25 colonnes, qui ne sert à rien, sauf en développement).
Puis je raisonne en disant qu'avec les coordonnées de 4 points, je pourrais dessiner la même chose avec seulement 3 droites, sans calculs. C'est la table TCO qui recense les points réellement utiles pour chaque zone. Il n'y a plus que 9 colonnes !
C'est là qu'il subsiste quelques erreurs, visibles en comparant les 2 images.

Mais, en même temps, il y a le calcul du JSON (2 681 lignes !), avec juste quelques erreurs dans quelques signaux. Je vais voir.

A suivre

Denis :P

2
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 28, 2025, 09:11:01 am »
Bonjour à tous,

Concernant Luzy, j'ai bien fait de me lancer. Il y a quelques nouveautés dans la V24 que je mettrai en ligne bientôt.

Exemple :
J'avais envisagé pour les noms de zone des choses du type XXX ou XXXCCC ou XXXCCC/CCC (X = une lettre, C = un chiffre), mais j'avais oublié XXXCCCX (Voie 3 A)

Maintenant, la largeur du trait sera fonction du nombre de cases du fond, les appareils de voie n'auront plus d'étiquette, les étiquettes auront une largeur variable en fonction du texte et leur emplacement sera aussi désolidarisé de la position du pavé (comme les signaux).

Pour info, un réseau comme Luzy nécessite 4 h de saisie pure. C'est peu pour un réseau de 10 m x 5,25 m.

A suivre
Denis  :P

3
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 28, 2025, 08:51:33 am »
Bonjour Dominique,

La taille de la fenêtre est "en dur" dans le programme. C'est même la toute première instruction dans le setup() et elle est obligatoire.
Donc, il y a 2 possibilités : soit la taille programmée, soit plein écran ("Bouton vert" pour Mac et "Carré" pour Windows)

Denis

4
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 27, 2025, 10:36:54 am »
Bonjour à tous,

J'ai démarré le réseau de Luzy, histoire de voir comment ça se passe avec un très grand réseau.
On a la chance d'avoir la version RRTC de ce réseau, Renaud Yver étant un spécialiste de ce logiciel.

Alors, le résultat est que le programme, à la V23 fonctionne bien, sans plantage.
Remarque : pour que l'analyse se passe bien alors qu'on n'a pas rentré tous les éléments, il suffit de mettre un butoir aux extrémités (C26 et C31 pour Luzy).
On peut ainsi afficher un TCO correspondant à ce qu'on a déjà rentré.

Mais il va falloir modifier les dessins pour le gestionnaire :
Si on met le nom des aiguilles sur les aiguilles, on cache tout. RRTC ne met pas les noms des aiguilles.
Je ne mets pas les noms des signaux dans le gestionnaire. A discuter.
La largeur des traits est certainement à réduire, en fonction du nombre de pavés du TCO.

A suivre
Denis :P

5
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2025, 10:31:47 pm »
Bonsoir,
J'ai beaucoup travaillé avec des fichiers existants et il restait des bugs pour les zones initiales, ainsi qu'en sauvegarde impossible...

Bon, on peut créer les premières zones et les sauver sans bugs.
C'était simple à corriger, mais ça n'était pas viable.

La V23 fonctionne. Je commence à rentrer Luzy.

Le programme étant construit pour générer un fichier JSON, il ne le calcule que quand tout est OK, c'est à dire quand l'analyse ne détecte plus rien.
Or, au début, il manque forcément des éléments et l'analyse trouve des choses à redire, d'où le message d'erreur systématique quand on veut sauver.
Il ne faut pas en tenir compte.
Puis la sauvegarde se fait, mais sans le fichier JSON, ce qu'indique le dernier message.

Donc, la toute première fois, vous partez sans aller chercher un fichier (bouton "Zones").
Puis vous sauvez, ce qui génère un fichier "Zones", entre autres.
Et la fois d'après, vous allez chercher les fichiers (boutons "Fichiers" puis "Charger") pour le compléter.

Denis  :P

6
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2025, 03:24:13 pm »
Normalement, c'est mieux... ::)
Je supprime les Z21 et les Z20 qui souffraient du même défaut

7
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2025, 02:59:44 pm »
J'ai trouvé le bug.
Recharge la V21 (j'ai aussi remis à jour celle que j'avais mis dans mon post de ce midi)

Denis

8
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2025, 02:22:59 pm »
Tu as essayé avec la version 21  envoyée ce midi ?

9
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2025, 01:44:23 pm »
Merci Christophe,

Le programme fourni permet déjà de renter son réseau et d'en faire un JSON et un TCO.
Si quelques uns de mes lecteurs pouvaient essayer de rentrer leur propre réseau, cela ferait plusieurs exemples pour faire des tests.
Et trouver ainsi des cas "à problèmes" pour pouvoir améliorer le programme.

Je pense que je vais rentrer "Luzy", pour voir si ça marche.

Effectivement, si le gestionnaire pouvait suivre, ce serait super.

Denis :P

10
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2025, 12:31:19 pm »
Bonjour à tous,

Voici la dernière version de mon éditeur JSON, version 21.

Après avoir corrigé quelques bugs, j'ai bien développé le TCO, en 2 versions :

1°) Version de vérification avec toutes les infos (nom des signaux, gare, manœuvre)
2°) La version gestionnaire, plus sobre, qui tient compte des zones multiples (en gris) et qui affiche la première position des lames pour les appareils de voie.

Le programme est effectivement énorme.

C'est en faisant le gestionnaire que je vais essayer de m'approprier des techniques de programmation objet nettement plus efficaces et que j'utiliserai les fonctions JSON de Processing.
Pour l'instant, je faisais tout "à la main" parce que je voulais définir toutes les infos nécessaires et dessiner un TCO. Maintenant que c'est fait, que je vois vraiment où j'en suis, je vais utiliser des techniques nouvelles.
 
Mais j'aurais un cahier des charges complet.

Les puristes vont me dire : "Mais il fallait commencer par là". C'est vrai…

Denis  :P


11
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 25, 2025, 07:11:04 pm »
Bonjour à tous,

PARENTHESE...

Je viens d'aller voir ce que j'avais écrit sur mon éditeur de réseau (dessinez votre réseau (le système de Denis)) et mon gestionnaire (gérez votre réseau (le système de Denis)) et il ne reste quasi rien de mes fils. Le piratage est passé par là...
J'étais surpris que plus personne ne me pose de questions : j'ai la réponse  :-\

De toutes façons, Ces deux fils servaient surtout à voir la faisabilité de réaliser un TCO facilement sous Processing et de faire un gestionnaire complet, également sous Processing. Il y avait de jolis trains virtuels et il restait à relier ça à un bus CAN pour qu'on passe aux trains réels.

Je vais les ressusciter ici, d'une part parce qu'il y avait quand même pas mal de bonnes idées et, d'autre part, parce que le gestionnaire était fonctionnel. Toutes les questions que je m'étais posées restent tout à fait d'actualité.

Le gestionnaire que je vais écrire, à la suite de la création du JSON sera, bien évidemment, fortement inspiré de mon ancien gestionnaire, sans trains virtuels.

J'ai, aussi, sous le coude un éditeur de TCO parfaitement à l'échelle (genre CDM rails, mais plus développé), mais il est pour l'instant encore avec des bugs. On verra plus tard.

FIN DE LA PARENTHESE

Denis :P

PS : merci d'avance à Pierre pour son aide  ;)



12
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 18, 2025, 01:03:39 pm »
Bonjour à tous,

Mais pourquoi donc ai-je réalisé ce programme ?

C'est vrai qu'on pourrait se poser la question à une époque où il y a des IA qui génèrent automatiquement un fichier JSON à partir de données.

Pourquoi un fichier au format JSON ?

C'est un format moderne qui permet de ranger des informations dans une structure claire, en identifiant bien les objets. En plus, il est géré nativement dans Processing, ce qui ne gâche rien.

Le choix du format JSON étant fait, pourquoi se casser la tête avec un programme de plus de 10 000 lignes, avec plus de 1 000 "if" et près de 500 "case" ??
Parce que, si la rédaction d'un fichier au format JSON quand on a déjà les infos est automatisable par IA, le calcul de toutes les infos l'est beaucoup moins.

Il faut se rendre compte que mon fichier JSON contient 90 % d'infos calculées, pour 10 % d'infos directes !
Par exemple, je dis qu'une zone s'appelle "Z25" et qu'elle "a un signal côté B".
Dans le JSON, on saura ça :
------------------------------------------------------------------
zone Z25 signal cote A : panneau -, signaux = -
zone Z25 signal cote B : panneau Cv sol, G, signaux = C1 : A, VL, RR30, (Z26 lames2), RR60, (Z26 lames1),  R30, (Z28), C, Cv, M,  Bs19
1°) Il n'y a pas de signal côté A (ça, ce n'est pas dur)
2°) Du côté B, il y a un signal sur un panneau "G", avec un signal au sol qui affiche "Carré violet" et "Manœuvres" et, sur le panneau, qui s'appelle "C1", les signaux "Avertissement", "Voie Libre", "Rappel de Ralentissement à 30 km/h" quand l'aiguille de la zone Z26 a les lames en position 2, "Rappel de Ralentissement à 60 km/h" quand l'aiguille de la zone Z26 a les lames en position 1, "Ralentissement à 30 km/h" si vous allez vers la zone Z28, le "Carré" et que la balise qui concerne ce signal a le numéro 19.

Au passage, ça vous dit quels panneaux acheter pour votre réseau et comment brancher vos moteurs d'aiguilles pour économiser les boutons (bretelles détectées automatiquement, "super appareils" pour regrouper les moteurs)

Et, "accessoirement", on dessine un TCO dans la foulée…

Et, tout ça sans à priori sur le réseau qui peut être de n'importe quelle taille et composé de n'importe quels éléments.

Denis

13
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 13, 2025, 08:06:40 am »
Bonjour,

J'ai remis à jour le lexique (zones d'approche, de sortie, enclenchements et TCO).

La partie TCO de mon programme doit être remaniée. J'y ai ajouté les coupures de rails et je vais déplacer les signaux à leur proximité.
Et, surtout revoir la manière de travailler en gérant, à nouveau, des connecteurs (X, Y, orientation, ...).
C'est vraiment dur de s'en passer ... ;D

Denis

14
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 12, 2025, 04:49:05 pm »
Bonjour Pierre,

Tu as raison, il faut détailler les enclenchements. D'autant que je parle des zones d'approche et des itinéraires.
C'est un sujet fondamental, régulièrement oublié quand on résume les itinéraires à une liste d'aiguilles qui se mettent en mouvement quand on appuie sur un bouton.

Merci pour tes encouragements.

Denis

15
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 10, 2025, 05:23:06 pm »
POST DU 10/03/25 PARTIE 2/2

BRETELLES :

Les appareils de voie sont commandés par de moteurs, mais, dans certaines configurations, la position d'une aiguille entraîne obligatoirement la position d'une autre aiguille sous peine de déraillement. Ce sont les bretelles. Elles permettent donc des gains en câblage et en sécurité.
Exemple de bretelle :



Contrairement aux apparences, le problème de les détecter automatiquement n'est pas simple.
Les aiguilles, dans une bretelle, sont opposées par leurs talons. C'est obligatoire.
Souvent, elles sont reliées par leurs voies déviées, comme dans l'exemple ci-dessus, mais elles peuvent aussi être voie directe - voie déviée, avec une aiguille droite et une aiguille gauche :



On peut aussi avoir un élément droit dans la bretelle :



Et c'est là qu'on apprécie les joies de l'informatique…
On cherche : "Des aiguilles, opposées par leurs talons, avec la possibilité d'une aiguille droite et d'une aiguille gauche et possibilité d'éléments droits ou courbes entre les talons des aiguilles".
Et on tombe sur ça :


 
Qui est tout, … sauf une bretelle !
Il manque donc un autre paramètre : la longueur des éléments, indispensable ici !

C'est pareil pour une bretelle double.
Il y a tout un monde entre ça :


 
Et ça :


 
Et pourtant, le schéma est le même !
Donc, il faut tenir compte des longueurs dans la détermination automatique des bretelles.
Il y a donc, dans mon programme, une longueur maxi (L_MAXI dans le setup) qui permet de bien définir les bretelles.
A noter que le branchement simple est le seul appareil de voie possible dans une bretelle pour la bonne raison qu'il n'a pas de moteur (cas de la bretelle double).
Dans une bretelle, il ne peut y avoir que 2 aiguilles.
Il s'ensuit que les appareils impliqués sont : les aiguilles, l'une des aiguilles d'une TJS, l'une des aiguilles d'une TJD à 2 moteurs, une aiguille triple.
Il n'est pas possible d'avoir une TJD à un seul moteur dans une bretelle.
Une bretelle, c'est le plus simple des super appareils (voir ci-après).

SUPER APPAREIL :

On a diminué le nombre de zones en créant des zones multiples.
On peut aussi diminuer le nombre de positions à étudier en regroupant les moteurs des appareils de voie des bretelles.

1°) Les bretelles simples :

Deux aiguilles, c'est 2 x 2 positions possibles. Mais comme les deux aiguilles sont liées, il n'y a que 2 positions à étudier : la position "bretelle" et la position "non-bretelle".
On n'a plus qu'un seul super appareil, composé des 2 aiguilles, et seulement 2 positions pour ce super appareil.
On remarquera que, dans une bretelle simple, les deux aiguilles sont dans la même position.


           
Ex : a0 droite et a1 droite pour la bretelle, a0 gauche et a1 gauche pour les voies parallèles, c’est-à-dire "non bretelle".
Donc, la définition d'une bretelle peut se simplifier :
"Br0" : a0, a1, droite.
La position "non-bretelle" peut s'écrire "Br0-" sans qu'on ait besoin de la décrire dans le JSON (Ce serait Br0- : a0, a1, gauche).
Dernière remarque :
Il n'est pas besoin de décrire une section qui serait entre les 2 aiguilles (une section n'a qu'une position)

2°) Les bretelles doubles :


 
Dans une bretelle double, il y a 5 appareils de voie. On n'oublie pas, en effet, la traversée centrale composée d'une "aiguille virtuelle", amenant 2 alimentations potentielles, elles bien réelles, en fonction de la bretelle choisie. Soit 32 positions potentielles et seulement 3 positions possibles.
Br0 : a0, a3, droite, a4
Br1 : a1, a2, gauche, a4
La description de la bretelle reste la même que la bretelle simple, mais, ici, on indique aussi la traversée simple en fin de description, sans donner sa position puisqu'elle est identique à celle des aiguilles.
Les 3 positions sont les suivantes :
- position 0 : Br0, Br1-, a4
- position 1 : Br0-, Br1, a4
- position 2 : Br0-, Br1-
En position 1, a4 est à droite par Br0 et à "non-gauche" = droite par Br1- : il est donc à droite.
En position 2, a4 est à "non droite" = gauche par Br0- et à gauche par Br1- : il est donc à gauche.
En position 3, a4 n'est pas concerné.
 

 
Mais attention, super appareil ne veut pas dire une seule zone : la bretelle double ci-dessus a bien 7 zones de détection de présence.

3°) Aiguilles triples. Exemple dans le réseau de Dominique :


 
Z29 est une aiguille triple, décomposée ici en 2 aiguilles consécutives : a9 et a11.
Dans la pratique, il y a 3 aiguilles à gérer ici, soit, à priori 2 x 2 x 2 = 8 possibilités.
Il y a bien une bretelle Br0 : a8, a11, gauche, mais elle ne fonctionne que si a9 est à gauche.
Donc il n'y a que 3 positions qui aient un sens :
- Position 0 : Br0, a9 gauche.
- Position 1 : Br0-, a9 gauche
- Position 2 : Br0-, a9 droite.
Il peut paraître surprenant, quand a9 est à droite, que la position de la bretelle intervienne, mais c'est nécessaire à la sécurité : si a9 est à droite, on ne peut pas envoyer un train venant de a8 vers la bretelle.
Autre exemple, dans le réseau de Dominique complété pour essais :


 
Z26 est une aiguille triple, décomposée ici en 2 aiguilles consécutives : a0 et a1.
Br0 : a0, a2, droite
Br1 : a1, a51/0, gauche
Les 3 positions sont :
- Position 0 : Br0, Br1-
- Position 1 : Br1, Br0-
- Position 2 : Br0-, Br1-

4°) Toujours dans le réseau de Dominique, une bretelle avec aiguille commune. Ici a16.


 
Il y a 3 aiguilles, donc 8 positions et, en fait, seulement 2 utiles :
- Position 0 : Br0, Br1-
- Position 1 : Br1, Br0-
On a la liste exhaustive de tous les super appareils possibles :
Bretelle, bretelle double, triple 1 et triple 2, aiguille commune.

LISTES D'APPAREILS DE VOIE :

C'est le moment de faire le point sur les différentes listes consacrées aux appareils de voie.

1°) On a une liste de tous les appareils de voie :
            "a0" : {
                    "nom" : "a0",
                    "type" : "TripleSDa",
                    "no" : 0
            },
Qui se lit : l'appareil a pour nom "a0", il est du type "aiguille triple symétrique à droite côté A", c'est le 1er appareil de la liste des appareils et a pour identifiant le numéro 0.

Rappel 1 : Une aiguille triple a sa première aiguille en partant de la pointe à droite et la suivante à gauche dans le cas d'une "TripleD" et sa première aiguille en partant de la pointe à gauche et sa suivante à droite dans le cas d'une "TripleG".
Si, en plus, elle est d'apparence symétrique, il y aura TripleSD et TripleSG.
La 1ere aiguille est côté A et la deuxième côté B.

Rappel 2
: Une aiguille ayant toujours 2 positions ("gauche" et "droite"), ce n'est pas la peine de l'indiquer dans le JSON.

2°) Une liste des bretelles :
            "Br0" : {
                    "nom" : "Br0",
                    "position" : ["a0","a2","droite"],
                    "no" : 0
            },
Qui se lit : Bretelle 0, position a0 et a2 à gauche, identifiant numéro 0.
L'autre position n'est pas décrite et s'appellera "Br0-".
Là, les positions sont décrites car spécifiques au réseau. On voit aussi pourquoi le nom d'une aiguille ne doit pas démarrer par "Br".

3°) Une liste des super appareils :
            "Su0" : {
                    "nom" : "Su0",
                    "positions" :  [["Br0", "Br1-"], ["Br0-", "Br1"], ["Br0-", "Br1-"]],
                    "no" : 0
            },
Là, les positions sont décrites car spécifiques au réseau. On voit aussi pourquoi le nom d'une aiguille ne doit pas démarrer par "Su".
 
BALISE :

On a considéré que la détection de présence dans une zone se fait par consommation de courant. C'est le système le plus performant. Mais il suppose de nombreuses coupures de rails.
Il existe aussi des détections de présence ponctuelles (ILS, infra rouge, capteurs à effet Hall…) et on les appellera des balises.
Mon programme ajoute systématiquement une balise (notée Bs) à chaque signal. Ce système sert pour garantir un arrêt devant un signal à un point précis.
Le programme ajoute aussi systématiquement une balise (notée Bb) avant un butoir pour garantir l'arrêt.
Je n'ai pas géré le cas de balises isolées (passage à niveaux, tunnels, panneaux "S", …), mais on pourrait définir une méthode pour en ajouter.

LONGUEURS :

Il est indispensable de connaitre la longueur de chaque zone. Par défaut, la longueur d'une zone sera de 999 mm dans mon programme.
Par ailleurs, il faut que des sections de longueur nulle existent pour "affecter" un signal à un appareil de voie.
De plus, certains signaux (jaune clignotant, rouge clignotant, blanc clignotant) sont liés à la longueur de la zone.
Enfin, dans le gestionnaire, j'aurais besoin de longueur précises les sections et branches des appareils de voies pour calculer la distance qui sépare un train de son signal d'arrêt. J'y reviendrai dans le gestionnaire, c'est fondamental.

FICHIERS :

Pour l'instant, dans Processing, tous mes fichiers sont issus de "Tables" et sont donc des fichiers dont l'extension est obligatoirement ".tsv", c’est-à-dire "Tabulation Separated Values" (valeurs séparées par une tabulation) qui se trouve être le fichier natif des fichiers Excel.
Il s'ensuit que le meilleur moyen d'ouvrir ces fichiers texte est l'application Excel (ou tout autre tableur).
La conséquence, c'est que le fichier JSON sort actuellement en "_JSON________.tsv".
Si on veut un vrai fichier JSON, il suffit de le copier ailleurs et de changer l'extension ".tsv" en ".json" et on obtient le fichier "_JSON________.json".
Le fichier JSON est, ici, un fichier de sortie et le fichier ZONES est le fichier d'entrée. Il ne contient que les informations que le programme ne peut pas deviner.
Le fichier ZONES, quant à lui contient exclusivement les valeurs nécessaires au calcul du fichier JSON. Il n'y a que des valeurs que vous rentrez. Tout le reste est calculé.
Il est fortement déconseillé de modifier des valeurs directement dans le fichier ZONES, tant elles sont liées les unes aux autres. En passant par le programme, tous les liens sont pris en compte et la cohésion est garantie.

Variables du fichier ZONES :
NOM :
Le nom de la zone simple.
PARITE :
La parité de la section, avec une aide dans le programme.
TYPE :
Numérotés de 0 à 11


 
ORIENTATION :

L'orientation est la position du dessin d'une section ou d'un appareil de voie par rapport à la verticale dans un pavé. La "précision" de cette orientation est de 45°. Elle est caractérisée par un nombre entre 0 et 7 dans le fichier zones.

GARE :

L'info de la gare. On a :
g0, g1, … qui sont les zones de gare (on n'en rentre qu'une partie)
ap_g0, ap_g1, … qui sont les zones d'approche des zones de gare (on les rentre toutes)
so_g0, so_g1, … qui sont les zones de sortie des zones de gare (on les rentre toutes)

MANŒUVRE :

L'info de la zone de manœuvres.
m0, m1, … qui sont les zones de manœuvre (on n'en rentre qu'une partie)
ap_m0, ap_m1, … qui sont les zones d'approche des zones de manœuvre (on les rentre toutes)
so_m0, so_m1, … qui sont les zones de sortie des zones de manœuvre (on les rentre toutes)

VITESSES :

L'info de la vitesse limite d'une zone ou, dans un appareil de voie, d'un segment de l'appareil.
X, Y :
Ce sont les coordonnées du centre du "pavé" sur le TCO. Un pavé n'a pas d'orientation. Il est calé sur une grille.
Les X, Y ne sont pas demandés lors de la création des zones simples :
C'est uniquement lors de modifications, c’est-à-dire dans une deuxième étape.

TCO :

A la SNCF, c'est le "Tableau de Contrôle Optique". Il est, en général, le long d'un mur dans le poste d'aiguillage et représente le tracé de toutes les zones gérées par ce poste d'aiguillage, avec l'occupation par les trains, la position des aiguilles, des itinéraires, ...
C'est purement visuel. Il n'y a pas de boutons sur un TCO à la SNCF.

Les modélistes se sont dit qu'il serait pratique, justement, d'y regrouper tous les boutons et le TCO est devenu le "Tableau de Commande Optique".

Tableau de Commande Optique (TCO)

C'était tentant du fait qu'on a déjà le dessin de tous les éléments…
Mais je n'avais pas envie de le dessiner : c'est le programme qui va se charger de le faire.
On doit quand même positionner les éléments (X, Y) et, le plus simple, c'est de rentrer les noms des zones dans Excel. C'est très souple, on peut déplacer plusieurs éléments d'un coup et avoir un positionnement global satisfaisant. C'est plus simple de se mettre en notation "L1C1" plutôt qu'en ABCD. Attention : Excel démarre à 1 et Processing à 0…
On note le nombre de cellules en horizontal et en vertical. En général, le nombre en horizontal est supérieur au nombre en vertical. C'est celui-là qui compte.
On rentre le nombre de colonnes d'Excel dans le setup "NB_PAVES = xx"
Une fois qu'on a rentré tous les X, Y dans les zones, on peut afficher le TCO.

1°) On appuie sur le bouton "Analyse" pour faire tous les calculs et on est ainsi sûr qu'il n'y a pas d'erreur. Si on oublie d'appuyer sur "Analyse" avant, on n'a pas les calculs des portions intermédiaires…

2°) On appuie sur le bouton "TCO" et on a un "paté" du TCO, coincé dans un carré de 500 x 500.
Il faut alors passer au plein écran et le TCO apparait.
On se rend compte alors que certains positionnements ne sont pas bons et on peut alors les modifier directement sur l'écran en cliquant dans les pavés des zones.
Si vous cliquez à gauche dans un pavé, il avance d'une case vers la gauche et le dessin se met à jour. De même pour droite, haut et bas. Et le dessin se recalcule immédiatement !
Quand vous êtes satisfaits du résultat, n'oubliez pas de sauver les X, Y :
1°) Cliquez sur "Valider" dans le rond en bas à droite
2°) Choisissez "Sauver" dans le menu général.

Composition du TCO :

Ce TCO est volontairement orienté vers la vérification des données, plus que vers un gestionnaire.
Par exemple, il n'affiche pas la position des appareils de voie (les lames).
Il affiche des panneaux de signaux complets avec tous les feux allumés en même temps …
Il y a un code couleur des zones :
Noir pour les gares
Violet pour les zones de manœuvres
Noir large sur Aqua pour les zones d'approche de gare
Noir étroit sur Aqua pour les zones de sortie de gare
Violet large sur Aqua pour les zones d'approche de manœuvres ou Violet large sur Noir si on est en gare.
Ce code couleur n'est utile que pour les vérifications et n'aura pas d'intérêt dans le gestionnaire.

Signaux :

Une particularité des panneaux de signaux SNCF est qu'il est impossible d'avoir, sur le même panneau, à la fois l'affichage du Carré et du Carré violet (les feux sont au même endroit).
J'ai donc décidé que, si l'on doit pouvoir afficher C et Cv au même endroit, il faut deux feux : un sur poteau et un au sol pour le Cv.
Dans les zones de manœuvres, j'ai décidé de faire figurer tous les feux, puisque chaque zone est banalisée. Mais les feux virtuels sont simplement affichés par un rond vide.
J'aimerais bien faire figurer ici les vitesses limites, toujours dans un but de vérification des entrées, mais il n'y a pas beaucoup de place…

Impression :

Il suffit de faire une copie-écran et l'imprimer. Mais comme j'ai pitié des cartouches d'imprimante, on peut mettre un fond blanc avant de faire la copie-écran en appuyant sur la bascule "Fond", en bas à gauche.

Pages: [1] 2 3 ... 52