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

DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • 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: 449
    • 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: 449
    • 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

  • Full Member
  • ***
  • Messages: 102
    • 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: 449
    • 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: 449
    • 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: 449
    • 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: 449
    • 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

DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #38 le: juin 28, 2018, 07:35:29 pm »
Bonjour,

J'ai bien avancé depuis ... octobre !!

Tout d'abord, une petite vidéo de mise en bouche :


Malheureusement, sur la vidéo, il apparait une petite flèche pour la souris, en lieu et place d'un curseur qui prend la forme d'un viseur avec lequel on pointe précisément le point voulu. (C'est dû à la captation de la vidéo). C'est bien triste, mais le programme fonctionne bien.
Sur la vidéo, on a l'impression qu'on clique dans le vide, alors que c'est, au contraire, très précis. Dommage.  :'(

Je le dis tout de suite : il est fort probable que le programme foire au départ sur Mac. C'est dû à un problème de Processing qui n'est pas tout à fait le même pour Windows et Mac, en particulier pour le dimensionnement des écrans.
L'inverse est aussi vrai. J'ai eu un mal fou à faire fonctionner sur mon Windows un exemple de programme Mac que m'avait généreusement fourni Pierre (Pierre59).
Il a fallu que j'intervienne dans le programme pour modifier quelques lignes.
Donc : attention si vous développez exclusivement en Mac. Cela peut ne pas marcher en Windows. Et réciproquement !

Ce programme n'est qu'une étape. Il manque encore plein de choses. Mais il faut bien, de temps en temps, dire où on en est.

Fonctionnement du programme TCO :

Ce programme TCO fait suite au programme Edite_TCO présenté précédemment.
Ces deux programmes sont liés : on dessine son propre réseau avec Edite_TCO et on le gère avec TCO.
Évidemment, justement parce qu'ils sont liés, les choix de programmation faits dans l'un se voient dans l'autre.
Et, pour l'instant, l'ancien programme Edite_TCO ne fonctionne plus complètement et ne génère pas exactement le bon fichier pour qu'il puisse être continué avec TCO.
Mais j'ai passé tellement de temps sur cet éditeur que j'ai voulu changer et voir comment faire un gestionnaire.
Rassurez-vous, il n'y a pas tellement de choses à changer dans Edite_TCO. Mais je veux avancer.

Fonctionnement (sur Windows) :
1°) On lance le programme et on choisit le seul fichier qui marche (voir plus haut)
2°) Un premier écran apparait, avec une dimension fixe. Devrait marcher sur Mac aussi.
3°) Il faut agrandir l'écran pour voir tout le réseau (en haut à droite sur la fenêtre)
4°) En passant la souris sur le bas apparaît un menu qui veut ressembler à un dock de Mac (j'aime bien  ;)).
Nota : le mettre en haut sur Mac ?
5°) On clique sur le choix d'itinéraire (l'aiguille triple en gris)
6°) Les actions à faire sont indiquées dans l'épaisseur de la plaque où se reflètent les icônes.
En vert OLIVE les actions réussies, en SABLE, les actions à faire, en VIOLET les erreurs.
7°) On clique sur le point de départ.
Ce point de départ n'est pas n'importe où :
Il faut viser un point jonction entre un appareil de voie et un non appareil de voie.
D'une seule action, je donne le départ et le sens de circulation.
Le train ira vers l'appareil de voie.
8°) Pareil pour le point d'arrivée : le train s'arrêtera juste avant l'appareil de voie.

J'ai chois cette façon de raisonner pour pouvoir "abouter" des itinéraires. Et ça marche. Le point d'arrivée correspond avec le point de départ.
Et ainsi, on peut faire un circuit bouclé en aboutant le nombre d'itinéraires qu'on veut.

9°) On a alors à l'affichage le premier itinéraire trouvé et, dans la barre, combien ont été trouvés au total (4 sur la vidéo).
En cliquant GAUCHE n'importe où, on voit défiler tous les itinéraires trouvés et ça revient au départ jusqu'à ce qu'on valide notre choix par un clic DROIT.
10°) Le numéro d'itinéraire validé apparait dans la barre.

