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 ... 50
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: Aujourd'hui à 10:25:33 am »
Bonjour,

Aujourd'hui : les itinéraires.

Il existe dans le programme un bouton "Itinéraires" qui donne tous les itinéraires entre un point A et un point B quelconque sur le réseau. C'est anecdotique.
C'est juste pour voir ce que ça donne. Je supprimerai certainement ce bouton par la suite.

En revanche, il y a un autre bouton, le bouton "Analyse", qui, lui, donne 3 tables qu'on peut lire par la suite dans Excel :
_TOUS_ITI____.tsv qui liste tous les itinéraires possibles du réseau
_TOUS_ITI_G__.tsv qui ne liste que ceux des gares
_TOUS_ITI_M__.tsv qui ne liste que ceux concernés par les zones de manœuvres.

Le fait que ce soit sous forme de tables est, là aussi, anecdotique.
Mais c'est utile en phase de développement.
C'est, comme le nom de la variable le dit bien : "littéral", c’est-à-dire lisible par un humain et il faudra qu'on décide ce qu'on garde pour le fichier JSON et sous quelle forme plus compacte.

Comment se calcule un itinéraire ?

Voici un exemple très simple :


 
En bleu, comme précédemment, les signaux, en rouge le "cote0" et, en "non rouge", le "cote1".

Je ne raisonne pas en aiguille à gauche/à droite, mais je considère les "lames" d'un appareil de voie.
Pour l'aiguille en Z5, quand les lames sont à 0 (= "L0"), on est "tout droit", de A à B.
Pour l'aiguille en Z5, quand les lames sont à 1 (= "L1"), on est "dévié", de A à C.
Pour la TJD Z2, quand les lames sont à 0, on va de A à B, en 1, on va de C à D, en 2, on va de A à D et en 3, on va de C à B.
Je n'ai ainsi qu'une seule variable à suivre pour connaitre la position des lames dans n'importe quel appareil de voie.

Evidemment, une section a les "lames" à 0…

Je veux aller de Z1, cote1 vers Z6, cote0.

J'ai 2 procédures dont le nom dit bien ce qu'elles font :
- connecteur_mitoyen(zone, connecteur)
- connecteur_suivant(zone, connecteur)

On démarre par connecteur_mitoyen(Z1, 1).

Les connecteurs d'une zone sont repérés par 2 variables : zone.connecteur[cote][lames]

Donc, on part de Z1.connecteur[1][0] et, en raisonnant sur les voisins, on trouve que le connecteur mitoyen est Z2.connecteur[0][0] (on démarre par lames à 0), c’est-à-dire A.
Puis on passe au connecteur suivant qui est le Z2.connecteur[1][0], c’est-à-dire B.
Connecteur mitoyen = Z3.connecteur[0][0]
Connecteur suivant = Z3.connecteur[1][0] qui est un butoir. Le mitoyen d'un butoir, c'est lui-même et on est dans le sens retour.
Connecteur suivant = Z3.connecteur[0][0] sens retour
Connecteur mitoyen = Z2.connecteur[1][0] sens retour, c’est-à-dire B
Connecteur suivant = Z2.connecteur[0][0] sens retour et comme on a mémorisé la première entrée dans Z2 dans une variable indépendante, on repart dans le sens aller, mais on avance les lames, ce qui fait qu'on repart de Z2.connecteur[0][2], c’est-à-dire A
Connecteur suivant = Z2.connecteur[1][2], c’est-à-dire D
Connecteur mitoyen = Z5.connecteur[2][1], c’est-à-dire C
Connecteur suivant = Z5.connecteur[0][1], c’est-à-dire A
Connecteur mitoyen = Z6.connecteur[1][0]
Connecteur suivant = Z6.connecteur[0][0] qui est le connecteur final.

Le Diable se cachant dans les détails, c'est, évidemment, plus compliqué que ça, mais on a là une bonne idée de ce qui se passe.

Calculer tous les itinéraires d'un réseau :

