Faire le bon choix ?

Bonjour à tous,

Je rejoins presque ce qu'a dit Pascal, à une petite différence près, on pourra couper le courant même s'il y a un train déjà présent dans le canton où notre train ira s'il y a une erreur d'aiguillage.

En l'absence de rétrosignalisation des aiguilles, on ne pourra stopper le train que lorsque l'erreur d'aiguillage aura été constatée, on ne le stoppera pas dans le canton précédent.

On réalise la chose avec deux flagmen (signaleurs). Voici comment j'ai fait:

1) On créé un premier signaleur baptisé "Minuterie" avec le paramétrage suivant:
1.1) signaleur déclenché si: le canton avant l'aiguille est canton courant d'un train ET que le trajet vers le bon canton est actif ET que le bon canton est réservé pour un train circulant dans le bon sens.



En soi, ce sont les conditions qui se réalisent lors de l'exécution d'un trajet

1.2) Mémoire du signaleur: on laisse le signaleur actif pendant 10 secondes (temps à adapter en fonction du réseau bien sûr). On force la réinitialisation du signaleur au bout des 10 secondes.



2) On créé un deuxième signaleur baptisé "Arret"

2.1) Déclenchement: quand le signaleur "Minuterie se désactive" Et que le mauvais canton est occupé



2.2) Condition: le bon canton est réservé dans le bon sens ET il n'est pas occupé



2.3) Opération: on coupe le courant



2.4) Mémoire: réinitialisation du signaleur identique à l'autre.

Je vous ai mis le fichier exemple en téléchargement

http://jean.home.cern.ch/jean/Download/Test_flag.yrr. En version V5.8.E2.

On doit pouvoir améliorer grandement la chose ... je vous laisse vous pencher sur le problème.

Jean

Bonjour à tous

Je rejoins la description de jean, sauf que je ne suis pas fan de la notion temps, car comment l'ajusté en fonction des profils locos. les bug sont fréquents cr XX secondes peuvent être trop peut pour certains convois marchandises réputés plus lent et trop pour un TGV ICE ou train grande ligne. C'est en tout les cas l'idée que je m'en suis fait lors de test.

L'idée directrice de jean et toutefois celle que j'utilise. Une question à Jean quand vous dites couper le courant ceci arrête l'exploitation du réseau ou juste le train qui s'est trompé d'itinéraire,

Merci pour votre réponse.

Bon train
Pascal

Au début de ce fil j'étais absent ce qui fait que j'ai suivi la discussion de loin, mais vu le nombre d'interventions j'ai repris depuis le début ce qui agite les esprits.
J'en conclus mais peut être ai-je tort que :
1 - si l'aiguillage réel n'est pas en accord avec celui du Dispatcher alors RRTC considère que tout va bien malgré l'erreur et un signaleur ne pourra pas connaitre la position de l'aiguillage
2 - il faut donc qu'a un moment ou un autre par un biais quelconque on signale à RRTC que l'aiguillage est mal orienté par rapport au trajet

La seule solution que j'ai trouvé est la suivante :
a - par définition la portion de voie contenant une aiguille et reliant deux cantons est un itinéraire
b - un itinéraire peut avoir dans ses propriétés des actions

Il suffit donc
- physiquementde mettre 2 indicateurs d'occupation aux deux sorties de l'aiguillage , de cette manières chacun d'eux sera dans un itinéraire différent correspondant à deux trajets différents
- de faire une macro à insérer dans les propriétés de l'itinéraire qui au bout d'un délai correspondant au temps que mettra le train à parcourir l'aiguille vérifiera si l'indicateur extérieur à l'itinéraire est activé, si c'est le cas il y a arrêt avant d'entrer dans le canton erroné, ce qui fait que même si le canton erroné est occupé il n'y a pas de catastrophe.

C'est à mon avis la seule solution avec la rétrosignalisation dans un seul sens il nécessite deux indicateurs par aiguillages. Donc comme il a été dit mieux vaut avoir de bons moteurs d'aiguille et réserver cette solution à des moteurs d'aiguillages posant problème.

Il existe aussi une solution sans ajout d'indicateurs mais avec des moteurs qui peuvent signaler à un TCO le sens de l'aiguille, c'est le cas des Tortoises dans ce cas la sortie du canton avant d'emprunter l'aiguillage à position erronée peut être interdite par un signaleur.
A ce sujet vu le cours du dollar c'est le moment d'acheter aux US je viens de rentre deux packs de 12 tortoises coût total par Paypal 220 euros soit 9 euros le moteur.

C'est mon avis et je le partage

Papy Guy

pascal a écrit:

Bonjour à tous

Je rejoins la description de jean, sauf que je ne suis pas fan de la notion temps, car comment l'ajusté en fonction des profils locos. les bug sont fréquents cr XX secondes peuvent être trop peut pour certains convois marchandises réputés plus lent et trop pour un TGV ICE ou train grande ligne. C'est en tout les cas l'idée que je m'en suis fait lors de test.