Et on peut recommencer avec deux autres points et générer autant d'itinéraires qu'on veut, distincts ou aboutés.
A noter aussi que les points de départ et d'arrivée peuvent être en dehors des gares. "N'importe où", aux restrictions près décrites plus haut.

11°) Pour mettre un train sur un itinéraire, on clique GAUCHE sur le pupitre, dans la colonne du train choisi.
On ne clique pas n'importe où : uniquement dans la case en bas du pupitre, en dessous de celle du curseur.
12°) Avec le viseur, on met le train à un début d'itinéraire (au point qu'on a choisi pour départ de l'itinéraire)
13°) Avec le curseur, on choisit la vitesse "de consigne", c'est à dire la vitesse maximale qu'aura le train.
14°) A gauche du curseur, un barregraph indique la vitesse réelle du train.
En particulier, lors d'un arrêt, la vitesse diminue sans que le curseur ne bouge.

Je n'ai, pour l'instant, pas géré l'accélération. Juste le ralentissement et l'arrêt, eux même perfectibles.

15°) Et c'est là qu'on voit le PRS : l'itinéraire s'efface au fur et à mesure !! ;D ;D ;D

On peut déplacer le pupitre. il faut le "prendre" en faisant un glisser-déposer avec la case du signal à gauche.
Ce déplacement est lourd en temps machine. En fait, on ne s'en sert qu'une fois, au début, et la position est mémorisée pour la prochaine fois.

Testé avec 4 mini itinéraires et 4 trains.

Je ne l'ai pas dit, mais la signalisation est complète (l'aiguille en plein milieu est limitée à 60 km/h). D'où les feux clignotants corrects.
Et le cab-signal est, lui aussi, complet : le feu du pupitre est celui que voit le conducteur du train.

Au niveau programmation, je ne peux pas rivaliser avec l'excellent programme de Pierre et son déplacement des trains fluide.
Mais j'ai fait d'autres choix qui influent sur le résultat. Et qui sont "lourds" en temps.

Denis

Le programme fait maintenant 2Mo. Demandez-le moi par mail (à moins que vous n'ayez une idée géniale pour le publier ici)


Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #39 le: juin 28, 2018, 10:13:00 pm »
Bravo Denis,

C'est une étape importante et la question du Mac trouvera sa réponse en éliminant les spécificités propres à chaque OS : il y a forcément un tronc commun qui marche !

Amicalement
Dominique

DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #40 le: août 04, 2018, 07:09:18 pm »
Voici ma dernière mouture. ;)

Première chose immédiatement visible : quand on ouvre le fichier, on a un réseau complet, qu’on peut utiliser.
Et comme la fenêtre fait 1366 x 768, même ceux qui ont un Mac ne seront pas gênés par mon menu qui ressemble à leur dock, mais sans être au dessus du vrai dock du Mac.

On peut bien sûr l’utiliser en plein écran ou en plus petit grâce aux loupes :
Si on clique GAUCHE, c’est le pupitre qui change de taille.
Si on clique DROIT, c’est tout le réseau qui change de taille.

On peut aussi déplacer le pupitre par glisser-déposer de la souris sur le signal du pupitre 0 (le premier à gauche).

Une fois qu’on a la configuration qu’on veut, on peut passer à la nouveauté principale :

La gestion des itinéraires.

Dans d’autres logiciels, on doit définir à l’avance les points qui pourront servir de point de départ et de point d’arrivée, généralement dans des grills de gare.
Là, on peut maintenant partir ou arriver de n’importe où, à proximité d'un signal.

Pour le découpage du réseau, l’élément de base est la zone.
Il existe fondamentalement deux types de zones :
Les zones appareils de voies qui ne contiennent que des appareils de voie. Je les nomme zones AV.
Les zones qui ne contiennent aucun appareil de voie. Je les nomme SAV.
Les zones mixtes. Je sais, ça fait 3 types… :D

Je suis sûr qu’à la SNCF on peut trouver des zones qui ne contiennent que des appareils de voie et qui, pourtant, ont aussi des signaux.
Mais j’ai pris pour principe que les zones AV n’auront aucun signal.

