Auteur Sujet: Modélisation logicielle d'un réseau - le système de Denis  (Lu 68327 fois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #45 le: août 05, 2018, 10:22:45 am »
Non, le Processing.exe de ton Mac (ce serait pareil avec un PC) a gardé le chemin de la dernière fois que tu as été chercher des data.

Donc, dans la fenêtre où on te demande de choisir le fichier, tout en haut, il est sur une directory "data", mais pas la bonne.
Remonte dans l'arborescence et choisis la bonne directory qui sera dans la V6-32.
Tu dois être dans une version antérieure à la V6-24.

Rassures-toi : une fois ce choix fait, Processing gardera le chemin vers la V6-32.
Mais, la première fois, il faut aller au bon endroit.
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #46 le: août 05, 2018, 02:48:10 pm »
C'était bien ça, Processing pointait sur un ancien dossier data ailleurs dans les anciennes versions.

C'est dommage que ton programme ne puisse pas récupérer son propre chemin d'accès pour éviter ça en partant du principe que le dossier data serait au même niveau !

Bon en lançant le programme avec l'un ou l'autre des .tsv dans le dossier date 'circuit_d'essai" ou "TCO____2018_07_30__17_31_34", ça plante encore plus grave avec même pas de barre de menu en bas et une "ConcurrentModificationException", dans l'onglet TCO à la ligne 22 où il y a "        for (Pave pave : tous_paves1) {"

et toujours :

Citer
2018-08-05 14:24:50.094 java[22667:4930413] pid(22667)/euid(502) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
objc[22667]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fffaf02ec90) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x1631a0cd8). One of the two will be used. Which one is undefined.

En ouvrant un circuit vide (annuler au lieu de choisir un .tsv), j'obtiens une exception pour pointeur null dans Mouse ligne 21
"                    pave_feu_noir.feu_noir[cote_feu_noir] = true;"
en tentant de sélectionner un itinéraire sans circuit  :-*
Je sais que c'est débile mais ça ne devrait pas planter !

Donc visiblement tu as fait de gros progrès et je dois pouvoir tester un peu maintenant. Dommage, je m'absente quelques jours. Je reprendrai à mon retour.

Amicalement
Dominique
Cordialement,
Dominique

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #47 le: août 05, 2018, 07:13:19 pm »
Merci Dominique, c'est sympa de bien vouloir tester.

Voyons les bugs (que j'ai malheureusement déjà trouvés aussi ...  :-[) :

1°) Choisir automatiquement la bonne directory.

Dans Processing, pour choisir un fichier, je dois obligatoirement mettre dans le setup() :
selectInput("Selectionnez un fichier pour determiner le repertoire de demarrage : ", "fileSelected");
Cela a un premier défaut :
-> Cela génère une page blanche sans intérêt au départ

On peut alors choir le fichier dans la fenêtre qui apparait.
Deux cas :
-> On est en adressage absolu (il existe getAbsolutePath dans Processing) et c'est mal barré parce qu'il faudra changer V6_32 en V6_33 si on a une nouvelle version.
Donc, très mauvaise idée
-> On est en adressage relatif (sauf que getRelativePath n'existe pas  :-[) et là, je cale. Ce serait bien.
Et c'est Processing qui mémorise la dernière directory, avec le problème que tu soulevais.

2°) "ConcurrentModificationException" (à cet endroit)

Figures-toi que ce n'est pas parce qu'on choisit un mauvais fichier, c'est ... parce qu'on sélectionne trop vite !!!  ??? ??? ???
Ailleurs, j'ai une explication (il y en a plusieurs) et je résous le problème. Mais, à cet endroit, je n'ai pas d'idée.
En quoi la rapidité de sélection peut influer ?
Il faut compter jusqu'à 2 avant de cliquer. C'est débile  :o

3°) En choisissant "annuler" :

Je n'ai jamais eu ça (et ce n'est pas faute de l'avoir fait).
On a ce que tu décrivais dans ton précédent post : un pupitre out petit (à l'échelle 1), au point 0,0. Et un menu. Et évidemment, pas de circuit.
C'est bizarre

Amicalement
Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #48 le: août 09, 2018, 06:01:21 pm »
Je viens de régler le cas 3°) du précédent post : on peut maintenant reculer n'importe où. Il faut quand même s'arrêter avant  ;)
C'était quand même la moindre des choses…

Je profite de ce problème pour expliquer comment je raisonne pour gérer les itinéraires.
Disons que c'est assez original. Assez pour qu'on n'ait pas besoin de bouton d'inversion.

Quand un train se déplace, il va d'un point à un autre.
Cela peut paraitre évident, dit comme ça, mais c'est beaucoup plus profond.
On va donc définir des "points" qui seront les positions possibles des véhicules (loco, wagons et voitures). Cette brillante idée est due à Pierre59, dans le Locodrome.
On calcule les points dans les pavés, puis ces points, de proche en proche, recouvrent tout le réseau, au fur et à mesure qu'on ajoute les pavés pour construire le dessin du réseau.
On remarquera que ces points ont des coordonnées fixes, une fois le réseau défini.

