Gare cachée à tronçon - pas d'entrée sur le premier tronçon

Bonjour à tous,
Ma question a peut-être déjà été traitée, mais je n'ai rien trouvé malgré quelques recherches.

Soit la gare cachée suivante :


J'ai créé un trajet permettant d'aller du canton 1 vers toutes les voies de la gare cachée, les cantons 5, 7 et 9 étant définis comme cantons d'arrivée.


Lorsque je lance le trajet pour Engine 1 alors que les cantons 4, 6 et 8 sont occupés, Engine 1 se déplace jusqu'au canton qui précède la gare, comme attendu.


Avec AutoTrain, je déplace Engine 3 du canton 6 au canton 7.
Ma question : Pourquoi le trajet de Engine 1 ne dirige-t-il pas le train vers canton 6, maintenant libéré
Et quelle est la méthode à appliquer afin que ce soit le cas ?


Les messages indiquent que Engine 1 est en attente de continuer son trajet... Moi aussi j'attends, mais sans succès! :-/


En revanche, si je prolonge avec AutoTrain le déplacement jusqu'au Block 10, alors Engine 1 réserve son entrée vers cantons 6 puis 7.


Je suis presque sûr que la solution est triviale, car je ne dois pas être le seul à devoir gérer une telle situation.
Merci pour vos lumières !

Rien que de normal: c'est la méthode standard de réservation des cantons dans TC.

"Lorsqu'il y a un itinéraire derrière le canton à réserver TC réserve l'itinéraire et le canton suivant cet itinéraire."

Dans ton cas de figure, le canton 7 occupé par engine 3 ne peut pas être réservé pour engine 1 qui est donc laissé en attente.

Si tu veux que engine 1 puisse avancer, il faut que tes deux locos, engine 1 et engine 3 soient en train d'exécuter le même trajet.

C'est la méthode qu'on utilise pour faire empiler des trains sur des voies de gare divisées en plusieurs cantons.

Maintenant, avec la V9 Gold, tu pourrais résoudre le problème en utilisant la nouvelle fonctionnalité d'empilage avec un seul canton sur ta voie de gare.

Jean

Merci, Jean, pour ton explication.
Je ne suis pas sûr de comprendre complétement :
En effet, au lancement du trajet, Engine 1 se déplace bien de Canton 1 à Canton 2, même si tous les cantons suivants sont occupés.
Pourquoi la même logique n'est-elle pas appliquée pour passer de Canton 2 à Canton 6 ?

Bonsoir,

je ne comprend rien à l' ennoncé du problème...

texte figure 3.... Engin 3 du Canton 4 au canton 5 ??
alors tu veux Engine 1 vers canton 4 ou 6 ??

texte figure 5... Engin 1 réserve entrée vers 4 puis 6 ???

Alors c' est une "Loco Gazelle"?
alors c' est vers 4 et 5 ou 6 et 7 que tu veux dire ?

Tiens donc... au fil de mes essais, tout à coup ça a fonctionné comme je l'attends !

Je suis en simulation, j'ai activé manuellement les indicateurs d'occupation de toutes les voies réservées par mes 4 véhicules. Et depuis, le trajet permet à Engine 1 d'entrer sur Canton 6 dès que Engine 3 est dirigé vers Canton 7.



Y a-t-il une explication à cette différence de comportement, sachant que Engine 1 et Engine 3 ont été déplacés exactement de la même manière que lorsque j'ai posé ma question ?

xaviermbcn a écrit:

Bonsoir,

je ne comprend rien à l' ennoncé du problème...

texte figure 3.... Engin 3 du Canton 4 au canton 5 ??
                       alors tu veux Engine 1 vers canton 4 ou 6 ??

texte figure 5... Engin 1 réserve entrée vers 4 puis 6 ???

  Alors c' est une "Loco Gazelle"?
                     alors c' est vers 4 et 5  ou  6 et 7  que tu veux dire ?

Salut Xavier,
Merci d'avoir souligné, j'ai corrigé l'énoncé, toute la rédaction avait été faite pour la voie droite, les captures d'écran ont été faites ensuite avec l'autre voie.

Bonsoir,

la façon de réagir de Engine 1 peut dépendre de plusieurs facteurs. Entre eux, en effet, ce n' est pas la même chose un canton Réservé/Non réservé (un train dans un bloc) que Occupé/Non occupé (indicateurs activés). Un autre aspect correspont à certaines règles de ton trajet. Tu peux jouet avec ça pour mieux comprendre TC. Et suivre ces messages avec le détail (voir la loupe).

cordialement,

Xavier

arathilion a écrit:

Y a-t-il une explication à cette différence de comportement, sachant que Engine 1 et Engine 3 ont été déplacés exactement de la même manière que lorsque j'ai posé ma question ?

TC n'ayant pas toutes les données, il reste dans l'expectative... c'est pour ça que parfois les réactions en simulation diffèrent quelque peu de ce qui se passe réellement sur le réseau...
Pour reproduire une situation en simulation, il faut inclure toutes les données de départ, y compris les occupations.