De la même façon, il doit exister à la SNCF des zones SAV sans aucun signal (hors zones de manœuvre où c’est, par contre, très courant).
Mais j’ai pris pour principe que les zones SAV auraient deux signaux, un à chaque extrémité.

Dans les zones mixtes, il y aura aussi deux signaux, mais placés sur la partie SAV. Exemple sur le réseau d’essai, en haut à gauche.

Avec ces deux principes, je peux placer automatiquement les signaux sur n’importe quel réseau.
Je suis conscient que ce sont des "limitations", mais qui ne doivent pas être bloquantes.

Le connecteur

Le connecteur est l’élément fondamental pour découvrir les itinéraires. (Merci Jean-Luc pour ce post pionnier sur le Forum Locoduino)

Au niveau structure, c'est le point qui est entre deux "pavés" (sous-ensemble des zones).
En fait, même s'ils existent vraiment "partout", ceux qui nous intéressent sont ceux qui sont juste à côté d'un signal.

Pour choisir un itinéraire, on clique GAUCHE à proximité d'un signal, au départ comme à l'arrivée.

Dans la précédente version, j'avais en plus comme contrainte que le connecteur soit au point de jonction d'une zone AV et d'une zone SAV. C'était très gênant en pleine voie. Cette contrainte n'existe plus.

Attention au fonctionnement du programme qui est très précis sur ce point :
Le programme choisit le connecteur avec signal LE PLUS PROCHE (à vol d'oiseau) du clic de souris.
Dans des zones denses, il faudra bien se rappeler ce point et bien viser. On pourrait avoir des surprises !

Pour bien mémoriser le choix du départ comme de l'arrivée, le signal choisi devient noir le temps qu'on ait choisi l'itinéraire.
On a donc un signal noir au départ et un signal noir à l'arrivée.
Ainsi, si vous avez cliqué à proximité d'un autre signal sans le vouloir, quand le programme vous dira "Aucun itinéraire n'est possible avec ces deux extrémités", vous verrez où est l'erreur…

Si un itinéraire est possible, il s'affiche en couleur "sable" et, dans la barre de statut (sous le menu), vous savez combien il en existe.
En cliquant GAUCHE autant de fois que nécessaire, on fait défiler tous les itinéraires trouvés.
Puis vous validez avec un clic DROIT. L'itinéraire passe au vert.

A noter que si aucun itinéraire ne vous convient, dans la liste des itinéraires, il y en a un qui est "vide". Si vous validez DROIT à ce moment, on oublie tout. Retour à la situation précédente.

Évidemment, les signaux reprennent leur couleur dès qu'on valide. Et d'ailleurs, les signaux suivent la position des aiguilles. Un minimum.

Voici la première vidéo qui illustre les différents choix.



Les itinéraires chainés

On a choisi un itinéraire. C'est bien. Mais il serait bien de pouvoir les chaîner.

1°) Chaînage "en avant" :

Très utile si on veut parcourir un ovale, par exemple. Il faut, au moins, chaîner deux itinéraires.
On peut, également passer par une boucle de retournement, en deux fois, bien sûr.

Fonctionnement :
Une fois le premier itinéraire choisi, on en choisit un deuxième, un troisième, …
La contrainte est que la dernière zone du premier itinéraire soit aussi la première zone du deuxième. C'est tout.

Voici la vidéo explicative. En faisant des arrêts image vous pourrez voir quels signaux sont noirs d'un itinéraire sur l'autre pour vérifier la technique de choix.



Vous noterez aussi qu'à chaque nouvel itinéraire, vous pourrez toujours choisir l'un des itinéraires proposés, comme avant. Donc, vous pouvez vraiment choisir d'aller où vous voulez, par le chemin que vous voulez.
Vraiment tout ? Non !

2°) Chaînage "retour" :


Il y a des situations où vous voudriez bien rebrousser chemin. L'exemple le plus courant est la navette

