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 - Bug Killer

Pages: [1] 2
1
J'ai modifié les objets pour obtenir un affichage des signaux dans les postes de conduite plus réaliste. Désormais, au lieu d'afficher le signal de sortie de bloc dès que le train entre dedans, il n'est affiché que lorsqu'il entre dans la dernière zone avant la sortie. J'ai mis à jour les fichiers disponibles ici. J'ai inclus les objets de mon projet de réseau avec le code des boucles de retournement et des tables tournantes.

2
Si un train doit toujours tenir en entier dans un canton, il ne peut pas toujours tenir entièrement dans une zone. A l'entrée ou la sortie de ma gare principale, un train peut occuper jusqu'à 6 zones consécutives dont la liste varie en fonction de la direction des appareils de voie. Il peut être à cheval sur une zone de BAL (ralentissement ou arrêt), une zone d'ADV et une zone de service.  Ce n'est cependant pas le plus compliqué à gérer. Ce qui a beaucoup compliqué, c'est ma fixette sur la possibilité de scinder et joindre deux trains dans une zone.

3
SourisD17 est un programme simple qui confie toute la régulation au croquis embarqué dans le Wemos. Le contrôleur à écrire n'utilise pas d'objets, seulement des évènements à traiter dans des fonctions. Il convient bien à un petit réseau avec un seul poste de commande et une ou deux souris sous Android. La mise au point du contrôle et de la régulation est très difficile car tout se passe dans le Wemos.

CentraleD17 et ses satellites sont plus complexes mais, avec le simulateur intégré, la mise au point est facile. Je déplace les trains pas à pas et j'examine ce qui se passe avec les outils de mise au point de l'IDE. L'utilisation des objets dérivés de ceux de Pierre59 permet de traiter chaque cas complexe isolément et, pour les cas simples, sans voies de service, son BAL fonctionne tout seul.

J'envisage d'utiliser un Raspberry Pi 400 avec un écran tactile pour faire tourner au moins un des postes de commande. Pour le fun.

4
CentraleD17 est beaucoup plus complexe que SourisD17, la première version de mon projet. Mon cahier des charges était :

- toutes les communications en TCP/IP.
- échanges avec la centrale à base de Wemos D1 mini réduits au strict minimum.
- plusieurs stations gèrent le réseau en simultané.
- les stations affichent des informations synchronisées.

Les stations ne se connectent donc pas au Wemos mais à CentraleD17 qui gère les flux de données entre la centrale, le système de contrôle-régulation et les clients. Il y a 6 modules :

1. Le client interface avec D17 (ClientD17). Protocole à modifier pour s'adapter à une autre centrale.
2. Le serveur de flux ServeurD17. Protocole à modifier pour s'adapter à une autre centrale.
3. Le contrôleur-régulateur
4. Le client interface avec ServeurD17.
5. Le gestionnaire de TCO
6. Le(s) gestionnaire(s) d'interface de conduite. Actuellement 14 "souris". En préparation 4 "cabines".

Tous ces modules sont dans CentraleD17 ainsi que la gestion de la base de données d'état du réseau. CommandeD17 comprend 4, 5 et 6. ConduiteD17 4 et 6. CommandeD17 et ConduiteD17 n'agissent donc pas directement sur la centrale mais envoient des requêtes à CentraleD17. Son module de contrôle-régulation vérifie si elles sont exécutables. Lorsqu'elles le sont, il envoie des requêtes au Wemos et le résultat aux stations concernées.

Exemple : sur un ordinateur exécutant CommandeD17 l'utilisateur clique sur le bouton de construction d'un itinéraire. Localement, CommandeD17 n'a aucune idée de la faisabilité de la construction. Cette requête est envoyée à CentraleD17 qui vérifie si elle est exécutable. Si elle l'est, les appareils de voie et les signaux sont manœuvrés par une requête envoyée au Wemos et les blocs concernés sont marqués. Le changement d'état des ADV et l'état "construit" est envoyé aux stations exécutant le module 5. Le changement d'état des signaux est envoyé aux ordinateurs qui exécutent les modules 5 et 6. Si la requête n'est pas exécutable immédiatement, l'itinéraire est "en attente de construction". Cet état est envoyé aux stations exécutant le module 5.

La centrale ne retourne que très peu d'informations :

- état de l'arrêt d'urgence car un bouton matériel est présent sur son boîtier
- niveau de consommation de courant
- état des détecteurs, 96 bits, nombre ajustable
- état des ADV, 48 bits, nombre ajustable, une fois pour ceux à gauche, une fois pour ceux à droite
- état des variables utilisateur, 96 bits, nombre ajustable
- résultat de la lecture d'un CV
- résultat de l'écriture d'un CV
- résultat de la comparaison d'un CV

