Messages

736

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau

« le: avril 16, 2015, 12:19:46 pm »

Concernant ce qui doit être décentralisé sur les cantons, j’ai choisi de décentraliser la commande de la loco (je suis en analogique) et la détection de présence. La commande des aiguillages est compliquée à décentraliser sur les cantons car on peut avoir plus ou moins d’aiguillages par canton ce qui abouti à un code ou des données spécifiques dans chaque canton et un tas de problème de mantenance dans les mises à jour. Idem pour la signalisation.

C'est la deuxième fois que tu dis "plus ou moins d'aiguillages par canton". J'aimerais que tu précises : tu "prolonges" les rails avec les contacts d'un relais ?
Parce que sinon, il faut bien détecter la présence des trains sur les aiguilles en carte B ?

Donc :

A) cartes de commande / détection de canton (pour moi une par canton mais il y a beaucoup de fonctions)
B) cartes de commande d’aiguillages
C) cartes de commande de signaux
D) carte de pilotage du réseau
E) carte TCO

Evidemment, en DCC, la carte A peut s’occuper de plusieurs cantons puisqu’elle a juste la détection à faire.

Je pense que le Nano de la carte canton peut effectivement gérer plusieurs cantons en DCC.
A mon avis, en DCC, il y a quand même autre chose à gérer au niveau du canton : le sens de déplacement sur le canton.

La loco reçoit de la centrale DCC son sens de déplacement via les rails, indépendamment de la carte canton.
En gros, l'info n'existe plus dans les cartes.

