LOCODUINO

Parlons Arduino => Modélisation, Architectures logicielles et matérielles => Discussion démarrée par: Pierre59 le mai 31, 2015, 11:28:07 am

Titre: Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le mai 31, 2015, 11:28:07 am
Bonjour

Je voudrais monter ici une approche objet de la modélisation logicielle d'un réseau.

Mon réseau est constitué d'un ovale à double voie sur lequel il y a une coulisse et une gare moyenne. Cette gare comporte plusieurs voies à quai, une partie marchandises et un dépot, de la gare part aussi une voie unique finissant à une petite gare terminus.

Le réseau comporte une trentaine d'aiguilles, une trentaine de zones et une dizaine de cantons.

Le réseau est géré par un très gros programme sur PC. Une dizaine de cartes électroniques sur deux bus I2C font l'interface entre le PC et le réseau.

Le programme sur PC comporte plusieurs parties :

- une partie de gestion des cartes électroniques (rétrosignalisation, souris, commandes des alimentations, des aiguilles, des signaux …)

- une partie de gestion de TCOs sur l'écran du PC (il pourrait avoir un TCO réel)

- une grosse partie de gestion du fonctionnement du réseau, cette partie reçoit toutes les infos du réseau (rétrosignalisation …) et toutes les commandes des utilisateurs (souris, itinéraires, …), elle sait ainsi toujours ce qui se passe sur le réseau. Cette partie est réalisée en programmation objet et ne comporte pas de tables, la description du réseau se fait par les liens entre les objets et les méthodes (fonctions) de ces objets.

Je vais essayer de décrire les principales classes et leur fonctionnement en détaillant un peu plus la classe Zone. Mes classes sont en Java mais je vais essayer de les présenter à la C++ (longtemps que je n'ai pas fait de C++ objet).

La classe essentielle est la classe Zone :

class Zone {
   String nom;
   boolean etat; // libre ou occupé
   Train train; // le train dans la zone
   Signal signalPair,signalImpair; // les signaux éventuels de la zone

   Zone(…) {…} // constructeur

   virtual Zone suivantePaire(); // la zone suivante paire (éventuellement vide)
   virtual Zone suvanteImpaire(); // la zone suivante impaire (éventuellement vide)

   virtual void actions(); // les actions spécifiques à faire en cas d'occupation
   virtual void desactions(); // les actions spécifiques à faire en cas de libération

   boolean occupee() { return etat; } // méthode utilitaire
   boolean libre() { return !etat; } // méthode utilitaire

   void occuper() { // appelée par la rétrosignalisation
      // fait tout ce qu'il y a à faire en cas d'occupation (actions communes à toutes les zones)
      actions(); // fait les actions spécifiques à une zone
   }
   void liberer() { // appelée par la rétrosignalisation
      // fait tout ce qu'il y a à faire en cas de libération (actions communes à toutes les zones)
      desactions(); // fait les actions spécifiques à une zone
   }
}

chaque zone réelle fait l'objet d'une classe héritant de la classe Zone, voici un exemple :

class Z9 : Zone { // héritage de Zone
   
   Z9(…) {…} // constructeur

   void actions() { aubiner(c3,c5); } // fermeture de signaux (occupation)
   void desactions() { detruire(XA,XB,XC); } // destruction d'itinéraires (liberation)

   Zone suivantePaire() { return z11; } // la zone paire suivante (toujours la meme)
   Zone suivantePaire() { if (a3.directe()) return z9; else return z7; } // la zone impaire suivante (dépends de la position de l'aiguille a3)
}

Ces classes zones décrivent la géométrie du réseau et les interactions entre les différentes parties. Elles précisent les liens entre les zones (de façon dynamique en fonction de la position réelle des aiguilles), l'emplacement des signaux, … Tout le réseau est ainsi décrit.

Les autres classes principales s'articulent autour des zones :

- la classe signal gère les signaux (lumineux et mécaniques), elle calcule les feux en fonction des occupations de zones, des signaux adjacents et de la position des aiguilles, elle fait le cantonnement pour les parties du réseau qui en sont équipées) et commandes les signaux.

- la classe Aiguille garde la position d'une l'aiguille et fait l'interface avec l'électronique pour les commandes

- la classe Train mémorise les informations sur un train ( sens, vitesse, nom de l'engin moteur, adresse DCC, …)

- la classe Itineraire réalise les itinéraires (une centaine), elle fait les enclanchements entre itinéraires, la mémorisation/création/destruction des itinéraires. Elle est organisée comme la classe Zone, la classe Itineraire contient tout ce qui est commun à tous les itinéraires, des classes (héritant de la classe Itineraire) contenant  les parties spécifiques.


Cette programmation objet bien que assez technique est très puissante, elle peut gérer des petits ou grands réseaux,, elle évite les tables (avec leur problèmes de construction/mise à jour, …), elle facilite grandement des modification ponctuelles du réseau (seules quelques classes sont à modifier ou à créer) et facilite la mise au point au début. Elle nécessite un processeur assez puissant. Du point de vue allocation mémoire les objets sont tous crées à l'initialisation du programme, l'accroissement des variables est linéaire avec l'accroissement du réseau.

Cette programmation n'évite pas (comme avec d'autres types de  programmations) les problèmes de synchronisation dans le cas de fonctionnement multi-tâches et/ou de programmation évenementielle (sur interruptions).

Voila, n'hésitez pas à poser des questions, et franchissez le pas de la programmation objet (voir les cours sur les objets et l'héritage dans une autre partie du site)

Pierre


Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le juin 16, 2015, 05:23:56 pm
Bonjour

J'en remet une couche (d'objets), voici un squelette d'itinéraire.

Il faut d'abord quelque classes accessoires  :

class Zone {
  boolean etat; // etat de la Zone (libre ou occupee)
public:
  boolean libre() { return !etat; }
};

class Aiguille {
public:
  boolean directer() { /* commande de l'aiguille */ return true; }
  boolean devier()   { /* commande de l'aiguille */ return true; }
};

class Signal {
public:
  boolean ouvrir() { /* commande du signal */ return true; }
  boolean fermer() { /* commande du signal */ return true; }
} ;

Puis quelques variables :

TB iTB; TD iTD; BT iBT; DT iDT; // itineraires
Zone za,zb,zc; // zones
Aiguille a1,a2,a3; // aiguilles
Signal s1,s2,s3; // signaux

La classe de base "Itineraire" contient tout ce qui est commun à tous les itinéraires :

class Itineraire { // classe de base des itineraires
  byte etat; // l'etat de l'itineraire (libre, en attente, forme, ... )

public:
  boolean libre() { return etat==0; }
  boolean formation()    { if (formable()) return former(); else return false; }
  boolean destruction() { if (deformable()) return deformer(); else return false; }
   
protected:
  virtual boolean formable();
  virtual boolean former();
  virtual boolean deformable();
  virtual boolean deformer();
 
// methodes utilitaires
protected:
  boolean libre(Zone &a) { return a.libre(); }
  boolean libres(Zone &a,Zone &b) { return a.libre() && b.libre(); }
  boolean libres(Zone &a,Zone &b,Zone &c) { return a.libre() && b.libre()&& c.libre(); }
  boolean libres(Zone &a,Zone &b,Zone &c,Zone &d) { return a.libre() && b.libre() && c.libre() && d.libre(); }
  // ...
  boolean libre(Itineraire &a) { return a.libre();
  boolean libres(Itineraire &a,Itineraire &b) { return a.libre() && b.libre(); }
  boolean libres(Itineraire &a,Itineraire &b,Itineraire &c) { return a.libre() && b.libre()&& c.libre(); }
  boolean libres(Itineraire &a,Itineraire &b,Itineraire &c,Itineraire &d) { return a.libre() && b.libre() && c.libre() && d.libre(); }
   // ...
  };

Les méthodes formation() et deformation() permettent de former et de détruire l'itinéraire (elles peuvent êtres enrichies si nécessaire). Elles peuvent êtres appellées par les boutons de commande et/ou par d'autres objets (Zone par exemple) pour des destructions automatiques.

Les méthodes formable(), former(), deformable() et deformer() sont propres à un itinéraire particulier, elles seront définies dans des classes dérivées, une par itinéraire (c'est pour cela qu'elles sont marquées virtuelles).

Les méthodes libre(s)(…) sont des méthodes utilitaires pour faciliter l'écriture des méthodes précédentes. Pour ne pas faire de copies inutiles les objets sont appelés par référence. (on peut aussi utiliser des méthodes avec un nombre d'arguments variables).

Voici pour finir un exemple d'itinéraire particulier (une des classes correspondant à chaque itinéraire) :

class TC:public Itineraire { // un itineraire particulier de T vers C
  virtual boolean formable() { return
    libres(iTB,iTD,iBT,iDT) && // enclanchements entre itineraires
    libres(za,zb,zc); // enclanchements sur les zones
  }
  virtual boolean former() { return a1.devier() && a2.directer() && s1.ouvrir(); }
  virtual boolean deformable() { return libres(za,zb,zc); }
  virtual boolean deformer() { return s1.fermer(); }
};

La méthode formable() gère les enclanchements.
La méthode former() établit l'itinéraire en positionnant les aiguilles et en ouvrant le signal.
La méthode deformable() s'assure que l'itinéraire peut être détruit.
La méthode deformer() ferme le signal.

Bien sur d'autres tests et d'autres actions peuvent êtres ajoutées dans ces méthodes.

Vous voyez ce n'est pas si compliqué que cela, il faut bien entendu écrire toutes les classes itinéraire particulier, mais c'est assez répétitif.
Il est facile de modifier des itinéraires d'ajouter des itinéraires …
Il est facile de faire la mise au point avec des affichages sur le moniteur série.
Bon courage !

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le juin 16, 2015, 07:45:28 pm
Merci beaucoup Pierre,

