Messages

601

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 11, 2016, 03:56:30 pm »

Génial !!!
Je vais essayer de décortiquer

602

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 11, 2016, 01:49:46 pm »

C'est quand même un sacré site que LOCODUINO : on en est quand même à la troisième (!!) possibilité de modéliser un réseau...
Pour un seul site, c'est bien une preuve de vitalité !
Comme ils disent dans la pub : le plus dur, c'est de choisir...

603

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 11, 2016, 10:29:12 am »

Comment sais tu que tu as trouvé tous les itinéraires de ton réseau ? 432 est faux il y en a plus car tu as plusieurs chemins intermédiaires entre les doubles diagonales. Par exemple, entre VoieLibre0 et VoieGarage7, tu as 5 itinéraires si mon compte est bon.

Tu as raison : c'est plus que 432, car tu as effectivement tu as des fois plus de 2 itinéraires pour 2 extrémités données.
Donc, le nombre d'itinéraires possibles est plus élevé.

108 est également faux car tu ne peux pas aller de VoieLibre0 à VoieLibre9 sans changer de sens.

108, c'était un maximum.
En fait, il y a 36 couples origine-extémité qui sont carrément impossibles.

Je veux bien ne pas faire d'analyse (surtout à la main, ce que je n'ai jamais fait), mais il faut quand même prioriser des choses, avoir des critères ?

604

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 11, 2016, 09:39:22 am »

La nuit porte conseil... 
La chose la plus difficile à comprendre dans SGDD, c'est cette histoire de niveaux. En plus, saisie manuelle.
D'un autre côté, la saisie manuelle permet d'influencer les choix de l'Arduino.
Comment optimiser et surtout automatiser ?

Pour optimiser les itinéraires, il faut faire comme en réalité, avec un maître mot : fluidité

Il faut donc arriver à donner un "poids" aux itinéraires. C'est la phase d'analyse. On ne la fait qu'une fois.
Soit on la fait à part en on inscrit les résultats "en dur" dans la programme d'exploitation, soit on la met dans le setup() et c'est automatique.

1°) Il faut trouver tous les itinéraires.
Combien y en a-t-il ?
Dans ma gare, 9 origines (à gauche) et 12 extrémités (à droite).
Donc 9 x 12 = 108 itinéraires. Deux sens => 216 itinéraires.
Une bonne partie des itinéraires ont 2 solutions à cause des doubles diagonales => 432 est une borne supérieure.
C'est beaucoup pour un humain, mais pas trop pour un Arduino. Et, là dedans, 180 itinéraires utiles.
En "largeur" de la matrice, on a un maxi de 11 (itinéraire voieLibre0 -> voieLibre7)

2°) Il faut donner un poids à chaque aiguille.
A chaque fois qu'une aiguille est utilisée dans un itinéraire, on lui ajoute 1, en faisant le tour de tous les itinéraires.
On a donc un mini de 4 pour une aiguille donnée (aiguille = 2 itinéraires mini, dans les 2 sens) et un maxi de ... on ne sait pas.
Je ne serais pas surpris qu'on atteigne les 25-30.
Un poids de 20 indique que cette aiguille est impliquée dans 0 itinéraires.

3°) En ayant le poids de chaque aiguille, on va pouvoir donner le poids de chaque itinéraire en additionnant.
Et plus un itinéraire est "lourd", plus il bloque d'autres itinéraires et plus il contrarie la fluidité.
Et donc plus il faut le faire tard ! 

On a ainsi une donnée supplémentaire dans l'objet "itinéraire" : son poids, calculé une fois pour toute dans le setup().

Maintenant, on va élaguer cette liste en ne gardant que les itinéraires de plus faible poids quand il y en a deux pour un même coupe origine-extrémité.
Et c'est là qu'on arrive à "seulement" 180 itinéraires.

Une autre variable des itinéraires est "l'heure" à laquelle il va être demandé, heure qui va servir à savoir quand on va pouvoir le lancer.

Le principe du "time sharing" me paraît la méthode la plus adaptée à notre problème.
C'est une méthode qui sert dans les serveurs. Vieille méthode et donc éprouvée.

Le principe est le suivant :
Plusieurs itinéraires doivent être exécutés en même temps.
Comme on ne peux pas les faire vraiment en même temps, on va leur donner une priorité dynamique.

1°) On note l'heure de la demande.

2°) On note le poids de l'itinéraire. On effectue en priorité les itinéraires courts, ce qui réduit la liste (fluidité toujours)

3°) Au bout d'un "certain temps", on effectue des itinéraires plus lourds, même s'ils bloquent tout (ex : voieLibre0 -> voieLibre7) parce qu'il faut aussi que ces itinéraires soient faits.

Voilà.
Y'a plus qu'à ... 

605

Shields et Modules / Booster DCC

