Auteur Sujet: Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.  (Lu 59912 fois)

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Bonjour à tous,

En répondre au challenge proposé sur le topic : Projet partagé d'un gestionnaire de réseau https://forum.locoduino.org/index.php?topic=1645.0
je propose pour ma part une solution que j’ai nommée satellites autonomes.

L’ambition des satellites autonomes est d’offrir une solution de gestion de réseau simple et rapide à déployer et ne nécessitant par la suite aucune intervention particulière durant l’exploitation. Priorité est donnée au plaisir du jeu en libérant le modéliste d’opérations fastidieuse ou encore de programmation.


Principes généraux :

Les satellites autonomes sont à la base des satellites Locoduino tels qu’ils ont été présentés en 2018. Ce sont des cartes qui reçoivent des commandes en entrée : commandes de mouvement d’aiguille ou de signalisation lumineuse par exemple, et qui envoient en sortie, des informations d’état concernant les équipements de réseaux sous sa responsabilité : Etat d’occupation, état des capteurs en entrée ou en sortie de canton…

Ces satellites auxquels nous avons donné la dénomination v1 sont ainsi des alliés précieux pour un gestionnaire de réseaux puisqu’ils lui apportent les informations nécessaires à la prise de décisions et en retour, exécutent les commandes demandées par ce gestionnaire.

Mais les gestionnaires de réseaux existants sont assez compliqués à programmer et cela rebute nombre d’entre nous à commencer par moi. Je parle de JMRI ou Rocrail pour les logiciels gratuits ou encore Train Controller mais il y en a beaucoup d’autres. Ce sont par ailleurs des solutions qui nécessite pour la plupart un ordinateur dédié (ou un Raspberry).

Mon travail a donc consisté à demander à chaque satellite de réaliser en plus, pour le canton qui est sous sa responsabilité, les fonctions de gestion de réseau : Sécurité et régulation des trains, commandes de ralentissement et/ou d’arrêt des locomotives, gestion de la signalisation lumineuse. J’ai donc introduit comme disent certains, une forme d’intelligence dans le système.

D’où aussi le nom de satellites autonome dans la mesure où il n’y a pas de gestionnaire centralisé.

Les objectifs :

Les objectifs que je me suis fixés avec les satellites autonomes étaient :

1° - Que la phase de description du réseau, des équipements, du nommage de zones ou des cantons, le choix des cibles de signalisation soient simplifiés autant qu’il serait possible. Et je pense que sur ce point l’objectif est largement atteint, voir dépassé comme vous pourrez en juger par la suite.

2° - Que pendant l’exploitation, le modéliste soit totalement libéré des contraintes de sécurité en particulier pour pouvoir pleinement profiter du plaisir du jeu.

3° - Que le modéliste n’ait rien à écrire ou modifier dans le code des programmes. Que les programmes à télécharger sur chaque carte soient tous rigoureusement identiques. De fait, hormis le nom du réseau Wifi et son mot de passe à renseigner une fois, il n’y a rien d’autre à faire.

4° - Offrir une interface simple et intuitive pour les quelques opérations de réglage comme par exemple pour les butées des servo-moteurs d’aiguilles.

5° - Mettre en œuvre les solutions techniques privilégiés par Locoduino comme le protocole DCC (que l’on retrouve aujourd’hui dans LaBox) ou l’adoption d’un bus de communication CAN.

6° - Simplifier autant que cela serait possible le câblage du réseau, nombre et longueur des câbles en particulier. Cela est en partie grandement réalisé par les liaisons en RJ45 qui véhiculent le bus CAN et l'alimentation électrique.