L'intérêt de la programmation Objet s'avère particulièrement utile dans ce domaine (je ne veux pas dire qu'il ne l'est pas dans d'autres).

Tes contributions m'ont convaincu : je vais essayer de concevoir la modélisation de mon réseau de cette façon, ce qui nous permettra d'en discuter avec du concrêt.

Amicalement
Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le juillet 06, 2015, 05:03:03 pm
Bonjour

Une dernière couche avant les vacances (toujours d'objet) pour les signaux. Les signaux sont très "polymorphes", c'est à dire qu'ils ont pas mal d'aspects et de comportements différents (lumineux, mécaniques, sémaphores, carrés, avertissements, …). Même façon d'écrire que pour les classes précédentes, une classe de base qui contient tout ce qui est commun, des classes dérivées pour les particularités. Sauf qu'ici on va regrouper des particularités, conduisant à de l'héritage d'héritage (pas de panique c'est tout naturel).

La première classe est la classe Signal :

typedef unsigned int typeFeux;

enum Feu {E=0,Vl=1,A=2,S=4,C=8,R=16,RR=32,M=64,Cv=128,D=256};
   
class Signal {
protected:
  typeFeux feu=E; // 16 cas possibles (16 bits)
public:
  virtual boolean ouvrir() { /* commande du signal */ return true; }
  virtual boolean fermer() { /* commande du signal */ return true; }
  boolean aubiner() {  return fermer();  }

  boolean ferme() { return feu&(S|C|Cv); }
  boolean v30() { return feu&RR; } // vitesse 30
  boolean r30() { return feu&A|R; } // ralentissement a 30
  };

  virtual typeFeux feux() { return E; }
  virtual void maj() {}
 
  virtual Signal* suivant() { return NULL; }
  virtual Signal* precedent() { return NULL; }
  virtual boolean occupe() { return false; } // occupation du canton

// methodes utilitaires
  Signal* selon(Aiguille &a,Signal &s1,Signal &s2) { return a.directe()?&s1:&s2; }

  boolean occupee(Zone &z) { return z.occupee(); }
  boolean occupees(Zone &z1,Zone &z2) { return z1.occupee() || z2.occupee(); }
  boolean occupees(Zone &z1,Zone &z2,Zone &z3) { return z1.occupee() || z2.occupee() || z3.occupee(); }
};

La classe Signal comporte une variable mémorisant l'état des feux, les valeurs des feux sont des puissances de 2 pour pouvoir faire des opérations ensemblistes (unions, intersections) facilement. Les fonctions ouvrir() et fermer() seront définies dans les classes dérivées. La fonction aubiner() ferme le signal (on pourrait éventuellement la redéfinir en cas de besoin). Les fonctions ferme(), v30() ou r30() sont des fonctions utilitaires ainsi que les fonctions occupee(s)() et la fonction selon(). Les fonctions fonctions feux() et maj() seront définies dans les classes dérivées, la fonction feux() "calcule" les feux à l'ouverture du signal, la fonction maj() est appelée par le signal suivant lors d'un changement de feux. La fonction utilitaire selon() retourne le signal suivant en fonction de la position de l'aiguille (facilité d'écriture). Les fonctions utilitaires occupee(s)() testent l'occupation du canton (utiles pour les cantons multi-zones notamment dans les gares).

Quelques classes correspondant à des signaux particuliers :

La classe Carré violet est la plus simple, pas d'interactions avec d'autre signaux. On peut aubiner le signal lors de l'occupation de la zone qui suit le signal. Cette classe peut être utilisée directement (sans faire de nouvelles classes). Pour ce type de carré on sait définir les méthodes ouvrir(), fermer() (feux() et maj() ne servent pas) :

class CarreViolet:public Signal {
  boolean ouvrir() { feu=M;  /* commande signal */ return true; }
  boolean fermer() { feu=Cv;  /* commande signal */ return true; }
};

Exemple de carré violet :

CarreViolet cv5;

La classe Carré (sans sémaphore) est plus intéressante car elle dépend d'autres signaux. On peut aubiner le signal lors de l'occupation de la zone qui suit le signal. Pour ce type de signal on sait définir les méthodes ouvrir(), fermer(), feux() et maj(), par contre les fonctions suivant() et precedent() dépendent d'un carré particulier (topologie du réseau), il faudra donc hériter de Carre pour un carré particulier. La classe Carre :

class Carre:public Signal {
  boolean ouvrir() { feu=feux(); precedent()->maj(); /* commande signal */ return true; }
  boolean fermer() { feu=C; precedent()->maj(); /* commande signal */ return true; }

  typeFeux feux() { // feux a l'ouverture
    if (suivant()->ferme()) return A; else return Vl;
  }

  void maj() { typeFeux f; // appele par le signal suivant
    if (ferme()) return; // pas de propagation si pas de changement
    f=feux(); if (f!=feu) { feu=f; precedent()->maj(); }
  }
};

Exemple de carré  particulier :

class C2:public Carre {
  virtual Signal* suivant() { return selon(a2,s1,s3); } // selon a2
  virtual Signal* precedent() { return &s1; }
};

le signal suivant dépends d'une aiguille.

La classe Sémaphore interagit avec d'autres signaux et avec des zones. Le sémaphore est fermé (aubiné) par l'occupation de la première zone du canton, lors de la libération de la dernière zone du canton ouvrir() est appelée pour mettre à jour les feux. La fonction occupe() teste l'occupation du canton (pour les cantons multi-zones). Pour ce type de signal on sait définir les méthodes ouvrir(), fermer(), feux() et maj(), par contre les fonctions suivant() et precedent() dépendent d'un sémaphore particulier, il faudra donc hériter de Semaphore pour un sémaphore particulier. La classe Semaphore :

class Semaphore:public Signal {
  boolean ouvrir() { feu=feux(); precedent()->maj(); /* commande signal */ return true; }
  boolean fermer() { feu=S; precedent()->maj(); /* commande signal */ return true; }

  typeFeux feux() { // feux a l'ouverture
    if (occupe()) return S; else // canton occupe ( precaution )
    if (suivant()->ferme()) return A; else return Vl;
  }

  void maj() { typeFeux f; // appele par le signal suivant
    if (ferme()) return; // pas de propagation si pas de changement
    f=feux(); if (f!=feu) { feu=f; precedent()->maj(); }
  }
};

Exemple de sémaphore particulier :

class S2:public Semaphore {
  virtual Signal* suivant() { return &s2; }
  virtual Signal* precedent() { return &s1; }
  virtual boolean occupe() { return occupees(za,zb,zc); } // occupation du canton (3 zones)
};

Voila avec cette façon de programmer on peut prendre en compte toutes les configurations de signal possible, j'ai sur mon réseau des carrés avec manoeuvre ou rappel de ralentissement et  en plus sémamaphore (pour les itinéraires permanents).

Je n'ai pas de classe Canton, mais cela serait possible.

Comme pour des zones et les itinéraires il manque les constructeurs (les destructeurs ne sont pas utiles ici), ce que je voudrai montrer ici c'est essentiellement l'aspect conceptuel de l'approche objet. Les classes ne sont pas exemptes d'erreurs, ni de mauvaises écritures (notamment Zone qui n'utilise pas les pointeurs où il faudrait). Bien qu'ayant enseigné, il y longtemps, le C++, j'ai beaucoup oublié (mais cela revient) car maintenant je fais du Java (je transcode ici du Java en C++), de plus je ne peux pas faire de tests, je peux juste compiler pour vérifier.

On pourrait imaginer de construire une bibliothèque de classes, mais cette bibliothèque ne pourrait pas être utilisée directement comme d'autres bibliothèques, il faudrait écrire des classes héritant des classes de la bibliothèque pour beaucoup de composants du réseau (zones, aiguilles, signaux, …), car ce sont ces classes qui définissent la topologie du réseau.

Bonnes vacances.

Pierre

Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le juillet 10, 2015, 12:22:01 am
Voilà une serie de contributions fort intéressantes et concrètes  :)

Je retiens d'abord le fait que la description du réseaux ne se fait pas dans une table, mais dans chaque objet directement : chaque zone (ou canton, mais une zone peut inclure une aiguille, pas un canton normalement) décrit les connexions aux zones adjacentes.

Cela demande certainement un petit travail de préparation : est-il possible de montrer un exemple simple ?
-> ce serait le coté statique !

Ensuite chaque objet peut être personnalisé (à partir de l'héritage) ce qui laisse entrevoir la grande souplesse du modèle et la facilité d'évolution (on ne peut pas penser à tout dès le début !).

Ensuite ce modèle vit au rythme des événements (les traitements des signaux remontés par les capteurs aux passage des trains appellent-ils les méthodes des objets directement ? ).
-> c'est le coté dynamique !

Merci pour ces "devoirs de vacances" : il va me falloir un peu de temps pour imaginer mon réseau de cette façon.

Et bravo encore à Denis et Pierre de rendre cette rubrique si concrète..

Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le juillet 11, 2015, 11:57:50 am
Bonjour

Quelques réponses :

Citer
chaque zone (ou canton, mais une zone peut inclure une aiguille, pas un canton normalement)

Toujours la polémique avec les cantons. Pour moi une zone est une portion de voie (avec ou sans aiguille(s)) munie d'une détection de présence des trains. Un canton est une portion de voie entre deux sémaphores.

Cela n'exclue pas qu'il puisse y avoir plusieurs zones dans un canton, dont des zones avec aiguilles.
Sur nos réseaux un canton a généralement au moins deux zones une zone de pleine voie et une zone d'arret.

Citer
est-il possible de montrer un exemple simple ?

J'ai regardé pour extraire une toute petite partie de mon réseau, mais c'est pas évident.

Citer
les traitements des signaux remontés par les capteurs aux passage des trains appellent-ils les méthodes des objets directement ?

Les évènements issus du réseau appellent les méthodes sur les objets, par exemple l'occupation et la libération des zones appellent les méthodes occuper() et liberer() de Zone. Il faut seulement veiller que pendant le traitement d'un évènement d'autres ne soient pas pris en compte, pour que la mise à jour de l'état du réseau puisse faire complètement. Plus généralement quand on a appelé une méthode sur un objet il faut que tout ce qui en découle se fasse sans interruption  (pour préserver un état cohérent du réseau).

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le novembre 18, 2015, 06:55:55 pm
Bonjour à tous,

Je voudrais témoigner ici que la modélisation "objet" de Pierre fonctionne bien !

J’ai donc modélisé mon réseau avec les objets Aiguille et Zone seulement pour commencer.

Cela se passe en 4 étapes :

Etape 1 : les classes prototypes (copier-coller du code de Pierre).

J’en ai profité pour ajouter l’action d’envoi des commandes d’aiguille sur le bus CAN, mais cela ne sert pas pour le moment.

///////////// PROTOTYPE CLASSE AIGUILLE ////////////////////

class Aiguille {
private:
  byte index;             // 0.. MaxAIG-1
  boolean etat=true;      // directe (true) ou deviee false)
  Zone* zone;             // la Zone ou est l'aiguille

public:
 
  Aiguille(byte a_index, Zone* z) { // constructeur
    index = a_index;
    zone=z; 
  }
 
  boolean directer() {     // commande de l'aiguille en position directe
    this->etat=true;
    output.id = 0x40;
    output.length = 1;
    output.data.bytes[0] = this->index + 0xC0;
    Can0.sendFrame(output);
    return true;
  }
 
  boolean devier()   {     // commande de l'aiguille en position déviée
    this->etat=false;
    output.id = 0x40;
    output.length = 1;
    output.data.bytes[0] = this->index + 0x80;
    Can0.sendFrame(output);
    return true;
  }
 
  boolean directe() {     // demande d'état
    return this->etat;
    } // méthode utilitaire};
};

////////////////// PROTOTYPE CLASSE ZONE ////////////////////

class Zone {
public:
  byte index;           // 0.. MaxZone-1
  boolean etat;         // libre ou occupé
  Signal* signalPair;
  Signal* signalImpair; // les signaux éventuels de la zone

  Zone(byte a_index, Signal* sp, Signal* si) { // constructeur
    index = a_index;
    signalPair=sp;
    signalImpair=si; }
   
   virtual Zone* suivantePaire() { return NULL; } // la zone suivante paire (éventuellement vide)
   virtual Zone* suivanteImpaire() { return NULL; } // la zone suivante impaire (éventuellement vide)

   virtual void actions() {} // les actions spécifiques à faire en cas d'occupation
   virtual void desactions() {} // les actions spécifiques à faire en cas de libération

   boolean occupee() { return etat; } // méthode utilitaire
   boolean libre() { return !etat; } // méthode utilitaire

   void occuper() { // appelée par la rétrosignalisation
      // fait tout ce qu'il y a à faire en cas d'occupation (actions communes à toutes les zones)
      actions(); // fait les actions spécifiques à une zone
   }
   void liberer() { // appelée par la rétrosignalisation
      // fait tout ce qu'il y a à faire en cas de libération (actions communes à toutes les zones)
      desactions(); // fait les actions spécifiques à une zone
   }

   Zone* selonAiguille(Aiguille* a,Zone* z1,Zone* z2) { return a->directe()?z1:z2; } // méthode utilitaire
};

Etape 2 : je crée toutes mes zones par héritage du prototype (voici seulement les 4 premières, elle sont toutes identiques)

////////////// HERITAGES CLASSES ZONES REELLES ////////////////////
// les zones reelles (héritages de Zone)

// 0 gare base loisirs (pair/droite= 1 impair/gauche=0=butoir)
class Z0 : public Zone { // 0 gare base loisirs (pair/droite= 1 impair/gauche=0=butoir)
public:
  Z0(byte ai, Signal* sp, Signal* si):Zone(ai,sp,si) {}
  virtual Zone* suivantePaire();
  virtual Zone* suivanteImpaire();
};
// 1 VV centre (pair/droite=2, impair/gauche=0)
class Z1 : public Zone { // 1 VV centre (pair/droite=2, impair/gauche=0)
public:
  Z1(byte ai, Signal* sp, Signal* si):Zone(ai,sp,si) {}
  virtual Zone* suivantePaire();
  virtual Zone* suivanteImpaire();
};
// 2 liaison VV-Hor (pair/droite=3siPdroite, impair/gauche=1+aiguillePdevié=4)
class Z2 : public Zone {
public:
  Z2(byte ai, Signal* sp, Signal* si):Zone(ai,sp,si) {}
  virtual Zone* suivantePaire();
  virtual Zone* suivanteImpaire();
};
// 3 gare centre (droite/pair=3=butoir, gauche/impair=2)
class Z3 : public Zone {
public:
  Z3(byte ai, Signal* sp, Signal* si):Zone(ai,sp,si) {}
  virtual Zone* suivantePaire();
  virtual Zone* suivanteImpaire();
};
etc…

Etape 3 : déclaration des objets réels (zones et aiguilles).

Pour accéder individuellement aux objets, à partir des index contenus dans les messages CAN (dans un événement « occupation de zone » par exemple), j’ai déclaré un tableau de zones. De même pour le tableau d’aiguilles.
De cette façon, on ne manipule que des pointeurs sur les zones et les aiguilles.

/////////////////// DECLARATIONS ZONES ////////////////////
// zones
Zone* z0=new Z0(0,NULL,s2);
Zone* z1=new Z1(1,NULL,s2);
Zone* z2=new Z2(2,NULL,NULL);
Zone* z3=new Z3(3,s2,NULL);
Zone* z4=new Z4(4,s2,c2);
Zone* z5=new Z5(5,s2,c2);
Zone* z6=new Z6(6,s2,c2);
Zone* z7=new Z7(7,s2,c2);
Zone* z8=new Z8(8,s2,c2);
Zone* z9=new Z9(9,s2,c2);
etc…

const int MaxZone = 40;

Zone* listez[MaxZone]=  {
    z0, z1, z2, z3, z4, z5, z6, z7, z8, z9, z10, z11, z12, z13, z14, z15,
    z16, z17, z18, z19, z20, z21, z22, z23, z24, z25, z26, z27, z28, z29, z30,
    z31, z32, z33, z34, z35, z36, z37, z38, z39
  };

/////////////////// DECLARATIONS AIGUILLES //////////////////// 
// aiguilles
Aiguille* a0=new Aiguille(0,z26);  //A
Aiguille* a1=new Aiguille(1,z26);  //B
Aiguille* a2=new Aiguille(2,z15);  //C
Aiguille* a3=new Aiguille(3,z26);  //D
Aiguille* a4=new Aiguille(4,z15);  //E
Aiguille* a5=new Aiguille(5,z14);  //F
Aiguille* a6=new Aiguille(6,z14);  //G
Aiguille* a7=new Aiguille(7,z12);  //H
Aiguille* a8=new Aiguille(8,z12);  //I
Aiguille* a9=new Aiguille(9,z29);  //J
Aiguille* a10=new Aiguille(10,z38); //K
Aiguille* a11=new Aiguille(11,z29); //L
Aiguille* a12=new Aiguille(12,z39); //M
Aiguille* a13=new Aiguille(13,z6); //N
Aiguille* a14=new Aiguille(14,z35); //O
Aiguille* a15=new Aiguille(15,z2); //P
Aiguille* a16=new Aiguille(16,z4); //Q
Aiguille* a17=new Aiguille(17,z17); //R
Aiguille* a18=new Aiguille(18,z24); //S
Aiguille* a19=new Aiguille(19,z37); //T TJD demi a5 vers deviation
Aiguille* a20=new Aiguille(20,z37); //U TJD demi a6 vers deviation

const int MaxAig = 21;
 
Aiguille* listea[MaxAig]= {
  a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11,
  a12, a13, a14, a15, a16, a17, a18, a19, a20
};

Etape 4 : la modélisation de mon réseau commence maintenant par l’écriture des méthodes particulières « suivantePaire » et « suivanteImpaire »

Pour ce faire, j’ai découpé mon réseau en zones. Certaines zones contiennent une aiguille ou plusieurs. J’ai défini le sens Pair (horaire) et Impaire (trigo) pour savoir quelle est la zone suivante paire ou impaire en fonction de la position d’aiguille s’il y en a une à traverser.

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

J’applique alors la méthode utilitaire du prototype :

selonAiguille(Aiguille* a,Zone* z1,Zone* z2) { return a->directe()?z1:z2; }
et cela donne :

///////////////////// METHODES PARTICULIERES DES ZONES ///////////////////////
// les methodes des zones

// Z0 gare base loisirs (pair/droite= z1 impair/gauche=butoir)
Zone* Z0::suivantePaire() { return z1; }
Zone* Z0::suivanteImpaire() { return NULL; }

// 1 VV centre (pair/droite=2, impair/gauche=0)
Zone* Z1::suivantePaire() { return z2; }
Zone* Z1::suivanteImpaire() { return z0; }

// 2 liaison VV-Hor (pair/droite=3, impair/gauche=1+aiguillePdevié=4)
Zone* Z2::suivantePaire() { return selonAiguille(a15,z3,NULL); }
Zone* Z2::suivanteImpaire() { return selonAiguille(a15,z1,selonAiguille(a16,NULL,z4)); }

// 3 gare centre (droite/pair=3=butoir, gauche/impair=2)
Zone* Z3::suivantePaire() { return NULL; }
Zone* Z3::suivanteImpaire() { return z2; }

// 4 GC Hor Ext (pair=6+aiguilleQdevié=2, impair=17)
Zone* Z4::suivantePaire() { return selonAiguille(a16,selonAiguille(a13,NULL,z7),selonAiguille(a15,NULL,z3)); }
Zone* Z4::suivanteImpaire() { return selonAiguille(a17,NULL,z16); }

// 5 GC Hor Int (pair=6, impair=17)
Zone* Z5::suivantePaire() { return selonAiguille(a13,z7,NULL); }
Zone* Z5::suivanteImpaire() { return selonAiguille(a17,z16,NULL); }

// 6 sortie GC Hor (pair=7, impair=5+aiguilleNdevié=4) - Normalement pas utilisé
Zone* Z6::suivantePaire() { return z7; }
Zone* Z6::suivanteImpaire() { return selonAiguille(a13,z5,selonAiguille(a16,z4,NULL)); }

etc..

Tests et Simulations

J’ai réalisé un petit montage sur le Due, avec un écran graphique 2,4 pouces et 3 boutons poussoirs (+, - et OK).
+ et - permettent de se déplacer dans les lignes et OK execute une fonction (menu sélectionné ou action)
Le programme affiche une liste de menus:

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

- menus Aiguilles :  je peux positionner chaque aiguille

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

- menu train : je peux définir le sens de déplacement
- menu Itinéraire : j’ai défini 7 points de départ. En appuyant sur OK, le programme demande la zone suivante successives aux objets en fonction des positions d’aiguilles (ici elles sont toutes droites, d’ou la série de « 1 » en bas de l’écran)

Ce petit bout de code fait tout (exemple pour le départ de la zone 5) :

zonedepart = 5;
        Show("5 ");
        zindex = 5;
        for (int i=0; i<10; i++)  {
          zt = senstrain? listez[zindex]->suivantePaire() : listez[zindex]->suivanteImpaire();
          if (zt == NULL) break;
          zindex = zt->index;
          tft.print(zindex);
          tft.print(" ");
        }

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

J’ai varié les positions d’aiguilles, le sens du train et à chaque fois, en vérifiant sur mon plan de réseau, les itinéraires sont tous bons !!!

CQFD
Un bon tuto suivra peut-être, prochainement.

Bien cordialement

Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le novembre 18, 2015, 07:05:39 pm
Juste une petite précision supplémentaire :
J'ai volontairement réduit les tailles des images qui doivent, au total, ne pas dépasser 192Ko.

Donc si vous voulez en savoir plus, je répondrai volontiers aux questions.

Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 11, 2016, 12:48:07 pm
Pour illustrer l'article de Pierre : "Un gestionnaire en C++ pour votre réseau" http://www.locoduino.org/spip.php?article154 (http://www.locoduino.org/spip.php?article154),
voici un exemple qui est la modélisation de mon propre réseau:

Je donne en pièces jointes la topographie réelle du réseau et le programme que j'explique ci-après:

Voici une version simplifiée (utilisée pour mon TCO) montrant les numéros d'aiguilles et de zones (à imprimer) :

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

Elle sera nécessaire pour se servir du programme.

Je suis parti du dossier Noyau de Base Gestionnaire C++ à la fin de l'article de Pierre et j'ai ajouté mes classes réelles d'aiguilles et de zones.

Les enchainements entre zones et aiguilles sont tout simplement décrits dans les méthodes suivantePaire() et suivanteImpaire() particulières de chaque zone.

Téléversez le programme dans un Arduino Mega ou Due (je n'ai pas encore essayé le Nano ou Uno) et ouvrez la fenêtre Moniteur à 115200 b/s.

Le programme initialise toutes les 19 aiguilles à "directe"

PRS1_DB1 v0.1 du 11 mars 2016
Toutes les aiguilles sont droites
aiguilles 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18
          1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1 
>

On peut faire, avec les commandes du moniteur :

A (ret) : afficher l'état de toutes les aiguilles (comme ci-dessus)

A n (ret) : inverser l'état de l'aiguille n
> A 0
aiguilles 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18
          0  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1 

I n (ret) : afficher l'itinéraire possible à partir de la zone n, dans le sens horaire, selon les positions des aiguilles
> I 13
Itineraires sens horaire a partir de 13->15->16->17->5->6->7->8->9->10->11->12->13->boucle

I n < (ret) : idem en sens inverse (anti-horaire)
> I 13 <
Itineraires sens trigo a partir de 13->12->11->10->9->8->7->6->5->17->16->15->13->boucle

La fin d'itinéraire est soit "sans fin" et il s'affiche "boucle", soit en "cul de sac" et il s'affiche "fin" :

> I 40
Itineraires sens horaire a partir de 40->0->1->2->3->41->fin

Vous remarquerez que les aiguilles sont dans des zones, ce qui permet de savoir si une aiguille est occupée ou libre (indispensable pour savoir si elles sont manoeuvrables). Parfois il peut y avoir plusieurs aiguilles dans une même zone. C'est réaliste.

Avec cette méthode il n'est pas besoin de savoir comment est connectée une aiguille, par son talon ou ses branches. Il suffit seulement de savoir quelle zone peut être atteinte en fonction de la position de l'aiguille. C'est NULL s'il n'y en a pas !
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 11, 2016, 10:52:27 pm
Retour sur la modélisation de Pierre : un exemple simple sera bien apprécié, je pense.  8)

Nous avons choisi le petit Locodrome initialisé par Guillaume ici : http://forum.locoduino.org/index.php?topic=91.msg650#msg650 (http://forum.locoduino.org/index.php?topic=91.msg650#msg650)

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

Et le programme pour modéliser les 5 zones et les 2 aiguilles se trouve ici en fichier joint.

Le programme tourne sur tous les types d'Arduino, même un Nano !

La commande "A n" permet d'inverser une aiguille n
La commande "I n" ou "I n <" permet d'afficher la suite de zones qui peuvent être parcourues (itinéraire possible) à partir d'une zone n de départ, dans le sens horaire ou anti-horaire (avec "<")

La modélisation du réseau se résume à la définition des méthodes des zones suivantes :

// 0 gare quai droit (zone paire = z2 si a0 droite, impaire = z5 si a1 droite)
Zone* Z0::suivantePaire() { return selonAiguille(a0,z2,NULL); }
Zone* Z0::suivanteImpaire() { return selonAiguille(a1,z5,NULL); }
/* si on accepte de passer les aiguilles en entrant par un talon, quelle que soit leur position
 * alors on peut définir ces methodes comme :
 * Zone* Z0::suivantePaire() { return z2; }
 * Zone* Z0::suivanteImpaire() { return z5; }
 */

// 1 gare quai gauche (zone paire = z2 si a0 deviée, impaire = z5 si a0 déviée)
Zone* Z1::suivantePaire() { return selonAiguille(a0,NULL,z2); }
Zone* Z1::suivanteImpaire() { return selonAiguille(a1,NULL,z5); }
/* si on accepte de passer les aiguilles en entrant par un talon, quelle que soit leur position
 * alors on peut définir ces methodes comme :
 * Zone* Z1::suivantePaire() { return z2; }
 * Zone* Z1::suivanteImpaire() { return z5; }
 */

// 2 aiguille a0 (zone paire = z3, impaire = z0 si a0 droite ou z1 si a0 deviée)
Zone* Z2::suivantePaire() { return z3; }
Zone* Z2::suivanteImpaire() { return selonAiguille(a0,z0,z1); }

// 3 boucle est (zone paire = z4, impaire = z2)
Zone* Z3::suivantePaire() { return z4; }
Zone* Z3::suivanteImpaire() { return z2; }

// 4 boucle ouest (zone paire = z5, impaire = z3)
Zone* Z4::suivantePaire() { return z5; }
Zone* Z4::suivanteImpaire() { return z3; }

// 5 aiguille a1 (zone paire = z0 si a1 droite ou z1 si a1 déviée, impaire = z4)
Zone* Z5::suivantePaire() { return selonAiguille(a1,z0,z1); }
Zone* Z5::suivanteImpaire() { return z4; }

Nous introduirons progressivement les autres méthodes (notamment la méthode provenance() qui permettra le suivi des trains), ainsi que les interfaces avec les organes réels du réseau.

Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le octobre 04, 2016, 10:18:48 am
Bonjour

Le troisième article de la série  "Un gestionnaire en C++ pour votre réseau" ( http://www.locoduino.org/spip.php?article172 ) est paru sur le site de LOCODUINO. Après les aiguilles, les zones et les signaux, les itinéraires sont abordés, ainsi qu'un exemple complet avec un réseau minimaliste, le Locodrome. Ce gestionnaire de réseau complet est destiné à fonctionner sur un Arduino Uno (ou plus), il pourra être testé complètement par le biais d’un TCO virtuel avec circulation effective de trains (tout aussi virtuels). Ce TCO virtuel est un programme écrit en Processing qui communique avec le gestionnaire par une liaison USB/série.

On trouvera dans le fichier joint (c'est le même que celui de l'article) :
- le programme de gestion du Locodrome en C++
- le programme du TCO en Processing
- une notice d'utilisation
- un dessin du TCO et un dessin du Locodrome

Le programme de gestion de réseau, utilisé pour le Locodrome, doit être considéré comme la version de référence (pour l'instant) rendant obsolète toutes les versions antérieures.

Avec ces deux programmes on peut jouer au trains (virtuels) presque comme sur un réseau réel.

Voir aussi sur le forum : "LOCODUINO->Parlons Arduino->Vos projets->TCO en Processing" ( http://forum.locoduino.org/index.php?topic=119.15 ), pour plus d'informations sur le TCO.

Bon amusement.

Pierre59
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le octobre 04, 2016, 10:25:10 am
Bonjour à tous,

Le 3ème volet du gestionnaire en C++ de Pierre est maintenant en ligne sur le site editorial de Locoduino, ici :
http://www.locoduino.org/spip.php?article172 (http://www.locoduino.org/spip.php?article172)

Nous vous invitons à en discuter ici.

Personnellement j'y trouve les réponses à toutes mes interrogations sur le fonctionnement complet d'un réseau ferroviaire, en particulier quelles sont toutes les interactions entre les éléments du réseau : les zones, les cantons, les aiguilles, les signaux, les itinéraires et, bien-sur, les trains et le TCO.

L'exemple du Locodrome avec le TCO séparé comprenant un simulateur de déplacement de 2 trains, montre bien la "dématérialisation" du gestionnaire par rapport au réseau et ses composants matériels. Mon architecture autour du réseau local CAN se prête bien à la réalisation complète de mon projet, les contributions précédentes de ce fil le montrent bien.

Amicalement
Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le octobre 06, 2016, 12:53:28 pm
De vrais bijoux de programmation objet.

Ces programmes valent vraiment le coup d'être étudiés et décortiqués.

Le programme TCO en processing a évidemment servi de base à mon propre développement (bientôt l'article ...  ;) ).
Je l'ai adapté à ma sauce, développé certains points, mais, fondamentalement, c'est le même programme.
Est même déjà développé ce que je voulais faire : mettre un point pour suivre le train !!
Merci Pierre.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le décembre 06, 2016, 06:17:22 pm
Bonjour à tous,

Les 3 articles de Pierre contiennent tout ce qu'il faut pour construire un gestionnaire complet, sophistiqué, évolutif, donc parfait selon mes intuitions, ce dont je suis sûr également, et ce n'est pas qu'une affaire de goût.

La question que l'on peut se poser est : est-il bien adapté à mon projet, à mon réseau, à son architecture technique, à mes scénarii de circulation, etc... ?

J'ai commencé, plus haut dans ce fil, à expliquer comment j'ai modélisé mon réseau, c'est à dire trouvé une description informatique de la topographie des voies, principalement grâce aux méthodes particulières suivantePaire() et suivanteImpaire() des objets Zone.

Et, de plus, cette modélisation est dynamique puisqu'elle s'adapte aux sens des aiguilles à tout instant !

Cela fait plus d'un an que mon embryon de gestionnaire, basé sur les objets zones et aiguilles de Pierre fonctionne sans la moindre erreur !

Je vais maintenant compléter ce gestionnaire jusqu'au bout, en partageant, avec vous, les étapes de ma progression, et en montrant les relations entre le gestionnaire et le matériel du réseau.

En général dans un projet, on commence toujours par une phase "papier" qui s'appelle "spécifications fonctionnelles puis organiques (dans le temps, quand je travaillais encore pour de vrai...). Cette étape avait pour but de prétendre qu'on allait tout prévoir dans le détail avant de commencer à réaliser.

Mais là on est dans un loisir ! A bas la rigidité !

Personnellement, je veux construire au fur et à mesure de mes disponibilités en temps et en argent, sans me sentir bloqué, sans avoir l'impression de faire des compromis, toujours en visant l'idéal et la perfection. C'est ambitieux ?

En fait non, grâce à Locoduino dirai-je !

Car mon réseau est construit autour de plusieurs modules qui prennent chacun en charge un partie du boulot : traction, aiguilles, occupations, TCO, etc..

C'est selon ce schéma d'architecture que j'ai publié avec l'article L’Arduino au coeur des systèmes de pilotage analogiques ou numériques : http://www.locoduino.org/spip.php?article153 (http://www.locoduino.org/spip.php?article153) :
(http://www.locoduino.org/local/cache-vignettes/L610xH401/fig5.2-282b9.png?1457605402)

J'ai donc réalisé plusieurs modules (même pas la moitié de ce que j'ai prévu, en fait), raccordés sur un bus CAN à 500kb/s, qui s'échangent des messages, sans hiérarchie.

Ce qui permet de répartir les responsabilités entre les organes capteurs (occupations, clés d'aiguilles sur le TCO, par exemple), les organes actionneurs (commandes d'aiguilles, par exemple) et le gestionnaire qui assure l'intelligence du réseau selon l'exemple ci-dessous :

(http://www.locoduino.org/local/cache-vignettes/L610xH433/genese6.1-cbff7.png?1456854952)

On en déduit tout de suite que le gestionnaire peut se réduire à un simple Arduino Due (le plus costaud de la famille, tant qu'à faire), disposant seulement d'une interface CAN pour recevoir des messages et en envoyer d'autres.

C'est vraiment le chef d'orchestre en haut de son estrade qui dirige les musiciens !

Et dans ce Due, le programme est exactement ce que Pierre a décrit dans ses articles Un gestionnaire en C++ pour votre réseau :
http://www.locoduino.org/spip.php?article154 (http://www.locoduino.org/spip.php?article154)
http://www.locoduino.org/spip.php?article167 (http://www.locoduino.org/spip.php?article167)
http://www.locoduino.org/spip.php?article172 (http://www.locoduino.org/spip.php?article172)

Et c'est d'autant plus naturel que le programme de l'Arduino tourne indéfiniment dans sa loop et ne va faire que lire les messages entrant, analyser ces messages et, en fonction de leur contenu, appeler des méthodes des objets Zone, Aiguilles, Signaux, Trains, etc..

La loop contiendra donc un grand switch pour traiter tous les cas, et on sait bien que l'on peut facilement rajouter d'autres cas par la suite : quelle souplesse cet Arduino !

Et certaines de ces méthodes vont envoyer un ou plusieurs message vers des organes de commande, via le bus CAN, tandis que d'autres ne feront que mettre à jour des variables dans les objets.

La définition de mon projet prend donc une toute autre forme, après avoir défini les modules nécessaires : définir les messages à échanger entre les modules (principalement avec le gestionnaire).

Ensuite, même si tous les messages ne sont pas encore définis, je peux commencer à coder.

C'est un peu cette aventure que je souhaite partager avec vous, dans la suite à venir. Je vais décrire succinctement mes modules et les messages qui les concernent. Puis l'intégration de tout cela dans le gestionnaire de Pierre.

Je pense que cela pourra vous aider à franchir le pas !

A suivre ...
Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le décembre 07, 2016, 01:33:51 pm

Bonjour

Il y a quelque chose qui me chiffonne beaucoup, dans le LocodromeBAL, associé à l'article 3 http://www.locoduino.org/spip.php?article172, les méthodes suivantePaire() et suivanteImpaire() ne servent pas, on peut les enlever cela ne change rien, en fait elles ne sont la que pour anticiper un peu la suite (l'article 4 à paraitre).

Ce qui veut dire que la topologie du réseau n'est en fait pas décrite explicitement, malgré cela le gestionnaire fonctionne tout à fait normalement, c'est donc le train lors de ses déplacements qui décrit d'une certaine façon la topologie du réseau ???

Bien sûr ces méthodes auront une utilité par la suite.

Pierre59
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le décembre 07, 2016, 02:05:34 pm
Merci Pierre,

Effectivement, je me demandais aussi où était vraiment décrite la topologie du réseau.
J'attends donc avec impatience le 4ème article !!  ;D

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le décembre 07, 2016, 02:44:26 pm
Bonjour Pierre,

Oui je suis d'accord, c'est la méthode selonAiguille() qui est utilisée à la base par suivantePaire() et suivanteImpaire, ainsi que provenance().

Ce qui est beau et pratique, c'est ta boîte à outil très complète et facile à comprendre qui laisse des choix selon les projets. Le Locodrome est un bon exemple pour comprendre la mise en oeuvre du gestionnaire. Comme il est simple il n'a probablement pas besoin de se servir de toutes les méthodes.

Dans mon réseau j'ai trouvé ce choix évident et bien pratique depuis le début car il permet de fixer la topographie, de connaître la liste des zones accessibles pour un itinéraire à partir de n'importe quel point du réseau et, bien-sur de réaliser le suivi des trains, la signalisation, tout en fait !

Dans la suite à venir de la mise en œuvre de mon réseau je vais montrer comment j'utilise ton gestionnaire. Il est certain que ce sera parfois critiquable mais, justement, j'aurai besoin de cette esprit critique pour faire mieux et que ce soit plus didactique.

Amicalement
Dominique
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le décembre 27, 2016, 11:34:18 pm
Effectivement, je me demandais aussi où était vraiment décrite la topologie du réseau.
J'attends donc avec impatience le 4ème article !!  ;D

Mon cher Denis, la réponse est dans la page précédente :
http://forum.locoduino.org/index.php?topic=166.msg781#msg781 (http://forum.locoduino.org/index.php?topic=166.msg781#msg781)

La construction pas à pas des objets m'amène à :
Citer
Etape 4 : la modélisation de mon réseau commence maintenant par l’écriture des méthodes particulières « suivantePaire » et « suivanteImpaire »

Cela n'empêche pas d'autres méthodes comme Pierre le suggère. Mais en tout cas mon réseau utilise ces méthodes suivantePaire() et suivanteImpaire() avec succès. Les exemples décrits le montrent bien, les écrans de test ayant été modernisés, j'y reviendrai prochainement.
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le janvier 03, 2017, 02:44:38 pm
Ce qui veut dire que la topologie du réseau n'est en fait pas décrite explicitement, malgré cela le gestionnaire fonctionne tout à fait normalement, c'est donc le train lors de ses déplacements qui décrit d'une certaine façon la topologie du réseau ???

Je comprend pourquoi : c'est parce que le TCO en Processing simule la conduite des trains et la topographie du réseau y est décrite aussi. Seule la rétrosignalisation émise par le TCO est en fait utilisée par le gestionnaire, ce qui permet de le simplifier.

Dans ma réalisation, je n'intègre pas tout de suite ce type de TCO graphique avec simulateur, juste un "mini-TCO" qui affichera ce que fait le gestionnaire. Les instructions suivantePaire() et suivanteImpaire vont être utiles pour déterminer les itinéraires et faire la poursuite en canton, le suivi des trains, etc.. mais je n'en suis pas encore là !
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le janvier 03, 2017, 04:07:11 pm
Quand on voit comment marche la recherche d'itinéraires, on doit facilement la rendre indépendante de la gestion du réseau proprement dite.

Donc, une solution intermédiaire serait de faire un "vrai" TCO, avec des vrais petits boutons, des LED et un itinéraire qui se trace quand on appuie sur Origine puis sur Extrémité ... avec aussi plein de fils. mais il y aurait de la demande.
Et pour ça, nettement plus simple, on a déjà quasi toutes les briques.

Comme je suis "un peu"  ;D perfectionniste, j'en veux toujours plus et je continue à chercher. :-*
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le janvier 03, 2017, 05:33:47 pm
Quand on voit comment marche la recherche d'itinéraires, on doit facilement la rendre indépendante de la gestion du réseau proprement dite.

Que cela soit un TCO sur un écran ou un TCO en dur cela ne change rien vis à vis de la gestion du TCO. Pour pouvoir faire des itinéraires à partir du TCO indépendamment du gestionnaire de réseau il faut que le TCO soit au courant de pas mal d'informations sur le réseau (topologie, aiguilles, zones, signaux, ...) et de leurs changements. Cela revient à transférer (ou à dupliquer) des parties du gestionnaire du réseau dans le TCO, avec le gros problème de maintient de la cohérence entre l'état du TCO et l'état du gestionnaire.

Comme j'en ai parlé dans le fil sur le système de Jean-Luc, j'utilise mon nouveau TCO (sur écran) pour faire circuler des trains virtuels et établir des itinéraires (avec recherche récursive) sans gestionnaire de réseau. Pour cela j'ai du ajouter au TCO des infos sur la topologie du réseau (les zones  suivantes paires et impaires), je dois gérer l'état des aiguilles, des zones et des signaux dans le TCO. Tout cela c'est des parties et des tâches du gestionnaire de réseau. Dans mon cas c'est facile car je fais circuler des trains virtuels sur un réseau tout aussi virtuel. Mais sur un réseau réel il faudra prendre en compte aussi l'interface réel avec le réseau (bus, Arduino, ...). Ce qui conduira à mettre pratiquement tout le gestionnaire de réseau dans le TCO.

Dans mon cas quand le TCO marchera bien je vais retirer tout ce qui a été rajouté (pour les itinéraires et la circulation des trains virtuels) pour les remettre dans le gestionnaire de réseau.

Je pense qu'il faut bien séparer les choses, le TCO affiche des informations fournies par le gestionnaire et il fournit au gestionnaire des demandes d'itinéraires (ou autres), mais il ne prend aucune décision. Le TCO et le gestionnaire sont deux programmes qui communiquent beaucoup entre eux, ils peuvent résider sur une seule machine (PC, Mac, PCduino, gros Arduino...) ou êtres répartis sur deux machines.

Pierre



Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le janvier 03, 2017, 07:16:13 pm
Tu as raison, pour nous.

Je pensais à ceux qui n'ont pas du tout de gestionnaire et qui veulent, en appuyant sur 2 boutons, voir les aiguilles se mettre en position (ce qu'on faisait d'antan avec une matrice à diodes), avec des aiguilles qui se mettent en position l'une après l'autre, évitant le traditionnel problème de la surintensité de ladite matrice à diodes.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le janvier 03, 2017, 07:57:15 pm
Si c'est un truc aussi simple que ça, je peux le faire facilement avec mon TCO basé sur un  Mega et qui communique via CAN avec le module de commande d'aiguille.

Actuellement j'ai un TCO en dur avec des inverseurs et 2 leds vertes pour chaque aiguille et une led rouge pour chaque zone (une zone peut contenir un élément de voie ou une aiguille, ou plusieurs).

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

Dans l'état actuel, chaque changement d'état d'un inverseur se traduit par un échange de message via CAN comme indiqué plus haut : http://forum.locoduino.org/index.php?topic=166.msg2274#msg2274 (http://forum.locoduino.org/index.php?topic=166.msg2274#msg2274)
De plus, chaque détection d'occupation ou le libération se traduit par la commande d'une led rouge et l'envoi d'un message CAN
Le TCO ne connait pas la topologie du réseau !

Mais ce serait facile de lui donner cette possibilité par un simple ajout logiciel : la description des zones et aiguilles selon les objets de Pierre, avec les méthodes suivantePaire() et suivanteImpaire(). C'est pas plus gros d'un tableau et cela me semble plus lisible et modifiable.

Après, pour créer un itinéraire, cela peut être très simple (en ajoutant un bouton par exemple pour initialiser le processus). Par un appui long sur ce bouton, on sélectionne un point de départ sur lequel se trouve un train détecté, on change éventuellement de train en appuyant plusieurs fois. Un nouvel appui long trace alors l'itinéraire devant ce train en fonction de la positions des aiguilles, par exemple en faisant clignoter les leds rouges d'occupation. Le changement d'une clé aiguille trace alors un autre itinéraire. Quand l'itinéraire souhaité est visualisé, un dernier appui long permet de le transmettre au gestionnaire ou au module de commande d'aiguilles qui fera la mise en place des aiguilles les une après les autres comme il se doit (ce que fait bien mon module de commande d'aiguilles).

Personnellement ce n'est pas ce que je ferai puisque je vais ajouter un écran graphique sur le bus CAN, mais c'est un simple exemple de faisabilité (qui demanderait un peu d'effort quand même, je le reconnais).

Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le janvier 04, 2017, 11:28:42 am

Bonjour

Bon, pour moi il n'y a que deux systèmes "viables" pour choisir les itinéraires :

- soit par appui sur un seul bouton (comme sur le Locodrome), mais cela conduit vite à beaucoup de boutons s'il y a beaucoup d'itinéraires

- soit par appui sur deux boutons, le bouton origine puis le bouton destination (ou vice-versa), ce qui limite bien le nombre de boutons

Les boutons pouvant êtres des boutons réels :

- soit sur une sorte de clavier séparé du TCO

- soit sur le TCO

Ils peuvent êtres des boutons virtuels sur un écran graphique et "appuyés" avec la souris ou un effet tactile, cela ne change rien.

Dans le cas avec deux boutons (réels ou virtuels) mis sur le TCO il est très pratique d'implanter les boutons sur le trace des voies, dans la zone d'origine et dans la zone de destination.

Ayant longuement pratiqué diverses méthodes ce sont les seules qui ne deviennent pas fastidieuses quand on "joue" au train, si la méthode est plus compliquée on se lasse très vite et on ne "joue" plus. Ma nette préférence étant pour les deux boutons sur le trace des voies.

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le janvier 04, 2017, 03:09:03 pm
Bonjour Pierre,

Oui je suis d'accord avec toi et je crois qu'il y a consensus sur Locoduino pour développer un écran interactif rien que pour choisir les itinéraires (et faire d'autres choses évidemment).

D'un coté Denis et toi avez développé un écran en Processing et le résultat est splendide.

De mon coté, je tente une autre approche en développant un écran en C/C++ sur Arduino Due (coût environ 65 € chez SainSmart), le Due étant connecté au bus Can permettant un échange de message du même type que celui de Processing (mais plus fiable évidemment).

J'ai écrit un programme sur Due qui affiche mon réseau sur un écran 5 pouces avec la bibliothèque "ILI9341_due"

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

La taille de 5" est due à mes contraintes de tableau de bord incliné à 60°, bien que j'aurais préféré 7". Mais bon !
La bibliothèque permet pas mal de possibilités graphiques et, pour le moment, les boutons en haut et en bas permettent de changer les aiguilles. Mais je vais changer cela et les utiliser pour stocker des commandes d'itinéraires avec un outil permettant d'en créer.

Comme tu l'as expliqué, il faudra choisir un bouton d'itinéraire libre, puis cliquer sur la zone de départ et la zone d'arrivée (si ces zones sont égales, alors ce sera un itinéraire automatique en boucle).

Au départ j'avais intégré cet écran graphique avec le gestionnaire : au total cela fait 5230 lignes de code dont presque la moitié pour le graphique.

Finalement je vais avoir un Arduino Due séparé.

Par rapport au TCO matériel, j'ai un peu développé les 5 zones de droite en les repliant au milieu, ce qui permettra de mieux voir les trains (il faut le plus possible de parties horizontales pour afficher les noms).

L'image ci-dessus montre que c'est loin d'être fini, pour afficher les différents attributs et les signaux.

J'ai du pain sur la planche  :P
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: bobyAndCo le janvier 04, 2017, 07:53:39 pm
Bonsoir,

Je vous présente mon TCO en HTML (lecture donc dans un navigateur web). On ne voit ici que le niveau 0 mais il y a un -1 (gare cachée) et un +1.

La commutation des aiguilles se fait par un click sur l'icon et l'image change bien sûr en fonction de la direction de l'aiguille. Les informations sont transmises par Ethernet à un MEGA qui gère au total 23 aiguillages. Sur le MEGA, les aiguilles sont programmées avec des structures en C mais ça pourrait tout aussi bien être de classes C++ ou de simples tableaux en langage Arduino.

On voit bien que ce ne sont pas les solutions qui manquent pour piloter nos Arduino's. Je répondrai volontiers à ceux qui souhaiteraient plus d'informations sur ce type de développement.

Bien amicalement.

(http://www.locoduino.org/IMG/png/tco_html.png)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le janvier 09, 2017, 09:01:39 pm
Bonsoir Pierre,

Je suis en train(haha  ;D ) de décortiquer ton programme 4 en Processing.
Il y a du grain à moudre !!

Je viens de comprendre d'où venait le nombre magique 0,551784, parce que maintenant tu es dans les courbes de Bezier cubiques.
https://www.google.fr/search?q=0.551784&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=l-RzWJ2JM7Os8wf3o5uACw (https://www.google.fr/search?q=0.551784&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=l-RzWJ2JM7Os8wf3o5uACw)
C'est effectivement encore plus rond qu'avant.

Par contre, ne commence pas par ça pour expliquer Processing, tu vas en rebuter quelques uns  ;D ;D
Et comme je me permets de faire varier l'épaisseur du trait, ça me promet quelques soirées bien occupées dans les maths et la géométrie.

J'utilise également les arcs à 45° (ceux que tu appelles Arc() ), mais eux aussi extensibles. Pareil... quelques soirées en perspective.
Mais je garderais sûrement ceux que j'ai déjà faits.

J'imagine que tu est passé aux courbes cubiques pour que, dans points(), tu puisses parfaitement suivre le tracé des courbes ?
Point() est assez costaud aussi.

J'aime bien ton idée de l'hexa pour les couleurs : comme je suis obligé d'être en HSB pour les couleurs pour les dégradés, ça marche aussi. Excellent !

Reste aussi les retraits automatiques (par changement d'identifiants), afficher les itinéraires, les trains...
Si j'ai fini en juin, je serais content !!  ;D ;D


Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le janvier 10, 2017, 10:56:11 am
Bonjour

Comme le déplacement des trains était saccadé, j'ai voulu (beaucoup) augmenter le nombre de points de passage des trains. Il est difficile de partager une courbe de Bézier en "arcs" de longueur égale, par contre c'est assez facile avec un cercle, c'est pour cela que je suis passé à des courbes Bézier cubiques qui avec le nombre magique sont quasiment des cercles.

Pour le calcul des coordonnées des points de passage (méthode points() ) j'ai du me "battre" avec Processing, j'ai assaini et simplifié cela dans une nouvelle version. J'ai aussi assaini le calcul des angles pour l'orientation des trains (tangente à la courbe) et l'ai rendu plus général.

Des arcs à 45° extensibles c'est une bonne idée, mais pour moi il faut que j'ai un cercle qui passe bien dedans, c'est déjà un peu juste avec les petits arcs, il faudra que je passe aussi aux courbes de Bézier cubiques (avec peut être d'autres nombres magiques).

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: HBC le janvier 16, 2017, 12:29:56 pm
Bonjour,

Je découvre le chapitre n°4 du gestionnaire en C++, déposé le 14 janvier, merci et bravo.

Suivant votre production avec assiduité, étant au chapitre 3 je m'en vais dévorer ce nouveau document.

Dire que je maîtrise totalement le contenu de vos exposés serait assez loin de la vérité, je suis un peu boa à digestion lente ... mais je me soigne ;-)

Vos articles, et tous les autres, disponibles tant sur le site que sur le forum sont vraiment très structurants et d'une qualité technique inégalée, soyez en tous remerciés, et félicités.

Bonne année à tous.

Cordialement
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 02, 2017, 10:27:49 am
Bonjour,
Tout d'abord félicitations car je suis admiratif de ce que vous faites.
Je vous soumet un petit problème concernant le programme TCOlocodrome car bien qu'ayant essayé toutes les versions, celui-ci ne compile pas chez moi quelques soient les versions de Processing(2, 3.2.4, 3.3). A chaque fois il bloque sur le code "shape(s,x,y); // decalage ligne colonne" dans le " void dessiner(int x,int y,int n,int c)" de la "class Forme".
Débutant en Processing, Java malgré de nombreuses recherche de solutions je n'ai pas trouvé l'origine de l'erreur.
Si vous pouviez m'aider à trouver la solution je vous en serais reconnaissant.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le mars 03, 2017, 08:33:58 am
Bonjour

Le Locodrome ne tourne que sur Processing 3. Personnellement je suis sur Mac (OSX 10.9.5) avec Processing 3.2.3, mais j'ai aussi essayé avec Processing 3.3 sans problèmes. D'autres on essayé sous Windows.

Pouvez vous préciser sur quoi vous le faites tourner, pouvez vous aussi préciser comment cela "bloque", erreur de compilation je suppose, qu'elle est cette erreur ?

Cordialement

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 03, 2017, 09:55:23 am
Bonjour,
Merci pour votre réponse.
Je suis sous Windows 7 et le problème (erreur compilation) existe quelque soit la version de Processing (2.2.1, 3.2.4, 3.3) utilisée.
La ligne 30 de l'onglet Formes de Tcolocodrome4C ( shape(s,x,y); // decalage ligne colonne ) est surlignée de jaune et le message d'erreur est le suivant:
 Cannot compile fragment shader: fragment shader failed to compile whith the following errors:ERROR:0:2: error(#239) Declaration must include a precision qualifier or the default precision must have been previouly declaredERROR ...

 Cette erreur apparait avec touts les versions de TCOlocodrome.

Cordialement
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 03, 2017, 10:21:01 am
Bonjour frdechaume,

Je me permets de répondre à la place de Pierre puisqu'il travaille sur Mac.
Moi, je suis sur Windows 10 et le programme fonctionne parfaitement chez moi, avec Processing 3.2.4 et maintenant dans la récente 3.3.

Je sais que ça n'a peut être pas de rapport, mais qu'as-tu de branché sur les ports com de ton PC ?

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le mars 03, 2017, 10:48:00 am
Bonjour

Pouvez vous essayer, dans le fichier "TCOlocodrome4C", de déplacer "size(1100,500,P2D);" de la ligne 50 vers la ligne 43, pour que se soit la première instruction du "setup()".

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 03, 2017, 12:20:41 pm
Re bonjour,

J'ai juste le port COM7 utilisé par un Arduino UNO.

La même erreur apparait en déplaçant "size(1100,500,P2D);" en ligne 43 au début du Setup.

Merci beaucoup pour vos réponses très réactives.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 03, 2017, 01:01:58 pm
Donc, ta deuxième ligne est bien :
int NO_PORT=0;
Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 03, 2017, 01:17:14 pm
Oui Denis ma 2ème ligne est bien "int NO_PORT=0;"
Merci de t’intéresser à mon problème.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 03, 2017, 02:11:05 pm
Il semble y avoir des problèmes entre les versions récentes de Processing et les anciennes versions de Windows...
https://github.com/processing/processing/issues/4929 (https://github.com/processing/processing/issues/4929)

D'autre part, il faut être bien sûrs des versions Processing (choix 32 ou 64 bits).

Dernière possibilité, un bug dans la version java ?
https://www.java.com/fr/ (https://www.java.com/fr/) et choisir le bouton du milieu : "Est-ce que je dispose de Java ?" qui va être suivi par "Vérifier votre version de java"
Je ne connais pas la version 32 bits de Windows 7 (je pense que c'est ton cas) puis que je suis en Windows 10, 64 bits.
J'ai la version 8 update 121, pour info.

Je ne pense pas que le problème soit dans le programme de Pierre, surtout pour un problème de compilation, parce que si c'était le cas, je planterais aussi.

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 03, 2017, 02:56:55 pm
Merci Denis
Je vais faire tout ce que vous me dites concernant les versions de Processing et Java; Je vous tiens au courant.
Comme vous, je ne pense pas que cela vienne du programme de Pierre puisque cela fonctionne chez vous.

A bientôt avec je l'espère avoir trouvé la solution.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 05, 2017, 10:18:03 am
Bonjour,
J'ai réussi a faire fonctionner Locodrome4 en retirant le paramètre "P2D" dans le Setup ligne 49 commande "size(1100,500,P2D); "
Je pense que cela vient d'un problème graphique bien que le driver de ma carte graphique soit à jour et que j'ai les bonnes versions de Java et Processing que j'ai vérifiées comme me le suggérait Denis
 
Il me reste un problème de tracé des "paves" comme vous pouvez voir sur l'image jointe que je n'arrive pas à résoudre malgré toutes les modifications que j'ai pu essayées dans le programme. Il est vrai que je suis loin d'avoir décortiqué tous les éléments de ce programme ce qui me permet d'améliorer mes faibles connaissances en Java et Processing.
Peut être pouvez vous m'aider sur ce problème?

Hors ce problème tous fonctionne très bien dans ce programme: circulation des trains qui suivent bien le tracé des "point" qui est correct, signalisation, itinéraires...
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le mars 05, 2017, 01:22:13 pm
Bonjour,
J'ai réussi a faire fonctionner Locodrome4 en retirant le paramètre "P2D" dans le Setup ligne 49 commande "size(1100,500,P2D); "
Bonjour

Cela a exactement le même effet quand je fais la même chose, mystère ?

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 05, 2017, 06:35:22 pm
Bonjour frdechaume,

Quand j'ai reçu le message, j'étais en rando  ::) et pas bien outillé pour répondre...

Nous sommes dans une situation embarrassante. Je m'explique :
Tu as remarqué certainement que je développe en parallèle un programme de TCO sur écran très fortement inspiré du locodrome (merci Pierre).
Tout fonctionnait parfaitement jusqu'à la version 3.2.3 (incluse) et Windows 10.
En passant à la 3.2.4, patatras !, mes courbes de Beziers sont "cassées".

J'ai donc mis un message en anglais sur Github de Processing :
https://github.com/processing/processing/issues/4879 (https://github.com/processing/processing/issues/4879)
C'est en anglais et la solution qu'on m'a proposé, c'est justement de passer en P2D (Processing 2D) et plus me servir de JAVA2D (si on ne met pas P2D dans Size)

Concrètement, j'avais, pour mon programme de TCO :
size(2560,1600); (en JAVA2D) et on m'a demandé de mettre :
size(2560,1600, P2D); (en Processing 2D)

Et, depuis, ça marche parfaitement, avec la 3.2.4 et la 3.3, avec P2D.

Ce qui me chagrine, c'est que toi, c'est l'inverse...

Ce que je propose : tu passes en Processing 3.2.3 (et tu ne pourras plus aller au dessus avec Windows 7) et tu ne mets pas P2D.

Bon courage ! ;)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 05, 2017, 08:12:43 pm
J'ai moi-même essayé de retirer P2D et voilà ce que j'obtiens en PJ.
On note deux choses :
1°) C'est coupé en deux
2°) On a des courbes Beziers cassées (horreur !!  :o)

Donc, c'est clair : il faut P2D !
C'est absolument indispensable au fonctionnement des programmes Processing, que ce soit Locodrome ou le mien.

Maintenant :
Comment faire marcher chez toi   AVEC  P2D ?

A suivre

Nota : tu as dû bricoler quelque chose, puisque toi, tu as affiché aussi les points (pour le suivi des locos). Bizarre.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 10:14:25 am
Bonjour,
Un petit point de situation sur mon Pb:
Tout d'abord Denis je suis désolé pour les courbes Bezier..!

1) pour le "renderer" P2D je pense que mon problème vient de ma carte graphique qui ne doit pas être compatible OpenGL.
2) je n'ai pas encore trouvé de site pour telecharger la version  3.2.3 de Processing qui effectivement semble être une solution
3) pour l'affichage des points j'ai simplement cliqué sur le bouton P du TCO donc je ne trouve pas cela bizarre
4) le graphe du TCO semble effectivement coupé en 2 mais cela provient à mon avis du rendu des "PaveArc" et "PaveArcN" pour lesquels je n'ai pas encore analysé tous les paramètres

5) je suis un peu le forum sur le programme de TCO de Denis (que je trouve excellent). Je n'ai pas de Pb avec les programmes sur les essais de cube, mais effectivement le rendu pour le TCO V4 me pose problème (affichage long et mauvais rendu des courbes)

 En tout cas encore merci  pour votre aide.

Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 06, 2017, 10:47:33 am

Citer
2) je n'ai pas encore trouvé de site pour telecharger la version  3.2.3 de Processing qui effectivement semble être un solution

Tout simplement ici www.processing.org (http://www.processing.org)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 10:52:52 am
Désolé mais je ne vois ou est la version 3.2.3.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 11:17:08 am
Désolé, Dominique, mais la 3.2.3 n'est plus disponible sur le site de Processing.
Je propose :
http://filehippo.com/fr/download_processing/tech/71955/ (http://filehippo.com/fr/download_processing/tech/71955/), avec Processing 3.2.3 pour Windows en 32 bits.

A noter pour frdechaume que Processing ne s'installe pas, au sens où on l'entend.
Dit autrement, pour changer vraiment de version, il faut :
1°) dezipper et installer sous C:\Program Files\Processing

2°) Dans la direcory Processing, pour l'instant, j'ai :
processing-3.2.3.old
processing-3.2.4.old
processing-3.3-windows64

Donc : la 3.2.3 que j'ai renommé en ".old", la version 3.2.4, également renommée en ".old" et la version sous laquelle je travaille actuellement, la 3.3.

3°) En renommant en ".old", je casse le lien entre les programmes ".pde" qui ne fonctionnent donc plus (c'est voulu).
Puis je recrée le lien avec la version que je veux utiliser en prenat mon ".pde" et "ouvrir avec" et je vais chercher "processing.exe" dans la bonne directory.
Le lien remarche donc.
Ne pas oublier non plus de cocher la case "toujours ouvrir avec" en passant.

4°) On est sûr que l'on travaille avec la bonne version en ouvrant le programme que l'on veut (p. ex locodrome) et dans l'en-tête, la version de processing apparaît.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 11:47:26 am
Merci Denis pour le lien mais je suis en 64bits, peut être as tu le lien pour cette version car je ne trouve pas.

