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

[Bug Killer]

J'ai mis en pièce jointe le réseau que je vais construire.

Pour les quelques tests que j'ai effectués sur un ovale avec une voie de garage, j'ai utilisé la centrale économique D17, un BAL embarqué dans la centrale et SourisD17, la partie commande dans un PC sous Windows, Linux ou OS-X (détails ici). Pour le réseau grand modèle, je ne vais conserver dans le croquis de la centrale que les interfaces matérielles et, bien sûr, la génération du signal DCC. Toute la partie gestion va passer sur le(s) PC. Pour cette partie, j'envisage d'utiliser le gestionnaire en C++ de Pierre59. 

J'ai déjà vu qu'il faut que je crée un autre type de signal abondamment utilisé dans le projet (carré - BAL + blanc clignotant) et que je dois voir comment inverser le sens logique de marche des trains quand ils passent de la zone 5 à la 6, de la 39 à la 40 et vice-versa.

A suivre, si vous le voulez bien.

[Dominique]

Bienvenue Sur Locoduino,


C'est un grand projet donc beaucoup de techniques à déployer et faire fonctionner ensemble : ça va être interessant 

Bien amicalement
Dominique

[Pierre59]

Bonjour

Très très joli réseau. Je me permet de faire quelques remarques.

En général on ne met pas de signaux dans les dépots, les zones marchandises, les grils …
On est pas obligé de mettre des signaux partout, des petites gares peuvent être, comme en réalité, sans signalisation.
Les signaux avec blanc clignotant sont assez rares en réalité, assez courants avec le blanc fixe.

Le problème des "sens" est souvent assez délicat à gérer. Sur le réseau on a deux plaques tournantes et un retournement si je ne m'abuse. Cela nécessite des "changements" de sens pour les trains.
En général on donne un sens aux voies, pair ou impair habituellement, surtout en double voie. Certaines voie peuvent être parcourues dans les deux sens : zones d'aiguillages, voies uniques, voies des dépots, … Pour ces voies on peut donner un sens arbitraire, en cohérence avec les voies avoisinantes.
Le problème vient avec les trains, en voie double le train a le sens de la voie, ailleurs il peut changer.   
Un train qui fait un retournement à Calais ou à Paris arrive avec un sens pair ou impair, mais repart avec un sens inversé (impair ou pair), mais le sens DCC ne change pas (cela doit être aussi vrai pour les plaques tournantes), pour un train on a donc besoin de deux sens : le sens réseau (pair/impair) et le sens DCC (avant/arrière). Une paire de booléens permet de gérer cela. On n'a besoin de mettre jour à ces booléens que dans deux cas : quand on inverse se sens de circulation du train par une commande sur la souris, quand on a un retournement de voie, une raquette ou un retournement sur un pont tournant. Le passage Z5/Z6 (et les autres) se fait alors tout seul, sans rien faire.

Cordialement

Pierre

Calais ou Paris

[Bug Killer]

Je vais essayer d'ajouter à ton gestionnaire quelques fonctions originales du mien :

- scission d'un train
- jonction de 2 trains
- régulation automatique de la vitesse en fonction d'un paramètre de chaque zone
- franchissement de signal fermé en "marche à vue" à une vitesse maxi de 15 km/h

Les deux 1ères fonctions nécessitent de pouvoir avoir 2 trains dans la même zone, repérés par le côté de la zone qu'ils occupent.
 
Les signaux qui n'ont pas de cible sur le plan ne sont là que pour la sécurité des manoeuvres, en cas de fausse manip ou d'oubli d'activation de marche à vue. Certains pourraient être supprimés si je testais l'occupation de la zone au lieu de l'état du signal qui en découle mais, dans mon gestionnaire actuel, les autorisations d'accès à la zone suivante et le ralentissement des trains sont basés sur la signalisation logique qui découle de l'occupation des zones et de la position des aiguilles. Les autorisations ne sont recalculées que s'il y a eu des changements. La régulation de marche des trains qui intervient toutes les 125ms n'a ainsi besoin de prendre en considération que :