L'idée directrice de jean et toutefois celle que j'utilise. Une question à Jean quand vous dites couper le courant ceci arrête l'exploitation du réseau ou juste le train qui s'est trompé d'itinéraire,

Merci pour votre réponse.

Bon train
Pascal

Bonsoir Pascal,

J'ai indiqué qu'il fallait ajuster la minuterie en fonction du réseau. Dans la solution que j'ai proposée qui, comme je l'ai dit, doit être améliorable, la minuterie doit être ajustée sur le temps que met le train le plus lent circulant sur le réseau pour parcourir le canton avant l'itinéraire et l'itinéraire. Je n'ai pas testé en réel sur le réseau, j'ai bricolé ça en quelques minutes au bureau.
Je ne vais sûrement pas non plus, tester en réel, car en 5 ans d'exploitation, je n'ai pas rencontré le problème, donc je fais confiance aux statistiques

Dans l'exemple proposé, on coupe le courant pour aller au plus simple. Je pense qu'on doit pouvoir simplement arrêter le trajet. C'est, sans doute, un peu plus compliqué dans la mesure où, lors d'une erreur d'aiguillage, TC ne sait pas quel train occupe le mauvais canton.

Ma proposition n'est qu'une idée de départ ... Ce qui serait bien, c'est que d'autres forumistes réfléchissent aussi à l'affaire, pour arriver à une solution logicielle élégante en commun

Jean

Bonsoir Guy,

C'est un petit peu usine à gaz ton truc et j'aperçois mal comment faire la macro qui va contrôler tout ça.

Quite à ajouter du hardware, je préfère la solution proposée par Marc et Pierrot un peu plus haut dans ce fil plutôt que de rajouter des contacts et des coupures de voie sur 10cm.

Amicalement,

Jean

Bonjour à tous

Merci à jean pour ça réponse , je suis d'accord avec votre position, sans contact aprés les aiguilles en entrées de canton, le seul moyen et la temporisation qui méne forcement à des collisions quand l'erreur d'aiguille dirige le train vers un canton déjà occupé. Je reste partisan du contact physique à l'entrée du canton mais ceci n'engage que moi.

Pour arrêter le train j'intégre pour ma part le flagman dans le canton et ainsi je peux arrêter uniquement le train qui fait fausse route et le reste du réseau fonctionne.

Alors évidemment il faut un fagmant par canton, ce qui demande quelque manip répétitive lorsque l'on parle de protéger une gare , mais bon, c'est peut-être le prix de la sécurité.

Bon train

Pascal

Comme je l'ai dit dans mon message je ne suis pas d'accord avec l'utilisation d'un signaleur car cela ne peut pas fonctionner en effet RRTC se fit pour l'exploitation à son TCO et le Dispatcher considère que l'aiguillage est dans le bon sens même s'il n'a pas été actionné par le moteur pour le mettre dans le sens de l'itinéraire.
Un exemple simple peut illustrer mon affirmation supposons que l'orientation de l'aiguillage soit inversé par rapport au TCO (ça nous renvoie à un autre fil) le TCO affichera un trajet sans problème alors qu'un train sera dévié de ce trajet à l'aiguillage en cause.
Autre point dans l'exemple de Jean un train est en canton courant C1 et va par son trajet normal en C2, s'il va sur C3 c'est qu'il est dévié de son itinéraire. On ne peut pas faire une vérification d'occupation de C3 en pensant que c'est notre train qui est dévié car un train différent peut être en attente dans C3 pour effec tuer un trajet passant par C1.
Comme je l'ai dit je ne pense pas qu'il y ait d'autre solution (qui peut être adaptée) que celle que je préconise plus haut car quoiqu'on fasse un signaleur ne peut signaler qu'une aiguille est mal orientée que si un vérification physique supplémentaire est effectué soit après le passage de l'aiguille soit avant si un moyen physique permet de vérifier la position de cette aiguille comme on peut le faire avec un tortoise.
Papy Guy

Papy Guy a écrit:

Comme je l'ai dit dans mon message je ne suis pas d'accord avec l'utilisation d'un signaleur car cela ne peut pas fonctionner

Mais si mais si, ça fonctionne. Tu n'as qu'à faire un test logiciel sur le fichier exemple que j'ai mis en ligne. Et je pense que Pascal l'a même testé en ligne.

Papy Guy a écrit:

en effet RRTC se fit pour l'exploitation à son TCO et le Dispatcher considère que l'aiguillage est dans le bon sens même s'il n'a pas été actionné par le moteur pour le mettre dans le sens de l'itinéraire.
Un exemple simple peut illustrer mon affirmation supposons que l'orientation de l'aiguillage soit inversé par rapport au TCO (ça nous renvoie à un autre fil) le TCO affichera un trajet sans problème alors qu'un train sera dévié de ce trajet à l'aiguillage en cause.