Pour les différentes versions j'ai un dossier différent pour chaque version et pour leur utilisation je fais bien attention à la version affichée dans l’en-tête.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 11:57:23 am
http://patreuh.blogspot.fr/2017/01/download-processing-323-64-bit-2017.html (http://patreuh.blogspot.fr/2017/01/download-processing-323-64-bit-2017.html)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 12:07:21 pm
Merci, mais le téléchargement à partir du site du lien renvoi à la version 3.3
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: gerard31 le mars 06, 2017, 02:20:24 pm
Bonjour

Je peux éventuellement vous envoyer Processing 3.2.3 en Windows 64 bits mais je n'ai pas trouver ou vu le moyen de joindre le fichier en MP.

Amitiés,

Gérard
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 02:27:18 pm
J'ai aussi la version qu'il te faut (116 Mo), via le site grosfichiers, mais j'ai besoin de ton adresse mail...
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 02:27:59 pm
Merci Gérard
Denis ma proposé le fichier par email.
Je te le demanderai si il y a un Pb avec Denis
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 02:31:19 pm
J'ai aussi la version qu'il te faut (116 Mo), via le site grosfichiers, mais j'ai besoin de ton adresse mail...

OK Denis
Je t'ai fait une réponse par Email
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 02:45:26 pm
Merci aussi Gerard, c'est sympa.  ;)
J'espère que c'est la solution...
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 03:23:31 pm
Merci Denis
J'ai pu extraire ton dernier fichier. Mais malheureusement ce n'est pas encore la solution.
J'arrive au même résultat que précédemment si ce n'est que les courbes sont mieux dessinées mais toujours pas dans le bon sens ainsi que les aiguilles.

