Messages

1

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

« le: mai 23, 2024, 04:24:15 pm »

@ Denis

Quelques remarques sur ton deuxième post

Auparavant, on a permis l'affichage de S, A, VL (Sémaphore, Avertissement, Voie Libre) sur tous les signaux.

- a propos de Vl, les carrées d'entrée des gares terminus n'affichent jamais Vl
- a propos de S, ce feu n'est utilisé que pour le cantonnement (BMU,BAL,BAPR, ...), sur un réseau il peut avoir de parties sans cantonnement (donc avec des signaux sans S)

Remarque : (on l'a déjà dit dans un précédent post) un signal de gare gérée par itinéraires n'affiche pas le S. Donc, quand je donnerai à toutes les voies de gare la possibilité d'afficher le C, il faudra effacer le S.

- dans les postes avec des itinéraires permanent, s'il y a du cantonnement, certains carrés peuvent présenter le S, pour assurer la continuité du cantonnement à la traversée d'un gare, d'une bifurcation , ...
- dans les postes avec du transit souple, s'il y a du cantonnement, les carrés peuvent s'ouvrir au sémaphore (S)

Il n'y a qu'un signal de manœuvre : le Cv (Carré Violet). C'est le seul qui ne soit pas un signal de cantonnement.

- il peut avoir d'autres signaux qui ne soient pas des signaux de cantonnement (avertissement, carré, ...)
- il y a un autre signal de manoeuvre, dans les grandes gares un feu de manoeuvre (M : blanc) peut être utilisé pour les départs en manoeuvre sur les carrés (compter les feux des signaux de grande gares : 5 feux (A, S, Vl, M, C)

Pierre

2

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

« le: mai 23, 2024, 01:51:29 pm »

@ Denis

Il y a deux types de limitation de vitesse.
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
- Les limites liées à une position déviée d'aiguille.

Les TIV sont surtout utilisés en ligne, même en présence d'aiguilles  (en talon). En présence d'aiguilles en pointe, si la vitesse est limitée à 30 ou 60 on utilise de RR30 ou RR60, sinon un TIV est utilisé. Il y a même des cas ou un RRxx et un TIV sont utilisés pour deux vitesses différentes suivant la position d'aiguilles.

A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant.

C'est quoi une marche avant ou une marche arrière (par rapport à quoi).

Pierre

3

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

« le: mai 23, 2024, 12:03:27 pm »

@ Denis

Au sujet de ton premier post.

Je fais la distinction car j'impose aux signaux de n'être que sur des sections

Ce n'est pas toujours possible. Tu parles de la Z46, en fait la Z46 ne comporte qu'une aiguille (a20) et c'est la Z38 comporte l'aiguille a10 et le carré violet, carré violet qui est sur une zone avec aiguille. Juste après un signal il faut un changement de zone pour aubiner le signal, sinon il faut une pédale (ou balise) pour le faire.

Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.

Les zones Z16 et Z30 sont aussi des zones de manoeuvres, mais ne sont pas en blanc ! en fait ce sont des zones hybrides ligne/manoeuvre.

Concernant les paritées, j'ai abandonné, dans le gestionnaire, les cotés 0/1 ou 1/2 pour des cotés pair/impair, c'est beaucoup plus simple. Et ceci pour toutes les zones. Cela implique aux changements de zone des transitions pair vers impair ou impair vers pair.

Pierre

4

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

« le: mai 10, 2024, 10:53:44 am »

Bonjour

Concernant les bretelles avec entrevoie courte (ou pas), la sncf couple souvent les deux aiguilles, cela se voit sur les TCOs avec les numéros d'aiguille (genre 123a et 123b), les deux aiguilles sont manoeuvrées ensembles. Voir par exemple sur le TCO de Méru https://www.utc.fr/~wschon/sr06/Simulateur-PRS/index_dev.html les aiguilles 103a et 103b ainsi que 109a et 109b.

Cette disposition évite les problèmes avec les caisses de véhicules débordant des essieux, elle évite aussi des dérives de trains pouvant conduire à des accidents.

J'ai fait des essais avec le gestionnaire json.

Pierre

5

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

« le: mai 07, 2024, 11:29:32 am »

@ 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

6

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

« le: mai 05, 2024, 05:12:19 pm »

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

7

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

« le: mai 05, 2024, 11:20:54 am »

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

8

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

« le: avril 29, 2024, 10:44:25 am »

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

9

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

« le: avril 12, 2024, 10:38:21 am »

@ 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

10

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

« le: avril 07, 2024, 11:08:07 am »

@ 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

11

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

« le: avril 06, 2024, 11:01:04 am »

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

12

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

« le: mars 28, 2024, 10:31:19 am »

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

13

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

« le: mars 27, 2024, 11:46:37 am »

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

14

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

« le: mars 25, 2024, 06:39:31 pm »

@ 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

15

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

« le: mars 25, 2024, 10:46:02 am »

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