LOCODUINO

Parlons Arduino => Modélisation, Architectures logicielles et matérielles => Discussion démarrée par: DDEFF le août 20, 2016, 12:18:22 pm

Titre: Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le août 20, 2016, 12:18:22 pm
Bonjour,

Je vais commencer par un état des forces en présence. L'ordre n'a aucune importance.

- Pierre59 (Pierre) a fait un article http://www.locoduino.org/spip.php?article154 (http://www.locoduino.org/spip.php?article154)
On a là une programmation à base d'objets et utilisation intensive des héritages qui permet une description d'un réseau, côté aiguilles, zones, ...

- Pierre a fait un autre article http://www.locoduino.org/spip.php?article167 (http://www.locoduino.org/spip.php?article167) qui, cette fois traite des signaux.
Toujours des objets et des héritages qui permettent la gestion complète de la partie signaux.

- Jean-Luc a, lui, porté son attention sur la gestion des itinéraires http://forum.locoduino.org/index.php?topic=167.0 (http://forum.locoduino.org/index.php?topic=167.0) en partant de ma gare et en étendant à tout un réseau. Là encore, les objets et les héritages et un résultat impressionnant.

- Et, évidemment, toujours de Jean-Luc, les articles sur les gares cachées :
http://www.locoduino.org/spip.php?article155 (http://www.locoduino.org/spip.php?article155)
http://www.locoduino.org/spip.php?article156 (http://www.locoduino.org/spip.php?article156)
http://www.locoduino.org/spip.php?article157 (http://www.locoduino.org/spip.php?article157)

- Pour mémoire, je fais un peu pâle figure avec SGDD qui est bien à base d'objets, mais où je n'avais pas compris la notion d'héritage. Et d'autres choses, d'ailleurs.  :P

Pourtant, toutes ces méthodes (y compris la mienne) souffrent d'une tare originelle : il faut "mettre les mains dans le cambouis" et décrire le réseau "en dur", directement dans le programme.  :o

Cela est, certes, bien expliqué dans les articles cités, mais, à chaque fois, il s'agit d'une méthode de description nouvelle.
On part d'un objet originel, avec des fonctionnalités parfaitement adaptées à l'objectif à atteindre.
Et d'héritage en héritage, on arrive à ce qu'on voulait. Par des méthodes tout à fait géniales, d'ailleurs.

A moins que je n'aie pas compris, il faut décrire plusieurs fois le réseau en fonction des résultats à atteindre. Ce qui est dommage.  :(

D'autre part, cette description se fait directement dans le programme, ce qui n'est pas évident.  :(

Ce qu'il faudrait c'est "un anneau pour les gouverner tous", selon la formule consacrée.

Je ne suis certes pas Sauron (c'est le méchant  8)) et je n'y arriverais pas tout seul. Mais je pense avoir une piste.

Je suis parti sur autre chose : un TCO sur écran, gratuit et sans fils.

J'ai fait une première version, en mode objet, mais sans héritages. Et, donc, très dure à développer.

Pierre a eu pitié de moi et m'a fourni une solution presque "clés en mains", avec le bon objet de départ et les héritages nécessaires. Et là, j'ai (enfin !) compris comment ça marchait. Un grand merci.
Il était temps qu'on me "décolle la pulpe du fond"… ;)

La V2 était donc nettement plus facile à développer, beaucoup plus souple et ceux qui ont vu le résultat ont l'air d'avoir apprécié.
Ces deux versions étaient compatibles avec SGDD. On pouvait suivre le déplacement d'un train géré par un Arduino DUE sur l'écran de l'ordinateur, PC ou Mac.

Et je développe en ce moment la V3 qui ne sera plus compatible SGDD pour plusieurs raisons :

1°) programmation SGDD lourde et "datée"
2°) j'ai voulu adjoindre à l'éditeur de TCO un embryon d'exploitation de réseau

Donc, avec mon éditeur de TCO, je fais (forcément) une description du réseau, à minima graphique.

L'intérêt d'un éditeur étant qu'on ne va pas écrire directement dans le programme. Cela résout l'un des problèmes cités.

Mais on peut plus !

Je suis en train de développer la V3 pour qu'à la fin on ait une matrice qui décrit tous les liens des cantons/aiguilles. Une description littérale, cette fois, du réseau et des connections des éléments entre eux. Description automatique, uniquement générée à partir des éléments graphiques de mon éditeur.

Il me reste à trouver le moyen que cette description soit compatible avec tous les objets dont on aura besoin pour la gestion du réseau.

Dit autrement, je cherche à ce que toutes les instanciations des classes soient paramétrées et qu'elles aillent chercher ces paramètres dans cette matrice. ???

Évidemment, pour l'instant, cette matrice sera sommaire, mais susceptibles d'évolution pour intégrer de nouveaux objets pour gérer le réseau.

Mais c'est une autre histoire…
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le août 20, 2016, 02:12:44 pm
Bravo Denis,

J'approuve ta recherche de ce but qui est la configuration graphique interactive du réseau, stade ultime et évidemment compliqué.

Ce serait pouvoir se passer, enfin, d'un logiciel du commerce pour lequel il faut quand même passer du temps à son apprentissage.

Je réagis juste un peu sur ce que tu affirmes qu'il faut décrire plusieurs fois le réseau avec les 3 propositions de gestionnaire dont Locoduino à probablement l'exclusivité : je montre bien dans le fil du Forum consacré à la solution de Pierre que le réseau est décrit, pour les zones et aiguilles, dans une seule série de méthodes particulières du type "zone suivante paire et impaire" et une autre pour les signaux. C'est facile à organiser dans le code, avec les onglets, pour le rendre fiable et clair.

J'ai hâte de lire la suite
Amicalement
Dominique

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le août 24, 2016, 09:12:41 pm
Tout d'abord, les méthodes proposées par Pierre, Jean-Luc (et même UAD de Thierry) sont tout à fait géniales.
Pour moi, ça ne fait aucun doute et j'aimerais bien les utiliser.
Elles sont même (assez) simples d'emploi pour celui qui a une bonne maîtrise des objets avec tout ce que ça implique. OK.  ;)

Ma problématique, c'est que les instanciations sont littéralement dans le programme. :(

Je vais donner un cas hyper simple : un rond avec 3 cantons.

Quand mon programme de TCO sera fini, j'aurais une matrice block[3], calculée sans intervention autre que dessiner à l'écran :

precedent, courant, suivant
     3                1             2
     1                2             3
     2                3             1

Ce que je veux, c'est que c'est que toute la partie d'instanciation "suivant pair" et "suivant impair" n'aient pas à être écrite dans le programme. Pas littéralement.

Pour décrire le réseau, une instanciation du genre :

for (int i = 0; i < 3; i++) {
    suivant_pair[i] = block[i].suivant();
    suivant_impair[i] = block[i].precedent();
}

Ce que j'ai écrit n'a aucun sens et n'est pas syntaxiquement correct. Mais j'espère qu'on y saisit l'idée.

Je n'ai aucune notion de la vraie syntaxe, ni même si c'est possible. :o
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le août 24, 2016, 10:20:40 pm
Je suis un peu comme toi Denis, certain qu'il existe des outils pour convertir le résultat d'une IHM graphique en programme, soit en passant par un traducteur de tableau (ça peut s'appeler un compilateur), soit en générant du code à partir de Macros paramètrées à partir du tableau ou de l'IHM directement. Il doit bien y avoir d'autres méthodes encore.

C'est ce que font JMRI, RocRail et TrainControler.

Les 2 premiers sont en open source donc on peut regarder dans leur code comment il font (tâche certainement très fastidieuse) !

Attention, en réalisant l'IHM interactive que tu veux faire, il est probable qu'il faille avoir une idée précise de la conversion en code qui doit suivre.

Mais nos experts sauront mieux que moi t'expliquer ...
Sujet très intressant  ::)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le août 24, 2016, 10:39:05 pm
Pour info, j'avais des zones "floues" dans TCO V1 et V2, spécialement dans la numérotation des cantons.

"Flou", en informatique, c'est être assis sur une bombe à retardement...
J'ai repris complètement cette partie qui est maintenant fiable. Mais quel boulot! :P

Et comme je passe d'un TCO purement graphique à un TCO qui prépare un gestionnaire, il était fondamental que la numérotation des cantons soit fiable...

Les infos liées aux cantons et aiguilles ont considérablement évolué. Et, là aussi, je veux qu'elles soient adaptées à tous les programmes à venir.
Toujours l'unicité.

Et, donc, ça avance. ;D
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Thierry le août 25, 2016, 09:48:54 am
La problématique posée par Denis est bien connue. La solution passe par une description 'texte' du résultat à obtenir, puis une analyse de ce texte par le programme pour en déduire les objets.
Reprenons ton cas de trois cantons :

precedent, courant, suivant
     3                1             2
     1                2             3
     2                3             1


Créons une syntaxe qui sera valide pour notre besoin, une ligne du fichier texte pour chaque canton :

précédent, courant, suivant

les trois valeurs sont séparées par des virgule. Eventuellement on peut imaginer une syntaxe encore plus évoluée au cas où il y aurait plusieurs précédents ou plusieurs suivants :

préc1:préc2,courant,suiv1:suiv2

le séparateur entre les différents précédents et suivants est ici un ':' .

Une fois la syntaxe décrite, on crée le fichier qui va bien pour ton exemple :

3,1,2
1,2,3
2,3,1
0


le zéro de fin, s'il n'est pas vraiment obligatoire permet de tout de suite savoir que c'est terminé !

Ce fichier serait stocké dans l'EEPROM, une carte SD ou tout autre moyen de stockage. Reste à créer les objets correspondants : dans le setup une phase de lecture du fichier, d'analyse ligne par ligne pour extraire les données utilisant une petite machine à état basique :

char ligne[80];
int prec[10];
int courant;
int suiv[10];
byte currPrec;
byte currSuiv;

enum TEXTINTERPRETER_STEP
{
TEXTINTERPRETER_STEP_PREC,
TEXTINTERPRETER_STEP_COURANT,
TEXTINTERPRETER_STEP_SUIV
};

#define SEPARATOR ','
#define PRECSUIV_SEPARATOR ':'

TEXTINTERPRETER_STEP etat = TEXTINTERPRETER_STEP_PREC;

currPrec = 0;
currSuiv = 0;
int value = 0;
for (int i = 0; i < 80; i++)
{
if (ligne[i] == 0)
{
// s'il n'y a pas de suivant...
if (etat == TEXTINTERPRETER_STEP_COURANT)
courant = value;

if (etat == TEXTINTERPRETER_STEP_SUIV)
suiv[currSuiv] = value;

break; // fin de ligne
}

if (ligne[i] == SEPARATOR)
{
switch(etat)
{
case TEXTINTERPRETER_STEP_PREC:
prec[currPrec] = value;
value = 0;
etat = TEXTINTERPRETER_STEP_COURANT;
break;

case TEXTINTERPRETER_STEP_COURANT:
courant = value;
value = 0;
etat = TEXTINTERPRETER_STEP_SUIV;
break;

// Pas de case SUIV. C'est traité par la fin de ligne.
}
continue;
}

if (ligne[i] == PRECSUIV_SEPARATOR)
{
switch(etat)
{
case TEXTINTERPRETER_STEP_PREC:
prec[currPrec] = value;
value = 0;
currPrev++;
break;

case TEXTINTERPRETER_STEP_SUIV:
suiv[currSuiv] = value;
value = 0;
currSuiv++;
break;
}
continue;
}

// Value
if (ligne[i] >= '0' && ligne[i] <= '9')
{
value = value * 10 + ligne[i] - '0';
}
}