Je n'utilise pas les points de la même manière que Pierre59, mais je ne sais pas si ma méthode est la meilleure. Elle est juste différente.

Je pars du fait qu'un train (au sens large : ce peut être une loco "haut le pied") doit forcément être sur un itinéraire. ;) ;)

Et un itinéraire, c'est aussi au sens large, comme expliqué précédemment : on peut très bien avoir un itinéraire entièrement en pleine voie, sans aucun appareil de voie ("SAV", voir un précédent post). Un train avance sur son itinéraire et "est transféré" sur l'itinéraire suivant. La dernière zone d'un itinéraire devient la première zone du nouvel itinéraire. Et ainsi de suite.

J'utilise une possibilité tout à fait courante à la SNCF : le carré manuel.
Comme un train ne peut pas quitter un itinéraire, on lui mettra un carré manuel à l'extrémité, sauf, évidemment, s'il est chaîné à un itinéraire suivant.
Si on parcoure une boucle fermée, on ne verra jamais apparaitre ce carré manuel.
Si on arrive sur une voie de gare, ce carré sera tout à fait à sa place classique.
Mais c'est une sécurité pour qu'un train ne sorte pas de son itinéraire (si c'est le dernier de la chaîne).

Maintenant qu'un train a son itinéraire, on sait tout sur lui. C'est pour ça que je raisonne comme ça.
On a en effet une échelle d'une incroyable précision : les points.
Pour vous donner une idée, depuis le coin en haut à gauche au coin en bas à droite, il y a plus de 7000 points ! :P
On connait la position de chaque signal et, en particulier celui que voit le conducteur du train.
On connait la position de chaque véhicule, que ce soit la loco, les wagons, …
On en déduit évidemment les zones occupées, celles qui se libèrent.

Et ça résout surtout une question que je me posais depuis 1990 (!) :o

Je raisonne en me disant qu'on a 128 crans de vitesse, de 0 à 127.
Si un train roule au cran 127, je considère qu'il avance de 127 points à chaque fois.
Au cran 100, on avance de 100 points, c'est-à-dire qu'on redessine le train 100 crans plus loin.

Puis je définis une zone de freinage, égale à 10 fois la vitesse du train. Pour l'instant, le facteur 10 sera l'objet d'essais. Si ça se trouve, il faudra 5 ou 20. On verra. Mais, pour l'explication, mettons 10 fois.
Donc, si le train roule au cran 127, il lui faudra une distance de 1270 points pour s'arrêter et 1000 points pour une vitesse au cran 100.
Vous constatez que c'est linéaire, ce qui n'est pas du tout le cas d'une courbe de décélération qui ressemble plutôt à une décharge de condensateur. Mais ça n'est pas grave :



En regardant ce schéma (issu de vraies mesures), on constate qu'il y a trois zones :
1°) La zone de décélération proprement dite
2°) La zone de vitesse constante à la vitesse de ralenti. Ici cran 10
3°) A 100 points du signal, on passe de 10 à 0 et le train s'arrête.
Il a bien mis 1270 points pour s'arrêter.
En fait, la variable d'adaptation, c'est la zone à vitesse ralenti.
On peut avoir une distance de freinage qui varie linéairement avec la vitesse, tout en ayant une courbe de décélération non linéaire.

Et c'est là que ça devient novateur.


On est à 1270 points du signal rouge (SEMAPHORE ou CARRE) et on démarre le freinage. On s'arrêtera pile où on voulait, exactement à 100 points du signal.
Mais à 1270 points du signal, où est-on ?
Prenons un cas classique :



