Auteur Sujet: Projet partagé d'un gestionnaire de réseau  (Lu 169337 fois)

DDEFF

  • Hero Member
  • *****
  • Messages: 760
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #465 le: juillet 23, 2024, 07:47:51 am »
@ Pierre,

Dans ton post #411 du 05/05/24, tu soulèves l'intéressant problème du garage franc.

J'avoue qu'à la SNCF, je ne sais pas comment c'est géré électriquement.
La seule chose visible, c'est une marque blanche au sol (une traverse peinte en blanc, un bloc béton peint en blanc, …). Avec du personnel sur le terrain, c'est jouable. On voit si on dépasse ou pas.
Mais nos petits trains n'ont pas de personnel au sol…

Je propose donc de faire la coupure plus loin, suivant le schéma  :



Les véhicules dessinés sont à bogie car c'est ceux-là qui "dépassent" le plus.
J'entends par "dépassement" la distance entre le bogie côté tampon et le bout du tampon. En gros, 3 cm, à vue de nez.
Donc, on ne fait pas la coupure à l'extrémité de l'aiguille, mais 3 cm plus loin.

Ainsi, si le véhicule avance un peu, il se trouve électriquement sur la zone de l'aiguille et empêche la création d'un itinéraire sur l'autre voie ou empêchant la destruction de l'itinéraire si on ne va pas assez loin sur la zone hors aiguille.

Jusque-là, c'était évident.

Mais on ne peut pas raisonner ainsi si plusieurs aiguilles se suivent.
La dernière zone d'un itinéraire est à la fois occupée électriquement et occupée par l'itinéraire.
Lorsque le train avance, elle devient à la fois inoccupée électriquement et disparait de la liste des zones de l'itinéraire.

Ce que je propose, c'est d'agir en 2 temps :

La zone devient inoccupée électriquement, tout en restant occupée par l'itinéraire.
Elle ne quittera la liste des zones de l'itinéraire que quand on aura 2 zones d'appareils de voie consécutives inoccupées électriquement.
On a ainsi un décalage d'une aiguille entre l'occupation électrique et l'occupation par un itinéraire. Comme l'occupation par un itinéraire bloque la création d'un autre itinéraire utilisant cette aiguille, on a bien une distance supérieure à 3 cm tout le temps, même si on perd un wagon.

Denis :P
« Modifié: juillet 23, 2024, 07:50:50 am par DDEFF »
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 346
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #466 le: septembre 19, 2024, 10:44:52 am »
Voici une nouvelle version du gestionnaire expérimental json en C/C++. Beaucoup de bugs ont étés éliminés, mais il en reste encore. Comme la précédente version, cette version est prévue pour tourner sur un ORDINATEUR, elle fonctionne comme la version en Processing (Java) en utilisant un TCO en Processing pour faire les tests.

La version Processing et cette version C/C++ sont quasiment équivalentes, mais il y a quelques différences entre la version Processing et la version C/C++ (dans le but de préparer la version tournant sur Arduino), voici les changements de la version C/C++ :

- le transit souple n'est pas encore mis en oeuvre (il faut juste traduire le code de Java vers C/C++ et tester)

- des "bus" ont étés introduits, le gestionnaire communique avec le réseau, le TCO, les manettes, la centrale (box), … par un ou plusieurs "bus", ces bus peuvent êtres très variés : ethernet, wifi, I2C, USB/série, CAN, … . Pour l'instant les messages comportent tous trois octets et ne sont pas répétés (on peut envisager des codes de détection d'erreurs comme un CRC, voire un numéro de message).

Pour passer à une version Arduino il va falloir faire quelques adaptations :

- la bibliothèque json utilisée existe sur Arduino (c'est pour cela quelle a été choisie) on pourra supprimer l'onglet et utiliser un "include" à la place (le changement de bibliothèque a représenté le plus gros du travail pour passer de Processing à C/C++)

- remplacer les structures de données, genre "vector", par des versions adaptée à l'Arduino et faire attention à la gestion mémoire

- choisir le ou les bus et les implémenter

- régler les problèmes d'initialisation du gestionnaire comme il a été discuté dans le post n° #461 et les suivants de ce fil

- prévoir un moyen de dialogue avec le gestionnaire pour l'affichage de ses messages et l'obtention des informations sur les trains, voir aussi le post n° #461 à ce sujet

- choisir où mettre le "fichier" json, sur carte SD ou en mémoire RAM ou FLASH (PROGMEM)


Les fichiers joints sont tout à fait fonctionnels, mais assez difficiles à mettre en oeuvre, c'est juste une version avant de passer à l'Arduino.

Pierre