Je crois que je vais approfondir ma recherche du coté de ma carte graphique.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 03:28:17 pm
De rien...

Je ne pense pas que ça vienne de la carte graphique et il faut que ça marche AVEC P2D.

Tu as essayé ?

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 03:42:08 pm
MERCI Denis
Cela marche,
 Oh le nul que je suis...j'avais oublié de remettre "P2D" dans le size.
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 04:12:44 pm
Résumé des épisodes précédents :

1°) Le programme de Pierre fonctionne parfaitement, tel quel. Ouf !!
2°) P2D est obligatoire
3°) Sous Windows 7 64 bits, apparemment, on ne peut pas dépasser la version 3.2.3 de Processing, mais il faut être à la bonne version de java (8 update 121 ?)

Maintenant, je serais pour essayer la version 3.3, maintenant que java est au top. Tu seras alors dans le même cas que moi avec Windows 10.

Allez, courage !  ;)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: frdechaume le mars 06, 2017, 04:53:54 pm
Je viens d'essayer avec Processing V3.3 et cela...................................................................... marche aussi.
Bravo Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 06, 2017, 05:31:31 pm
De rien, c'est normal  ;)

Donc, on est dans une situation correcte vu de Windows (je ne sais pas pour Mac) :

1°) P2D obligatoire maintenant (depuis Processing 3.2.4) dans TOUS les programmes Processing.
2°) Il faut que java soit bien à jour. En fait, c'était la vraie origine du problème.