C'est le même principe que le chaînage en avant. Sauf que vous choisissez le deuxième itinéraire dans l'autre sens.
Là aussi, la dernière zone du premier itinéraire doit être la même que la première zone du deuxième.

Voici la vidéo explicative :



Le train ralentit et dès que la vitesse est à zéro, il change de sens.
On peut, bien sûr, mixer les deux modes. Et, là, oui, on peut tout faire !

Remarque sur les vidéos :


1°) J'ai fait exprès de rendre immédiate l'accélération. La loco "s'essuie les roues" au démarrage, surtout si vous demandez la vitesse maximale. Cela m'était très utile pour le développement.
Par contre, les ralentissement/arrêts sont, eux, bien naturels.
Voilà un exemple de décélération suivie d'un  arrêt :



On a une décélération qui suit bien une courbe de ralenti réaliste. Le fait que cette courbe ressemble à une décharge de condensateur nous aide bien…

2°) Le retournement est, lui aussi, brutal. Il faudra ajouter un temps d'arrêt en gare dans une prochaine version.

3°) Vous avez certainement cherché un bouton d'inversion de sens du train. Il n'y en a pas !!
Une flèche suit l'orientation de la loco (merci Pierre59 pour cette idée sympa), mais c'est tout.
Si vous voulez reculer, il faut demander un itinéraire dans l'autre sens à partir de la zone où vous êtes.
Pour l'instant, ça ne marche que si vous êtes sur une zone de fin d'itinéraire, mais je suis en cours de développement. La difficulté viendra de l'effacement de tout, y compris les chaînages, si on veut reculer de façon inopinée. Mais c'est jouable.

4°) Au fur et à mesure de l'avancement, comme dans un PRS, les zones s'effacent quand le train les quitte. C'est le but.
Il y aura un autre bouton de recherche d'itinéraires sur le menu où, cette fois, les itinéraires seront sauvegardés pour faire une boucle continue ou une navette sans fin. Faisable aussi.
Les itinéraires continueront à s'effacer au fur et à mesure car c'est la solution qui permet le plus de flexibilité, mais ils se "régénèreront" automatiquement.

5°) Vous avez remarqué qu'on peut poser un train sur n'importe quelle zone. C'est bien.
Mais j'ai à gérer la composition du train pour qu'elle puisse évoluer. On a le droit d'ajouter ou de retirer des véhicules à tout moment, voire le train complet.

6°) Puisqu'on peut aller partout, il faut ajouter une gestion de gare cachée.
On peut d'ores et déjà le faire en demandant une voie précise de la gare, mais il faut que je gère la recherche d'une voie libre automatique.

Voici le lien pour télécharger le programme :
http://www.locoduino.org/IMG/zip/train_tco_v1_6_33.zip
« Modifié: août 09, 2018, 05:41:14 pm par DDEFF »

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #41 le: août 04, 2018, 08:21:33 pm »
Super, Denis : au moins on est certain que tu n'est pas crâmé par la canicule  ;D

Bravo, j'ai lu tout le message et les vidéos : c'est captivant comme d'habitude !

Bon j'ai téléchargé et lancé sur Mac et vlan :
"2018-08-04 20:12:36.448 java[22101:4806959] pid(22101)/euid(502) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!"

Et rien ne s'affiche dans la fenêtre hormis la barre de menu et un tout petit rectangle gris en haut à gauche qui s'avère être les potars de vitesse, mais c'est minuscule. Si je clique sur "+" les potars s'agrandissent.

Quand on veut déplacer la palette des commandes (en cliquant en haut sur le signal), le drag & drop fonctionne bien mais la palette dans sa position initiale reste affichée "sur le dessus" et disparait seulement au relâchement de la souris.

