[partiel. résolu] arrêt avant la zone d'arrêt sans raison

Bonjour à tous,

je vous soumets un problème, que j'arrive pas à résoudre.

Voici mes fichiers :
http://www.amfrailroad.ch/documents/AMFRR.yrr
http://www.amfrailroad.ch/documents/AMFRR.yrs
http://www.amfrailroad.ch/documents/AMFRR.yrl
http://www.amfrailroad.ch/documents/AMFRR.yrD

Mon soucis :
démarrer un autotrain depuis le canton 110 S pour aller au canton 112 S (110M pour 112 M va aussi)
tout se passe bien, le train rentre dans le canton et ne s'arrête qu'une fois avoir atteint la zone d'arrêt 112 S stop (dans la fenêtre Control).

Maintenant, faire un autotrain depuis un des canton Bakersfield 5 à 9, toujours direction du 112 S.

Là, étrangement lorsque le train mord le canton 112S, le trajet s'arrête, sans attendre d'arriver au contact d'arrêt.

Identique en faisant un trajet.
Impossible de trouver d'où ça vient....

Voici la réponse reçue ce jour de Freiwald :

Citation :

Hello Christophe,


thank you very much for your inquiry.

>From the distance it is almost impossible to find out the reason of this
effect.

But there are some general things you should check:

1.
Each indicator must be triggered reliably when it is expected to be
triggered.

2.
Each indicator symbol must only be turned on once (!!) by a passing train.
Ensure with an approriate "Memory" setting, that each indicator is not
turned off, while the train is still located on this indicator.


I hope this helps.



Best regards

Voici encore des indications des messages en mode détail :

Citation :

Aucun indicateur de freinage ni d'arrêt spécifié pour Canton '112 S'. Indicateur '112 S' sera utilisé comme indicateur d'arrêt.

Pourtant en partant des cantons 110S ou 110M, ça marche correctement.
J'ai recontrôlé, et mes zones d'arrêt et de ralentissement sont bien configurés.
Aucune message de ce genre depuis les 110S/110M...

étrange, non ?

C'est à nouveau moi ;-)

J'ai trouvé ou est le problème, mais pas pourquoi....

En partant des Bakersfield 5à 9 il prend les zones d'arrêt dans le sens inverse. alors qu'il circule toujours dans le même sens.....

Je vais faire part de ma recherche à Jürgen, peut-être aura-t-il des infos à me donner...

Cette fois j'arrête de parler sur ce fil pour ce soir :-)

Christophe

Bonjour Christophe,

Le lien pour charger le fichier de réseau ne fonctionne pas ...

Donc je ne peux pas voir éventuellement ce qui se passe.

J'ai déjà vu ce genre de problème sur un réseau. En fait, le dessin du SPC était fait de telle façon que le train inversait son sens de circulation entre deux cantons et donc le sens des indicateurs d'arrêt n'était plus correct pour le canton concerné.

Si tu peux corriger les liens, je chargerai le fichier pour jeter un oeil.

Bonne journée,

Jean

Jean_01 a écrit:

Le lien pour charger le fichier de réseau ne fonctionne pas ...

Bonjour Jean,
c'est corrigé, désolé.

Le canton est effectivement pas placé du même côté sur le TCO et sur le dispatcher.
Mais pourquoi ça fonctionne depuis deux voies et pas depuis les autres ? (alors qu'un bloc les sépare et que celui-ci est toujours identique...

bisounours a écrit:

Jean_01 a écrit:

Le lien pour charger le fichier de réseau ne fonctionne pas ...

Bonjour Jean,
c'est corrigé, désolé.

Le canton est effectivement pas placé du même côté sur le TCO et sur le dispatcher.
Mais pourquoi ça fonctionne depuis deux voies et pas depuis les autres ? (alors qu'un bloc les sépare et que celui-ci est toujours identique...

Bonjour Christophe,

J'ai un peu regardé et je pense avoir trouvé le coupable.

Un bloc les sépare dis-tu ... ce n'est pas ce qui se passe si tu regardes ton SPC

1) Si on fait un Autotrain de 110S à 112S et qu'on regarde, sans le lancer (icône des jumelles), les cantons sélectionnés, on a: 110S, 111 et 112S. Effectivement, un bloc les sépare

2) Si on fait la même chose de Bakersfield6 à 112S, il sélectionne: Bakersfield6, Bakersfield sw E, 210A, 111, et 112S. Et là ce n'est plus un bloc qui les sépare, mais 3 parmi lesquels 210A qui est parcouru en sens inverse et inverse donc le sens logique du train.