Il faut aussi remercier Pierre pour son programme et Gérard31 qui avait aussi gardé les anciennes versions de Processing (une bonne idée).  ;D
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 06, 2017, 06:05:26 pm
Sur mon Mac, la version Java est celle d'Apple, donc pas celle d'Oracle :
Java(TM) SE Runtime Environment (build 1.6.0)

Les programmes de Pierre tournent parfaitement et apparemment ceux de Denis aussi.

Je suppose que Processing intègre sont propre Java pour cela (ce serait bien raisonnable !)

Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 16, 2017, 05:57:31 pm
Je vais ici reprendre l'exemple de la mise en oeuvre du gestionnaire de Pierre dans mon réseau.

La description que je vais faire est et sera complétée par mon autre fil http://forum.locoduino.org/index.php?topic=290.0 (http://forum.locoduino.org/index.php?topic=290.0) consacré à mon projet global.

Une petite introduction est cependant nécessaire : Lorsque j'ai commencé la construction de mon réseau, j'étais loin de comprendre comment j'allais arriver à réaliser le gestionnaire. J'ai donc commencé par la réalisation d'un module de traction, puis d'un module de commandes d'aiguilles puis d'un module TCO qui gère les occupations  et les aiguilles. Le gestionnaire était ptévu sous la forme d'un Arduino Due relié aux autres (tous des Arduino Mega) via un bus CAN.