Une fois les données extraites de la ligne, il est possible de créer les objets (je suis à peu près sûr de ne pas coder ces lignes correctement, il faut en saisir l'esprit !):

    suivant_pair[courant] = block[suiv[0]].suivant();
    suivant_impair[courant] = block[prec[0]].precedent();

c'est un point de départ, le code est là aussi fourni sans aucune forme de test, ni compilation, ni exécution !
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le août 25, 2016, 02:07:51 pm
Merci Thierry !

Je sens qu'on avance.

Je prends l'exemple de Jean-Luc sur les itinéraires (voir : http://forum.locoduino.org/index.php?topic=167.0 (http://forum.locoduino.org/index.php?topic=167.0))

Au départ, la classe Voie. On garde (évidemment !)
class Voie
{
  private:
    byte mIdentifiant;
    byte mDirection;
 
  protected:
    void fixeDirection(byte dir);
   
  public:
    Voie(byte identifiant) { mIdentifiant = identifiant; mDirection = AUCUNE_DIRECTION; }
    byte idVoie() { return mIdentifiant; }
    byte direction() { return mDirection; }
    virtual void connecteDeVoie(Voie *voie, byte connecteur) = 0;
    virtual bool creeCheminVers(byte identifiant, byte dir, Voie *venantDe = NULL) = 0;
};

Entre autres, Jean-Luc a créé la classe Voie avec connecteDeVoie qui permet de connecter des voies entre elles. OK

Puis il crée 5 classes correspondant aux différents types. OK. C'est fondamental et vrai quelque soit le réseau.

Là où je commence à tiquer, c'est lors de la création des objets :
/*
 * Création des objets qui composent la gare
 *
 * Les voies de garage
 */
VoieEnImpasse voieGarage0(VOIE_GARAGE_0);
VoieEnImpasse voieGarage1(VOIE_GARAGE_1);
VoieEnImpasse voieGarage2(VOIE_GARAGE_2);
VoieEnImpasse voieGarage3(VOIE_GARAGE_3);
VoieEnImpasse voieGarage4(VOIE_GARAGE_4);
VoieEnImpasse voieGarage5(VOIE_GARAGE_5);
VoieEnImpasse voieGarage6(VOIE_GARAGE_6);
VoieEnImpasse voieGarage7(VOIE_GARAGE_7);
VoieEnImpasse voieGarage8(VOIE_GARAGE_8);
VoieEnImpasse voieGarage9(VOIE_GARAGE_9);
VoieEnImpasse voieGarage10(VOIE_GARAGE_10);
/*
 * Les voies d'entrée et de sortie
 */
VoieNormale voieLibre0(VOIE_LIBRE_0);
VoieNormale voieLibre1(VOIE_LIBRE_1);
VoieNormale voieLibre2(VOIE_LIBRE_2);
VoieNormale voieLibre3(VOIE_LIBRE_3);
VoieNormale voieLibre4(VOIE_LIBRE_4);
VoieNormale voieLibre5(VOIE_LIBRE_5);
VoieNormale voieLibre6(VOIE_LIBRE_6);
VoieNormale voieLibre7(VOIE_LIBRE_7);
VoieNormale voieLibre8(VOIE_LIBRE_8);
VoieNormale voieLibre9(VOIE_LIBRE_9);
/*
 * Les voies de liaison
 */
VoieNormale voie0(VOIE_0);
VoieNormale voie1(VOIE_1);
VoieNormale voie2(VOIE_2);
VoieNormale voie3(VOIE_3);
VoieNormale voie4(VOIE_4);
VoieNormale voie5(VOIE_5);
VoieNormale voie6(VOIE_6);
VoieNormale voie7(VOIE_7);
VoieNormale voie8(VOIE_8);
VoieNormale voie9(VOIE_9);
VoieNormale voie10(VOIE_10);
VoieNormale voie11(VOIE_11);
VoieNormale voie12(VOIE_12);
VoieNormale voie13(VOIE_13);
VoieNormale voie14(VOIE_14);
VoieNormale voie15(VOIE_15);
VoieNormale voie16(VOIE_16);
VoieNormale voie17(VOIE_17);
VoieNormale voie18(VOIE_18);
VoieNormale voie19(VOIE_19);
VoieNormale voie20(VOIE_20);
VoieNormale voie21(VOIE_21);
VoieNormale voie22(VOIE_22);
VoieNormale voie23(VOIE_23);
VoieNormale voie24(VOIE_24);
VoieNormale voie25(VOIE_25);
VoieNormale voie26(VOIE_26);
VoieNormale voie27(VOIE_27);
VoieNormale voie28(VOIE_28);
VoieNormale voie29(VOIE_29);
VoieNormale voie30(VOIE_30);
VoieNormale voie31(VOIE_31);
VoieNormale voie32(VOIE_32);
VoieNormale voie33(VOIE_33);
VoieNormale voie34(VOIE_34);
VoieNormale voie35(VOIE_35);
VoieNormale voie36(VOIE_36);
/*
 * Aiguillages
 */
Aiguillage aiguille0(AIGUILLE_0);
Aiguillage aiguille1(AIGUILLE_1);
Aiguillage aiguille2(AIGUILLE_2);
Aiguillage aiguille3(AIGUILLE_3);
Aiguillage aiguille4(AIGUILLE_4);
Aiguillage aiguille5(AIGUILLE_5);
Aiguillage aiguille6(AIGUILLE_6);
Aiguillage aiguille7(AIGUILLE_7);
Aiguillage aiguille8(AIGUILLE_8);
Aiguillage aiguille9(AIGUILLE_9);
Aiguillage aiguille10(AIGUILLE_10);
Aiguillage aiguille11(AIGUILLE_11);
Aiguillage aiguille12(AIGUILLE_12);
Aiguillage aiguille13(AIGUILLE_13);
Aiguillage aiguille14(AIGUILLE_14);
/*
 * Croisements
 */
Croisement croisement0(CROISEMENT_0);
Croisement croisement1(CROISEMENT_1);
Croisement croisement2(CROISEMENT_2);
/*
 * TJDs
 */
TraverseeJonctionDouble tjd0(TJD_0);
TraverseeJonctionDouble tjd1(TJD_1);
TraverseeJonctionDouble tjd2(TJD_2);
TraverseeJonctionDouble tjd3(TJD_3);
TraverseeJonctionDouble tjd4(TJD_4);
TraverseeJonctionDouble tjd5(TJD_5);
TraverseeJonctionDouble tjd6(TJD_6);
TraverseeJonctionDouble tjd7(TJD_7);
TraverseeJonctionDouble tjd8(TJD_8);
TraverseeJonctionDouble tjd9(TJD_9);
TraverseeJonctionDouble tjd10(TJD_10);
TraverseeJonctionDouble tjd11(TJD_11);
TraverseeJonctionDouble tjd12(TJD_12);
TraverseeJonctionDouble tjd13(TJD_13);
TraverseeJonctionDouble tjd14(TJD_14);
TraverseeJonctionDouble tjd15(TJD_15);
TraverseeJonctionDouble tjd16(TJD_16);

Ces cantons, aiguilles, etc... existent dans le dessin du TCO, avec leur nom.
Donc, pas à re-créer puisque l'info existe déjà.

Là, je pense que ta manip fonctionne sans problème.

Puis, dans le setup, on a 110 (!) lignes :

voieLibre0.connecteSortantAVoie(aiguille0, ENTRANT);
  aiguille0.connecteSortantDevieAVoie(voie0, ENTRANT);
  aiguille0.connecteSortantDroitAVoie(voie1, ENTRANT);
  voie0.connecteSortantAVoie(tjd0, ENTRANT_BIS);
  voie1.connecteSortantAVoie(tjd8, ENTRANT_BIS);
 
  voieLibre1.connecteSortantAVoie(tjd0, ENTRANT);
  tjd0.connecteSortantAVoie(voie3, ENTRANT);
  tjd0.connecteSortantBisAVoie(voie2, ENTRANT);
  voie3.connecteSortantAVoie(tjd8, ENTRANT);
  tjd8.connecteSortantAVoie(voie22, ENTRANT);
  tjd8.connecteSortantBisAVoie(voie21, ENTRANT);
  voie22.connecteSortantAVoie(aiguille12, SORTANT_DEVIE);
  aiguille12.connecteEntrantAVoie(voieGarage2, SORTANT);
  voie32.connecteSortantAVoie(aiguille12, SORTANT_DROIT);

  voieLibre2.connecteSortantAVoie(tjd1, ENTRANT);
  voie2.connecteSortantAVoie(tjd1, ENTRANT_BIS);
  tjd1.connecteSortantAVoie(voie8, ENTRANT);
  tjd1.connecteSortantBisAVoie(voie6, ENTRANT);
  voie8.connecteSortantAVoie(tjd12, ENTRANT);
  voie21.connecteSortantAVoie(tjd12, ENTRANT_BIS);
  tjd12.connecteSortantAVoie(voie27, ENTRANT);
  tjd12.connecteSortantBisAVoie(croisement2, ENTRANT_BIS);
  voie27.connecteSortantAVoie(tjd15, ENTRANT_BIS);
  croisement2.connecteSortantAVoie(tjd15, ENTRANT);
  tjd15.connecteSortantBisAVoie(voie31, ENTRANT);
  tjd15.connecteSortantAVoie(voie32, ENTRANT);
  voie31.connecteSortantAVoie(aiguille11, ENTRANT);
  aiguille11.connecteSortantDevieAVoie(voieGarage3, SORTANT);
  aiguille11.connecteSortantDroitAVoie(voieGarage4, SORTANT);

  voieLibre3.connecteSortantAVoie(tjd2, ENTRANT);
  voie6.connecteSortantAVoie(tjd2, ENTRANT_BIS);
  tjd2.connecteSortantAVoie(voie12, ENTRANT);
  tjd2.connecteSortantBisAVoie(voie11, ENTRANT);
  voie12.connecteSortantAVoie(tjd11, ENTRANT_BIS);
  voie20.connecteSortantAVoie(tjd11, ENTRANT);
  tjd11.connecteSortantBisAVoie(voie26, ENTRANT);
  tjd11.connecteSortantAVoie(croisement2, ENTRANT);
  voie26.connecteSortantAVoie(tjd14, ENTRANT);
  croisement2.connecteSortantBisAVoie(tjd14, ENTRANT_BIS);
  tjd14.connecteSortantAVoie(voie30, ENTRANT);
  tjd14.connecteSortantBisAVoie(voie29, ENTRANT);
  voie30.connecteSortantAVoie(aiguille10, ENTRANT);
  aiguille10.connecteSortantDroitAVoie(voieGarage5, SORTANT);
  aiguille10.connecteSortantDevieAVoie(voie34, ENTRANT);
  voie34.connecteSortantAVoie(aiguille14, SORTANT_DROIT);
  voie33.connecteSortantAVoie(aiguille14, SORTANT_DEVIE);
  aiguille14.connecteEntrantAVoie(voieGarage6, SORTANT);
 
  voieLibre4.connecteSortantAVoie(tjd4, ENTRANT);
  voie11.connecteSortantAVoie(tjd4, ENTRANT_BIS);
  tjd4.connecteSortantAVoie(voie16, ENTRANT);
  tjd4.connecteSortantBisAVoie(croisement0, ENTRANT_BIS);
  voie16.connecteSortantAVoie(tjd7, ENTRANT_BIS);
  croisement0.connecteSortantAVoie(tjd7, ENTRANT);
  tjd7.connecteSortantAVoie(voie20, ENTRANT);
  tjd7.connecteSortantBisAVoie(voie19, ENTRANT);
  voie19.connecteSortantAVoie(aiguille8, SORTANT_DROIT);
  voie25.connecteSortantAVoie(aiguille8, SORTANT_DEVIE);
  aiguille8.connecteEntrantAVoie(voie28, ENTRANT);
  voie28.connecteSortantAVoie(tjd16, ENTRANT);
  voie29.connecteSortantAVoie(tjd16, ENTRANT_BIS);
  tjd16.connecteSortantAVoie(voie33, ENTRANT);
  tjd16.connecteSortantBisAVoie(voieGarage7, SORTANT);

  voieLibre5.connecteSortantAVoie(tjd3, ENTRANT_BIS);
  voie10.connecteSortantAVoie(tjd3, ENTRANT);
  tjd3.connecteSortantAVoie(croisement0, ENTRANT);
  tjd3.connecteSortantBisAVoie(voie15, ENTRANT);
  voie15.connecteSortantAVoie(tjd6, ENTRANT);
  croisement0.connecteSortantBisAVoie(tjd6, ENTRANT_BIS);
  tjd6.connecteSortantAVoie(voie18, ENTRANT);
  tjd6.connecteSortantBisAVoie(croisement1, ENTRANT_BIS);
  voie18.connecteSortantAVoie(tjd10, ENTRANT_BIS);
  croisement1.connecteSortantAVoie(tjd10, ENTRANT);
  tjd10.connecteSortantAVoie(voie25, ENTRANT);
  tjd10.connecteSortantBisAVoie(voieGarage8, SORTANT);

  voieLibre6.connecteSortantAVoie(aiguille3, SORTANT_DROIT);
  voie5.connecteSortantAVoie(aiguille3, SORTANT_DEVIE);
  aiguille3.connecteEntrantAVoie(aiguille4, ENTRANT);
  aiguille4.connecteSortantDroitAVoie(voie9, ENTRANT);
  aiguille4.connecteSortantDevieAVoie(voie10, ENTRANT);
  voie9.connecteSortantAVoie(tjd5, ENTRANT_BIS);
  voie14.connecteSortantAVoie(tjd5, ENTRANT);
  tjd5.connecteSortantAVoie(croisement1, ENTRANT);
  tjd5.connecteSortantBisAVoie(voie17, ENTRANT);
  voie17.connecteSortantAVoie(tjd9, ENTRANT);
  croisement1.connecteSortantBisAVoie(tjd9, ENTRANT_BIS);
  tjd9.connecteSortantAVoie(voie24, ENTRANT);
  tjd9.connecteSortantBisAVoie(voie23, ENTRANT);
  voie24.connecteSortantAVoie(aiguille9, SORTANT_DROIT);
  voie36.connecteSortantAVoie(aiguille9, SORTANT_DEVIE);
  aiguille9.connecteEntrantAVoie(voieGarage9, SORTANT);

  voieGarage0.connecteAVoie(aiguille1, ENTRANT);
  aiguille1.connecteSortantDroitAVoie(voie5, ENTRANT); 
  aiguille1.connecteSortantDevieAVoie(voie4, ENTRANT);

  voieGarage1.connecteAVoie(aiguille2, SORTANT_DEVIE);
  voie4.connecteSortantAVoie(aiguille2, SORTANT_DROIT);
  aiguille2.connecteEntrantAVoie(voie7, ENTRANT);
  voie7.connecteSortantAVoie(aiguille5, ENTRANT);
  aiguille5.connecteSortantDevieAVoie(voieLibre9, ENTRANT);
  aiguille5.connecteSortantDroitAVoie(aiguille6, ENTRANT); 
  aiguille6.connecteSortantDroitAVoie(voieLibre8, ENTRANT); 
  aiguille6.connecteSortantDevieAVoie(aiguille7, ENTRANT);
  aiguille7.connecteSortantDroitAVoie(voie14, ENTRANT);
  aiguille7.connecteSortantDevieAVoie(voie13, ENTRANT);
  voie13.connecteSortantAVoie(tjd13, ENTRANT);
  voie23.connecteSortantAVoie(tjd13, ENTRANT_BIS);
  tjd13.connecteSortantAVoie(voie36, ENTRANT);
  tjd13.connecteSortantBisAVoie(voie35, ENTRANT);
  voie35.connecteSortantAVoie(aiguille13, ENTRANT);
  aiguille13.connecteSortantDroitAVoie(voieGarage10, SORTANT);
  aiguille13.connecteSortantDevieAVoie(voieLibre7, ENTRANT);

Et, là, ça serait quand même bien que ce soit automatique, toujours à partir de la matrice issue du TCO.

Que les choses soient bien claires : c'est normal que Jean-Luc ait fait comme ça, ce n'est en aucun cas une critique de la méthode qui fonctionne parfaitement.
Je cherche à ne pas re-saisir pour que des néophytes puissent utiliser cet excellent programme.

Par contre, je suis bien conscient que, côté programmation, ça ne va pas être de la tarte !!  :-[
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Thierry le août 25, 2016, 04:36:34 pm
Non, ce n'est pas compliqué, mais il faut définir les besoins dès le départ, et c'est cette définition qui va permettre d'avancer.

D'après ce que j'ai lu, les liens possibles sont :

connecteAVoie
connecteSortantAVoie
connecteSortantDroitAVoie
connecteSortantDevieAVoie
connecteSortantBisAVoie
connecteEntrantAVoie
connecteEntrantBisAVoie

avec deux chances en plus. Un, il faut deux arguments, quelle que soit le lien, et deux, des identifiants sont utilisés pour la création de tous les objets. Il 'suffit' donc de définir la bonne syntaxe. Pour changer, j'ai utilisé le '/' comme séparateur, mais c'est un choix personnel !

objet/type de connection/objet lié/type de lien

'objet' et 'objet lié' sont les identifiants donnés dans les constructeurs et correspondent à l'objet concerné, et à celui passé en argument. bien sûr on parle là de leur valeur numérique, pas de AIGUILLE_12 ici !

'type de connexion' va être une version abrégée de la liste citée plus haut :

V : connecteAVoie
SV : connecteSortantAVoie (!)
SRV : connecteSortantDroitAVoie
SVV : connecteSortantDevieAVoie
SBV : connecteSortantBisAVoie
EV : connecteEntrantAVoie
EBV : connecteEntrantBisAVoie


et le type de lien sera :

E : ENTRANT
S : SORTANT
EB : ENTRANT_BIS
SR : SORTANT_DROIT
SV : SORTANT_DEVIE


ne reste plus qu'à construire le fichier avec tous les liens, genre

127/V/12/E

et le décompresser comme expliqué plus haut. On peut même sans doute simplifier l'analyse en n'utilisant qu'un seul caractère pour ces types, ou toujours trois caractères...


Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le août 25, 2016, 05:17:39 pm
J'aime quand on me parle comme ça  ;D ;D

Je sais maintenant que je peux me lancer dans l'évolution majeure de la V3 : décrire, à partir des cubes et des dessins, les liens entre cantons et entre aiguilles.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le septembre 04, 2016, 03:09:32 pm
La V3 avance, mais ça n'est pas facile...

A partir du moment où on fait un éditeur, et que, donc, on est soumis à une RHM (relation homme-machine).
Et, un bonhomme, ça peut faire n'importe quoi, effacer des données sensibles, renter des chose incohérentes et le système doit résister à tout.

Par ailleurs, ce système passant du statut de gentil machin graphique à création d'une base solide pour un futur système de gestion, il doit s'étoffer.

J'en suis au stade où j'ai toutes les coordonnées x et y (origine-extrémités de tout ce qui est tracé sur les cubes). C'était une phase "hardue" ;)  parce que les cubes peuvent s'étendre avec la molette et la mise à jour des x-y doit suivre !

La phase suivante (plus simple) verra ces coordonnées affectées aux origine-extrémité des cantons et des aiguilles (au sens large puisque ça va du croisement à la TJD en passant par les aiguilles).

Et, une fois cet état atteint, on pourra faire la matrice décrivant tout réseau de façon automatique.

A suivre, donc. :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le septembre 17, 2016, 09:29:08 am
Grande avancée hier : j'ai trouvé pourquoi, par moments, je perdais des cubes.
Et j'ai corrigé. Mais ça faisait "un certain temps" que je me cassais les dents sur ce problème, tant ça paraissait aléatoire...  ;D

J'arrive maintenant à suivre les points particuliers des cubes et je réorganise les cubes de cantons. Très bientôt, les aiguilles.
Plus tard, la fameuse matrice qui permettra d'expliquer l'organisation du réseau aux autres programmes.

Je gère maintenant correctement le choix des fichiers, ainsi qu'une fonction "undo" bien pratique. Et à plusieurs niveaux !

A suivre  : :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le septembre 20, 2016, 06:08:39 pm
ça y est, j'ai ma matrice !  8)
Il reste encore des bugs, mais ça marche.

A peaufiner, donc  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Patrick75 le septembre 21, 2016, 09:03:01 pm
Je serai tenté par une description du réseau dans une matrice bien que ça diverge de la programmation C++ objet orthodoxe,  si je comprends bien.

Notre projet de réseau est complexe :
. 80 cantons à 2 zones environ plus une 20aîné de  zones d'aiguilles et une 10aine de zones d'arrêt supplémentaires pour les  cantons banalisés
. une 50aine d'aiguilles
. 5 à 8 pupitres de commande d'aiguilles et de carré de protection et la répétition des signaux de Bal Sncf
. pas d'itinéraires automatiques
. détection par consommation de courant à partir d'une source 24V continu
. 2 sources de courant traction Vnormal, Valentino
. un Arduino Due par canton, pupitre, zone complexe d'aiguilles

Le réseau sera construit en plusieures phases.

Je préférerais que la programmation de tous les Due de cantons soit identique et aussi definitive que possible.

La référence à une matrice unique centrale avec si possible une procédure de distribution automatique au démarrage me plairait bien.

Qu en pensez vous ?

Merci pour tous vos messages et articles qui nous aident beaucoup.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le septembre 22, 2016, 09:29:48 am
Merci de l'intérêt porté à mon fil  :D

Je réponds dans l'ordre :

1°) La programmation objet complète est le Graal de la programmation en C++.
Aussi, je ne préconise absolument pas de créer une matrice pour gérer le réseau.

Je devrait plutôt dire "plus" car c'est ce que je faisais dans SGDD 1 et 2  ;)
Mais je débutais en C++ et je n'avais pas saisi toute la subtilité et la puissance de la programmation objet.

Mais pourquoi suis-je content, alors, d'avoir réussi à créer une matrice ?
Parce que c'est une matrice particulière qui doit me permettre, normalement, d'utiliser n'importe que programme sans avoir à y re-décrire le réseau.
Et, tant qu'à faire, utiliser les programmes des autres qui, eux, maîtrisent parfaitement la programmation objet (Jean-Luc, Pierre59, Thierry, ...) moyennant une adaptation.

Pour l'instant, j'avance à petits pas, mais j'ai la certitude que la solution est possible.
Je teste actuellement sur le réseau que j'ai déjà pris comme modèle dans mes articles SGDD.
Et il traîne encore des bugs que j'élimine un à un.

2°) Quel réseau ! 8)  8)

Deux-trois trucs me font "tilter" néanmoins :

- "Pas d'itinéraire automatique" ?: avec un tel réseau, ça va être coton à gérer !

- "24V continu" : ça me rappelle Pierre Chenevez  ::)

- "Un Arduino DUE par canton" : ça me paraît disproportionné. Je suis sûr qu'on peut faire plus simple.
Via un bus CAN, on en est à un NANO pour gérer 8 aiguilles.

Et un seul DUE pour tout le réseau.
Pour 80 cantons et 50 aiguilles, il en faudra peut être deux (une éventuelle question de temps de traitement), mais ça n'est même pas sûr.

Mais le projet nous intéresse, c'est évident  ;D ;D
Essaie de le détailler dans un fil que tu créerais.

A bientôt.

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le octobre 19, 2016, 06:16:41 pm
Bonjour à tous,

J'en suis arrivé à une version 1.3 qui possède déjà pas mal des caractéristiques finales. ;D ;D

Mode d'emploi :


Lancer Processing, choisir l'un des 3 fichiers, ce qui prend les 3 (les trois dont le nom ont la même date)
Faire clic, puis L (= load).
Je ne sais pas pourquoi je suis obligé de faire clic, mais c'est obligatoire et je n'arrive pas à m'en débarrasser...

Là, on voit 14 (!!!) commandes de locos, mais c'est pour voir presque tous les types de feux.
On peut choisir parmi les 29 (!!) fonctions du DCC par un clic, pour chaque loco.

Évidemment, je vais faire une version 7 fonctions (F0 à F6), 14 fonctions (F0 à F13).
On peut zoomer sur la palette, la déplacer.
Et on peut sélectionner le nombre de trains dans le 1er onglet, ligne 57, variable c_max_p = 28 colonnes pour 14 trains. Il faut évidemment choisir un nombre pair ...

Il reste des lignes à virer, des lignes à ajouter (la dernière case qui servira à la photo de la loco) et, plus dur, gérer le port série avec le DUE.
Et .... tester PCDuino !

Pour l'instant, ce qui marche :

1°) un feu aux dimensions exactes (époque III).  ;D ;D

Dans la V1.2, les dimensions étaient fausses et j'ai dû tout revoir.
J'ai eu du mal à récupérer les infos dont j'avais besoin.
C'était sur le forum LR (http://forums.e-train.fr/viewtopic.php?f=20&t=57722 (http://forums.e-train.fr/viewtopic.php?f=20&t=57722)) et sur un autre que certains connaissent déjà : le petit train du Tertre (http://lestrainsdutertre.redheberg.com/TouteVapeur/Bienvenue.html (http://lestrainsdutertre.redheberg.com/TouteVapeur/Bienvenue.html))
Vaut le détour !

2°) Le fonctionnement du signal est calqué sur le CabSignal de Pierre59, un futur additif du Locodrome (http://www.locoduino.org/spip.php?article172&var_mode=calcul (http://www.locoduino.org/spip.php?article172&var_mode=calcul)), dont j'avais eu la primeur (merci Pierre).
Globalement, le programme complet est fortement inspiré du locodrome et j'ai encore d'autres choses à y découvrir et adapter à mon projet.
C'est une véritable mine.
Pour info, j'ai pris la vraie fréquence de clignotement, 1.1 Hz.

3°) J'ai voulu une interface agréable à regarder (je vais l'avoir sous les yeux ... un certain temps).

La vitesse est réglée par un curseur qu'on peut déplacer à la souris.
C'est la vitesse demandée par le conducteur.
A droite, on a un barregraphe coloré qui correspondra à la vitesse réelle du train.
C'est à dire que si, pour l'instant, les deux sont liées, ce ne sera plus vrai à terme.
On demande la vitesse maxi, par exemple, et le train va mettre un certain temps pour l'atteindre.
D'où le décalage qu'il y aura entre la position du curseur et la hauteur du barregraphe.

Le gestionnaire enverra une consigne de vitesse maxi, quelle que soit la position du curseur.

Par ailleurs, la cote du barregraphe, analogique par nature, est affichée en digital au dessus, en bleu.

Pour l'instant, ça va de 0 à 100, mais il faudra que la vitesse maxi soit fonction de la loco (dans son fichier, j'y reviendrai).
J'ai mis des graduations logarithmiques, pour l'instant.
J'ai essayé des graduations qui suivent la courbe logistique, la vraie, mais ce n'est pas terrible, tassé en haut et en bas...

4°) Reste une case vide en bas.
Ce sera la photo de la loco.
Et, dans le fichier de la loco (un quatrième, donc), on sauvera la vitesse maxi du train et peut-être certains CV, quand je gèrerais le DCC.

A suivre  :P