La longueur de la zone comprise entre le signal CARRE et le signal AVERTISSEMENT (en vert sur l'image) est de plus de 2500 points.
Et donc le train va passer à fond (cran 127) au droit du signal d'AVERTISSEMENT, puis, à 1270 points du signal CARRE, il va s'arrêter à 100 points du CARRE.

Mais, dans cet autre cas :



On a un problème : la distance entre le CARRE et l'AVERTISSEMENT est supérieure à 1270 points.
Et on va devoir commencer à s'arrêter sur la zone d'AVERTISSEMENT.

Je ne connais pas beaucoup de gestionnaires de trains qui soient capables de freiner avant d'avoir croisé le signal d'AVERTISSEMENT. En général, tout se passe sur la dernière zone.

J'ai eu cette idée en 1990, mais c'est la première fois que je la réalise. ;D ;D ;D

Pour aller jusqu'au bout de l'explication, à la SNCF, si la zone d'arrêt est trop courte, on emploie le signal rouge clignotant qui, justement, prévient le conducteur qu'il faut commencer à freiner plus tôt que d'habitude.  Et c'est signalé sur sa feuille de route quand il prend son  train en charge.
Je n'ai pas encore géré le signal rouge clignotant. C'est prévu.

Gestion de la marche arrière :

Maintenant que vous avez suivi comment je gère les itinéraires, vous comprenez pourquoi je n'ai pas besoin de bouton de marche arrière : il suffit que je demande un itinéraire dans l'autre sens… et que je me sois arrêté.

"Accessoirement", il faut effacer tout ce qui restait à faire dans l'autre sens…
Et dès que la zone sur laquelle est le train devient la dernière de son itinéraire, le transfert d'itinéraire a lieu automatiquement. C'est "magique".

Voici la vidéo explicative :
Je crée 3 itinéraires chaînés et je décide, à un moment de m'arrêter et de repartir dans l'autre sens.
Je sélectionne un nouvel itinéraire, tout s'efface et c'est parti !

https://www.youtube.com/watch?v=Ylsb8KT9oFI&feature=youtu.be

Le programme qui fait ça est là :
http://www.locoduino.org/IMG/zip/train_tco_v1_6_33.zip
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 321
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #49 le: août 09, 2018, 06:21:02 pm »
Bonjour

Super, je vois que tu avance bien.

Pour obtenir un déplacement plus fluide des trains, j'avance toujours d'un seul point, mais pour respecter la vitesse le délai entre un point et le suivant dépend de la vitesse (0 à 127).

Pour les itinéraires j'essaie de respecter le plus possible ce que fait la SNCF, avec un point de départ et un point d'arrivée, les points de départ sont toujours devant un signal.

Ton système comptant les points avant un signal est assez astucieux pour faire les ralentissements. Mais un gestionnaire gérant des trains réels et non pas des trains virtuels ne peut pas trop utiliser ce système sauf peut être en implantant des balises sur le réseau.

Bon courage

Amitiés

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #50 le: août 09, 2018, 06:46:32 pm »
Merci Pierre, tes encouragements me vont droit au cœur  ;D ;D

Je ne suis pas trop pour installer des balises sur le réseau, à priori.
Je pense que les "balises" existent naturellement : le changement de zone.

Le but étant que les déplacements de trains virtuels soient synchrones avec les déplacement réel.
Il reste donc un gros boulot, parce que ça n'est pas gagné ! Ce n'est peut-être même pas possible...

Remarque : Je pense que ce n'est pas au gestionnaire de gérer lui-même les ralentissements. C'est plutôt le boulot de la centrale DCC (à mon avis).
Mais le gestionnaire doit donner le top pour lancer le ralentissement.
Ma gestion de la courbe, c'est un peu "pour le fun".

Citer
Pour les itinéraires j'essaie de respecter le plus possible ce que fait la SNCF, avec un point de départ et un point d'arrivée, les points de départ sont toujours devant un signal.
Moi aussi, c'est forcé. On est en phase.
Quand je dis "n'importe où", c'est pour dire que ça peut aussi être en pleine voie (pas forcément à côté d'un appareil de voie). Mais toujours au pied d'un signal.

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

fmd14

  • Newbie
  • *
  • Messages: 35
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #51 le: août 10, 2018, 10:36:48 am »
Bonjour,

Félicitation pour votre travail

je voudrais dessiner un réseau
je ne trouve pas l'éditeur de réseau  dans la avant dernière version

beau travail encore

FMD14
FMD14

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #52 le: août 10, 2018, 11:02:18 am »
Bonjour fmd14,

J'ai bien un éditeur (sinon, je n'aurais pas pu réaliser ce réseau  8)), mais je le trouve beaucoup trop lent.
A la lumière de mon expérience sur le TCO, je me rends compte qu'il doit bénéficier des mêmes accélérations dans le traitement.
Je dois donc le revoir pour l'améliorer... et trouver du temps pour le faire. ;)

Ceci étant, même quand l'éditeur sera amélioré, tu auras certainement remarqué que, pour l'instant, je suis dans les trains virtuels.
Je ne suis pas encore au point pour passer au réel. Mais c'est bien sûr prévu.  ;D

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #53 le: août 10, 2018, 11:07:52 am »
Pour bien comprendre la démarche de ralenti, je vais exposer quelques cas concrets et bien détailler.

Zone de freinage :




Sur le cas suivant, la zone1 fait 400 points et la zone2 fait 470 points.
La zone de freinage est égale à 10 x vitesse de consigne.

Supposons qu'un train arrive au cran 30. Il va donc mettre 300 points à s'arrêter.
Donc, juste quand il passe de la zone2 à la zone1, il commence à ralentir et s'arrête juste devant le butoir, à 100 points précisément car 300+100 = 400.

Maintenant, le train arrive au cran 77. Il va donc mettre 770 points pour s'arrêter.
Juste quand il passe de la zone3 à la zone2, le feu que voyait le conducteur, qui était à VOIE_LIBRE, passe à AVERTISSEMENT. Le processus s'enclenche et il s'arrête à 100 points du butoir car 770+100 = 400+470.