Avant de se lancer dans des boucles imbriquées, on va calculer combien de recherches d'itinéraires on va avoir.
Le réseau de Dominique comporte 47 zones.
A priori, on a 47 zones x 2 cotes x 47 zones x 2 cotes = 8 836 itinéraires.
C'est beaucoup, mais c'est gérable.
Première simplification : on part et on arrive sur une section. Il y en a 31.
Deuxième simplification : on n'arrive pas sur la même zone que celle du départ.
Donc 31 x 2 x 30 x 2 = 3 720 itinéraires.
On a gagné 60% des tests !
for (Zone zone0 : toutes_zones) {
    //-------------------------------- on balaie toutes les zone0----------------------------------------
    if (zone0.type == 99) {
        //---------------------------- on part obligatoirement d'une section ----------------------------
        for (int cote0 = 0; cote0 < 2; cote0++) {
            //------------------------ on teste les 2 cotés de la zone0 ---------------------------------
            for (Zone zone1 : toutes_zones) {
                //-------------------- on balaie toutes les zone1 ---------------------------------------
                if ( zone1.type == 99) {
                    //---------------- on part obligatoirement d'une section ----------------------------
                    if (zone1 != zone0) {
                        //------------ on ne peut pas avoir zone0 = zone1 -------------------------------
                        for (int cote1 = 0; cote1 < 2; cote1++) {
                           compte_ori_ext++;
                           zone_depart  = zone0;
                           cote_depart  = cote0;
                           zone_arrivee = zone1;
                           recherche_itineraires(zone0.connecteur[cote0][0], zone1.connecteur[cote1][0]);
                        }
                    }
                }
            }
        }
    }
}

Dans la pratique, on n'a que 579 itinéraires possibles et le calcul ne prend qu'une seule seconde. Et on ne fait pas que ça.

Je calcule également les itinéraires des gares, c’est-à-dire que je limite les sections de départ et d'arrivée : on part d'une zone en ap_g0 vers une zone en g0 (champ gare) ou on part de g0 vers so_g0. Et pareil pour g1.
On trouve 18 itinéraires sur 128 testés.

Enfin, on calcule aussi les itinéraires de la zone de manœuvres.
On trouve 30 itinéraires sur 288 testés.

A chaque fois, on obtient une table qui donne, en littéral, les itinéraires trouvés.

Maintenant, je pose deux questions :
- Ai-je bien trouvé tous les itinéraires possibles (surtout en gare et en manœuvres) ?
- Sous quelle forme doit-on les rentrer dans le JSON ?

Une autre question se pose :
A quoi cela peut-il servir de calculer TOUS les itinéraires d'un réseau ?

Cela sert à calculer où on doit implanter des RR (Rappel de Ralentissement) et, par la suite les R (Ralentissement).
On a vu dans mon précédent post que les limites de vitesse sont distinguées en "RR" et "TIV".
Donc, si, dans la liste de l'itinéraire, on a une vitesse "en RR", on remonte dans l'itinéraire jusqu'à arriver sur une section qui aura donc un signal RR.

Remarque :
Cela ne veut pas dire que, dans le même itinéraire, on pourra remonter jusqu'à trouver la section précédente.

Exemple : on est dans l'itinéraire Z25 -> Z28.
Aussi bien dans Z44 que dans Z26 en position déviées, on a une limite à 30 km/h.
Donc, il y a bien un RR affiché dans le signal de Z25.
Mais l'itinéraire n'est pas assez long pour qu'on puisse aller jusqu'à Z22 ou Z23 qui, eux, auront un R qui justifiera du RR en Z25.
Donc, dès qu'on sait que le signal de Z25 peut afficher RR, on sort de la boucle.
Et, à la fin de ces boucles, on a tous les signaux susceptibles d'afficher RR.
Et il faut repartir dans les d'autres boucles pour déterminer les R dans la section précédant la section ayant un RR.
Et c'est là que Z22 et Z23 auront un signal susceptible d'afficher R.

Remarque :
Il existe 2 types de R/RR : le R/RR30 et le R/RR60. Ils se gèrent de la même façon.

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

On a deux types de C :

1°) Le C "d'impossibilité de continuer", lié au fait que les lames des appareils de voie sont dans une position qui ne vous permet pas d'avancer. Exemple : vous arrivez par la voie déviée d'une aiguille et les lames sont en position "tout droit".
Remarque : il existe à la SNCF une possibilité technique de continuer quand même si c'est prévu et que cette aiguille est "talonnable".
Je pense que ce n'est pas une bonne idée en miniature. Il y a déjà tellement de possibilités de dérailler que ce n'est pas la peine d'en rajouter…