C'est bien pour cela qu'on va actionner une minuterie dans le canton courant qui appartient au trajet normal et que si le canton réservé par le trajet normal pour le train n'est pas occupé lorsque la minuterie se termine, on va stopper le train grâce aux opérations du deuxième signaleur.

Papy Guy a écrit:

Autre point dans l'exemple de Jean un train est en canton courant C1 et va par son trajet normal en C2, s'il va sur C3 c'est qu'il est dévié de son itinéraire. On ne peut pas faire une vérification d'occupation de C3 en pensant que c'est notre train qui est dévié car un train différent peut être en attente dans C3 pour effec tuer un trajet passant par C1.

Et pourquoi ne peut-on pas faire cette vérification en pensant que c'est notre train? Je dirais même qu'on est absolument certain que notre train est en C3:
- Notre train devrait être en C2. Or la non occupation de C2 montre qu'il n'y est pas. Comme on n'a qu'une seule aiguille entre C1 et C2, notre train ne peut être qu'en C3.
- Si notre train était en C2, C2 serait occupé et le signaleur "Arrêt" ne serait pas activé.
- Si C3 n'est pas occupé avant que le signaleur "Arrêt" ne se déclenche, notre train sera stoppé net.
- Il se peut que C3 soit déjà occupé. Dans ce cas, le signaleur "Arrêt" sera activé et si le train déjà présent en C3 n'est pas trop long, on évitera la collision par l'arrière. S'il occupe tout le canton, on n'évitera pas cette collision, mais comme le train percutant sera immédiatement stoppé, on peut espérer des conséquences pas trop graves.

La solution n'est, certes pas, la panacée, mais elle permet dejà d'arrêter le train avant qu'il n'ait mis complètement le souk sur le réseau.

Papy Guy a écrit:

Comme je l'ai dit je ne pense pas qu'il y ait d'autre solution (qui peut être adaptée) que celle que je préconise plus haut car quoiqu'on fasse un signaleur ne peut signaler qu'une aiguille est mal orientée que si un vérification physique supplémentaire est effectué soit après le passage de l'aiguille soit avant si un moyen physique permet de vérifier la position de cette aiguille comme on peut le faire avec un tortoise.

Et pour ce qui est d'avoir une solution de type hardware, la solution de Marc est beaucoup plus simple que celle que tu préconises.

Jean

Jean et bien non je persiste et je signe, le signaleur ne peut pas signaler une mauvaise orientation d'une aiguille car en reprenant ton exemple de "minuterie" tu dis :

1) On créé un premier signaleur baptisé "Minuterie" avec le paramétrage suivant:
1.1) signaleur déclenché si: le canton avant l'aiguille est canton courant d'un train ET que le trajet vers le bon canton est actif ET que le bon canton est réservé pour un train circulant dans le bon sens.
En soi, ce sont les conditions qui se réalisent lors de l'exécution d'un trajet

c'est là que la bât blesse car dans tous les cas d'orientation d'aiguillage et même au cas extrême où l'aiguille concernée n'est plus en place sur le réseau RRTC signalera que les conditions du signaleur sont respectées même si l'aiguillage est mal orienté.
Tu dis :

Tu n'as qu'à faire un test logiciel sur le fichier exemple que j'ai mis en ligne. Et je pense que Pascal l'a même testé en ligne.

Il est impossible en mode hors ligne d'accomplir un trajet en faisant dévier le train de l'itinéraire ni d'orienter l'aiguille d'un ititénaire en contradiction avec le trajet en cours.

Et pourquoi ne peut-on pas faire cette vérification en pensant que c'est notre train? Je dirais même qu'on est absolument certain que notre train ets en C3

Parce que si quand le train arrive en C3 le canton devient occupé il n'y aura pas suivi de train par le dispatcher car ce canton n'est pas dans le trajet.
Tout ce que l'on peut connaître c'est l'occupation de ce canton c'est tout. MAIS si ce canton est déjà occupé soit par un train à l'arrêt soit par un train effectuant un itinéraire et en attente de la libération de C2 il y aura collision car le signaleur Minuterie ne sera pas actif.

Et pour ce qui est d'avoir une solution de type hardware, la solution de Marc est beaucoup plus simple que celle que tu préconises.