Enfin, un train arrive à fond, cran 127. Il devrait mettre 1270 points pour s'arrêter.
Mais il ne bénéficie pas de cette distance…
Tout est perdu ? Que nenni !

Observons de plus près la courbe de décélération :



Le train freine vraiment au début, sur 400 points, maintient une vitesse de cran 10 et ralenti jusqu'à l'arrêt sur 200 points.
Le top départ du ralenti final n'est pas donné par la courbe, mais par la position du signal.
En fait, à 300 points du signal, on démarre un ralenti linéaire sur 200 points.
Ce qui fait qu'on s'arrête à 100 points du signal.

Donc, le train arrive au cran 127 à 870 points du signal (zone1+zone2)
400 points plus loin, il est au cran 10. On est à 470 points du signal.
Il reste au cran 10 jusqu'à ce qu'il arrive à 300 points du signal et là, il termine son arrêt sur 200 points.
Il arrive donc à 100 points du signal, dans tous les cas, même si les zones sont courtes.

Ces exemples numériques sont sujets à évolution.
On a toute latitude sur la forme plus ou moins accentuée de la courbe de freinage, la décélération finale en 200 points, le facteur 10 de la zone de freinage, …

Ce que je voulais surtout mettre en exergue, c'est que le freinage ne démarre pas d'un point précis sur le réseau (ILS ou autre).

Et cela correspond vraiment à la réalité :
Le vrai conducteur d'un vrai train peut commencer à ralentir AVANT de passer au droit de l'AVERTISSEMENT, en fonction de sa vitesse à ce moment.
S'il arrive à fond, il ne va pas passer le signal d'AVERTISSEMENT à fond pour freiner à mort avant le CARRE. Il commencera avant, ce qui est beaucoup plus naturel.

Dans la pratique, il faut absolument que la centrale DCC fournisse, via le bus CAN, sa vitesse de consigne au gestionnaire.
Et que, dans l'autre sens, le gestionnaire oblige le train à freiner si la sécurité l'impose, indépendamment d'un ILS ou autre, juste parce qu'il le juge nécessaire.

Je sais : pas gagné !...

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #54 le: août 10, 2018, 12:46:42 pm »
Dans la pratique, il faut absolument que la centrale DCC fournisse, via le bus CAN, sa vitesse de consigne au gestionnaire.
Et que, dans l'autre sens, le gestionnaire oblige le train à freiner si la sécurité l'impose, indépendamment d'un ILS ou autre, juste parce qu'il le juge nécessaire.

Bonjour Denis,
Tu as tout à fait raison, c'est ce que j'applique dans mon réseau et qui sera démontré à Orléans le 11 Novembre sur le stand Locoduino.

La centrale que je réalise est entièrement pilotée par le gestionnaire de Pierre59 et elle dispose aussi de ses propres boutons de commande pour piloter 2 trains manuellement ou automatiquement.

Comme tu l'as très bien expliqué :

- La commande manuelle de la centrale remonte, via Can, les paramètres de conduite au gestionnaire qui les renvoie à la centrale sauf si la consigne est restrictive, auquel cas c'est cette consigne qui est transmise.

- Les accélérations et ralentissements sont gérés par la centrale, en fait sous forme de transition douce entre une vitesse de départ et une vitesse d'arrivée.

- Les vitesses 30, 60 et 90 km/h à l'échelle sont étalonnées dans la centrale pour chaque machine, c'est à dire que si le gestionnaire demande une vitesse de 30 (le cran 30 DCC), ce sera le cran DCC correspondant à la vitesse réelle de 30 km/h qui sera utilisé.
Cela implique que la centrale reçoive au moins 2 détecteurs de rétrosignalisation pour une mesure de vitesse. Avec le bus Can c'est facile.

De cette façon cela simplifie pas mal les contraintes sur le gestionnaire.

Dominique
Cordialement,
Dominique

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #55 le: septembre 06, 2018, 04:30:38 pm »
Mais pourquoi avoir fait un réseau aussi moche ?   ;D



Je suis bien d'accord qu'il n'est pas beau, c'est le moins que l'on puisse dire…
Je l'ai construit pour pouvoir tester tous les cas complexes, en me disant que, si ça marche avec un tel réseau, ça n'en sera que plus facile avec un réseau "normal".

Voyons dans le détail les pièges qu'il recèle.  >:(

Z0 :
Une zone courte pour savoir comment gérer un train long qu'on poserait là pour démarrer.
En fait, c'est comme si le train sortait d'un tunnel et on voit apparaître les véhicules au fur et à mesure de l'avancement du train.
Cet effet n'est utilisé que dans ce cas. Après, plus aucun véhicule ne disparaît (heureusement)