2°) Le deuxième type de C est complètement différent : c'est l'aiguilleur qui gère la gare qui l'affiche ou le retire quand toutes les conditions (sécurité, horaires, …) sont remplies.
Exemple : Le train que vous prenez est déjà là, 20 minutes avant le départ. Il y a peu de trafic et e l'itinéraire est déjà "formé". Si le train avançait, il n'y aurait aucune impossibilité technique, toutes les aiguilles étant déjà "en position". Mais il n'est pas l'heure, ou d'autres raison peuvent être évoquées, et l'aiguilleur fait afficher le C au signal devant le train.
Quand il le décidera, il éteindra le C et le train pourra partir.

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. Cela vaut aussi pour les zones d'approche.

Signaux de manœuvres :

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.

Dans la pratique, il y a moins de signaux que sur les voies principales car les trais roulent "à vue", à 15 km/h maxi.
Ils sont indispensables aux frontières zone de manœuvre/voies principales et pour les zones d'approche de la zone de manœuvre. Après, les règles sont floues…

Signaux au-dessus des butoirs :

Il s'agit obligatoirement de carrés ayant la particularité de n'avoir qu'un feu, au milieu du butoir.
En zone de manœuvre, ce sont des Cv (et donc violets) (Z18, Z19, Z20 et Z21) et des C (et donc rouges) sur voies principales (Z40 et Z41)


Voilà donc comment, en appuyant simplement sur le bouton "Analyse", on calcule tous les itinéraires et les signaux d'un réseau. Le tout en une seconde chrono !

Denis  :P

2
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 21, 2024, 05:07:32 pm »
Bonjour,

Depuis des années, je suis persuadé qu'on peut calculer les signaux à partir du dessin du réseau et quelques infos simples.

La vraie question qui se posait, c'était de savoir quelles infos étaient absolument indispensables.
Je viens de franchir une étape que je vais vous détailler.

Je vais le faire sous forme d'une série de posts. Le programme sera proposé dans le dernier post.

Pour l'instant, il sort plusieurs fichiers complets, faciles à lire (et à comprendre, j'espère), mais il faudra en extraire les infos utiles au fichier JSON en ce qui concerne les signaux et les itinéraires.
En gros, il y a "trop" d'informations et il ne faudra garder que celles absolument nécessaires au gestionnaire. Par exemple, quand il y a plusieurs itinéraires entre un point A et un point B, lequel choisir ?

Infos minimales :

Je prends comme exemple le réseau de Dominique qui est assez représentatif des difficultés rencontrées par de nombreux modélistes.


 
Sur ce dessin, sont représentés les infos qui doivent être rentrées dans mon programme pour que tous les calculs soient faits.
Il faut faire ce dessin, avant de rentrer les infos.
 
Dès le dessin, il faut prendre des décisions : sens de circulation des zones, leur nom, la position des signaux.
 
A noter que j'ai retiré les numéros de voie et je n'ai gardé que les noms de zone.
On pourra, par la suite, donner des numéros de voie, mais ils ne serviront pas dans un gestionnaire.

Sont représentés :

1°) Le dessin du réseau :

En rose, les "appareils de voie" (aiguilles, TJD, croisements, …).
En bleu, les "sections", c’est-à-dire tout ce qui n'est pas un appareil de voie (rails droits, courbes, flexibles)

Exemple : Z17 est un appareil de voie (une aiguille) et Z16 est une section.

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

Une première difficulté apparait sur la Z46 qui est, pour moi, une "zone complexe". Elle est composée de l'aiguille a20, d'une section de longueur nulle qui supportera le signal et de l'aiguille a10.
Dans le programme actuel, la Z46 est une TJD sans signal.
C'est une erreur, mais je réserve pour la suite le traitement des zones complexes. J'ai une idée assez précise de ce que je vais faire, mais on en parlera plus tard. Il y a déjà assez de questions à se poser avant.

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

Je considère qu'il y a 2 gares : la gare g0 en bas (hors zone de manœuvres) et la gare g1 en haut.