Physiquement la vérification d'une orientation de l'aiguille ne peut s'effectuer qu'à la sortie de l'aiguillage c'est pourquoi il faut un indicateur de contact (1cm de long) pour signaler qu'un train est passé sur une branche ou l'autre de l'aiguille, mais je t'accorde que l'on peut ne mettre qu'un indicateur sur une des deux sorties de l'aiguille 1) trajet 1 l'indicateur n'est pas activé et 2) l'indicateur est activé. Il faut donc 1 DP1 et une entrée de module de rétro pour que RRTC le prenne en compte
Je n'ai pas vu la solution de Marc, je vais regarder de plus prés, mais il est impossible à partir du C1 de connaître par un contact virtuel (qui ne peut se trouver que dans C1) la position de l'aiguille sauf si on utilise un moteur qui signale à RRTC la position de l'aiguille. J'explique pourquoi plus haut.
En effet le Saint Esprit n'étant pas inclus dans RRTC je ne vois pas comment ce logiciel peut connaître la position d'une aiguille si aucun dispositif ne lui signale cette position et ce n'est pas un indicateur situé dans le canton le précédant qui le pourra sauf miracle.
C'est mon avis et je le partage, j'adore ce genre de débat.
C'est ainsi que l'on fait avancer le scmilblick.
Papy Guy

Guy,

Je crois que tu n'as pas bien compris le truc qui est pourtant simple: il n'y a pas un mais deux signaleurs, le deuxième étant activé par l'état inactif du premier.

Le premier, "minuterie", est activé quand on remplit les conditions pour faire un trajet normal.

Si, à la fin de la minuterie, le train n'est pas arrivé dans le canton où il devrait être dans le trajet normal, le deuxième signaleur est activé et stoppe le train.

Contrairement à ce que tu dis, il est parfaitement possible de faire un test logiciel. Essaye ceci:

1) Test 1
- assigne un train sur canton1, et occupe le canton 1, tous les autres cantons étant inoccupés
- démarre le trajet C1-C2-C4
- le signaleur "Minuterie" va s'activer.
- effectue le trajet normalement.
- le train va poursuivre son chemin et quand le signaleur "Minuterie" s'éteindra, il ne se passera rien.
Ce test montre que les signaleurs n'ont aucune influence si le train effectue son trajet normalement

2) Test2
- assigne un train sur canton1, et occupe le canton 1, tous les autres cantons étant inoccupés
- démarre le trajet C1-C2-C4
- le signaleur "Minuterie" va s'activer.
- pendant que "Minuterie" est actif, active le contact de canton3. C'est exactement ce qui se passerait si le train était mal orienté et qu'il entrait sur le canton3
- à l'instant où le signaleur "Minuterie" va s'éteindre, le signaleur "Arrêt" va s'activer et le train sera stoppé (voir la fenêtre de train)
Ce test montre que si le train occupe le mauvais canton (erreur d'aiguillage), il est stoppé.

Le test2 en images:

1) le trajet a été démarré, le signaleur "Minuterie" est activé



2) Le train est entré dans canton3 (canton occupé, donc erreur d'aiguillage), le signaleur "Minuterie" est toujours actif.



3) Le signaleur "Minuterie" s'est éteint et a donc activé le signaleur "Arrêt" puisque canton 2, canton dans lequel devrait se trouver le train à la fin de la minuterie, n'est pas occupé, le train est stoppé.



Jean

Oh là là , je n'ai pas dit que l'exemple ne fonctionnait pas et j'ai bien compris son articulation.
Cependant il a trois défauts majeurs :

1 - le postulat de mise en oeuvre est basé surl'occupation ou non du canton C3, si ce canton était libre et devient occupé il y a erreur d'aiguillage s'il ne l'est pas le trajet s'accomplit normalement. Or je l'ai dit dans mes deux interventions ce canton C3 peut être occupé et dans ce cas il y aura application du signaleur Arrêt. Le fait que C3 soit occupé quand C1-C2-C4 s'exécute n'a rien d'exceptionnel, ainsi le TCO peut représenter une gare sur voie unique le trajet arrive sur la voie d'évitement et un train fait correspondance sur C3. Je viens d'essayer l'exemple si C3 est occupé il y a déclenchement de l'arrêt d'urgence même si l'aiguillage est bien orienté.

2 - L'arrêt d'urgence ne s'effectue que lors de l'arrivée dans le canton erroné et non dans l'itinéraire reliant les deux cantons C1-C2

3 - Cet exemple ne fonctionne et n'est applicable que dans un seul sens (sous réserve que C3 soit libre) : celui ou l'aiguille est prise en talon par le trajet. En reprenant le TCO de l'exemple si l'aiguillage de l'itinéraire C2-C4 est mal orienté le train déraille car l'exemple différencie deux cantons alors que dans ce sens le train n'accède qu'à un canton : le C4. Je t'accorde d'ailleurs que ma solution de détection dans l'itinéraire est aussi batarde car elle ne peut résoudre une erreur d'aiguillage quand le trajet emprunte une des deux sorties de l'aiguille, cela bien sûr si l'aiguille n'est pas talonnable ou si le coeur d'aiguille est alimenté.

C'est pourquoi tant qu'un moteur d'aiguille n'est pas en mesure de signaler sa position à RRTC il n'y a pas de solution logicielle donc les deux seules solutions sont :
1 - faire confiance à la fiabilité des moteurs d'aiguille
ou
2 - mettre des Tortoises ou similaires alors RRTC pourra vérifier la direction de l'aiguille avant la sortie du canton.