Par ailleurs, c'est une zone mixte qui comporte à la fois des AV (Appareils de Voie) et SAV (Sans Appareil de Voie) et que, comme on ne met pas de signal sur un AV, il est placé automatiquement en retrait du (ou des) AV de fin de zone.

Enfin, côté butoir, la cible apparait également en retrait, ce qui n'est pas le cas à la SNCF.
En effet, si on doit mettre un feu côté butoir, ce feu est SUR le butoir.
Une chose à corriger.

Z1 :
Une voie de garage classique.
Vous n'allez pas le croire : quand on part de Z0, c'est la zone qu'on trouve en dernier en recherche d'itinéraires, après 172 itérations !!
Cela est dû au fait que, comme l'aiguille de Z0 est en position tout droit, il faut avoir exploré toutes les autres solutions avant qu'on change la position de l'aiguille dans l'algorithme de recherche et qu'on trouve (enfin !) Z1. Mais cela ne prend que quelques milli secondes.

Z2 :
Zone mixte simple. Pour moi, la première fois que l'itinéraire trouvait un pavé "à l'envers".
On voit aussi, à gauche, une cible à moitié "mangée" par la voie du niveau inférieur.
Très facile à régler en décalant d'1/2 carreau vers la droite le niveau inférieur.
Ce bug pourrait aussi être réglé en dessinant les choses dans un autre ordre (les signaux en dernier), mais l'ordre choisi est celui qui est le plus rapide à dessiner et le temps est ce qu'il y a de plus dur à trouver dans un gestionnaire. J'y reviendrais.

Z3, Z4 :
Rien à dire de particulier.

Z5 :
Une aiguille triple. Plus complexe à gérer, avec une subtilité inhérente à sa construction à partir de formes (l'une des formes est "à l'envers" par rapport aux autres).
L'aiguille aurait pu être liée à la Z4, mais j'ai voulu tester une zone d'aiguille isolée.

Z6 :
J'ai volontairement omis le butoir pour cette voie de garage.
C'est une hérésie pour la SNCF, évidemment.
Mais je voulais que ce type d'erreur dans le dessin du réseau ne génère pas de plantage de l'application.
En fait, j'ai résolu le problème en ce sens qu'on ne peut pas sélectionner cette extrémité libre. On ne peut ainsi pas aller vers cette absence de butoir. La seule solution est donc de retourner dans l'éditeur et de rajouter un butoir.

Z6, Z7, Z8 :

Rien à dire de particulier.

Z9 :
Gestion d'une TJD.
Là, je peux dire que ça n'a pas été facile car il y a, à priori, de nombreux cas à gérer.
Jusqu'à ce que je remarque qu'en fait, on est en présence d'une aiguille simple pour chaque entrée !
De quelque côté qu'on aborde une TJD, on n'a qu'un seul choix : tout droit ou dévié.
En fait, c'est un peu plus complexe, mais l'idée est là.
Le cas d'une TJD qui servirait à faire une boucle de retournement est aussi traité.

Z10, Z11 :
Rien à dire de particulier.

Z12 :
Il fallait bien traiter le cas d'une zone qui soit sur deux niveaux. C'est le cas ici.
Beaucoup plus complexe qu'on pourrait le penser de prime abord.
De plus, c'est une boucle de retournement (voir Z15 à Z20).

Z13 :
La première zone comportant deux aiguilles.

Z14 :
Cette zone, coincée entre deux boucles de retournement, n'a pas posé de problèmes particuliers pour la recherche d'itinéraires, mais plus tard, lors de l'affichage des itinéraires.
Il faut afficher, de la bonne couleur et effacer au bon moment.

Z15 à Z20 :

Là, on attaque un gros morceau. 8)
Dans l'approche la plus basique de recherche d'itinéraires, si on repasse deux fois au même point, on abandonne la branche concernée.
Dans le fil de Jean-Luc (http://forum.locoduino.org/index.php?topic=167.30) de … 2016, il explique bien pourquoi il faut tenir compte du sens de passage quand on fait les recherches.
En particulier pour la boucle de retournement, évidemment.
Donc, si, en continuant la recherche en marche avant, on repasse par le même point, c'est qu'on est passé par une boucle de retournement.
On doit donc reculer dans la recherche pour revenir à ce point et repartir en avant pour parcourir la boucle dans l'autre sens !
C'est absolument indispensable pour pouvoir choisir n'importe quel point (signal) de la boucle.
J'ai compliqué le problème en mettant une voie d'évitement, pour pouvoir vérifier que tous les cas soient traités.

Z21 :
J'ai voulu vérifier qu'on arrivait bien à positionner les signaux sur un simple pavé, qui plus est en courbe. Et ça marche.
Une telle disposition n'aurait aucun sens à la SNCF, bien sûr. C'est un essai.

Accessoirement, je me suis posé la question de savoir si on devait allumer toute la zone Z21 en rouge (= occupation) si on allait, par exemple de Z23 à Z12.
Quand je dis "toute", je veux parler du pavé arc de cercle 45° qui ne fait pas partie du trajet.
Je ne trouve pas ça d'une esthétique folle, mais c'est indispensable à la logique SNCF : Si une zone est occupée, elle est toute entière allumée en rouge.

Z22 et Z23 :
Initialement, je n'avais mis qu'une zone, pour régler un autre problème soulevé par Jean-Luc, toujours dans le même fil.
La question était de ne faire qu'un seul passage dans la recherche d'itinéraires, de ne pas tourner en rond ad vitam aeternam.
Pas de problème, ça, ça marche.

Mais un autre problème, plus sournois, est apparu si on ne fait qu'une seule zone :
Un train dans la boucle et qui voudrait la parcourir (position des aiguilles de Z21 en position tout droit, comme sur le schéma) ne le pourrait pas !!
Si vous regardez bien, les signaux  de la boucle seraient tous deux à SEMAPHORE…
Donc, OK pour une boucle ronde, mais avec un minimum de deux zones… et un train plus court que la plus petite des zones (je développerais plus tard cette intéressante question plus générale)

Dernière remarque sur le schéma des zones :

J'avais pensé faire afficher par le programme le nom des zones.
Outre que ça n'est pas si évident que ça à faire, je pense que c'est inutile.
Je ne me sers jamais des noms des zones dans le programme et je viens seulement de réaliser ce dessin, en mettant le nom des zones directement à la main dans l'image.
Dans l'éditeur, j'ai bien besoin de nommer les zones (qui sont des ensembles de pavés), mais il faut juste que deux zones n'aient pas le même nom. C'est tout.

Apparaissent aussi les signaux, ce qui va me permettre de parler de la signalisation.

La signalisation

A la SNCF, on étudie la situation de chaque signal et on définit les conditions d'allumage de chaque feu. C'est forcément la meilleure méthode qui résout la totalité des cas rencontrés, y compris les plus complexes. C'est aussi la seule qui réponde à toutes les situations.

Cette méthode est appliquée par Pierre59 dans son article sur un gestionnaire en C++ http://www.locoduino.org/spip.php?article167
Y est décrit la façon permettant de se rapprocher le plus possible de la solution SNCF et c'est, en plus, un excellent article pour comprendre la programmation objet.

J'y ai appris de nombreuses choses et je programme aussi avec des objets (c'est génial).