Pourquoi 210A est-il sélectionné dans le trajet? tout simplement parce que, dans ton SPC, tu as créé un itinéraire Bakersfield sw E ---> 210A. Cet itinéraire est à supprimer et à remplacer par un itinéraire entre le noeud et Bakersfield sw E.

Une fois cela fait, Autotrain ne sélectionne plus le canton 210A et ton problème disparaît.

A tout bientôt,

Jean

Salut,
merci de prendre le temps de regarder mon fichier.

Le canton 210a est parcouru lorsque les trains sortent des voies de triage, je suis obligé de le laisser, sinon je n'aurais pas de "courant" sur cette section de voie.

C'est apparamment ce canton qui pose problème, mais pourquoi arrivé sur le canton 112 S/112M, il prend la zone d'arrêt comme si le train venait de la droite, ça je comprend pas.
En fait, je voulais dire que le train passait toujours via le canton 111 avant de rentrer au 112, qu'il parte des voies principales ou du triage.

Christophe,

Je n'ai jamais dit qu'il fallait supprimer le canton 210A. Ce sont simplement tes itinéraires qui sont mal faits entre:

Le noeud (situé entre 112S et 111) et les cantons Bakerfield6 sw E et 210A.

En effet, dans ta situation actuelle, tu as:

1) un lien entre bakerfield6 sw E et 210A. Ce lien est ridicule, il fait un retour en arrière.
2) un lien entre 210A et le noeud
3) Pas de lien entre bakerfield6 sw E et le noeud (tu peux le voir en supprimant le lien bakerfield6 sw E --->210A)

Pour que ça fonctionne correctement il faut que tu aies:

1) un lien entre bakerfield6 sw E et le noeud
2) un lien entre 210A et le noeud
3) aucun lien entre bakerfield6 sw E et 210A

Dans ton paramétrage actuel même un Autotrain entre bakerfield6 sw E et 111 ne fonctionnerait pas à cause de tes liens mal faits qui imposent un retour en arrière dans 210A et donc une inversion du sens dans 210A.

Donne moi ton email personnel et je t'enverrai le fichier rectifié.

Jean

Salut Jean,
j'ai bien reçu ton fichier.
Malheureusement ça va pas aller.
Car quand je pars de Bakersfield (5 -9), je dois passer par Bakersfield Sw E, puis par le 210a pour aller sur le 111.

Simplement pour une question d'esthétique, on a mis au même niveau les cantons Bakersfield Sw E et le 211a. Mais sur le terrain il passe bien via les deux cantons.

l'arrivée du 210 a est bien à droite, et repart à gauche, mais on a caché la route sous le bloc pour faire plus joli.

Je vais continuer à chercher une solution, merci pour ton aide.

Christophe

Salut la foule,

Jean, merci de consacrer du temps à notre problème.

bisounours a écrit:

J'ai trouvé ou est le problème, mais pas pourquoi....

En partant des Bakersfield 5à 9 il prend les zones d'arrêt dans le sens inverse. alors qu'il circule toujours dans le même sens.....

Effectivement en paramétrant les indicateurs pour les deux sens de circulation, le problème disparait. Il doit bien y avoir une logique à ces problèmes mais cette dernière nous échappe et ajouter 4 coches, c'est pas la fin du monde...

Le passage de 210A est mal interprété par le logiciel, car il n'aime pas les routes cachées sous les cantons.

Si un train sur le réseau entre dans le canton par la droite, on ne peut pas dire au logiciel dans le SPC qu'il entre par la gauche. Le simple fait de rajouter des indicateurs de canton dans le canton d'arrivée n'est qu'une solution apparente au problème, car le logiciel aura, malgré tout inversé l'orientation du train. Et vous devrez aussi en rajouter dans 111, car, dans la situation actuelle, si jamais le train doit s'arrêter dans 111, il aura exactement le problème.

J'ai modifié légèrement le SPC pour que le train passe par 210A dans le bon sens. Je pense que cela ne nuit en rien à l'esthétique du SPC, mais au moins, la logique du trajet est respectée.

En test logiciel, tout fonctionne parfaitement.

J'envoie le fichier modifié à Christophe.