Une dernière précision lorsque je disais qu'en mode hors ligne, au cours de l'exécution d'un trajet, il n'était pas possible de modifier l'orientation des aiguillages déterminée par le trajet, et d'attribuer le train qui effectue le trajet à un canton qui ne fait pas partie de ce trajet c'est exact. On peut cependant coutourner cette interdictio :
- en passant en mode édition pendant l'éxécution du trajet
- en acceptant d'interrompre le trajet en cours
- après le passage en mode édition d'orienter l'aiguillage en position d'erreur et d'attibuer le train du trajet à un canton hors trajet
- de quitter le mode édition
- d'accepter le redémarrage des trajets en cours au moment du passage en mode édition
- à la reprise du trajet celui-ci se ferme automatiquement et les réservations sont annulées
Tout cela n'avance pas à grand chose.

Moralité : Aucune solution logicielle possible, mais si les forumistes ont eu le courage de suivre le fil de la discussion ils auront énormément appris et pris conscience que si RRTC peut beaucoup il ne peut exploiter des renseignements qui ne lui sont pas transmis, ce dernier point est valable pour tous types de logiciels y compris WDGP. Pas de Saint Esprit dans le logiciel il exploite ce qu'on lui donne en patûre.

Papy Guy

Bonsoir à tous

Cette situation et ce fil sont des plus intéressant, les questions qui se posent sont à mon sens les suivantes:

1 Je veux que mon train ne démarre que lorsque je suis sûr que tous les aiguilles sont bien positionnées ?

2 Je veux arrêter mon train lorsque l'erreur d'itinéraire s'est déja produite.

Dans le cas 1 je suis d'accord qu'il faut obligatoirement un retour d'info sur la position de l'aiguille. J'irai même plus loin en disant qu'il faut prélever cette info directement sur l'aiguille.

Dans le cas 2 je vais sans doute décevoir notre ami Guy mais cela fonctionne et je ne peux pas m'imaginer avoir un version de RRTC 5.8 complétement Buger au point qu'une configuration presque similaire à celle de Jean fonctionne sur mon réseau

C'est dailleurs un souci de moteur d'aiguillage capricieux qui m'a fait me pencher sur le probleme. Un flagman attribuer au Block (Canton) permet d'arrêter un train une fois qu'il s'est trompé d'itinéraire , mais en aucun cas avant que l'erreur se soit produite.

Bon train à tous

Pascal

PS Jean j'ai bien verifier le Fichier en ligne en version Offline et sur mon réseau est cela fonctionne mais je ne suis pas fan de la minuterie trop compliqué à affiner.

Ami Pascal,
Je ne suis pas décu, car malheureusement aucun signaleur ne peut avertir le logiciel qu'une aiguille est mal orientée pour l'exécution d'un itinéraire.
Tu dis je mets un signaleur par canton, la vérification d'une fausse direction ne peut donc s'effectuer qu'à postériori ce qui fait que si le canton suivant la fausse direction est déjà occupé , il y a collision.
Je n'ai pas vu la configuration des signaleurs à intégrer dans ta solution mais il est fort probable que si le canton où le train se retrouve en cas de fausse direction est occupé son trajet sera stoppé même si l'aiguille a été bien orientée.
Dans ton PS tu dis que l'exemple offline de Jean fonctionne, c'est vrai si C3 n'est pas occupé quand le trajet C1-C2-C4 est lancé, si C3 est occupé il y a arrêt de RRTC même si l'aiguillage est en bonne position.
La vérification d'une fausse direction par signaleur aprés l'aiguille revient à vérifier l'arrivée d'un train après le passage d'un pont s'il n'arrive pas de l'autre côté c'est que le pont s'est écroulé c'est alors trop tard.
Même si on prend l'hypothèse que le canton de fausse direction ne sera jamais occupé le signaleur ne fera son travail que dans un seul sens celui où le train prend l'aiguille au talon. Comme je l'ai dit plus haut un itinéraire qui prend une aiguille à une de ses sorties sur un trajet ne peut être contrôlé par des signaleurs. Si l'aiguille est mal orientée le train déraille dans l'itinéraire.

Petite précision pour les débutants en RRTC qui lisent ces lignes :
- un trajet est composé de cantons, d'itinéraires et de liens, il a un (ou des) cantons de départ et un (ou des) cantons d'arrivée
- un itinéraire comporte un aiguillage (ou plus) et relie des cantons et a des propriétés
- un lien relie deux cantons sans possibilité de changement de direction il n'a pas de propriétés

Enfin pour terminer tu dis :
Dans le cas 1 je suis d'accord qu'il faut obligatoirement un retour d'info sur la position de l'aiguille. J'irai même plus loin en disant qu'il faut prélever cette info directement sur l'aiguille.
Tout a fait d'accord mais si l'aiguille n'est pas en mesure de transmettre l'info alors pas de solution.