Une autre erreur :
"objc[22117]: 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 (0x1294ddcd8). One of the two will be used. Which one is undefined.
java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at processing.core.PApplet.selectCallback(PApplet.java:6616)
   at processing.core.PApplet.access$1(PApplet.java:6609)
   at processing.core.PApplet$3.run(PApplet.java:6520)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
   at java.awt.EventQueue.access$500(EventQueue.java:97)
   at java.awt.EventQueue$3.run(EventQueue.java:709)
   at java.awt.EventQueue$3.run(EventQueue.java:703)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: java.lang.IllegalArgumentException: This table has no column named 'poids'
   at processing.data.Table.getColumnIndex(Table.java:2228)
   at processing.data.Table.getColumnIndex(Table.java:2198)
   at processing.data.Table.getInt(Table.java:3079)
   at processing.data.Table$RowPointer.getInt(Table.java:2726)
   at Train_TCO_V1_6_32.charge_table_TCO(Train_TCO_V1_6_32.java:5547)
   at Train_TCO_V1_6_32.fileSelected(Train_TCO_V1_6_32.java:2923)
   ... 21 more"

Mais, chapeau, quel beau boulet !

Amicalement

Dominique
« Modifié: août 04, 2018, 08:28:06 pm par Dominique »

DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #42 le: août 04, 2018, 08:39:13 pm »
Merci Dominique ! ;D ;D

L'erreur est sur les Mac, identifiée depuis le 1er Avril (et ce n'est pas un poisson !!) et toujours pas résolue.
Voir le lien :
https://github.com/processing/processing/issues/5462.

Exemple de message sur ce lien, qui résume bien (désolé pour ceux qui ne comprennent pas la langue de Bill Gates**):

"We have by now more than established that this message got introduced with macOS 10.13.4 and that it happens on all systems running macOS.
No need to add more comments saying that you are seeing this as well! Thanks for everyone's reports so far."

Ils on même dû bloquer le post, tellement les gens trouvaient que ça ne marchait pas !! 8)

** allusion au fait que Microsoft a racheté Github

DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #43 le: août 05, 2018, 09:23:44 am »
J'ai trouvé !  ;)

Dominique, les bugs que tu décris sont dus au fait que tu n'est pas dans la bonne directory !

Je m'explique :
Quand on développe en Processing et qu'on a besoin de données, il faut les mettre dans une sous-directory appelée "data".

Exemple ici :

La directory principale s'appelle "Train_TCO_V1_6_32"
Elle contient tous les programmes en .pde qui sont nécessaires ... et la direcyory "data" qui contient les données du réseau.
Donc, tout au même endroit.
C'est super pour faire un .zip, le programme gère ainsi tous les onglets et les ouvre d'un coup, d'un seul et si je veux faire une nouvelle version, j'ouvre un .pde et je fais "enregistrer sous" par exemple Train_TCO_V1_6_33.
Processing va tout seul recréer l'ensemble dans une nouvelle directory Train_TCO_V1_6_33.

Mais, car il y a un mais, le programme "processing.exe" qui est installé sur ton ordi (PC ou Mac) garde en mémoire l'emplacement de l'ancienne directory data qu'il a utilisé la dernière fois.
Et toi, la dernière fois que tu t'en est servi, le fichier "circuit d'essai.tsv" ne contenait pas de colonne "poids" (entre autres) et tout plante.

Et, donc, il suffit d'aller chercher le fichier "circuit d'essai.tsv" de la directory "Train_TCO_V1_6_32/data".
Et ça devrait marcher.

Concernant le "bug" de déplacement du pupitre, il est voulu ( ??? ).
Ce n'est pas très joli, certes, mais c'est la solution la plus économe en temps machine.
D'ailleurs, je ne déplace que le fond de pupitre (pas les curseurs, etc...) en me disant que l'on ne déplacera le pupitre qu'une seule fois.

Amicalement
Denis

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #44 le: août 05, 2018, 10:02:30 am »
Citer
Et, donc, il suffit d'aller chercher le fichier "circuit d'essai.tsv" de la directory "Train_TCO_V1_6_32/data".
Et ça devrait marcher.

Mais c’est ce que je fais ou je n’ai pas compris ta phrase.

Je télécharge ta version (la Mac décompresse automatiquement et je vois le dossier). Dans le dossier double-clic sur le pde qui lance Processing et ouvre ton appli. Quand je la lance elle demande le fichier de données.

Je choisis "circuit d'essai.tsv" là où il est donc ton appli doit connaître son chemin à l’interieur du dossier data.