Le fichier image joint, très tassé, ne rend pas la qualité du vrai affichage vectoriel.
(http://forum.locoduino.org/index.php?action=dlattach;topic=211.0;attach=472;image)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le octobre 22, 2016, 11:22:18 am
Suite à quelques questions qui m'ont été posées (en off), je précise un peu plus ma démarche.
J'ai, en cours de développement toujours, deux programmes complémentaires.
Je vous ai présenté le deuxième dans le précédent post et, en PJ, vous trouverez le premier. Je sais, c'est un peu bizarre ... :)

Le premier programme est un éditeur de TCO.

Le but étant que quelqu'un qui n'est pas forcément féru de C++ (Arduino), de Java (Processing) puisse dessiner son réseau et avoir un vrai TCO.
On a à sa disposition une palette contenant tous les symboles nécessaires (on pourrait en ajouter, d'ailleurs) et, par drag & drop, on les mets où on veut, on les oriente, on les copie, on les déplace par lots, ... Bref, on dessine petit à petit son réseau.

Je me suis très fortement inspiré du Locodrome de Pierre (=Pierre59), qui est une formidable boîte à outils concernant les objets, des briques, qu'on peut adapter à ses goûts et ses besoins.

Les briques qui permettent de dessiner une Ferrari peuvent aussi servir à dessiner un tracteur :
Ils ont tous les deux quatre roues. Je prends les roues de la Ferrari, je change la taille et j'ai des petites roues à l'avant et des grandes à l'arrière !

Ce programme a été développé sous Windows, avec une vraie souris à molette, ce qui est extrêmement pratique à l'usage.

Pour la fonction zoom, on a le choix entre mettre la souris au dessus de la partie à zoomer et tourner la molette dans un sens ou dans l'autre.
Si on n'a pas de souris, on fait + ou -, toujours en ayant mis la souris sur la partie qu'on veut zoomer.

Sur un portable, avec un touchpad, c'est effectivement moins pratique, mais possible.

On peut évidemment sauver ce qu'on a fait (ouf ! ;)) simplement en appuyant sur "S".

Cela génère trois fichiers texte :
--> Un fichier qui décrit chaque cube, avec toutes ses caractéristiques
--> Un fichier qui décrit les cantons (donne la liste des cubes qui le composent) et qui donne l'élément suivant et précédent
--> Un fichier qui décrit les aiguilles (donne la liste des cubes qui le composent) et qui donne les éléments qui y sont rattachés
J'appelle "élément" un canton ou une aiguille.
"Aiguille" au sens (très) large : aiguille, TJD, croisement, triple...

Quand on a fini de dessiner son TCO, ces 3 fichiers seront à transférer de la directory "data" du TCO à la directory "data" des commandes.
Comme vous le remarquerez, le nom des fichiers suit une logique stricte : quand on sauve, le nom du fichier contient la date, l'heure (minutes et secondes).
C'est comme ça qu'on les relie ensemble.
Il est d'ailleurs quasi obligatoire de trier la directory data en fonction de la colonne date. Comme ça, les 3 fichiers sont ensemble.

Le deuxième programme sert à commander les trains

Il y a toujours une palette, mais elle contient des éléments de commande des trains.
L'autre palette a disparu, on ne peut plus bouger les cubes ni modifier le tracé.
Mais, alors qu'on ne pouvait pas changer la position des aiguilles, là, on pourra (pas encore fait).

Je pense que je ne ferais pas directement la commande des aiguilles, mais celle des itinéraires, en utilisant une méthode différente du Locodrome :
Premier clic sur un train, deuxième clic sur sa destination. Et c'est le programme qui se débrouillera pour savoir comment y aller.

Là, le programme de Jean-Luc sera bien utile, même si, pour l'instant, il n'a pas cette fonction.

En tous cas, je ne veux pas avoir à dresser moi-même la liste de tous les itinéraires possibles.

La nouvelle palette contient à l'ouverture 14 manettes. C'est beaucoup trop.
Allez ligne 57 et mettez "8" au lieu de "28". Vous n'aurez plus que 4 manettes, ce qui est déjà pas mal.

Et là, vous apprécierez (je l'espère) de pouvoir déplacer la manette où vous voulez et surtout de zoomer dessus.
Vous verrez la qualité des fonctions de dessin vectoriel de Processing : ça reste net à grande échelle. Vous pourrez voir les ombres sous le curseur, etc...

Avenir :

Malheureusement, je me rends compte en développant le deuxième programme qu'il a une influence sur le premier. D'où le fait que ferai l'article sur le premier quand je saurais qu'il n'évoluera plus.

Ce que je voudrais développer aussi, c'est que le point qui symbolise une loco dans le Locodrome avance exactement en phase avec le vrai train.
J'entends par là qu'on puisse en déduire la vitesse réelle du train à tout moment. J'ai des pistes, mais il faut se lancer.

Processing existe aussi pour Android (et pas trop pour Iphone). On peut donc envisager une manette déportée sur un mobile.
J'attends l'article de bobyAndCo pour voir comment l'intégrer  ;D ;D

Vous noterez également que les fonctions DCC sont distinctes du reste. En virant une colonne sur deux, on peut envisager une commande analogique. A voir.
En fait, c'est aussi un labo. C'est quand même agréable de faire ce qu'on veut...

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 12, 2016, 02:18:52 pm
Je propose aujourd'hui de faire le point sur ce que je veux faire, à terme, et ce qui fonctionne déjà.

Étant donné le prix des logiciels du commerce, n'ayant peur de rien, j'ai cherché à en faire un moi-même, à ma sauce.
Je dis tout de suite que, sans un site comme Locoduino, je n'y serais jamais arrivé. Imaginez qu'en 2014, je ne connaissais pas le langage C…

Quatre ordinateurs

Le premier, c'est celui du salon (ou du bureau, comme vous voulez) et vous devez installer dessus la dernière version de Java et du logiciel Processing.
Avec Processing, mon premier logiciel en Processing : TCO.

Processing ?

Pour faire simple, un Arduino sait exécuter une tâche quand vous appuyez sur un bouton poussoir, allumer une LED, …
Mais il est très pauvre en entrées sorties avec un écran.

Processing sait, par contre, gérer quasiment tout ce que vous voulez faire sur un écran (faire tourner des figures en 3D, dessiner en 2D, …) mais il ne sait pas allumer une LED !

En fait, ces deux là sont faits pour s'entendre, via le bus série.

Donc, sur votre ordinateur (PC, Mac ou Linux) vous allez créer votre TCO en jouant avec des petits cubes. Vous pourrez les déplacer, les copier-coller ou couper-coller.
Tout ça avec une palette qui contient, à l'origine, tous les types de figures (ligne droite, courbe, aiguilles, croisements, TJD, TJS et triples)

J'ai voulu une interface sobre, épurée, avec le moins de texte possible.
En plus, je cherche à dessiner un réseau complet (c'est absolument indispensable ici, vous verrez pourquoi), une représentation assez proche de la réalité, y compris des longueurs à l'échelle.

On peut évidemment sauver le résultat et cela génère 4 fichiers textes :

Block___2016_11_10__08_04_55.tsv
C_panel_2016_11_10__08_04_55.tsv
Turnout_2016_11_10__08_04_55.tsv
Specifs.h

Les trois premiers sont liés par une date-heure commune (à la seconde près) et sont destines au deuxième ordinateur.
Le quatrième est destiné au troisième ordinateur.

Quand votre TCO est complètement dessiné, vous n'avez plus besoin du premier ordinateur. Après tout, on ne change pas de réseau tous les jours…

(http://www.locoduino.org/IMG/jpg/tco_dom1.jpg)

Le deuxième ordinateur

Ce n'est plus un vrai ordinateur, mais un couple PCDuino3 - écran.
Et quand je dis écran, c'est un grand écran (27", au moins) et il est attaché au mur, comme les vrais TCO.
Et si je pouvais, il ferait toute la longueur du mur, comme les vrais TCO.
Je pense qu'on peut même recycler une ancienne TV à écran plat.

PCDuino3 ?

Pour 70 €, vous allez avoir un micro ordinateur qui fonctionne en Linux. L'écran se branche en HDMI.
Et comme Processing fonctionne aussi en Linux, vous installerez mon deuxième logiciel : Commandes.

Il faut copier les 3 fichiers en .tsv avec et vous retrouverez votre joli dessin de TCO, mais plus la palette qui servait à le dessiner.

(http://www.locoduino.org/IMG/jpg/commande_dom.jpg)

A la place, un boîtier de commandes qu'on peut déplacer et dimensionner pour conduire de 1 à n trains. Commande uniquement à la souris.
Cette partie est en cours de développement.

A court terme, je souhaite doter le programme de Jean-Luc d'entrées sorties plus conviviales en le gérant depuis Processing. Et intégrer le programme de Pierre (= Pierre59), celui qui gère le célèbre Locodrome.

Par rapport aux solutions du commerce, j'insiste sur trois points :

1°) Maintenant que j'ai dessiné le TCO, je ne décrirai plus le réseau une nouvelle fois. Il faudra que ça se débrouille pour toutes les fonctions.

On vient de voir que le programme de Jean-Luc pouvait être intégré (http://forum.locoduino.org/index.php?topic=167.45 (http://forum.locoduino.org/index.php?topic=167.45)) et que donc, automatiquement, tous les itinéraires possibles sont calculés. C'est même tellement rapide qu'on n'a pas besoin de les sauvegarder : ils sont calculés à la demande, en quelques millisecondes.

Je ne veux pas non plus décrire des trajets : ce sera au programme de les trouver, en fonction de paramètres à définir.

2°) J'affiche sur chaque commande le signal que "voit" le conducteur de la loco.
Sous une forme agréable et conforme à la réalité SNCF, pas un simple voyant.

3°) Par ailleurs, je veux voir les trains se déplacer.
J'entends par "se déplacer" un mouvement continu. Pas un bond brutal de canton en canton.
Un mouvement coulé qui suit de belles courbes, sur des cantons pas forcément rectilignes, horizontaux ou verticaux.

C'est même cette fonction qui doit me permettre d'avoir sur la commande la vitesse réelle du train.
Quel plaisir de voir la vitesse réelle se rapprocher progressivement de la vitesse de consigne !

Certes, ça suppose que les paramètres DCC soient bien ajustés, via une phase de tests. A mon avis assez longue.

Donc, un point va se déplacer, accélérer, ralentir, en fonction de la vitesse réelle du train. C'est pour cette raison que le tracé du TCO doit correspondre au vrai tracé du train.
A chaque signal de changement de canton, d'aiguille, cela donnera un top qui resynchronisera le point par rapport au point sur l'écran. Plus les paramètres DCC seront précis, plus le dessin du TCO sera proche de la réalité, plus ce sera facile de resynchroniser.

Une fois qu'on est synchrone, tout est possible :
1°) Plus besoin de couper les rails pour les zones d'arrêt
2°) On peut déclencher une action (sifflet, par exemple) a un point précis du réseau, sans ILS ou autre.

Le troisième ordinateur

Cette fois-ci, c'est un Arduino DUE, gestionnaire du réseau.
Il est relié au PCDuino3 par un câble USB série (au moins pour les essais).
Il reçoit du PCDuino3 les ordres (choix d'itinéraires, vitesse, …) et lui envoie le résultat (occupation des cantons, couleur des signaux, …)

C'est là que vous utilisez le fichier "Specifs.h" généré par TCO, au début.

La partie description du réseau existe (le programme de Jean-Luc), mais il reste beaucoup à faire.
En particulier répondre à la question très complexe : parmi tous les itinéraires calculés, quel est le meilleur ?

C'est là aussi qu'il me faut intégrer la partie signaux de Pierre. J'ai bon espoir.

Et, évidemment, le DUE est relié au réseau via un bus CAN.

Je ne veux pas voir de fils sous le réseau.
Uniquement des câbles Ethernet avec des RJ11/RJ45 qui vont de modules en modules.

Jean-Luc a réalisé le premier d'entre eux : le module 8 aiguilles.

On fera évidemment un module cantons.

Les possibilités du bus CAN sont énormes et permettront à la fois de gérer la mise en place des aiguilles, mais de gérer aussi toute la rétro-signalisation.

Les bibliothèques de Thierry permettront une gestion simplifiée de tous ces échanges.

Le quatrième ordinateur

C'est la centrale DCC, avec un Arduino MEGA.

Logiciel DCC++ dont Dominique vous a déjà parlé sur le Forum et dans des articles.

Relié bien sûr au gestionnaire. A définir.
Je penche pour un lien vers le DUE par le bus série et relier le DUE au PCDuino par un bus CAN.
Le deuxième bus CAN du DUE vers le réseau.

En fait, la seule information qui va être véhiculée sera du DUE vers le MEGA, c'est la vitesse maxi de consigne.
Exemple : "Je veux que le train 1 aille au maximum à 30 km/h".

Cela suppose que cette centrale DCC puisse commander plusieurs trains. A suivre.

Comme vous le voyez, c'est extrêmement ambitieux, mais faisable.
Et qu'on peut agglomérer les réalisations des uns et des autres en un ensemble complet.

C'est très motivant.
N'hésitez pas à vous exprimer, à donner vote avis.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 19, 2016, 08:59:45 am
Je commence à voir un peu de lumière dans le programme de Jean-Luc (voir le fil sur ce programme).
Par ailleurs, concernant Processing, je vois le cheminement pour intégrer le Locodrome de Pierre.

Au passage, je vais faire figurer les retraits de Pierre (un blanc entre 2 cantons, pour les séparer) en l'automatisant de manière simple :
Il faut ajouter un retrait entre 2 cubes voisins s'ils n'ont pas le même label ! :D

Au début, je ne voulais pas faire figurer de signaux.
Ceux de Pierre sont sobres et je vais les ajouter, avec un détail supplémentaire :
Signal un feu quand on est en pleine voie et 2 feux quand on peut avoir le carré ou les ralentissements, rappels, etc...

A suivre  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le décembre 06, 2016, 04:42:23 pm
Juste une remarque :

Comme je viens de mettre un nouveau Post sur le fil de Jean-Luc, je vais devoir adapter mon programme TCO pour que les enum{...} soient dans le bon ordre.
Comme ça, ça me repose un peu .... ;D
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le janvier 11, 2017, 02:22:11 pm
Bonjour,

Je viens de terminer mes deux courbes de 90°, l'une droite et l'autre orientée à 45°.
Ces deux courbes sont extensibles.

Pourquoi avoir recommencé, puisque ça marchait déjà avant ?

C'est simple : après avoir correspondu avec Pierre (=Pierre59), il m'a expliqué qu'il avait changé de courbes de Bezier.
Il utilise maintenant des courbes dites cubiques au lieu de courbes quadratiques.

Dans les courbes quadratiques, on n'a qu'un point attracteur et donc assez peu de possibilité de manœuvre.
Disons que si on veut faire un joli cercle, on s'en approche avec une sorte de parabole.

Dans les courbes cubiques, on a deux points attracteurs, avec 2 vecteurs associés.
Et là, si on veut approximer un cercle, on est presque à la perfection.

Voilà ce que ça donne en vrai :

(http://www.locoduino.org/IMG/png/comparatif_quadraticvertex_et_beziervertex.png)

A gauche, une courbe quadratique et à droite une courbe cubique.

Si on observe bien, la courbe quadratique souffre de deux défauts :
1°) elle est trop "pointue" pour simuler un cercle
2°) si vous regardez vraiment bien, vous verrez que l'épaisseur du trait varie et qu'elle est plus fine au milieu.

Mais pourquoi vouloir approximer un cercle ?

C'est vrai qu'on nous a expliqué depuis longtemps que la courbe idéale pour les trains était justement la parabole.
C'est toujours vrai, pour les vrais rails. Pour les trains réels et aussi pour les nôtres.

Mais là, on est sur un TCO qui ne représente qu'approximativement notre réseau. Ce n'est donc pas un réel problème d'approximer une parabole par un cercle pour un TCO.

Et surtout, si on veut faire rouler des trains sur le TCO, c'est beaucoup plus simple à programmer !!
D'où le réel intérêt de ce changement de type de courbes.

Sinon, le train du TCO va rouler à côté des rails !!  ;D ;D

Il me reste à faire la même chose pour les 1/8è de cercle, eux aussi extensibles.  :-*



Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le janvier 14, 2017, 05:17:16 pm
"Les mathématiques, c'est l'art de raisonner juste sur une figure fausse"… disait mon prof de maths en 4ème.

Une fois n'est pas coutume, je vais vous donner un petit aperçu des choses qu'on doit résoudre pour faire un TCO élégant. Je vous rassure, je n'irai pas ici plus loin que des maths niveau 5ème.

On a vu dans le post précédent qu'on allait maintenant utiliser des courbes de Bezier cubiques pour avoir de jolis cercles. On pourra ainsi voir nos petits trains rouler exactement au milieu du tracé du TCO.
Pour le 1/4è de cercle, c'était "assez" facile puisque le centre du cercle était bien dans le coin.
Pour le 1/8è de cercle, ça n'est plus vrai et il va falloir chercher les coordonnées.

J'ai fait ce joli dessin avec le logiciel gratuit que mes enfants utilisaient au collège : Geogebra.
Je vous conseille de le télécharger (https://www.geogebra.org/download), de façon à pouvoir zoomer sur certains points, ça peut être instructif.

(http://www.locoduino.org/IMG/png/courbe_un_carre.png)

J'appellerai "e" le côté du carré. il est fixé à le 9 dans le locodrome, mais je voulais calculer pour n'importe quelle valeur. Il est à 10 chez moi.

J'appellerai "t" l'épaisseur du tracé, fixé à 3 dans le locodrome et à 2 chez moi.

J'appellerai "d" la valeur t/2/racine(2) qui sert dans les calculs. Elle vaut 1 dans le locodrome.
J'ai compris alors pourquoi Pierre (=Pierre59) avait utilisé 9 et 3 !! De toute beauté.

J'appellerai "z" le facteur de zoom. Dans le dessin, il est à 1 (on reste dans 1 carré).

On a au départ 6 points qui sont :

X1 de coordonnées (0 , -e/2+t/2) : 0 en x et pour y, on descend d'1/2 côté et on remonte d'1/2 épaisseur
X2 de coordonnées (e-d,  -d). Voilà l'usage du "d".
X3 de coordonnées (0,  -e/2) : on descend d'1/2 côté.
X4 de coordonnées (e,  0)
X5 de coordonnées (0, -e/2-t/2): on descend d'1/2 côté et on descend d'1/2 épaisseur.
X6 de coordonnées (e+d,  -d)

On notera que la difficulté vient du fait que les corde1, corde2 et corde3 (voir figure) ne sont PAS parallèles. Ils sont en éventail.

Au début, j'avais dessiné sur un cahier, à main levée, et j'ai cherché à trouver un centre commun à corde1 et corde3, en me disant que je me débrouillerai bien pour trouver un cercle qui soit à peu près centré après pour le suivi des trains.

J'ai donc raisonné en me disant que le centre du cercle qui passait par X1 et X2 était sur la médiatrice de corde1.
De même, le centre du cercle passant par X5 et X6 serait sur la médiatrice de corde3.
Et, évidemment, comme ces deux médiatrices se coupent, ce point d'intersection est le centre commun pour les deux cercles.
Et, ( oh surprise ! ) : ce point commun est aussi le centre du cercle qui passe par X3 et X4 !!
Je vous assure que ça n'a rien d'évident. Pas du tout.
Mais ça nous arrange vraiment parce qu'on n'approxime rien : le calcul est exact.

Autre trouvaille, qui n'avait rien d'évident non plus, c'est que les 3 angles au centre de chaque arc font exactement 45° !!
Si vous regardez bien le dessin, les trois triangles (gauche1, corde1, droite1), (gauche2, corde2, droite2) et (gauche3, corde3, droite3) sont semblables, décalés chacun les uns des autres, mais avec un point commun et des angles identiques. Et ça, j'achète !!

Par contre, les coordonnées du centre des cercles sont complexes.

On n'est plus simplement "dans un coin", comme avec des 1/4 de cercles.

Et il n'est pas question de déplacer artificiellement le centre C1 sur le point Coin1 parce que vous allez voir que quand on veut zoomer pour agrandir la courbe, le centre s'éloigne de plus en plus des coins ou de points simples.

En fait, pour les courbes de Bezier, on n'a pas besoin de calculer les coordonnées du centre. Il faut calculer les coordonnées des deux points "attracteurs" de chaque courbe approximant le 1/8è de cercle.
Et comme on est exactement à 45° d'angle au centre, on trouve sur internet le nombre "magique" correspondant, à savoir "m" = 0.265206.

Vous comprendrez maintenant pourquoi j'étais content de m'apercevoir que chaque angle faisait exactement 45°. Un calcul (infernal, d'ailleurs) en moins. Et une précision de 1/1 000 000 !!

Mais pour calculer les coordonnées de P1 (côté X1) et P2 (côté X2), on passera par les coordonnées du centre des cercles.


Les voilà :  C1(e*K1,  e/4+e*K)

Avec K1 = (5*racine(2)-7)/(8*racine(2)-12) = -0.103553
Avec K = racine(2)/2 = 0.707107
Vous pourrez faire le calcul avec e = 9 et confirmer les données de la figure pour C1.
Et moi, je peux faire le calcul pour e = 10.

Vous remarquez une chose étrange : les coordonnées du centre des cercles ne dépendent pas de l'épaisseur des bandes sur le TCO, uniquement du côté du carré !

En ayant C1 et X1, on calcule la pente de la droite qui passe par les deux points, ce qui donne la pente de la droite passant par X1 et P1. Et, avec le nombre magique, on a les coordonnées de P1.

Pente de la perpendiculaire a1 = -e*K1/(e/4+e*K+(e-t)/2)

Donne P1( e*m/racine(1+a1),  a1*[e*m/racine(1+a1)]-(e-t)/2)

Pour e = 9 et t = 3, P1(2.296489, -2.815714)
Pour P2, symétrique de P1 par rapport à la médiatrice, même genre de calcul, avec X2 et C1.
Je ne vais pas vous infliger le calcul pour les autres points.

Vous aurez remarqué que les formules ne sont pas évidentes, sans être vraiment atroces. Finalement, le raisonnement, lui, est assez simple et c'est pour ça que je voulais vous le présenter.

Mais ça n'est pas fini. Passons aux zooms.


Normalement, en bougeant la molette, on agrandit la courbe.
Mais le résultat ne va pas :

(http://www.locoduino.org/IMG/png/courbe_quatre_carres.png)

On a bien les 45°, les cercles concentriques, mais il y a un angle inacceptable entre la droite et le cercle. On ne peut pas zoomer de cette façon.

Je propose plutôt ça, mais je dois encore faire les calculs.

(http://www.locoduino.org/IMG/png/courbe_six_carres.png)






Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le février 04, 2017, 02:20:29 pm
Bonjour,

Voici la V4.0 de mon TCO en Processing. :D

De nombreuses améliorations pour la saisie des éléments :

- Utilisation de courbes de Bezier cubiques (au lieu de quadratiques), ce qui donne des courbes qui copient quasi parfaitement des arcs de cercles.
Cela permettra d'avoir des trains qui suivront exactement les rails...
- Création d'une voie courbable assez sophistiquée.  ;D

J'ai fait une petite vidéo pour ceux qui veulent voir ce que ça donne. Mettez en plein écran 8)
https://youtu.be/_RC34uAZ3PY (https://youtu.be/_RC34uAZ3PY)

Le programme lui-même est en PJ.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le février 04, 2017, 02:41:21 pm
Alors là bravo  ::)

Très jolie danse du ventre avec des rails flexibles 8)

Très beau travail et résultat excellent, et ça fonctionne aussi sur Mac avec Processing 3, Java 6 (avec quelques difficultés pour avoir les équivalents clavier - "les modifiers" Mac et PC, mais cela semble faisable)

Amicalement
Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le février 04, 2017, 03:54:57 pm
Merci Dominique,

Content que ça plaise...
Et que ça marche aussi sur Mac.
Tout se fait à la souris, clic gauche, clic droit. Mais pour remplacer la molette, il faut faire + ou -.
Et, de temps en temps, appuyer sur CTRL.

Je ferais évidemment un article, d'abord pour installer Processing (attention V3.2.4 boguée). Prendre la V3.2.3.

PS : sur ton exemple, tu as mis des droites de 1 cube de côté l'une à côté de l'autre. Tu aurais pu utiliser 1 seul cube droit et "tirer dessus" (molette). ;)
Il faut un article de mode d'emploi.

Et, pour les experts, un article sur les courbes de Bezier cubiques : ce que c'est, quelques graphiques et "un peu" de maths. :o
Pour info, j'ai quand même mis 70 heures pour les voies courbables... :P
Pas évident du tout, au départ (et des articles faux sur internet : ne pas croire tout ce qu'on lit)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le mars 02, 2017, 09:01:42 pm
Je continue mon TCO par une pièce de choix : la plaque tournante  ;D ;D ;D

C'est Pierre (=Pierre59) qui m'avait donné l'idée et qui planche d'ailleurs dessus. J'attends de voir !
Donc, je suis parti de courbes de Beziers cubiques pour approximer les cercles.
Voici le résultat en vidéo.

https://youtu.be/JoZSNi1xkGA (https://youtu.be/JoZSNi1xkGA)

Pour ceux qui se demandent comment je calcule les nombres "magiques" liés à ces courbes, le plus simple est de voir comment je fais les cercle représentant la fosse de la plaque.
Il me reste à traiter le pont lui-même et à faire rouler des trains dessus (de bonnes soirées en perspectives  :P)

Mais ça avance...

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le mars 20, 2017, 08:04:22 pm
On continue… ;)
La plaque tournante :

Comme il s'agit d'une pièce de choix, on ne pouvait pas la laisser dans cet état !
J'ai donc ajouté un pont tournant (ça peut servir  8)) dont la forme est celle de celui du Fleischmann 6152, à 48 voies maximum.

Mise en œuvre :

1°) On sélectionne la plaque tournante et on la place où on veut.

2°) On appuie sur CTRL, ce qui change le curseur en "+". C'est le mode "sélection".

3°) On sélectionne le cube en bas à droite de la plaque qui devient foncée (sélectionnée) par un minuscule "glissé" sur le cube.

4°) On choisit dans la fenêtre popup le nombre maxi de voies, ce qui a pour effet d'afficher un carré avec les étiquettes donnant les possibilités de voies.
On ne peut mettre des voies que sur les cubes ayant un label.
Si on met une voie de plaque tournante ailleurs que sur les étiquettes, elle disparait, purement et simplement.

