-
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
(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 :
(https://www.locoduino.org/local/cache-vignettes/L768xH486/_dsc1036-d9984.jpg?1700554649)
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
-
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
-
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.
-
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.
(https://www.locoduino.org/IMG/jpg/gestionnaire10.jpg)
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 :
(https://www.locoduino.org/IMG/jpg/gestionnaire_plan_de_base.jpg)
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.
(https://www.locoduino.org/IMG/jpg/decodeur_02.jpg)
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 (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
-
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
-
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
-
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
-
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 !
-
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
-
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
-
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
-
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.
(https://www.locoduino.org/IMG/jpg/_dsc9055-3.jpg)
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 (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.
(https://www.locoduino.org/IMG/jpg/_dsc1036s.jpg)
Vue d’ensemble d’une carte satellite
(https://www.locoduino.org/IMG/jpg/_dsc1036_1s.jpg)
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.
(https://www.locoduino.org/IMG/jpg/_dsc1036_2.jpg)
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.
(https://www.locoduino.org/IMG/jpg/_dsc1036-copies.jpg)
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.
(https://www.locoduino.org/IMG/jpg/_dsc1038s.jpg)
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.
(https://www.locoduino.org/IMG/jpg/_dsc1040s.jpg)
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.
(https://www.locoduino.org/IMG/jpg/_dsc1045s.jpg)
Dans le bas à gauche de la carte, nous avons la partie signalisation.
(https://www.locoduino.org/IMG/jpg/_dsc1045_1s.jpg)
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).
(https://www.locoduino.org/IMG/jpg/_dsc1045_2s.jpg)
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).
(https://www.locoduino.org/IMG/jpg/_dsc1045_3s.jpg)
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).
(https://www.locoduino.org/IMG/jpg/_dsc1045_4s.jpg)
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).
(https://www.locoduino.org/IMG/jpg/_dsc1045_5s.jpg)
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.
(https://www.locoduino.org/IMG/jpg/_dsc1036_aigs.jpg)
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 :
(https://www.locoduino.org/IMG/png/sat_autonome_pinmapping_v4.png)
(https://www.locoduino.org/IMG/jpg/pcbs.jpg)
Et voici le lien de téléchargement du fichier Gerber pour les cartes satellites
https://www.locoduino.org/IMG/zip/gerber_v7.zip (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
-
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.
(https://www.locoduino.org/IMG/jpg/_dsc1036_2.jpg)
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 ».
(https://www.locoduino.org/IMG/jpg/satellites_dicovery1s.jpg)
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.
(https://www.locoduino.org/IMG/jpg/satellites_dicovery2s.jpg)
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".
(https://www.locoduino.org/IMG/png/ecran1.png)
Voyons maintenant comment cela se passe pour une aiguille dont la pointe est reliée à S0 mais côté anti horaire.
(https://www.locoduino.org/IMG/jpg/satellites_dicovery6s.jpg)
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 !
-
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.
(https://www.locoduino.org/IMG/jpg/appairage_5_7.jpg)
Pour les cantons 6 et 8, le cas et totalement similaire
(https://www.locoduino.org/IMG/jpg/appairage_6_8.jpg)
Tout comme les cantons 7 et 9
(https://www.locoduino.org/IMG/jpg/appairage_7_9.jpg)
Ou encore les cantons 8 et 10
(https://www.locoduino.org/IMG/jpg/appairage_8_10.jpg)
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 ».
(https://www.locoduino.org/IMG/jpg/appairage_2_6.jpg)
(https://www.locoduino.org/IMG/jpg/appairage_2_10.jpg)
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.
-
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
-
Bonsoir Christophe
Est il possible avant de passer au cas de la demo du dessin "imposé"
Tu puisses nous décrire les combinaisons applicables pour:
Une bretelle à droite
Une bretelle à gauche
Le cas d'une TJD étant proche d un combo de ces deux usages faut il l aborder comme tel
Un cas de croisement
D avance merci
Laurent
-
Si tu veux bien, je vais me concentrer sur la demande et éviter de m’éparpiller façon puzzle et aussi pour que ceux qui suivent ce fil ne soient pas non plus noyés.
Ce n'est pas moi qui ai travaillé sur le plan imposé.
Christophe
-
Nous voici donc sur l’étude des intersections entre c0 et c6, c1 et c5 et c0 avec c5.
Ces liaisons sont réalisées par l’intermédiaire d’un appareil de voie assez sophistiqué qui s’apparente à un croisement de voies mais avec en plus deux aiguilles permettant de se diriger de c5 vers c1 si l’une des aiguilles est droite, vers c0 si elle est déviée.
De même, l’autre aiguille droite relie c0 à c6 (par l’intermédiaire de A2 déviée) et c0 à c5 si elle est déviée.
(https://forum.locoduino.org/index.php?action=dlattach;topic=1645.0;attach=5545;image)
Commençons par la liaison la plus simple que vous allez facilement reconnaître, c5 vers c1. c5 est à horaire de c1 et on accède lorsque l’aiguille A1 est droite.
(https://www.locoduino.org/IMG/jpg/gestionnaire4aiguilles_0.jpg)
Voyons maintenant c0 vers c6. Cette liaison est possible si l’aiguille A2 est déviée, c’est ce que l’on indique en commutant le switch de droite du satellite s6. Pour c0, on accède avec l’aiguille A3 droite, les deux switches de s0 sont donc sur off.
(https://www.locoduino.org/IMG/jpg/gestionnaire4aiguilles_1.jpg)
Pour c0 vers c5 (ou c5 vers c0), pour des questions de logique interne au programme, nous allons déclarer que la connexion se réalise quand A1 et A3 sont déviées. Vous constatez donc que les switches de droite de s5 et de s0 sont commutés sur « on » pour indiquer, aiguilles déviées.
(https://www.locoduino.org/IMG/jpg/gestionnaire4aiguilles_3.jpg)
Dans la pratique, il ne sera donc possible de passer de c5 à c0 (ou l’inverse) que si les deux aiguilles A1 et A3 sont déviées. Le passage de c5 à c1 ne pourra se faire que si A1 est droite ET A3 déviée, ce qui rend l’itinéraire c6->c0 impossible.
De même, pour aller de c6 à c0, l’aiguille A3 devra être droite et A1 déviée, condition pour éviter une éventuelle collision. Ceci est traité de manière logicielle et nous verrons cela un peu plus tard.
Je ne vais pas faire affront à votre intelligence en vous décrivant le mécanisme pour A7, A5 et A4 qui est la symétrie de ce que je viens de présenter.
Voilà, nous avons terminé tout le processus de découverte du réseau et des liaisons entre les cantons.
Il ne reste plus maintenant qu’à placer les équipements de détection (Railcom, capteurs ponctuels, consommation de courant), placer les signaux lumineux, souder les fils, régler vos servos d'aiguilles et vous pourrez jouer au train sur votre réseau en toute sécurité.
Christophe
-
Bonsoir
Merci Christophe pour ce complément.
Si à la place d avoir une TJS nous avons une TJD pour A1 13.
Ce changement d appareil offre une liaison supplémentaire entre C6 et C1
Aussi les combinaisons décrites précédemment restent valables:
Positions géographiques:
La liaison "droite" et la position géographique des lames pour avoir un liaison C5-C1
A1 droite et A3 droite <==> liaison C5 - C1
A1 déviée et A3 droite <==> liaison C5- C0
A1 droite et A3 déviée ==> non tracé
A1 droite et A3 déviée et A2 droite <==> non trace
A1 droite et A3 déviée et A2 déviée <==> C6 - C1
A1 déviée et A3 déviée et A2 déviée <==> C6 - C0
On voit bien que la position de A2 va être importante ( elle fermera le carre de C2 devant A2)
Elle priorisera ou non le lien entre C5 ou C6 pour la liaison vers C1 ou C0 ( selon A1 et A3)
Ainsi A2 dévié A1 droit et A3 déviée donnerait une sortie sur C6 prioritaire sur une entrée C5 vers C1 ou C0?
Est ce bien cela?
Laurent
-
@Laurent,
Oui c'est bien cela !
Christophe
-
Hello
Y a t il une possibilité d'initialiser/associer la position géographique ( direction des lames) avec la position du moteur qui peut selon son orientation physique être "0 "ou "1" pour une direction donnée? (cas de montage des servo en "reverse")
Je pense à cette conf via ton interface lors du réglage des positions
Ltr
-
@Christophe
Perso j attends la suite AVEC UNE TRES GRANDE IMPATIENCE!
Plusieurs raisons à cela:
- approche novatrice ( tu est sur de l'inédit)
- approche éprouvée (tu l as testé!)
- combinaisons associations de techno ( BAL, RAILCOM, ...)
Il y a encore beaucoup d'éléments dont tu vas procéder aux descriptions et qui nous permettront de mieux nous approprier concepts et solutions.
Hate d y etre !
Un TRES GRAND MERCI pour les explications que tu nous donnes.
Ltr
-
@Laurent,
Je ne suis pas sûr de bien comprendre la question, mais je vais faire une réponse et tu me diras si c'est de cela que tu veux parler.
Sur l'interface web pour les réglages, tu as une valeur pour l'aiguille déviée et une autre pour l'aiguille droite. La première pouvant être inférieure à la seconde ou vis et versa ce qui autorise différentes possibilités de montage du servo.
A la première utilisation, les servo se mettent tous en position "aiguille droite". Ensuite, quand on quitte le jeu et pour peu que l'on fasse une sauvegarde globale avant d'éteindre, les positions d'aiguilles sont sauvegardées dans leur position. Au prochain démarrage, au besoin le système va remettre les aiguilles comme elles étaient.
Dans les commandes d'aiguillage, il n'y a pas de commande de type "dévié" ou droit mais "va à la position inverse de là où tu es". Si donc on est droit, un appui sur un BP par exemple fera aller à dévié, un nouvel appui sur le BP fera aller à droit.
Est-ce que ça répond à tes questions ?
-
Merci Christophe
Oui parfaitement!
En effet l'étalonnage du servo est un réglage particulier qui doit être traité. ( selon un process/menu dédié comme tu l'as prévu)
J essaye d être didactique pour que les néophytes ou moins expérimentés avec ces composants puisse mieux comprendre leur mise en œuvre simplifiée.
Par ailleurs mécaniquement les positions et orientations pouvant être croisées il est donc bon de pouvoir les croiser comme tu l as indiqué.( cela joue directement sur la polarisation de la pointe de cœur via un éventuel relais de commutation)
Ltr
-
cela joue directement sur la polarisation de la pointe de cœur via un éventuel relais de commutation
Là c'est le must ! Pour la continuité électrique et aussi parce que le relais de commutation permet, en récupérant l'état, de s'assurer que la commande a bien été exécutée. Ce n'est pas une commande "aveugle" et on a bien un accusé de réception de l'exécution.
Je n'ai pas vu dans le commerce ce type de support. En DIY, Jean-Luc en avait fait des sympas n impression 3D. Peut-être s'il nous lit accepterait-il de publier les STL ?
-
Nous allons maintenant nous intéresser ici à l’équipement qu’il faut positionner sur chacun des cantons. Je précise que ces équipements ne sont pas très différents de ce que l’on rencontre sur n’importe quel réseau.
(https://www.locoduino.org/IMG/jpg/canton-et-appareils.jpg)
Je ne fais ici la représentation que d’un seul type de canton car cela est absolument identique pour tous les cantons hormis les servos dont le nombre dépendra du nombre d’aiguilles.
- Une carte satellite ici en violet. Je rappelle qu’il n’y a qu’un seul type de cartes satellites et que les programmes sont identiques pour toutes les cartes.
- Une carte de détection Railcom® qui va nous apporter deux informations, l’occupation ou non du canton par une locomotive et surtout, l’adresse de cette locomotive qui va par exemple nous permettre d’envoyer des commandes à la centrale DCC comme un ordre de ralentissement ou un ordre d’arrêt.
- Deux capteurs ponctuels (ici des capteurs infra rouge) placés judicieusement à bonne distance des extrémités de canton ou d’appareils de voie de telle manière à ce que les distances d’arrêt soient suffisantes et aussi une zone de cantonnement suffisante pour contenir la totalité d’un convoi.
- Un signal lumineux et éventuellement un second à l’autre extrémité si votre canton est à double sens de circulation.
- Autant de servomoteurs que d’aiguilles (maximum quatre dans cette version)
- Enfin, un capteur par consommation de courant. Celui-ci n’est pas obligatoire car Railcom® assure déjà la détection de la locomotive. Mais la locomotive peut être déjà sortie du canton (donc plus détectée par Railcom®) sans que pour autant la totalité du train ait libéré le canton. Si vous gérez manuellement vos locomotives, c’est acceptable, mais si vous souhaitez vous reposer sur des automatismes, il faudra détecter en plus la consommation de courant résultant par exemple d’une résistance placée sur le dernier essieu du convoi.
Il vous reste à équiper l’ensemble de votre réseau de manière identique.
Si vous avez suivi le déroulement de ce fil, vos programmes sont déjà téléchargés dans les satellites. Il nous faut faire un dernier passage par l’interface web qui permet de régler chaque satellite individuellement. Nous avons vu le réglage des buttées de servomoteurs, vous avez pu tester le déplacement de vos aiguilles et constaté que les contacts avec le rail principal étaient assez fermes.
(https://www.locoduino.org/IMG/jpg/interface2.jpg)
Vous allez donc décocher le mode wifi (vous n’en avez plus besoin) et le mode Discovery. Cette désactivation va avoir pour effet de redémarrer l’ESP32 en désactivant tout le code du mode Discovery, économiser ainsi de l’espace en mémoire et des performances de calcul et redémarrer en mode exploitation !
N’oubliez d’installer pas la centrale DCC compatible Railcom® que vous pouvez télécharger ici : https://github.com/BOBILLEChristophe/DCCxx-ESP32-Railcom (https://github.com/BOBILLEChristophe/DCCxx-ESP32-Railcom)
La centrale DCC est au protocole DCC++ et donc pilotable avec tous les logiciels compatibles. Vous pouvez installer ce logiciel sur LaBox de Locoduino dont nous avons beaucoup parlé dernièrement. Vous trouverez ici des informations à ce sujet : https://www.locoduino.org/spip.php?article334 (https://www.locoduino.org/spip.php?article334)
En bonus une petite vidéo :
https://www.youtube.com/watch?v=qTaGxd1uDpA&ab_channel=ChristopheBOBILLE
La 231 G libère le premier canton mais stationne sur le suivant. Du coup, la petite 030 va ralentir au moment de son passage sur le premier capteur, puis s'arreter au passage sur le second capteur. La vidéo n'est pas parfaite mais en faisant attention vous verrez le changement des leds de signalisation que j'ai soudées directement à la carte. Je précise que c'est réalisé sans trucage !!!
Ca y est, cette fois, vous pouvez jouer au train en toute sécurité et en toute sérénité.
Nous en avons terminé avec l’installation et c’est sans doute le bon moment pour répondre à toutes les questions que vous pourriez avoir.
Dans les postes à suivre, j’expliquerai le contenu des programmes mais je vous rassure, il n’est absolument pas nécessaire de lire ce qui va suivre. Cela est surtout destiné à ceux qui souhaitent comprendre le fonctionnement du programme.
-
Bonsoir
J ai quelques questions que vont aussi se poser ceux qui voudront se lancer dans la réalisation.
Focus sur les positions des coupures/ isolations.
1 le capteur ponctuel en entrée de canton joue t il immédiatement un rôle ( circulation de droite à gauche )ou son rôle de borne t il uniquement à donner l’ordre final d arrêt dans le sens de circulation vers la fin d un canton? ( send de circulation de gauche a droite )
2 le capteur railcom: tel que place sans coupure la détection se fait sur l ensemble du canton
Ici entre cote droit par une coupure sur chaque rail et côté aiguillage qui appartient au canton juste après chaque branche sur chacun des rails.
Aussi tt présence sur une part de se segment est détectée par la carte satellite.
( que le message soit railcom ou non!)
Les capteurs pour ponctuels informe d une position précise.
Le capteur de conso conforte une détection globale y compris sur l’aiguille sans coupure supplémentaire .
-
Je poursuis le questionnement
Si à défaut de capteur ponctuel par infra rouge on décide de mettre localement des capteurs par détection de courant comment allons-nous procéder!?
Comme on veut récupérer les info railcom on peut considérer devoir garder ces info pour toute présence sur le canton
En revanche on veut savoir si une sous section de ce canton est occupée ou non.
On pourrait par exemple avoir alors pour un canton banalisé comme décrit 3 détecteurs railcom.
1 global et 2 comme detecteur ponctuel chacun
On pourrait alors sortir sur une diode chaque sortie de capteur ponctuel, la placer en entrée du capteur railcom ( parallelisation des états de sortie des capteurs) et en entrée individuelle de capteur ponctuel.
Ce n est pas économe en composants mais on peut ajuster le hard en conséquence pour y parvenir ( 1 seul régulateur pour les -18mv +18mv pour les 3 zones et donc on a juste a doubler les lm339 et le 74hc02 avec quelques résistances et diodes .
D autres types de capteur par conso sont possible aussi mais on aura alors pas railcom en info.
A voir ou trouver un optimum.
En revanche il y a une question magique !
Si on a un train sur notre canton alors son adresse railcom est transmise et l’occupation du canton confirmée .
Dans le cas du réseau de demo la tjs qui appartient à c5 est dans une description analogue au canton de demo de christophe.
En revanche cette section peut être parcouru par un train qui va de c6 à c0 ( ou l’inverse )
Hors ce train emmet sur railcom et sa presence sans coupure supplémentaire va indiquer une présence sur la dernière section du canton que nous avions associé à un capteur de détection de courant .
Dans ce cas de figure il me semble qu il y a un une magie qui s opère.
On ne peut avoir que un seul engin qui émet en railcom canal 1 par canton.
En effet il se peut que le train qui parcourt c5 n est pas encore arrive sur la zone d arrêt donc une détection sur la tjs d un train qui n est pas celui sur c5 ne doit pas l’arrêter puisque pas encore arrivé sur la ZA de C5. Idem le franchissement de la tjs n influe tout au plus que sur les signaux environnants.
Que se passe t il alors si pareil cas se présente ? ( presence sur la tjs et train en mouvement sur c5?)
Faut il un découpage interne avec repiquage d alim …!?
Ltr
-
Bonjour Laurent et merci pour ces questions. Je commençais à me demander si cela intéressait quelqu’un !
1 le capteur ponctuel en entrée de canton joue t il immédiatement un rôle ( circulation de droite à gauche )ou son rôle de borne t il uniquement à donner l’ordre final d arrêt dans le sens de circulation vers la fin d un canton? ( send de circulation de gauche a droite )
Oui les capteurs ponctuels jouent immédiatement un rôle et même plusieurs.
Le premier rôle est de renseigner sur le sens de roulage du train sur le réseau (vers horaire ou vers anti horaire). En effet, même Railcom ne donne pas cette info. Railcom peut nous dire que la locomotive va en avant ou en arrière. Mais si la locomotive est inversée sur les rails ? Donc, le premier capteur ponctuel activé nous renseigne de manière certaine par quel côté entre le train.
Ensuite, comme tu le précises, s’il doit y avoir ralentissement puis arrêt de la locomotive, c’est le passage sur le premier capteur qui provoquera le ralentissement et le passage sur le second qui activera l’arrêt.
Cela permet d’avoir le même équipement pour une voie qui serait à double sens de circulation. Les capteur joueront un rôle inverse.
2 le capteur railcom: tel que place sans coupure la détection se fait sur l ensemble du canton
Ici entre cote droit par une coupure sur chaque rail et côté aiguillage qui appartient au canton juste après chaque branche sur chacun des rails.
Tout d’abord, pour la détection Railcom avec les cartes ici proposées nécessite d’isoler les deux rails. Ce qui, sur le petit schéma proposé veut dire deux isolations à droite et quatre à gauche (sur chacun des rails de l’aiguille).
Est-ce que la coupure est juste après l’aiguille ? La règle est celle du cantonnement qui veut que la zone de cantonnement soit suffisante pour accueillir un convoi dans son ensemble. Si donc l’espace après la première aiguille n’est pas suffisant pour cela, on va reculer la position de la coupure jusqu’à (proximité d') une nouvelle zone de cantonnement.
Pour le capteur de consommation, j’ai précisé son intérêt qui est effectivement de mesurer sur l’ensemble de la zone qu’il n’y a pas quelque chose de présent et qui consomme du courant (locomotive, wagon avec essieu et résistance, wagon avec éclairage intérieur et/ou fin de convoi…). Avec Railcom, si la locomotive est sortie de la zone, plus de détection alors que des wagon peuvent encore y être !
Je profite pour revenir sur une idée que tu avais émise un jour et que je trouve intéressant de reprendre ici, à savoir une mesure de courant décentralisée et sur chaque canton. Il y a de multiples avantages :
Fiabilité de la détection et rapidité de la coupure locale (et non globale)… Mais aussi, la valeur retournée dans ce cas est significative, est-ce plutôt une locomotive ou simplement un wagon.
Je serai très intéressé que tu m’aide à implanter une telle lecture de courant sur une carte satellite autonome.
Si à défaut de capteur ponctuel par infra rouge on décide de mettre localement des capteurs par détection de courant comment allons-nous procéder!?
Il ne faut pas le faire à mon sens et ce que je dis précédemment le démontre bien je crois.
Pour la suite de tes questions/suggestions, tu m’excuseras mais je ne comprends pas ce que tu veux dire !!!
Christophe
-
Bonjour et merci pour ces premières réponses.
Je ne suis pas le seul intéressé mais il y a beaucoup de timides :)
Comme il peut m'arriver de me tromper et d'apprendre en même temps je vais reformuler mes sollicitations.
Mon expérience avec les détecteurs de présence ou leur absence est que si on veut avoir une vitesses constante de déplacement sans à-coup des engins moteurs alors il faut que les chutes de tensions soient similaires sur toutes les zones ( de détection vs de non détection)
Dans le cas contraire si ABC est activé on risque des déclanchements "abusifs". Pour s en prémunir on "lisse" le tout" et on gagne visuellement une meilleure régularité au prix de quelques diodes, sacrifice que je pense acceptable.
Je me suis posé la question de savoir quel type de détection poser sur ton "cœur satellitaire" avec son entrée détection RC et sur les capteurs ponctuels.
J ai émis l'hypothèse suivante:
on garde la détection RC qui assure aussi la détection globale (il me semble)
on la complète du même dispositif pour les capteurs ponctuels ( LM339 et 74HC02 +diodes et résistances ) pour chaque capteur ponctuel.
Mais les sorties de ces capteurs ponctuels sont aussi des info RAILCOM que l on peut envoyer vers l entrée RAILCOM en séparant les flux par une diode afin d avoir une entrée "OU" à trois entrées sur le satellite en entrée détection RAILCOM.
Chaque capteur ponctuel allant lui aussi via une autre diode (pour équilibrage electrique) vers l entrée ponctuelle correspondante sur le satellite)
La ou c est un peu plus complexe c est le découpage des rails associé à cette implémentation, notamment pour le cas de l'aiguille en pointe qui devrait être" autonome" en terme de détection elle aussi pour éviter un faux positif si un engin sur le canton en cours n est pas encore arrivé sur la section d'arrêt et qu' un train parcourt l aiguillage alors mis dans une liaison entre autres cantons mais transitant par le canton en cours. (qui alimente l appareil en pointe, sur le reseau de demo c est la TJS qui est dans ce cas)
Sauf peut être à se baser sur RAILCOM en complément car l ordre d arrêt serait former dans ce cas de la combinaison de :
- présence RAILCOM sur le canton en cours
- passage sur le capteur ponctuel d entrée qui force le ralentissement pour l'adresse RC en cours
- arrivée sur le capteur ponctuel de sortie avec le même ID RAILCOM que dans le canton alors on procède à l arrêt
Si l ID railcom est diffèrent ou qu'il n existe pas ( détection de courant simple sans railcom = cas d un wagon avec éclairage ou essieux résistif ou d un autre engin moteur ayant un ID diffèrent) alors il n y a pas d ordre d arrêt.
La seule limite que j entrevois et le cas de convois en pousse avec loco à l'arrière. ( qui imposerait une émission RAILCOM à l avant du convoi) ( moins pratique pour des convois en manœuvre mais le but des satellites est surtout de permettre une exploitation de circulation de convoi "en poursuite" avec sécurité des itinéraires)
Couvrir l exhaustivité des cas n est pas simple! Même si bcp de cas sont déjà pris en compte ici.
-
@Laurent,
Comme je te l'ai déjà dit, toutes ces interrogations et cogitations sont intéressante mais ne doivent pas être traitées ici. Le but de ce fil est de présenter le concept et surtout sa mise en œuvre "simple" pour un public peu ou pas expérimenté.
Il est certains que ce concept poussé plus avant doit permettre des choses assez puissantes mais c'est vraiment un autre sujet (un autre fil pourquoi pas ?). Et comme je te le disais également, je dois rester concentré sur celui-ci pour faire fonctionner cette première étape à coup sûr avant d'aller plus loin.
Christophe
-
Pas de soucis
Peux tu nous parler des capteurs ponctuels que tu utilises ( ref, type, mise en œuvre)? ( et comme tu les as testé les écueils desquels il faut se prémunir...)
Ltr
-
Pas de soucis
Peux tu nous parler des capteurs ponctuels que tu utilises ( ref, type, mise en œuvre)? ( et comme tu les as testé les écueils desquels il faut se prémunir...)
Ltr
Les capteurs ponctuels à infra rouge que j’ai retenus.
Comme beaucoup sans doute, j’ai essayé plein de choses. Les capteurs à effets Hall ont eu longtemps ma préférence, ils sont discrets, économiques et très fiables. Leur principal inconvénient est qu’il faut fixer un aimant sous la loco et parfois cela pose des problèmes. Et puis, certains finissent par se décrocher provoquant parfois des dégâts.
J’ai découvert les TCRT5000 (seuls) il y a déjà un petit moment, je les ai testés dans différentes configurations. Ca fonctionnait bien mais c’était très délicats de trouver le bon réglage.
Et puis j’ai testé des modules chinois tout assemblés qui me coutaient moins cher que le seul TCRT5000, très simples à régler avec la résistance variable et surtout très fiables.
https://www.youtube.com/watch?v=kLCSsNo7pS8&ab_channel=ChristopheBOBILLE
Voici un exemple sur Ali à 1,07€ : https://fr.aliexpress.com/item/32703689686.html
J’en suis vraiment très content et je n’ai depuis plus aucun problème. Ceux-ci fonctionnent à une fréquence (38 Khz je crois) qui les rend vraiment insensibles aux éclairages extérieurs communs (lumière du jour, ampoules...).
Je recommande de placer à l’avant de la locomotive un petit papier blanc autocollant qui accélère considérablement la vitesse de détection.
-
Présentation du programme.
Pour découvrir le programme commençons par un rapide survol global.
Voici la liste des différents fichiers dans lesquels sont réparties les différentes parties du programme.
(https://www.locoduino.org/local/cache-vignettes/L400xH1009/fichiers_globaux-2-40ef3.png?1700583422)
Le cœur du programme est contenu dans les fichiers Node.h et Node.cpp. J’ai choisi Node (nœud en français) car le satellite autonome est avant tout un nœud dans une chaine, un ensemble d’autres satellites avec lesquels il échange et collabore.
Node est un peu le « cœur de satellite ». Les membres de la classe Node représentent "en logiciel" les objets physique du canton. Ce même fichier contient une autre classe NodePeriph qui elle "symbolise" de manière épurée les satellites "voisins". L'instance de la classe Node initialise huit instances de la classe NodePeriph, nombre maximal de satellites "voisins" possible dans cette version.
Les fichiers Aig, Loco, Sensor, Signal sont les éléments logiciels qui figurent ces objets physiques et les méthodes, les actions de ces objets physiques.
Railcom est à rapprocher de ces fichiers en ce sens qu’il apporte des informations sur l’éventuelle présence d’une locomotive sur le canton en nous précisant l’adresse de cette locomotive.
Settings contient tout ce qui est nécessaire au paramétrage du satellite. C’est par l’intermédiaire des fonctions contenues dans ce fichier que l’on lit ou que l'on sauvegarde le fichier json où sont regroupées les données de paramétrage.
Discovery contient tous les éléments logiciels qui permettent le processus de découverte présenté précédemment. Discovery est activé par défaut au premier lancement de la carte satellite. Une fois la configuration globale réalisée, on doit désactiver le mode Discovery pour activer GestionReseau qui maintenant restera activé en permanence jusqu’à ce que l’on active à nouveau Discovery pour une extension par exemple.
GestionReseau contient toutes les fonctions qui vont analyser tous les messages CAN reçus par le satellite. Je rappelle que chaque satellite envoie toutes les 100 milli secondes environ les principales données le concernant : présence d’une locomotive et adresse de cette locomotive, position de ses aiguille, cantons à partir desquels il est possible d’accéder.
Nous verrons plus tard en détail comment chaque satellite traite les données reçues des autres pour adapter son propre comportement.
Enfin, le fichier main.cpp qui correspond au fichier « .ino » sous l’IDE Arduino. C’est le premier fichier appelé au lancement du microcontrôleur. On y trouve principalement les instances des objets logiciels et aussi l’activation des méthodes de ces différents objets logiciels.
Je ne m’attarderai pas sur les fichiers Wifi, WebHandler, Config et même Can qui ne sont que des programmes « utilitaires » permettant le fonctionnement de l’ensemble.
Voilà pour la présentation globale des fichiers du programme. Nous verrons dans les postes suivants le fonctionnement détaillé des principaux d’entre eux.
-
Bonjour,
J’ai découvert les TCRT5000 (seuls) il y a déjà un petit moment, je les ai testés dans différentes configurations. Ca fonctionnait bien mais c’était très délicats de trouver le bon réglage.
Et puis j’ai testé des modules chinois tout assemblés qui me coutaient moins cher que le seul TCRT5000, très simples à régler avec la résistance variable et surtout très fiables.
Comment installes-tu ces capteurs ? Sous la voie ? Sous la plateforme ?
Tu es en HO ?
Je ne suis pas le seul intéressé mais il y a beaucoup de timides
On n'est pas timides, mais c'est du haut niveau !
-
On n'est pas timides, mais c'est du haut niveau !
Merci de plonger dans le bain ! Non ce n'est pas du haut niveau. C'est nouveau, assez différents dans les concepts des approches "classiques" mais facile à appréhender. Posez toutes les questions que vous voulez, aucune n'est idiote et mettra en avant un manque de précision de mon côté que je m'empresserai de corriger pour les autres. Donc tu vois, en plus tu feras une BA.
Comment installes-tu ces capteurs ? Sous la voie ? Sous la plateforme ?
Tu es en HO ?
Oui je suis en HO, mon plateau fait 6mm d'épaisseur, je positionne sous le plateau.
Question suivante :D
-
En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.
Connectés à un satellite V1 ils envoient les messages Can (seulement quelques pins dans les satellites autonomes).
https://forum.locoduino.org/index.php?topic=290.msg12026#msg12026 (https://forum.locoduino.org/index.php?topic=290.msg12026#msg12026)
-
@dmskd N'hésite pas à présenter ton réseau (ou ton projet). Où tu en es dans la construction. Si tu es intéressé par ce principe et j'essayerais de te donner les meilleurs renseignements.
Eventuellement aussi d'autres conseils comme pour le câblage pour éviter des erreurs.
Christophe
-
En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.
Connectés à un satellite V1 ils envoient les messages Can (seulement quelques pins dans les satellites autonomes).
https://forum.locoduino.org/index.php?topic=290.msg12026#msg12026 (https://forum.locoduino.org/index.php?topic=290.msg12026#msg12026)
Merci Dominique pour cette info.
Il faudra aussi qu'un jour on fasse un corpus des meilleurs solutions. Je n'hésite pas à avancer meilleures car nous les avons testées éprouvées alors autant en faire profiter d'autres plutôt que de les laisser galérer
-
Avec Locoduino on apprend tous les jours. 8)
Il faut être curieux et rigoureux. Parfois cela demande du temps avant de s'approprier des concepts, des syntaxes mais c est point de passage.
Locoduino essaye d être le plus didactique possible sur de nombreux sujets. ( et y contribuera encore longtemps!)
Pour te rassurer Dominique (@dmskd) , je ne suis pas toujours "confort" avec toutes les rubriques. J'y vais donc par étapes.( J explore aussi beaucoup c est vrai!)
Comme le propose Christophe ici point besoin de connaitre tous les détails puisque le premier niveau de compréhension et d identifier le fonctionnement global du satellite autonome et d'en faire le rapprochement avec son réseau ferroviaire. ( et ses besoins)
La mise en place de ce projet se veut rapide, répétitive en étant très innovante.
Pour rassurer, Christophe qui utilise comme moi PlateformIO comme IDE ( interface soft comme l'IDE ARDUINO) produit un fichier main.cpp.
Sous IDE ARDUINO il faut le renommer en main.ino
Cela sera le seul "truc" compliqué à faire pour être sous cet IDE et utiliser les fichiers fournis.
Laurent
-
En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.
Sur mon réseau (N) j'utilise des capteurs équivalents (ITR9909) mais pour les positionner au raz des traverses, ça oblige à en couper 2.
Dans les parties cachées (il n'y en a que là) ce n'est pas gênant, mais ailleurs ce serait quand même un peu voyant.
@bobyAndCo
Pour la programmation et les cartes électroniques, je me débrouille.
Le haut niveau est pour moi le suivi des trains sur le réseau par le gestionnaire.
Mon petit réseau actuel est exploité entièrement en manuel (à partir d'une tablette), à part quelques sécurités dans la gare cachée.
Mais le futur réseau est beaucoup plus ambitieux, et je n'échapperai pas à me triturer le cerveau pour comprendre comment gérer la circulation des trains.
Ce qui m'inquiète c'est la multiplication des cartes électroniques : cartes RailCom, cartes pour décoder les messages Railcom, cartes de détection de présence... Quand il y a beaucoup de cantons, ça fait beaucoup de cartes.
Tu veux des questions, en voici une.
Je comprends que la détection RailCom génère un signal relativement faible. Je suppose que les cartes doivent être proches de la voie.
-
Bonsoir Christophe
Je commence a mieux comprendre/identifier certains de mécanismes sous jacents que tu as mis en œuvre et que tu nous détailleras très bientôt.
J ai bien vu que l utilisation de capteur optique dans leur rôle de postions en capteur ponctuel représente un net avantage de mis en ouvre simple et léger :)
Je pense que je proposerai et vous présenterai bientôt un redesign du circuit de détection RC incluant également les éléments traitants ces capteurs ponctuels tels que nous les a présenté Dominique ( source G BUNZA). Ceci facilitera fortement la mise en place de la solution satellites autonomes.
J ai une question d'ordre fonctionnel:
Dans le réseau de démo sur la TJS:
Si nous avons un train en mouvement sur C5 vers A1 qui est déviée alors le bloc agira et lorsque la loco se présentera dans C5 sur le capteur ponctuel d entrée, le ralentissement va s'opérer jusqu' à l arrivée sur le capteur de "sortie" proche de A1 ou s arrêtera le convoi (machine en tête ou en queue)
Toutefois que se passe t il si un engin est détecté sur la TJS alors que
le train n'est pas encore dans C5: ici le train sur la TJS ( et surement en mouvement entre C2 ou C0) sera détecté par le capteur RAILCOM de C5, ne va t on pas alors arrêter le mauvais convoi? ( puisque c est l adresse de ce train qui va être associée au canton C5 car FIFO? ( First IN dans le satellite)
le train est dans C5: on a alors un imbroglio pour la lecture de l adresse RAILCOM car 2 engins ne peuvent emmètre en même temps ( tout cela est peut être très théorique mais me semble être des combinaisons plausibles d'enchainements de différents mouvements).
J ose en déduire qu' il faut donc en principe que le train dans C5 s'identifie avant qu'une possible détection émettant sur la TJS ne vienne placer son adresse dans le satellite.
ou bien que la solution peut reposer sur une détection de présence seule (par conso de courant) et non railcom sur une aiguille en pointe?
Peut être as tu d autres mécanismes que tu dévoileras très bientôt aussi lorsque tu vas aborder le fonctionnement des briques du programme.
Une autre question plus d ordre implémentation à propos de la frequence d émission des messages que tu as mis sur 100 millis sec. ( 0.1 secondes)
Cette frequence parait très rapide de prime abord et on pourrait penser que 1/4 de seconde ( par exemple donc 0.25 secondes) semblerait suffisant. Aussi pourquoi aller "aussi vite" dans l envoi des trames toutes les 100millis sec? N'émet t'on pas que ce qui as changé?
Je réserve (déjà) d autres questions pour le traitement en enfilade des aiguilles pour la suite... ;)
Ltr
-
Bonsoir Dominique
Je vais essayer de t apporter aussi quelques retour d'info sur les sujets que tu soulèves ( retours d expériences en la matière)
Tu soulignes que le nombre de cartes augmentent et que leur localisation a de l'importance dont celle liée à la détection RAILCOM du fait des faibles tensions présentes dans le processus d émission.
Un bit 0 ou un 1 Railcom dure 4us ( 4 micro secondes). Il repose sur le déstockage de l énergie emmagasinée précédemment au CUTOUT pour opérer.
La norme a codifié cela ( RCN210 et RCN 217) et encodé les messages par soucis de sécurisation des contenus ( encodage 4-8).
Il est envident que plus un signal et propre et mieux il est traité sinon il n'est pas jugé conforme et est donc ignoré. ( donc préférer des distances courtes et non parasitées reste toujours préférables mais on est pas à qq dizaines de cm prêt ici) ( c est moins le cas par exemple avec des servos plus sensibles au parasitage)
Les satellites autonomes reposent sur une mise en place distribuée (c est à dire proche des zones à équiper) comme l étaient les satellites V1 de LOCODUINO.
Le PCB présenté par Christophe regroupe le "cœur" et se voit complété d' un circuit dédié pour la détection ( je devrais dire de circuits pour les détections).
L'approche segmentée présente plusieurs avantages:
répartition par blocs fonctionnels
réparation/substitution en cas de panne de façon simplifiée
optimisation des placements
Je l ai annoncé dans mon post précèdent je proposerai un new design pour la carte gérant les détections.
On peut surement envisager d autres formes de PCB mais cela reste un redesign initial du travail de Christophe.
Je veux bien y contribuer fortement puisque je suis plus à l'aise avec le design des PCB que le C++! :P ::) 8)
Personnellement je vois plutôt une implémentation du bus I2C pour la gestion des signaux que des 95HC... mais c est la une affaire de gouts :)
Cet usage pourrait être étendu aux commandes pour les servos ou des relais de commutation des pointes de cœur voir à des retours d info de capteurs externes via ce canal...
Les possibilités ne manquent pas et j ai déjà eu l occasion d en discuter avec Christophe qui rappelons le encore propose une solution novatrice et déjà éprouvée.
Le nombre d I/O sur l ESP 32 et leur utilisation rend l'utilisation du bus I2C comme une alternative à leur extension de façon simple.
Pour ma part j aime bien la SX1509 très polyvalente mais un PCA9685 offre aussi son lot de possibilités!
pour le SX1509: https://learn.sparkfun.com/tutorials/sx1509-io-expander-breakout-hookup-guide/all (https://learn.sparkfun.com/tutorials/sx1509-io-expander-breakout-hookup-guide/all)
ex PCA9685: https://www.aranacorp.com/fr/utilisation-dun-module-pca9685-avec-arduino/ (https://www.aranacorp.com/fr/utilisation-dun-module-pca9685-avec-arduino/)
Vivement la suite! :)
Ltr
-
Je comprends que la détection RailCom génère un signal relativement faible. Je suppose que les cartes doivent être proches de la voie.
@Dominique. Laurent répond bien à ta question. Moins on a de câbles sur le réseau et mieux c'est. Moins on a de longueur pour chaque câble et mieux. C'est l'un des énormes avantages des satellites où toute la rétrosignalisation et les commandes sont véhiculées dans un bus (CAN) très peu sensible aux interférences et qui plus est, dans le cas des satellites autonomes transitent dans du câble RJ45 torsadé et blindé.
-
Je l ai annoncé dans mon post précèdent je proposerai un new design pour la carte gérant les détections.
Personnellement je vois plutôt une implémentation du bus I2C pour la gestion des signaux que des 95HC... mais c est la une affaire de gouts :)
Cet usage pourrait être étendu aux commandes pour les servos ou des relais de commutation des pointes de cœur voir à des retours d info de capteurs externes via ce canal...
Les possibilités ne manquent pas et j ai déjà eu l occasion d en discuter avec Christophe qui rappelons le encore propose une solution novatrice et déjà éprouvée.
Le nombre d I/O sur l ESP 32 et leur utilisation rend l'utilisation du bus I2C comme une alternative à leur extension de façon simple.
Bonjour Laurent,
Tout d'abord, merci de t'impliquer comme tu le fais dans ce projet. Effectivement, les domaines où nous sommes respéctivement le plus à l'aise sont complémentaires et ça peut contribuer beaucoup à faire avancer ce projet.
Pour la mesure de courant sur chaque satellite ce serait un énorme plus de pouvoir intégrer un ACS-712 (ou autre). Je rappelle que c'est toi qui avait déjà émis l'idée il y a quelques temps. Si l'on avance dans cette direction, il faut aussi mettre Railcom sur la même carte ? Cela fait un peu de monde, mais malheureusement (et ça répond aussi à Dominique) c'est nécessaire. Nous souhaitons des solutions toujours plus performantes qui rendent les solutions complexes. On n'a pas tous ces problèmes quand on pilote à vue et a la mano !
Pour l'I2C, pourquoi pas. J'ai mis des 74HC595 pour la simplification. Sur les signaux, il faudra aussi une capacité de "décoder" l'I2C. Simplicité ? Cout ?
-
Bonjour à tous,
la question des longueurs de câble se pose avec les protocoles non redondants, bas niveau (5V) et ne travaillant pas en différentiel :
A contrario du CAN.
déjà pour le Railcom : des problèmes avec 50 cm entre la voie et la détection. A réduire au maximum.
l'I2C est bien adapté aux liaisons courtes (moins de 50 cm)
le S88 que j'ai abandonné.
Blinder les câbles n'est une panacée : il faut gérer et éviter les boucles de masse.
Dans l'industrie les câbles UTP (non blindés) sont le standard pour l’Ethernet.
Les retours d'expérience sont les bienvenus.
-
Une autre question plus d ordre implémentation à propos de la frequence d émission des messages que tu as mis sur 100 millis sec. ( 0.1 secondes)
Cette frequence parait très rapide de prime abord et on pourrait penser que 1/4 de seconde ( par exemple donc 0.25 secondes) semblerait suffisant. Aussi pourquoi aller "aussi vite" dans l envoi des trames toutes les 100millis sec? N'émet t'on pas que ce qui as changé?
Qui peut le plus peut le moins. Cette fréquence est déjà celle des satellites V1. Si l'on peut fonctionner comme cela, c'est préférable. En effet, une détection ponctuelle par définition furtive peut "échapper".
J'ai fait le calcul que si le bus fonctionne à 1Mbps, que l'on a 25 satellites qui échangent des messages de 8 bytes de data avec un identifiant long de 29 bits, le bus était chargé tout au plus à 15-17 % de ses possibilités. Pourquoi se gêner !
C'est plus au niveau du récepteur que cela peut poser problème qui lui même peut "sauter des messages". Mais ce ne sera pas pire que de baisser la fréquence.
-
Merci Michel aussi pour ta contribution. Voilà de nouvelles compétences ! Je précise que nous travaillons avec Michel à l'implémentation d'un protocole CAN au sein de LaBox pour la rendre elle aussi totalement intégrée à un réseau de satellites et de gestionnaire.
Blinder les câbles n'est une panacée : il faut gérer et éviter les boucles de masse.
Tu peux développer ?
-
Hello
L I2C est plutôt économique avec les SX1509 et PCA9685 en regard des possibilités qu'ils apportent.
Pour le SX1509 la lib existe:
https://github.com/sparkfun/SparkFun_SX1509_Arduino_Library (https://github.com/sparkfun/SparkFun_SX1509_Arduino_Library)
Idem cote PCA9685 il y en plusieurs, donc voir c elle qui offre le plus de confort à l'usage.
A noter de suite que la puce SX travaille en 3v3 ( avec IO 5V tolérant) et la PCA en 5V, ceci imposera la présence d un "level shiftter" ( 4 résistances 10K et 2 Nmosfet type BSS138 par exemple) et des tensions adéquates aux abords.
On peut aussi les considérer selon leur usage comme des "extends" facultatifs avec une approche modulaire. ex Si pas de signaux car gare cachée, on n'équipe pas. ( besoin non nécessaire)
Si pour des raisons éco on doit étaler la dépense on équipe quand on est plus "argenté" ou pas exemple lorsque l'on met en place la signalisation... mais le cœur du dispositif est opérationnel sans les "extends" facultatifs.
Je peux regarder pour un ACS712 ou un cousin d ordre similaire à placer a coté de la détection RAILCOM.
Si je comprend l idée ses mesures permettraient de distinguer le passage de l'engin moteur sur une section mais aussi de déclencher des sécurités en cas de court circuit / dépassement de seuil ( Discussion que j avais eu avec Michel à l'expo de Gennevilliers en juin 2023)
D autres usages en vue?
Ltr
-
J ai une question d'ordre fonctionnel:
Dans le réseau de démo sur la TJS:
Si nous avons un train en mouvement sur C5 vers A1 qui est déviée alors le bloc agira et lorsque la loco se présentera dans C5 sur le capteur ponctuel d entrée, le ralentissement va s'opérer jusqu' à l arrivée sur le capteur de "sortie" proche de A1 ou s arrêtera le convoi (machine en tête ou en queue)
Toutefois que se passe t il si un engin est détecté sur la TJS alors que
le train n'est pas encore dans C5: ici le train sur la TJS ( et surement en mouvement entre C2 ou C0) sera détecté par le capteur RAILCOM de C5, ne va t on pas alors arrêter le mauvais convoi? ( puisque c est l adresse de ce train qui va être associée au canton C5 car FIFO? ( First IN dans le satellite)
le train est dans C5: on a alors un imbroglio pour la lecture de l adresse RAILCOM car 2 engins ne peuvent emmètre en même temps ( tout cela est peut être très théorique mais me semble être des combinaisons plausibles d'enchainements de différents mouvements).
J ose en déduire qu' il faut donc en principe que le train dans C5 s'identifie avant qu'une possible détection émettant sur la TJS ne vienne placer son adresse dans le satellite.
ou bien que la solution peut reposer sur une détection de présence seule (par conso de courant) et non railcom sur une aiguille en pointe?
Alors déjà, un mouvement de C5 vers A1 ne me dit rien. Tout d’abord, on ne sait toujours pas laquelle est A1 et laquelle est A3. Pierre a posé la question plusieurs fois mais je crois toujours sans réponse.
Alors, s’agit il de C5 vers C1 via A1 ou de C5 vers C0 via A1 (ou A3 ?) ?
Je vais donc faire une réponse globale qui de toutes les façons vaudra quel que soit le cas :
Deux possibilités : La TJS isole de façon interne et selon la position de ses aiguilles C5 de C0 (et donc C6) ou pas.
Dans le premier cas, il n’y a pas d’interférence dans la détection Railcom donc pas de problème. Dans le second cas, il faut isoler par exemple C5/C1 la TJS. Il n’y a pas besoin de détection Railcom dessus, juste une détection par consommation de courant pour savoir si elle est occupée ou libre. Détection qui sera assurée par le satellite sur C0 ou C6 (très certainement C0 d'ailleurs).
-
Je peux regarder pour un ACS712 ou un cousin d ordre similaire à placer a coté de la détection RAILCOM.
Si je comprend l idée ses mesures permettraient de distinguer le passage de l'engin moteur sur une section mais aussi de déclencher des sécurités en cas de court circuit / dépassement de seuil ( Discussion que j avais eu avec Michel à l'expo de Gennevilliers en juin 2023)
D autres usages en vue?
Ltr
Bien sûr qu'une détection "locale" apporterait beaucoup. Certainement en termes de latence et de précision. Et puis pourquoi stopper tout le réseau pour un court-circuit "local". En cas de détection, l'état du canton est placé à "busy" pour tous les autres et aucun train ne peut s'engager dessus.
Oui j'ai l'intuition qu'il y aura d'autres usages et je suis intéressé de savoir ce que Michel en pense. La lecture analogique peut nous renseigner sur la nature de la consommation (locomotive > xxxmA, wagon < yyy mA) etc...
-
Pour préciser qui est A1 et A3 on prend le sens de circulation anti horaire de la "V1" et on incrémente les appareils de numéros impaires au fur et a mesure de leur introduction sur la "voie principale" dans le sens de circulation nominal (le plus souvent utilisé)
Donc A1 est la première lame de la TJS (la plus à gauche) A3 celle placée à droite
L'itinéraire "voie" principale favorise toujours un positionnement des lames en position directe (non déviée) ou par prise en talon d une aiguille ( pour Vmax)
Par principe sur une voie on ne trouve pas:
- d aiguille triple (au moins en double voie et on évite en VU sauf ligne "secondaire")
- la direction "droite" d une TJS / TJD est toujours celle qui est retenue
- Si la géométrie des appareils le permet on peut passer une aiguille "déviée" à une vitesse nominale (celle de la zone traversée <= vitesse max de la ligne) sinon réduite. ( et par principe réduite dans les autres cas)
Plusieurs vitesses sont possibles grâce au TIV (tableau indicateur de vitesse ex 70) sinon à la signalisation lumineuse par défaut ( Ralentissement 160, 60, 30,...)
[/list]
Ici V1 avec une circulation à gauche type SNCF tourne dans le sens anti horaire.
V2 dans le sens horaire.
Ltr
-
@Dominique. Laurent répond bien à ta question. Moins on a de câbles sur le réseau et mieux c'est. Moins on a de longueur pour chaque câble et mieux.
Tout à fait d'accord, mais l'âge avançant très vite, moins on a d'équipements sous la table et mieux c'est.
-
Tout à fait d'accord, mais l'âge avançant très vite, moins on a d'équipements sous la table et mieux c'est.
C'est pour cela que j'ai placé les cartes en façade de mon réseau !
(https://www.locoduino.org/local/cache-vignettes/L768xH512/_dsc1082-32db0.jpg?1700558887)
Mais aussi, nous allons faire en sorte de regrouper tout sur une seule et même carte.
-
Retour à la présentation des satellites autonomes.
Dans un précédent post, nous avons vu les fichiers du programme. Je vais maintenant vous présenter les fichiers contenus dans le dossier data, dossier qui est copié en mémoire flash de l’ESP32.
(https://www.locoduino.org/local/cache-vignettes/L400xH179/fichiers_dossier_data-2-7e910.png?1700584166)
Favicon.png est la petite image que vous avez dans les onglets du navigateur web. Vous pouvez la changer par une autre si vous le souhaitez.
Les fichiers index.html, scripts.js et w3.css sont les fichiers qui assurent le fonctionnement de la page web qui renseigne sur les liaisons du satellite avec ses voisins et permet différents réglages comme les buttées de servomoteurs.
(https://www.locoduino.org/IMG/png/ecran1.png)
Index.html, c’est la partie codée en HTML pour l’affichage de la page.
https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/index.html (https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/index.html)
Scripts.js, le code JavaScripts qui assure l’interactivité de la page, l’échange de données en entrée et en sortie avec le programme principal en C++.
https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/script.js (https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/script.js)
w3.css est une bibliothèque graphique pour enrichir le rendu visuel de la page : https://www.w3schools.com/w3css/w3css_examples.asp (https://www.w3schools.com/w3css/w3css_examples.asp)
Enfin, le fichier settings.json qui regroupe les informations de paramétrages spécifiques pour chaque satellites.
Voici une petite partie du contenu de ce fichier avant sa première utilisation. C’est un peu effrayant de prime abord, mais je vous rassure, vous n’avez que deux informations à renseigner. Pour toutes les autres, c’est le programme qui s’en chargera automatiquement à l’occasion du processus de découverte et pendant l’exploitation (position des aiguilles, locomotives présentes etc…).
"idNode":255,
"wifi_on":true,
"ssid":"xxxxxxxxxx",
"password":"xxxxxxxxxx",
"discovery_on":true,
"comptAig":0,
"masqueAig":0,
"p00":"null",
"p01":"null",
"p10":"null",
"p11":"null",
"m00":"null",
"m01":"null",
"m10":"null",
"m11":"null",
Mais il faut impérativement renseigner le « ssid » de votre box et son « password » en remplaçant « xxxxxxxxxx » et « yyyyyyyyyy » par vos propres valeurs.
Une fois cette modification réalisée une première fois, elle sera valable pour tous les satellites, vous n’aurez plus à vous en préoccuper.
L'intégralité du fichier settings.json est visible ici : https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/settings.json (https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/settings.json)
Voilà pour le contenu du dossier data à copier sur l’ESP32 en même temps que le programme principal.
-
Blinder les câbles n'est une panacée : il faut gérer et éviter les boucles de masse.
Tu peux développer ?
Un petit schéma ...
Si entre deux modules, on blinde le câble signal et que l'on raccorde des deux cotés le blindage à la masse on créé une boucle d'induction pour les champs parasites. On créé alors un courant de circulation qui développe un potentiel qui se superpose au signal.
Il est donc recommandé de ne mettre à la masse qu'un coté du blindage.
Cette solution simple sur le papier se révèle plus compliquée dans la réalité.
-
Bonjour Christophe, bonjour à tous,
Ci dessous un lien qui pointe vers un site sur la CEM (compatibilité électro magnétique) et qui explique entre autre la façon de raccorder les masses d'un câble blindé.
Dans le cas du schéma proposé (carte 1, liaison, carte2), il me semble qu'il faut raccorder la tresse du câble blindé aux 2 extrémités, car les 2 cartes sont elles même déjà relié à la masse par l'alimentation. En principe, l'impédance du câble de masse de l'alimentation étant inférieur à celle du blindage (section du câble d'alimentation plus forte, donc moins impédante), relier les 2 extrémités du blindage à la masse ne pose pas de problème pour ce cas précis.
Ceci n'est que mon humble avis et je peux me tromper !
https://www.tecnipass.com/cours-electronique.cem-cem.perturbations-cem.solutions?page=6 (https://www.tecnipass.com/cours-electronique.cem-cem.perturbations-cem.solutions?page=6)
A+ Rémi
-
Bonjour Christophe, bonjour à tous,
il me semble qu'il faut raccorder la tresse du câble blindé aux 2 extrémités, car les 2 cartes sont elles même déjà relié à la masse par l'alimentation. En principe, l'impédance du câble de masse de l'alimentation étant inférieur à celle du blindage (section du câble d'alimentation plus forte, donc moins impédante), relier les 2 extrémités du blindage à la masse ne pose pas de problème pour ce cas précis.
Ceci n'est que mon humble avis et je peux me tromper !
Non, c'est justement parce qu'elles sont déjà reliées qu'il ne faut pas les relier une seconde fois sinon tu crées la boucle.
-
Merci Remi,
Toutes ces contributions sont importantes. et même si elles peuvent présenter des inexactitudes elles ont le mérite de lever des questions qui trouveront j'en suis certain des réponse avec d'autres contributeurs. Et comme on le voit, ça aborde de vrais questions.
Bon, la bonne réponse semble t'il est arrivée pendant ma réponse !
-
Re,
Vous trouverez ci joint, uniquement à but d'information, un extrait d'un document de 2009 (voir la première page) qui explique pourquoi il est nécessaire de relier le blindage d'un câble aux deux extrémités. Ces règles sont toujours appliquées dans l'industrie des systèmes de télécommunications depuis plus de 30ans.
Après, je ne sais pas si cela éclaircira le sujet.
A+ Rémi
-
Bonsoir,
Pouvez-vous me donner la référence du capteur de courant (Photo page 2, réponse 25).
Je ne suis pas là pour critiquer, je n'en ai pas les moyens, mais les TJD en général ne sont pas appréciées (déraillements).
-
Bonsoir,
le document du CEA rappelle les principes dont celui de base qui est que Un raccordement à une extrémité empêche les courants BF de circuler sur la tresse.
Il s'applique aux câbles coaxiaux en HF (dixit quelques MHz -> 500 MHz) et des signaux faibles.
Ici on a le cas du CAN que l'on souhaite utiliser à 1 Mb/s et on est en numérique et en différentiel.
Mon sentiment est que pour bien faire on devrait utiliser du câble torsadé non blindé (UTP) en respectant la paire utilisée.
Ou si on est craintif, du blindé (UTP) en ne raccordant qu'une extrémité.
A noter que le satellite V1 utilisait et utilise encore du câble plat non blindé et ce, sans problème pour le CAN.
Actuellement, c'est cette option qui est retenue pour LaBox.
L'environnement d'un réseau de train numérique est certainement bien fourni en matière de perturbations BF (le DCC est à +/- 6 KHz) et impulsionnelles (solénoïdes, moteurs et contact voie).
-
Bonsoir,
Pouvez-vous me donner la référence du capteur de courant (Photo page 2, réponse 25).
Je ne suis pas là pour critiquer, je n'en ai pas les moyens, mais les TJD en général ne sont pas appréciées (déraillements).
Bonsoir,
Ce sont ces capteur :
Mais attention, il faut du code derrière pour traiter la mesure et gérer le résultat. msport et/ou laurentr sauront excpliquer mieux que moi les différentes équation à appliquer. Au besoin, je sais fournir le code pour la détection.
https://fr.aliexpress.com/item/1005006391760222.html?src=google&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&isSmbAutoCall=false&needSmbHouyi=false&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005006391760222&ds_e_product_merchant_id=5293214119&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=20497291105&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=CjwKCAiA75itBhA6EiwAkho9e6Qmlt6UeIscizT4Fa9MV18rSVlL8-IAZVyeg_ssL5NgsiV3yfAERxoC01oQAvD_BwE&aff_fcid=f83c72d8a1224e6a95af86164e48211b-1705439223784-01139-UneMJZVf&aff_fsk=UneMJZVf&aff_platform=aaf&sk=UneMJZVf&aff_trace_key=f83c72d8a1224e6a95af86164e48211b-1705439223784-01139-UneMJZVf&terminal_id=d03f1c67fa254b76acedf042f34e4653&afSmartRedirect=y (https://fr.aliexpress.com/item/1005006391760222.html?src=google&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&isSmbAutoCall=false&needSmbHouyi=false&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005006391760222&ds_e_product_merchant_id=5293214119&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=20497291105&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=CjwKCAiA75itBhA6EiwAkho9e6Qmlt6UeIscizT4Fa9MV18rSVlL8-IAZVyeg_ssL5NgsiV3yfAERxoC01oQAvD_BwE&aff_fcid=f83c72d8a1224e6a95af86164e48211b-1705439223784-01139-UneMJZVf&aff_fsk=UneMJZVf&aff_platform=aaf&sk=UneMJZVf&aff_trace_key=f83c72d8a1224e6a95af86164e48211b-1705439223784-01139-UneMJZVf&terminal_id=d03f1c67fa254b76acedf042f34e4653&afSmartRedirect=y)
-
Le fil des détecteurs à transformateur de courant est celui ci
http://forum.locoduino.org/index.php?topic=489.0
Peut-être un de ces modules peut convenir :
https://fr.aliexpress.com/item/1005001771821385.html
le module à ACS712 qui délivre 5V/5A donne donc 5mV pour 5mA, en fait +5mV sur 2,5V, ce qui est délicat à détecter.
https://fr.aliexpress.com/item/1005006391760222.html
-
Bonsoir
Pour la mesure de conso ( et tout ce que l'on pourra exploiter ensuite grâce à cette mesure) on peut aussi ajouter un montage à base d' AMPLI OP comme le LM358 dont le gain sera réglable, ce qui nous affranchirait des contraintes des plages /échelles de l'ACS712.
Le LM358 est dispo et pourrait être substituable par un clone aux caractéristiques voisines.
Ceci me semble bien adapté mais comme toujours challengeable :)
Ltr
-
On peut aussi ajouter le INA-169 à la liste.
Nous en avions discuter aussi sur Locoduino il y a un moment:
https://forum.locoduino.org/index.php?topic=1038.45 (https://forum.locoduino.org/index.php?topic=1038.45)
mais aussi du ACHS-7122
https://forum.locoduino.org/index.php?topic=843.msg10309#msg10309 (https://forum.locoduino.org/index.php?topic=843.msg10309#msg10309)
La solution que Michel avait proposé est elle validée?
ACS712 + LM358 ( dont on bornera la plage de sortie sur 3V3 Max car ESP32 et 3V3 et non 5V en Vin max sur les broches...)
Ltr
-
Bonsoir
Je me suis entretenu avec Christophe dans la soirée sur le contenu de sa réalisation et nous avons déjà convenu de différents points.
La solution actuelle est pleinement opérationnelle. Ceux qui désirent se lancer dans sa réalisation le feront sans difficulté à l'aide de ce que Christophe met déjà à leur disposition enrichi de ses conseils de mise en œuvre et explications dans cette rubrique.
La solution proposée n'a pas fini de vous surprendre de par le nombre d'innovations internes qu'elle porte ET SURTOUT le fait que c'est totalement "invisible" dans le cadre de la mise en œuvre de la solution.
Nous avons identifié des points d'améliorations/complétude qui auront besoin d être testés aussi. Ce a quoi nous nous attellerons et vous ferons part de nos avancées
Certains se poseront alors la question: "J attends la V2 ou pas?"
La réponse est simple: "un tiens vaut mieux que 2 tu l'auras!"
Aussi chacun jugera librement de l'opportunité d'exploiter dès à présent la solution dans sa forme actuelle et de la compléter par la suite. On parle bien de compléter pas de remplacer (donc ne rien jeter!). C est donc aussi l'occasion de se familiariser avec cette solution et d'envisager son extension ultérieure si elle vous apporte satisfaction.
Pour ne pas complexifier la lecture de ce post dédié à la mise en œuvre de la solution initiale j'ouvrirai un post complémentaire ( qui sera aussi utile pour la partie du gestionnaire de réseau) afin de traiter spécifiquement de possibles mises en œuvre plus spécifiques et ou complémentaires.
Nous y serons astucieux encore une fois pour faciliter la mise en œuvre de la solution.
Trois points sont déjà au menu:
- Mesure du courant et protection ( déjà abordé dans les derniers échanges ici même)
- Traitement des zones d'appareils complexes
- Introduction du bus I2C et de périphériques
Enfin nous aborderons cela avec une "approche modulaire" et un hardware redessiné pour l'occasion dont les grandes lignes ne changent en rien de l'œuvre initiale. ( et seront compatibles* ( * = possiblement sous réserve d'éventuelles mises à jour soft)
Ltr
-
Bonjour
Apres quelques lectures sur le sujet il semble que le INA219 soit avec le support de l I2C un candidat intéressant pour les mesures de tensions et courant.
Des suggestions?
Ltr
-
Le fil des détecteurs à transformateur de courant est celui ci
http://forum.locoduino.org/index.php?topic=489.0
Peut-être un de ces modules peut convenir :
https://fr.aliexpress.com/item/1005001771821385.html
le module à ACS712 qui délivre 5V/5A donne donc 5mV pour 5mA, en fait +5mV sur 2,5V, ce qui est délicat à détecter.
https://fr.aliexpress.com/item/1005006391760222.html
Bonsoir,
Merci. Celui avec le TI me conviendrait , je pense que la broche "OUT" est 0 ou 1
-
Bonsoir,
la sortie de ce montage n'est pas couplée en continu mais par un condensateur de valeur non précisée. (si le schéma est correct)
La sortie est une succession de pics à gérer par programme.
A tester.
-
Bonsoir
Merci Michel
La led 1 Green est à retourner je pense.
Ltr
-
Bonjour,
oui, le schéma a du être établi à partir du circuit, comme tout ce qu'on trouve sur Internet, à prendre avec précaution.
-
Le nombre d I/O sur l ESP 32 et leur utilisation rend l'utilisation du bus I2C comme une alternative à leur extension de façon simple.
Pour ma part j aime bien la SX1509 très polyvalente mais un PCA9685 offre aussi son lot de possibilités!
pour le SX1509: https://learn.sparkfun.com/tutorials/sx1509-io-expander-breakout-hookup-guide/all (https://learn.sparkfun.com/tutorials/sx1509-io-expander-breakout-hookup-guide/all)
ex PCA9685: https://www.aranacorp.com/fr/utilisation-dun-module-pca9685-avec-arduino/ (https://www.aranacorp.com/fr/utilisation-dun-module-pca9685-avec-arduino/)
Je suis peut-être hors sujet, mais je comprends qu'il faut augmenter le nombre d'I/O sur l'ESP32. Pour des entrées numériques, j'ai développé une carte relativement simple basée sur des registres à décalage qui permet d'ajouter au choix 8, 16, 24 ou 32 entrées.
On doit pouvoir faire de même pour des sorties. Je ne l'ai pas encore réalisée mais je l'ai testée sur des plaques de montage rapide.
-
quelque chose comme ça ?
-
Bonjour
C est bien l idée en effet pour les I/O supplémentaires.
A noter qu'il vaut mieux développer cela sur le post des évolutions des SATELITTES AUTONOMES.
L internet des solution de registres à décalage est que cela est directement exploitable avec la solution de Christophe qui les mets déjà en œuvre.
Ltr
-
Félicitations pour tout ce travail et surtout pout le concept qui correspond complétement à ce que je cherche à faire. (petites automatisations sur un reseau étagere et sans ordinateur)
J'attend un peu pour me lancer car je suis seulement en train de finaliser ma centrale labox et faire des essais CAN.
En tous cas, je suis le sujet de trés près!!
-
Christophe
Pour compléter le montage du détecteur RAILCOM tu peux envisager de venir mettre un double INA169 comme sur le schéma ci joint.
page 16 dans ce doc:
https://www.ti.com/lit/ds/symlink/ina169.pdf?ts=1706707855189&ref_url=https%253A%252F%252Fwww.google.com%252F (https://www.ti.com/lit/ds/symlink/ina169.pdf?ts=1706707855189&ref_url=https%253A%252F%252Fwww.google.com%252F)
Intérêt on utilise toujours la même résistance de shunt déjà en place pour la détection RAILCOM.
Les mesures sont différenciées.
On peut alors temporiser aussi soit au niveau de CPU ( par soft) soit sur l'entrée du CPU par ajout d'un condo.
Ca reste à tester...
Sinon il faut regarder les calculs pour un shunt a 1.8r et l INA219 ou cela conduit...
Laurent
Ltr
-
Bonjour à tous,
Je viens de publier sur le site éditorial les trois premiers articles sur le sujet des satellites autonomes. Cela permettra une lecture plus structurée. N’hésitez vraiment pas à poser des questions ou émettre des avis. Le concept de satellite autonome s’inscrit dans la lignée des satellites v1 et porte un certain nombre de concepts qui nous intéressent à Locoduino. En réagissant, c’est sur l’ensemble de ces concepts que vous apporterez votre contribution.
Christophe
-
Bonsoir
Le 4eme volet est également dispo!
Efficace et très bien fait.
La suite la suite..!!
Ltr
-
Hello Christophe
Tu peux me confirmer que le mapping suivant est bon ? ( d après tes docs.)
Quels sont les utilisations qui peuvent être modifiées et celles qu'il faut considérer comme fixes?
Je pense à regrouper certains PINS par usage ( ex les SERVO), ajouter l'usage de l'I2C au passage, ...
Ltr
-
Hello Christophe
Tu peux me confirmer que le mapping suivant est bon ? ( d après tes docs.)
Salut Laurent,
Désolé, j'avais zappé ce message. Le bon mapping est celui qui est en bas de la page : https://www.locoduino.org/spip.php?article349
Il a évolué hier encore pour la pin 33 (lecture de courant). C'est LE sujet sur lequel je travail totalement en cemoment et je vais te poser un certain nombre de question sur le fil "Détection par consommation avec des courants faibles" : https://forum.locoduino.org/index.php?topic=1656
-
No soucis!
J ai légèrement fait évoluer ce mapping pour des optimisations de routage sur le nouveau PCB.
A priori rien de gravissime à (re)définir.
Ltr
-
Vous savez, je suis malouin et les Anglais ont essayé bien avant vous...
Je ne comprends pas bien cette phrase sortie de son contexte et posée ici, dans ce fil...
Christophe
-
Vous savez, je suis malouin et les Anglais ont essayé bien avant vous...
Plouf !.. Je me jette à l'eau...
Je ne suis pas très "Malouin" ;) , mais curieux et opiniâtre, alors, avec votre assistance je parviendrai peut être à quelque chose... Alors voilà :
Tout d'abord, je dois vous faire part de toute mon admiration pour vos écrits plus créatifs les uns que les autres,
même s'ils demeurent parfois encore un peu abscons pour un néophyte...
Un merci tout particulier à Christophe (@bobyAndCo) pour son projets de satellites autonomes qui se veut didactique et s'adressant aussi aux moins expérimentés.
C'est, je le pense, exactement la solution que je cherchais pour piloter mes locomotives "à la main" à l'aide d'un TCO "analogique" (pas certain que ce soit le bon terme) commandé par interrupteurs ou boutons poussoirs et surtout, sans nécessiter la présence d'un ordinateur même si ça reste possible...
Seulement voilà... Je ne suis vraiment pas expérimenté et c'est là que le bat blesse... Bien que bricoleur averti et amateur de projets Arduino, sachant souder, je ne suis ni informaticien ni électronicien et forcément, ça se complique...
Alors voilà mes questions, merci pour votre patience et votre bienveillance, espérant qu'avec votre assistance,
je parviendrai à monter avec mes petits doigts boudinés le réseau de mes rêves !..
1°/ Je n'ai trouvé nulle part le code nécessaire au fonctionnement des différentes cartes, "Main", "Watchdog" et "Cartes satellite"...
Peut-être cela m'aurait-il aidé à résoudre certaines des questions suivantes ?..
2°/ Je n'ai pas trouvé non plus comment sont envoyées les commandes d'aiguilles ?..
Par des boutons poussoirs et/ou des interrupteurs j'imagine, mais avec quel signal, 5v "High" ou "Low" ?..
Et si oui, sur quelles broches de l'ESP ou quels points de la carte satellite ?..
Et à ce propos, existe-t-il un schéma de câblage de tous les différents éléments ?.. Ça, c'est sûr que ça me simplifierait la vie...
3°/ Le Bus CAN qui relie tous les satellites entre eux doit-il être également relié à la centrale, ou la lecture des informations se fait directement par les voies ?..
4°/ Toujours à propos du Bus CAN, la liaison entre les satellites se fait par un câble RJ45 (6 pôles ?), mais comment s'effectue celle entre une carte satellite et la "Watchdog" ou la "Main" ?..
D'un côté nous avons une prise RJ45 et de l'autre un bornier à vis avec 2 pôles... Quels sont les câbles à relier ?..
5°/ Pour faire fonctionner tous ça, il nous faut bien entendu une centrale DCC capable de fournir le signal de voies adéquat...
Mais alors quelle centrale ?
- N'importe quelle centrale DCC compatible Railcom® ?..
- Ou peu importe la centrale pourvu que le décodeur soit compatible Railcom® ?..
- Ou encore, "les deux mon capitaine" ?..
Parmi celles abordées sur Locoduino, il me semble que "LaBox" conviendrait parfaitement, mais pour des raisons d'incompréhension que je développerai dans un autre "post" dédié à cette centrale, je me demandais si celle d' "Une station DCC complète, polyvalente et économique avec JMRI." (https://www.locoduino.org/spip.php?article253 (https://www.locoduino.org/spip.php?article253)) pourrait convenir également,
ou encore "Réalisation de centrales DCC avec le logiciel libre DCC++" (https://www.locoduino.org/spip.php?article187 (https://www.locoduino.org/spip.php?article187)) ?..
6°/ À propos des Led pour les signaux de feux, si j'ai bien compris, le satellite se charge d'activer les led nécessaires à une position de signal ?
Mais alors, quelles Led sont à relier à quelles sorties de la carte ? J'ai vu qu'il y avait 2 x 8 plots, mais je ne comprends pas comment ils sont déterminés...
Par exemple est-il possible d'utiliser une de ces sorties pour allumer une led du TCO ?..
7°/ J'en ai presque terminé, mais me posais également des questions pour le cas d'une voie de garage :
Le satellite n'est relié qu'à une seule aiguille (celle de l'entrée/sortie de la voie de garage) et commande ainsi le ralentissement automatique puis l'arrêt...
C'est bien ça ?..
Alors, à quel moment sera activé le ralenti ? Au moment de la détection par le décodeur Railcom® ? Et l'arrêt ?..
Et dans le cas d'une entrée en "Marche arrière" (les wagons se présentent en premier), comment pourrait être déclenché la commande de ralenti ?
Ainsi, la situation d'une voie de garage nécessiterait-elle un ou deux capteurs IR (un pour le ralenti et l'autre pour l'arrêt), ou plutôt un IR et un autre par consommation de courant ?.. Une autre solution ?..
8°/ Et cette fois j'en termine ici, l'orientation des satellites sur le schéma est-elle correcte ou est-ce une vue simplifiée ?
(http://gestionnaire_plan_de_base-9ed90)
Il me semble qu' au satellite 09 succède le satellite 10 (dans le sens des aiguilles d'une montre) et qu'ainsi, pour leur découverte mutuelle, le câble RJ45 devrait bien sortir du 09 par le côté "Sat+", mais entrer dans le 10 par le côté "Sat-" et non "Sat+" comme c'est le cas sur le schéma... Et idem pour les satellites 2, 1, 0 et 5 ?..
Ou alors ça n'a aucune importance ?..
Merci infiniment pour les réponses que vous voudrez bien m'apporter, et une fois encore,
un énorme bravo à tous les contributeurs pour le travail qu'ils mettent à la disposition du plus grand nombre !
-
Vous savez, je suis malouin et les Anglais ont essayé bien avant vous...
Je ne comprends pas bien cette phrase sortie de son contexte et posée ici, dans ce fil...
Christophe
Désolé Christophe, tu trouveras la réponse dans le post précédent...
J'apprends à me servir de la messagerie Locoduino...
C'était juste un clin d'oeil bienveillant aux origines dont tu as pu nous faire part...
Bravo et merci pour ton projet !!!
-
Bon ! Eh bien sincèrement merci pour toutes ces questions très pertinentes et cela me rassure de voir qu’il y en a que ça intéresse. Je vais essayer de répondre précisément à chacune. Et merci pour tes appréciations motivantes.
Mais tout d’abord :
Seulement voilà... Je ne suis vraiment pas expérimenté et c'est là que le bat blesse... Bien que bricoleur averti et amateur de projets Arduino, sachant souder, je ne suis ni informaticien ni électronicien et forcément, ça se complique...
Alors voilà mes questions, merci pour votre patience et votre bienveillance, espérant qu'avec votre assistance,
je parviendrai à monter avec mes petits doigts boudinés le réseau de mes rêves !..
J’ai vraiment voulu dès l’origine que tout soit le plus simple possible et accessible avec peu de compétences que ce soit en informatique (rien à programmer), pas d’électronique et juste quelques soudures et du bon sens. Sois rassuré !
1°/ Je n'ai trouvé nulle part le code nécessaire au fonctionnement des différentes cartes, "Main", "Watchdog" et "Cartes satellite"...
Peut-être cela m'aurait-il aidé à résoudre certaines des questions suivantes ?..
Plusieurs raisons à cela ! Je travaille toujours et toujours sur le code car je trouve toujours des améliorations. Donc j’ai attendu le plus longtemps possible qu’on me le demande pour publier du code qui serait assez rapidement dépassé. C’est chose faite.
Pour l’instant, le code est disponible à partir de mon GitHub :
Pour les satellites (clients) : https://github.com/BOBILLEChristophe/Satellites_autonomes_client
Pour le main :
https://github.com/BOBILLEChristophe/Satellites_autonomes_main
Pour le watchdog :
https://github.com/BOBILLEChristophe/Satellites_autonomes_-watchdog
Je rapatrierai sur le Git de Locoduino quand le code sera assez finalisé.
2°/ Je n'ai pas trouvé non plus comment sont envoyées les commandes d'aiguilles ?..
Par des boutons poussoirs et/ou des interrupteurs j'imagine, mais avec quel signal, 5v "High" ou "Low" ?..
Et si oui, sur quelles broches de l'ESP ou quels points de la carte satellite ?..
Commander n’importe quelle aiguille du réseau est une commande qui (actuellement) circule par le bus CAN, à partir d'un TCO par exemple. Il n’y a pas de commande directe sur le satellite !
Il pourrait y avoir une commande directe en sus, à étudier !
La commande des aiguilles est donc une commande envoyée sur le bus avec l’identifiant du satellite et la position de l’aiguille. La commande étant de type toggle, le premier message commande dans un sens, le second l’autre sens. L'usage de boutons poussoirs sur un TCO physique est donc recommandé. En virtuel, pas de problème.
Et à ce propos, existe-t-il un schéma de câblage de tous les différents éléments ?.. Ça, c'est sûr que ça me simplifierait la vie...
Oui je le ferai !
3°/ Le Bus CAN qui relie tous les satellites entre eux doit-il être également relié à la centrale, ou la lecture des informations se fait directement par les voies ?..
Aucune information par les voies, si ce n’est les commandes de locomotives en DCC ! Tu pensais peut-être à un sniffer DCC ? J'avoues qu'au travers d'échanges que j'ai avec Marcel (Catplus) cette éventualité à été avancée. Ce pourquoi j'ai "posé" le hard de DCC Inspector sur une carte dont j'ai parlé récemment sur le forum. Tu fais bien de soulever ce point car il est loin d'être inintéressant, et permettrait alors l'usage de n'importe quelle centrale même commerciale à condition qu'elle génère Railcom. Bien vu !!! Au passage, je tiens à remercier Marcel qui me fait souvent ch*er avec des idées complètement farfelue de prime abord mais qui se révèlent particulièrement pertinentes quand on creuse.
A l'heure actuelle, oui la centrale DCC est totalement intégrée dans le concept de satellites autonomes. Les satellites ont besoin des confirmations de commandes renvoyées par la centrale pour mettre à jour les informations de locomotives internes (vitesse et sens en particulier).
Cela veut dire que l’on ne peut pas utiliser n’importe quelle centrale (en particulier du commerce) qui doit être capable de « former ce message » mais doit aussi être compatible Railcom et qui exclus donc (pour l’instant ?) la Box !!! pour laquelle j’ai pourtant mis au point la messagerie CAN ad hoc.
Donc, cela suffit je pense à s'intéresser au sniffer DCC !!!
4°/ Toujours à propos du Bus CAN, la liaison entre les satellites se fait par un câble RJ45 (6 pôles ?), mais comment s'effectue celle entre une carte satellite et la "Watchdog" ou la "Main" ?..
D'un côté nous avons une prise RJ45 et de l'autre un bornier à vis avec 2 pôles... Quels sont les câbles à relier ?..
Sur les prises RJ45, une paire de fil est dédiée à CAN H et CAN L. Les 3 autres paires font circuler le courant dont prudement je dis actuellement que c'est du 12V mais le 24V doit pouvoir être supporté sans problème à mon avis. A expérimenter.
Dans l’article 2, j’ai expliqué ceci mais il faudra sans doute que je sois plus précis :
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.
Pour les cartes watchdog et main, je conseille de les placer chacune à l’extrémité du bus CAN. Le mieux est donc de sortir du dernier satellite en filaire et d’entrer dans les cartes en filaire avec le connecteur, soit de couper un RJ45 pour entrer en filaire dans les cartes watchdog. Je donnerai les fils correspondant car les autres fils, c’est du 12/24v !!!
5°/ Pour faire fonctionner tous ça, il nous faut bien entendu une centrale DCC capable de fournir le signal de voies adéquat...
Mais alors quelle centrale ?
- N'importe quelle centrale DCC compatible Railcom® ?..
- Ou peu importe la centrale pourvu que le décodeur soit compatible Railcom® ?..
- Ou encore, "les deux mon capitaine" ?..
Parmi celles abordées sur Locoduino, il me semble que "LaBox" conviendrait parfaitement, mais pour des raisons d'incompréhension que je développerai dans un autre "post" dédié à cette centrale, je me demandais si celle d' "Une station DCC complète, polyvalente et économique avec JMRI." (https://www.locoduino.org/spip.php?article253 (https://www.locoduino.org/spip.php?article253)) pourrait convenir également,
ou encore "Réalisation de centrales DCC avec le logiciel libre DCC++" (https://www.locoduino.org/spip.php?article187 (https://www.locoduino.org/spip.php?article187)) ?..
Pour la première partie de la réponse, j’ai déjà répondu. Pour la seconde, en l’état, il ne semble pas que cette carte soit compatible avec Railcom qui nécessite une action du logiciel sur une broche Break que pour l’instant il semble que nous n’ayons trouvé que sur le LMD18200. Ce pourquoi je sais que Michel travaille à implanter le 18200 sur la Box.
Il existe des solution matérielles (non testée) pour générer le cutout nécessaire à Railcom. A tester si vraiment l’utilisation du 18200 ne convenait pas.
En dernier recours, j'ai développé une centrale DCC sur ESP32 (wifi) qui génère le Railcom avec un LMD18200 : https://youtu.be/AmGNV-QiFVU?si=raftdZYYFYu7-zuo
Elle est compatible avec les commandes DCC++ / DCCpp, donc JMRI, RocRail... elle dispose même de sa propre interface de commande que j'ai développée en HTML et JavaScript
7°/ J'en ai presque terminé, mais me posais également des questions pour le cas d'une voie de garage :
Le satellite n'est relié qu'à une seule aiguille (celle de l'entrée/sortie de la voie de garage) et commande ainsi le ralentissement automatique puis l'arrêt...
C'est bien ça ?..
Alors, à quel moment sera activé le ralenti ? Au moment de la détection par le décodeur Railcom® ? Et l'arrêt ?..
Oui c’est bien cela. En fait, du point de vue logiciel, s’il n’y a pas de voie est comme « il n’y a pas de voie libre » donc je freine dès que la loco est identifiée par Railcom et je stoppe quand je franchis le capter vers la fin de la section de voie.
Ainsi, la situation d'une voie de garage nécessiterait-elle un ou deux capteurs IR (un pour le ralenti et l'autre pour l'arrêt), ou plutôt un IR et un autre par consommation de courant ?.. Une autre solution ?..
Un capteur suffit (pour le stop en fin de voie). Le ralenti, comme dit ci-dessus, est appliqué dès que la loco est identifiée par Railcom (quelques secondes à peine après son entrée).
Et dans le cas d'une entrée en "Marche arrière" (les wagons se présentent en premier), comment pourrait être déclenché la commande de ralenti ?
Vous pointez ici un problème général qui n’a pas encore sa solution, c’est la question du convoi poussé. J’ai cela dans un coin de la tête et sera traité quand les nombreuses autres questions prioritaires le seront (ou si j’ai de l’aide pour le développement !!!). Je pense que je n’échapperai pas au suivi de convois de cantons « voisins » pour le régler. Pas très compliqué à faire du point de vue logiciel mais question de temps.
Bon dans le cas précis du convois "poussé" sur la voie de garage, le ralenti interviendrait très tard mais l'arrêt serait assuré par le capteur en fin de voie. Pour peu que le convoi ne s'engage pas à pleine vitesse dans cette voie de garage !!!
8°/ Et cette fois j'en termine ici, l'orientation des satellites sur le schéma est-elle correcte ou est-ce une vue simplifiée ?
(http://gestionnaire_plan_de_base-9ed90)
Il me semble qu' au satellite 09 succède le satellite 10 (dans le sens des aiguilles d'une montre) et qu'ainsi, pour leur découverte mutuelle, le câble RJ45 devrait bien sortir du 09 par le côté "Sat+", mais entrer dans le 10 par le côté "Sat-" et non "Sat+" comme c'est le cas sur le schéma... Et idem pour les satellites 2, 1, 0 et 5 ?..
Ou alors ça n'a aucune importance ?..
L’ordre n’a absolument aucune importance. L’utilisateur ne connais même pas l’ID du satellite normalement sauf dans le débug de l’interface série.
J’espère avoir répondu au mieux et pourtant superficiellement à chaque question. Chacune d’elles aurait mérité un post à chaque fois.
En tous les cas, bravo très sincèrement car je vois à la pertinence de tes questions et de ton analyse que tu as fait un vrai (gros) travail de compréhension. Et chacune de tes questions et très pertinente. Merci ! Merci vraiement.
Tout ceci est en évolution et le sera sans doute encore longtemps mais tous les systèmes un peu sophistiqués sont dans ce cas. J’espère vraiment que je peux te compter parmi ceux qui expérimenteront et aideront à progresser.
Bien cordialement
Christophe
-
Mais Christophe, c'est moi qui te remercie !!!
Tu ne peux pas imaginer à quel point tes réponses me font plaisir, j'avais tellement peur de déplaire avec des questions stupides au regard de vos connaissances à tous...
De ce que j'en retiens dans l'immédiat, c'est qu'il est urgent de patienter... Ça, je devrais savoir faire...
Je prends le temps de bien analyser toutes tes réponses et reviendrai probablement vers toi pour celles que je n'aurais toujours pas comprises...
D'ici là, j'épluche ton message et me penche sur la centrale "DCC sur ESP32 (wifi)" que tu as développée, qui devrait également m'amener à de nouvelles interrogations,
que je développerai dans un autre post pour ne pas polluer celui-ci.
Je te renouvelle toutes mes félicitations pour ce projet que je trouve révolutionnaire, espérant que tu trouveras les ressources avec d'autres pour l'aboutir au mieux.
De mon côté, je ne peux pas vous être d'une grande utilité dans ce domaine, mais si je peux contribuer à quoi que ce soit dans ma partie (graphisme), c'est avec un immense plaisir que je le ferais.
Encore mille mercis, je suis de près l'évolution du projet.
Très sincèrement,
Fred.
-
Bonsoir Fred
Je vais te rassurer et aussi peut être te surprendre mais je aussi suis très loin de tout maitriser et les échanges communautaires ici même nous enrichissent mutuellement dans nos compréhensions, et pratiques diverses. Tu n'es pas le seul à mener tes ( /ces) réflexions. Tu es juste un des premiers à les formuler. Bravo et merci pour cet apport.
Collectivement nous allons pouvoir partager nos expériences de tous niveaux et chaque participation apporte ca pierre à l édifice ( ex ajd les cas de la gestion des rames " en pousse" ( motrice en queue) ou de boutons de commande)
Chacun ayant un projet diffèrent et une façon d'aborder les solutions à mettre en œuvre contribue a éprouver les solutions et d'en repousser leur limite.
Aussi les "early adopters" même néophytes tiennent un rôle important dans les retours d'expériences ( et doléances)!
Pas besoin d être ingénieur motoriste pour profiter/utiliser de son automobile tous les jours! On se concentre alors sur les sensations de conduite.
C'est la philosophie que Christophe pousse ( il y a des "trucs" sous le capot, regarde qui veut et pour la conduite chacun est libre d agir comme il veut en respectant toutefois les règles du code de la route/mise en œuvre) . On suit, on court et on en redemande!
Ltr.
-
Je me suis aperçu que je n’avais pas répondu à cette question.
6°/ À propos des Led pour les signaux de feux, si j'ai bien compris, le satellite se charge d'activer les led nécessaires à une position de signal ?
Mais alors, quelles Led sont à relier à quelles sorties de la carte ? J'ai vu qu'il y avait 2 x 8 plots, mais je ne comprends pas comment ils sont déterminés...
Par exemple est-il possible d'utiliser une de ces sorties pour allumer une led du TCO ?..
Le processus est le suivant. Pendant le mode Discovery, le programme détermine, en fonction de la typologie, le type de signal qui sera à horaire et celui qui sera à anti horaire. Il n’y a que deux signaux possibles (dans cette version). Selon la nature du signal, 5 leds pour horaire par exemple, le programme affecte donc 5 sorties dans l’ordre orange, rouge, vert, orange, orange, et s’il y a 3 leds à anti-horaire, les 3 sorties suivantes soit orange, rouge, vert.
-
Merci... Je précise ma question alors : Potentiellement deux signaux à 8 feux ?.. (Carré + Ralentissement + Rappel de ralentissement) ...
-
Oui tout à fait il y a 16 sorties disponibles donc 1 feu ralentissement ou rappel de ralentissement à horaire et 1 feu ralentissement ou rappel de ralentissement à anti horaire.
Christophe
-
Hello
Quelques questions dans la foulées de celle de Fred:
Gestion des led avec en Combo avec l'œilleton sur l'une des sortie?
Pour la gestion des Ralentissement 30 60 et Rappel de Ralentissement 30 60 faut il prévoir un câblage de chaque led en individuel ou en série?
Le niveau d intensité lumineuse de chaque sortie est il réglable ou faut il plutôt sélectionner un jeu de résistance/couleur de led/nombre de leds pour un optimum visuel.
Ltr
-
Gestion des led avec en Combo avec l'œilleton sur l'une des sortie?
Oui je n'en ai pas parlé mais c'est possible et déjà dans le programme.
Pour la gestion des Ralentissement 30 60 et Rappel de Ralentissement 30 60 faut il prévoir un câblage de chaque led en individuel ou en série?
Pas sûr de comprendre la question mais je me risque avec ce que je comprends. Il faut alimenter chaque led individuellement à la sortie des ULN (chaque led sa sortie). On est en anode commune
Le niveau d intensité lumineuse de chaque sortie est il réglable ou faut il plutôt sélectionner un jeu de résistance/couleur de led/nombre de leds pour un optimum visuel.
Non le niveau de chaque sortie n'est pas réglable. Oui il faut sélectionner les résistances selon le résultat que l'on veut avoir. Mais je rappelle la cible, je ne suis pas certain que pour le plus grand nombre cela ait une grande importance. Ou alors, on passe un peu de temps à tester le résultat avec des résistance de différentes valeurs. Ne doutons pas que les bonnes valeurs seront rapidement mises à disposition sur le forum !!!
Comme cela ça laisse des choses à réaliser pour les versions améliorées, d'autant que les réglages de PWM (s'il y en a) peuvent facilement se faire à partir de l'interface web.
Christophe
-
Pour la gestion des Ralentissement 30 60 et Rappel de Ralentissement 30 60 faut il prévoir un câblage de chaque led en individuel ou en série?
Pas sûr de comprendre la question mais je me risque avec ce que je comprends. Il faut alimenter chaque led individuellement à la sortie des ULN (chaque led sa sortie). On est en anode commune
On peut monter les diodes R30, RR30 et les rouges du carré en série ou en || et utiliser une seule sortie ULN. La résistance sera diférente dans les 2 cas.
Pour les valeurs de résistances on peut utiliser comme base les valeurs données par Renaud Yver pour les feux Decapod :
- led orange/jaune : 10 000 Ohms
- led rouge : 10 000 Ohms
- led verte : 80 000 Ohms
- led blanche : 30 000 Ohms
- led violette : 2 200 Ohms
4700 Ohms pour les diodes jaunes et rouges en // et je dirais 8200 Ohms pour les diodes en série
-
Pour la gestion des Ralentissement 30 60 et Rappel de Ralentissement 30 60 faut il prévoir un câblage de chaque led en individuel ou en série?
Pas sûr de comprendre la question mais je me risque avec ce que je comprends. Il faut alimenter chaque led individuellement à la sortie des ULN (chaque led sa sortie). On est en anode commune
On peut monter les diodes R30, RR30 et les rouges du carré en série ou en || et utiliser une seule sortie ULN. La résistance sera diférente dans les 2 cas.
Pour les valeurs de résistances on peut utiliser comme base les valeurs données par Renaud Yver pour les feux Decapod :
- led orange/jaune : 10 000 Ohms
- led rouge : 10 000 Ohms
- led verte : 80 000 Ohms
- led blanche : 30 000 Ohms
- led violette : 2 200 Ohms
4700 Ohms pour les diodes jaunes et rouges en // et je dirais 8200 Ohms pour les diodes en série
Oui, en principe c'est vrai que certaines leds sont allumées en même temps que les autres. Au moins les oranges. Le programme doit être modifié mais ça peut le faire : https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/src/Signal.cpp
Ca pourra poser problème si le satellite est réaffecté mais ça en posait de toutes façons.
Sur quelle tension te bases tu pour les valeurs des résistances ?
@Laurent - Voilà un sujet qui peut militer en faveur des sorties en PWM. Du coup, la valeur de la PWM serait définie par le programme même pour des valeurs de résistances identiques. Mais pas dans la version de base dont je cois que vous comprenez bien à quel public et quel usage je les destine.
Christophe
Dans tous les cas, on voit bien toutes les marges de progression possibles
-
Hello
Pour moi la "simplicité" serait de poser un chip I2C type PCA9685 qui peut piloter servo, relais et leds sans soucis.
Chaque canal peut avoir son propre PWM commandé par un "analogwrite()... facilement customisable selon la couleur des leds depuis l'interface web de config/réglages.
Une valeur moyenne de la résistance fait le job de protection par défaut. ( disons 10K pour 5V)
Mais je suis peut être trop optimiste? Apres si le temps de réaction est un peu long pas de soucis la dessus, ce n est pas vital.
Il faut juste que la commande de servo soit achevée quand un engin va franchir l'appareil. (en gros entre 1 et 2 sec pour manipuler le servo de la position de départ à celle d'arriver.)( x nb de servo a manipuler l'un après l'autre)
Temporisable donc...
Apres si pour le signaux on confie cela à un accessoire externe qui pilote les états des leds, il faut juste envoyer une commande d'un byte par exemple (1fois) qui sera interprétée par ce décodeur de signal qui combinera alors l'affichage des leds selon l'affichage sur le feu désiré. ( ex un rappel cli avec œilleton est la combinaison commandée par l instruction 18, le carré par l instruction 1, le VL par l'instruction 5... ( valeurs arbitraires pour démo)
Et pendant ce temps l'ESP32 mouline à autre chose pour ne traiter les changements d état des signaux que lorsque c'est requis.
Ltr
Ltr
-
Je ne sais pas te répondre comme cela, c'est beaucoup d'informations que tu envoies en peu de temps qui mériteraient plus de réflexion. Par ailleurs, j'ai toujours besoin de vision globale pour comprendre toutes les interactions et j'ai parfois du mal à savoir où tu es exactement.
Pense par exemple que si l'on change le mode d'affichage des leds maintenant, ça change des choses dans le programme. Idem pour les servos. Je ne peux pas me permettre de m'éloigner trop en ce moment. Je dois capitaliser sur ce qui marche.
Ce n'est pas plus simple pour moi puisque tu me proposes quelque choses qui comporte des incertitudes contre quelque chose qui fonctionne.
Et puis il faut que j'avance sur la rédaction des articles.
Par contre je suis vraiment très intéressé par la gestion des CC et de la détection "courants faibles" car j'ai un besoin et sinon je me le coltine moi même. Après, promis je collaborerai plus.
Christophe
-
Pas de soucis
Chaque chose en son temps
Je vais attaquer ce WE la partie détection de présence avec courant faible en approche modulaire. Je proposerai donc plusieurs déclinaisons selon les propositions données dans les échanges antérieurs sur ce sujet https://forum.locoduino.org/index.php?topic=1656.0 (https://forum.locoduino.org/index.php?topic=1656.0)
Les montages seront substituables par échange du bouclier les uns aux autres puisque j aurai défini un format pour le volumes global et les I/O d interface qui sont identiques.
Ltr
-
Bonjour à tous les deux
@ Laurent & Christophe
Pourriez-vous svp faire un point (genre tableau ou autre) ou vous en êtes.
Entrées, sorties, cour circuit, leds, résistances, PCB, etc....
Marcel
-
Bonjour à tous,
Je pense qu’il est bien comme l’a demandé Catplus, de faire un point d’étape sur le projet des satellites autonomes.
Tout d’abord, une certaine confusion a pu s’installer car deux fils avec des intitulés similaires ont eu une activité assez intense ces derniers jours.
Donc pour que les choses soient claires, il y a ce projet de satellites autonomes qui est maintenant finalisé, qui fait l’objet d’une série d’articles en cours et qui est aussi l'objet de ce fil : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
Peu de temps après que j’ai commencé à publier sur ce sujet, notre bouillonnant Géo Trouvetou de Locoduino en la personne de Laurent a proposé sur un autre fil de rechercher des évolutions et des extensions à ce concept, mais en cherchant plutôt à en élargir les capacités.
Si je me risquais a faire une analogie empruntée au monde automobile, je dirais que le satellite autonome est une berline familiale alors que la démarche de Laurent se rapproche plus du prototype de course en cours d'élaboration.
Autant le concept de satellite autonome dans sa version actuelle s’adresse à des réseaux de petites et moyennes tailles, autant la démarche de Laurent semble viser des réseaux de grande importance et cherche à résoudre des besoins plus complexes. Du moins, me semble t’il.
Concernant les satellites autonomes, il y cependant un point que je n’avais pas traité et que j’ai trouvé sur le fil de Pierre et Denis : La détection de véhicules roulants autres que les locomotives. Pour faire simple, les wagons qui n’auraient pas encore quitté un canton ou qui se serait décrochés (le résultat est le même).
Ce point est primordial dès que l’on va commencer à introduire une gestion d’itinéraires partiellement ou totalement automatisée.
J’ai donc pris du temps pour travailler ce point avec un second qui met en œuvre des équipements similaires : La détection des courts-circuits locaux.
Aujourd’hui, la plupart des réseaux ont une détection des courts-circuits qui est centralisée avec un détecteur par consommation de courant et une coupure d’alimentation logicielle à l’intérieur de la centrale.
Dans l’esprit des satellites, il m’a semblé important que cette détection des courts circuits soit assurée au niveau local (chaque satellite ayant son propre système) et que la coupure de l’alimentation ne soit plus logicielle mais matérielle ce qui, au moins sur le papier, doit être plus rapide.
L’un des autres avantage d’une détection locale est que la coupure d’alimentation peut intervenir plus rapidement qu’avec un système centralisé dès que le courant dépasse par exemple 1A qui est normalement la consommation maximum sur un canton.
Certes, les satellites autonomes savent fonctionner avec une détection de court circuits centralisée et les deux peuvent cohabiter, mais le progrès me semblait tel que j’ai souhaité l’intégrer dès la première version, quitte à prendre un peu de retard.
Ces derniers temps, j’ai aussi passé pas mal de temps sur la question de l’intégration de Railcom dans la Box de Locoduino. En effet, bien qu’il existe une solution alternative au travers d’une centrale Railcom que j’ai développée, je souhaitais, dans une approche pérenne, utiliser la Box plus complète, pour laquelle également j’ai développé les commandes CAN et qui surtout fait l'objet d'un suivi et d'une assistance ce que je ne peux pas faire avec ma centrale.
Il ne fait maintenant plus de doute, en particulier à la lecture des annonces de DCC-Ex, que les fonctionnalités nécessaires à Railcom ne seront pas implantées pour ESP32, donc la Box qui s'appuie aujourd'hui sur ce logiciel.
La solution de replis qui me semble la plus réaliste, au moins à court terme, est l’implantation sur Arduino Mega. C’est en tous les cas celle que je vais prendre.
Sur la branche devel du Github de DCC-Ex, on peut voir que les développements de Railcom sont bien avancés en particulier pour le Mega et je ne serai pas étonné que cette version (qui n’est que ßeta) soit pourtant opérationnelle.
https://github.com/DCC-EX/CommandStation-EX/blob/devel (https://github.com/DCC-EX/CommandStation-EX/blob/devel)
et particulièrement :
https://github.com/DCC-EX/CommandStation-EX/blob/devel/DCCTimerAVR.cpp (https://github.com/DCC-EX/CommandStation-EX/blob/devel/DCCTimerAVR.cpp)
Je vais donc en faire le test dès mon retour en France.
Alors, quelle est la suite. Je vais être en mesure de publier d’ici quelques jours le cinquième article qui en quelque sorte va conclure sur ce que l’utilisateur doit savoir pour mettre en œuvre et utiliser facilement les satellites autonomes sur son réseau et ce, sans avoir à lever le capot, ce qui était mon ambition dès le départ.
Ensuite, je publierai le code qui intéresse les développeurs mais probablement pas la grande majorité des utilisateurs.
Ce que je souhaite de la part de tous les lecteurs, c’est qu’ils me fassent part de toutes leurs questions, incompréhensions, réserves etc… car c’est comme cela que je pourrai bien sûr améliorer ce qui doit l’être.
Et si vous êtes tenté par l’aventure, je vous invite vivement à vous manifester car je pourrai alors vous accompagner et vous faciliter les choses, à minima, par des achats groupés de PCB ou de matériel.
Christophe
-
Bonjour
J'ai apporté une vision sous forme de tableau de synthèse dans le fil correspondant aux évolutions.
Pour ce qui est de la démarche je confirme ce que Christophe indiquait plus tôt.
Sur la base de son concept il me fallait pousser plus loin l'approche initiale en la complétant pour pouvoir couvrir des mises en œuvre plus étendues ( ex cas des zones d'aiguillages étendues)
Une base commune d'évolutions comme l'a indiqué Christophe était aussi de traiter au niveau local la détection de CC et l'occupation hors RAILCOM.
Ces ajouts sont nativement intégrés à la "V2" en approche modulaire qui est décrite dans le fil traitant des évolutions.
Sachant qu'il s'agit de concepts en cours de définition (affinage) et évoluant il faut bien garder à l'esprit le coté expérimental contrairement à la solution native présentée ici déjà opérationnelle.
Laurent
-
Bonsoir à tous
Merci à vous deux pour toutes ces explications & votre travail accompli.
J'espère que de nombreux Arduinoistes feront le pas.
Marcel
-
Bonjour à tous,
Parlons argent puisque la question a été posée sur un autre fil concernant les satellites autonomes. Je me suis donc livré au chiffrage des principaux éléments dont tous, sauf un, proviennent de chez TME dont je suppose la qualité ne sera pas discutée.
Si vous allez chez Ali vous avez 5 ESP pour le prix d'1 chez TME :)
Vous me dispenserez de chiffrer les résistances, diodes et autres composants dont les prix unitaires sont inférieurs au dixième d'€
(https://www.locoduino.org/IMG/png/evaluation_prix_satellite-2.png)
Nous arrivons pour les satellites à 24,51€ et pour les cartes Railcom à 5,48€.
Qui dit mieux ?
PS : En PJ le fichier Excel qui vous donne les liens
Christophe
-
Il faut que je me livre au même type d exercice pour chaque bouclier car en CMS, il y a le montage usine a ajouter en supplément. ( un peu la flemme de le faire tt de suite!)
Le plus onéreux à produire sera selon moi le module RAILCOM qui est à implantation bi face.
Si on considère que les modules seront finalisés avec leur CMS il resterait alors à tous les composants traversant qui seront alors à souder ( connecteurs et supports)
On peut demander à l'usine de le faire mais le cout n'est pas avantageux et souder un support ou un connecteur n'est pas d'une difficulté majeure! C'est un kit
A titre d exemple pour ce qui est des connecteurs ( sources ALIEXPRESS) pour environ 100€ on doit pouvoir réaliser près de 50 cartes (tous connecteurs confondus)...
On a déjà vu pire la aussi!
Ltr
-
Bonjour à tous,
Je viens de publier le 5° article qui commence à aborder le programme mais qui précise aussi où et comment renseigner les identifiants de votre box.
https://www.locoduino.org/spip.php?article352 (https://www.locoduino.org/spip.php?article352)
Bonne lecture.
-
Bonjour et merci à tous,
je me lancerais bien dans la fabrication de quelques modules (3 ou 5) pour commencer et tester, mais il me manque encore quelques infos...
Peut-être ont-elles déjà fait l'objet de réponses, mais ou je ne les ai pas trouvées, ou je ne les ai pas comprises...
Il y aurait dans les tuyaux ou dans les tiroirs une "V2" des satellites autonomes, mais encore en développement ?..
Et si j'ai bien compris, celle-ci, la "V1" est opérationnelle et l'on peut se lancer dans sa fabrication ?..
1°/ Cette "V2" des satellites autonomes, est-ce une amélioration apportée et proposée sur les différents fils de discussion (en particulier "Les SATELLITES AUTONOMES: évolutions du socle initial") ou ferait-elle l'objet d'un "Post" à elle seule ?..
2°/ Pour ce qui est de la commande des aiguilles adressée au satellite par le bus can, j'en ignore tout de la mise en œuvre :
J'imagine (mais j'ai peut être trop d'imagination), qu'il doit falloir insérer un nouveau nœud dans le bus qui relie déjà les satellites et les deux cartes Main et watchdog,
mais alors, si c'est bien le cas, à quoi est relié ce nœud ?..
Une carte capable de générer le message de changement de direction et de l'envoyer à la bonne adresse, ou une "manette" de pilotage reliée à la centrale qui serait capable de faire la même chose en plus des commandes destinées aux locos ?
Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ? (Au regard de toutes vos inventions, j'ai du mal à imaginer le contraire)...
Où puis-je la trouver avec ses explications, schémas, Gerber, codes, etc ?..
Locoduino est un grand bazar (au bon sens du terme), super bien achalandé, mais dans lequel j'ai encore un peu de mal à m'y retrouver...
3°/ Pour ce qui est de l'utilisation d'une centrale compatible RailCom®, peut-on se lancer dans la fabrication de "La Box" comme ça semblerait être proposé dans le post
"Détection RailCom© avec ESP32 (ou Arduino)" (https://www.locoduino.org/spip.php?article334 (https://www.locoduino.org/spip.php?article334)) ou vaut-il mieux faire confiance au projet de Christophe,
"Une station DCC compatible RailCom" (https://forum.locoduino.org/index.php?topic=1352.0 (https://forum.locoduino.org/index.php?topic=1352.0)) ?..
Quelqu'un pourrait-il également m'indiquer le lien à suivre pour envisager la fabrication de la centrale idoine ?..
Une fois encore, je présume qu'il y aura un nouveau "nœud" reliant la centrale à notre bus ?..
Et pour terminer,
4°/ Pour faire circuler les informations du can et le 12/24v, de quels câbles avons-nous besoin ?
- RJ45 (4 paires) ou RJ12 (3 paires) ?
- Câbles droits ou croisés ?
- Blindés ou non ? (J'ai bien vu toutes les interventions et croisements de fers, mais je n'ai pas réussi à me faire une opinion...
- Quelles sont les identifications de chaque fil ?
Pour tous ceux qui le souhaiteraient, je suis prêt à m'associer à une commande de PCB, avec ou sans les fournitures concernées,
pour la fabrication de 3 ou 5 cartes satellites,
la même quantité pour les cartes de détection du signal Railcom©
et 2 pcb pour la Main et la Watchdog... Et plus si affinités...
-
Bonjour et merci à tous,
je me lancerais bien dans la fabrication de quelques modules (3 ou 5) pour commencer et tester, mais il me manque encore quelques infos...
Peut-être ont-elles déjà fait l'objet de réponses, mais ou je ne les ai pas trouvées, ou je ne les ai pas comprises...
Bonjour Frédéric,
Tu trouveras ci-dessous les réponses à tes questions toujours très pertinentes.
Il y aurait dans les tuyaux ou dans les tiroirs une "V2" des satellites autonomes, mais encore en développement ?..
Et si j'ai bien compris, celle-ci, la "V1" est opérationnelle et l'on peut se lancer dans sa fabrication ?..
C’est vrai que cette « évolution » que Laurent a lancée aurait mérité un peu plus d’explications sur son positionnement et sa raison d’être. Je ne doute pas qu’il le fera sur le fil de son projet. C’est vrai que la dénomination V2 n’est pas appropriée et je ne sais d’ailleurs pas comment elle est apparue.
De ce que moi j’en comprends, il s’agit d’une version « plus musclée » qui correspondrait mieux à de plus grands réseaux (on parle de cantons de 3 mètres !!!), qui prendrait en charge plus d’équipements (plus d’aiguilles par exemple) et chercherait à améliorer ce qui pourrait éventuellement l’être dans mon projet.
Mais comme je l’ai dit, Laurent t’apportera mieux que moi ces réponses.
Pour ce qui est des satellites autonomes (pas v1), oui elle est opérationnelle, cela fait maintenant six mois environ que je la teste sur mon propre réseau.
2°/ Pour ce qui est de la commande des aiguilles adressée au satellite par le bus can, j'en ignore tout de la mise en œuvre :
J'imagine (mais j'ai peut être trop d'imagination), qu'il doit falloir insérer un nouveau nœud dans le bus qui relie déjà les satellites et les deux cartes Main et watchdog,
mais alors, si c'est bien le cas, à quoi est relié ce nœud ?..
Une carte capable de générer le message de changement de direction et de l'envoyer à la bonne adresse, ou une "manette" de pilotage reliée à la centrale qui serait capable de faire la même chose en plus des commandes destinées aux locos ?
Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ? (Au regard de toutes vos inventions, j'ai du mal à imaginer le contraire)...
Où puis-je la trouver avec ses explications, schémas, Gerber, codes, etc ?..
Locoduino est un grand bazar (au bon sens du terme), super bien achalandé, mais dans lequel j'ai encore un peu de mal à m'y retrouver...
Ce qu’il faut essentiellement avoir présent à l’esprit, c’est que les satellites autonomes privilégient la communication par le bus CAN à toutes autres forme de communication quand cela est possible. Le TCO n’échappe pas à la règle.
Donc je te redis clairement ce que j’ai dis déjà la dernière fois, les satellites reçoivent en effet les ordres de commande des aiguilles sous forme de messages CAN.
Il y a plusieurs façons d’envisager un TCO, il peut être virtuel, sur tablette ou écran ou bien physique avec de vrais boutons, de vraies leds etc… Le fait de communiquer en CAN permet au satellite autonome de répondre à toutes les formes choisies.
Puisque tu penses TCO physique, voici comment je procéderais. Les boutons de commande des aiguilles étant des boutons poussoirs répartis sur le tableau avec une lisibilité et une ergonomie maximale. Mais en tant que graphiste, tu dois savoir faire. Pour le micro contrôleur, je choisirais un Mega pour avoir d’emblée beaucoup d’entrées (boutons…) et de sorties (leds…).
Je choisirais un shield CAN (plutôt un Seeed Studio) qui fonctionne à 1Mbs : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/
Ce Mega avec son shield s’insèrent dans le bus CAN très simplement en reliant les fils du précédent et du suivant. Il devient de cette façon un nouveau nœud du bus CAN mais sans rien de plus.
Selon que l’on appuie sur tel ou tel bouton, le programme du Mega détecte que la commande est adressée à tel ou tel satellite et que cela concerne le servo 0, 1, 2 ou 3 du satellite. Et il allume alors la led correspondante.
Voilà, je ne veux pas faire trop long mais tu as ici le principe général pour un TCO physique. Il y en a eu un article, il y a longtemps mais c’était en xpressnet : https://www.locoduino.org/spip.php?article42
Ca peut te donner une idée.
Je suis très partant pour réaliser le programme pour un bus CAN si tu réalises la partie « physique ». Ce sera un bon sujet à partager.
3°/ Pour ce qui est de l'utilisation d'une centrale compatible RailCom®, peut-on se lancer dans la fabrication de "La Box" comme ça semblerait être proposé dans le post
"Détection RailCom© avec ESP32 (ou Arduino)" (https://www.locoduino.org/spip.php?article334 (https://www.locoduino.org/spip.php?article334)) ou vaut-il mieux faire confiance au projet de Christophe,
"Une station DCC compatible RailCom" (https://forum.locoduino.org/index.php?topic=1352.0 (https://forum.locoduino.org/index.php?topic=1352.0)) ?..
Quelqu'un pourrait-il également m'indiquer le lien à suivre pour envisager la fabrication de la centrale idoine ?..
Une fois encore, je présume qu'il y aura un nouveau "nœud" reliant la centrale à notre bus ?..
Décidément, tu sais aborder les bons sujets !
Oui les satellites autonomes ont besoin sur le réseau d’une centrale DCC qui puisse générer un cutout. A l’heure actuelle, la Box ne dispose pas de cette faculté.
Alors, je ne parlerai pas de « confiance » pour la station que j’ai réalisée mais simplement d’option à ce stade. Oui cette station, couplée à une carte LMD18200 est la seule qui puisse être aujourd'hui utilisée avec les satellites autonomes. Mais cette station, qui fonctionne, était au départ un sujet de recherche et d’expérimentation en attendant Railcom sur la Box. Je ne souhaite pas en assurer le support ni les évolutions. Elle peut cependant être adopté en sachant qu’il faudra un jour basculer et que cela n’induit aucun cout qui ne soit réutilisable comme le LMD18200.
Dans un second temps, comme la version Railcom de DCC Ex sera disponible sur Mega (l’est peut-être déjà en Beta), je pense que ce sera une bonne évolution. Toujours avec un LMD18200
L’insertion de cette station dans le bus CAN se fera aussi simplement que montré plus haut et deviendra alors un nœud CAN également.
Et pour terminer,
4°/ Pour faire circuler les informations du can et le 12/24v, de quels câbles avons-nous besoin ?
- RJ45 (4 paires) ou RJ12 (3 paires) ?
- Câbles droits ou croisés ?
- Blindés ou non ? (J'ai bien vu toutes les interventions et croisements de fers, mais je n'ai pas réussi à me faire une opinion...
- Quelles sont les identifications de chaque fil ?
Pour tous ceux qui le souhaiteraient, je suis prêt à m'associer à une commande de PCB, avec ou sans les fournitures concernées,
pour la fabrication de 3 ou 5 cartes satellites,
la même quantité pour les cartes de détection du signal Railcom©
et 2 pcb pour la Main et la Watchdog... Et plus si affinités...
Il s’agit de câbles RJ45 de catégorie 5 ou 6. Pas de câble croisé (mais cela existe-t-il encore ?). En catégorie 5 ou 6 je crois qu’ils sont d’office blindés. C’est du basique, ce qu’il y a de plus courant et de moins cher (moins d’un €).
En utilisant ces câbles tu n’as pas de soucis d’identification des fils, sauf option particulière que je ne recommande pas mais je te donnerai alors l’identification si tu procèdes ainsi.
Comme tu es le premier à te lancer, je te propose de t’accompagner pas à pas et effectivement de faire des commandes groupées. J’allais justement envoyer une commande de PCB, je peux en mettre 5 de plus.
Par ailleurs, j’ai tous les composants en quantité et je dois envoyer une nouvelle commande (pour ce projet et d’autres).
Ce que je te propose pour tout ce qui est de nature perso, c’est d’échanger en MP.
Christophe
-
Bonsoir
Je répondrai volontiers aux différentes questions dans le post dédié aux évolutions.
J'y ai actualisé les premiers chiffrages sur la base d'une réalisation "en volume" (tirage de 80 pièces)
Pour le moment cela reste très compétitif mais il reste encore à chiffrer une partie du montage... c est en cours! De bonnes surprises ne sont pas à exclure.
Ltr
-
Bonjour Christophe
J'ai une question à propos du mode DISCOVERY et de l'état de la LED.
Lorsque l'on associe une paire de satellites le fait de presser 1 bouton sur le premier va faire clignoter la led de celui ci.
Cet état de clignotement reste présent sur chaque satellite dont 1 bouton est pressé tant que le processus d association n'est pas achevé.
Le processus d'association bascule la led en allumage FIXE une fois le processus d'appairage achevé ET que 1 bouton sur chaque satellite reste pressé.
Elle est OFF ensuite en fois les boutons relâchés.
C est bien cela? ( elle est OFF en utilisation normale)
Si par "accident" un bouton d'appairage est pressé sans autre binôme dans le processus de découverte il n'y a pas de modification des attributions existantes?
Que se passe t il si un satellite n'a pas de voisin? (soit horaire soit antihoraire) C'est le cas d'une voie en impasse par exemple.( tiroir ou gare terminus)
J'imagine que le soft gèrera le ralentissent dans la zone traitée par ce satellite et arrêtera le train une fois le capteur ponctuel horaire atteint. C'est bien cela?
Pour un mouvement dans le sens de circulation opposé, y a t il des critères à avoir?
Tout mouvement des lors que les sécurités de "bloc automatique" sont respectées sont autorisées dans une zone d'un satellite donné?
Ltr
-
Lorsque l'on associe une paire de satellites le fait de presser 1 bouton sur le premier va faire clignoter la led de celui ci.
OUI
Cet état de clignotement reste présent sur chaque satellite dont 1 bouton est pressé tant que le processus d association n'est pas achevé.
OUI
Le processus d'association bascule la led en allumage FIXE une fois le processus d'appairage achevé ET que 1 bouton sur chaque satellite reste pressé.
OUI
Elle est OFF ensuite en fois les boutons relâchés.
OUI
C est bien cela? ( elle est OFF en utilisation normale)
OUI
Si par "accident" un bouton d'appairage est pressé sans autre binôme dans le processus de découverte il n'y a pas de modification des attributions existantes?
NON
Que se passe t il si un satellite n'a pas de voisin? (soit horaire soit antihoraire) C'est le cas d'une voie en impasse par exemple.( tiroir ou gare terminus)
J'imagine que le soft gèrera le ralentissent dans la zone traitée par ce satellite et arrêtera le train une fois le capteur ponctuel horaire atteint. C'est bien cela?
OUI, s'il n'y a aucun satellite identifié à la sortie d'un canton (en fonction de la position des aiguilles éventuellement) on est dans le même cas que pour un canton occupé, le signal se met au rouge, le train frein puis s'arrête !
Pour un mouvement dans le sens de circulation opposé, y a t il des critères à avoir?
Pas comprendre la question
Tout mouvement des lors que les sécurités de "bloc automatique" sont respectées sont autorisées dans une zone d'un satellite donné?
Les commandes des trains ne suivent pas la signalisation qui n'est la que pour la décoration. Le satellite déduit des possibilités en fonctions de son environnement (position des aiguilles, occupation ou non de cantons voisins (jusqu'à +2). Ce sont ces états qui conditionnent si l'on peut appliquer tel ou tel ordre à une locomotive et qui déduisent la signalisation adéquate.
-
Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ?
Pour répondre au souhait de LocoFred de réaliser un TCO « physique », avec des boutons poussoirs pour changer la position des aiguilles sur les satellites autonomes, j’ai écrit ce petit programme qui fait le job.
Je suis parti d'un postulat qui est que nous avions 10 aiguilles (donc 10 boutons)
const uint8_t nb_btn = 10; // Nombre de boutons
Que la première broche utilisée (sur un Mega) est la broche 20.
const byte firstBtnPin = 20; // Première broche de connexion des boutons
Que les boutons actionnent dans l'ordre les aiguilles des satellites comme suit :
btn[0].sat = 11; btn[0].aig = 0;
btn[1].sat = 11; btn[1].aig = 1;
btn[2].sat = 12; btn[2].aig = 0;
btn[3].sat = 12; btn[3].aig = 1;
btn[4].sat = 12; btn[4].aig = 2;
btn[5].sat = 13; btn[5].aig = 0;
btn[6].sat = 14; btn[6].aig = 0;
btn[7].sat = 14; btn[7].aig = 1;
btn[8].sat = 15; btn[8].aig = 0;
btn[9].sat = 16; btn[9].aig = 0;
La bibliothèque CAN utilisée est acan2515 de Pierre Molinaro : https://github.com/pierremolinaro/acan2515/tree/master (https://github.com/pierremolinaro/acan2515/tree/master)
Le shield CAN recommandé est celui de SEED Studio : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/ (https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/)
qui autorise 1Mbps de débit.
Sur un Mega, il sera nécessaire de respecter le brochage suivant :
(https://europe1.discourse-cdn.com/arduino/original/3X/1/6/1682709e0a37454a76b5f3207c6c4ee0c1434813.jpg)
Voici le code que vous pouvez aussi télécharger :
/*
Etude du programme pour des commandes d'aiguilles à partir de boutons poussoirs sur un TCO (physique)
à destination des satellites autonomes
Ce programme est destiné à fonctionner sur Arduino Uno ou Mega.
Les broches sont commutées sur HIGH à l'état repos de boutons poussoirs par activation des résistances PULLUP internes
Elles sont commutées sur LOW par l'appui sur le bouton poussoir lorsqu'elles reçoivent un signal à la masse (GND)
Cet état LOW correspond au bouton appuyé.
v 0.0.1 - 21/02/2024
copyright (c) 2024 christophe.bobille - LOCODUINO - www.locoduino.org
*/
const byte thisNodeId = 252; // N° de nœud CAN du TCO sur le bus
const uint8_t nb_btn = 10; // Nombre de boutons
const byte firstBtnPin = 20; // Première broche de connexion des boutons
const uint32_t delayDebonce = 100; // Delay du debonce (en millisecondes)
const uint32_t delaySendMsg = 2000; // Delay entre l'envoi de messages CAN (en millisecondes)
class Button
{
private:
public:
byte ID;
byte pin;
bool pressed;
uint32_t lastDebounceTime;
uint32_t lastTimeSendMsg;
byte sat;
byte aig;
Button();
};
Button::Button() // Constructeur
: ID(0),
pin(255),
pressed(false),
lastDebounceTime(0),
lastTimeSendMsg(0) {}
Button btn[nb_btn]; // Instances de Button
/************************ ACAN *****************************/
// If you use CAN-BUS shield (http://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/) with Arduino Uno,
// use B connections for MISO, MOSI, SCK, #9 or #10 for CS (as you want),
// #2 or #3 for INT (as you want).
#include <ACAN2515.h>
static const byte MCP2515_CS = 53; // CS input of MCP2515 (Arduino Mega)
static const byte MCP2515_INT = 2; // INT output of MCP2515 (Arduino Mega)
ACAN2515 can(MCP2515_CS, SPI, MCP2515_INT);
static const uint32_t QUARTZ_FREQUENCY = 16UL * 1000UL * 1000UL; // 16 MHz
CANMessage frame; // Instance de CANMessage
/**********************************************************/
void setup() {
Serial.begin(115200);
/************************ ACAN *****************************/
//--- Begin SPI
SPI.begin();
//--- Configure ACAN2515
Serial.println("Configure ACAN2515");
ACAN2515Settings settings(QUARTZ_FREQUENCY, 1000UL * 1000UL); // CAN bit rate 1000 kb/s
const uint16_t errorCode = can.begin(settings, [] {
can.isr();
});
if (errorCode != 0)
{
Serial.print("Configuration error 0x");
Serial.println(errorCode, HEX);
}
/************************ ACAN : paramètres du messages *******************/
// Structure de l'identifiant des messages CAN : https://www.locoduino.org/IMG/png/satautonomes_messageriecan_v1.png
const byte prio = 0x03; // Priorité la moins élévée
const byte commande = 0xE1; // Identifiant des commandes d'aiguilles pour les satellites autonomes
const byte resp = 0x00; // Ceci n'est pas une réponse
frame.id |= prio << 27; // Priorite 0, 1 ou 2
frame.id |= commande << 19; // commande appelée
frame.id |= thisNodeId << 11; // ID expediteur
frame.id |= resp << 2; // Response
frame.ext = true; // Identifiant long (29 bits) = true
frame.len = 2; // Nombre d'octets de données du message
/**********************************************************/
for (byte i = 0; i < nb_btn; i++)
{
btn[i].ID = i;
btn[i].pin = firstBtnPin + i;
pinMode(btn[i].pin, INPUT_PULLUP);
Serial.print("setup btn : ");
Serial.println(i);
}
// Exemple d'aiguilles à commander
// sat désigne sur quel satellite s'applique la commande
// aig désigne sur quelle aiguille de ce satellite s'applique la commande
btn[0].sat = 11; btn[0].aig = 0;
btn[1].sat = 11; btn[1].aig = 1;
btn[2].sat = 12; btn[2].aig = 0;
btn[3].sat = 12; btn[3].aig = 1;
btn[4].sat = 12; btn[4].aig = 2;
btn[5].sat = 13; btn[5].aig = 0;
btn[6].sat = 14; btn[6].aig = 0;
btn[7].sat = 14; btn[7].aig = 1;
btn[8].sat = 15; btn[8].aig = 0;
btn[9].sat = 16; btn[9].aig = 0;
}
void loop()
{
for (byte i = 0; i < nb_btn; i++)
{
// Le bouton est détecté comme appuyé
if (LOW == digitalRead(btn[i].pin))
{
// L'état pressed est vrai et le delay de debonce est dépassé
if (btn[i].pressed && millis() > btn[i].lastDebounceTime + delayDebonce)
{
// Le delai par rapport au dernier envoi est dépassé
if (millis() > btn[i].lastTimeSendMsg + delaySendMsg)
{
// Envoi du message CAN de commande
frame.data[0] = btn[i].sat; // ID satellite destinataire
frame.data[1] = btn[i].aig; // Aiguille à commuter
const bool ok = can.tryToSend(frame);
if (ok)
btn[i].lastTimeSendMsg = millis();
else
Serial.println("Send failure");
}
btn[i].lastDebounceTime = millis();
}
btn[i].pressed = true;
}
else
btn[i].pressed = false;
}
}
-
Bonjour à tous et compliments pour votre brainstorming (c'est mieux que orage de cerveaux :D).
Je souhaite réaliser un réseau mettant en oeuvre les satellites autonomes https://www.locoduino.org/spip.php?article348 (https://www.locoduino.org/spip.php?article348). Pour cela j'ai besoin de réaliser les cartes main et watchdog et en plus la centrale DCC compatible Railcom. Je cherche désespérément dans les topics et le forum le schéma de cette carte ESP32 universelle et la manière de la raccorder au LMD18200.
Pouvez-vous m'indiquer un lien ?
Un lien sur le fichier Gerber ou un site marchand pour le circuit imprimé me ferai également gagner du temps; sinon tant pis je me mettrai au travail sur Kicad...
Un grand merci d'avance.
Cordialement
-
Bonjour,
Pour le lien sur le PCB de la carte ESP32 universelle, il est ici : https://forum.locoduino.org/index.php?topic=1648.msg17802#msg17802
ou plus directement ici : https://www.locoduino.org/IMG/zip/esp32_can_v6_38_pins_gerber-2.zip
Tu notes bien que tous ls composants ne sont pas obligatoirement à commander.
Le fil pour la centrale DCC Railcom est ici : https://forum.locoduino.org/index.php?topic=1352
Le programme de la centrale est téléchargeable ici : https://github.com/BOBILLEChristophe/DCCxx-ESP32-Railcom
Bien lire le readme sur la première page du Github qui donne les pins à raccorder. En particulier pour le CAN qui utilise le broches 22 et 23 au lieu de 4 et 5 habituellement.
#define CAN_RX GPIO_NUM_22
#define CAN_TX GPIO_NUM_23
Pour les autres broches :
#define PIN_PWM GPIO_NUM_12 // ENABLE (PWM)
#define PIN_DIR GPIO_NUM_13 // SIGNAL (DIR)
#define PIN_BRAKE GPIO_NUM_14 // CUTOUT (BRAKE)
#define CURRENT_MONITOR_PIN_MAIN GPIO_NUM_36 // Mesure de courant
Pour les composants, s'il t'en manque ou si parfois il faut commander de trop grosses quantités, tu me fais signe car j'ai pas mal de réserve.
Attention aussi à commander les bons ESP32 (wroom, 2cœurs, 240Mhz, 38 pins) En cas de doute, ne pas hésiter à m'envoyer le lien.
Je vais aussi relancer une commande de PCB pour les satellites (mais ce n'est pas ce qui coute le plus cher).
Et n'hésite surtout pas à partager si tu as des questions, des problèmes ou si tout fonctionne bien pour en faire profiter tout le monde.
Christophe
-
Bonjour et merci Christophe.
Je ne manquerai pas de revenir vers toi si pb rencontrés.
Pour l'instant j'essaie de définir mon système et tes renseignements vont me permettre d'y voir plus clair.
Merci encore
-
Pour répondre au souhait de LocoFred de réaliser un TCO « physique », avec des boutons poussoirs
Servi sur un plateau...
Merci Christophe !..
-
Je suis parti d'un postulat qui est que nous avions 10 aiguilles (donc 10 boutons)
Peut-on envisager de commander jusqu'à 30 aiguilles par "Mega" ?..
Broches 20 à 49 ?..
Voire plus (broches 3 à 13) ?..
Bon, je suis un peu gourmand, mais comme "qui peut le plus peut le moins",
mieux vaut savoir tout de suite à quoi s'en tenir non ?..
;D
-
Avec quelques composants additionnels on peut faire tout ce qu’on veut :
Mon TCO est animé par un Arduino MEGA 2560 qui gère :
- 20 inverseurs d’aiguilles = 20 pattes : AG1 à AG20 sur 21 bornes avec Gnd
- 36 Leds vertes (positions aiguilles) : 5 x 74HC595 chainés = 3 pattes
- 36 Leds rouges (occupations) : 5 x 74HC595 chainés = +1 patte
- 35 Détecteurs occupation = 35 pattes
- 36 bornes avec Gnd (y.c. va-et-vient)
- Bus CAN = 5 pattes (port SPI)
- Console = 2 pattes (port USB)
AU TOTAL = 68 pattes sur 70 !
https://forum.locoduino.org/index.php?topic=290.msg3411#msg3411 (https://forum.locoduino.org/index.php?topic=290.msg3411#msg3411)
-
Voilà qui me semble une optimisation optimale de ce que l'on peut faire pour un TCO avec un MEGA.
@Dominique, je ne comprends pas 5 x 74HC595 chainés = 3 pattes ? Je pensais que l'on ne pouvait enchainer que deux 74HC595.
Combien de leds peuvent-être allumée en même temps ? Ou, ce qui est la question exacte, quel est le courant maxi nécessaire pour les leds ?
Christophe
-
Effectivement, on peut chainer beaucoup de 74HC595.
J'ai essayé avec 10 au début mais c'était lent et avec 2 chaines de 5 c'est très rapide.
Toutes les leds peuvent être allumées en même temps, avec les limitations des leds et des sorties du 595. C'est un registre à décalage avec ses propres Latch internes. !
J'ai une animation au démarrage, genre sapin de Noel. Ca en jète !
Tout le programme dans un seul .ino est en PJ, si ça peut aider...
-
La question était en fait, si toutes les leds sont allumées en même temps, cela représente quelle valeur de courant "tiré" sur le MEGA en même temps ?
-
La question était en fait, si toutes les leds sont allumées en même temps, cela représente quelle valeur de courant "tiré" sur le MEGA en même temps ?
Rien : il y a seulement 3 sorties par 595 au niveau TTL. C'est lui (le 595). qui supporte le courant des leds.
(http://www.locoduino.org/IMG/jpg/img52.jpg)
-
Bonjour,
Tout d’abord, merci à tous ceux qui contribuent a enrichir ce site . Il m’a permis quelques réalisations . J’attends un câble USB pour tester la box que je viens de terminer. J’envisage très sérieusement de me lancer dans les satellites autonomes . Dans un premier temps, j’étais un peu rebuté par la haute technicité des discussions sur le forum, mais quand j’ai vu le message de « LocoFred », je me suis dit : pourquoi pas moi ? Je vais donc me lancer !
J’ai cru comprendre que « bobyAndCo » habitait Saint Malo, si c’est bien le cas, aurait-il quelque moment à me consacrer pour que je puisse voir son réseau et me rendre compte de ce qu’il y a à réaliser. Breton et retraité, je suis relativement disponible. Pour l’instant je démarre.
-
Bonjour phenixpopol,
Popol ? Paul peut-être ? ou alors Saint-Pol-de-Léon, c'est en Bretagne aussi ?
Je t'accueille avec plaisir pour te montrer mon réseau et les satellites autonomes.
Je profite de ton message pour rappeler une nouvelle fois que les satellites autonomes sont effectivement des machines complexes à l’intérieur mais c'est pour en rendre la mise en œuvre et l’utilisation très simple. Et c'est bien le cas.
Je pensais que les articles étaient assez clairs sur ce point mais apparemment non. Je vais voir ce que je peux faire.
N’hésite pas à me contacter en MP pour convenir des modalités.
Christophe
-
Bonjour à tous,
Cela faisait un petit moment que je n’avais pas communiqué sur ce fil. La principale raison est que j’ai été très occupé par la question de la détection dont il est question dans un fil spécifique : https://forum.locoduino.org/index.php?topic=1656 (https://forum.locoduino.org/index.php?topic=1656)
Aujourd’hui, avec l’aide de rNe (René), vous arrivons au bout de la mise au point d’une version exploitable (V1.0). Les PCB devraient partir en fabrication sous un ou deux jours et l’intégration à l’ensemble du concept de satellites autonomes sera ainsi réalisée.
De quoi parle t’on ? Je crois qu’il est intéressant de d’expliquer précisément de quoi il s’agit et ce que cela apporte aux satellites autonomes.
La réflexion a débuté sur l’intérêt qu’il y avait dans une gestion automatisée de réseau, à connaître l’état d’occupation d’un canton, non pas seulement par une locomotive ou un train, mais aussi par un wagon qui se serait décroché ou tout simplement par la queue du train qui n’a pas encore quitté le canton alors que la locomotive, elle, est déjà sur le suivant. Pour une "conduite à vue" cela n'est pas très important, mais avec une gestion automatisée, on voit bien que cela pose des problèmes de sécurité et qu’il est intéressant d’y apporter des réponses.
La meilleure technique pour détecter des wagons est, selon moi, de placer une résistance de 10 kΩ (ou 20 kΩ) sur le dernier essieu du dernier wagon. Cela peut aussi être des feux de fin de convoi ou de l’éclairage dans les wagons. Tout ce qui entraine une petite consommation de courant, suffisante cependant pour être détectée.
Nous avons donc travaillé avec rNe (René) sur un montage qui a été proposé à la base par Pyk35 (Cédric) qui nous a tout de suite donné des résultats très satisfaisants. https://forum.locoduino.org/index.php?topic=489.msg9139#msg9139 (https://forum.locoduino.org/index.php?topic=489.msg9139#msg9139)
A cette détection de courants faibles, il me semblait être totalement dans l’esprit des satellites autonomes d’associer une détection locale en cas de court-circuit sur le canton et bien sûr une coupure de l’alimentation DCC du canton. Nous gagnons ainsi en rapidité de détection et de coupure par rapport à une détection centralisées qui continue cependant à exister.
Pour des questions de simplicité et de cohérence, ce dispositif a été placé sur la carte Railcom et nous en avons profité pour mettre les deux cartes (Satellites et Railcom/Détection) au même format pour qu’elles puissent se superposer.
J’ai pu réaliser les premiers tests qui sont totalement satisfaisants donc l’intégration aux satellites autonomes est maintenant effective.
Ce silence n’était donc pas le signe d'un abandon du projet mais justifié par le temps nécessaire pour la mise au point de cette évolution majeure.
Pour toutes questions et suggestions sur cette nouvelle carte, je vous remercie de le faire sur le fil spécifique : https://forum.locoduino.org/index.php?topic=1656 (https://forum.locoduino.org/index.php?topic=1656)
Voici en PJ la carte dans son état quasi finalisé.
-
Bonjour à tous,
René (alias rNé) a réalisé un nouveau dessin de la carte satellite plus compact mais aussi moins chère à fabriquer puisqu'elle tient maintenant dans un format de 100 mm X 100 mm qui chez JLCPCB revient à 3,99€ port compris pour 5 exemplaires soit 80 centimes pièce !
Deux ou trois corrections ou améliorations (sérigraphie...) et le prochaine version sera en production.
Quelques photos pour vous faire patienter :
(https://alkans.fr/locoduino/satellites_autonomes/img/_DSC1132_2.jpg)
(https://alkans.fr/locoduino/satellites_autonomes/img/_DSC1136_2.jpg)
(https://alkans.fr/locoduino/satellites_autonomes/img/_DSC1135_2.jpg)
(https://alkans.fr/locoduino/satellites_autonomes/img/_DSC1141_2.jpg)
(https://alkans.fr/locoduino/satellites_autonomes/img/_DSC1145_2.jpg)