Dans le cas 2 je vais sans doute décevoir notre ami Guy mais cela fonctionne et je ne peux pas m'imaginer avoir un version de RRTC 5.8 complétement Buger au point qu'une configuration presque similaire à celle de Jean fonctionne sur mon réseau
Dans le cas d'un aiguillage mal orienté on ne peut en aucun cas dire que RRTC est buggé, tout logiciel travaille avec des données qui lui sont transmises physiquement (rétrosignalisation) ou manuellement (position initiale des trains), si l'aiguille n'est pas en mesure de signaler la position qu'elle occupe réellement sur le réseau à TC ce n'est pas le logiciel qui est en cause, c'est pourquoi Freiwald ne peut (à mon avis) apporter de solution logicielle à ce problème.
Cordialement

Papy Guy De la discussion jaillit la lumière.

Papy Guy a écrit:

Dans ton PS tu dis que l'exemple offline de Jean fonctionne, c'est vrai si C3 n'est pas occupé quand le trajet C1-C2-C4 est lancé, si C3 est occupé il y a arrêt de RRTC même si l'aiguillage est en bonne position.

Non Guy, désolé d'en rajouter une couche, mais si C3 est occupé quand le trajet est lancé ET que l'aiguillage est en bonne position, il n'y a pas déclenchement de l'arrêt.

En effet, lors de la fin de la minuterie, C2 sera occupé et la condition de déclenchement du signaleur "Arrêt" ne sera pas remplie. Le signaleur ne sera donc pas activé et le train poursuivra son trajet normal.

Jean

Ami Jean,
Voici ce que j'obtiens au démarrage du trajet C1-C2-C4, aiguillage bien orienté :



et ce qui se passe 10 secondes après : arrêt de RRTC et fin du trajet



Amicalement

Papy Guy

Ben oui, c'est normal.

Si tu démarres le trajet et que tu ne fais pas bouger le train vers son canton normal (C2), il sera supposé être arrivé dans C3 quand la minuterie s'arrête (erreur d'aiguillage). Et donc il sera stoppé.

Maintenant, refais le même test et avant que la minuterie s'arrête, tu occupes le canton C2, comme le fera le train s'il roule normalement en prenant le bon itinéraire, sans erreur d'aiguillage.

Le signaleur "Arrêt" ne sera pas activé et le train effectuera son trajet tout à fait normalement.

Jean

Jean, je me doutais de ta réponse. En omettant les réserves de Pascal sur la minuterie, supposons que le temps pour aller de C1 à C2 soit de 15 secondes et que celui pour aller de C1 à C3 soit de 10 secondes, ce qui serait somme toute normal un itinéraire est droit l'autre courbe. Le train fonctionnera 5 secondes dans C3 avant de s'arrêter...
Je pense qu'il n'est pas nécessaire de continuer à somodiser les diptères sur les solutions qui ont été trouvées, car sans doute es tu d'accord avec moi, elles ne fonctionnent que dans un sens ce qui quand même posent problème.
Papy Guy

Bonjour à tous,

Mon chère Guy il ne faut pas me préter des propos que je n'ai pas.

Vous dites:
"car malheureusement aucun signaleur ne peut avertir le logiciel qu'une aiguille est mal orientée pour l'exécution d'un itinéraire."

Je ne dis cela à aucun moment au contraire je rejoints tout à fait cet argument.

Vous dites:
"Tu dis je mets un signaleur par canton, la vérification d'une fausse direction ne peut donc s'effectuer qu'à postériori ce qui fait que si le canton suivant la fausse direction est déjà occupé , il y a collision."

Vrai et faux

-Vrai si un seul contact dans le canton, encore que ,je ne veux pas compliquer les choses.

-Faux si un contact physique quelqu'il soit peut être activé à l'entrée du canton ou "cher Guy à la sortie de l'aiguillage" on peut stopper le train avant la collision.

"La vérification d'une fausse direction par signaleur aprés l'aiguille revient à vérifier l'arrivée d'un train après le passage d'un pont s'il n'arrive pas de l'autre côté c'est que le pont s'est écroulé c'est alors trop tard."

Certe mais pas non plus de collision oserais-je dire donc objectif atteint. La solution sur mon réseau est réalisée pour cette objectif éviter la collision sans quoi j'aurai opté pour la solution 1 décrite dans ma réponse plus haut.


Vous dite
"Dans le cas d'un aiguillage mal orienté on ne peut en aucun cas dire que RRTC est buggé,"

Peut être me suis mal exprimé mais je ne dis pas que RRTC est buggé il fonctionne trop bien pour cela et permet trop de chose. L'expression buggé etait en réponse a votre avis dans ce fil disant que "Comme je l'ai dit dans mon message je ne suis pas d'accord avec l'utilisation d'un signaleur car cela ne peut pas fonctionner ". Eviter une collision suite à une erreur d'aiguillage fonctionne et je le maintiens.