Malheureusement, comme, par définition, je ne connais pas le réseau qui va être décrit, il faut que je travaille avec des règles plus générales, ce qui résout toutefois la quasi-totalité des cas rencontrés et, en particulier toutes les situations tordues de mon réseau d'essai.

Vous remarquerez que le schéma du réseau ne mentionne aucun numéro de signal, parce que ça ne me sert pas : c'est le programme qui fait les calculs tous seul.

Supposons que, d'un coup de baguette magique, je connaisse le signal suivant de chaque signal.
J'ai bien dit le suivant (dans les deux sens de circulation), tenant compte de la position des différentes aiguilles du réseau.

Je peux alors appliquer quelques règles simples (dans l'ordre) :

1°) S'il n'y a pas de signal suivant, je mets mon signal au CARRE.
Cela arrive dans le cas des butoirs (ce n'est pas, au sens strict, un CARRE, mais, en tout cas, c'est infranchissable !) et dans le cas des aiguilles prises en talon, lorsque c'est l'autre direction qui est sélectionnée.

2°) Si, pour aller au signal suivant, je rencontre un pavé occupé, je mets SEMAPHORE.

3°) Si le signal suivant est à CARRE ou SEMAPHORE, je mets l'AVERTISSEMENT.

4°) Si, pour aller au signal suivant, je rencontre une aiguille en position déviée limitée à 30 km/h (ou 60 km/h), je mets le signal à RAPPEL DE RALENTISSEMENT (30/60).

5°) Si le signal suivant est à RAPPEL DE RALENTISSEMENT (30/60), je mets RALENTISSEMENT (30/60).

On remarquera un aspect sympa : tout en recherchant le signal suivant, on peut noter, au passage, si on a rencontré un pavé occupé, une aiguille avec ralenti en position déviée. On ne perd pas de temps.

Comment marche la "baguette magique" ?

En fait, cela ressemble à une recherche d'itinéraire, mais en beaucoup, beaucoup plus simple :

1°) On ne va pas loin, on va juste au signal suivant.
2°) On ne change aucune position d'aiguille (surtout pas !) et donc c'est nettement plus rapide.

Quand je vous exposerai ma gestion des itinéraires améliorée, je parlerai du cas des carrés manuels automatiques qui s'ajoute aux cas précédents.