Avec ces modules je peux faire tourner mes trains manuellement sans sécurité (sans cantonnement), sans signaux, sans itinéraires.

Mon gestionnaire a commencé par intégrer un module graphique qui sert à visualiser des tas de choses qui me servent à comprendre où je vais !
Il y  en a un exemple au début de ce fil, lorsque j'ai intégré les zones selon Pierre.

Après le 4ème article du gestionnaire de Pierre, j'ai donc décidé d'intégrer la totalité des ressources qui sont permises, tout simplement en partant de son exemple du Locodrome et en y greffant mes zones, mes aiguilles, mes signaux, mes itinéraires :

Pour les zones, voici un exemple de classe dérivée de la classe de base Zone :

// 6 sortie GC Hor (pair=7, impair=5+aiguilleNdevié=4)
class Z6 : public Zone {
public:
  Z6(int n,Signal* sp,Signal* si):Zone(n,sp,si) {}// constructeur
  virtual Zone* suivantePaire();
  virtual Zone* suivanteImpaire();
  virtual void actions();
  virtual void desactions();
};

J'en ai 47 comme ça, toutes (presque) identiques (parfois sans les methodes actions() et desaction()) !

Pour les signaux, voici quelques exemples de classes dérivées :

class S5:public SemaphoreBAL {
public:
  S5(int n):SemaphoreBAL(n) {} // constructeur mini
  virtual Signal* suivant();
  virtual Signal* precedent();
  virtual boolean cantonOccupe();
};

class CRR3:public CarreAvertissementRappelRalentissement {
public:
  CRR3(int n):CarreAvertissementRappelRalentissement(n) {} // constructeur mini
  virtual Signal* suivant();
  virtual Signal* precedent();
  virtual boolean ralentissement30();
};

class CV1:public CarreViolet {
public:
  CV1(int n):CarreViolet(n) {} // constructeur mini
  virtual Signal* suivant();
  virtual Signal* precedent();
};

J'en ai 30 comme ça, avec pas mal de types de signaux, ce qui n'était pas évident vu mes lacunes en signalisation SNCF (j'ai appris depuis) !!

Pour les itinéraires, voici un exemple de classe dérivée :

//X27a30 = de z27 à z30 avec Carré C1
class X27a30:public Itineraire {
public:
  X27a30(int n):Itineraire(n) {}
  virtual boolean formable();
  virtual void former();
  virtual boolean deformable();
  virtual void deformer();
  virtual void tracer(boolean b);
};

J'en ai 43 comme ça, toutes identiques (seul le nom change)  !

Ensuite je déclare les objets réels :

// declarations des objets réels

SignalBAL* s1=new S1(0);
SignalBAL* s2=new S2(1);
SignalBAL* s3=new S3(2);
SignalBAL* sr4=new SR4(3);
SignalBAL* s5=new S5(4);
SignalBAL* s6=new S6(5);
SignalBAL* s7=new S7(6);
SignalBAL* sr8=new SR8(7);
Signal* c1=new C1(8);
Signal* c2=new C2(9);
Signal* c4=new C4(10);
Signal* crr2=new CRR2(11);
Signal* crr4=new CRR4(12);
Signal* c3=new C3(13);
Signal* c5=new C5(14);
Signal* c6=new C6(15);
Signal* c7=new C7(16);
Signal* c8=new C8(17);
Signal* cr1=new CR1(18);
Signal* cr2=new CR2(19);
Signal* crr1=new CRR1(20);
Signal* crr3=new CRR3(21);
Signal* cv1=new CV1(22);
Signal* cv2=new CV2(23);
Signal* cv3=new CV3(24);
Signal* cv4=new CV4(25);
Signal* cv5=new CV5(26);
Signal* cv6=new CV6(27);
Signal* cv7=new CV7(28);
Signal* cv8=new CV6(29);

#define MaxSignal 30

Signal* tableSignaux[MaxSignal] {s1,s2,s3,sr4,s5,s6,s7,sr8,c1,c2,c4,crr2,crr4,c3,c5,c6,
  c7,c8,cr1,cr2,crr1,crr3,cv1,cv2,cv3,cv4,cv5,cv6,cv7,cv8}; // la table des signaux

/////////////////// DECLARATIONS des ZONES ////////////////////

Zone* z0=new Z0(0,NULL,NULL); // n° / signal-pair / signal-impair
Zone* z1=new Z1(1,NULL,NULL);
Zone* z2=new Z2(2,NULL,NULL);
Zone* z3=new Z3(3,NULL,NULL);
Zone* z4=new Z4(4,c7,NULL);
Zone* z5=new Z5(5,c6,NULL);
Zone* z6=new Z6(6,NULL,NULL);
Zone* z7=new Z7(7,s5,NULL);
Zone* z8=new Z8(8,s6,s5);
Zone* z9=new Z9(9,s7,s6);
Zone* z10=new Z10(10,sr8,s7);
Zone* z11=new Z11(11,crr4,sr8);
Zone* z12=new Z12(12,NULL,NULL);
Zone* z13=new Z13(13,c4,c8); // c8 ou NULL ?
Zone* z14=new Z14(14,c5,c5); // c5 ou NULL ?
Zone* z15=new Z15(15,NULL,NULL);
Zone* z16=new Z16(16,crr3,cv5); // cv5 ou NULL ?
Zone* z17=new Z17(17,NULL,NULL);
Zone* z18=new Z18(18,NULL,cv3);
Zone* z19=new Z19(19,NULL,NULL);
Zone* z20=new Z20(20,NULL,NULL);
Zone* z21=new Z21(21,NULL,NULL);
Zone* z22=new Z22(22,NULL,cr1);
Zone* z23=new Z23(23,NULL,cr2);
Zone* z24=new Z24(24,NULL,NULL);
Zone* z25=new Z25(25,NULL,crr2);
Zone* z26=new Z26(26,NULL,NULL);
Zone* z27=new Z27(27,NULL,c1);
Zone* z28=new Z28(28,cv1,c2);
Zone* z29=new Z29(29,NULL,NULL);
Zone* z30=new Z30(30,cv6,s1);
Zone* z31=new Z31(31,s1,s2);
Zone* z32=new Z32(32,s2,s3);
Zone* z33=new Z33(33,s3,sr4);
Zone* z34=new Z34(34,sr4,crr1);
Zone* z35=new Z35(35,NULL,NULL);
Zone* z36=new Z36(36,NULL,cv2);
Zone* z37=new Z37(37,cv7,cv8);
Zone* z38=new Z38(38,cv4,NULL);
Zone* z39=new Z39(39,NULL,NULL);
Zone* z40=new Z40(40,NULL,NULL);
Zone* z41=new Z41(41,NULL,NULL);
Zone* z42=new Z42(42,NULL,NULL);
Zone* z43=new Z43(43,NULL,NULL);
Zone* z44=new Z44(44,NULL,NULL);
Zone* z45=new Z45(45,NULL,NULL);
Zone* z46=new Z46(46,NULL,NULL);

#define MaxZone  47

Zone* tableZones[MaxZone]=  {   // liste des pointeurs de zone pour la retrosignalisation
    z0, z1, z2, z3, z4, z5, z6, z7, z8, z9, z10, z11, z12, z13, z14, z15,
    z16, z17, z18, z19, z20, z21, z22, z23, z24, z25, z26, z27, z28, z29, z30,
    z31, z32, z33, z34, z35, z36, z37, z38, z39, z40, z41, z42, z43, z44, z45, z46  };

/////////////////// DECLARATIONS des AIGUILLES //////////////////// 
 
Aiguille* a0=new Aiguille(0,z26);  //dans z26
Aiguille* a1=new Aiguille(1,z26);  //dans z26
Aiguille* a2=new Aiguille(2,z15);  //dans z15
Aiguille* a3=new Aiguille(3,z44);  //dans z44
Aiguille* a4=new Aiguille(4,z15);  //dans z15
Aiguille* a5=new Aiguille(5,z42);  //dans z42
Aiguille* a6=new Aiguille(6,z43);  //dans z43
Aiguille* a7=new Aiguille(7,z12);  //dans z12
Aiguille* a8=new Aiguille(8,z12);  //dans z12
Aiguille* a9=new Aiguille(9,z29);  //dans z29
Aiguille* a10=new Aiguille(10,z38); //dans z38
Aiguille* a11=new Aiguille(11,z29); //dans z29
Aiguille* a12=new Aiguille(12,z38); //dans z38
Aiguille* a13=new Aiguille(13,z39); //dans z39
Aiguille* a14=new Aiguille(14,z35); //dans z35
Aiguille* a15=new Aiguille(15,z2); //dans z2
Aiguille* a16=new Aiguille(16,z6); //dans z6
Aiguille* a17=new Aiguille(17,z17); //dans z17
Aiguille* a18=new Aiguille(18,z24); //dans z24
Aiguille* a19=new Aiguille(19,z45); //dans z45 coté pair
Aiguille* a20=new Aiguille(20,z46); //dans z46 coté impair

#define MaxAig  21

Aiguille* tableAiguilles[MaxAig]= {
  a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11,
  a12, a13, a14, a15, a16, a17, a18, a19, a20 };

/////////////////

Itineraire *x4a7=new X4a7(0);
Itineraire *x5a7=new X5a7(1);
Itineraire *x7a11=new X7a11(2);
Itineraire *x11a13=new X11a13(3);
Itineraire *x11a14=new X11a14(4);
Itineraire *x13a16=new X13a16(5);
Itineraire *x14a16=new X14a16(6);
Itineraire *x16a4=new X16a4(7);
Itineraire *x16a5=new X16a5(8);
Itineraire *x22a25=new X22a25(9);
Itineraire *x23a25=new X23a25(10);
Itineraire *x25a27=new X25a27(11);
Itineraire *x25a28=new X25a28(12);
Itineraire *x27a30=new X27a30(13);
Itineraire *x28a30=new X28a30(14);
Itineraire *x30a34=new X30a34(15);
Itineraire *x34a22=new X34a22(16);
Itineraire *x34a23=new X34a23(17);
Itineraire *x28a36=new X28a36(18);
Itineraire *x36a28=new X36a28(19);
Itineraire *x14a18=new X14a18(20);
Itineraire *x18a14=new X18a14(21);
Itineraire *x14a38=new X14a38(22);
Itineraire *x38a14=new X38a14(23);
Itineraire *x13a30=new X13a30(24);
Itineraire *x14a30=new X14a30(25);
Itineraire *x25a13=new X25a13(26);
Itineraire *x25a14=new X25a14(27);
Itineraire *x14a11=new X14a11(28);
Itineraire *x13a11=new X13a11(29);
Itineraire *x16a13=new X16a13(30);
Itineraire *x16a14=new X16a14(31);
Itineraire *x30a27=new X30a27(32);
Itineraire *x30a28=new X30a28(33);
Itineraire *x4a3=new X4a3(34);
Itineraire *x3a4=new X3a4(35);
Itineraire *x3a1=new X3a1(36);
Itineraire *x30a13=new X30a13(37);
Itineraire *x30a14=new X30a14(38);
Itineraire *x37a18=new X37a18(39);
Itineraire *x18a37=new X18a37(40);
Itineraire *x37a38=new X37a38(41);
Itineraire *x38a37=new X38a37(42);

#define MaxItineraire 43

Itineraire* tableItineraires[MaxItineraire] {
    x4a7,x5a7,x7a11,x11a13,x11a14,x13a16,x14a16,x16a4,x16a5,x22a25,
    x23a25,x25a27,x25a28,x27a30,x28a30,x30a34,x34a22,x34a23,x28a36,x36a28,
    x14a18,x18a14,x14a38,x38a14,x13a30,x14a30,x25a13,x25a14,x14a11,x13a11,
    x16a13,x16a14,x30a27,x30a28,x4a3,x3a4,x3a1,x30a13,x30a14,x37a18,x18a37,x37a38,x38a37}; // la table des itineraires pour tco

Les tableaux d'objets sont indispensables pour pouvoir ensuite accéder à leurs méthodes et variables à partir de leur numéro.

Jusque là c'est assez simple quand on a bien décortiqué son réseau et réalisé les coupures de zones et les points d'alimentation nécessaire, ce qui n'était pas tout à fait mon cas (je devrai faire quelques modifications).

A partir de là, maintenant, il faut définir les méthodes particuliers qui dépendent de la configuration du réseau (il faut un bon dessin !) :

Zone* Z12::suivantePaire() { return selonAiguille(a7,z13,selonAiguille(a6,NULL,z43)); }
Zone* Z12::suivanteImpaire() { return selonAiguille(a8,z11,selonAiguille(a11,NULL,z29)); } // !! changement de sens sur z30
void Z12::actions() { aubiner(crr4,c8,c6); }
void Z12::desactions() { detruire(x11a13,x13a11,x11a14,x14a11);detruire(x13a30,x30a13,x14a30,x30a14); }

Signal* CRR2::suivant() { return selonAiguille(a0,selonAiguille(a1,c1,selonAiguille(a3,NULL,c2)),selonAiguille(a2,NULL,selonAiguille(a4,c8,c4))); }
Signal* CRR2::precedent() { return selonAiguille(a18,cr1,cr2); }
boolean CRR2::ralentissement30() { return a1->deviee()?true:false; }

boolean X4a7::formable() { return libres(x4a7,x3a4,x4a3,x5a7) && libres(z6,z7,z39); }
void X4a7::former() { a16->directer(); a13->devier(); c7->ouvrir(); }
boolean X4a7::deformable() { return libres(z4,z6,z39); }
void X4a7::deformer() { c7->fermer(); }
void X4a7::tracer(boolean b) { trace(b,z4,z6,z39);z7->tracer(b); }

Ce qui fait encore un gros paquet de lignes de code, soit 600 lignes dans mon cas !!!

Au total, l'ensemble des définitions des objets dérivés, les déclarations d'objets réels et les méthodes particulières prennent 1950 lignes de code (dont quelques lignes de commentaires quand même). C'est un gros travail assez fastidieux, mais plein de copier-coller.

Ce qu'il faut mettre dans les méthodes particulières doit suivre un certain nombre de règles que j'ai notées au fur et à mesure. Je vous les donnerai dans une des suites de ce fil.

Maintenant que tout cela est fait, il faut le tester et corriger les anomalies.

Je dois dire que ces tests sont absolument nécessaires car, à ce stade de l'écriture des méthodes particulières des objets, on ne se rend pas bien compte si on bien codé ou pas.

En effet, il n'est pas toujours facile de savoir comment combiner les zones et les aiguilles, comment définir les itinéraires et le meilleur moyen est de simuler un passage de train et de regarder le comportement du gestionnaire.

Ce sera l'objet de la suite qui va suivre !!!

...
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 16, 2017, 08:58:23 pm
Bonsoir Dominique,

Ton avancée me plait beaucoup.

On vit "en direct" les déclarations pour transformer un locodrome avec 2 aiguilles en un vrai réseau, le tien.
Comme je le connais bien, je suis avec intérêt.

Bon courage !  ;D

Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 16, 2017, 10:56:58 pm
Merci Denis,

La suite va t'interesser !

Maintenant je vais aborder la méthode de tests et de mise au point des méthodes particulières des objets !!!

Vous avez remarqué que le Locodrome (V4) est fourni avec un programme écrit en Processsing. Ce programme communique, via un port série de votre ordinateur, avec un Arduino (Uno, Mega, etc..) dans lequel le Gestionnaire a été téléversé (ce qui suppose au préalable que le compilateur soit content :-)).