Bon train à tous

Pascal

Ben je n'ai pas eu l'impression de sodomiser quoi que ce soit dans ce fil, mais je peux me tromper.

Oui, le train va rouler un peu dans C3, mais il n'ira pas plus loin. Si un train est déjà présent dans C3, on a une bonne chance d'atténuer la collision ou même de l'eviter si le train présent est court.

Dans l'autre sens de circulation on peut être en présence de divers cas:

1) aiguille talonnable mécaniquement et électriquement (Marklin par exemple) et ça fonctionne comme dans le premier sens

2) aiguille talonnable mécaniquement mais à pointes de coeur polarisés: on aura court circuit. A vitesse lente le train plantera peut être un chou. A vitesse rapide, il passera sur l'élan. Le système fonctionnera dans ce dernier cas

3) aiguille non talonnable: déraillement du train, donc fonctionnement impeccable du système (je plaisante bien sûr )

Jean

Pour Pascal,
La tradition Internet veut que l'on se tutoie sur les forums, n'hésite donc pas. Faire le contraire me laisse penser que je suis plus vieux que je ne pense l'être .
En lisant ta réponse il apparait que j'ai mal inteprété des passages de ton intervention mea culpa mea maxima culpa.

Je tiens cependant à reprendre un passage de ta réponse :
Faux si un contact physique quelqu'il soit peut être activé à l'entrée du canton ou "cher Guy à la sortie de l'aiguillage" on peut stopper le train avant la collision..
Pour en venir au même résultat mieux vaut ma solution l'attribution d'un indicateur à l'itinéraire qui bloque le train avant l'entrée du canton.

Cependant pour une solution ne fonctionnant que dans un seul sens il faut :
- une coupure de rail
- un indicateur de contact
- une entrée de module de rétrosignalisation
- un cablage supplémentaire

Une solution fiable à 100% fonctionnant dans les deux sens qui bloque le train dans le canton précédant l'itinéraire erroné sans arrêter le reste de l'exploitation est l'emploi d'un Tortoise ou similaire qui peut envoyer sa position à RRTC. Cette solution ne reviendra pas plus cher (au taux actuel du dollar) que celle de l'indicateur supplémentaire dans un itinéraire.
Il faut savoir que le moteur du Tortoise reste en permanence sous tension (conso 60mA au repos) et peut donc signaler sa position en permanence suivant le croquis ci-dessous


Seul problème pour les Tortoises il faut des décodeurs intégrant un relais bi stable, le SA DEC 4 DC va bien et n'est pas pllus onéreux qu'un autre.


Note: Do not use additional resistors.
The resistance of the Tortoise motor is about 600 ohms, an ideal limiting resistance for LEDs.


Pour Jean
Je ne voulais pas dire que c'était toi qui maltraitait ces pauvres diptères , ce sont tous ceux (moi compris) qui se sont masturbés le cerveau pour trouver une solution logicielle.
Ton explication pour le sens inverse hum, hum... en admettant que l'aiguille soit talonnable sans court-jus, si celle-ci ne s'est pas déplacée pour l'itinéraire sa position sera aussi erronée au prochain passage dans le sens inverse.

Amitiés à tous les deux

Papy Guy

Bonsoir à tous

Pas de probleme pour le tutoiement.

Mon chére Guy récupérer l'info sur le moteur turtoise garantit-il la présence du fil qui à fait basculé l'aiguille?
C'était ta réflexion à Jean me semble t-il ou tu mettais en cause de maniére caricatural la présence de l'aiguillage sur le réseau.

Pour le reste avec le moteur turtoise comment se fait le retour d'info vers RRTC via quel procéder ?

Le S DEC 4 ne renvoie pas d'info sur la position de laiguille à ma connaissance.

Mais peut-être me trompe-je .

Merci pour les infos .

Bon train à tous

Pascal

Papy Guy a écrit:

Il faut savoir que le moteur du Tortoise reste en permanence sous tension (conso 60mA au repos) et peut donc signaler sa position en permanence suivant le croquis ci-dessous

Désolé Guy mais un tortoise moteur bloqué consomme 15 à 16mA sous 12 volts.
C'est dans la notice, et j'ai vérifié.
Si les tiens consomment 60 mA, c'est q'il y a un problème, mais je pense que c'est plutôt une faute de frappe

Le schéma que tu as ajouté n'est pas en rapport avec ce que l'on peut faire avec un tortoise, sauf pour un TCO avec des leds et des inters.

Les 2 inverseurs intégrés sont plus utiles à mon avis.

Bonne soirée


Marc