5°) On sélectionne une voie de plaque tournante et on la place où on veut ("drag and drop", "glisser- déposer", comme aurait dit Molière s'il avait connu l'Arduino  ;D)

S'affiche alors une voie droite, complètement indépendante des cubes pour ce qui est du dessin et elle a déjà son butoir.
Repassage automatique au mode "normal" (curseur flèche et cases claires).

6°) Si on fait jouer la molette (ou +/- pour les malheureux n'ayant pas de molette  :-[ ), on peut allonger ou rétrécir la voie correspondante.
C'est la voie "simple", juste radiale.
On ne peut pas lui relier une autre voie (par exemple pour sortir de la plaque).
C'est pour ça qu'elle a déjà son butoir.

Mais il existe une voie "complexe" qui permet nettement plus de possibilités.

7°) Vous sélectionnez le cube voulu (CTRL+glissé gauche sur le cube de l'étiquette) et il devient plus foncé.

Le curseur repasse à "+" et vous indiquez alors où vous voulez que la voie arrive en sélectionnant le cube et clic DROIT.
La voie se dessine, mais le tracé reste anguleux.

Je conseille de garder pour l'instant le tracé anguleux, on l'améliorera plus tard.

A noter que, comme on reste dans le mode "sélection", on peut changer de case d'arrivée (toujours clic DROIT).
Si vous mettez l'arrivée en dehors du triangle qui lui est réservé et qui est centré sur la plaque, vous allez avoir des formes étranges, mais pas de plantage !
A noter aussi qu'il faut sortir du mode sélectionné et y rentrer à nouveau pour passer au cube suivant, sinon, il ne se passe rien. C'est voulu : un seul cube à la fois.

8°) Quand on a mis toutes ses voies et qu'on est revenu au mode "normal", on peut jouer de la molette (ou +/-) et "arrondir les angles", avec une grande précision, en choisissant le cube sur lequel on veut agir.

9°) Et maintenant, on peut agrandir la plaque elle-même (molette sur le cube de la plaque) jusqu'à la dimension voulue.

A noter qu'on peut se servir de cet agrandissement pour bien aligner les butoirs dans le cas des voies simples :

Dans un premier temps, on met les voies simples trop grandes.
Puis on affiche une (trop) grande plaque tournante, à une dimension telle qu'elle corresponde à l'endroit où on voudra les butoirs.
On rétrécit chaque voie en alignant bien les butoirs le long du cercle.
Et on rétrécit la plaque à sa dimension définitive.

Pour mémoire, la table tournante 32 voies de la version gold d'un célèbre logiciel.

(http://www.locoduino.org/IMG/png/plaque_tournante_rrtc_32_voies.png)

Et maintenant, une petite vidéo, pour voir que les explications précédentes sont finalement assez simples.

https://youtu.be/5-uAO9q0bwo (https://youtu.be/5-uAO9q0bwo)

Prochaine intervention (demain, si tout va bien, le temps de faire le post avec une petite vidéo) : le scoop !
(Non, ça n'est pas le changement de couleur des rails, encore que…)

A suivre  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le mars 21, 2017, 05:50:22 pm
La problématique :

Comme beaucoup de modélistes désirant faire un TCO, j'ai un problème de gare cachée.
En effet, la mienne sera juste en dessous de la gare visible, à la verticale de celle-ci.
C'est très loin d'être original.  ::)

La solution classique est de figurer chaque gare sur le TCO en décalé.
Par exemple en bas du TCO la gare visible et en haut du TCO la gare cachée.
Les deux sont bien séparées.

Soit on reproduit les deux gares indépendamment (cas le plus fréquent), soit on les relie "quand même" via un lien qui ne représente plus la réalité, mais un chemin "logique".

Cet état de fait a été enraciné avec les TCO composés de vrais cubes pour une raison simple : on ne peut, mécaniquement, pas superposer deux cubes ! :-[

La solution pour "superposer" des cubes consiste à créer des cubes spécifiques. Je vous donne un exemple de tels cubes, sur la gauche dans le schéma suivant (RailMaster Hornby).

(http://www.locoduino.org/IMG/png/hornby_railmaster.png)

Si on veut traverser un ensemble de voies, on utilise une succession de tels cubes.
Mais on ne peut pas envisager tous les cas et on est limités à des superpositions de droites.
Dans ces conditions, si on veut superposer des courbes, on doit, là encore, déformer la réalité.

Tout cela est très dommage… :'(

D'autant que ça augmente assez considérablement la taille du TCO qui doit être composé de cubes  tout petits. ???

Un matin …

Le 6 mars, au réveil, j'ai eu une idée qui résout tous ces problèmes.
La nuit porte conseil.  ;)

Il "suffit" de décaler les cubes de 1/2 cube, en x et en y ! ;D ;D ;D
On crée deux couches, décalées, avec des rails de couleurs différentes.

Dans mon logiciel TCO, on a deux variables border_x et border_y qui donnent les dimensions des bordures (à gauche en x et en haut en y).
C'est bien sûr le cas aussi dans le locodrome (les mêmes causes produisent les mêmes effets).
Les dimensions de l'affichage n'ont, en effet, aucune raison d'être un nombre entier du pas de la grille et il faut bien compenser.

L'idée (simpliste) consiste à ajouter 1/2 cube à border_x et border_y pour passer d'un "niveau" à l'autre. En fait, c'est "un peu" plus compliqué que ça. Mais c'est l'idée.

Un problème d'alignement surgit quand on veut abouter un circuit composé de deux niveaux…

Pour les droites, c'est simple : on fait un zoom qui avant d'1/2 à chaque fois, en démarrant à 1/2 cube. Comme le cube s'oriente dans tous les sens, ça résout déjà pas mal de cas. Mais pas tous.

J'ai donc poussé plus loin avec les arcs de courbe à 90° qui gèrent maintenant toutes les possibilités.
Amusez vous à zoomer sur un cube arc 90° nouvelle version : c'est vraiment nouveau.
En particulier, on n'atterrit plus à chaque fois au milieu de l'arête d'un cube, mais aussi dans les coins !
C'est absolument nécessaire.
On change simplement de niveau en appuyant sur ALT.

Voyons ce que cela donne sur un exemple.

https://youtu.be/kIBDImmrANE (https://youtu.be/kIBDImmrANE)

Cette méthode est tout à fait neuve et n'a pas d'équivalent dans le commerce. :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le mars 22, 2017, 11:38:38 am
C'est superbe !

Construire graphiquement son réseau avec un minimum d'éléments dans la palette et autant de possibilités : bravo Denis  ;D
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le mars 22, 2017, 01:02:04 pm
Merci Dominique  ;D

C'est sûr que si on juge des possibilités d'un programme à sa seule palette, on loupe pas mal de choses...
C'est un peu comme les icones sur un mobile : de nombreuses fonctions n'ont pas de bouton (ex zoom avec 2 doigts)

Il va quand même falloir un bon mode d'emploi  ;)
J'ai fait ce que j'ai pu pour simplifier les actions, mais tout n'est pas aussi "évident" que ça.

Pour votre culture, je vous mets le lien pour voir comment fonctionne la palette de RailMaster de Hornby :

https://www.youtube.com/watch?v=UTdOztswg4M&t=47s (https://www.youtube.com/watch?v=UTdOztswg4M&t=47s)

Regardez à peu près à 1mn du début pour voir leur façon de travailler.
La palette est fixe, on doit dès le début savoir comment la pièce est orientée pour choisir la bonne pièce, traitement en deux temps...
Et "un peu" carré comme dessin.

A propos des vidéos sur YouTube: je les trouvais moches et toutes floues, contrairement au film l'original.
J'ai compris pourquoi :
Il faut forcer l'affichage à HD 1080. Apparemment, en automatique, ça ne marche pas.

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le mars 22, 2017, 01:28:46 pm
Q : Comment vois-tu la suite du programme ?
R : Il reste quelques bugs à corriger, puis je m'attelle à la description du réseau.

1°) Chaque cube va avoir une étiquette qu'on devra mettre à la main.
-> Pour les branchements (terme officiel SNCF), normalement 1 seul cube (sauf cas particuliers)
-> Pour les cantons, on sélectionne tout les cubes d'un canton et leur donne une étiquette en une fois (heureusement !  ;))
Tout ça marche déjà, mais il faudra que j'y ajoute la plaque tournante.

2°) On a donc pour un canton un ensemble de cubes qu'il va falloir ordonner. Et là, ça se complique puisqu'il faut connaître les coordonnées x y exactes de chaque extrémité de "rail" dans un cube, quelle que soit son orientation et son zoom…
Cette partie là aussi est faite, mais il faut que je voie pour la plaque tournante, assez spécifique.

3°) Une fois les cubes ordonnés, on a donc une origine et une extrémité x y de canton et, donc, on peut "abouter" automatiquement les cantons et les cantons aux branchements.
Donc, vérifier que tout ça est toujours OK, surtout après le changement de niveaux !

4°) A ce stade, je sais quel est le canton/branchement (= l'élément) qui précède ou suit un canton/branchement.

Précède ou suit … physiquement.
Exemple : un branchement a physiquement une origine et deux extrémités physiques, dans tous les cas.

Le rôle du gestionnaire de réseau sera de donner un élément suivant ou précédent à un élément donné, mais cette fois de façon logique.

Exemple : suivant la position de l'aiguille, un branchement a, cette fois,  une seule origine et une seule extrémité logique.
Par extension, une fois l'itinéraire choisi, un canton d'entrée de gare a un seul canton d'extrémité logique : la voie d'arrivée de la gare.

5°) Prochaine étape : justement, définir les itinéraires.
Je n'utiliserai pas la méthode du locodrome qui suppose de les décrire tous à la main et de leur affecter un bouton. On a déjà 8 boutons pour deux aiguilles.
Le locodrome est un formidable outil pédagogique, mais cette partie n'est pas à étendre pour un grand réseau.

Ce sera une méthode nouvelle, compatible locodrome, qui utilisera ce qui était bien dans la méthode SGDD, dans celle de Jean-Luc et celle de Pierre. Voir à ce sujet : http://forum.locoduino.org/index.php?topic=167.60 (http://forum.locoduino.org/index.php?topic=167.60)

Mais il faut la développer parce que toutes ces méthodes n'étaient que des ébauches.

Évidemment, les principes resteront :

