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

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #30 le: avril 04, 2017, 09:16:36 am »
Question : Ça avance, ton truc ?
Réponse : Ah oui ! Je vais te monter un programme dont je suis sûr qu'il ne marche pas !

Q : Hein !?!
 :o :o :o :o :o :o :o
Et tu es fier de toi ?
R : Absolument ! Et c'est toi qui va le faire marcher.

Q : Qui, moi ? Mais je n'y connais rien…
R : Tu as réussi à faire marcher le locodrome ?

Q : Mais c'est pas pareil : il était tout fait et tout marchait bien !
R : Ce que je retiens, c'est que tu as Processing sur ton ordi et tu sais téléverser un programme Arduino ?

Q : Là, ça va, mais j'ai juste fait un programme pour faire clignoter une LED.
R : Hé bien, ça suffit.

Tu extrais les fichiers du .zip suivant : http://www.locoduino.org/IMG/zip/tco_v5_3.zip

Il y  a trois répertoires :
-> TCO_V5_2 qui contient mon programme Processing
-> LocodromeBAL4 qui contient le programme Arduino du locodrome de Pierre auquel j'ai retiré l'onglet "Specifs.h"
Tu peux voir le fil de Pierre (http://forum.locoduino.org/index.php?topic=166.60, au 22/03/17) les modifs que j'y ai faites :
J'ai simplement déplacé les infos spécifiques au locodrome dans un onglet … spécifique.
Et là, je l'ai retiré, ce qui fait qu'il ne marche plus.

-> TCOlocodrome4C qui contient le programme Processing du locodrome de Pierre, tel quel.
Donc, maintenant, tu lances mon programme et tu vas dessiner le réseau du locodrome.
C'est pas dur : 2 aiguilles, 2 arcs 45°, 4 droites et 4 arcs 90°

Q : Je choisis quoi, comme fichier ?
R : Rien, tu fais "annule", on n'en a pas besoin pour l'instant.

Q : Bon, ça y est : j'ai la palette et le quadrillage.
R : Tu peux aller voir la vidéo du 04/02/17 sur ce fil pour t'aider à poser les cubes, les orienter et les allonger.
Franchement, avec une souris à molette, ça va vraiment mieux.

Q : Bon, ça y est, j'ai ça :



Tiens, tu as changé les couleurs ?

R : Maintenant, il va falloir numéroter les cubes.
D'abord, il faut passer en mode "sélection", en appuyant sur la touche CTRL : la flèche de la souris devient une croix.
Pour revenir en mode normal, tu ré-appuie sur CTRL.
Pour les branchements, tu sélectionne un seul cube : il passe en foncé pour savoir s'il a bien été sélectionné.
Si tu t'es trompé tu peux désélectionner en sélectionnant avec le bouton droit.
Après, tu appuies sur le clavier, touche "m" (memory) …

Q : Mais il ne se passe rien !
R : Je sais, c'est un bug récalcitrant : il faut quasi à chaque fois appuyer deux fois, juste pour cette touche !
Q : OK.
R : Pour les cantons, tu sélectionnes plusieurs cubes en gardant le bouton gauche appuyé en dessinant un rectangle. On gagne du temps.
Et une fois qu'on a sélectionné, on donne un numéro au canton.
Il faut appuyer sur "d" (display) pour afficher les numéros…
Règle fondamentale :
-> Un branchement est numéroté de 1 à 100,
-> Un canton de 101 à 200.
-> Une voie de garage de 201 à 255,

On a donc 100 branchements, 100 cantons et 55 voies de garage maxi. De quoi voir venir, quand même…

Q : Bon, voilà, c'est fini, j'ai tout numéroté.



R : Maintenant, tu appuies sur "a" (analysis)

Q : Il me trouve des erreurs !
R : Pas de panique ! Dans la quasi-totalité des cas, c'est parce que tu as trop zoomé sur un cube droit et les dessins se superposent.
Le programme n'arrive pas à abouter les cubes et il se plaint…
Il faut raccourcir et vérifier une dernière fois.

Q : Je ré-appuie sur "a" ?
R : Oui, jusqu'à ce qu'il n'y ait plus d'erreurs du tout.

Q : C'est encore long ?
R : Non : tu appuies sur "r" (routes) et c'est fini.

Q : Et alors ? J'ai rien vu !
R : Tu vas dans le répertoire TCO_V5_2 et tu y trouves un nouveau fichier "Specifs.h", créé par le programme Processing. Il n'y était pas avant, c'est toi qui l'a créé.
Tu le copies et tu le colles dans le répertoire LocodromeBAL4.
C'est ce fichier qui manquait.
Et maintenant, tu fais marcher le locodrome comme avant !!!
Si tu compares le fichier Specifs.h dans le fil de Dominique et celui-là, tu verras qu'ils ne sont pas exactement identiques :
-> Les noms sont différents,
-> L'ordre n'est pas tout à fait le même, mais ça marche

Q : On peut changer les noms et ça marche quand même ??
R : Oui. Ce qu'il faut garder, c'est la structure des objets. Et le programme manipule des objets. Le nom n'est qu'une donnée parmi d'autres. Si tu changes les numéros sur ton circuit dans TCO, les noms des objets vont changer, mais ça marchera toujours.

Q : Alors, c'est fini ?
R : Tu peux sauver ton dessin en tapant "s" (save) dans Processing.

Q : C'est pas ça que je voulais dire. On peut dessiner n'importe quel réseau ?
R : Non, pas encore à cause de deux problèmes fondamentaux :
-> Pour l'instant, on ne peut dessiner que des réseaux qui n'ont pas deux branchements consécutifs
-> Il faut aussi que le dessin du Processing suive …
Ce sera le programme "commandes".

Mais, bon, c'est quand même une étape importante : la génération entièrement automatique d'un morceau de programme Arduino. :-* :-* :-*

Q : Au fait, pourquoi tu nous fais parler, comme ça ?
R : Parce que ça me rappelle une série de livres de Jean-Pierre Oemichen "L'électronique ? Mais c'est très simple"…
« Modifié: avril 06, 2017, 08:59:38 am par DDEFF »

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #31 le: avril 05, 2017, 11:10:03 am »
Je suis désolé, il y a un problème.
Dans ma précipitation, j'avais mis le mauvais .zip. Je viens de remettre le bon... mais le programme Arduino se plaint maintenant d'un problème de mémoire ... :-[

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #32 le: avril 06, 2017, 08:59:10 am »
Je suis déçu... :(

Avant hier, je finis mon programme de TCO qui construit la partie "Specif.h" de l'Arduino.
Je fais tourner ce programme, je génère "Specif.h", je le mets dans le répertoire de l'Arduino, j'écrase l'ancien "Specifs.h".
Fatigue ? Trop longtemps travaillé sur Processing où ça n'est pas utile ?
Toujours est-il que je ne téléverse pas le programme dans l'Arduino qui contient donc la version de Pierre du locodrome.
Évidemment, quand je lance le programme Processing de Pierre, tout fonctionne à merveille...
Et je m'enthousiasme, je fais un post optimiste que vous avez certainement lu.

Et puis, le lendemain (hier, donc), je me dis que c'est quand même louche qu'après un programme de presque 1000 lignes, j'arrive à générer sans une seule erreur, même pas une parenthèse qui manque, rien !
Et je m'aperçois de cette erreur de débutant... ::)
Je téléverse et je vois quelques erreurs mineures, des inversions de noms, enfin, le train-train  ;D

J'ai corrigé (et le lien de mon post précédent) :
http://www.locoduino.org/IMG/zip/tco_v5_3.zip

Donc, je confirme : cette fois, le programme "TCO_V5_3" génère bien le bon fichier pour l'Arduino. C'est une bonne nouvelle.

Mais ce n'est pas pour ça que je suis déçu.
C'est parce que le programme Processing de Pierre contient (aussi) une description du réseau et il faudrait (encore) que je fasse un "Specifs.pde" pour que tout marche.
En fait, c'est même tellement intégré que ce serait un travail énorme.

Donc, quitte à programmer, autant directement programmer mon programme "commande" apte, lui, à récupérer n'importe quel réseau.
Je reprends donc mon bâton de pélerin.
Que c'est loin, Saint-Jacques de Compostelle ! :P
« Modifié: avril 06, 2017, 09:01:50 am par DDEFF »

Pierre59

  • Jr. Member
  • **
  • Messages: 56
    • Voir le profil
Re : Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #33 le: avril 06, 2017, 04:34:51 pm »
Mais ce n'est pas pour ça que je suis déçu.
C'est parce que le programme Processing de Pierre contient (aussi) une description du réseau et il faudrait (encore) que je fasse un "Specifs.pde" pour que tout marche.


Bonjour


En fait il y a deux programmes bien distincts. D'une part le gestionnaire de réseau écrit en C++ et d'autre part le TCO virtuel écrit en Processing (en réalité c'est en grande partie du Java). Dans les deux cas il y a une partie générale ne dépendant pas du réseau et une partie qui dépend du réseau. On cherche ici à automatiser l'écriture des parties dépendant du réseau à partir du dessin du TCO.

Pour le gestionnaire il faut écrire automatiquement toutes les classes zones (constructeur, méthodes actions(), desactions(), suivantePaire(), suivanteImpaire(), …) et  toutes les classes signaux (constructeur, méthodes suivant(), precedent(), …), voire les classes itinéraires, ainsi que toutes les déclarations de variables. Il faut aussi pouvoir choisir le type des signaux (parmi les nombreux possibles).

Pour le TCO virtuel, cela dépend si on veut faire circuler des trains virtuels ou pas. Si on veut des trains virtuels il faut décrire au minimum la topologie du réseau, les zones, les aiguilles et les signaux. Pour les zones il faut connaitre les suivantes paires et impaires (fonction de la position des aiguilles). Dans les deux cas il faut définir, en fonction de la position des aiguilles ce qu'il faut colorer pour matérialiser les occupations de zone et/ou les itinéraires (méthode trace()).

Le Locodrome est trop simple (pas de zones avec plusieurs aiguilles) et ne montre pas tous les problèmes, pour plus de variété voir le TCO de Dominique. Mais on peut aussi se passer du TCO virtuel avec un TCO réel.

Il me semble difficile d'automatiser complètement l'écriture automatique des programmes, mais on peut faire automatiquement le gros de l'écriture, puis mettre ses mains dans le "cambouis" pour adapter au réseau.

Pierre

« Modifié: avril 06, 2017, 04:37:17 pm par Pierre59 »

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #34 le: avril 06, 2017, 04:58:40 pm »
Merci Pierre,

Je joins le "Specifs.h" généré par mon programme.
Tu constateras que c'est quasi le même que le tien ... aux noms près.

Le programme ne peut pas deviner comment s'appellent les zones, par exemple.

J'ai donc appelé les zones avec le numéro des Blocks/Turnouts dans mon programme.

Par exemple:
-> Z0 s'appelle Z101 parce que c'est le Block 101.
-> Z2 s'appelle Z1 parce que c'est le Turnout 1.

Pour les signaux, j'ai compliqué un peu avec le nom de la zone qu'on décrit et la zone où on va.
-> S1 s'appelle S104_103 (on va de 104 vers 103)
-> S2 s'appelle S103_104 (on va de 103  vers 104)
-> C1 s'appelle S103_1 (on va de 103 vers 1)

J'ai donc un nom pour tout, différent, gérable automatiquement.

Le problème, c'est que dans le programme Processing de gestion de locodrome, il faudrait aussi que le change tous les Z0 en Z101, etc...
Pour le locodrome, c'est faisable. Mais pas pour un "vrai" réseau.

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #35 le: avril 27, 2017, 06:16:17 pm »
Petit point rapide avant le Salon de Lille...

Depuis un an et demi, je cherche à automatiser le passage d'un dessin de réseau à un programme Arduino qui gèrerait le réseau.

En novembre 2015, j'avais produit un article SGDD(1) où je modélisais ma gare, pourtant très complexe, en seulement 85 octets.
Mais il fallait pas mal de patience pour arriver à trouver ces 85 octets !
La suite du programme n'utilisait pas la programmation objet, que j'ai appris à connaître depuis, même si je ne maîtrise encore pas tout…

Grâce à Processing, j'ai mis l'accent sur l'esthétique du TCO et les récents posts donnent une idée des progrès accomplis. Mais le vrai problème restait là : comment modéliser automatiquement ?

Au début du mois d'avril 2017, j'avais réussi à modéliser le fameux locodrome, mais avec une méthode qui n'était guère extensible à d'autres réseaux.
La partie la plus délicate étant la désignation des suivants et des précédents des signaux.

En fait, évidemment, il faudrait une bonne récursivité qui étudierait tous les cas.

Seulement, la récursivité souffre de trois écueils :


-> Au début, ça ne démarre pas : on n'a pas suffisamment analysé les conditions initiales !
-> Après, ça ne s'arrête plus ! : Là, ce sont les conditions de sortie qu'on n'a pas bien encadrées.
-> Puis ça marche dans 99% des cas et on croit qu'on a fini.
Quelques réglages et… on voit que c'est carrément la méthode qui n'est pas bonne et se fait coincer dans certains cas.
Tout est à recommencer !

Je n'ai pas eu le temps de vérifier complètement le fichier Specifs.h.

Mais pour la partie méthodes des signaux, j'ai tout vérifié sur un circuit type où tous les éléments existent :

-> Des aiguilles, successives cette fois, et même en "communication" (terme SNCF officiel)
On va donc avoir à gérer des selonAiguille(a1, Sxx, selon(a2, Syy, Czz))
-> Une Traversée Jonction Double
-> Une "traversée" simple
-> Des voies de garage
-> Et même une aiguille triple, extension de la méthode des selonAiguille(a1, Sxx, Cyy Szz)

Voici le réseau vierge :



Puis le réseau numéroté :



Et enfin, si j'appuie sur "R", voilà la sortie (seulement la partie méthode des signaux)

Signal* C101_2::suivant() { return C104_8; }
Signal* C101_2::precedent() { return C103_1; }
 
Signal* C101_1::suivant() { return C103_9; }
Signal* C101_1::precedent() { return C104_2; }
 
Signal* C102_4::suivant() { return C104_8; }
Signal* C102_4::precedent() { return C103_1; }
 
Signal* C102_3::suivant() { return C103_9; }
Signal* C102_3::precedent() { return C104_2; }
 
Signal* C103_1::suivant() { return selonAiguille(a1, C101_2, selonAiguille(a3, C105_6, C102_4)); }
Signal* C103_1::precedent() { return C109_9; }
 
Signal* C103_9::suivant() { return C109_7; }
Signal* C103_9::precedent() { return selonAiguille(a1, C101_1, selonAiguille(a3, C105_5, C102_3)); }
 
Signal* C104_8::suivant() { return selonAiguille(a8, C107_7, C106_7); }
Signal* C104_8::precedent() { return selonAiguille(a2, C101_2, selonAiguille(a4, C105_6, C102_4)); }
 
Signal* C104_2::suivant() { return selonAiguille(a2, C101_1, selonAiguille(a4, C105_5, C102_3)); }
Signal* C104_2::precedent() { return selonAiguille(a8, C107_8, C106_8); }
 
Signal* C105_6::suivant() { return selonAiguille(a6, C202_0, C204_0, C104_8); }
Signal* C105_6::precedent() { return selonAiguille(a5, C201_5, C103_1); }
 
Signal* C105_5::suivant() { return selonAiguille(a5, C201_0, C103_9); }
Signal* C105_5::precedent() { return selonAiguille(a6, C202_6, C204_6, C104_2); }
 
Signal* C106_7::suivant() { return selonAiguille(a7, C108_9, C109_9); }
Signal* C106_7::precedent() { return C104_8; }
 
Signal* C106_8::suivant() { return C104_2; }
Signal* C106_8::precedent() { return selonAiguille(a7, C108_7, C109_7); }
 
Signal* C107_7::suivant() { return selonAiguille(a7, C109_9, C108_9); }
Signal* C107_7::precedent() { return C104_8; }
 
Signal* C107_8::suivant() { return C104_2; }
Signal* C107_8::precedent() { return selonAiguille(a7, C109_7, C108_7); }
 
Signal* C108_9::suivant() { return C203_0; }
Signal* C108_9::precedent() { return selonAiguille(a7, C106_7, C107_7); }
 
Signal* C108_7::suivant() { return selonAiguille(a7, C106_8, C107_8); }
Signal* C108_7::precedent() { return C203_9; }
 
Signal* C109_9::suivant() { return C103_1; }
Signal* C109_9::precedent() { return selonAiguille(a7, C107_7, C106_7); }
 
Signal* C109_7::suivant() { return selonAiguille(a7, C107_8, C106_8); }
Signal* C109_7::precedent() { return C103_9; }
 
Signal* C201_5::suivant() { return C105_6; }
Signal* C201_5::precedent() { return ; }
 
Signal* C201_0::suivant() { return ; }
Signal* C201_0::precedent() { return C105_5; }
 
Signal* C202_0::suivant() { return ; }
Signal* C202_0::precedent() { return C105_6; }
 
Signal* C202_6::suivant() { return C105_5; }
Signal* C202_6::precedent() { return ; }
 
Signal* C203_0::suivant() { return ; }
Signal* C203_0::precedent() { return C108_9; }
 
Signal* C203_9::suivant() { return C108_7; }
Signal* C203_9::precedent() { return ; }
 
Signal* C204_0::suivant() { return ; }
Signal* C204_0::precedent() { return C105_6; }
 
Signal* C204_6::suivant() { return C105_5; }
Signal* C204_6::precedent() { return ; }

Je ne regrette pas les trois semaines que je viens de passer… ;D

Je n'ai pas le temps de détailler, mais je le ferais bientôt.
Notez, au passage que, maintenant, je tiens compte des signaux capables d'afficher le carré (Cxx) et ceux qui se limitent au Sémaphore (Syy)

Tout ce que je peux dire aujourd'hui, c'est que je demande quand même assez peu de choses à l'amateur :

1°) Dessiner son réseau avec le programme TCO.
Profiter que le plan est vierge pour en faire une copie : elle resservira.

2°) Numéroter le réseau dans le programme avec quelques règles :
-> numéroter les aiguilles de 1 à 100
Zéro n'est pas possible.
J'appelle "Aiguille" tout ce qui n'est pas un "canton" : les branchements, les traversées,…

-> numéroter les cantons de 101 à 200
Un canton n'a pas d'aiguille. Ce n'est pas une zone dans la terminologie de Pierre.

-> numéroter les voies de garage de 201 à 255

3°) Comme mes appellations ne vont pas vous plaire, il faudra que vous fassiez une table d'équivalences (transform.tsv) avec juste deux colonnes :
Votre numérotation / ma numérotation.
Pour l'instant, je ne m'en sers pas, mais ce sera facile à gérer.
Et c'est pour ça que vous apprécierez d'avoir gardé un dessin de réseau vierge  ;)