Ce n'est pas très difficile d'arriver à ce stade où le compilateur voit un "sans faute", quand on part bien du Gestionnaire (V4) et qu'on introduit progressivement tous les objets que j'ai présenté précédemment. Mon conseil est de vérifier très souvent et de corriger les erreurs au fur et à mesure.

Donc le programme Locodrome en Processing ressemble à cela :

(http://www.locoduino.org/local/cache-vignettes/L610xH270/tcobal4-77b35.png?1481449822)

Et le principe des échanges entre le Locodrome Processing et le Gestionnaire Arduino est assez simple :

Dans la série des onglets du programme Arduino (Composants.h, Constantes.h, Fonctions.h, Methodes.h, Signaux.h, SignauxBal.h, TCO.h, Train.h), on remarque qu'il y en a un qui s'appelle TCO.h et qui contient cette fonction tco(byte c,byte x,byte n).

// commandes du TCO, des aiguilles et des signaux
// ne sert que pour l'interface avec le TCO virtuel

/////////////////////////////////////////////////////////////////////////////
enum  {CODE_AIGUILLE,CODE_ZONE,CODE_SIGNAL,CODE_CARRE,
       CODE_BOUTON,CODE_BOUTON_CLI,CODE_ERREUR,CODE_INFO,CODE_CAB,CODE_MEM,CODE_TRAIN};

void tco(byte c,byte x,byte n) { byte buf[3]; // code numero info
  if (TCO) { buf[0]=c; buf[1]=n; buf[2]=x; Serial.write(buf,3); return; }
  switch(c) { // mise en forme pour affichage sur le moniteur serie
    case CODE_AIGUILLE:   Serial.print('A'); break; // manoeuvre aiguille
    case CODE_ZONE:       Serial.print('Z'); break; // coloration zone (sur tco)
    case CODE_SIGNAL:     Serial.print('S'); break; // manoeuvre signal (semaphore)
    case CODE_CARRE:      Serial.print('C'); break; // manoeuvre signal (carre)
    case CODE_BOUTON:     Serial.print('B'); break; // coloration bouton (sur tco)
    case CODE_BOUTON_CLI: Serial.print('b'); break; // coloration bouton clignotant (sur tco)
    case CODE_ERREUR:     Serial.print('E'); break; // erreur
    case CODE_INFO:       Serial.print('I'); break; // info
    case CODE_CAB:        Serial.print('s'); break; // cabsignal
    case CODE_MEM:        Serial.print('M'); break; // memoire RAM disponible (borne a 4095)
    case CODE_TRAIN:        Serial.print('T'); break; // suivi des trains
    default:              Serial.print('?');   
  }
  Serial.print(n);
  if (c==CODE_ERREUR || c==CODE_INFO) return;
  Serial.print('=');
  if (c==CODE_AIGUILLE) { if (x) Serial.print('/'); else Serial.print('|'); }
  else { //Serial.println(x);
    switch(x) { // mise en forme des couleurs
      case COULEUR_GRISE:   Serial.print('G'); break;
      case COULEUR_ROUGE:   Serial.print('R'); break;
      case COULEUR_BLANCHE: Serial.print('B'); break;
      case COULEUR_JAUNE:   Serial.print('J'); break;
      case COULEUR_VERTE:   Serial.print('V'); break;
      case COULEUR_ROSE:    Serial.print('r'); break;
      default:              Serial.print('?');   
    }
  }
  Serial.print(' ');
}

Cette fonction tco() est appelée à différents endroits du code Arduino, dans les méthodes:

Et seulement dans ces méthodes : cela correspond aux ordres qui seraient envoyés vers les organes de commande (visualisation sur un TCO, manoeuvre des signaux et des aiguilles via la formation des itinéraires).

Si on regarde maintenant la fonction tco() qui reçoit 3 arguments :

On voit que cette fonction se contente d'envoyer seulement quelques caractère "imprimables" : A pour aiguille, Z pour Zone, etc... puis un numéro, puis un code de couleur G pour gris, R pour rouge, etc...

C'est simple et cela permet au programme Locodrome Processing de réagir en affichant des changements de couleur de zone (rouge = occupée, grise = libérée, blanche = réservée pour un itinéraire), des basculements d'aiguilles, des couleurs de signaux.

Dans l'autre sens, il faut bien que le Gestionnaire réagisse aux événements du réseau virtuel simulé par le Locodrome :

Je vais laisser de coté la gestion des trains pour le moment, histoire de ne pas trop compliquer la compréhension de l'exposé, mais sachez que le Gestionnaire a quand même besoin de connaître le sens de déplacement des trains pour appliquer les règles d'itinéraires.

Pour réagir, le Gestionnaire fait une traitement dans sa loop() des caractères reçus via le port série :

void loop() { Itineraire* it; char code=0;
  if (Serial.available()>=1) { // test si retrosignalisation ou commande
    code=Serial.read();
    if (!TCO) { Serial.println(); Serial.print(code); Serial.print(':'); Serial.print(' '); }
    if (code=='X') { // commande de reinitialisation
        reset();
    }
    if (code>='0' && code <='8') { // commande d'itineraire
      it=tableItineraires[code-'0'];
      if (it->enAttente()) it->effacer();   else // destruction
      if (it->libre())     it->formation(); else // essai de formation
      if (it->forme())     it->destruction();    // essai de destruction
      if (!TCO && it->enAttente()) Serial.print('m');
    }
    if (code>='A' && code <='F') { // occupation zone (retrosignalisation)
       tableZones[code-'A']->occuper();
     }
    if (code>='a' && code <='f') { // liberation zone (retrosignalisation)
      tableZones[code-'a']->liberer();
    }
    if (code=='s') train1->invSens();
    if (code=='S') train2->invSens();
    code=0; return;
  }
 
  // test itineraires en attente
  for (int i=0; i<MaxItineraire; i++) {
    it=tableItineraires[i];
    if (it->enAttente()) {
      if (!TCO && it->formable()) { Serial.println('('); Serial.println(i); Serial.print(')'); Serial.print(':'); Serial.print(' '); }
      if (it->formable()) it->formation();
    }
  }
} // fin loop

C'est impressionnant de concision !

Alors la vraie question vous saute aux yeux : ces traitements des échanges pour le Locodrome ne marchent plus pour mon réseau car j'ai 47 zones, 30 signaux, 21 aiguilles, 43 itinéraires !

Pas de panique !

Je n'ai pas changé la présentation des messages dans le sens Gestionnaire -> Locodrome.
Par contre, dans le sens Locodrome -> Gestionnaire, au lieu d'utiliser une lettre de l'alphabet pour chaque d'objet (il n'y en aurait pas assez), j'ai utilisé un simple entier avec la convention suivante :

Ce que j'ai matérialisé dans cette fonction :

void execCode(int c) {
  int code = c;
  Itineraire* it;
  /////////////////  TRAITEMENT ITINERAIRE ////////////
  if (code>=0 && code <MaxItineraire) { // commande d'itineraire
    it=tableItineraires[code];
    if (it->enAttente()) it->effacer();   else // destruction
    if (it->libre())     it->formation(); else // essai de formation
    if (it->forme())     it->destruction();    // essai de destruction
    if (!TCO && it->enAttente()) Serial.print('m');
  }
  /////////////////  TRAITEMENT OCCUPATION ////////////
  if (code>=100 && code <100+MaxZone) { // occupation zone (retrosignalisation)
    tableZones[code-100]->occuper();
  }
  /////////////////  TRAITEMENT LIBERATION ////////////
  if (code>=200 && code <200+MaxZone) { // liberation zone (retrosignalisation)
    tableZones[code-200]->liberer();
  }
  ///////////////// INVERSION DE SENS ////////////
  if (code==300) train1->invSens();
  if (code==301) train2->invSens();
  return;
}

Mais vous avez remarqué aussi une autre GROS problème : le programme Locodrome en Processing ne correspond plus graphiquement à mon réseau

Mais comme Pierre avait tout prévu, on peut tester le gestionnaire sans le Locodrome en Processing, simplement avec les affichages dans le moniteur : c'est beaucoup moins "parlant" mais c'est utile quand même.

Voici un exemple de scenario de simulation fait entièrement avec le moniteur de l'IDE Arduino :

0 A13=/R E46Z4= Z6= Z39= Z7= B0=B
4 A7=/R A6=/R C11=? C6=? Z11= Z12= Z43= Z14= B4=B
104 E202Z4=
106 E46T6=? Z6=
139 T39=? Z39=
107 T7=? Z7=
204 T4=G Z4=
206 Z4= Z6= B0=G T6=G Z6=
239 T39=G Z39=
108 C3=V T8=? Z8=
207 T7=G Z7=
109 C4=V T9=? Z9=
208 C3=B T8=G Z8=
110 C5=V T10=? Z10=
209 C4=B C3=R T9=G Z9=
111 C6=V T11=? Z11=
210 C5=B C4=R T10=G Z10=
112 C11=? T12=? Z12=
143 T43=? Z43=
114 T14=? Z14=
211 C6=B C5=R T11=G Z11=
212 Z11= Z12= B4=G T12=G Z12=
243 T43=G Z43=
6 A5=/R A4=/R C13=B Z42= Z15= Z16= B6=B

La première ligne "0 A13=/R E46Z4= Z6= Z39= Z7= B0=B" signifie :

Un peu plus loin "209 C4=B C3=R T9=G Z9=" signifie :

Bon c'est fastidieux, il faut le reconnaitre !

Il faut tout de même trouver une solution plus graphique : il y en a deux possibles :


La réponse est les deux mon général !

C'est ce que je vais vous présenter dans la suite ...

