Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - bobyAndCo

Pages: 1 ... 15 16 [17] 18 19 ... 59
241
Implantation des satellites autonomes sur le réseau :

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

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



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

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

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

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

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



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

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

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

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

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

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



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

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

Christophe

242
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.

243
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: janvier 10, 2024, 02:07:16 pm »
Bon est-il possible de considérer que la version fournie par Denis ci-dessus est définitive ??? Si oui, est-il possible de l'avoir sur fond blanc, c'est plus pratique pour ajouter des infos (graphiques, textes...).

On est bien d'accord que maintenant ce sont des aiguilles entre A, 1, et 2 ???

Cela fait donc 6 aiguilles (bien qu'il n'y ait pas de A6. Je ne me trompe pas ?

244
Bonjour à tous,

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

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


Principes généraux :

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

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

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

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

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

Les objectifs :

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

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

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

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

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

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

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

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

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

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

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


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

Christophe

245
Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.

Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.

@Christophe,

Le mieux serait que tu proposes sur mon plan initial, les zones, signaux, les noms et les circulations que tu envisageraient pour servir de base à tes satellites autonomes.
Je joins le dessin sur lequel tu vas ajouter ces éléments.

Il faut bien que nous partions d'une même référence pour que la discussion soit constructive.

Nono, non, donne le même cahier des charges à tout le monde et quand vous serez d'accord vous me faites signe.

246
Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel  de ralentissement au besoin !
Si tu as le contrôle manuel des aiguillages tu peux bloquer un train au dernier moment avec un feu qui passe du vert au carré devant son nez. Ce n'est pas sensé arriver.

Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.

Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.

247
Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?
Non il y a des erreurs et des manques.

Pierre

C'est un peu con, car j'avais commencé à bosser ! Et pourquoi y aurait-il des erreurs et des manques, ne peut-on pas choisir ce que l'on veut ? Mais pourquoi ne pas choisir Méru après tout, moi plus c'est complexe plus ça me va. Et oui d'abord, pourquoi pas Méru ???

248
Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau
« le: janvier 09, 2024, 09:36:52 am »
J'avais réalisé un gestionnaire dans TrainZ que j'ai du abandonner car Auran refusait un patch de leur moteur de jeu sans lequel ça ne pouvait pas marcher.

Sans itinéraire le gestionaire ne sait pas où va un train et ne peut donc pas commander les aiguilles.
Si Christophe bouge les aiguilles lui-même c'est que c'est lui le gestionnaire du réseau. Il sait où vont ses trains (donc il connait les itinéraires) et il prend des décisions connaissant ces itinéraires. Et la signalisation est ajustée à ses désirs sans tenir compte de la règle d'or de l'avertissement avant un arrêt.
Et ça peut fonctionner parceque nos trains ont des distances d'arrêt très courtes comparées aux trains réels et n'ont donc pas toujours besoin d'un avertissement.

Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel  de ralentissement au besoin !

249
Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.

Un billet n’est-il pas un itinéraire à une heure donnée et à un prix donné ?

N’inversons pas les choses, j’ai dit que la signalisation et la sécurité totale du réseau était possible sans aucune notion d’itinéraire mais je n’ai pas dit que la gestion d’itinéraire n’était pas possible avec les satellites autonomes.


250
Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau
« le: janvier 09, 2024, 08:17:25 am »
Bonjour Christophe,

La notion d'itinéraire est INDISPENSABLE. Regarde la gare pourtant assez simple de MERU : c'est même un PRS (Poste tout Relais à transit Souple), le top des itinéraires
D'autre part, le Carré est fondamentalement différent des autres signaux car il peut être commandé manuellement, indépendamment des positions des trains et des aiguilles.
C'est l'Aiguilleur, un métier complexe qui décide (ou non) de lancer un train en fonction de tout un tas de critères.
C'est Etienne66 qui a raison.

Denis

Messieurs, répondez au cahier des charges proposé par Dominique et l'on verra qui a raison !

Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.

Christophe

251
Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau
« le: janvier 09, 2024, 07:50:51 am »
Voilà ma proposition pour les coupures de zones, les zones, les aiguilles et les signaux.

Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?



Et comme tu n'as pas remis les références des appareils, est-on bien d'accord que AIG1 et AIG2 sont bien ce que tu as présenté précédement :



Serait-il possible d'avoir la représentation du réseau dans son ensemble et en haute definition ?

Merci par avance.

Christophe

252
Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau
« le: janvier 09, 2024, 07:29:27 am »
Bonjour,
J'ai lu vos échanges sur les cantons, zones, N+1, N-2, etc... et vous essayez d'inventer le bogie avant d'avoir inventé la roue.

Il y a deux choses distinctes dans la sécurité des trains : le cantonnement et l'interconnexion (interlocking en anglais)
Et il y a un grand principe : un conducteur ne doit jamais se voir présenter un feu rouge avant d'avoir passé un avertissement.

Pour les signaux de cantonnement pas de souci : on regarde l'occupation de n+1 et le feu n+1 et ça peut se faire localement sans
passer par la centrale.
Mais pour les carrés c'est totalement différent et ça ne peut se faire que par une gestion d'itinéraire.
Un carré ne doit passer au vert (ou jaune) que si un train a demandé le passage vers une destination, que son trajet ne rentre
pas en conflit avec celui d'un autre train et que les aiguilles ont été positionnées pour ce trajet. Et il faut souvent pouvoir gèrer
le feu en avance, alors que le train n'a pas encore passé le signal précédent.
Pourquoi ne pas mettre un carré au vert en l'absence de train si les aiguillages offrent un trajet libre? Parce que si un train arrive
et qu'un autre train demande le passage le feu va passer au rouge devant son nez.
Donc il faut une gestion d'itinéraire qui va gérer des réservations au moins à deux cantons devant un train.
La définition de cantons ne suffit pas pour la gestion des carrés. Il faut définir des trajets constitués de plusieurs cantons,
avec des sens de circulation pour chaque canton avec la possibilité de réserver un trajet pour plusieurs trains si ils vont dans le même sens.
Il faut aussi définir les trajets incompatibles entre eux. Par exemple les trajets utilisant un groupe d'aiguillages ou deux trajets
avec un croisement.
La boucle de retournement pose également un problème particulier (le train en N est aussi en N+2 mais dans l'autre sens!)

La gestion du carré violet impose également le système d'itinéraire car il faut savoir si le train est en manoeuvre ou pas et
ça ne peut pas se faire automatiquement.

Enfin il y a les conflits à longue distance. Par exemple il ne faut peut-être pas engager un train sur une voie unique si il n'y a pas
de voie libre dans la gare suivante.


Bonjour Etienne66

Je suis désolé de te contredire, mais ce que tu affirmes est faux, tout au moins sur nos petits réseaux miniatures. J’ai démontré le contraire avec les satellites autonomes.

Rapidement, je rappelle le concept. Sur chaque canton est disposé un satellite et chaque satellite dispose d’un gestionnaire qui est rigoureusement identique sur chaque satellite. Il n’y a donc aucune gestion centralisée du réseau. C’est ce que Pierre a qualifié de gestion répartie.

Chaque satellite autonome connait ses liaisons avec ses voisins (rien de nouveau), et comme il connait ses voisins, il connait aussi les voisins de ses voisins.

Aussi, le satellite à C0 connait l’état des aiguilles de C+1 et aussi l’état d’occupation de C+1.

Il en est de même pour C+2 et ainsi C0 connait l’état d’occupation C+2 et l'état de ses aiguilles et peut alors afficher un ralentissement ou toute signalisation adéquate comme C+1 sait aussi afficher la bonne signalisation.

On voit donc qu’il n’y a aucune notion d’itinéraire, je ne l’utilise d’ailleurs pas sur mon réseau, tout est simplement déterminé en fonction de l’état du réseau à un instant t, état connu par chacun des satellites qui reçoit des autres ces informations toutes les 100 ms au travers du bus CAN et qui adapte son comportement en fonction des informations reçues.

Vitesse et direction des trains sont aussi des informations connues des satellites.

Je précise cependant que la détection est faite avec Railcom, ce qui permet aussi aux satellites de connaitre en temps réel chaque train, sa position, sa vitesse et sa direction et chaque satellite si nécessaire, sait envoyer une commande à la centrale pour ralentir ou encore arrêter un train.

A ta disposition pour discuter de cela au besoin.

Christophe

253
Bus CAN / Re : Question mise en place CAN dans la centrale DCC
« le: janvier 08, 2024, 09:06:17 pm »
N'hésite surtout pas à revenir vers moi pour plus d'explications comme par exemple la mise en œuvre concrète. Par ailleurs pour la gestion du petit réseau que tu envisages, je t'invite à suivre ce que je publie sur les satellites autonomes sur le forum et sans doute bientôt sous forme d'articles.

Bon courage

Christophe

254
Bus CAN / Re : Question mise en place CAN dans la centrale DCC
« le: janvier 08, 2024, 08:47:33 am »
Bonjour becbunsen,

Tu abordes plusieurs sujets en un.

Tout d’abord dans le titre du sujet où tu parles de mettre en place CAN dans la centrale DCC. Bon, plus exactement, je pense que tu veux dire, « comment piloter ma centrale DCC en utilisant un bus CAN ».

Tout dépend bien sur de ta centrale, mais si par exemple tu utilises LaBox de Locoduino, nous avons, mes camarades Dominique, Michel et moi-même développé et testé des commandes CAN qui permettent de piloter LaBox.

Tu trouveras sur ce lien le programme complet de LaBox auquel j’ai ajouté les fichiers « CanMsg .h» et « CanMsg.cpp »

https://github.com/BOBILLEChristophe/CommandStation-EX-LaBox2/blob/main/CanMsg.cpp

Dans le fichier « config.LaBox.h », nous avons ajouté ligne 181 #define CAN en plus des paramètres spécifiques à LaBox

#define USE_HMI
#define HMI_SHOW_CURRENT
#define CAN

Enfin, le fichier « CommandStation-EX-LaBox2.ino » pour inclure le CAN.

Dans le fichier CanMsg.cpp tu vas trouver un certain nombre de commande qui permettent de piloter les locomotives en CAN (à partir de la ligne 113) :

uint16_t loco = 0;
      if (cmde < 0xFA)
        loco = (frameIn.data[0] << 8) + frameIn.data[1];

      switch (cmde) // Fonction appelée
      {
      case 0xF0:
        DCC::setThrottle(loco, frameIn.data[2], frameIn.data[3]);
        xQueueSendToBack(xQueue, &frameIn, 0);
        break;
      case 0xF1:
        DCC::setFn(loco, frameIn.data[2], frameIn.data[3]); // frame.data[2] = fonction, frame.data[3] : 'on' ou 'off'
        break;
      case 0xF7:
        // WRITE CV on MAIN <w CAB CV VALUE>
        DCC::writeCVByteMain(loco, frameIn.data[2], frameIn.data[3]);
        break;
      case 0xFE:
        TrackManager::setMainPower(frameIn.data[0] ? POWERMODE::ON : POWERMODE::OFF);
        xQueueSendToBack(xQueue, &frameIn, 0);
        break;
      case 0xFF:
        DCC::setThrottle(0, 1, 1); // emergency stop
        xQueueSendToBack(xQueue, &frameIn, 0);
        break;


Comme tu le vois, nous trouvons les commandes de traction, les commandes de fonction (jusqu’à 28 fonctions), la mise sous tension du réseau, l’emmergency stop et même la possibilité de modifier les CV qui sont modifiables sur la POM comme le son.


Sur cet autre lien, tu trouveras maintenant un programme conçu pour. Tester toutes ces commandes CAN : https://github.com/BOBILLEChristophe/Test_CommCan_LaBox_2

Ce programme doit être installé sur n'importe quel Arduino relié au bus CAN avec la centrale, il tourne en automatique pour voir s'executer une à une les principales commandes à destination de la centrale.

Voilà déjà pour commander une centrale DCC avec des commandes CAN.

Pour le pilotage en automatique de ce type de réseau, je t’en reparle dans la journée.

255
Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau
« le: janvier 07, 2024, 09:04:07 pm »
Un tracé dans ce genre là (en mieux) ?

Ok pour l'exercice mais il faudrait tout de même définir les zones de cantonnement. Je suppose que les deux rails 6001 après les aiguilles 6080 et 6081 et avant le TJS SL80 ne suffisent pas pour cantonner un train.

Pages: 1 ... 15 16 [17] 18 19 ... 59