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

[DDEFF]

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

Denis

[Dominique]

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

[Dominique]

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

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

La construction pas à pas des objets m'amène à :

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.

[Dominique]

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

[DDEFF]

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"  perfectionniste, j'en veux toujours plus et je continue à chercher.

[Pierre59]

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

[DDEFF]

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.

[Dominique]

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



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

[Pierre59]

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

[Dominique]

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"



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 

[bobyAndCo]

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.

[DDEFF]

Bonsoir Pierre,

Je suis en train(haha  ) 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
C'est effectivement encore plus rond qu'avant.

Par contre, ne commence pas par ça pour expliquer Processing, tu vas en rebuter quelques uns 
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 !! 

[Pierre59]

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

[HBC]

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

[frdechaume]

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.