« le: mars 10, 2016, 02:08:39 pm »

Je viens de trouver sur internet un lien pas vieux (3 semaines) pour un booster DCC qui m'a l'air assez sympa.
Pas forcément hyper original, mais assez bien fait.

Vidéo :

Explications (matériel et programme) :
http://www.trainelectronics.com/DCC_Arduino/DCC_Booster/index.htm

Matériel : H-Bridge 43 amp BTS7960B à 12,79$ sur e-bay (franco de port)
Logiciel classique.

606

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 10, 2016, 08:58:50 am »

PEBCAK...
Maintenant, fonctionnement parfait.
Merci Jean-Luc

607

Le logiciel DCC++ / Re : DCC++ BaseStation

« le: mars 09, 2016, 10:31:16 pm »

Je confirme : Elektor.
Ils l'ont même fait avec une GameBoy Color. ET bi-courbe, SVP !!

608

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 09, 2016, 04:45:10 pm »

Arduino DUE connecté en USB sur le programming port, comme je l'ai toujours fait...
Je suis en version 1.6.7
La compil se passe bien, le téléversement aussi.
Dans "outils", je suis sur programmateur : "arduinoISP".
Voir copie écran jointe.

Et quand je clique sur la loupe à droite (moniteur série), il ne se passe rien.

Tu as mis le DEBUG en Debug.h.
J'ai essayé de mettre #include "debug.h" dans GrapheReseau, mais le compilateur me parle mal 



Arduino : 1.6.7 (Windows 10), Carte : "Arduino Due (Programming Port)"

In file included from R:\Documents publics\_Trains\Locoduino\Jean-Luc\GrapheReseau\GrapheReseau\GrapheReseau.ino:3:0:

Debug.h:6: error: default argument given for parameter 2 of 'void afficheNomVoie(byte, bool)' [-fpermissive]

 extern void afficheNomVoie(byte id, bool aLaLigne = false);
                                                          ^
In file included from sketch\Voie.h:7:0,

                 from R:\Documents publics\_Trains\Locoduino\Jean-Luc\GrapheReseau\GrapheReseau\GrapheReseau.ino:1:

Debug.h:6: error: after previous specification in 'void afficheNomVoie(byte, bool)' [-fpermissive]

 extern void afficheNomVoie(byte id, bool aLaLigne = false);
             ^
exit status 1
default argument given for parameter 2 of 'void afficheNomVoie(byte, bool)' [-fpermissive]

609

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 09, 2016, 02:57:52 pm »

Si je voulais être caustique, je dirais qu'il fait la même chose que l'ancien : il n'affiche toujours rien ...
Mais il compile sur DUE, effectivement, et sur un UNO.
J'ai dû oublier quelque chose 

610

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 09, 2016, 01:21:16 pm »