Mais, pour savoir dans quel sens va le train, sur ce canton précis, c'est plus dur :
    Soit on va le chercher dans la trame DCC, ce qui suppose un "sniffer" sur mesure (c'est à dire qui cherche l'info dans la trame DCC pour un train donné)
    Soit, au niveau de la carte D, on se rappelle du sens qu'on a demandé la dernière fois et qu'on garde donc en mémoire.
        Mais il faut, dans ces 2 cas, "traduire" ce sens de déplacement du train en sens de déplacement sur un canton donné.
    Dernière possibilité : le calculer au niveau du canton (vu qu'on a 3 zones)
Pas si facile, le DCC ... 

Et on a besoin de ce sens dans les enclenchements :
Classiquement, on interdit de bouger une aiguille quand l'un des 3 cantons adjacents est occupé.
Mais si un seul canton adjacent est occupé et que le train s'éloigne de l'aiguille, on ne va quand même pas bloquer l'aiguille.

A minima : tout est géré en carte D, en mémorisant les dernières demandes. Pourquoi pas ?

J’utilise 2 bus CAN, 1 pour la traction (cartes A), 1 pour les accessoires (B, C et E)
D doit donc avoir 2 contrôleurs CAN, c’est le cas de l’Arduino DUE.

Il y a une limite du nombre de cartes par bus CAN ?

Les cartes A reçoivent des commandes de D (vitesse de loco, sens de circulation, allumage/extinction des feux, affectation de convoi à un canton). Elle émettent à intervalles réguliers l’état d’occupation en pleine voie et en zone d’arrêt à destination de D. Elle émettent lorsqu’une machine passe d’un canton à l’autre la PWM et la composante intégrale de la loi de commande de manière à synchronise la  commande d’un canton à l’autre.

Les cartes B reçoivent les commandes de D (position des aiguilles) et émettent à destination de D la position effective lue via des fins de course.

Les cartes C reçoivent les commandes de D (signalisation)

La carte D connaît la topologie du réseau.

Elle reçoit de A l’état d’occupation en pleine voie et en zone d’arrêt et de B l’état des aiguillages. Elle reçoit également de E les commandes. Elle envoie à E les information de position des convois et des aiguillages.

La carte D connaît donc l’état global du réseau :
- convois présent, position de chaque convoi ;
- suivi des convois de canton en canton ;
- position des aiguilles.

Elle gère :
- affectation d’un poste de conduite à un convoi ;
- allumage/extinction des feux ;
- anti-collision ;
- positionnement des aiguillages ;
- gestion de la signalisation ;
- mémorisation des caractéristiques de loi de commande de chaque locomotive et envoi de ces caractéristiques aux cantons en fonction du suivi de convois.

Elle exécute :
Les commandes des postes de conduite;
Les commandes du TCO.

Dans les deux cas il y a filtrage : le fait qu’une commande d’un poste de conduite demande à entrer dans un canton occupé par un autre convoi est mis attente. De même le changement de position d’un aiguillage venant du TCO ou d’un poste de conduite alors que cet aiguillage est affecté à un autre convoi est mis en attente ou interdit.

Par la dessus, on peut mettre une circulation automatique en substituant un automate à un poste de conduite.

Parenthèse DCC pour ceux qui ont déjà une centrale du commerce :
Si on veut automatiser certaines actions, il faut faire une souris compatible XpressNet.
J'avais trouvé quelque chose chez Lenz (le Xpa, commandable par un téléphone). En gros, du bricolo, à 70 € quand même.
Puis je me suis souvenu du site de Paco où une souris XpressNet existe directement, mais avec un PIC. On passe à moins de 10 €.
Reste à faire la même chose en Arduino.
Évidemment, on ne peux pas passer d'un programme en HEX pour PIC à un programme Arduino. Il faut obligatoirement avoir le source du HEX ?

La carte E gère le TCO : changement de position d’aiguillage, réservation d’un itinéraire, affectation d’un convoi à un poste de conduite. Elle envoie ces ordres à D et reçoit de D le positionnement des convois et les positions des aiguilles.

La logique de fonctionnement n’est pas trop compliquée, il faut juste bien la spécifier et la vérifier.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

Alors, là, c'est grandiose !!
C'est vrai qu'il "suffisait" de créer un nouveau langage avec un compilateur !!!!!!!
Ben voyons !!
Oui, je veux bien des détails.   

Encore merci pour ce résumé très clair.

Amicalement

737

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau

« le: avril 15, 2015, 07:02:43 pm »

Bonsoir à tous,

Lorsqu'on conçoit un réseau, en plus des rails, des locos et des wagons, du choix DCC ou analogique (PWM), on fait le choix d'une centrale pour commander les convois et les aiguilles. Ensuite on arrive très vite à définir des cantons et choisir des détecteurs de rétrosignalisation pour organiser la circulation des trains avec des règles de sécurité (éviter les rencontres indésirables), installer des feux de signalisation et d'avertissement, gérer des itinéraires avec des gares de départ et d'arrivée, des horaires, des annonces sonores, etc…, tout en se réservant des possibilités de commande manuelle de convois pour des manoeuvres par exemple et pour le plaisir avant tout.

Pour mettre en oeuvre tout ce joli monde, la voie la plus facile, mais la plus onéreuse, consiste à acheter des produits du commerce (centrale, détecteurs, décodeurs) ainsi qu'un logiciel sur PC qui s'occupera de tout (TCO, pilotage, automatismes, cantons, signalisation, ..). L'ennui c'est que les limites du projet sont celles du logiciel.. et du porte-monnaie.

Disons que c'est sûr que c'est la voie (ah ah!) la plus onéreuse. Que ce soit la plus facile n'est, par contre, pas évident.
On présente toujours des cas très simples et, quand on creuse un peu, on se rend compte que la voie classique (DCC + rétro signalisation + logiciel) n'est pas si simple que ça.

De toutes façons, le problème est complexe et, quelque part, même si on le planque, il ressort toujours quelque part.

Pour réaliser quelques économies substantielles, on peut réaliser bon nombre des modules nécessaires par soi-même (DIY). Locoduino est là pour cela.

Oui

Pour les automatismes de circulation (bloc système, signalisation, itinéraires, ..), la solution du logiciel sur PC (TrainController, iTrain, …) reste tentante mais elle implique la remontée des signaux de rétrosignalisation vers le PC une l'interface entre le PC et la centrale.

J'ajouterai CdmRail, gratuit, mais je préfère l'Arduino.

Alors pourquoi ne pas tenter de se passer complètement du PC ?

Oui, bonne idée.

On peut construire un vrai TCO plus agréable à regarder et plus facile à utiliser qu'un écran de PC, avec ses boutons, curseurs, et Leds bien réels. D'accord, il y a beaucoup de fils à souder, mais le résultat en vaut la peine !

Oui !!

Reste enfin le logiciel qui va gérer l'ensemble de la circulation, la rétrosignalisation, la sécurité, la signalisation : Est-ce possible avec un Arduino ?

Oui, heureusement. De nombreux chercheurs sont déjà sur la piste. Les pistes devrais-je dire, d'ailleurs. Parce qu'un tel problème n'a pas qu'une seule solution.

L'expérience de mes 2 premiers minuscules réseaux m'a conduit à des solutions très spécifiques, pas généralisables vers des réseaux plus grands. Je cherche donc une modélisation logicielle plus sérieuse.

La lecture de quelques documentations des solutions du commerce me conduisent au principe suivant : La rétrosignalisation est caractérisée par un ensemble de procédures et de composants qui permettent à l’unité de commande du TCO de connaître ce qui se passe sur le réseau et, en conséquence, d’exécuter des actions paramètrées associées à ces évènements.

La modélisation ne serait donc qu'un simple (mais énorme) automate qui associe une ou plusieurs actions à chaque événement. Ce qui sous-entend un satané programme de configuration !

Disons que, pour résumer, il faut définir ce qui doit vraiment avoir lieu au niveau du canton et ce qui doit vraiment être centralisé. Et ce n'est pas aussi simple que ça.
Qui dit centralisation dit bus et celui qui se détache, c'est le bus CAN. C'est un point qui me parait clair. J'ai moi même essayé plein d'autres idées (plus folles les unes que les autres) et on n'en revient toujours au bus CAN.
Ce qui induit une certaine logique de fonctionnement (des buffers, etc ...) et une gestion des infos bidirectionnelles.

Pas si simple : il faut en outre une définition du réseau (cantons, aiguilles, signaux, distances, vitesses limites, priorités) sur laquelle se superpose les positions et les mouvements des trains (donc aussi une définition des trains). Les interactions sont très nombreuses !

Contrairement à ce que tu penses, la vraie difficulté n'est pas de décrire le réseau (c'est une table), gérer les signaux non plus (les règles sont simples : ça ne dépend que des occupations et des positions d'aiguilles).
Une fois que tu as les signaux, les vitesses maxi sont simples.
Et c'est même rapide à calculer (j'ai 7,5 millisecondes pour 19 cantons et 26 aiguilles).