Dans la version actuelle, les possibilités offertes sont particulièrement bien adaptées pour une mise en œuvre simple sur des petits et moyens réseaux, des dioramas, des va-et-vient sur lesquels je dirais, il n’y a qu’à poser les satellites à proximité des cantons, souder quelques fils, procéder à la reconnaissance mutuelle, régler le cas échéant les valeurs de servos moteurs d’aiguilles et c’est tout. Il est possible d’utiliser son réseau avec trois satellites pour en tester le comportement et d’ajouter un quatrième, puis un cinquième puis tous les autres. Rien de ce qui a déjà été fait n’est remis en cause.
Les satellites autonomes permettent donc de couvrir les besoins de la grande majorité des modélistes Je suis bien conscient et j’assume le fait que cela ne répondra pas par exemple aux besoins d’une vaste gare cachée avec de nombreuses aiguilles ni encore à ceux d’un grand réseau complexe.

Point important à noter : Pour rester cohérent avec mon objectif de simplification, j’ai retenu la technologie Railcom pour la détection et l’identification des locomotives. Cela nécessite donc que toutes les locomotives disposent de cette technologie. La reconnaissance par RFID est aussi incluse (mais optionnelle) mais elle ne peut pas se substituer à Railcom.

Voilà donc posés les principes généraux et la philosophie de ces satellites autonomes. Je vous présenterai par la suite les différents matériels, la mise en œuvre concrète et bien sûr, pour ceux que cela intéresse le code des programmes.

En attendant, voici ce à quoi ressemble un satellite autonome :


Je répondrai volontiers à toutes les questions que vous voudrez me poser, mais n'anticipez pas trop sur ce que je dois vous présenter par la suite.

Christophe
« Modifié: janvier 13, 2024, 07:31:44 am par bobyAndCo »

laurentr

  • Hero Member
  • *****
  • Messages: 643
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #1 le: janvier 10, 2024, 02:08:45 pm »
Bonjour Christophe

Hâte de découvrir toutes les astuces que tu as pu mettre en œuvre pour parvenir à ce très beau résultat dont tes vidéos sur YouTube illustre bien la mise en œuvre des satellites autonomes!

Bravo!

Quelques questions au vol qui trouveront leur(s) réponse(s) en temps opportun:

Tu utilises la lecture du Channel 1 RAICLOM  pour récupérer l'adresse ou tu as prévu aussi la possibilité de les récupérer sur le CH2 si le décodeur est configuré pour l émettre?

Ltr

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #2 le: janvier 10, 2024, 02:13:35 pm »
Bonjour Laurent,

Non je n'utilise pas le CH2 de Railcom qui n'apporte rien dans le concept de satellite autonome. Il en sera peut-être différemment dans des évolutions.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #3 le: janvier 10, 2024, 07:27:53 pm »
Implantation des satellites autonomes sur le réseau :

Pour respecter les règles du challenge qui a été proposé, je vais donc reprendre le réseau type qui a été défini et vous montrer comment j’implante les satellites autonomes sur ce réseau et comment ceux-ci vont assurer la mission que l’on attend d’eux.

L’approche des satellites autonomes étant assez différente des approches « classiques » j’ai modifié certains aspects du plans mais cela ne change en rien les paramètres de base ni les contraintes fixées.



Sur le réseau, il faut implanter autant de satellites autonomes qu’il y a de canton. Je précise bien canton et non de zone !

A cette implantation de base, il faut ajouter deux cartes qui sont de simples ESP32 disposant de la communication CAN :

1° - Une carte dénommée « main » car elle assure quelques opérations centralisées sur lesquelles je reviendrai.

2° - Une carte qui fait office de « watchdog ». Le rôle exclusif de cette carte est de s’assurer en temps réel que tous les cartes du réseau sont fonctionnelles et dans le cas contraire, stopper immédiatement toutes circulation de convois pour éviter des accidents.

Dans la mesure où les cartes satellites autonomes s’articules autour d’un bus CAN, la topologie schématique est la suivante :



Je rappelle que le CAN utilise un bus ce qui veut dire que l’on part d’une carte pour entrer dans une autre dont on ressort etc… etc… Aucune architecture en étoile (comme on en trouve avec Ethernet) n’est possible en CAN.