Par ailleurs, une navette se promène sur les zones vertes (de Z40 à Z41).
 
Je n'ai pas considéré que Z40+Z0 et Z41+Z3 soient des gares, mais on aurait pu le faire car, dans la réalité, ce serait le cas.
Mais l'intérêt de déclarer un ensemble de zones comme étant une gare, c'est qu'on peut attribuer des itinéraires à cette gare. Et là, … les itinéraires…

2°) L'orientation des zones (les flèches rouges) :

Toute zone a un sens privilégié, ne serait-ce que pour la dessiner.
Je préfère raisonner par "côtés" (voir un précédent post à ce sujet).
Le sens privilégié (la grosse flèche) va du "cote0" au "cote1" (de A à B). Donc, quand vous sélectionnerez une section, vérifiez bien que le sens que vous avez choisi correspond bien à celui du dessin du réseau.
Pour les appareils de voie, j'ai fait un récapitulatif des différents cas :


 
Le point rouge correspond au cote0, les autres extrémités étant cote1. Je reviendrais sur ce schéma dans les itinéraires.

Le point bleu sur le dessin du réseau correspond à la présence d'un signal.
Pour les zones n'ayant qu'un seul sens de circulation, le signal est toujours "cote1".
Pour les zones ayant les deux sens de circulation (les zones "banalisées"), on a une deuxième flèche, plus petite.
Pour moi, les zones banalisées "ont un sens". Pensez-y en choisissant où vous mettez les feux (côté A ou côté B dans le programme) : il y a un signal "cote0" (= A) et un signal"cote1" (=B).

3°) La parité :

On n'a pas à rentrer spécifiquement la parité d'une zone.
Rien qu'en choisissant une section sur l'octogone de départ, vous définissez la parité de la zone. Puis, par itération successives, le programme calcule la parité des appareils de voie.
Par exemple, la zone 24 est déclarée "sens impair" par le fait que les zones Z22, Z23 et Z25 sont impaires.
La parité d'une zone est donc calculée et entrée directement dans le fichier JSON pour usage ultérieur dans un gestionnaire. Les zones banalisées sont dites "pairimpair".

4°) Zones complexes :

Pour l'instant, chaque appareil de voie est une zone à lui tout seul. Ce n'est pas toujours le cas dans la réalité.
On regroupe souvent des appareils en une seule zone ou une zone peut être constituée d'une section et d'un appareil de voie. C'est ce que j'appellerai une "zone complexe", pour l'instant non gérée par le programme actuel. A suivre, donc.

5°) Les vitesses limites :

J'ai défini (arbitrairement) la vitesse maxi à 160 km/h.
Il y a deux types de limitation de vitesse.
 
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
On la rentre simplement dans la section en cliquant sur le point blanc sur le tracé de la zone. On affiche alors la vitesse qui apparait dans un losange sur le dessin de la zone.
Dans les fichiers d'itinéraires, la vitesse limite sera alors suivie de "TIV".

- Les limites liées à une position déviée d'aiguille.
On la rentre de la même façon sur la branche concernée du dessin de l'appareil de voie.
Elle est également affichée dans un losange sur la branche concernée.
Dans les fichiers d'itinéraires, la vitesse limite sera alors suivie de "RR".
On verra dans le calcul des signaux que cette info est cruciale.

A noter que la vitesse limite dans la position "tout droit" est une limite de type TIV.

6°) Le calcul des zones de gare :

Les gares sont parfois importantes et, même si on peut rentrer ces infos à la main, zone par zone, cela peut être très fastidieux. J'ai donc développé un programme qui complète automatiquement les infos rentrées.
Dans une première version, j'arrivais à définir les gares en ne définissant qu'une seule zone. Mais il fallait des gares vraiment particulières.
Dans cette version, il faut rentrer les infos de zone d'approche et de zone de sortie, le programme ne pouvant pas toujours les définir automatiquement.

