Modélisation logicielle d'un réseau - le système de Denis

[DDEFF]

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
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 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 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?article156
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. 

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. 

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  ) 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…

[Dominique]

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

[DDEFF]

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 :

Code: [Sélectionner]

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.

[Dominique]

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 

[DDEFF]

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!

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.

[Thierry]

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 :

Code: [Sélectionner]

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 !):

Code: [Sélectionner]

    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 !

[DDEFF]

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)

Au départ, la classe Voie. On garde (évidemment !)

Code: [Sélectionner]

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 :

Code: [Sélectionner]

/*
 * 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 :

Code: [Sélectionner]

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 !! 

[Thierry]

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 :

Code: [Sélectionner]

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

[DDEFF]

J'aime quand on me parle comme ça 

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.

[DDEFF]

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.

[DDEFF]

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

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  :

[DDEFF]

ça y est, j'ai ma matrice ! 
Il reste encore des bugs, mais ça marche.

A peaufiner, donc 

[Patrick75]

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.

[DDEFF]

Merci de l'intérêt porté à mon fil 

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 !  

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 
Essaie de le détailler dans un fil que tu créerais.

A bientôt.

[DDEFF]

Bonjour à tous,

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

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

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) et sur un autre que certains connaissent déjà : le petit train du Tertre (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), 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 

Le fichier image joint, très tassé, ne rend pas la qualité du vrai affichage vectoriel.