Pour les distances d'arrêt, la solution classique est de prendre p.ex 4/5 de la longueur de la pleine voie du canton le plus court :
Si le train arrive à fond, à 4/5 de la longueur il est à la vitesse de ralenti. Vitesse qu'il garde jusqu'à la zone d'arrêt où il s'arrête vraiment.
Ce système permet un arrêt toujours au même endroit : au pied du signal.
Une amélioration serait de calculer l'endroit où le train doit commencer à freiner en fonction de sa vitesse initiale. Ce serait plus réaliste. C'est faisable, mais ça commence çà être costaud.
Reste à gérer les itinéraires. Faisable aussi. Plusieurs solutions.

Pour l'instant, ce qui me bloque, c'est de tester comment se font les échanges d'infos sur le bus CAN.

Alors connaissez-vous de la littérature pour atteindre ce but, des documents même théoriques ou des bibliothèques logicielles qui pourraient m'aider ?

Je t'ai joint mon programme. Il tourne sur un Uno, mais il sera mieux sur un Méga (je viens d'en recevoir un). Le plan de réseau correspondant.
C'est une piste parmi d'autres, avant le bus CAN. Et même avant d'avoir un réseau ... :-)
Tu verras les tables et comment elles se remplissent.
Je suis à ta dispo pour en parler.
Mais nos autres intervenants ont certainement bien d'autres idées.

738

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 15, 2015, 12:29:19 pm »

A Pierre :

Je suis convaincu que le PRS n'est pas fait pour simplifier les choses...
J'ai utilisé ton schéma pour décrire ce que serait un vrai PRS complet.
Évidemment, quand c'est à nous de câbler, on simplifie.
Je comprends ça parfaitement. Mais ça n'est plus vraiment un PRS.