PS : si vous avez à gérer des cas qui ne sont pas décrits dans mon réseau d'essai, n'hésitez pas à m'en faire part pour que je les intègre. Je veux que ça marche partout.
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Thierry

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 744
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #56 le: septembre 07, 2018, 09:44:32 am »
Beau boulot de recherche et de mise au point. En informatique on appelle ça un jeu d'essai qui sert à vérifier tous les cas de figure. Enfin tous ceux auxquels on pense. Le dernier et le plus laborieux cas de figure à tester reste toujours le 'gros' jeu d'essai. Celui qui sature tous les compteurs par sa taille plus que par sa complexité...

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #57 le: septembre 07, 2018, 06:58:24 pm »
Merci Thierry,

Venant d'un spécialiste, c'est un beau compliment.

Je comprends aussi que ça serait bien d'essayer sur un vrai réseau  ;D
Patience, ça vient.  ;)

J'ai peaufiné la souplesse et l'ergonomie du programme (il me reste à faire les vidéos sur "VotreTube" et le post).
En particulier, on doit pouvoir changer d'avis quand on veut. Je ne t'apprendrai pas que c'est souvent plus dur d'effacer que de construire...




"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 321
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #58 le: septembre 09, 2018, 10:12:38 am »

Bonjour

J'ai suivi la discussion sans trop intervenir car entre les cimes enneigées et la grande bleue je n'avais pas trop l'esprit à cela.

Il me semble qu'il manque au moins trois choses à ton réseau de test :

- une TJS, les TJS (contrairement aux TJD) m'ont posées pas mal de problèmes dans dans la recherche d'itinéraires car il y a un cas pas possible (par rapport à une TJD), cela devrait aussi poser problème dans la recherche du signal suivant.

- un croisement, cela peut poser des problèmes d'incompatibilité d'itinéraires, entre autres

- en réalité (à la SNCF) beaucoup de voies ont un sens (disons la moitié), une voie unique peut être parcourue dans les deux sens, pour une voie double chaque voie à un sens, cela implique qu'il y ait des signaux que dans un sens (sauf pour les voies doubles équipées d'IPCS). Même des voies de gares peuvent avoir un sens, par exemple pour un évitement.

Ensuite j'ai plein de petites remarques :

- la SNCF utilise deux types de carrés, des carrés et des carrés violets (hauts ou bas), les carrés violets sont implantés dans les zones de manoeuvre, il me semble difficile de choisir automatiquement le type de carré, ni de décider s'il faut implanter un carrée violet bas ou pas pour faire des manoeuvres par refoulement sur les voies principales. Il arrive aussi souvent qu'il n'y ai qu'un carré violet pour deux voies

- pour les départs en manoeuvre les signaux ne présentent pas la voie libre ou l'avertissement, mais le feu manoeuvre (blanc lunaire), les carrés violets présentent normalement à l'ouverture un feu manoeuvre, mais il arrive couramment que des carrés (non violets) puissent aussi présenter un feu manoeuvre

- à la SNCF les carrés et les carrés violets sont fermés par défaut, seul l'établissement d'un itinéraire peut les ouvrir

- les sémaphores sont très très souvent implantés en pleine voie sans qu'il y ait d'appareils de voie

- le cas des zones Z13, Z20 et Z21 est symptomatique, il est très courant que quelques carrés protègent un ensemble d'appareils de voie, ensemble pouvant être important dans les grandes gares, par contre le cas des zones Z5 et Z9 est caricatural et me semble très loin de la réalité.

- on a pas le choix entre des signaux lumineux ou des signaux mécaniques, ou même une absence de signaux, on ne peux pas choisir entre du BAL ou du BAPR, …

En résumé il me semble qu'il est quasiment impossible d'implanter correctement les signaux automatiquement, désolé.

Amicalement

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #59 le: septembre 11, 2018, 02:11:54 pm »
Bonjour Pierre,

Ne sois pas désolé, ton post pose de vrais problèmes et ce n'est qu'en les résolvant qu'on améliore son programme.
La bonne nouvelle, c'est que j'ai déjà une solution pour une partie d'entre eux.  :D
En fait, c'est dans l'éditeur qu'il faut résoudre ces remarques, moyennant quelques questions.

Tout d'abord, nous sommes d'accords sur plusieurs points :

1°) Il n'y a qu'en raisonnant localement et en étudiant tous les cas qu'on résout 100% des problèmes.
C'est le cas à la SNCF et dans ton programme.

2°) Aucun programme ne peut résoudre seul certaines interrogations :

Choix d'un signal lumineux/mécanique.
     Seule l'histoire de la ligne peut répondre à cette question.
     Cette question est à ajouter à mon éditeur.
     Mais, si tu regardes le fichier du réseau, tu verras que j'ai déjà prévu la place pour la réponse.

La zone considérée est une zone de manœuvre ou pas.
     Il faut, là aussi, poser une question. On ne peut pas le déduire de quoi que ce soit.
     Il en découle un certain type de signalisations, avec des feux et une logique spécifiques.
     Je connais le problème, mais je ne m'y suis pas penché pour l'instant.
     Les 5 interrogations de mon précédent post n'en parlent pas et, bien sûr, ne résolvent pas ces cas là.