Dernier petit truc noté au passage: vous avez des contacts d'occupation intégrés dans les itinéraires, qui augmentent le temps de calcul du PC et renvoient des messages dans la fenêtre des messages du genre: "L'état d'occupation de Itinéraire '111' est modifié et évalué par le même évènement. Modifier les paramètres de Itinéraire '111' pour s'assurer que son état d'occupation change avant d'être évalué par d'autres éléments."

En suppriment l'attribution des contacts aux itinéraires, vous n'aurez plus les messages et le fonctionnement sera complètement identique, puisque, de toutes façons, TC ne libère les itinéraires qu'au contact d'arrêt du canton suivant.

Jean

Bonjour Jean,

Jean_01 a écrit:

Le passage de 210A est mal interprété par le logiciel, car il n'aime pas les routes cachées sous les cantons.

Si un train sur le réseau entre dans le canton par la droite, on ne peut pas dire au logiciel dans le SPC qu'il entre par la gauche. Le simple fait de rajouter des indicateurs de canton dans le canton d'arrivée n'est qu'une solution apparente au problème, car le logiciel aura, malgré tout inversé l'orientation du train. Et vous devrez aussi en rajouter dans 111, car, dans la situation actuelle, si jamais le train doit s'arrêter dans 111, il aura exactement le problème.

J'ai modifié légèrement le SPC pour que le train passe par 210A dans le bon sens. Je pense que cela ne nuit en rien à l'esthétique du SPC, mais au moins, la logique du trajet est respectée.

En test logiciel, tout fonctionne parfaitement.

J'envoie le fichier modifié à Christophe.

Christophe et moi avons essayé tes modifications mais le problème subsiste.

Le train suit normalement la continuité des cantons (l'icône est du bon côté) mais la référence prise pour les indicateurs est erronnée même lorsque l'on fait partir le train du canton 210a. C'est donc que le problème ne provient pas d'un quelconque élément situé "en amont" du canton 210a.

Jean_01 a écrit:

Dernier petit truc noté au passage: vous avez des contacts d'occupation intégrés dans les itinéraires, qui augmentent le temps de calcul du PC et renvoient des messages dans la fenêtre des messages du genre: "L'état d'occupation de Itinéraire '111' est modifié et évalué par le même évènement. Modifier les paramètres de Itinéraire '111' pour s'assurer que son état d'occupation change avant d'être évalué par d'autres éléments."

En supprimant l'attribution des contacts aux itinéraires, vous n'aurez plus les messages et le fonctionnement sera complètement identique, puisque, de toutes façons, TC ne libère les itinéraires qu'au contact d'arrêt du canton suivant.

Certes oui. En incorporant les indicateurs dans les itinéraires, ceux-ci marquent leur occupation dans la fenêtre dispatcher. Pure cosmétique, au même titre que les itinéraires sans aiguillages.

Salut Sebi,

Il y a quand même un truc qui me semble bizarre: le dernier fichier que j'ai envoyé à Christophe, je l'ai testé une bonne duzaine de fois en test logiciel, bien sûr, et tout fonctionnait correctement.

Je viens de le retester encore autant de fois et tout fonctionne, quel que soit le canton de départ, y compris 211A

J'utilise TC depuis plus de 5 ans et je n'ai jamais vu un truc qui fonctionne en test logiciel et qui foire sur le réseau. Et pourtant j'ai vu passer un bon paquet de réseaux, du plus simple au plus compliqué.

1) Avez-vous fait vos tests avec le dernier fichier que j'ai envoyé à Cristophe?

2) Est ce que le fichier que vous utilisez fonctionne en test logiciel chez-vous?

Jean

Salut Jean,

Jean_01 a écrit:

1) Avez-vous fait vos tests avec le dernier fichier que j'ai envoyé à Cristophe?

Oui

Jean_01 a écrit:

2) Est ce que le fichier que vous utilisez fonctionne en test logiciel chez-vous?

Oui également.

Maintenant, que tu me dis ça, le problème vient peut-être du système digital utilisé : nous utilisons RCI et si tu as laissé ton (tes) système(s) il est possible, bien qu'étrange, que Train Controller agisse différemment.

Bonsoir,
la version D2 résoud presque tous nos problèmes.....
L'arrêt sur le canton de destination se fait maintenant correctement, et avec le bon détecteur. C'était donc bien un bug..
Par contre, encore un dernier soucis. Si le bloc précédent est fermé, il ralenti bien sa vitesse, mais ne s'arrête jamais...

Je vais remonter ce dernier soucis à Jürgen, et peut-être qu^à la D3 tout ira bien ;-)

Merci encore Jean pour ton aide !

Christophe