ServeurD17 interroge l'état du Wemos à chaque fois qu'il envoie un paquet de requêtes ou au bout de 125ms sans requête.

Actuellement, il n'y a pas de gestion centralisée des fichiers contenant les profils des engins moteurs et la description des TCO. Ces fichiers texte doivent être présent à l'identique sur tous les ordinateurs.

5
J'ai extrait du code les fichiers les plus impliqués dans la gestion de la circulation. Ils sont dispos ici.

6
Eclipse aussi est disponible pour macOS https://www.eclipse.org/downloads/packages/

Installer et exécuter Eclipse Installer puis installer Eclipse CDT.

7
Comme le projet est développé avec wxWidgets, normalement ça fonctionne aussi mais je n'ai pas testé car je n'ai pas de machine sous macOS. Plus de renseignements ici : https://www.wxwidgets.org/docs/faq/osx/

8
Le projet est entièrement en C/C++. Le passage à Windows avec VS2019 est en cours.

9
Je peux actuellement publier le projet pour Eclipse et Code::Blocks sous Linux. Il vous faudra fabriquer et installer wxWIdgets-3.1.4 et wxSQLite3 4.6.9. ça vous va ?

10
En fait, j'avais déjà un programme qui fonctionnait sur un petit réseau mais très difficile à appliquer à un gros. J'ai combiné ta méthode basée sur les objets avec mes propres développements : cantons multi-zones, présence simultanée de 2 trains par zone (si, si, ça marche avec un algorithme trapu de suivi des trains). Je n'ai pas réussi du premier coup et j'ai failli abandonner. Je suis donc reparti de presque zéro en implémentant les objets un par un tout en les adaptant à mes objectifs. Je publierai le code dès que je le trouverai suffisamment stable.

11
Après avoir cuisiné le modèle de Pierre59 à ma sauce, j'ai pu modéliser entièrement mon futur réseau qui, après évolution, comprend 62 blocs, 86 zones de détection, 37 appareils de voie, 2 boucles de retournement, 2 plaques tournantes, 86 itinéraires, permanents ou à destruction automatique, et 61 signaux dont 27 virtuels qui ne servent qu'à la régulation. Le mode simulation de mon logiciel m'a permis de vérifier le bon fonctionnement. Tout marche, le BAL, le BMVU, l'accès aux zones de service avec affichage du feu de manœuvre, le retournement d'une loco sur une plaque, etc.

Merci encore à Pierre pour ses travaux car je n'aurais pas eu l'idée par moi-même d'utiliser un objet dérivé par élément.




12
Le plan complet est annexé au premier message du fil. Depuis ma question j'ai vu dans le code où se trouve les rejets de pointeurs nuls quand il n'y a pas de signal suivant ou précédent.

13
Je vais juste citer la réponse que j'ai eu d'un cheminot ayant travaillé dans la filière Transport-Mouvement de la SNCF :

"Ce qui importe est la position de l'aiguille. Sur la photo ci-dessus, l'aiguillage comporte une voie directe à gauche, une déviée à droite.
La direction que donne l'aiguille est TOUJOURS déterminée en partant de la pointe, ce qui est très logique. On dit que l'aiguille est "à gauche", lorsqu'elle donne la direction de gauche, "à droite" lorsqu'elle donne la direction de droite, bien sûr.
Ceci résout, en particulier, le cas des aiguillages symétriques aux branches courbes, du même rayon ou pas.

La notion d'aiguille "à gauche" ou "à droite" est utilisée réglementairement dans toutes les fonctions concernées. Elle va être essentielle pour toute commande d'aiguille, par levier ou motorisée, et pour tout montage de parcours, enclenchements, position des signaux, ..., bref la commande binaire du oui -non, ou (+) - (-)."

14
Encore une question. Soit la configuration de voie suivante :

S1                     S2
-------------------------
          \
           \----------------- Z3

La fonction precedent() de l'objet S2 doit-elle renvoyer S1 ou nullptr quand l'aiguille mène à droite vers Z3 ?

15
2 questions :

Que doit retourner la méthode CantonOccupe lorsque la prochaine zone ne fait pas partie d'un canton de BAL mais est une voie de service ou une voie de manoeuvre ?

Lorsque la position d'une aiguille prise en talon ne permet pas d'accéder au prochain canton, faut-il quand même renvoyer son état, forcer à true ou forcer à false ou est-ce sans importance ?

Un commentaire :

Ayant un souci de compréhension de ce que représente "directe" et "déviée" dans le cas d'un TJD, d'une TJS ou d'un aiguille symétrique, j'ai posé la question sur un autre forum et j'ai appris que ce n'est pas ainsi qu'on indique la direction à la SNCF. On y utilise "gauche" et "droite", ce qui est sans ambigüité. Je me suis permis de modifier les noms des méthodes en conséquence.

Pages: [1] 2