-> Ne jamais avoir à décrire les itinéraires
-> Automatisation de la description du réseau nécessaire pour que les programmes tournent
-> La façon de demander un itinéraire doit être la plus simple possible (un clic sur l'entrée, un clic sur la destination)
-> On doit pouvoir effacer un itinéraire (pas si évident que ça en a l'air suivant l'état d'avancement de l'itinéraire)
-> La circulation dans la gare doit être la plus fluide possible.

Q : Tout ça dans le programme "TCO" ?
R : Non, il y a des choses qui n'ont rien à y faire.

Le programme "TCO" sert à préparer des fichiers pour le programme "Commandes"
Aujourd'hui, 4 fichiers :

-> C_panel_(date).tsv qui décrit tous les cubes
-> Block_(date).tsv qui décrit tous les cantons
-> Turnout_(date).tsv qui décrit tous les branchements
Ces 3 fichiers sont à destination du programme commandes.pde (Processing)
-> Specifs.h à destination de l'Arduino gestionnaire du réseau.

Donc, par exemple, le programme TCO n'a pas à faire bouger les aiguilles, faire tourner la plaque tournante (je supprimerai) ou faire avancer les trains.

Parenthèse sur le mouvement des trains sur le TCO : "TCO" est actuellement entièrement en courbes Bezier cubiques, donc en "vrais" cercles.

Concernant les itinéraires, seule l'automatisation de la description du réseau sera dans "TCO".

Q : Tu dis que ton programme est basé sur le locodrome. Ils n'ont pas l'air de se ressembler : l'un fait à peu près 1 000 lignes et le tien plus de 5 000 lignes …?
R : En fait, c'est parce que les deux programmes n'ont rien en commun !!

Si on observe bien les choses, on pourrait dire que "TCO" est un pré-locodrome.
"Commandes", lui, ressemblera beaucoup plus au locodrome.

Mais, en allant dans le détail, l'onglet "Formes" est "le même" que mon onglet "Form" et l'onglet "Paves" est "le même" que l'onglet "Cube"+"Cube45". Et ce sont des parties fondamentales.

Après, les différences entre ces onglets portent sur des "détails" : je peux donner la taille que je veux aux cubes alors que les pavés font 9 de côté, je n'utilise plus quadraticVertex(), j'ai plus de modèles, etc…
Mais la logique est vraiment la même.

Après, plus rien à voir.
Par exemple, j'ai une palette pour dessiner le réseau alors qu'il est décrit "en dur" dans locodrome.
Les buts ne sont pas du tout identiques.
Mais comme la base est la même, la façon de raisonner est la même et on convergera.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 (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 (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 :

(http://www.locoduino.org/IMG/png/reseau_depart.png)

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é.

(http://www.locoduino.org/IMG/png/reseau_final.png)

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"…
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 ... :-[
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 (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
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Pierre59 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

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 :

(http://www.locoduino.org/IMG/png/reseau_type_vierge.png)

Puis le réseau numéroté :

(http://www.locoduino.org/IMG/png/reseau_type_numerote.png)

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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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

(http://www.locoduino.org/IMG/png/itineraires2.png)

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 (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 (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…
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 :
https://youtu.be/BHoyH7XonEY (https://youtu.be/BHoyH7XonEY)

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)

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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.

https://www.youtube.com/watch?v=xNL-_q-Ybp8 (https://www.youtube.com/watch?v=xNL-_q-Ybp8)

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.

https://www.youtube.com/watch?v=5oIPjexo_XU (https://www.youtube.com/watch?v=5oIPjexo_XU)

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 :

https://www.youtube.com/watch?v=ki3OFXSQxwo (https://www.youtube.com/watch?v=ki3OFXSQxwo)

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 :

(http://www.locoduino.org/local/cache-vignettes/L150xH66/deceleration_127-0-c2db1-4e559.png?1533401621)

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 (http://www.locoduino.org/IMG/zip/train_tco_v1_6_33.zip)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 (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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique 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.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 :

(http://www.locoduino.org/IMG/png/deceleration_127-0_reduite.png)

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 :

(http://www.locoduino.org/IMG/png/cas_du_ralentissement_sur_zone_d_arret.png)

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 :

(http://www.locoduino.org/IMG/png/cas_du_ralentissement_sur_zone_d_avertissement.png)

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 (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 (http://www.locoduino.org/IMG/zip/train_tco_v1_6_33.zip)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Pierre59 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: fmd14 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 :


(http://www.locoduino.org/IMG/png/cas_du_ralentissement_sur_zone_d_avertissement_avec_zones.png)

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 :

(http://www.locoduino.org/IMG/png/deceleration_127-0_reduite.png)

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
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le septembre 06, 2018, 04:30:38 pm
Mais pourquoi avoir fait un réseau aussi moche ?   ;D

(http://www.locoduino.org/IMG/png/circuit_d_essai_avec_zones.png)

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.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Thierry 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é...
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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...




Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Pierre59 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
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF 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 :

(http://www.locoduino.org/IMG/png/choix_position_des_signaux.png)

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.
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le septembre 14, 2018, 12:21:34 pm
Voici un nouveau topo sur les itinéraires.

Petit aparté sur la TJS :

Comme je l'avais promis, j'ai essayé une TJS.
Au début, j'ai simplement changé la TJD Z9 en TJS et ça a marché du premier coup.
Évidemment, quelques possibilités d'itinéraires en moins, mais c'est tout à fait normal.
Et puis, j'ai remis la TJD en Z9 et changé Z15 pour une TJS.
Et là, comment dire, je ne retrouvais plus mes petits… :( :(

En fait, le problème ne venait pas de la TJS (ça faisait pareil avec une TJD), mais du fait que cet emplacement se combinait avec une raquette…
Déjà peu de réseaux ont une raquette, mais, en plus, que cette raquette ait comme élément fondamental une TJS/TJD est quasi introuvable… sauf ma future gare.

(http://www.locoduino.org/IMG/jpg/gare_denis_numerotee.jpg)

Sur le schéma (merci Jean-Luc  ;)), ça n'est pas flagrant : on ne voit pas de raquette.
Mais, si vous y réfléchissez, vous verrez que, quelle que soit la voie par laquelle vous sortez par la gauche, vous aurez parcouru une boucle de retournement en revenant par la gauche !!
Et comme vous ne pouvez pas sortir par la droite (c'est une gare terminus), je vais avoir ce problème de raquettes basées sur des TJD à grande échelle.

J'ai donc fait quelques ajustements et, maintenant, ça marche ! Ouf !
Merci Pierre d'avoir fait cette importante remarque.  ;)

Revenons aux itinéraires.

Les différentes typologies :

A la SNCF, on parlera de transit "rigide" pour dire que, une fois l'itinéraire créé, on ne touche plus aux aiguilles tant que le dernier wagon n'a pas quitté complètement l'itinéraire.
La plupart des réseaux miniatures fonctionnent comme ça parce que ça a le mérite d'être simple et efficace, en particulier quand les itinéraires sont courts.

Puis est venu le transit "souple" en 1934, mais pas encore en poste "tout relais".
En 1939, le premier PRA (Poste tout Relais à destruction Automatique) qui, comme son nom l'indique est géré entièrement par des relais.
C'est du transit "rigide", mais la nouveauté, c'est qu'on crée un itinéraire en appuyant sur un bouton.
C'est une grande avancée.
Et, mieux, on libère les aiguilles d'un seul coup : c'est la "destruction automatique".
Puis, en 1950, le premier PRS (Poste tout Relais à transit Souple).

Transit souple :

C'est l'aboutissement de la technologie à relais.
La nouveauté, c'est qu'on libère non pas l'itinéraire entier quand il a été entièrement parcouru, mais zone par zone, au fur et à mesure que le dernier wagon quitte une zone. La zone pouvant être un appareil de voie (AV), ou une zone sans appareil de voie (SAV).
On peut donc réutiliser cette zone immédiatement pour un autre itinéraire. La fluidité est maximale.

Mais, on n'a rien sans rien et la complexité est maximale :
Il faut obligatoirement une détection de présence sur chaque zone et plus on veut améliorer la fluidité, plus les zones doivent être petites et, donc, plus nombreuses.
D'où le fait que les PRS en train miniature sont quasi inexistants.
Lecteur de Loco Revue depuis 1974 (!!), j'ai recensé :
Le PRS à relais de Pierre Chenevez (1970-73) et celui des Frères Jesu LR 503, 504, 506 et 507 en 1988.
Depuis, plus rien.

C'est pourtant ce que j'ai choisi de développer (sans relais, bien sûr) et vous avez vu sur les précédentes vidéos que ça marche. Mais c'est du lourd !
Et c'est justifié pour une gare comme la mienne, avec deux doubles diagonales.

Pour être tout à fait exhaustif, ce sera un PRG (Poste tout Relais Géographique).
La différence fondamentale entre un PRS et un PRG, c'est qu'en PRS, on a un bouton par itinéraire, ce qui peut faire parfois beaucoup.
En PRG, on appuie sur le bouton de départ puis sur le bouton d'arrivée.
L'idée du PRG date du 19è siècle, mais le premier PRG est de 1971.

Gestion d'itinéraires :

J'ai trois niveaux d'affichage des itinéraires, chacun caractérisé par une couleur distincte :

1°) couleur SABLE :
On a donné le point A et le point B et le programme a trouvé tous les itinéraires possibles entre ces deux points.
Le premier itinéraire trouvé s'affiche couleur SABLE.
Par des clics GAUCHE successifs, on balaie tous les itinéraires trouvés, y compris un itinéraire vierge (et donc GRIS) qui sert à abandonner la recherche.

2°) couleur BLANCHE :
Par un clic DROIT, on choisit l'itinéraire souhaité qui passe en couleur BLANCHE.

3°) couleur VERTE/ROUGE :
Si on affecte un train à un itinéraire de couleur BLANCHE, il passe en couleur VERTE et est affiché.
Toutes les zones où est le train sont ROUGES.

Dans chaque couleur, il faut mémoriser les pavés et les zones concernées et, entre autres, la position des lames des AV.

Dans l'état actuel, pour un seul train, les différentes phases s'enchainent correctement.
On affiche les itinéraires SABLE, puis les BLANCS et enfin les VERTS.
Au fur et à mesure, les pavés affichent la bonne couleur, les AV la bonne position et, comme on affiche les itinéraires chaînés dans l'ordre où le train les parcourra, tout va bien.

On peut le voir pour deux trains simultanés sur la vidéo suivante (avec la TJS). Petit détail : pour la navette, j'ai choisi de ne pas passer par le même endroit pour l'aller et le retour. Mais on pourrait choisir le même parcours dans les deux sens.

Nota pour les vidéos : elles sont en HD (1920 x 1080) et en grand écran.
En particulier, surveiller le sens des trains (la petite flèche sur la loco).
Quand le train n'est pas ralenti, il est à fond. C'est moche et irréaliste, mais on voit bien si le train ralentit ou pas. Il y aura une accélération douce dans la version finale.

https://www.youtube.com/watch?v=HNvQ2cy7apo (https://www.youtube.com/watch?v=HNvQ2cy7apo)

Mais vous remarquerez sans peine que j'ai bien fait attention qu'il n'y ait aucune zone commune pour les deux trains.
Parce qu'il me reste à faire s'imbriquer tous ces niveaux avec plusieurs trains…

Destruction manuelle d'itinéraire :


L'autre difficulté, c'est qu'à force de lancer plusieurs itinéraires chainés, on peut avoir envie de changer d'avis et de faire tout autre chose.
On peut aussi être amené, suite à un accident ou un wagon perdu, à contourner l'obstacle.
 Et il faut tout effacer pour reprogrammer autre chose, au pied levé.
Je comprends mieux, à postériori, pourquoi les aiguilleurs de la SNCF ont apprécié d'avoir des PRA, avec "destruction automatique"…

Et là, j'ai trouvé une méthode simple.

Tout d'abord, dès qu'un train est sur un itinéraire (il est donc VERT), cet itinéraire enregistre le numéro de ce train. Par exemple 3.
Et ce numéro de train ne démarre pas à 0, mais à 1. C'est très important.
Si on a des itinéraires chaînés, eux sont BLANCS et ont comme numéro de train -3.
Il y a donc un seul itinéraire (VERT) avec comme numéro de train 3 et un ou plusieurs itinéraires (BLANCS) avec -3.
C'est par ce simple système que je sais quel itinéraire est lié avec le suivant !

Et quand on veut changer d'avis, on sait immédiatement lesquels effacer.
Je n'utilise donc pas le 0 (évidemment) et quand on a dessiné un itinéraire BLANC, il a, par défaut, -1000 comme numéro de train.

Quand on a chaîné des itinéraires vides (BLANCS et -1000), ils sont chaînés par le début du suivant/fin du précédent.
Dès qu'on pose un train, on a un 3 et quelques -3 (par exemple) au lieu des -1000.

Cette partie est simple à effacer.
De même la partie VERTE de l'itinéraire où est le train.
Là où les choses se compliquent, c'est pour la partie occupée de l'itinéraire (ROUGE).

Parce que, au moment où on change d'avis, on peut très bien être à cheval sur plusieurs zones.

Mise en œuvre :

Au début, j'avais considéré comme une erreur le fait de choisir le même point (le même signal) pour A et B. Puis je me suis dit que ça déclencherait l'annulation.
Et ça pouvait même servir à changer le sens de déplacement d'un train sur place.

Si on choisit pour A et B le signal à l'avant du train, on efface tout. Et le train ne bouge pas. L'itinéraire est simplement raccourci.
On peut dès lors choisir pour lui un nouvel itinéraire qui va dans le même sens ou le sens opposé.

Voir les deux vidéos suivantes, qui montrent ces cas.

https://www.youtube.com/watch?v=0ocBvULrTJA (https://www.youtube.com/watch?v=0ocBvULrTJA)

https://www.youtube.com/watch?v=LhoYvBmgl9k (https://www.youtube.com/watch?v=LhoYvBmgl9k)

Si on choisit pour A et B le signal à l'arrière du train, on efface tout et on change le sens du train sur place. Ce qui, en fait correspond à inverser complètement l'itinéraire puisque c'est l'itinéraire qui donne le sens au train.
Puis on choisit pour lui un nouvel itinéraire qui va dans le même sens ou le sens opposé.

Voir les deux vidéos suivantes, qui montrent ces cas.

https://www.youtube.com/watch?v=Ok57_u2BRzQ (https://www.youtube.com/watch?v=Ok57_u2BRzQ)

https://www.youtube.com/watch?v=hXRAGjQEUCs (https://www.youtube.com/watch?v=hXRAGjQEUCs)

La nuance importante par rapport aux précédents cas, c'est qu'au lieu d'avoir une zone commune aux deux itinéraires (la dernière du précédent est la première du suivant), le train est à cheval sur trois zones (Z11, Z13 et Z14) et, suivant les cas, la loco est sur la première ou la dernière des 3 zones suivant le sens dans lequel on repart.
C'est "un peu plus complexe" que premier/dernier pour construire le nouvel itinéraire…

Récapitulatif des possibilités d'erreurs/annulations d'itinéraires gérées :

1°) Vous avez cliqué sur la mauvaise origine. Ce n'est pas la peine de continuer.
Vous recliquez sur le bouton recherche d'itinéraires du menu.

2°) Vous avez cliqué sur la bonne origine et sur la mauvaise extrémité.
Là, on est en itinéraires SABLE.
Vous cliquez GAUCHE pour faire défiler tous les itinéraires trouvés jusqu'à atteindre un itinéraire vierge (GRIS). Vous cliquez DROIT pour le valider, ce qui efface tout.

3°) Vous avez validé et vous êtes en itinéraires BLANCS. Mais vous avez choisi le mauvais.
Vous cliquez sur le bouton de recherche du menu.
Vous cliquez GAUCHE sur le point origine.
Comme deux itinéraires ne peuvent avoir la même origine, ça efface l'itinéraire.

4°) Vous avez positionné votre train et, même, il roule.  Votre itinéraire est VERT.
Et vous voulez tout recommencer.
Vous arrêtez le train et vous choisissez A et B sur le même signal (origine ou extrémité) de la zone en ROUGE.

Ce qui me plait particulièrement, c'est qu'il n'y a, pour tout ça qu'un seul et unique bouton (recherche d'itinéraires) et qu'on peut l'appliquer à n'importe quel signal du réseau. C'est quand même très souple.







Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le octobre 31, 2018, 04:31:05 pm
J'ai suspendu mon activité informatique jusqu'à fin septembre pour diverses autres occupations.
Depuis début octobre, je m'y suis replongé et … ça marche !!

Je fais maintenant fonctionner plusieurs trains ensemble en gérant des itinéraires avec des incompatibilités, les feux, etc…

Avant de continuer, je fais un petit aparté sur la question de Marc-Henri sur le fil de Jean-Luc (18/09/2018) concernant le fait de simuler le déplacement des trains sur le TCO.
Je souscris complètement aux réponses qui lui ont été faites par Pierre et Jean-Luc.

Le présent post vise à détailler les problèmes (nombreux) qui se posent.

Il n'est pas du tout évident de faire se déplacer des trains sur un TCO, au-delà des grands principes qui sont, eux, relativement simples. Le Diable se niche dans les détails.

Pour l'instant, je me limite aux Grandes Lignes et je ne traite pas les zones de manœuvre.
C'est en effet un autre monde, avec moins de zones, moins de signaux et une vitesse limitée.
Bien sûr, je traiterai le sujet. Mais plus tard.

Le modéliste :

Dire que le modéliste est à la fois conducteur et aiguilleur, c'est enfoncer une porte ouverte.
Poser un train sur le réseau, mettre le curseur à fond et bouger les aiguilles au gré de l'inspiration, on l'a tous fait. C'est naturel.

Mais je voudrais suivre un cheminement plus structuré en rentrant un peu plus dans chaque métier.

1°) Quand le conducteur prend "son" train en charge, il a son bulletin de freinage (ex bulletin de composition) qui détaille les caractéristiques du train.
Et, évidemment, il a son itinéraire (les gares traversées et la destination).

2°) L'aiguilleur, lui, a déjà préparé les itinéraires de sa zone.
Dans ce post, je ne traiterai que des itinéraires manuels, ceux qu'on construit en cas de dérangement (ex : un arbre tombé sur la voie et qu'il faut éviter).
C'est le bouton "choix d'itinéraire" du menu.

En effet, une fois qu'on sait traiter ces cas, on pourra alors gérer des itinéraires en automatisant certaines tâches.
Dans la réalité, quand l'aiguilleur saisit les origines et extrémités de l'itinéraire (A et B), le programme ne propose qu'un seul itinéraire (le meilleur parmi tous ceux possibles, tenant compte de certains paramètres).
Ce sera le bouton "meilleur itinéraire" du menu. On l'étudiera dans un autre post.

Les itinéraires manuels ont une autre utilité : la programmation d'un itinéraire précis, pas forcément le meilleur, mais celui qu'on veut. C'est particulièrement utile entre deux gares.

Exemple : je veux absolument passer par la voie de parade, même si, actuellement, elle est occupée.
Il y aurait bien un autre itinéraire, libre en plus, qui me permettrait aussi d'aller à destination, mais je veux passer par la voie de parade. Le recours aux itinéraires manuels est alors indispensable.

Les différents types d'itinéraires :

Jusque là, j'avais considéré et géré les itinéraires de la même façon (il faut bien se lancer…).
Mais il faut aller plus loin. Un itinéraire n'est pas seulement une liste de pavés orientés et de positions des lames des appareils de voie.

TCO et aiguilles :

Pour pouvoir gérer les trains de manière optimale, il faut en finir avec l'idée que le TCO reflète à tout moment la position réelle des aiguilles sur le réseau. Le mot important, là, c'est "à tout moment".

Il y aura donc, pour chaque pavé, deux variables :
"lame" qui reflète vraiment la position des aiguilles sur le terrain
"lame_tempo" qui affiche au TCO une position d'aiguille qui n'est pas celle du réseau ("tempo" est assez clair : ce sera temporaire).

TCO et occupation :

Plus subtilement, il y aura pour chaque pavé deux niveaux d'occupation :
"occupation" qui correspond à l'occupation réelle d'un véhicule sur le réseau.
"réserve" qui correspond au fait que le pavé, bien que physiquement non occupé, a déjà un numéro de train. Il est donc réservé par un train.
De cette façon, un pavé réservé ne pourra plus servir dans un autre itinéraire, tant qu'il restera réservé. C'est encore plus vrai s'il est vraiment occupé.

C'est particulièrement utile pour une traversée, une TJS ou une TJD.

Deux grands types d'itinéraires :

J'ai deux listes d'itinéraires (des ArrayList, c'est génial) :

La liste "tous_iti_tempo" qui correspondent aux itinéraires trouvés par le programme, suite à la recherche de tous les itinéraires entre A et B.
Ils sont affichés successivement, au dessus de tous les autres, de couleur SABLE.
Ils ne tiennent pas compte des occupations, des réservations et utilisent la position "lame_tempo".
Pendant l'affichage de ces itinéraires, les autres restent affichés (mais en dessous), les trains roulent normalement en suivant les vraies positions des lames d'aiguille.
Ces itinéraires sont indispensables aux aiguilleurs pour bien choisir celui qu'il veut sélectionner.
Avec le bouton "meilleur itinéraire", ils ne seront pas affichés puisqu'il n'y a qu'un itinéraire affiché. Et donc, pas de choix.

La liste "tous_iti" qui correspond aux autres itinéraires. Là encore, deux possibilités :

Les itinéraires réservés, affichés en BLANC.
Les itinéraires occupés, affichés en VERT (et en ROUGE pour les zones réellement occupées).

Itinéraires et points :

Les points servent "d'étapes" pour faire avancer les trains.
Un véhicule est dessiné à la verticale d'un point puis à la verticale d'un autre point un peu plus loin quand il avance.
Il est donc inutile de calculer les points pour les itinéraires SABLE et BLANC. On gagne ainsi un temps d'exécution précieux.
Et on peut même aller encore plus loin :
Quand un train arrive sur un itinéraire BLANC, il faut calculer les points pour qu'il puisse avancer. Mais si, parce que le train ne peut pas aller jusqu'au bout de l'itinéraire (ex : un autre itinéraire incompatible est déjà présent sur la fin de l'itinéraire ou coupe l'itinéraire), on ne calculera les points que jusqu'au pavé réservé ou occupé.

Il s'ensuit qu'un même itinéraire peut être VERT au début puis BLANC sur la fin.
Et, pour être tout  fait précis, forcément ROUGE au tout début puisque c'est là qu'est le train.

Autre façon de voir les choses : on n'a calculé les points que dans les parties VERT/ROUGE des itinéraires.

Remarque connexe : quand on affiche les itinéraires SABLE au dessus des autres, il faut mémoriser les couleurs de ces pavés pour pouvoir effacer ces itinéraires temporaires (quand on les fait défiler un par un) et retrouver la couleur précédente de chaque pavé.
Avec une difficulté supplémentaire puisque les trains bougent…

Effacement des pavés lors des mouvements de trains :

Parce que je suis en PRS, il faut effacer chaque zone au fur et à mesure du déplacement du train.
Là encore, on a le problème d'afficher la bonne couleur lors de l'effacement.
Voici des explications détaillées de la situation la plus simple avec deux trains, l'un bloquant l'autre, puis le débloquant.

(http://www.locoduino.org/IMG/png/01-reseau_initial.png)

Je choisis sur le réseau de cliquer gauche sur les points cerclés.
Le premier itinéraire utilisera les cercles jaunes et le deuxième les cercles bleus.
Pour le premier itinéraire, je clique d'abord dans le cercle jaune en haut à gauche, puis dans le cercle jaune au milieu.
A chaque fois qu'on clique, le feu correspondant devient NOIR, masquant temporairement le vrai signal.
Pour le deuxième itinéraire, je cliquerai gauche d'abord dans le cercle bleu du milieu, puis dans le cercle bleu en haut.

Je choisis l'itinéraire du premier train.
Les images sont petites, parce que l'important, c'est qu'on voie qu'entre les deux points choisis il y avait 4 itinéraires possibles.
Les itinéraires sont de couleur SABLE et, quand on change de choix (clic gauche) on retrouve bien la couleur GRIS précédente.
Première image : on vient de choisir A et B. Affichage du premier itinéraire trouvé.
Deuxième image : premier clic gauche. On efface le premier et on affiche le deuxième.
Troisième image : deuxième clic gauche. On efface le deuxième et on affiche le troisième.
Quatrième image : troisième clic gauche. On efface le troisième et on affiche le quatrième.
Quatrième clic gauche : plus aucun itinéraire affiché. On revient à la toute première image (en grand).

A noter : si, à ce moment, on clique DROIT :
Remise à zéro et affichage "aucun itinéraire sélectionné").

Cinquième clic gauche : retour à la première petite image.

(http://www.locoduino.org/IMG/png/02-quatre_itineraires.png)
 
Je choisi le premier itinéraire par un clic droit. Il devient BLANC.
Je pose le train numéro 3 dessus, il devient VERT. Et ROUGE au début à cause de la présence du train.

(http://www.locoduino.org/IMG/png/03-validation_premier_itineraire.png)

Vous retrouvez donc le premier itinéraire VERT.
Je vais créer un deuxième itinéraire pour un autre train qui va passer en grand partie au même endroit.
Le premier itinéraire est VERT et j'affiche au dessus un itinéraire temporaire SABLE.
On voit bien que j'ai sélectionné comme premier point celui vers le milieu et comme deuxième point celui vers le haut à gauche : les feux sont en NOIR.
Je rassure tout le monde : c'est uniquement un affichage.
De même, l'affichage de la position des lames a changé, mais c'est, là aussi, temporaire.
Si le train jaune avançait, il suivrait son itinéraire VERT, avec des lames dans la position de l'image précédente.

Mais on voit très bien le tracé du nouvel itinéraire. C'est le but.

(http://www.locoduino.org/IMG/png/04-proposition_nouvel_itineraire.png)

Je clique droit. Le deuxième itinéraire devient BLANC.
Mais là, je ne suis plus en affichage temporaire.
Le premier itinéraire (le VERT) reprend ses droits, sa couleur et ses positions de lames d'aiguilles.
Les feux ne sont plus en NOIR.
En fait, la partie en BLANC est assez limitée.

(http://www.locoduino.org/IMG/png/05-validation_nouvel_itineraire.png)

Je pose le deuxième train, le bleu.
On ne calcule les points que sur une partie de l'itinéraire. Ce n'est pas la peine d'aller plus loin puisque le train bleu ne pourra pas avancer.

(http://www.locoduino.org/IMG/png/06-pose_train1_sur_nouvel_itineraire.png)

Le train jaune avance, efface derrière lui.
Mais remarquez la subtilité :
Au début, il efface la couleur ROUGE et la remplace par la couleur GRIS_FONCE.
Mais quand il arrive sur la future zone de l'itinéraire du train bleu, il met la couleur en BLANC, couleur de la réservation des pavés d'un itinéraire. Et la position des lames suit aussi.

(http://www.locoduino.org/IMG/png/07-avancement_train_3_debut.png)

Puis, le train jaune avançant, dès qu'il arrive sur la dernière aiguille qui bloque le train bleu.
Immédiatement, le train bleu est débloqué, ce qui se remarque dans son CagSignal qui passe à RALENTISSEMENT_CLI (= R60). Il était à CARRE depuis le début.
En effet, j'ai déterminé au départ que les deux aiguilles en plein milieu seraient limitées à 60 km/h en position déviée.

(http://www.locoduino.org/IMG/png/08-deblocage_train_1.png)

Puis on arrive en position finale, chaque train arrêté devant son CARRE.

(http://www.locoduino.org/IMG/png/09-position_finale.png)

Poussons un peu plus loin.
Le train jaune a le même itinéraire que précédemment.
Le train bleu a aussi le même itinéraire
Puis on ajoute une suite pour le train jaune (A et B dans les cercles jaunes).

(http://www.locoduino.org/IMG/png/10-suite_itineraire.png)

Clic DROIT pour valider. On lance le train jaune jusqu'à ce qu'il libère le train bleu. L'itinéraire du train bleu s'affiche complètement en vert puisqu'il est libre jusqu'au bout (ni occupation, ni réservation).
Vous noterez que, à ce moment, le train jaune a l'AVERTISSEMENT puisque le signal d'après est CARRE.

(http://www.locoduino.org/IMG/png/11-liberation_train_bleu.png)

Le train bleu démarre et dépasse la TJS

(http://www.locoduino.org/IMG/png/12-debut_liberation_train_jaune.png)

Comme le train jaune a atteint la dernière zone de l'itinéraire 1, qui se trouve être la première zone de l'itinéraire 3, il y a transfert du train de l'itinéraire 1 vers l'itinéraire 3 et effacement complet de l'itinéraire 1 dans la liste "tous_iti".
Le train jaune est donc complètement sur son nouvel itinéraire.
Le train bleu n'a pas changé d'itinéraire, mais c'est maintenant le premier itinéraire de la liste.
Le train jaune est sur le deuxième itinéraire.
Quand le train bleu a avancé, il a dépassé la TJS et donc l'a libérée. Elle est maintenant réservée (en BLANC) et dans la bonne position. Le feu du train jaune est maintenant à SEMAPHORE Le train jaune reste bloqué à cause de l'occupation de la zone suivante par le train bleu.
Quand le train bleu aura complètement quitté la zone, le train jaune pourra avancer, mais sera immédiatement bloqué par un SEMAPHORE sur  la zone tant que le train bleu n'aura pas quitté les aiguilles. A noter qu'il peut avancer parce qu'on a, au passage, calculé les nouveaux points jusqu'au SEMAPHORE.

(http://www.locoduino.org/IMG/png/13-suite_liberation_train_jaune.png)

Le train bleu a passé les aiguilles et le train jaune est libéré. Cette fois, les points sont calculés jusqu'au bout. Et donc, en VERT.

(http://www.locoduino.org/IMG/png/14-go_train_jaune.png)
 
Maintenant que j'ai tout détaillé, j'arrête ce très long post.
Avec une dernière vidéo (c'est encore plus beau en mouvement) de 3 trains, le troisième faisant navette au milieu des autres…

https://youtu.be/KYUNXD2jAEU (https://youtu.be/KYUNXD2jAEU)


Titre: Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le décembre 06, 2018, 09:41:46 pm
Ça démarre insidieusement par la création d'une variable booléenne pour mémoriser une situation et régler un cas particulier.
Puis une deuxième variable pour régler un autre cas.
Puis on passe à une variable entière pour un troisième cas…
Au bout d'un moment, ça devient suspect  ??? et on se rend compte qu'on vient de lever un lièvre : il faut revoir en profondeur l'analyse du problème.
Les cas singuliers sont en fait des cas particuliers d'une vision plus générale.
J'ai donc revu ma copie et posé les bases d'une nouvelle façon de voir les choses.

La variable "numero_train" :

Le grand changement, c'est d'avoir exploité au maximum la variable "numero_train" dans les pavés.
J'avais déjà entrevu la solution, mais je n'avais pas traité à fond toutes les possibilités de cette variable.
Ce qui a profondément transformé mon programme qui a maintenant moins de variables, moins de lignes, plus de clarté et de lisibilité. 8)

Voilà mon réseau d'essais, avec des numérotations liées à cet article.
Je rappelle qu'on n'a jamais besoin de ces numéros de zone ni dans l'exploitation du réseau, ni dans le programme lui même (voir précédents posts)

(http://www.locoduino.org/IMG/png/numerotations.png)

En premier, le pupitre avec les numéros de train, qui commencent à 1, pas à 0. C'est important.
En bleu, le train n°2 et on voit son orientation sur le pupitre, orientation qui suivra la vraie orientation du train (merci à Pierre (=Pierre59) pour cette idée).
En jaune, le train n°3.
Voilà comment les numero_train sont présents dans les pavés :

(http://www.locoduino.org/IMG/png/tableau.png)

N est le numéro de train.
Si numero_train est négatif, c'est qu'on n'a pas de train sur l'itinéraire
Si numero_train est positif, c'est qu'on a bien un train sur l'itinéraire
Pas de train = -1000, ce qui laisse 999 numéros de trains ! ;D

Ce numero_train existe aussi pour les itinéraires.
Il peut y avoir plusieurs itinéraires qui ont le même numero_train, en négatif : tous les itinéraires suivants, recopiés, (voir plus loin)
Mais il n'y a qu'un seul itinéraire ayant un numero_train positif : celui sur lequel est vraiment le train à un moment donné.

Comme je ne voulais pas détailler tous les pavés, on raisonnera sur les zones dans ce post.
En réalité, ça se passe au niveau des pavés.

Cas particulier de la couleur SABLE des itinéraires (itinéraires temporaires) :

La couleur SABLE ne correspond pas à un numero_train.
Elle est gérée par une variable booléenne "iti_tempo".

Pendant qu'on affiche la couleur SABLE (qui est dessinée au dessus de tous les tracés, avec iti_tempo à true) les autres couleurs continuent leur vie "en dessous", les trains continuent à rouler, etc.
Dès qu'on a choisi un itinéraire, on met iti_tempo à false et on retourne aux couleurs normales qui ne sont désormais plus masquées.
Les couleurs affichées avant qu'on dessine des itinéraires temporaires ont pu évoluer entre temps.
La couleur SABLE ne masque pas les trains.

Évolution des couleurs :

Quand on ouvre le réseau, tous les numero_trains sont à 0 et donc tout est affiché en GRIS.
Ce qui explique pourquoi on démarre les numero_train à 1.

Sur l'exemple précédent, j'ai défini un premier itinéraire.
(Un clic sur le point de départ, un clic sur le point d'arrivée)
iti1 : Z1, Z4, Z5, Z6, Z9, Z10, Z11 pour le train 3.
Puis, toujours pour le train 3, iti2 : Z11, Z6, Z5, Z4, Z2, Z1
Si on regarde bien, ça fait un "8" couché.

Puis, pour le train 2, iti3 : Z3, Z4, Z5, Z6, Z7, Z8.
Là, on a affaire à un point à point.

Pour le train 3, avec, entre parenthèses, le numero_train du pavé :
Z1(3) est en ROUGE à cause de l'occupation.
Z4(3), Z5(3), Z6(3), Z7(3), Z9(3), Z10(3) et Z11(3) sont en VERT. Comme c'est le premier itinéraire demandé, il est complètement VERT car rien ne l'empêchait.

Quand je fais le deuxième itinéraire du train 3, Z11(3) est déjà VERT et le reste.
Z6(3) est déjà VERT, mais on ne peut plus changer la position du branchement, réservée par iti1.
Z5(3) et Z4(3) sans changement, avec les positions du premier itinéraire.
Z2  ne fait pas partie du premier itinéraire et on a donc Z2(-3).
Le signe – signifie qu'il n'y a pas de train dessus. C'est l'itinéraire "suivant" de iti1.
Z1(3) à cause du premier itinéraire.

Pour le train 2 qui vient après les deux autres itinéraires, on a :
Z3(2), Z4(3), Z5(3), Z6(3), Z7(3), Z8(-2)
Le train 2, bloqué par un carré en sortie de Z3 (voir son cab-signal) n'est pas gêné que les numero_train soient d'un numéro différent du sien sur les zones suivantes puisqu'il ne peut pas y aller…

Vous voyez ainsi que, pour un même itinéraire, on peut avoir des pavés ayant des numero_train différents.

En effet, à un instant donné, un pavé ne peut avoir qu'un seul numero_train. ;)
C'est la phrase clé.

Quand on a réservé le pavé P pour le train 3, il reste réservé pour le train 3.
Dans tous les itinéraires utilisant le pavé P, il restera affecté au train 3.

Calcul des points :

Un véhicule (loco ou wagon) ne peut avancer que s'il est sur une zone où on a des points. Il avance par sauts minuscules. Par exemple, l'itinéraire 1 ci-dessus compte … 10 304 points !
Dès le début, on se dit qu'il va falloir calculer les points le moins souvent possible sous peine de saturation processeur.

Autre remarque :
Il ne faut pas, à chaque fois, calculer tous les points d'un itinéraire, mais seulement ceux qui servent.

Exemple :
Pour le premier itinéraire du train 2, je n'ai calculé que les points de Z3. Ce n'est pas la peine d'aller plus loin car il est bloqué par un CARRE.
En fait, je ne m'occupe pas du CARRE, je regarde simplement les numero_train de cet itinéraire :
Z3(2), Z4(3), etc.
Dès l'instant où la Z4 est affectée au train 3, je sais que le train 2 ne pourra pas y aller. Et j'arrête de calculer les points.

Quand a-t-on vraiment besoin de calculer les points ?

Dans seulement 3 cas :

1°) Quand on pose un train :
L'itinéraire était BLANC et devient VERT, puis ROUGE pour les zones occupées.

2°) Quand on relance un train arrêté :

Exemple : le train 2 est actuellement arrêté devant son CARRE.
Quand il pourra rouler, par passage de CARRE à RAPPEL_RALENTISSEMENT_60, il aura fallu, auparavant calculer les points de la suite de l'itinéraire

3°) Lors d'un transfert d'itinéraire :
Ex : quand il sera entièrement sur la Z11, le train 3 sera en train de ralentir devant un CARRE de fin d'itinéraire. Dès que l'itinéraire suivant sera possible, le train passera de dernière zone de l'itinéraire 1 à première zone de l'itinéraire 2. Et, là, il faudra calculer les points de l'itinéraire 2.

Donc le calcule se fait très rarement, en "one shot" (comme disent les Brexitois) à chaque fois.

Depuis le début de l'itinéraire jusqu'à ce qu'on trouve une zone qui n'a pas le bon numero_train.
Pour le train 3, on calcule les points tant que la zone a le numero_train = 3, -3, 0 ou -1000.
3, c'est évident, -3 car on peut le transformer en 3, 0 pour une première affectation d'une zone entièrement vide et -1000 uniquement quand on pose le train la première fois.

Et quand le calcul des points arrive sur un pavé ayant le mauvais numero_train, il s'arrête et décrète que le train est "en attente".
"iti_en_attente = true" pour cet itinéraire.

Quand les numero_train des pavés évoluent-ils ?

Là, par contre, très souvent.
Le moment clé est la sortie d'un train d'une zone. On est en PRS, je le rappelle.

S'il n'y a qu'un seul train sur le réseau, au fur et à mesure que le train avance, on met le numero_train à 0 chaque fois qu'on sort d'une zone.

Mais j'ai voulu améliorer l'aspect visuel quand il y a plusieurs trains. Et aussi améliorer la compréhension de façon "parlante".

Dans l'exemple, seul le train 3 peut avancer.
Il va libérer Z1 qui va passer à 0 (GRIS).
Puis il va libérer Z4 qui va passer à -2 (BLANC). Pourquoi ?
Quand on libère Z1, personne n'en a plus besoin et on la libère complètement en passant à 0.
Par contre, quand on libère la Z4, le train 2, lui, va en avoir besoin et on la lui réserve en la mettant à numero_train = -2.
Puis, en avançant, le train 3 va libérer Z5 qui devrait, par le même raisonnement, passer à -2 et donc apparaitre en BLANC.
Oui, mais, maintenant, le canton formé par Z4 et Z5 est maintenant entièrement libre.

Temps mort : un canton, c'est une ou plusieurs zones avec un feu à chaque bout (en banalisé).
Ne pas confondre zone et canton. Ce n'est pas la même chose.


Donc, le train 2, ayant un canton libre devant lui, va pouvoir avancer.
Calcul des points jusqu'à Z5 inclus, les -2 deviennent des 2, et passage à VERT pour les zones.

Le train 3, sur Z6, empêche le train 2 d'aller plus loin.

Libération de Z6 qui passe à -2 (BLANC), de Z7 qui passe à -2 (BLANC) et Z8 est déjà à -2 (BLANC)

Donc libération totale du train 2, toutes les zones Z6, Z7 et Z8 passent à 2 (VERT) et le train 2 peut aller jusqu'au bout.

A noter aussi que cette libération du train 2 va maintenant bloquer le train 3. C'est lui qui, maintenant, va avoir iti_en_attente à true ! ;)

Quand le train 3 est entièrement sur Z1, abandon du premier itinéraire, transfert du train 3 au début de l'itinéraire 3 qui commence à Z11.

Le train 2 libère Z3 qui passe à 0 (GRIS), puis Z4 qui passe à –3 (BLANC), puis Z5 qui passe à -3 (BLANC), puis Z6 qui passe à -3 (BLANC).
Le train 3 est libéré, calcul des points et on a :
Z11(3), Z6(-3->3), Z5(-3->3), Z4(-3->3), Z2(-3->3), Z1(0->3). Tout est VERT et il peut avancer.

Si vous avez bien saisi cette mécanique, vous remarquerez que les points ne sont calculés que pour les zones VERT et ROUGE.
Pour être plus exact, c'est parce qu'on a des points que les zones sont VERT ou ROUGE.

Signal CARRE :

Je reviens sur le signal le plus complexe : le CARRE.
Complexe parce qu'il peut être modifié manuellement.
Gérer automatiquement une chose manuelle est impossible dans tous les cas.
Par contre, si on y arrive dans trois situations, cela couvre une très grande majorité des cas possibles.

1°) le signal est devant un branchement pris en talon et dans la mauvaise position.
On a le CARRE puisqu'on a pris comme règle que le branchement n'est pas talonnable.
(Je ne désespère pas de gérer les branchements talonnables, mais c'est une autre histoire)

2°) le dernier pavé d'un itinéraire se termine forcément par un CARRE s'il n'a pas d'itinéraire suivant.
Lancer un train, c'est lui trouver un itinéraire suivant.

3°) le pavé suivant dans l'itinéraire n'a pas le même sens.

Ce cas survient si on a deux trains face à face et il faut bien en arrêter un.
A tester car j'ai encore quelques bugs.

Itinéraires répétitifs:

Un itinéraire répétitif, c'est un itinéraire qui se détruit, comme les autres, mais qui se reconstruira plus tard.

A partir du moment où on sait transférer un train d'un itinéraire sur un autre, c'est une suite assez logique.
Il "suffit" de recopier l'itinéraire qu'on est en train de parcourir en bout de liste.
Pour qu'on identifie dès le départ que tel itinéraire sera répétitif, j'ai dû créer un autre bouton au menu.

Dans l'exemple, j'ai crée, avec le bouton de recherche d'itinéraire, un premier itinéraire pour le train 3 qui va de Z1 à Z11, puis un deuxième itinéraire qui va de Z11 à Z1.
On a iti1 = Z1->Z11 et iti2 = Z11->Z1. Et iti2 suivant de iti1.
Le train 3 parcoure iti1, arrive en Z11, effectue un transfert de iti1->iti2 et parcoure iti2 jusqu'à Z1 et il s'arrête.

Si je crée iti1 à partir du bouton "itinéraire répétitif" et iti2 à partir du même bouton, que va-t-il se passer ?
Le train 3 parcoure iti1.
En fait, dès qu'il a démarré, il a recopié iti1' = iti1. Et dit que suivant(iti2) = iti1'.
Il y a maintenant dans "tous_iti" : iti1, iti2, iti1'.
Le train 3 arrive en Z11, sait que suivant(iti1) = iti2, et il y a transfert du train 3 sur iti2.
A cet instant, iti1 a disparu et il reste iti2, iti1'.
Dès que le train 3 a basculé, on ajoute iti2' = iti2 et on dit que suivant(iti1') = iti2'.
Il y a maintenant dans "tous_iti" : iti2, iti1', iti2'
Quand le train 3 arrive en Z1, on efface iti2, on transfère le train sur iti1'.
Il reste iti1' et iti2'.
Dès que le train 3 a basculé, on ajoute iti1" = iti1' et on dit que suivant(iti2') = iti1".
Quand le train 3 arrive en Z11, on efface iti1', on transfère le train sur iti2'.
Etc.

Donc on peut abouter autant d'itinéraires que l'on veut et ils se recopient à l'infini.

Paradoxe :

Après plus de deux ans de recherches et de développement, je suis en mesure de poser un train sur un ovale, mettre le curseur à fond et le regarder tourner !!!
Tout ça pour ça…. :o

Navette :

Comme le transfert peut aussi avoir lieu avec le changement loco en tire -> loco en pousse et réciproquement, on peut faire une navette infinie aussi, sans difficulté particulière.

Exemple sur la vidéo suivante ou j'exploite avec un train les 4 terminaisons possibles.

https://youtu.be/-hWQCjWum1o (https://youtu.be/-hWQCjWum1o)

Et pour arrêter ?

Eh oui, l'infini c'est long (surtout sur la fin) et il faudrait pouvoir arrêter quand on veut.
C'était déjà fait avant (voir mon post du 14 septembre).
On arrête manuellement le train là où on veut.
Un double clic sur l'un des signaux de la zone occupée et tous les itinéraires qui ont le même numero_train, mais en négatif, sont supprimés et le seul itinéraire qui a le numero_train en positif est réduit à la seule zone occupée.

C'est là qu'on voit la puissance des numero_train. Simple et diablement efficace.

Deux itinéraires répétitifs sécants :

Pour bien monter que ce sont les itinéraires répétitifs, je vous montre la vidéo des itinéraires du début, mais en répétition pour chaque train ! Et tout s'enchaîne sans heurts !

https://youtu.be/5wtNJxUYsn0 (https://youtu.be/5wtNJxUYsn0)

Et l'éditeur, dans tout ça ?

Ayant atteint une étape cruciale dans le gestionnaire, je vais faire une pause et m'attaquer à l'éditeur.
Il existe déjà, mais mal programmé.
J'ai fait de gros progrès dans la gestion du temps machine, par contrainte de calculs à faire en temps réel pour le gestionnaire.
Je vais appliquer ces innovations à l'éditeur qui va devenir beaucoup plus rapide. C'est fondamental.

En plus, je vais très vraisemblablement intégrer certaines modifications apportées par Pierre pour le dessin des formes qui composent le réseau dans son article du 14 octobre http://www.locoduino.org/spip.php?article231 (http://www.locoduino.org/spip.php?article231)

Le gestionnaire est fini ?

Que nenni !

Il manque :

1°) La gestion des zones de manœuvre, avec de vraies spécificités

2°) La gestion du nombre de wagons. Là,
    le train 1 a 1 loco et 3 wagons
    le train 2 a 1 loco et 4 wagons
    le train 3 a 1 loco et 8 wagons
    le train 4 est une loco HLP (Haut Le Pied = seule)
On ne peut rien y changer, sauf à "mettre les mains dans le cambouis".
Il faut pouvoir modifier le nombre de wagons très facilement, en détacher un ou plusieurs, etc.

3°) Pouvoir choisir que le pupitre soit en regroupé (comme maintenant) ou tout à droite du réseau (ce doit être facile)

4°) Améliorer l'accélération.
Pour l'instant, la partie pour l'accélération c'est :

void acceleration() {
    vitesse = consigne;
}

Difficile de faire moins…

Alors que l'arrêt, par exemple fait 53 lignes et fait un beau ralenti type décharge de condensateur (voir mon post du 9 août).

Et, surtout, ce n'est pour l'instant qu'un jeu, sophistiqué, certes, mais sans lien avec le monde réel.
Je compte beaucoup sur mes collègues Orléanais pour m'expliquer ce qu'ils ont fait et qui est exactement ce qui me manque.
Complémentaires, je disais. ;D

Piste pour un décor sur mesure :

Comme on peut mettre n'importe quelle image comme fond de décor, je me suis amusé à ajouter deux rectangles. C'est moche, mais ça marche. Mais on peut dessiner ce qu'on veut.

Il suffit d'avoir Paint.net qui gère les calques. C'est gratuit.
1°) Vous faites une copie d'écran de votre réseau
2°) Vous redimensionnez l'image à 1366 x 768 (la définition donnée dans le setup)
3°) Vous ouvrez un nouveau calque
4°) Vous dessinez ce que vous voulez (bâtiments, photos, chemins, …). C'est facile parce que vous avez le réseau en transparence. Vous pouvez être très précis.
5°) Vous ne sauvez QUE le calque (sans le réseau) et vous appelez votre image "Fond ecran.png" rangée dans "data/Icones"

Aucune incidence sur le temps de traitement car elle n'est dessinée qu'une seule fois.

(http://www.locoduino.org/IMG/png/essai_fond_ecran.png)

Nota : on ne peut pas prendre une photo de son vrai réseau et la mettre en fond pour une raison toute simple : les rails ne sont pas les mêmes (les branchements, traversées ont un angle de 45°, en particulier). On a fait le maximum pour que ça ressemble, mais c'est un schéma…

Pour ceux que ça intéresse : le lien vers le TCO V7_0 : http://www.locoduino.org/IMG/zip/train_tco_v1_7_0.zip (http://www.locoduino.org/IMG/zip/train_tco_v1_7_0.zip)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Pierre59 le décembre 07, 2018, 12:17:34 pm
Bonjour

j'ai, comme d'habitude, quelques remarques à faire.

Concernant les "numero_train" codant des informations en tranches en collaboration avec la couleur, ce me semble une régression dans l'utilisation de la programmation objet. Si on a besoin d'infos sur les trains dans les pavés on ajoute au pavé une référence sur un objet train !

Concernant les carrés (et les carrés violets) c'est certes les seuls signaux sur lesquels il y a action "manuelle" qui est tout à fait normale, deux actions "manuelles" sont possibles ouverture du carré ou fermeture du carré. Ces actions se font souvent indirectement par la création ou la destruction d'itinéraires. La réalisation effective des ces actions  (faites ou pas faisables)  est du ressort des enclenchements qui sont justement là pour empêcher des actions non conformes. Par exemple dans un poste d'aiguillage électromécanique unifié, il y a un levier par signal, la manoeuvre de ce levier (donc du signal) est contrainte par des enclenchements, des enclenchements mécaniques vis à vis des autres leviers (d'aiguille, de signaux, d'autorisations, …) et par des enclenchements électriques (occupations des zones, enclenchements d'approche, …), Dans les postes plus modernes (PRS) les principes d'enclenchement sont les mêmes mais sont tous réalisés électriquement. Ces principes permettent de gérer les carrés dans tous les cas !

Concernant les itinéraires à tracé permanent, ton histoire de "phénix" n'est pas très convaincante. Voici la définition d'un itinéraire permanent, un itinéraire permanent n'est pas détruit après le passage d'un train ce qui implique que les carrés ne soient pas fermés à l'aubination, mais mis au sémaphore.

Amicalement

Pierre
 
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le décembre 07, 2018, 04:04:47 pm
Merci Pierre,

J'aime bien tes remarques car elles font toujours réfléchir.
Mais sur la première, je ne la comprends pas

Citer
Concernant les "numero_train" codant des informations en tranches en collaboration avec la couleur, ce me semble une régression dans l'utilisation de la programmation objet. Si on a besoin d'infos sur les trains dans les pavés on ajoute au pavé une référence sur un objet train !

J'ai trois objets :
L'objet "Train" qui a une variable numero_train qui est fixée une fois pour toutes quand je choisis le train que je vais poser.
L'objet "Pave" qui a une variable numero_train, très souvent mise à jour.
L'objet "Itineraire" qui, entre autres, est une ArrayList de Pave. Et donc, ordonnée.

Si je parcoure les pavés de l'itinéraire (dans une boucle "for", par exemple), je parcoure aussi les numéro_train des pavés (via pave.numero_train).
Dans la liste des pavés de l'itinéraire, certains sont occupés par un train, d'autre non.
En fonction des numero_train des pavés composant l'itinéraire que je parcoure (dans la boucle "for"), j'ai des actions (avancée, arrêt, ralenti, ...) sur le train qui est sur l'itinéraire. Et je mets à jour la variable numero_train dans le pavé en cours de traitement à ce moment.

En fait je ne mets à jour des infos sur le numero_train des pavés que sur des pavés qui ne contiennent pas de train. Sinon, on pourrait avoir des surprises...

Pour moi, la variable "numero_train" du pavé n'est pas liée (au sens objet) à la variable numero_train du train.
Mais je me trompe peut-être ? Et il y aurait une autre façon de raisonner ?

Concernant les enclenchements, je les gère par les numero_train des pavés.

Dans ma façon de raisonner, un itinéraire peut ne pas avoir de train (avant qu'on l'y pose), mais un train ne peut pas ne pas être sur un itinéraire.

Même quand il a atteint son but (par exemple sur une voie de gare), il est sur un itinéraire.
Cet itinéraire est composé des pavés composant la zone de la voie de gare, tous occupés dans ce cas.
Au sens SNCF, ce n'est pas un itinéraire, c'est une occupation de zone, ni plus, ni moins.

Au passage, comme il est sur la dernière zone d'un itinéraire qui n'a pas de suivant (dans ce cas d'école) il a le CARRE.
Si on lui définit un nouvel itinéraire à partir de cette zone, ce sera considéré comme le "suivant" de l'itinéraire sur lequel il est.
Donc transfert, feu à VOIE_LIBRE et départ du train.

Cet itinéraire suivant est donc composé de pavés.
Supposons qu'on parle du train 2 et que le numero_train de l'un des pavés de l'itinéraire suivant soit 3.
Le train 2 ne pourra franchir cet "obstacle". C'est, pour moi, un exemple de condition d'enclenchement (parmi d'autres).

Je suis bien conscient que ma façon de voir les choses peut surprendre... 8)

Concernant la dernière remarque sur le Tracé Permanent, je vais changer ma dénomination. Je vais parler "d'itinéraires répétitifs". Tu as raison : ce que je fais n'est pas un TP.

Amicalement

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le mars 22, 2019, 09:03:45 pm
Bonsoir,

(http://www.locoduino.org/IMG/png/vue_gestionnaire.png)

Voici une vue de la nouvelle version du gestionnaire :
1°) Avec une image en arrière plan (on peut mettre ce qu'on veut)
2°) Il y a maintenant une loco
3°) Les voitures sont plus longues et suivent les bogies
4°) Quand on appuie sur F0, ça allume les feux

Mais tout cela sur des trains ... virtuels

Il reste encore du boulot ! ;)

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 01, 2020, 09:04:42 pm
Bonsoir Denis,

J'arrive sur votre fil après m'être investi sur la question des TCO sous processing grâce aux articles de Pierre59. Il était "fatal" que j'en vienne à votre "système" que je commence à  regarder de près. J'ai seulement, pour l'instant, jeté un œil sur votre code et je peux dire que je suis sincèrement "espanté" comme on dit dans mon coin. En particulier, le menu façon mac est trop "big"!! Mais pas que ça ; les fonctionnalités sont bluffantes.

Dans ce fil, peut-être aussi dans un autre ?, j'ai vu que vous en digital et moi en analogique avions les mêmes "toc" ; aussi je réponds ici à quelques unes de vos remarques :

- l'affichage de la vitesse réelle, rapportée à l'échelle, qui est pour moi également un plus significatif. Aujourd'hui ma solution est simpliste : si je touche à la consigne vitesse, j'affiche une vitesse en % de la consigne maximum, donnée propre à chaque loco, suivant une table en EEPROM.
Mais dès lors que deux détecteurs se suivant ont tous les deux été abordés avec la même consigne vitesse, le calcul du temps entre les deux détections m'affiche la vitesse kmh et je peux dire qu'elle est parfaitement reproductible. Attention : je ne dis pas qu'elle est constante, en effet d'une section à l'autre les forces de freinage sont différentes et conduisent à des vitesses moyennes (sur la section considérée) différentes, mais sur une section donnée elles sont bel et bien reproductibles. Ce qui me donne l'idée d'exploiter ceci pour... oui par exemple une sonorisation. Ou autre, il y a certainement d'autres applications.

- le nombre de zones par canton
j'ai suivi le même chemin.
Étant parti sur des barrières IR, je n'avais qu'une section par canton. Très frustrant pour la gestion des arrêts.
La découverte des CJMCU3216 dont j'ai fait la publicité en son temps m'a ouvert des horizons et j'ai ainsi pu multiplier les capteurs pour arriver à un capteur frontière plus de part de d'autre un (donc deux...) capteur d'arrêt.
Avec l'intuition que 2 pourraient aussi bien faire le boulot de 3. Prise de tête mais à l'arrivée j'ai effectivement pu supprimer la détection frontière :
- mes 2 capteurs restants sont à 10cm de part et d'autre de la frontière de section. (échelle N)
- si la section n+1 est occupée, l'approche du capteur se fait en marche lente et (si n+1 ne s'est pas libérée) arrêt au détecteur, sur quelques "loop" de freinage, ce qui donne un arrêt au signal si tout est bien paramétré.
- si n+1 est libre : la détection fin(n) réserve, polarise et alimente immédiatement n+1. Avec à la clé des transitions désormais totalement "lisses".
- la fin de détection par le capteur d'entrée de la section n+1 libère la section n. (mais pour ça il faut des capteurs parfaitement sensibles et fiables, qui ne retombent pas avant que le dernier wagon ne soit passé et là... pour moi... il n'y a qu'une solution... mes 3216 !!)

Il y a bien sûr quelques "complications" à traiter pour les trains, et/ou locos en solo, qui décideraient d'inverser leur sens de circulation entre deux, mais ça se fait bien sûr.

Seul inconvénient du principe : les trains réservent un peu plus de temps que nécessaire les sections. Ce qui n'est vraiment significatif que pour les sections courtes.

Et de plus, bien que ça ne soit pas lié mais c'est une contrainte que je m'imposais comme vous, un train peut être plus long que la section la plus courte (voire que n'importe laquelle) et ça marche toujours !

Je me prépare à apprivoiser votre programme TCO, dont je voudrais aussi saisir la "mécanique" interne et ça ne sera pas évident ! aussi je viendrai probablement vous solliciter. Je n'en suis pas à imaginer utiliser un gestionnaire (il faudrait d'ailleurs que j'ai auparavant un réseau doté de plus de deux aiguilles !) mais c'est probablement la suite logique...

Cordialement, et au plaisir d'échanger
Philippe
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 02, 2020, 12:26:09 pm
Bonjour Philippe,

Merci pour ces compliments (ça fait toujours plaisir  ;D), mais ils sont un peu exagérés.

Si tu veux du bon code, clair, concis et efficace, vois, comme tu l'as fait, les articles et posts de Pierre (Pierre59).

Mon code est brouillon, un peu bancal parfois, et je dirais que j'ai progressé dans Decoduino, lui aussi perfectible.
Mais c'est plus facile : un seul véhicule, un seul décodeur, ...

Certes, j'obtiens des résultats à force de persévérance et quelques bonnes idées.
Par ailleurs, je me tiens à une charte graphique qui fait que mes affichages sont cohérents (c'est important).
Et je tiens à ce que mes affichages aient un air "réel", avec des détails qui font "vrai".
C'est plus agréable de jouer avec un "vrai" poste de conduite.

Par contre, je sais exactement où je veux aller, je connais bien les techniques SNCF. Donc, tant que ça ne fait pas vraiment ce que je veux, je continue.
C'est parfois fort long...

Je réponds à tes questions :
1°) Ton raisonnement (% de la vitesse réelle) correspond exactement à ce que fait un décodeur DCC. Mais en analogique.

2°) Personnellement, je n'utilise pas les détections ponctuelles. C'est toujours "énorme" et pas vraiment sécurisant. La détection par conso de courant est (un peu) plus proche de celle de la SNCF et ça protège une zone, pas un point.
Je dis "un peu" car, maintenant, ce sont des fréquences envoyées dans la voie sur les lignes modernes.
D'un autre côté, à l'époque que je reproduis (les années 60), c'était bien une consommation de courant et, même un court-circuit qui était utilisé.

3°) Là où ça se complique, c'est que tu raisonnes toujours comme en pleine voie (d'où ton terme de "canton").
Dans un grill de gare, il n'y a pas un"canton n+1". Il peut y en avoir plusieurs possibles.

4°) La "mécanique" de mon gestionnaire est assez sophistiquée.
Et, en particulier, je ne demande pas que le train le plus long soit plus court que la zone la plus courte. C'est une originalité de mon système.
En fait, je me moque complètement de la longueur des zones et du nombre de zones couvertes par le train.
Au passage, tu as changé ton texte en le déplaçant car c'est ce que tu disais  ;)
Je raisonne sur la globalité du tracé à parcourir. Et comme j'y fais circuler des trains, je connais la longueur d'un train.

On pourra en reparler.

Bien amicalement
Denis  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 02, 2020, 03:43:19 pm
Bonjour Denis,

Ce qui me manquera toujours, c'est la culture SNCF, que j'ai notée chez bon nombre des piliers de Locoduino. Je suis tombé dans le train réduit par le hasard de la découverte d'Arduino puis de la rencontre manigancée par Google avec un fort vecteur contaminant du nom de Locoduino. Mais ça ne fera probablement jamais de moi un modéliste et mon intérêt premier reste le plaisir de voir tourner... mon code.

Ceci influe dont beaucoup sur mes choix, ou non choix. Le meilleur exemple : la détection par conso de courant. J'avoue n'avoir pas expérimenté et ne connaître que par ce que j'en ai lu sur le forum. Pas sûr du tout que ça m'ait permis de m'en faire une idée précise. En tous cas, et à tort ou à raison, j'en ai retenu que c'était une solution relativement chère et avec l'inconvénient de ne renseigner qu'en cas de présence d'un consommateur... par définition en fait. Or, un convoi ne se résumant pas à la loco l'idée de devoir graphiter des essieux me rebute "grave". Il y a probablement une part d'idées fausses dans ce résumé à charge.
Cependant il y en a aussi dans celle que les détections ponctuelles
Citer
C'est toujours "énorme" et pas vraiment sécurisant
. Mais si ces deux critiques peuvent être écartées, et je témoigne que oui (à ce jour), c'est il me semble la solution la plus flexible. Mais entre deux solutions également opérationnelles, il n'y a pas vraiment d'enjeu autour de ce choix, sauf peut-être pour un débutant qui se trouverait placé devant.

Citer
Là où ça se complique
dis-tu...
bien sûr ne traiter que des pleines voies simplifierait bien les choses et un grill (la culture SNCF finira quand même par infuser !) les complique... sauf à se le voir comme un stimulant et une occasion de "ciseler" du code. Et là aussi j'imagine que tout le monde a sa solution. Pourvu que ça marche. (j'imagine aussi qu'à bien y regarder toutes les solutions se ressembleront forcément)
"Là où ça se simplifie" beaucoup, c'est si on est en digital. Mais ça ce serait un autre débat et bien plus déterminant.

Pour ce qui est de la longueur des trains, je crois qu'on ne s'est finalement pas compris car je n'ai pas modifié ce que je disais et de fait on se comprend : j'ai moi aussi voulu qu'il n'y ait aucune contrainte sur la longueur des trains.
Pourtant je ne comprends pas ceci :
Citer
je raisonne sur la globalité du tracé à parcourir. Et comme j'y fais circuler des trains, je connais la longueur d'un train.
Peux tu préciser ? Parles-tu de la longueur réelle, "physique" du train ?? Alors comment la connaître et surtout pourquoi ?

Heureux de cette discussion
Bien amicalement
Philippe

 
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 02, 2020, 05:27:58 pm
Bonjour Philippe,

Citer
la détection par conso de courant. J'avoue n'avoir pas expérimenté et ne connaître que par ce que j'en ai lu sur le forum. Pas sûr du tout que ça m'ait permis de m'en faire une idée précise. En tous cas, et à tort ou à raison, j'en ai retenu que c'était une solution relativement chère et avec l'inconvénient de ne renseigner qu'en cas de présence d'un consommateur... par définition en fait. Or, un convoi ne se résumant pas à la loco l'idée de devoir graphiter des essieux me rebute "grave". Il y a probablement une part d'idées fausses dans ce résumé à charge.

La détection par consommation de courant est très bon marché. Il faut évidemment que les essieux soient "conducteurs" (10 ou 20 kOhm).
Comme je suis, comme toi, en N. Il s'ensuit que les essieux sont très petits.
La méthode traditionnelle dit "graphiter les essieux". J'avoue être tenté, mais le "bindotb" n'existe plus.
Je pense que je vais tester le produit pour la pelouse Magigras  :o

https://eshop.microrama.eu/fr/paysages/295-magiplast-flexelec.html (https://eshop.microrama.eu/fr/paysages/295-magiplast-flexelec.html)

Franchement, baser la sécurité d'un réseau uniquement sur les détections ponctuelles est une erreur.
Dès qu'on perd un wagon, qu'une saleté se met sur le détecteur, etc.. on a des problèmes.
La détection par consommation de courant n'est pas exempte de défauts non plus (rails sales), mais c'est globalement la méthode la plus efficace.

Concernant ta dernière question, je pense qu'il va falloir que tu lises tout ce fil (en particulier 07/12/2018).
Ma méthode suppose qu'on voie des trains virtuels se déplacer sur le TCO. C'est très particulier.

Normalement, tu dessines un réseau avec Edit_TCO, puis tu l'exploites avec Trains_TCO.

Trois précisions :

1°) Avec l'expérience de Decoduino, je vais adapter ces deux programmes.

2°) Edit_TCO nécessite une refonte complète pour les réseaux complexes comme le mien.
La principale critique que j'y ferai, c'est que les aiguilles ont forcément un angle de 45°, ce qui limite vraiment.
Puis, faire des éléments complètement sur mesure.

3°) Sur Trains_TCO, il faut arriver à y faire fonctionner des vrais trains.
Les trains virtuels, ça permet de progresser, mais, à un moment, il faut aller jusqu'au bout.
Je vais commencer par commander un train avec Decoduino.

Mais si ton tracé n'est pas trop spécifique, essaie de le dessiner, puis d'y exploiter des trains virtuels. Et dis-moi ce que tu en penses.

Bien amicalement
Denis  :P

Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le novembre 02, 2020, 06:11:12 pm
La détection par consommation de courant est très bon marché. Il faut évidemment que les essieux soient "conducteurs"
Franchement, baser la sécurité d'un réseau uniquement sur les détections ponctuelles est une erreur.
Dès qu'on perd un wagon, qu'une saleté se met sur le détecteur, etc.. on a des problèmes.
La détection par consommation de courant n'est pas exempte de défauts non plus (rails sales), mais c'est globalement la méthode la plus efficace.

On peut contourner pas mal de problèmes en combinant plusieurs techniques de capteurs : Consommation, RFID et ponctuelles type barrières optiques, effet Hall ou détection lumineuse différentielle (type SMA23 de Geoff Bunza qui me semble la moins intrusive dans le réseau et les matériels roulants).

Après, on ramène tout via un bus Can vers un algorithme de traitement (des redondances) : c'est interessant !
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Pierre59 le novembre 03, 2020, 11:06:33 am
2°) Edit_TCO nécessite une refonte complète pour les réseaux complexes comme le mien.
La principale critique que j'y ferai, c'est que les aiguilles ont forcément un angle de 45°, ce qui limite vraiment.
Puis, faire des éléments complètement sur mesure.

Je suis tout à fait d'accord avec toi. Aussi pendant le premier confinement j'ai fait des tests pour sortir du carcan imposé par les pavés. J'ai alors développé un système de placement des éléments de voie complètement différent, au lieu de mettre les éléments dans des cases, je les mets bout à bout. Il n'y a plus alors aucune contrainte sur les éléments : angles des aiguilles quelconques, aiguilles courbes, grands arcs de cercle de n'importe quel angle, …

J'ai notamment développé un jeu complet d'appareils de voie avec un angle de 26.56505117707799° (vous avez certainement reconnu l'arc tangente de 1/2, lol), c'est l'angle de la diagonale d'un rectangle de côtés 1 et 2 (mais d'autres angles sont possibles), ceci en trois tailles : petite, moyenne et grande.

Ce choix d'angle est fait pour rester globalement sur la grille habituelle, pour contrôler les angles , le parallélisme, …

L'exemple ci-dessous utilise des appareils de voie d'angle 27° et de taille moyenne, on peut voir qu'ils ne sont plus du tout dans les cases de la grille.

Si cela intéresse quelqu'un je pourrait détailler, voire faire un article.

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 03, 2020, 11:30:44 am
Bonjour Denis,

Je te remercie pour tes réponses à des questions qui n'apportent finalement rien à ton projet. Sinon de faire vivre ce fil, qui le mérite grandement !

J'ai en effet pu facilement et en peu de temps traduire mon projet de réseau sur ton éditeur de TCO y compris mon embryon de gare cachée !!, et je confirme que, sans du tout exagérer le compliment, c'est vraiment très fort !
Voici quelques constatations et suggestions, qui ne retirent rien au fait que dans l'état c'est GEANT ! :
- j'ai eu quelques plantages, il semble qu'il y ait un conflit entre un pavé que tu remplis trop en bas, ce qui fait en même temps monter le menu. Je n'ai pas eu assez de cas pour être sûr que ça soit la bonne analyse
- j'ai patiné avant de trouver comment utiliser les segments flexibles ; il faudrait ajouter dans le doc d'aide qui la sélection du point d'arrivée se fait par un clic DROIT.
- petit détail juste pour la beauté du dessin, je trouve qu'il faudrait deux TJD symétriques dans la palette pour que le dessin de la voie directe en gris corresponde toujours à la voie... directe.

Voici le résultat, avec le dessin sous CDM-rail à côté. (vu que ça sera mon premier et dernier vrai réseau et que je redoute l'erreur grossière de débutant, un avis me serait précieux !)
(https://i.servimg.com/u/f44/11/73/62/86/tco_pr14.jpg)

Puis-je continuer sur cette base, c'est à dire m'atteler à l'exploitation sous TRAIN_TCO ? ou vaut-il mieux le dessiner différemment ?

Conformément à ton conseil, j'ai lu tout le fil. Ce que j'avais déjà d'ailleurs déjà fait mais la seconde lecture m'éclaire un peu plus... mais pas complètement.
En particulier sur ce qu'il faut attendre du gestionnaire.
Je pense que tout le monde passe par la même progression  :
- un réseau, cad un "graphe" comme je l'ai lu et je retiens, à faire fonctionner
- la question de l'indispensable TCO à traiter et la solution processing, merci à Pierre et à toi qui fournissez des applis clé en main, s'impose pour moi vu le matériel +câblage qu'elle évite.
Disons que j'en suis là.
 
Ensuite commence ce que je ne comprends plus bien.
- un TCO qui commande les aiguilles et rétro-signale leur position et peut-être aussi les signaux, c'est le minimum. Les commandes de vitesse, pour moi non, je préfère des manettes physiques, des joysticks en l'occurrence.
- un + important est la visualisation de l'occupation des zones et cantons car on peut ainsi surveiller que tout ce passe bien du côté des libérations, ce qui me semble le principal et réel voire seul intérêt. Pas (encore) besoin d'un gestionnaire pour ça.
- ensuite viendra la question des itinéraires : c'est bien ça la véritable vocation du gestionnaire ? Je pense que oui.
- mais alors, qu'en attend-on ? Il y a une bonne partie des réponses dans le fil mais je ne suis pas encore prêt à tout comprendre. Je m'interroge tout de même, outre l'intérêt de s'amuser et casser la tête à le programmer (plaisir que je comprends et partage), sur celui de faire circuler des trains virtuels sur le TCO. Pour une simulation oui, bien sûr, mais en couplage avec un réseau sur lequel les trains tournent devant toi (à priori!) ? D'autant que CDM_rail, qui est un simulateur, gère les itinéraires et, d'après ce qu'il me semble, peut aussi prendre en charge le contrôle d'un réseau physique ?

Voilà donc pour moi des questions "existentielles" pour savoir, maintenant que j'ai mis les doigts dans le machin, jusqu'où je vais devoir y passer et s'il y a un "bon choix" de départ à ne pas rater.
Tiens à propos...
dans la perspective d'un projet stade papier à ce jour, l'option "détecteurs_de_conso versus détections_ponctuelles" est ouverte. J'ai regardé d'un peu plus près la première et réalisé que ça ne marche que dans un sens ??? En digital pas de souci (sauf pour les retournements ?) mais en analogique c'est cuit ?

C'est finalement fou le nombre de questions qui se révèlent au fur et à mesure... jusqu'à même tomber sur les ponts de Koenigsberg !

A suivre ?
Philippe

Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 03, 2020, 12:02:28 pm
Bonjour Pierre,

Oui, j'avais reconnu arctg(1/2), mais je ne connaissais que 5 décimales...
(A parté complet : en terminale, j'avais apppris 1500 décimales de PI que je récitais en 20 minutes. J'en connais encore 100 par cœur  :o)

Ton TCO mérite un article. Et en attendant qu'il soit fait et validé, n'hésite pas à m'envoyer ce que tu as.  ;D

Bravo !
Bien amicalement
Denis :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 03, 2020, 12:32:18 pm
Bonjour Philippe,

C'est une bonne journée : deux réponses le même jour !  ;D

Bien heureux que tu aies pu réaliser ton plan de réseau avec Edit_TCO. Très bonne idée d'avoir fait la comparaison avec CDM Rail.
Il est clair que tu as dû déformer un peu, moins qu'avec les TCO taillés à coup de serpe et anguleux qu'on voit régulièrement, mais quand même.

Citer
j'ai eu quelques plantages, il semble qu'il y ait un conflit entre un pavé que tu remplis trop en bas, ce qui fait en même temps monter le menu. Je n'ai pas eu assez de cas pour être sûr que ça soit la bonne analyse
C'est, malheureusement, une bonne analyse : On a beaucoup de mal à dessiner tout en bas du TCO à cause du menu.
Et on ne peut même pas dézoomer un peu car ce sont des nombres entiers. C'est aussi une chose que je veux modifier : un zoom décimal où on peut zoomer/dézoomer "un peu".

Citer
j'ai patiné avant de trouver comment utiliser les segments flexibles ; il faudrait ajouter dans le doc d'aide qui la sélection du point d'arrivée se fait par un clic DROIT.
Tout à fait vrai.

Citer
petit détail juste pour la beauté du dessin, je trouve qu'il faudrait deux TJD symétriques dans la palette pour que le dessin de la voie directe en gris corresponde toujours à la voie... directe.
Pas compris : je dessine bien une voie directe. Pour moi, une TJD à 4 possibilités et une seule de dessinée.

Concernant ton plan : Enfin un plan avec des voies de retournement...
Bon, deux, face à face, c'est peut être un peu beaucoup ?

Citer
Puis-je continuer sur cette base, c'est à dire m'atteler à l'exploitation sous TRAIN_TCO ? ou vaut-il mieux le dessiner différemment ?
Oui, bien sûr, tu peux continuer.

Il te reste à répondre aux questions de l'éditeur quand tu vas nommer les zones.
Cela va te faire les retraits entre zones et implanter automatiquement les signaux !

Et là, tu as fini. :D
Maintenant que ton réseau est dessiné et sauvé, tu n'as plus rien à faire pour y faire circuler des trains (virtuels).

Tu recopies juste ton plan qui est le .tsv de la data d'Edit_TCO dans la data de Trains_TCO et HOP, c'est parti ! ;D ;D
Plus simple, je ne peux pas. Il n'y a rien à programmer !

Tu peux même m'envoyer ton fichier .tsv et, moi aussi, je pourrais jouer avec.

Joue avec les trains virtuels et les questions existentielles disparaitront.

Concernant les détections à consommation de courant : non, ça marche dans les deux sens, même en analogique (heureusement).
On en reparlera.

Bien amicalement
Denis  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 03, 2020, 03:51:53 pm
... !! reconnaitre quoi ?? Arc tangente de 1/2 à la 5éme décimale ?!!
Moi je me souviens de 1.414, 1.732 et 3.14159. Un peu plus avec "que j'aime à faire connaître un nombre..." mais pas beaucoup. Quant-au 122 vers de "la mer toujours recommencée" je dis pas le mal (non, pas de mer) et que c'est moi qui doit toujours recommencer.
Vous êtes des "bêtes" ! Des matheux quoi.

Bon Denis... pour ce qui est de la TJD ce que je voulais dire c'est qu'idéalement et vu que contrairement au croisement son dessin n'a qu'une symétrie, il faudrait pouvoir avoir huit représentations.
Par exemple ici il y a une qui n'est aujourd'hui pas possible sur Edit_TCO.
(https://i44.servimg.com/u/f44/11/73/62/86/tjd10.jpg)

Mais je suppose que le cas est traité par TRAIN_TCO ? Je ne vais pas tarder à voir ça. Je nomme et je mets le fichier ici.
Merci pour ta réponse

ah... les retournements. Oui, deux ! parce que JE VEUX FAIRE DES HUIT (et sans arrêts) ! Là ! Mais sauf erreur, le découpage en zones que j'envisage devrait en faire juste un cas parmi d'autres.
(https://i44.servimg.com/u/f44/11/73/62/86/retour11.jpg)

Philippe
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 03, 2020, 04:31:02 pm
Tu donnes 5 positions. OK

Tu noteras que l'ombre des 4 premières est différente, mais que l'ombre de la 5ème est la même que la première.
On n'a donc que 4 positions possibles pour un croisement ou une TJD.

Par contre, dans Trains_TCO, tu verras que, pour chaque "ombre", la voie donnée peut avoir 4 positions.
Dans le pavé de la palette, j'ai pris l'une des 4 positions possibles pour la voie donnée.

Bon courage pour bien découper ton réseau vis à vis des voies de retournement pour éviter les courts circuits  ;D

Pour Trains_TCO, c'est géré.

Denis :P
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le novembre 03, 2020, 06:16:07 pm
Bonjour Philippe,

Ensuite commence ce que je ne comprends plus bien.
- un TCO qui commande les aiguilles et rétro-signale leur position et peut-être aussi les signaux, c'est le minimum. Les commandes de vitesse, pour moi non, je préfère des manettes physiques, des joysticks en l'occurrence.
- un + important est la visualisation de l'occupation des zones et cantons car on peut ainsi surveiller que tout ce passe bien du côté des libérations, ce qui me semble le principal et réel voire seul intérêt. Pas (encore) besoin d'un gestionnaire pour ça.
- ensuite viendra la question des itinéraires : c'est bien ça la véritable vocation du gestionnaire ? Je pense que oui.
- mais alors, qu'en attend-on ? Il y a une bonne partie des réponses dans le fil mais je ne suis pas encore prêt à tout comprendre. Je m'interroge tout de même, outre l'intérêt de s'amuser et casser la tête à le programmer (plaisir que je comprends et partage), sur celui de faire circuler des trains virtuels sur le TCO. Pour une simulation oui, bien sûr, mais en couplage avec un réseau sur lequel les trains tournent devant toi (à priori!) ? D'autant que CDM_rail, qui est un simulateur, gère les itinéraires et, d'après ce qu'il me semble, peut aussi prendre en charge le contrôle d'un réseau physique ?

Je te rejoins et j'ai décidé de matérialiser un TCO (un Arduino Mega) pour visualiser les occupations et positionner les aiguilles à la main , puis un module de commande des aiguilles (un Mega caché sous la plaque à coté de l'écran 5 pouces) puis une centrale (DCCpp bien-sur, encore un Mega) capable de piloter 12 trains avec des potars linéaires (j'adore), tu les vois à droite sur la photo (le bloc noir) :

(https://www.locoduino.org/IMG/jpg/img_4291.jpg)

puis un module de programmation des locos (à gauche, pas aussi sophistiqué que ce que fait Denis, mais ça me suffit) et enfin un gestionnaire basé sur le gestionnaire en C++ de Pierre qui occupe un Due avec un écran 5 pouces tactile.
Il y a en plus des détecteurs de consommation, des détecteurs RFID pour déterminer les trains à coup sur et des détecteurs ponctuels pour les zones d'arrêt. Un jour il y aura des barrières infrarouges pour compter les wagons et vérifier que les trains n'en perdent pas (ça se passera dans les tunnels).
Tout ce petit monde est relié par un bus Can (c'est d'ailleurs le truc qui pose le moins de problème dans l'ensemble du réseau !)
Je n'ai pas choisi Processing et je reste dans l'environnement Arduino qui me comble assez pour le moment  8)
L'écran 5 pouces fait donc partie du gestionnaire et permet de suivre son propre fonctionnent par les affichages et aussi de piloter les aiguilles (faire des itinéraires), de piloter les trains (suivre les trains, varier les vitesses, assurer la sécurité, les arrêts, les pannes, etc..)
Voici un exemple avec 4 trains stockés en gare cachée (sous le village) et un itinéraire pour un premier train qui démarre pour aller dans la gare visible devant le village (en faisant le grand tour) :

(https://www.locoduino.org/IMG/jpg/img_4303.jpg)

Puis un 2eme train avec un autre itinéraire (plus court, mais dans l'autre sens) pendant que le premier se déplace (il démarre) :

(https://www.locoduino.org/IMG/jpg/img_4304.jpg)

A noter : j'ai supprimé le segment noir qui est remplacé par rien sur les positions d'aiguilles non réalisées : on voit mieux le chemin à parcourir sur un petit écran.

Les boutons permettent à mon petit fils (4 ans) de faire marcher tout ça sans moi (enfin je reste pas loin).
Et je n'ai pas fini et je passerai à 7 pouces prochainement .
Mais le virtuel, ça m'a passé  ;D
De plus je garde le contrôle manuel à tout moment ! Tout n'est pas automatique.

J'arriverai, un jour, à finir de tout décrire sur mon sujet :
https://forum.locoduino.org/index.php?topic=290.msg11141#msg11141 (https://forum.locoduino.org/index.php?topic=290.msg11141#msg11141)

Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 04, 2020, 07:31:04 pm
Bonsoir Denis,

c'est gagné ! j'ai réussi à faire rouler un train virtuel. Le nommage s'est bien passé, c'est aussi souple et astucieux que le dessin des voies.
Le rendu dans TRAIN_TCO est très joli, très propre.
Mais je n'ai trouvé à télécharger qu'une version de 2018, 1.7.0; elle est très instable, lente à réagir, le bloc de commandes est minuscule et ne se grossit que peu et difficilement, et le choix des itinéraires et très limité puisque les aiguilles ne sont pas manœuvrables. Mais c'est plein de promesses.
Je mets le .tsv est en PJ.

Autre chose : j'ai vu ton architecture matérielle avec le PCduino à 70euros ; je te signale (peut-être ?) une nouveauté Rasberry pour 70euros également, plus puissant je crois et avec l'avantage d'avoir un clavier... on ne peut même pas dire intégré puisque tout est dans le clavier !
https://youtu.be/ZSvHJ97d8n8


et bonsoir Dominique,

c'est impressionnant ! Et ça illustre très bien la globalité de ce qui est nécessaire à la conduite d'un réseau. J'ai eu des yeux ronds en voyant ce que tu sortais sur l'écran 5", j'ignorais qu'on pouvait faire ça (maintenant j'ai vu la librairie dans ton fil). J'aurais vu ça avant je n'aurais peut-être jamais ouvert un fil qui parle de "processing" car j'étais parti sur l'idée d'un réseau "tout Arduino". Mais ayant pu constater ce que permet processing, j'envisage j'avoue de laisser Denis me simplifier la vie ! De plus je dispose d'une tablette tactile windows de 11" ! Même si ça n'est pas encore l'écran mural de 26". Reste que je veux moi aussi avoir un mode tout manuel, donc à voir.

Bien amicalement
Philippe
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 04, 2020, 08:08:15 pm
Bonsoir Philippe,

J'ai eu cette nuit un plantage de mon NAS (Synology 212J). Il ne s'allume plus.
J'en ai commandé un en urgence. Demain (disent-ils...) ou après demain ?
Je n'ai pas perdu mes données (2 disques en RAID1), mais la boi-boite est HS, brutalement, sans prévenir.

Dès que je peux, je t'envoie la dernière version, nettement améliorée, Trains_TCO_V1_9_1.
En attendant, l'avant dernière :

https://www.locoduino.org/IMG/zip/train_tco_v1_9_0.zip (https://www.locoduino.org/IMG/zip/train_tco_v1_9_0.zip)

Tu n'as rien à faire, sauf de mettre ton fichier dans de data de la V1_9_0.

Bien amicalement
Denis :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 06, 2020, 09:32:17 am
Bonjour Philippe,

J'ai un nouveau NAS (livré en 1 jour) , transféré les disques dans le nouveau NAS et, 10 minutes après, c'était bon !!
Les NAS, c'est génial. ;D ;D

Donc, j'ai testé ton réseau avec la 9_1 : fonctionnement impeccable.
Les itinéraires, même les plus complexes, fonctionnent.
Pense à déplacer ton pupitre  sur la droite.
Il y a quand même une erreur de dessin en haut à gauche (je pense que tu as voulu faire une TJD).

Pour Dominique :
Je teste actuellement un pupitre de commande de trains avec Decoduino.
Avec une limitation de taille : 1 seul train (L298 oblige) sur un rond qui fait office et de voie de programmation et de "réseau", moyennant un inverseur double (DPDT).
Je vais faire marcher ça avec l'Arduino UNO.
Je vais utiliser tout ce qui s'est déjà dit sur Locoduino à ce sujet (pas besoin de réinventer l'eau tiède), mais peaufiner l'interface Processing <-> UNO via le bus Série et DCCpp.

Petit à petit, mes trains vont devenir de moins en moins virtuels. ;)

Bien amicalement
Denis  :P
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: msport le novembre 06, 2020, 10:15:32 am
1 seul train (L298 oblige) ...

On serait passé en G sans le dire ? Quand même, avec 2 A, ça fait un budget pour les utiliser avec des locos en N !
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 06, 2020, 10:28:43 am
OK, Michel   ;)

Je veux simplement commencer avec une seule loco (c'est d'autant plus facile que je n'ai qu'une loco DCC  ;D), mais je verrais après le passage d'une loco à l'autre.
Chaque chose en son temps.

Bien amicalement
Denis  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: Dominique le novembre 06, 2020, 12:30:14 pm
D’autant que sur une voie de programmation il n’est possible de ne placer qu’une seule loco (et même un seul décodeur).
Sur la voie principale il y a pas mal d’exceptions: ton programme les prend-il en compte ?
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 06, 2020, 01:35:54 pm
Ben, après, et c'est le but de ce fil (si, si), mon gestionnaire et un bus CAN... 8)

En ce moment, je vois tous les échanges nécessaires via la bus série (vers Arduino, pour débuter) et, à très court terme, les animations d'aiguilles, de manettes...
Je suis encore en phase purement Processing. Mais c'est presque fini.

Denis  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 06, 2020, 05:29:25 pm
Bonjour Denis et tous (mêê non, pas "tousse"),

oui en effet, j'avais déjà pu apprécier le fonctionnement de la V9. Toujours très impressionnant ; j'ai sans faire exprès demandé l'itinéraire le plus compliqué peut-être et ton code s'en sorti brillamment
(https://i44.servimg.com/u/f44/11/73/62/86/captur10.jpg)
(Je suis rassuré au passage sur les possibilités de mon dessin)

et de plus en plus convaincu. Trouver aussi facilement un tel itinéraire, et je suppose qu'il n'y aura aucune manœuvre d'aiguille manuelle pour qu'il se réalise (?) (mais quid des priorités entre convois ?)... sûr qu'on ne peut plus faire marche arrière quand on y a goûté.

Je suis surpris que le code soit aussi compact. Je ne l'ai pas regardé mais bravo, déjà, pour l'algorithme de création d'itinéraire. Peut être tout cela aurait-il tenu sur un Mega ? Probablement limite et c'est en tout cas un bien qu'il soit déporté sur Processing et donc, à priori, sur un processeur autrement puissant.
L'inconvénient peut-être, et tu en parles, c'est le flux de données, à double sens dans ce cas et je suis dubitatif à l'égard du port série.

J'ai vu sur train_TCO et ton circuit d'essais qu'il est possible de régler quelque chose que je n'ai pas su faire (ni retrouver car j'étais certain d'avoir lu qq chose à ce sujet...) :
sur ton retournement qui passe par le niveau 2 (ou -1), la zone comprend bien à la fois les pavés des niveaux 1 et 2. Comment fait-on ça s'il te plaît ??
(https://i44.servimg.com/u/f44/11/73/62/86/captur11.jpg)

Bien amicalement
Philippe
(l'erreur en haut à droite ? Eh non, car c'est un petit bug dans le dessin des retraits : la voie tout en haut est au niveau 1, celle immédiatement en dessous au niveau 2 et son dessin croise celui du niveau 1 exactement à l'endroit du retrait derrière l'aiguillage de la boucle au niveau 1. D'où l'impression de couac mais non car ça ne joue pas sur le fonctionnement)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 06, 2020, 07:06:04 pm
Bonsoir Philippe,

Pour les zones bi-niveaux, tu sélectionne un niveau, tu crées la zone, puis tu passes à l'autre niveau et tu ajoutes les pavés.
Si tu as une zone avec un bout en niveau 0, un bout en niveau1, puis un bout en niveau 0, tu crées le niveau 1 (sans signaux), puis tu ajoutes les deux bouts du niveau 1 et, là, tu mets les signaux.

Voilà, voilà... 8)

A part ça, je note que le 02/11, tu n'avais pas fait le dessin et le 06/11, ton réseau marche. Et tu ne connaissais ni Edit_TCO, ni Trains_TCO.
Moi, je dis, "Chapeau" !

Concernant les priorités, c'est tout bête : tu mets un deuxième train...

Tu peux générer des itinéraires incompatibles, il seront réservés, mais les trains ne se rentreront pas dedans.

Bien amicalement
Denis  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: simontpellier le novembre 06, 2020, 08:51:42 pm
... oui mais c'est parce que j'ai pris du temps pour bricoler ton code pour pouvoir prendre les aiguilles en manuel. Et faire des huit !
Ça permet de voir ce qu'il y a sous le capot ; belle mécanique !

(https://i44.servimg.com/u/f44/11/73/62/86/captur12.jpg)
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 06, 2020, 09:19:58 pm
Aucune chance que ça marche !
L'itinéraire est une pierre essentielle du programme.
TOUT tourne autour des itinéraires.

On ne peut pas bouger les aiguilles manuellement. Tu vas avoir des accidents
Titre: Re : Modélisation logicielle d'un réseau - le système de Denis
Posté par: DDEFF le novembre 07, 2020, 10:10:36 am
Bonjour Philippe,

Je m'explique :

Dans mon système, un train n'existe que parce qu'il est sur un itinéraire.

D'ailleurs, au début, il n'y a pas de train sur le réseau. Et, pour en mettre un, on doit créer un itinéraire sur lequel le train se déplace.
Un train ne peut se déplacer que sur un itinéraire. Sinon, il va rester bloqué à la fin du dernier itinéraire que tu as demandé.
Pas d'itinéraire, pas de train...

On n'a pas besoin de commander les aiguillages, c'est l'itinéraire qui le fait.
Et, surtout, gère la façon dont les choses vont se dérouler (arrêter les trains quand c'est nécessaire, redémarrer quand c'est possible, ...)

De la même manière, le pupitre n'a pas de bouton AV/AR. Ça ne sert pas non plus.
Si on veut reculer, on efface l'itinéraire du train (double clic) et on en refait un dans l'autre sens.

Maintenant, je pressent que tu voulais ajouter des boutons d'aiguillages, c'est que tu voulais faire passer le train là, là et là.
C'est tout à fait possible :

Tu fais un itinéraire jusqu'au premier point. De là, tu demande un itinéraire jusqu'au deuxième point, puis du deuxième point, tu redemandes un dernier itinéraire jusqu'au 3ème point.

Le train va suivre les itinéraire enchaînés, avec arrêt ou non, suivant ce que tu lui as demandé en construisant les itinéraires.
À chaque demande d'itinéraire, le programme propose tous les itinéraires possibles entre les deux points. Le premier proposé n'est pas forcément celui que tu veux et on peut choisir celui qu'on veut (clic GAUCHE), puis le valider (clic DROIT)

Bien amicalement
Denis  :P