- l'état du signal suivant
- la vitesse maxi autorisée sur la zone
- la vitesse et le sens indiqués par le poste de conduite.

Comme je vais migrer tous ces algorithmes dans le logiciel sur PC, le traitement sera plus rapide et je pourrais peut-être refaire les calculs d'autorisation à chaque itération.

Ce n'est pas très visible mais sur le plan le sens pair est indiqué par les flèches superposées aux sections de rail et aux aiguilles. Il n'y a pas de boucle de retournement (c'est un double ovale replié en os de chien et une voie unique) mais en plus des plaques tournantes, il y a deux endroits, entre la zone 5 et la zone 6, ainsi qu'entre les zones 39 et 40, où le sens de marche réseau doit être inversé. C'est dû à la 4ème voie à quai et à la voie de service qui peuvent être parcourues dans les deux sens et cisaillent la voie 3. J'ai mis un zoom sur ces zones en pièce jointe.

[Bug Killer]

La remarque de Pierre sur la boucle de retournement m'a titillé. Je pensais qu'il n'y en avait pas, or, il y en a deux. Je vais donc considérer que toutes les voies de la gare d'Abbeville sont dans le sens pair depuis Paris (à gauche) vers Calais (à droite). Les sections de changement de polarisation et de sens de circulation seront les Z42 et Z43 côté Calais, Z58 et Z59 côté Paris.

Merci Pierre.

[Pierre59]

Bonjour

Ce serait peut être plus simple de mettre toutes les voies d'Abbeville dans le même sens et de faire l'inversion de polarité dans les deux retournements Paris et Calais.

Cordialement

Pierre

[Bug Killer]

Ben c'est ce que j'ai dit.

[Pierre59]

Désolé j'ai lu trop vite

Pierre

[Bug Killer]

Dans les méthodes suivant() et precedent() de la classe Signal, est-il utile de renvoyer le pointeur du signal suivant ou précédent si celui-ci est un carré sans BAL ?

[Pierre59]

Quand on ouvre un carré même sans bal il faut l'état du signal suivant pour savoir si on l'ouvre à Vl ou A.
Quand on change les feux d'un carré il faut prévenir le précédent pour qu'il mette à jour ses feux.

Cela se complique un peu si le signal peut présenter le R ou le RR. De plus les suivants et précédents dépendent de la position des aiguilles.

Pierre

[Thierry]

Il y a aussi une règle en développement : l'absence de retour d'une fonction est inutile, alors que retourner une information, même très faiblement utile, a une chance de servir à quelque chose... Par exemple, une fonction fait généralement quelque chose (sinon c'est la fonction elle même qui est inutile !), on peut juste retourner un booléen qui signalera si la chose a été faite, ou si l'on s'est trouvé dans un cas qui empêchait de faire le travail, ou l'ancieene valeur d'un objet mis à jour par la fonction, etc...

[Bug Killer]

@Pierre59 : pigé !

@Thierry : ici il s'agissait de savoir s'il était utile de créer des méthodes renvoyant un résultat non nul mais inutilisé (ce qui n'est pas un cas normal) dans un objet dérivé alors qu'il existe une méthode par défaut renvoyant un pointeur nul dans la classe de base.

Ce sont mes enchaînements de carrés violets logiques (sans signal physique) qui m'ont fait me poser cette question. A priori, l'état de ces Cv ne dépend pas des signaux voisins, uniquement de l'orientation des aiguilles, mais ça ne m'a pas coûté cher en temps d'écrire leurs méthodes.

[Pierre59]

Dans le cas des Cv les méthodes précèdent et suivant ne servent pas.

Pierre

[Bug Killer]

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.

[Bug Killer]

Encore une question. Soit la configuration de voie suivante :

Code: [Sélectionner]

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

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