Et je n'ai pas parlé des enclenchements liés aux itinéraires qui ne simplifient pas non plus les choses.
Entre autres, les enclenchements doivent tenir compte non seulement de l'occupation des voies, mais aussi du sens de circulation des trains.

Là aussi, les amateurs, que nous sommes, ont tendance à "élaguer"...

A Jean-Luc :

C'est de 1991 ...

J'ai décrit ça pour illustrer le principe.

1°) Des modules standard. On n'a pas à décrire le réseau. C'est en aboutant les différents modules qu'on décrit le réseau.
Je suis toujours sur le cas des 200 aiguilles dont, à mon avis, facilement 50-60 en gare.

2°) Ce n'est pas forcément une tension. La consigne peut être numérique. Ce serait certainement mieux avec un Arduino.
L'idée est que le module n'a qu'une décision à prendre : on sort par en haut ou par en bas.
Et à la fin on arrive à l'autre extrémité.

739

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 14, 2015, 05:44:33 pm »

Bonjour Pierre,

Sur ton schéma, j'aurais 3 coupures à faire en plus :
Quand un train va de Z en E, une fois qu'il a libéré la première aiguille, on doit pouvoir aller de Z en C
Quand il a libéré la deuxième aiguille, on doit pouvoir aller de Z en D.
Par ailleurs, quand on va de T vers le haut, on doit pouvoir aller de Z en T dès que la première aiguille est libre.
Évidemment, ça complique ... 

L'idée que j'ai est de créer des modules standards avec un Arduino chacun et qu'on assemble en fonction du plan des voies.
Exemple en bas de page.
Chaque module s'occupe uniquement des ses entrées sortie (3 ou 4)
Chaque module correspond à un niveau de tension qui est sa position en Y, le zéro étant la voie du bas dans la gare.
On part, par exemple, d'une des voies de gauche.
Potentiels respectifs : 3V, 4V et 5V.
A droite, potentiels de 1V à 7V.

On demande aller de la voie 3 à la voie 6.

A chaque module, on compare la tension de référence du module à la tension de consigne (ici 6V).
Dans le premier module, la consigne est à 6V et la référence à 3,5V => on sort du module par en haut.
Dans le deuxième module, 6V > 4,5V => On sort par en haut
Dans le troisième module, 6V > 5,5V => On sort par en haut
Etc...
Et dans le dernier module on sort par en bas car 6V < 6,5V.

Il y a 6 types de modules :
Aiguille en pointe, aiguille en talon, bifurcation montante, bifurcation descendante, croisement seul et la TJD.

Un itinéraire se construit en appuyant d'abord sur le canton origine puis sur le canton arrivée (géographique)

L'ordre d'appui des boutons donne le sens de circulation du train.
Le sens de recherche des itinéraires est, lui, toujours de gauche à droite.

L'avantage est que le lanceur origine est plus compliqué que le lanceur extrémité. Ici 2 lanceurs origine et 7 lanceurs extrémité.
Le dernier module boucle et prévient le lanceur origine que l'itinéraire est formé.

Vous venez de lire mon idée du 05/02/1991 que je n'ai jamais pu tester (j'ai eu 2 enfants  et pas de place pour un réseau  )

740

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 13, 2015, 07:19:59 pm »

4°) Il faut que chaque aiguille puisse être alimentée par plusieurs endroits. ça complique aussi le câblage.

741

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 13, 2015, 07:10:19 pm »

1°) On ne recherche pas d'itinéraire au fur et à mesure que le train roule. On est d'accords, mais on le dit différemment.
On le redéfinit. OK
2°) Attention à un autre point : un croisement ne bouge pas, n'a aucune bobine (Tortoise ou servo), mais pose exactement le même problème que la TJD.
3°) Je propose d'avoir des modules avec un arduino pro mini chacun et qui règlent un problème spécifique :
Une aiguille en pointe, une en talon, un croisement, une bifurcation, une TJD.

742

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 13, 2015, 04:10:19 pm »