Stay tuned !
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 16, 2017, 11:43:14 pm
Commençons par le moteur graphique intégré au gestionnaire :

J'ai assemblé un Arduino Due avec un écran graphique tactile 5 pouces et un shield adapté.

Voici une image et une video du résultat obtenu avec une simulation de circulation de trains envoyant les codes présentés précédemment via le port série :

(http://forum.locoduino.org/index.php?action=dlattach;topic=166.0;attach=778;image)
https://player.vimeo.com/video/208743931 (https://player.vimeo.com/video/208743931)

Cet affichage graphique montre la topographie du réseau, les aiguilles et les zones, avec leur différents états, mais pas encore les signaux.
Ce programme est ajouté au gestionnaire et écrit en langage Arduino, en utilisant la bibliothèque UTFT.
On voit sur la vidéo que les affichages ne sont pas instantanés. J'ai ajouté un onglet "Graphiques.h" qui contient 1350 lignes de code !

Mais la représentation des aiguilles et des zones, les formations et destructions d'itinéraires, les occupations et libérations sont maintenant parfaites : les tests m'ont permis de mettre au point les methodes des zones et des itinéraires. Pour les signaux cela reste à faire.

Ce n'est pas un TCO utilisable pour le fonctionnement du réseau, mais seulement pour la mise au point.
Sa description sera donnée plus tard.

Ensuite, voici la version Locodrome adaptée à mon réseau, mais c'est Pierre qui l'a faite ! Je n'ai aucun mérite !

(http://forum.locoduino.org/index.php?action=dlattach;topic=166.0;attach=782;image)

Pour le moment ce Locodrome ne communique pas  encore avec le Gestionnaire. Mais c'est autrement plus sympathique.

Je vous en dirai plus un peu plus tard car cela ouvre des perspectives et on peut imaginer tout le potentiel des travaux de Denis qui développe un générateur de réseau !

A suire...
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 17, 2017, 01:38:12 pm
Merci Dominique pour ces encouragements.
Je prépare un scoop (à ma connaissance, une fonctionnalité inédite) et je peaufine en ce moment la plaque tournante.

La suite va être moins visuelle, parce que, justement, ça consistera à automatiser ce que tu fais en ce moment !! ;)
Ce qui serait bien, c'est que tu puisses regrouper la totalité des spécificités de ton réseau dans un seul onglet de l'Arduino (qui s'appelerait specifs.h).

Ceux qui ont bien suivi ce que j'ai fait dans TCO comprendront que l'onglet "Routes" de mon TCO en Processing sert justement à créer les spécificités d'un réseau.
Pour l'instant, ça crée les spécifs du système de Jean-Luc, vouée à gérer les itinéraires (et cette automatisation fonctionne parfaitement).
Par la suite, justement, cet onglet devra servir à créer les spécificités d'un "locodrome" (terme générique), basé sur les préceptes de Pierre.

Mais tu avances bien, c'est motivant.  ;D

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 17, 2017, 03:01:59 pm
Définir toutes les méthodes dans un fichier specif.h ne va pas être chose facile  >:( >:( >:(

Pour arriver à modéliser un réseau jusqu'au point où le Gestionnaire pourra exercer ses différentes méthodes, j'ai rassemblé un certain nombre de réflexions et de règles à observer, qui sont probablement évidentes pour les modélistes baignant la dedans depuis longtemps et connaissant bien le fonctionnement de la SNCF.

Je vous soumets donc le fruit de mes cogitations qui s'appliquent à mon tracé de réseau représenté sur cette image :
(http://forum.locoduino.org/index.php?action=dlattach;topic=166.0;attach=784;image)

Pour utiliser le Gestionnaire il faut se conformer aux règles de la SNCF.

Après le tracé du réseau il faut faire le découpage en zones (ne pas confondre avec les cantons).
   
La topographie du réseau (sa modélisation) est décrite dans les méthodes suivantePaire(), suivanteImpaire() des zones qui définissent les connexions entre zones en fonction des positions des aiguilles.

Le découpage en zones permet ensuite de délfinir les signaux et les itinéraires.
   
La formation d'un itinéraire positionne les aiguilles et les signaux et autorise donc le passage du train.
   
      
Le placement des signaux commence par les sémaphore de BAL sur les trajets (cantons) sans aiguilles:
   
Le placement des signaux continue par les carrés avant aiguilles (ou croisements, TJDs, etc..):
   
Le placement des signaux continue enfin par les signaux de manoeuvre:
   
Une fois que les signaux sont placés et les itinéraires définis, on peut programmer les methodes paticulières

1) En sachant que les methodes appelées par la rétrosignalisation dans la LOOP  sont les commandes venant de la rétrosignalisation:

2) Les commandes des signaux (appellées par les commandes d'itinéraires, depuis le TCO) sont :

3) Les commandes des Itinéraires (venant du TCO) sont:

4) Les commandes d'aiguilles:

Règles concernant le découpage en zones

Sur une zone il ne peut y avoir qu’un seul train à la fois, en conséquence s’il peut y avoir deux trains (ou plus) sur une zone sans risques de collision alors la zone doit être scindé en deux zones (ou plus).

Un canton est une suite de zones (avec ou sans aiguille) entre deux signaux pouvant présenter le sémaphore (BAL)
Par exemple Z16-Z4 est un canton si on fait du BAL, sinon c’est deux zones !
Mais comme un train doit tenir entièrement dans la zone z4 (car c'est une gare cachée) la zone z16 doit pouvoir être libre quand un train occupe z4, pour permettre à un autre train d'entrer dans la zone z5. Donc ici, c'est bien 2 zones.

Un canton ne peut être libre que si toutes les zones sont libres. (il ne suffit pas que le seule zone suivante soit libre, sauf si le canton n’a qu’une seule zone)


Règles concernant les signaux

La méthode suivant() d’un signal concerne le signal suivant dans le sens de la marche du train

Un signal est aubiné par l’occupation de la zone suivante (celle tout juste après le signal, quelques mètres après le signal à la SNCF) dans la methode actions() de la zone.
Normalement on ne devrait aubiner que le signal ouvert (s’il existe) mais on peut aussi aubiner tous les signaux autour à la fois, car ils sont déjà fermés.
Lors du parcours d’un itinéraire le signal est aubiné lors de l’occupation de la zone qui suit la zone d’origine (regle précédente)

REGLE : desaubiner() et cantonOccupe() ne servent que pour les signaux de BAL
Dans le cas de signaux de BAL (pouvant présenter le sémaphore) le signal est désaubiné  à la libération de toute les zones qui suivent le signal (souvent il n’y en a qu’une seule, dans ce cas c’est la même zone qui aubine et désaubine le signal de BAL).

REGLE : desaction() ne sert que pour les signaux avec BAL, c’est inutile pour les autres

REGLE : Le ralentissement se fait par un signal d’avertissement (ou de ralentissement)


Règles concernant les itinéraires

Un itinéraire a une zone d’origine et une zone de destination (généralement sans aiguilles),. Entre les deux il peut y avoir plusieurs zones avec ou sans aiguilles.
En partant de la zone d’origine vers la zone de destination toutes les zones traversées font partie de l’itinéraire (+celle origine et celle de destination).

L’itinéraire est détruit lors de la libération de l‘avant dernière zone !
En transit rigide, la zone qui détruit un itinéraire est l'avant-dernière zone juste avant la zone de destination.
Exemple, l'itinéraire z16-z17-z4 est détruit quand un train est entièrement entré dans la zone z4 et a donc libéré la zone d'aiguille z17.
Ainsi, un nouvel itinéraire z16-z17-z5 peut être formé.

Le gestionnaire ne traite pas des aiguilles prises en talon, le suivant de C1 c’est S1 ! (cela ne sert pas dans le gestionnaire contrairement aux zones)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 19, 2017, 07:18:01 pm
Ce dimanche est à marquer d'un pierre blanche  ;D

Je viens de brancher ce mini-TCO, construit sur un Due avec un écran 5" et qui contient à la fois :

(http://forum.locoduino.org/index.php?action=dlattach;topic=166.0;attach=778;image)

Je mets sous tension et... miracle, tout marche nickel 8)

Les commandes d'aiguilles sont possible soit du TCO physique soit du TCO graphique (les lampes des positions s'allument en conséquence sur le TCO physique et la représentation de l'aiguille change sur le TCO graphique.

Les occupations et libérations sont parfaitement représentée.

Je m'attendais à ce que la surcharge graphique conduise à des pertes de messages... Mais non ! Vraiment balaise ce Due  >:(

Prochaines étapes : je remplace les commandes d'aiguilles par les boutons tactiles, qui font double emploi avec les clés du TCO physique, par des commandes d'itinéraires, les 20 à 24 itinéraires les plus pertinents avec formation ou mise en attente par les boutons tactles et destructions  automatique lors du passage des trains.

Vive le bus CAN et la souplesse qu'il permet, ainsi que sa fiabilité  ;)
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 19, 2017, 07:34:24 pm
YESSS !!!!!! ;D ;D ;D ;D ;D

Un grand bravo !
Je suis vraiment content pour toi.
Et ça montre à ceux qui en douteraient encore que le locodrome de Pierre est vraiment une belle invention.
Et qu'on peut l'adapter à n'importe quel réseau.

Sans compter ton TCO, tout petit, mais costaud ! 8) 8) 8)

Amicalement
Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 19, 2017, 09:02:35 pm
Merci Denis,

Ce n'est qu'une étape car j'ai 2 TJDs à remplacer par 4 aiguilles, mon TCO physique à modifier (le tracé des voies a légèrement changé), le contrôleur d'aiguilles à modifier, le module de traction à refaire complètement sur la base de DCC++ avec le Cab Signal pour piloter les trains à partir de la signalisation, et le module contrôleur de signaux à faire... puis le décor  :P

Ce module de traction présentera des trains virtuels "normalisés" vis à vis du Gestionnaire : les échanges concernant la vitesse seront en vitesse réelle.
Il assurera l'étalonnage des trains, et détectera la position des trains à la mise sous tension (voir http://forum.locoduino.org/index.php?topic=245.msg2928#msg2928 (http://forum.locoduino.org/index.php?topic=245.msg2928#msg2928)).

Grâce à DCC++, les paramètres des décodeurs de tout mon matériel roulant seront gérés dans une base de donnée pour permettre la mise en place et la suppression dynamique de trains vis à vis du Gestionnaire.

J'ai encore du pain sur la planche et ce sera décrit dans mon projet http://forum.locoduino.org/index.php?topic=290.0 (http://forum.locoduino.org/index.php?topic=290.0) mais seulement quand ce sera réalisé.

Patience !

Bien amicalement
Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 22, 2017, 07:03:08 pm
Bonjour Dominique,

J'ai résolu une partie de ton problème (la plus simple) :
Voici le programme locodrome original (l'ovale et 2 aiguilles) pour l'Arduino.
J'ai créé un onglet Specifs.h dans ce programme Arduino et j'y ai mis tout ce qui est spécifique à ce réseau.
C'était d'autant plus simple que Pierre avait tout bien groupé. Merci Pierre  ;)

Au passage, il faut aussi déplacer les #include du .ino dans cet onglet.

Et, pour finir, on met un #include "Specifs.h" dans l'onglet .ino, justement pour pouvoir accéder à tout ce qu'on vient de déplacer.

L'onglet que je viens de créer correspond au réseau locodrome original. C'est pour l'exemple.
Pour ton réseau, on crée un autre onglet "Specif.h"... spécifique à ton réseau.

Le programme Arduino reste le même, quel que soit le réseau : il n'y a que l'onglet "Specifs.h" qui change.  8)

Mais pourquoi est-ce important ?

Parce qu'un onglet "Specifs.h", finalement, c'est un simple fichier texte.
Et, un fichier texte, on sait le générer dans Processing.

C'est ce que j'ai fait avec un "Specifs.h" pour la description de réseau de Jean-Luc (voir le fil correspondant).
Il "suffit" de faire pareil avec la description type locodrome...
Bon, mais, ça, c'est mon problème. Là, effectivement, ça n'est plus simple, mais j'y arriverais.

yapuka  :P

Denis
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Dominique le mars 24, 2017, 11:11:26 pm
C'est un bon début  :D

Si tu arrives à génèrer (sous forme de texte) les lignes de programme des méthodes des objets, alors tu auras gagné !

Amicalement
Dominique
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le mars 25, 2017, 10:02:08 am
Bonjour Pierre,

Je n'y ai jamais bien réfléchi, mais les boucles de retournement posent-elles un problème pour le déplacement des trains sur le locodrome ?

Amicalement
Denis
Titre: Re : Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le mars 27, 2017, 05:32:26 pm
Je n'y ai jamais bien réfléchi, mais les boucles de retournement posent-elles un problème pour le déplacement des trains sur le locodrome ?

Bonjour

Sur la base du Locodrome je n'ai écrit que deux TCOs, le mien et celui de Dominique, ni l'un ni l'autre n'ont de boucles de retournement, donc je n'ai pas trop réfléchi au problème.

Bien que revenant à peine de vacances à la montagne, j'ai écrit un "démonstrateur" pour faire des tests dans le cas le plus simple. Il reste encore pas mal de petits problèmes techniques.

Amicalement

Pierre
 
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: Pierre59 le avril 07, 2017, 11:54:37 am

Bonjour

Voila j'ai résolu (assez difficilement) les problèmes techniques relatifs au fonctionnement d'une raquette (boucle de retournement) avec les TCOs en Processing. Dans la foulée j'ai rajouté une deuxième raquette.

Le programme (en Processing) est "sauvagement" dérivé du TCO de Dominique. Les deux gros changements sont d'une part le dessin du réseau et d'autre part l'introduction d'un booléen (inv) pour inverser le sens du train (loco et rame) quand c'est nécessaire, ce booléen est indirectement positionné par les méthodes suivantPair() et suivantImpair() des trois zones.

Le programme fonctionnel est fourni ci-dessous, voir le fichier "Notice" pour le fonctionnement.

Amusez vous bien.

Pierre
Titre: Re : Modélisation logicielle d'un réseau - le système de Pierre59
Posté par: DDEFF le avril 07, 2017, 12:56:47 pm
Hallucinant !! :o :o

J'ai aussi commencé à décortiquer le programme version "réseau de Dominique".
C'est impressionnant, dense et redoutablement efficace.
On peut même dételer les locos !
Très bonne idée aussi : les noms en tout petit dans les voies elles-mêmes, affichables ou non.

Un grand Bravo !! ;D ;D ;D

Amicalement
Denis