Dans le cas de la gare0 du réseau de Dominique, on rentre :
En zone 11 : "ap_g0" dans le champ "gare". C'est la zone d'approche de la gare0.
En zone 16 : "so_g0" dans le champ "gare". C'est la zone de sortie de la gare0.
En zone 25 : "ap_g0" dans le champ "gare". C'est la zone d'approche de la gare0.
En zone 30 : "so_g0" dans le champ "gare". C'est la zone de sortie de la gare0.
Et on rentre "g0" dans la zone 27, ce qui devrait permettre de calculer la gare.
Malheureusement, ça "bave" sur la zone de manœuvres qui se trouve ainsi déclarée "gare", ce que je ne veux pas.
Il faut donc, en plus rentrer "bloque" en zones Z36, Z45 et Z46. Et là, tout est OK.

7°) Le calcul des zones de manœuvres :

C'est un calcul similaire au calcul d'une gare, mais il n'y a pas besoin de bloquer puisque la gare est déjà définie et elle va bloquer l'expansion de la zone de manœuvres.
Il faut juste entrer :
En zone 16 : "ap_m0" dans le champ "manœuvres". C'est la zone d'approche de la zone de manœuvres 0.
En zone 30 : "ap_m0" dans le champ "manœuvres". C'est la zone d'approche de la zone de manœuvres 0.
Puis Z36 et Z37 définies comme "m0".

A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant. Les zone Z16 et Z30 sont donc banalisées.

Une zone de manœuvres est toujours banalisée.
 
Il s'ensuit que la zone de gare Z14 est forcément banalisée à cause de Z45 et Z46 banalisées, ainsi que la zone de gare Z28 à cause de Z36.

Voilà, on a fait le tour de toutes les infos nécessaires au fonctionnement du programme.

On voit qu'elles sont chacune assez simple à déterminer et que les connaissances de la SNCF sont très minces pour mener à bien cette mission.
Tout le reste est automatique.

En PJ, le réseau en plus grand, plus lisible, les appareils de voie, imprimables et le fichier "Zones" initial en .tsv (à ouvrir dans Excel) dans lequel on voit qu'il y a plein de cases vides...
On y voit aussi les cases remplies via les dessins de zones. On ne rentre rien directement dans le fichier sous peine d'erreurs et d'incohérences.

A suivre : les itinéraires

Denis :P

3
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 09, 2024, 02:48:12 pm »
Bonjour Pierre,

Le problème que tu poses n'est pas lié au PRS, il est, en effet beaucoup plus général.

Comme tu le sais déjà, il s'appelle à la SNCF la "limite de zone de garage franc", symbolisée, à la SNCF, par une marque blanche qui indique l'endroit à partir duquel un véhicule (loco ou wagon, voiture, ...) engage le gabarit d'une voie voisine.
C'est même en vente chez Décapod, pour info (voir fichier joint).

Concernant le matériel en miniature, comme la détection se fait par détection de courant, c'est donc au niveau des roues que l'on détecte une présence.
Et, particulièrement pour les voitures (ou tout matériel à bogies), il y a un bon écart entre le tampon et la roue... ce qui n'arrange rien.

Ce qui m'embête aussi, c'est que je n'ai aucune idée de la façon dont la SNCF gère le problème que tu soulèves.
Parce que mettre un repère blanc, c'est bien, mais ça ne résout pas le problème.

A mon avis, en gérant les longueurs de train (en comptant les "points" dans l'image à l'écran, par exemple), on devrait pouvoir s'en sortir.
Mais un train virtuel ne perd jamais ses wagons...
Je pense que le vrai problème se pose quand les wagons se décrochent.

Denis

4
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 04, 2024, 07:08:45 pm »
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 2 secondes la liste des 2288 itinéraires possibles de ton réseau, parmi 3720 couples départ/arrivée testés  :P

Denis

5
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 30, 2024, 02:56:32 pm »
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

6
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 30, 2024, 02:02:33 pm »
@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

7
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 30, 2024, 11:58:47 am »
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

8
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 11, 2024, 11:30:59 am »
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

9
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 27, 2024, 08:32:06 am »
@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

10
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2024, 09:24:43 am »
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

11
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 09:57:08 pm »
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

12
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 05:21:49 pm »
@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

13
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 10:04:03 am »
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

14
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 08:32:30 am »
@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

15
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 20, 2024, 05:41:12 pm »
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

Pages: [1] 2 3 ... 50