Pour Marc
La conso que je donnais était erronée, tu es gentil de dire que c'est une faute de frappe, c'est plutôt une panne de mémoire (l'âge) .

Pour Pascal
tu dis :

Mon chére Guy récupérer l'info sur le moteur turtoise garantit-il la présence du fil qui à fait basculé l'aiguille?
C'était ta réflexion à Jean me semble t-il ou tu mettais en cause de maniére caricatural la présence de l'aiguillage sur le réseau.

Là tu poses un problème. Après cogitation ma conclusion est qu'il doit pouvoir être possible de retrosignaler la position à partir du schéma de mon fil précédent, mon raisonnement est le suivant
1- l'orientation du moteur peut déclencher une LED spécifique
2 - Quand la Led s'allume il y a consommation de courant
3 - Un DP1 détecte une consommation de courant (voir http://train.modele.free.fr/detecteur.htm) et si elle existe il active une entrée de module de rétrosignalisation
4 - Donc l'activation d'une LED peut activer une entrée de module de rétrosignalisation.
Je suis nul en électronique, peut être dis-je une grosse sonnerie, mais avant de mettre ce système en oeuvre je ferai appel à des forts en électronique car peut être faudra-t-il intégrer des résistances complémentaires. Mais à mon avis je pense qu'électroniquement il doit être possible de rétrosignaler une consommation autre que celle d'une section de voie.

Quand je disais que même si une aguille n'était pas en place tout semblait être normal, je ne voulais pas être caricatural et blesser quiconque je voulais simplement illustrer le fait que de manière immuable le TCO et le Dispatcher afficherait imperturbablement l'itinéraire et le trajet déclenché sans sourciller que l'aiguille soit en place ou non car RRTC si fit au données qui lui sont intégrées on lui dit qu'à tel endroit il y a une aiguille avec telle adresse qui s'oriente à droite avec telle connexion dont acte RRTC fera comme si les données fournies étaient correctes et existantes et agira en conséquence.

tu dis aussi :

Le S DEC 4 ne renvoie pas d'info sur la position de laiguille à ma connaissance.

Je n'ai jamais dit ça, je mentionnais simplement le fait qu'étant donné qu'il fallait des relais bistables pour actionner les Tortoises, il falait compter dans le coût total les SA DEC 4 DC car ils intègrent des relais bistables dans le module qui rend caduque l'installation de relais complémentaires.

Papy Guy De la discussion jaillit la lumière

Bonjour à tous

Pour Guy

Nous voilà au moins d'accord sur un point la solution que tu décris nécessite un module de rétrosignalistion et un cablage supplémentaire donc même combat que si je rajoute un contact de plus dans un bloc, ou me trompe-je?

Mais restons sur la solution de position des aiguilles

Pour ma part mais ceci n'engage que moi, je pense qu'une solution la plus fiable possible est qu'il faut et je le maintiens prélever l'info directement sur l' aiguille comment , voilà l'idée .

Elle existait sur la voie Fleischmann (je n'utilise pas ce système de voie donc je ne sais pas si c'est encore le cas).

Je pense qu'il faut isoler l'aiguille électriquement de l'aiguillage la partie de l'aiguille alimentée sera donc celle realisant la direction puisque en contact avec le rail. Il suffit ainsi d'y souder un fil pour récupérer le courant et transférer l'info via un module de rétrosignalistion opto,disponible sur le marché. C'est le chemin le plus directe mais on peut imaginer mettre des relais ou autres à la guise de chacun.

Il y aura une fois une phase et une fois un neutre me diras-tu, et bien oui tu as raison un relais sur le neutre permet de le passé en phase ou l'inverse, ou deux modules de rétrosignalisation permettent de rétrosignaler 16 aiguillages, puisque un sera dédié aa la phase et l'autre au neutre.

Et enfin si d'aventure l'aiguille s arrete au millieu le risque de déraillement éviter puisqu aucune des deux aiguilles n'est en contact avec un rail et aucune n'est donc alimenté ellectriquement.

Merci pour tes commentaires .

Bon train à tous

Pascal

Bonjour,

Voici ce que j'ai fait sur une des aiguilles de mon réseau il y a environ une semaine avec toute satisfaction pour l'instant.


On peut faire difficillement plus simple, pas besoin de rétrosignalisation supplémentaire, ni de "flagman" ou autre à paramétrer, les trains s'arrêtent toujours dans le canton avant l'aiguille, ça fonctionne dans les 2 sens, ....
Seul problème, l'utilisation des aiguilles elles-mêmes comme contact pour le relais n'est pas des plus fiable. En effet, ces endroits sont soumis à des poussières venues du ballast, à une peinture éventuelle des flancs des rails, et à la pression plus ou moins importante de l'aiguille sur le rail fixe.
C'est d'ailleurs pour ces raisons que l'on emploie souvent un contact auxiliaire du moteur d'aiguille comme commutation du coeur de celle-ci.

J'attends vos réactions

Marc