Projet d'utilisation du gestionnaire en C++ de Pierre59

[Dominique]

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.

Je ne suis pas certain que "gauche" et "droite" soit moins ambiguë que "droite" et déviée" pour une aiguille car "tout droit" peut-être  sans ralentissement et "déviée" peut-être à gauche ou à droite mais avec ralentissement : dans ce cas spécifique, la programmation du comportementd'un train n'est pas simple en testant l'état de l'aiguille !!

Mais pour une TJS ou TJD c'est plus concevable peut-être.

[Bug Killer]

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 (+) - (-)."

[Pierre59]

Bonjour

Le gestionnaire de l'article est une version simplifiée qui ne prend pas en compte les voies de service ni les manoeuvres (pas de gestion du feu manoeuvre (blanc) dans les signaux).

Normalement pour passer à une voie de service il doit y avoir un carré (sans BAL) pouvant présenter le feu de manoeuvre (blanc).

La méthode cantonOccupe() a un résultat booléen, elle ne sert que quand on ouvre un signal de BAL pour savoir s'il faut le mettre au sémaphore ou pas.

Dans l'état actuel si suivant() ou precedent() retournent null c'est une erreur d'exécutuion. C'est une précaution pour éviter les oublis, mais cela peut être changé.

J'ai beaucoup de mal à répondre aux questions, sans savoir quel est le type du signal concerné (et les feux) ainsi que son insertion dans le réseau.

Cela serait bien d'avoir un "dessin" complet du réseau (avec les signaux (avec feux si possible) et des repères : noms de zones, d'aiguilles, signaux, …), cela permettrai d'avoir des réponses beaucoup plus pertinentes aux questions.

Cordialement

Pierre

[Bug Killer]

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.

[Bug Killer]

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.

[Pierre59]

Bonjour

Très très belle réalisation, on aimerais en savoir un peu plus.

Pierre59

[Bug Killer]

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.

[Dominique]

Bonjour,

J'ai hâte aussi d'en savoir plus notamment sur le suivi des trains.

J'utilise aussi les objets de Pierre59, prêt aussi à partager.

Bon courage
Dominique

[Bug Killer]

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 ?

[Dominique]

Une version C/C++ est-elle envisagée ?

[Bug Killer]

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

[Dominique]

Je suis sur Mac !

[Bug Killer]

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/

[Bug Killer]

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

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

[Dominique]

Okay, je ne cherche pas à compiler et exécuter ton développement mais seulement comprendre comment fonctionne le suivi et l’espacement des trains.

Je peux essayer de lire et comprendre les fichiers sources sur Mac, même sans installer Éclipse et wxWidget, surtout s’ils sont commentés.

Car on n’a pas exactement le même réseau et les même capteurs.

Merci d’avance
Dominique