La zone considérée a une vitesse limitée et laquelle.

L'appareil de voie considéré a une vitesse limitée en position déviée et laquelle.

Il y a (ou pas) un feu à une extrémité de la zone.
     Là, c'est déjà géré par mon éditeur, en une question.

Construction d'une zone dans mon éditeur :

Quand on construit le réseau dans l'éditeur, on déplace des pavés depuis la palette jusqu'au TCO où on les pose.
On les oriente, on les allonge, … bref, on construit pas à pas un dessin de son réseau.
A ce stade, la notion de zone n'existe pas. C'est juste une liste de pavés indépendants. Il n'y a aucun signal.

Pour moi, un signal c'est :
     Une position x, y
     Un mat de hauteur normale, de hauteur réduite ou à ras du sol
     Une cible et des feux sur la cible en BAL ou une ou plusieurs cibles avec des signaux mécaniques.

Pour l'éditeur, un signal aura une position x, y, un mat standard et une cible sans feux.

Je me permets d'insister sur le mat, souvent dessiné "en l'air" et qui ne permet pas de façon non ambigüe de définir la voie qu'il gère.
Là, j'ai repris le tien qui, lui, indique clairement les choses. Il est super.

Par ailleurs, les feux seront gérés dans le gestionnaire et n'ont aucun intérêt dans l'éditeur.

Pour créer une zone, on sélectionne les pavés la composant.
C'est une étape essentielle. Déjà, en choisissant les bons pavés, on fait une grande partie du travail.

Par exemple, dans le post précédent, j'ai choisi le pavé arc de cercle 45°+le pavé droit (étendu) pour composer la Z4.
Puis j'ai choisi le pavé aiguille triple seul et j'ai défini la Z5.
Si j'avais choisi les 3 pavés en une seule fois, la Z4 aurait inclut l'aiguille triple et Z5 n'aurait pas existé.
Cela aurait d'ailleurs été nettement plus plausible, comme tu l'as remarqué.

On a, à ce moment, un ensemble de pavés qui ont le même identifiant de zone.
Mais ça n'est pas tout !!

Tous les pavés ont, par construction, deux connecteurs (je n'épilogue pas, ça nous mènerait trop loin).
Les connecteurs qui ont le même x,y sont "oubliés" et n'apparaissent pas : on a un trait continu en allant d'un pavé à l'autre.
Mais, fatalement, deux connecteurs (ou plus, avec les AV) n'auront pas de mitoyen : les connecteurs d'extrémité.
Ceux-là vont apparaitre sous forme de retraits : on aura une coupure du trait en allant d'un pavé au suivant.
On identifie donc clairement une zone : elle a des retraits à chaque extrémité.

Et les signaux, dans tout ça ?

Les signaux ont comme x, y les coordonnées de ces connecteurs d'extrémité.
Dans "Formes", je décale le mat du signal pour qu'il soit là où il est vraiment dessiné.

Donc, à priori, on peut mettre un signal à chaque fois qu'il y a un retrait.
Ce qui répond, au passage, à l'une de tes interrogations pour les signaux en pleine voie.

Mais j'ajoute comme règle qu'on ne peut pas avoir de signal sur un AV.
Donc, quand la zone termine par un AV, le programme décale le signal au premier pavé SAV.

Exemple sur Z2.
Le signal de gauche est à l'extrémité de la zone.
Le signal à droite est décalé pour ne pas être sur l'aiguille.

Et maintenant, voici la question qui est posée à chaque création de zone :



Là, j'ai répondu en cliquant sur le premier bouton pour toutes les zones.
D'où, évidemment, deux signaux à chaque zone.

Mais j'aurais pu ne mettre qu'un signal pour certaines zones, en choisissant de le mettre à droite ou à gauche suivant ce que je veux.
Et même, j'aurais pu ne pas mettre de signal pour cette zone.

Donc, on peut installer des signaux en pleine voie, sur des zones qui n'ont qu'un signal (celui qui est dans "le bon sens").

Enfin, si je mets deux signaux sur une zone, cela devient, de fait, un canton.

Mais si le canton est, par exemple, constitué de 3 zones, je mets :
Un signal à gauche dans la zone de gauche
Pas de signal dans la zone médiane
Un signal à droite dans la zone de droite
Et j'ai mon canton à 3 zones !

Donc, par rapport à tes questions, il me reste du travail pour les zones de manœuvre, pas encore traitées.

Je vais remplacer Z15 par une TJS. Je pense que ça marche, mais il faut vérifier.

Et je vais gérer les itinéraires et les incompatibilités. Pour l'instant, je peux gérer deux trains, ça marche, mais il faut que les itinéraires n'aient pas de partie commune (ni sécants). J'ai presque fini.
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)