4°) Appuyez sur "A" (analysis) pour vérifier que tout est OK
Puis appuyez sur "R"
Vous récupérerez le fichier Specifs.h  :o

Quelques remarques utiles :

Grâce à ce programme, vous générez un programme Arduino.
(Pour l'instant, les itinéraires ne sont pas faits, mais c'est à venir).
Mais je n'ai fait aucune hypothèse, ni sur l'alimentation du réseau (DCC ou analogique), ni sur la façon dont sera fait le TCO !

Même si vous voulez un TCO physique, avec de vrais boutons, vous aurez besoin d'un gestionnaire Arduino. Et vous pourrez utiliser mon programme TCO pour le générer...  ;)

Ce n'est pas fini, mais un grand pas vient d'être franchi.   :P
« Modifié: mai 04, 2017, 04:00:46 pm par DDEFF »

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #36 le: octobre 12, 2017, 09:46:57 am »
Bonjour,

Nouvelle page pour mon programme : il est maintenant capable de gérer les itinéraires ! ;D ;D ;D



Je vais cependant vous décevoir d'emblée car j'en suis "seulement" au stade de les trouver tous et de les dessiner. Aucun ordre n'est envoyé au réseau.
De même, je ne tiens pas compte (pour l'instant) des itinéraires existants ni des occupations. Mais, à côté des problèmes de trouver tous les itinéraires, c'est assez "simple"...

Je remercie particulièrement Pierre59 pour m'avoir appris à programmer avec les objets (j'ai encore des progrès à faire, bien sûr), pour son Locodrome(voir les articles http://www.locoduino.org/ecrire/?exec=article&id_article=154 et suivants) et aussi Jean-Luc pour avoir bien analysé la problématique dans son fil (http://forum.locoduino.org/index.php?topic=167.0)

Originalité :

Je dessine le réseau avec mes petits pavés et c'est tout.
A aucun moment je ne décris quelque part les itinéraires, je ne les mémorise pas. Ils sont crées "ex nihilo", à la demande.
Je n'ai pas non plus d'analyse préalable du réseau. Juste le dessin. Là, c'est vraiment nouveau. ;)

Je ne raisonne pas en "zone de gares" pour limiter les recherches. Je n'ai, à priori, aucun besoin de limiter les recherches.
Les seules limites que j'ai fixées, sont :
-> 100 pavés maxi pour un itinéraire
-> 20 itinéraires maxi pour deux points A et B donnés (dans ma gare, j'ai le cas de 11 maxi)
On peut mettre moins ou plus, ce sont juste deux nombres à changer. En dépendent le temps de calcul et la taille mémoire.
Vous noterez que je n'ai pas de limite de nombre d'itinéraires (à part la place mémoire…)

Il s'ensuit que je peux aller de A à B, n'importe où.
Cela explique aussi que je n'ai aucun bouton pour gérer les itinéraires. Deux clics suffisent.

Pour être vraiment précis, "n'importe où", ce n'est pas tout à fait vrai :
-> le point de départ est à choisir sur une voie, juste à proximité du premier appareil de voie du futur itinéraire.
-> le point d'arrivée est, lui aussi, sur une voie, juste à proximité d'un appareil de voie.
On a plus de latitude pour le point d'arrivée puisqu'on n'impose pas que cet appareil de voie soit le dernier appareil de voie de l'itinéraire.
Vous le verrez en testant, on peut arriver sur une voie au point de contact avec un appareil de voie.

Donc, pas d'itinéraire d'un point en pleine voie vers un point en pleine voie et pas non plus d'itinéraire entre deux appareils de voies noyés dans un grill.
On pourrait le faire, mais la saisie d'itinéraire serait complexifiée. Et je ne suis pas sûr que ça corresponde à un besoin.

Je gère les boucles de retournement.
A ce sujet, ce n'est pas un réel problème puisque mes pavés n'ont pas de notion de sens.
Je cherche les itinéraires de connecteur en connecteur, un peu comme dans la solution de Jean-Luc.
Mais je ne permets pas de sortir d'une boucle : je bute volontairement sur l'aiguille d'entrée qui devrait avoir alors deux (!) positions.
En particulier, j'arrive ainsi à gérer une voie d'évitement dans une boucle. ;D

Comment tester ?

Je ne souhaite pas entrer dans les détails ici (je ferai des articles à la fin). Je fournis donc un mode d'emploi juste pour faire des essais.

Vous dé-zippez le fichier, vous allez dans le répertoire  et vous double-cliquez "TCO_V7_10.pde" (par exemple) et vous lancez (touche Play en haut à gauche).
A la question du choix de fichier, c'est très simple : il n'y en a qu'un !
Vous le choisissez donc.
Puis vous tapez c g i.
"c" pour (Charger le réseau) exemple
"g" pour supprimer la (Grille)
"i" pour passer en mode (Itinéraires).
Le curseur devient une bulle vous demandant le point de départ (au bout de la pointe)
Puis le curseur change pour connaitre le point d'arrivée.
Comme c'est pédagogique, il apparait des fenêtres pop-up donnant quelques renseignements.
Quelques OK plus tard, c'est fini.
Tous les itinéraires possibles entre A et B sont calculés. Mais on ne les voit pas encore.
On appuie sur "m" (Montre itinéraires) et une nouvelle bulle vous invite à les afficher un par un.
Un dernier appui sur M pour revenir au curseur normal (la flèche).

Dans la pratique, les itinéraires s'empilent dans un objet ArrayList.
Je cherche en effet à mémoriser tous les itinéraires d'une gare donnée, ce qui pourrait paraître contradictoire avec ce que j'ai dit au début. Mais non :

Cette partie du programme servira à donner un "poids" à chaque appareil de voie.
Je poursuis là une idée qui m'est chère visant à choisir le meilleur itinéraire parmi tous ceux possibles.

Le meilleur n'étant pas celui qui est le plus court, mais celui qui bloque le moins un grill de voie et donc améliore la fluidité.

 Le "poids" est simplement le nombre de fois qu'un appareil de voie est impliqué dans un itinéraire, en balayant tous les itinéraires possibles.
On ne le calcule qu'une fois, on le mémorise dans le pavé et c'est tout. Rassurez-vous : ça se fera juste en appuyant sur un bouton dans le programme TCO.
Si, par exemple, une aiguille sert dans 5 itinéraires, quand on l'utilise, on bloque potentiellement 4 autres itinéraires.
Donc, parmi tous les itinéraires entre A et B, on fait la somme des "poids" de chaque itinéraire en additionnant les "poids" de chaque appareil de voie le composant.
Le "poids" le plus faible l'emporte.
Incidemment, plus l'itinéraire est court, moins il utilise d'appareils de voie et plus il a de chance d'être le meilleur. Mais pas forcément et c'est dans ces cas là que ça devient intéressant.
Je vais tester avec ma gare et ses 180 itinéraires, pour voir.

J'en suis là.
J'aimerais votre avis. N'hésitez pas à poser des questions, à me dire si ça plante, etc…
« Modifié: octobre 14, 2017, 09:49:38 am par DDEFF »

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #37 le: octobre 14, 2017, 09:48:26 am »
Dans ce programme, je teste à la fois ce que fera le programme TCO (celui qui reste sur l'ordi, qu'on ne fait qu'une fois) et le programme Commandes (celui qui sera sur le PCDuino).
Dans le programme TCO, on verra toujours la grille et dans Commandes on ne verra jamais la grille.
A terme, il n'y aura donc pas de touche "g".
Donc, ici, s'agissant d'un programme pédagogique, il faut appuyer sur "g" avant d'appuyer sur "i" pour faire disparaître la grille.

Pour les curieux, il y a une touche "g" pour afficher/masquer la grille et une touche "G" (en majuscule) qui donne, en plus de la grille, les coordonnées colonne et ligne de chaque pavé. Pour moi, développeur, ça a un intérêt, mais sinon, ça ne sert absolument à rien. ;)

Autre remarque, qui a pu choquer :
 
Je fais figurer le nombre d'itérations pour chaque étape du programme. Avec même obligation de cliquer pour continuer ! >:( C'est vraiment inutile, à part dans un programme pédagogique.
Pire : ça finit inexorablement par "Revenu au départ sans rien trouver" !! :o

Pourquoi ?

Si j'affiche le nombre d'itérations, il va les indiquer au fur et à mesure.
Quand il a trouvé le premier itinéraire, il affiche ce nombre, pour ce premier itinéraire.
Puis il remet le compteur à 0 et repart d'où il est (c'est à dire de la fin du premier itinéraire) et recule dans l'arborescence.
Puis il bute sur un appareil de voie et repart en marche avant, avec une autre position de l'appareil de voie jusqu'à ce qu'il trouve le deuxième itinéraire en arrivant à destination. Il affiche le nouveau nombre d'itérations.

Et, forcément, il arrive un moment où il a trouvé tous les itinéraires.
A cet instant, il est "retourné au départ sans rien trouver", sous entendu "comme nouvel itinéraire".

J'ai le même message pour le cas où le programme ne trouve vraiment rien et dans le cas où il ne trouve pas d'autre itinéraire.
Je pourrais facilement distinguer les deux cas, avec un "if" de plus, mais, de toutes façons, ces messages disparaîtront.

Avez vous trouvé l'itinéraire qui affiche 172 itérations ? ::)

J'ai en tête de nombreuses optimisations. Je trouve en effet ce programme efficace, mais trop lent à mon goût.
Particulièrement dans la recherche du connecteur mitoyen où je balaye tous les pavés. En mettant un paramètre supplémentaire dans les formes, je vais tout de suite tomber dessus, en 2 tests seulement.
De même, ce n'est pas la peine de redessiner un pavé s'il n'a pas changé.
Et d'autres choses qui me permettrons de simplifier grandement la gestion des signaux.

A suivre