A chaque extrémité du bus doit être disposée une résistance qui idéalement est de 120Ω. Pour n’avoir à y penser qu’une seule fois et éviter des oublis en cas de modification du réseau, je suggère des placer la carte main à l’une des extrémités avec sa résistance de 120Ω et la carte watchdog à l’autre extrémité, elle aussi avec sa résistance de 120Ω. Comme cela, aucune des cartes satellites n’a besoin de résistance.

A partir du plan de réseau imposé, voici l’implantation des cartes satellites ainsi que de la carte main et de la carte watchdog.

Notez que j’ai renommé certaines choses : Pour les satellites autonomes, il n’y a pas de distinction de zones mais seulement des cantons. Pour des raisons de cohérence, j’ai juste changé le préfixe de « z » en « c » (pour canton) mais je n’ai pas modifié la numérotation et j’ai supprimé les zones qui n’ont pas de raison d’être dans l’approche de satellites autonomes.

Tous les signaux ont « s » maintenant comme préfixe, le programme se chargera de déterminer par lui-même les différentes cibles et en modifiera de toutes façons certaines car il ne figure pas dans le plan initial de ralentissement par exemple.

Pour ceux qui se souviennent du Locoduinodrome et des satellites v1, vous retrouvez des choses qui vous sont familières.



Notez qu’à chaque satellite autonome doit être associé une carte de détection Railcom qui pour des raisons de place ne figurent pas sur ce schéma. Ces cartes sont décrites en détail dans cet article : https://www.locoduino.org/spip.php?article334

Dans un prochain post, j’aborderai la notion de « discovery » qui est sans doute l’élément le plus innovant des satellites autonomes qui permet à l’application de construire toutes les liaisons rapidement et simplement et qui permet aussi de créer automatiquement les objets logiciels pour les aiguilles et les signaux.

Christophe
« Modifié: janvier 13, 2024, 07:32:10 am par bobyAndCo »

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #4 le: janvier 11, 2024, 11:03:24 am »

Bonjour

Tu a beaucoup (trop) bricolé tes cantons pour les adapter à tes satellites, en essayant de supprimer les zones.

Prenons un exemple concret, un train est sur le canton c5 en arrêt   devant le carré fermé s4, le canton c5 est occupé et protégé par le sémaphore s2.
On a un train sur la voie A (canton c0) que l'on veut envoyer vers le canton c6, il faut passer par la TJS A1-A3, or le canton c5 dans lequel est la TJS est occupé, comment on fait, de plus qu'est ce qui empêche d'ouvrir le carré s4 laissant passer un autre train au même endroit (la TJS A1-A3).

Un canton est protégé par un sémaphore (ou un carré pouvant présenter le feu sémaphore) situé juste au début du canton, pour les cantons parcourus dans les deux sens il y a un sémaphore de chaque coté.
Le canton c0 a comme sémaphore de protection le carre s4 d'un coté et s5 de l'autre, dans les deux cas il y a un canton parasite qui vient s'insérer (c5 ou c9), bizarre.
Le canton c6 a deux signaux de protection s6 et s1, c'est normal c'est un canton à géométrie variable, pour s6 pas de problèmes mais pour s1 le canton c5 viens intempestivement s'insérer entre s1 et c6.

En pratique on ne peut pas se passer de zones pour les deux TJS (A1-A3 et A5-A7).
Plus généralement on ne peut pas se passer de zones pour les bifurcations et les faisceaux d'entrées de gare.

Pierre

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #5 le: janvier 11, 2024, 11:08:23 am »
B'hein ça c'est toi qui le dit. En prtique ça fonctionne et c'est l'essentiel, non ? Attends au moins de voir le résultat avant de dire que cela ne fonctionne pas.

Christophe

laurentr

  • Hero Member
  • *****
  • Messages: 643
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #6 le: janvier 11, 2024, 11:30:28 am »
Bonjour

Je comprends les interrogations de Pierre59 car je m étais livré a une analyse similaire du fait de l inclusion des TJS/TJD aux cantons collatéraux.
 En cas d occupation on ne voyait pas le mécanisme garantissant la securité lors du"cisaillement" et la poly detection lorsque la loc qui emmet en RC transite par la TJS TJD alors que le canton auquel elle est attache est possiblement lui aussi déjà occupé avec une émission RAILCOM...

