LOCODUINO

Discussions Générales => Les réseaux => Discussion démarrée par: Bug Killer le octobre 30, 2020, 12:33:35 pm

Titre: Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le octobre 30, 2020, 12:33:35 pm
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 (http://jmdubois.free.fr/dcc/index.html)). 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 (https://www.locoduino.org/spip.php?article154). 

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.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Dominique le octobre 30, 2020, 12:42:48 pm
Bienvenue Sur Locoduino,


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

Bien amicalement
Dominique
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Pierre59 le octobre 30, 2020, 03:17:40 pm
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
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le octobre 30, 2020, 03:45:54 pm
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.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le octobre 31, 2020, 09:27:56 am
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.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Pierre59 le octobre 31, 2020, 10:08:03 am
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
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le octobre 31, 2020, 10:18:40 am
Ben c'est ce que j'ai dit.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Pierre59 le octobre 31, 2020, 10:31:10 am
Désolé j'ai lu trop vite

Pierre
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le octobre 31, 2020, 12:01:47 pm
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 ?
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Pierre59 le octobre 31, 2020, 01:02:49 pm
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
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Thierry le octobre 31, 2020, 01:15:36 pm
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...
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le octobre 31, 2020, 03:20:00 pm
@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.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Pierre59 le octobre 31, 2020, 03:48:42 pm
Dans le cas des Cv les méthodes précèdent et suivant ne servent pas.

Pierre
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le novembre 02, 2020, 05:20:43 pm
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.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le novembre 02, 2020, 06:56:07 pm
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 ?
Titre: Re : Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Dominique le novembre 02, 2020, 09:15:11 pm
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.
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le novembre 03, 2020, 09:26:27 am
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 (+) - (-)."
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Pierre59 le novembre 04, 2020, 10:28:07 am
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
Titre: Re : Projet d'utilisation du gestionnaire en C++ de Pierre59
Posté par: Bug Killer le novembre 04, 2020, 09:16:12 pm
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.