J ai lu un peu vite mais je pense être confronté au même problème. Est ce que ce ne serait pas
Parce que tc a déjà choisi un des cantons (4,6 ou et que celui qui si libère (5,7 ou9) n est pas celui que tc a choisi. J arrive cette conclusion parce que le fonctionnement est aléatoire et si on libère le bon canton le trajet continue. J ai remarqué que cela ne se produit pas avec tous les trajets. Un de ceux avec lequel cela se produit souvent à l’option « utiliser l itinéraire le plus ancien ». Du coup je suis preneur d une solution pour que le train ne reste pas à l’arret Alors qu il a un canton d’en libre derrière.
J ai parfois remarque qu après un certain temps le trajet se poursuivait.

J'ai le même problème, Vincent. Selon les options choisies dans les règles du trajet, le comportement est différent mais jamais vraiment parfait...

Merci de ton retour.
C est rassurant de savoir qu on est pas seul...

Bonjour,

comme TC offre une grande variété de solutions pour un même problème il est nécessaire savoir quels sont les objectifs que tu as pour tes trajets et tes trains. Une solution, par exemple, pour optimiser ta gare cachée, en cas de ne pas avoir de Succésseures serait de faire arriver tes Trajets jusqu'à Block 2. Comme ça tu évites que ta locos bloque l' entrée en cas que TC choisisse un block occupé. Puis, à chaque Trajet de sortie tu fait démarrer un trajet de Block 2 jusqu'au Block qui se libère ...

cordialement,

Xavier

rico a écrit:

J'ai le même problème, Vincent. Selon les options choisies dans les règles du trajet, le comportement est différent mais jamais vraiment parfait...

En fait, si on veux vraiment que TC ait le comportement que l'on désire, il ne faut pas lui laisser de choix... toujours le tenir en laisse... après il ne reste plus que les erreurs de calcul sur les distances d'arrêt ou la commande de fonctions...

Bonsoir,

DiCoS69 a écrit:

... En fait, si on veux vraiment que TC ait le comportement que l'on désire, il ne faut pas lui laisser de choix...

Cela me paraît cohérent ... Ceci étant, on peut faire confiance à TC pour découvrir des circulations (comme un spectateur dans la réalité mais éventuellement au détriment du respect de cette réalité) et surtout pour la gestion des gares cachées (en fonction de la longueur des trains et de bien d'autres contraintes) ...

A+
Georges

C'est bien ce qui le rend attrayant au final.

Geo69 a écrit:

Bonsoir,

DiCoS69 a écrit:

... En fait, si on veux vraiment que TC ait le comportement que l'on désire, il ne faut pas lui laisser de choix...

Cela me paraît cohérent ... Ceci étant, on peut faire confiance à TC pour découvrir des circulations (comme un spectateur dans la réalité mais éventuellement au détriment du respect de cette réalité) et surtout pour la gestion des gares cachées (en fonction de la longueur des trains et de bien d'autres contraintes) ...

A+
Georges

Oui, bien sûr, et tant que la complexité du réseau et des circulations reste "raisonnable", on peut s'attendre à un fonctionnement sans faille... au-delà, il y a tant de paramètres influents, qu'il faut que toutes les données soient bien transmises en temps et en intégralité pour ne pas avoir un (petit) dysfonctionnement de temps à autre...
Ce n'est heureusement, pas souvent TC qui est en cause... bien que ce soit difficile à cerner...
Exemple : une fonction sensée être déclenchée par l'activation du marqueur d'arrêt du canton d'arrivée d'un trajet, et qui "oublie" parfois d'être exécutée (non activée dans la fenêtre de train), alors que le train s'est bien arrêté, prouvant que le marqueur a bien été activé... cela pouvant se produire aléatoirement sur des trajets différents...

DiCoS69 a écrit:

Geo69 a écrit:

Bonsoir,



Exemple : une fonction sensée être déclenchée par l'activation du marqueur d'arrêt du canton d'arrivée d'un trajet, et qui "oublie" parfois d'être exécutée (non activée dans la fenêtre de train), alors que le train s'est bien arrêté, prouvant que le marqueur a bien été activé... cela pouvant se produire aléatoirement sur des trajets différents...

Tiens, très bon exemple ... Pour celà Freiwald m' a proposé de mettre un petit retard de temps entre action et action et ça marche !

Bonjour,

DiCoS69 a écrit:

... une fonction sensée être déclenchée par l'activation du marqueur d'arrêt du canton d'arrivée d'un trajet, et qui "oublie" parfois d'être exécutée (non activée dans la fenêtre de train), alors que le train s'est bien arrêté, prouvant que le marqueur a bien été activé... cela pouvant se produire aléatoirement sur des trajets différents...

Dans ce cas, TC est bien "tenu en laisse" mais il pousse le réalisme très très loin et, comme dans la réalité, il y a le règlement et le conducteur du train qui le respecte ou qui oublie de klaxonner !...

xaviermbcn a écrit:

... Pour celà Freiwald m' a proposé de mettre un petit retard de temps entre action et action et ça marche !

C'est vrai qu'un petit délai fait souvent des miracles !...

A+
Georges

xaviermbcn a écrit:

... Pour celà Freiwald m' a proposé de mettre un petit retard de temps entre action et action et ça marche !

Geo69 a écrit:

C'est vrai qu'un petit délai fait souvent des miracles !...

A+
Georges

Je confirme. Parfois il suffit même de modifier l'ordre de succession des actions pour résoudre le problème du raté occasionnel.

C'est vrai, je l'ai constaté aussi, le coup du délai ou la position dans la liste des opérations peuvent jouer un rôle...