Donc sauf à un sous découpage ou les explications ad hoc... nos neurones souffrent mais nos yeux vont apprécier puisque cela fonctionne :)

Hate de voir la suite!

Ltr

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #7 le: janvier 11, 2024, 12:45:46 pm »
Bonjour Laurent,

L'objectif n°1 n'est-il pas de garantir qu’un train ne puisse s’engager sur un canton qui est déjà occupé ?

Si ce canton suivant est libre, l’objectif n°1-bis n’est-il pas de garantir que le train ne puisse s’engager sur ce canton alors que les appareils de voie ne sont pas correctement positionnés (par exemple à talon aiguille déviée) ?

Je parle donc bien d’éviter la collision de deux trains ou un déraillement quasi certain qui sont dans les deux cas dommageables pour le modéliste.

Il est où le problème si je garantie cela ?

En objectif n°2, je dirais de disposer d’une signalisation qui soit le reflet des situations concrètes.

Objectif n°3, que les locomotives "obéissent" à la signalisation !

J’ai été clair dès le départ que mon objectif était d’apporter des solutions simples et pratiques pour une grande majorité de modélistes et qui leur garantissent avant tout la sécurité et une signalisation réaliste, pas de créer une usine à gaz !
« Modifié: janvier 11, 2024, 12:50:59 pm par bobyAndCo »

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #8 le: janvier 11, 2024, 01:02:53 pm »
Bonjour Christophe,

Ton système a quelque chose de sympa : tu décris le réseau indépendamment d'un programme.

Mais, sur ton schéma, si c5 est occupé, on ne peut plus aller de c0 à c6.
Il faut absolument que la TJS soit une zone, indépendante de tous les cantons qui l'entourent. Une zone reliée au bus CAN, sans signaux, mais avec une détection de présence et gérée indépendamment.

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #9 le: janvier 11, 2024, 01:21:06 pm »
Mais c’est de l’acharnement ou quoi ! Vous ne voulez vraiment attendre que j’ai fini avant de tirer à boulet rouge ?

Vous savez, je suis malouin et les Anglais ont essayé bien avant vous, mais sans succès, alors ça m’en touche une sans faire bouger l’autre !

Pourquoi ne pas vouloir attendre que j’ai terminé pour juger ? Ce n’est tout de même pas fair-play.

Et vous, vous en êtes où ?

Christophe

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #10 le: janvier 11, 2024, 01:43:11 pm »
Christophe, tu prends les choses trop à cœur.

Je reconnais volontiers que tu as cherché à faire quelque chose d'original, que tu ne l'a pas simplement imaginé, mais, en plus réalisé, ce qui mérite le respect.
L'idée, je l'ai dit, est sympa et a du potentiel.

