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

[DDEFF]

Suite à quelques questions qui m'ont été posées (en off), je précise un peu plus ma démarche.
J'ai, en cours de développement toujours, deux programmes complémentaires.
Je vous ai présenté le deuxième dans le précédent post et, en PJ, vous trouverez le premier. Je sais, c'est un peu bizarre ...

Le premier programme est un éditeur de TCO.

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

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

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

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

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

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

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

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

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

Le deuxième programme sert à commander les trains

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

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

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

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

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

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

Avenir :

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

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

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

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

[DDEFF]

Je propose aujourd'hui de faire le point sur ce que je veux faire, à terme, et ce qui fonctionne déjà.

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

Quatre ordinateurs

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

Processing ?

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

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

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

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

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

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

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

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

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



Le deuxième ordinateur

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

PCDuino3 ?

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

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



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

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

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

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

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

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

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

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

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

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

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

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

Le troisième ordinateur

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

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

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

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

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

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

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

On fera évidemment un module cantons.

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

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

Le quatrième ordinateur

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

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

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

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

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

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

C'est très motivant.
N'hésitez pas à vous exprimer, à donner vote avis.

[DDEFF]

Je commence à voir un peu de lumière dans le programme de Jean-Luc (voir le fil sur ce programme).
Par ailleurs, concernant Processing, je vois le cheminement pour intégrer le Locodrome de Pierre.

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

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

A suivre 

[DDEFF]

Juste une remarque :

Comme je viens de mettre un nouveau Post sur le fil de Jean-Luc, je vais devoir adapter mon programme TCO pour que les enum{...} soient dans le bon ordre.
Comme ça, ça me repose un peu ....

[DDEFF]

Bonjour,

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

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

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

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

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

Voilà ce que ça donne en vrai :



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

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

Mais pourquoi vouloir approximer un cercle ?

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

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

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

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

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

[DDEFF]

"Les mathématiques, c'est l'art de raisonner juste sur une figure fausse"… disait mon prof de maths en 4ème.

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

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

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



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

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

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

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

On a au départ 6 points qui sont :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

[DDEFF]

Bonjour,

Voici la V4.0 de mon TCO en Processing.

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

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

J'ai fait une petite vidéo pour ceux qui veulent voir ce que ça donne. Mettez en plein écran


Le programme lui-même est en PJ.

[Dominique]

Alors là bravo 

Très jolie danse du ventre avec des rails flexibles

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

Amicalement
Dominique

[DDEFF]

Merci Dominique,

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

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

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

Et, pour les experts, un article sur les courbes de Bezier cubiques : ce que c'est, quelques graphiques et "un peu" de maths.
Pour info, j'ai quand même mis 70 heures pour les voies courbables...
Pas évident du tout, au départ (et des articles faux sur internet : ne pas croire tout ce qu'on lit)

[DDEFF]

Je continue mon TCO par une pièce de choix : la plaque tournante 

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



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

Mais ça avance...

[DDEFF]

On continue…
La plaque tournante :

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

Mise en œuvre :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



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

A suivre 

[DDEFF]

La problématique :

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

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

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

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

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



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

Tout cela est très dommage…

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

Un matin …

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

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

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

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

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

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

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

Voyons ce que cela donne sur un exemple.



Cette méthode est tout à fait neuve et n'a pas d'équivalent dans le commerce.

[Dominique]

C'est superbe !

Construire graphiquement son réseau avec un minimum d'éléments dans la palette et autant de possibilités : bravo Denis 

[DDEFF]

Merci Dominique 

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

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

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



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

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

Denis

[DDEFF]

Q : Comment vois-tu la suite du programme ?
R : Il reste quelques bugs à corriger, puis je m'attelle à la description du réseau.

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

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

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

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

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

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

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

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

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

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

Évidemment, les principes resteront :

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

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

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

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

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

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

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

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

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

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

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

Après, plus rien à voir.
Par exemple, j'ai une palette pour dessiner le réseau alors qu'il est décrit "en dur" dans locodrome.
Les buts ne sont pas du tout identiques.
Mais comme la base est la même, la façon de raisonner est la même et on convergera.