Et ça marche sur un UNO (je n'ai pas de MEGA). Tu dois avoir raison.

611

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 09, 2016, 12:14:20 pm »

A part ça, la compil ne marche pas... 

Message :
Arduino : 1.6.7 (Windows 10), Carte : "Arduino Due (Programming Port)"
GrapheReseauDDEFF:23: error: conflicting declaration 'SerialEmulation Serial'
 SerialEmulation Serial;
                 ^
In file included from C:\Users\PARENTS1\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.6\cores\arduino/Arduino.h:189:0,
                 from sketch\GrapheReseauDDEFF.ino.cpp:1:

C:\Users\PARENTS1\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.6\variants\arduino_due_x/variant.h:245:18: error: 'Serial' has a previous declaration as 'UARTClass Serial'

 extern UARTClass Serial;
                  ^
exit status 1
conflicting declaration 'SerialEmulation Serial'

612

Le logiciel DCC++ / Re : DCC++ BaseStation

« le: mars 09, 2016, 11:53:19 am »

Moi, j'ai regardé la partie Processing. On est complémentaires.

Le résultat est assez impressionnant, la programmation est propre, très bien documentée.
Cela donne une bonne idée de ce que l'on peut faire avec Processing.

Mais il y a quand même une ombre au tableau.

Analyse de la partie Processing (appellée DCCpp_Controller) :

J'ai trouvé où était décrit le réseau qu'on voit en jaune.   

C'est dans "controllerConfig" (le deuxième onglet) des lignes 371-481 pour le réseau principal.
C'est le tracé en jaune.

Un supplément est fait pour déplacer la partie aérienne (la boucle supérieure) lignes 483-494 parce qu'elle a deux positions (voir les vidéos)
C'est le petit tracé en jaune.

Puis sont décrits les aiguilles (lignes 513-587), avec les différentes positions possibles :
- couleurs jaune (libre)
- vert                  (fait partie d'un circuit)
- rouge               (en mauvaise position pour le circuit considéré)

Puis les circuits pré-enregistrés (lignes 589-1037), avec les boutons elliptiques en bleu en bas à droite

Dit autrement, vous aurez à refaire toutes ces lignes (de 371 à 1037 !!) pour votre propre réseau.
Pas insurmontable, puisqu'on a des modèles, mais assez fastidieux.   

Il faudrait que je voie comment adapter mon "TCO en Processing" (qui, lui, a un éditeur intégré : tout se fait avec la souris et quelques touches) pour que cette partie soit plus simple à faire. Parce que, là, c'est "en dur" dans le programme !

Il y aurait du travail, mais ça me paraît faisable. 

La question est : y-a-t-il un "marché" ?
Dit autrement, qui voudrait que cette interface soit plus facile à adapter à son réseau ?

613

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 09, 2016, 11:44:09 am »

Yes !!!!

A bientôt 60 balais (le 26/04, le jour de Tchernobyl  ), c'est quand même plus dur.

614

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 09, 2016, 10:38:18 am »

Merci Jean-Luc pour ta patience...

Mais je crois avoir compris.

Dans la class Voie, ligne 222 tu définis :

Code: [Sélectionner]

    virtual bool creeCheminVers(byte identifiant, byte dir, Voie *venantDe = NULL) = 0;
Donc venantDe est un pointeur et tu l'initialises à NULL.

Également dans la class Aiguille, ligne 452, tu définis :

Code: [Sélectionner]

    virtual bool creeCheminVers(byte identifiant, byte dir, Voie *venantDe = NULL);
Donc il y a des venantDe qui servent quand on est sur une voie et d'autres qui servent quand on est sur une aiguille.

En fait, ce pointeur est crée et initialisé à NULL dans tous les creeCheminVers(...), comme donnée d'entrée.

Dans la class Aiguille, ligne 441, tu définis :

Code: [Sélectionner]

    Voie *mVoieSortantDroit;Donc mVoieSortant droit est un pointeur.

Quelques lignes plus bas, ligne 458, tu lui affectes la valeur :

Code: [Sélectionner]

    mVoieSortantDroit = &voie;
Là, l'affectation est claire pour moi.

Mais pour venantDe, c'est plus complexe et je ne la trouvais pas.

En fait, tu la passe avec le this ligne 295 :

Code: [Sélectionner]

      if (mVoie->creeCheminVers(identifiant, dir, this))
Là, c'est pour VoieEnImpasse, mais il y en a pour tous les éléments.

Et après, effectivement, tu compares les deux pointeurs pour la TJD ligne 792 :

Code: [Sélectionner]

      if (venantDe == mVoieEntrant && mVoieSortant != NULL)Et comparer des pointeurs, c'est comme comparer les contenus.

C'est bon ? 

J'ai relu la prose de Thierry et ça m'a aussi aidé.
J'avais cru comprendre ses articles, mais finalement pas complètement...

Autre chose :

On démarre par la class Voie.
class VoieEnImpasse hérite de Voie
class VoieNormale hérite de Voie

Puis class VoieMuli
class Aiguille hérite de VoieMulti
class Croisement hérite de VoieMulti

class TraverseeJonctionDouble hérite de Croisement

C'est quand même très souple

615

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc

« le: mars 08, 2016, 06:00:08 pm »

Donc, pour voir ce que j'ai compris :

Sur ton schéma, Jean-Luc, chaque flèche est un pointeur.

Pour tjd12, pointeur de mVoieEntrant = voie8 et pointeur de mVoieEntrantBis = voie21
De même pour voie8, pointeur de mVoieSortant = tjd12 et pour voie21, pointeur de mVoieSortant = tjd12

Maintenant, il faut l'écrire en code compilable.

Dans le test if (venantDe == mVoieSortantDroit) {..},

mVoieSortantDroit est un élément de la classe Voie et donc ce n'est pas un pointeur.
Il s'ensuit que venantDe n'est pas non plus un pointeur pour qu'on compare des choses de même nature.

Il y a deux mVoieSortantDroit : celui de la voie8 et celui de la voie21 et il faut donc choisir.

Tu es dans bool traverseeJonctionDouble(...), donc tu es sur la tjd12 et tu recherches les antécédents pour pouvoir créer un chemin qui va venir soit de la voie8, soit de la voie21.
Quand tu rentres comme argument de bool(...) Voie *venantDe, tu veux préciser en entrée que tu viens de la voie8 ou que tu viens de la voie21.

Admettons qu'on vienne de la voie8.

Est-ce que je peux dire, dans tjd12, que Voie *venantDe = voie8 ?

Par ailleurs, dans voie8, mSortantDroit, pointe vers tjd12.
Est-ce que je peux dire, dans voie8 cette fois, que *mSortantDroit = tjd12 ?

Et là, je bloque. Que valent venantDe et mSortantDroit  ?