Tu maîtrise le bus CAN, tu sais gérer un ESP32 (ce qui n'est pas une mince affaire), et ça fonctionnera sur beaucoup de réseaux.
Je pense que, pour plus d'universalité, il faut développer aussi une carte de zone, certainement plus simple, d'ailleurs, qu'une carte de canton.

C'est tout ce que j'ai dit. Je n'ai pas "tiré à boulets rouges" sur quelqu'un qui est, sans aucun doute, meilleur que moi en programmation.

Denis

"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #11 le: janvier 11, 2024, 02:49:30 pm »
Bon après ces petites péripéties, reprenons le fil du sujet et abordons le matériel qu’il est nécessaire de déployer.

La carte main et la carte watchdog.



Ce sont deux cartes ESP32 équipées d’un transceiver CAN MCP2562. Assez classique donc. Comme précisé sur le schéma précédent, elles doivent être intégrée au bus CAN.

Pour ceux qui le souhaitent, je joins les fichiers Gerber d’une carte assez universelle pour ESP32 à 38 pins.

https://www.locoduino.org/IMG/zip/esp32_can_v6_38_pins_gerber-2.zip

Les cartes satellites.

Le microcontrôleur sur chaque carte est un ESP32, choix qui répond bien à différentes contraintes : Cout faible, puissance du processeur double cœur, mémoire flash suffisamment importante pour stocker des données comme un serveur d’application et les données spécifiques du canton et de ses accessoires.



Vue d’ensemble d’une carte satellite



L'ESP32 au cœur du système

Au centre de la carte, nous avons un ESP32 à 38 pins ESP32-DevKitC avec 4MB de mémoire flash et deux cœurs que nous exploitons car la carte est beaucoup sollicitée en calculs.
On trouve facilement ce type de carte sur internet pour une dizaine d’euros environ.



Les boutons poussoirs et le switch du mode Discovery.

Juste au-dessus, nous avons les boutons de sélection et le switch utilisés dans le processus de découverte sur lesquels je reviendrai en détail plus tard.



Les cartes sont reliées entre elles avec des câbles Ethernet et des connecteurs RJ45. Dans ces câbles transitent le signal CAN (High et Low) mais aussi le courant en 12 ou 24 volts qui sert à l’alimentation électrique de la carte et de ses accessoires.
Il n’y a aucun autre câble nécessaire pour relier les satellites entre eux. Les seuls autres câbles nécessaires sont pour les équipements locaux : capteurs et servo moteurs.
Je recommande des câbles de catégorie 6 ou plus pour la qualité de transmission et pour supporter le courant de puissance. S’agissant de câbles torsadés, on mesure facilement l’intérêt de ce principe de liaison.

Les cartes doivent être reliées en série pour former un bus et ne peuvent en aucun cas faire l’objet de liaisons en étoile comme on le fait par exemple en Ethernet en utilisant des hubs.



Convertisseur 5V/1A

A droite de l’ESP32, nous avons un convertisseur 5 volts/1 ampère pour alimenter les principaux accessoires de la carte comme les servomoteurs d’aiguilles, les feux de signalisation etc… La tension maximale admissible pour le convertisseur est 36 volts mais 24 volts me semble être un maximum raisonnable.
L’ESP32 est alimenté par ce courant de 5 volts et utilise ensuite son propre convertisseur pour la réduction du courant en 3,3 volts, sa tension de fonctionnement. Quelques pads à souder sur la carte permettent de « repiquer » du 5 ou du 3,3 volts en cas de besoin (capteur IR de position par exemple).
Un bornier à vis sert à alimenter la première carte en 12 ou 24 volts avec une alimentation extérieure. Courant qui sera ensuite véhiculé de cartes en cartes par le câble Ethernet comme nous l’avons vu plus haut.

Il est judicieux de réalimenter régulièrement le circuit (toutes les 6 ou 8 cartes) par le biais de ce bornier.



Transceiver MCP2562

Juste en dessous de l’alimentation, nous avons la communication CAN avec un transceiver MCP2562, une résistance de 120 Ω qui doit être activée lorsque la carte est la première ou la dernière du bus en plaçant un cavalier sur le jump.
A droite du transceiver on distingue l’emplacement pour un connecteur destiné à la liaison CAN en filaire mais qui n’est pas installé ici puisque le transport du signal s’opère à l’intérieur du câble RJ45.



Dans le bas à gauche de la carte, nous avons la partie signalisation.



Il est possible d’alimenter jusqu’à 16 leds de signaux lumineux par l’utilisation de registres à décalage, ici des 74HC595 encadrés en rouge ci-dessous avec le repère (1).



Le courant sur chacune des sorties des 74HC595 devant être au maximum de 20 mA, nous utilisons des transistors Darlington ULN2803 distribuer le courant aux différentes leds - repère (2).



On dispose des résistances à chaque sortie de ULN2803 pour adapter le courant à la spécificité des leds reliées à la carte - repère (3).



L’alimentation des led’s en courant peut être assurée directement au travers du régulateur 5 volts de la carte. On disposera alors un jumper sur la partie gauche - repère (4).



Il est également possible d’alimenter directement les ULN2803 au travers du connecteur et d’une diode en bas et au milieu de la carte - repère (4). La tension du courant pourra alors être différente de 5 volts et les résistances seront alors calculées en conséquence. Il ne faudra surtout pas oublier d’enlever le jumper.
L’alimentation des leds est à anode commune.



Connexions pour quatre servomoteurs d’aiguilles

Enfin, sur la partie basse et droite de la carte, nous disposons de quatre connecteurs pour piloter jusqu’à quatre servo-moteurs d’aiguilles.

Chaque carte satellite permet la reconnaissance de locomotives avec la technologie Railcom© et donc, la détection d’occupation.

Deux capteurs « tout ou rien » sont présents (capteurs à effet Hall, IR…) à 10 ou 20 centimètres de chaque extrémité du canton.

Voilà pour la présentation matérielle de ces cartes satellites dont on rappelle qu’il faut en disposer une pour chaque canton dont on veut assurer le contrôle.

Pour info, voici le mapping adopté pour la carte satellite :





Et voici le lien de téléchargement du fichier Gerber pour les cartes satellites

https://www.locoduino.org/IMG/zip/gerber_v7.zip

Je vous rappelle que je répondrai volontiers aux questions que vous ne manquez certainement pas d'avoir (sauf si comme je l'ai déjà dit, on anticipe sur ce que j'ai prévu de publier) !

Christophe
« Modifié: janvier 13, 2024, 07:38:59 am par bobyAndCo »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #12 le: janvier 11, 2024, 04:04:20 pm »
Nous allons maintenant voir ce que j’ai appelé le « processus de découverte » ou « discovery ». C’est certainement le point le plus innovant dans ce projet de satellites autonomes que je vous propose.

Comme vous le savez sans doute déjà et vous le constatez actuellement sur le forum, dans une approche « classique » de gestionnaire, il vous est demandé d’établir des listes de jonctions avec des z1, z2, c0, s4, s6, a0 et a1 et que sais-je encore et ensuite de déterminer quelles cibles pour la signalisation. Mais franchement qui a encore envie de faire cela au 21° siècle ?

Pour les satellites autonomes, ce processus fastidieux est remplacé par un processus de découverte réciproque qui va servir à l’apprentissage des cartes.

Pour pouvoir fonctionner de manière autonome, chaque satellite à besoin de connaitre la topologie de son environnement : Satellite(s) qui le précède(nt), satellite(s) qui le suit (suivent), et ce en fonction de la présence et de la position d’éventuelles aiguilles.

Cette connaissance porte pour une part sur des éléments statique et pour une autre, sur des valeurs variables, donc dynamiques.

Cantons et aiguilles sont par exemple des équipements statiques. Position des aiguilles, présence ou non d’un convoi sur un canton, signalisation lumineuse sont des informations dynamiques qui évoluent avec l’exploitation.

L’identification et la hiérarchisation des équipements statiques est réalisée à l’occasion de ce j’ai appelé « le processus de découverte » ou « discovery ».

La gestion des équipements dynamiques est, elle, totalement autonome en fonction des informations échangées entre les cartes et aussi des commandes envoyées comme le déplacement d’une aiguille ou les commandes de locomotives.

Discovery : le processus de découverte.

A sa première utilisation, chaque satellite se voit attribué un ID (identifiant unique). Cet identifiant est « distribué » par la carte main qui incrémente un compteur pour chaque nouveau satellite « anonyme » se connectant au bus CAN.

Astuce : je recommande avant toute chose d’identifier toutes les nouvelles cartes en les raccordant les unes après les autres au bus CAN. Cette opération d’identification peut être réalisée en une seule fois avant même leur implantation sur le réseau. On peut ainsi raccorder une carte sur le bus puis la déconnecter, en mettre une autre à la place et ainsi de suite. L’identifiant, une fois attribué, est conservé « en dur » dans le satellite, vous pouvez retirer la carte du bus puis initialiser tour à tour toutes vos cartes.

L’ordre dans lequel est attribué l’identifiant d’un satellite n’a aucun lien avec sa position ultérieure sur le réseau. De même, les satellites n’ont pas besoin d’être reliés entre eux en essayant de respecter la topologie du réseau ce qui serait de toutes les façons impossible sur un réseau un peu complexe. Vous chercherez cependant à les disposer à proximité du canton qu’elles pilotent pour minimiser les longueurs de fils avec les capteurs et les servomoteurs.

J’ai cherché à simplifier au maximum cette phase de description du réseau et autoriser avec peu de contraintes les évolutions de configuration.

Le mapping du réseau se fait sur un modèle de découverte (apprentissage ou discovery). On enregistre pour un satellite les satellites qui lui sont directement avoisinants. Un satellite enregistre les identifiants (ID) de ceux qui le suivent ou le précèdent, que ce soit directement ou par l’intermédiaire d’aiguilles et, par un simple système de chainage progressif, nous obtenons toutes les interconnexions des satellites du réseau entre eux.



   
Les boutons poussoirs et le switch du mode Discovery

Pour ce faire, nous utilisons les boutons poussoir Sat- et Sat+ de la carte et des cartes voisines. On se sert également d’un switch à 2 leviers soit 4 états binaires possibles : 00, 01, 10, 11. Les états 0 sont utilisés pour des cantons reliées entre eux sans aiguille ou avec une aiguille droite alors que les états 1 sont utilisés pour indiquer que les cantons sont reliés lorsqu’une aiguille est déviée.

C’est la combinaison de deux boutons poussoirs et d’un switch à quatre états qui va permettre aux satellites d’échanger leurs informations et leurs positions relatives sur le réseau. Cette opération devra être répétée pour chaque satellite (canton).

Très important : Par convention, on réalise toujours le processus de découverte dans le sens horaire, c’est à dire le sens des aiguilles d’une montre. Nous nommons le satellite que l’on est en train de programmer S0, le suivant (dans le sens horaire) S1 ou S+1 ou encore SP1 (pour S « plus » 1). Ceci est vrai quelque soit le sens de roulage des trains par exemple. La seule question à se poser est de savoir si le canton S0 est avant ou après (dans le sens des aiguilles d'une montre) l'autre canton (satellite) auquel on souhaite le relier. Il est après, on appuiera sur le bouton - (moins), il est avant, on appuiera sur le bouton + (plus)

Un même satellite S0 peut avoir jusqu’à trois satellites S+1 qui se distingueront les uns par rapport aux autres en fonction de la position des aiguilles : S+1 droit, S+1 dévié, S+1 dévié 2.

A l’inverse, le satellite se trouvant à anti-horaire de S0 avec ou sans aiguille sera désigné SM1 ou S-1 pour satellite -1. Un même satellite S0 peut avoir jusqu’à trois satellites S-1 qui se distingueront les uns par rapport aux autres en fonction de la position des aiguilles : S-1 droit, S-1 dévié, S-1 dévié 2.

Mais notez qu’au total, dans cette version, un satellite ne peut avoir que 4 aiguilles au total. Par exemple 3 à horaire et 1 à anti horaire ou 2 à horaire et 2 à anti horaire ou encore 1 à horaire et 3 à anti horaire.

Concernant les leviers du switch, il faut entendre que le swith 1 correspond à l’aiguille qui est la plus proche du canton. Le switch 2 correspond à l’aiguille la plus extrème du canton.

Comment fonctionne le système de découverte / apprentissage ?

Quand deux satellites soient reliés sans l’intermédiaire d’une aiguille ou par une aiguille en position droite, les switches 1 et 2 de chacune des cartes seront sur « off ».



Nous appuyons en premier sur le bouton poussoir (-) de S0 (la led rouge clignote) puis sur le bouton poussoir (+) de SP1.

Quand les deux leds s’allument en continu, cela indique que les deux satellites se sont identifiés mutuellement. On peut dès lors relâcher les deux boutons poussoirs.

Prenons maintenant l’exemple où nous avons une aiguille en sortie de canton S0 à horaire. L’ID de « S1 dévié » sera enregistré en basculant le switch de droite du satellite S0 sur « on » puis nous allons à nouveau « appairer » les deux cartes par un appui simultané sur les boutons poussoirs. et la reconnaissance de cette nouvelle carte est opérée quand les deux leds restent allumées. La led rouge en s’allumant en permanence nous confirme une nouvelle fois la bonne exécution de l’opération.

Rien de plus compliqué. S0 connait maintenant l’ID du satellite qui gère le canton « S1 dévié ».

Important : Par convention, pour les satellites autonomes, une aiguille reliée à pointe à un canton appartient à ce canton. Que l’aiguille soit déviée à gauche ou à droite est sans incidence pour le programme.



Maintenant que nous avons relié deux cantons S+1 avec la sortie SO (à horaire), le logiciel déduit logiquement qu’il y a une aiguille et crée automatiquement l’objet logiciel correspondant. Celui-ci apparaît dans l’interface web du satellite et il vous est d’ores et déjà possible de l’actionner et de procéder au réglage des servomoteurs et de tester le rendu. Les valeurs des butées sont renseignées par défaut à 1500, valeur de moyenne pour la plupart des servomoteurs.

Vous noterez que l’appWeb nous renseigne également sur son ID sur les ID des satellites déjà "appairés".



Voyons maintenant comment cela se passe pour une aiguille dont la pointe est reliée à S0 mais côté anti horaire.



Le satellite S-1 est relié à S0 par l’aiguille déviée la plus proche de S0 :
Le switch gauche de S0 est commuté sur « off » et le switch droit est commuté sur « on ». Ne vous trompez pas, le switch le plus à droite représente toujours l’aiguille la plus proche du canton. Le switch 1, lui, l’aiguille la plus éloignée, et ce quel que soit le côté horaire ou anti-horaire. C’est une petite gymnastique à laquelle il faudra s’habituer.

Notez que l’on appuie maintenant sur le bouton poussoir Sat+ de S0 et Sat- de S-1, S0 étant, dans le sens horaire + par rapport à S-1 qui lui est -.

Notez enfin que l’appui simultané sur les deux boutons + et - d’un même satellite a pour effet d’effacer toutes les données enregistrées pour ce satellite.

Pour la suite des explications, nous allons concrètement expliquer la découverte mutuelle des satellites à l'aide du plan qui a été imposé pour l’exercice mais n'hésitez pas d'ores et déjà à poser des questions !
« Modifié: janvier 11, 2024, 05:51:33 pm par bobyAndCo »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1058
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #13 le: janvier 11, 2024, 07:24:59 pm »
Nous avons vu la découverte mutuelle des satellites de manière théorique. Voyons maintenant sur le plan comment cela se concrétise.

Commençons par le cas simple du canton 5 et du canton 7. Il n’y a aucune aiguille ni sur 5 ni sur 7, les switches sont sur off pour les deux satellites. On appuie sur le bouton – de Sat 5 car il est avant Sat 7 dans le sens horaire et on appuie sur le bouton + de Sat 7 qui est après Sat 5 dans le sens horaire.



Pour les cantons 6 et 8, le cas et totalement similaire



Tout comme les cantons 7 et 9



Ou encore les cantons 8 et 10



Pour le canton 2, les cas ne sont pas plus compliqués. C2 étant relié à C6 et à C10 par l’intermédiaire d’aiguilles droites, tous les switches sur ces trois satellites vont rester sur « off ».





Voilà déjà une grande partie de nos satellites reliés entre eux. Nous allons dans le post suivant traiter les cas où l’on trouve les aiguilles A1, A2, A3, A4, A5, A7.
« Modifié: janvier 11, 2024, 07:27:25 pm par bobyAndCo »

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #14 le: janvier 11, 2024, 07:28:29 pm »
Le cas de la boucle intérieure ne devrait pas non plus poser de problème de description, même avec les TJS.
Vu d'un canton, c'est une aiguille simple, voire un "tout droit".

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)