D'accord avec ta méthode pour calculer l'itinéraire au lieu de stocker tous les itinéraires possibles.
C'est aussi comme ça que je faisais (j'avais potassé en 1998 sur le sujet).
Par contre, on ne choisit pas le plus court. C'est souvent celui qui génère le plus d'incompatibilités avec les autres.
On décide de prendre celui qui va le plus à gauche.
Comme ça, quand il y a 2 diagonales, on a moins de chance de faire des itinéraires qui se croisent.
Le train qui vient de l'extérieur prend donc la diagonale externe et celui qui vient dans l'autre sens prend la diagonale interne.
C'est juste une probabilité : deux itinéraire demandés peuvent être incompatibles, quelle que soit la méthode.

Une fois qu'un itinéraire est construit, on ne peut plus utiliser ses aiguilles tant que le train ne les a pas "effacées" en roulant dessus.
Quand le train parcoure l'itinéraire, il en efface les aiguilles une à une.
C'est cette notion qu'on appelle "souplesse".
Une fois une aiguille effacée, elle devient immédiatement disponible pour un autre itinéraire.

D'où la nécessité de tester l'occupation des aiguilles une par une.
D'où le fait que j'ai raisonné comme ça sur mon projet sur le forum Loco Revue.

Si on va jusqu'au bout du raisonnement, l'itinéraire est accroché non pas à sa voie d'origine, mais à sa voie d'extrémité.

A+
PS : j'ai essayé de mettre une image, mais je n'ai pas compris comment faire.

743

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 12, 2015, 08:50:07 pm »

Bonjour,
200 aiguilles, c'est vraiment énorme.
Je commencerais par distinguer 2 zones : les gares cachées et la zone visible.

En général, quand les réseaux sont de cette taille (que tu ne nous a pas donnée, d'ailleurs  ) il y a énormément d'aiguilles alignées dans une gare cachée.
J'entends par "alignées" des gares dans lesquelles les aiguilles sont les unes derrière les autres et qu'un seul itinéraire est possible, excluant tous les autres.
Chacun permet d'aller vers une voie de garage.
Il y a plein de voies de garages avec un train prêt sur chacune et chaque fois qu'un train rentre, c'est un autre qui sort.
Deux gares de ce type sont sur le réseau et la gestion consiste à envoyer un train d'une gare cachée à l'autre gare cachée.
A partir du moment où il n'y a pas d'itinéraires compatibles, c'est assez facile à gérer.

Et puis il y a la partie visible (avec une troisième gare !), plus complexe à gérer.
Là, trois types de gestion :
Le type PRA (Poste tout Relais Automatique), PRS (Poste tout Relais à transit Souple) et le PRG, plus récent, (Poste tout Relais à gestion Géographique).
Évidemment, on ne le fera pas à relais ...

Le PRA est assez "simple" : on décrit l'itinéraire quelque part, il s'exécute en mettant les aiguilles dans la bonne position (l'une après l'autre pour éviter les appels de courant).
Son défaut viscéral : tant que l'itinéraire n'est pas parcouru jusqu'au bout, il bloque tout le monde.
Ce serai utilisable en gare cachée.

Le PRS est, lui, assez tordu. Là, on voit très très peu de réalisations. C'est une sorte de Graal.
ça démarre pareil, mais dès qu'un autre itinéraire compatible est réalisable, il se lance.
Le premier train finit son itinéraire, mais un autre train est lancé. C'est ça, la souplesse.
ça suppose évidemment que chaque aiguille soit considérée comme un canton, géré comme tel.
C'est nettement plus complexe, surtout en câblage.
Je ne connais que 2 réalisations : Pierre Chenevez en 1972 (avec quelques erreurs de schémas, d'ailleurs) et celle, dans les années 1990, des frères Jesu dans Loco Revue.
Je n'en ai jamais vue en électronique.
Je ne sais pas si un logiciel l'a fait. C'est possible.

Le PRG est du même genre, mais on sélectionne un itinéraire en appuyant sur le bouton Origine de l'itinéraire et sur l'Extrémité pour le lancer.
Sinon, il faut retenir le numéro d'itinéraire, ce qui n'est pas gérable avec 200 aiguilles.
On doit pouvoir le faire avec DES Arduinos. Mais rien de tout fait.

Bon courage !
Denis