Version 7.01 du 7 avril 2020: passer sur V7.04

[jpp38]

Michel (Midav)

Est-ce que, dans l'essai que tu as fait, tu as modifié une option de simulation, ou est-ce que ce comportement anormal se produit sur la base des options que tu avais déjà auparavant…. Autrement dit, si c'est une régression sur le mode de fonctionnement antérieur?

Par ailleurs, je ne comprends pas d'où sort cette violation de signal. Peux-tu expliquer?

Est-ce que le problème arrive en Simu aussi?

Je pense que ça va être "chercher une aiguille dans une meule de foin" si on cherche à comprendre ce qui se passe sur ton .lay.
Si ta réponse à ma première question amène la conclusion qu'il s'agit d'une régression sur le mode par défaut, je referai une version V7.004 identique à la V7.01 hors modif BAL/BAPR, et je te demanderai (si tu es d'accord) de refaire l'essai sur cette version, pour voir si ça se passe encore.


JP

[midav91]

Bonjour Jean Pierre
J'ai bien vu ton message en MP.
Je suis dessus depuis hier.

Est-ce que, dans l'essai que tu as fait, tu as modifié une option de simulation, ou est-ce que ce comportement anormal se produit sur la base des options que tu avais déjà auparavant….

Je suis en mode BAL (rien de coché parmi les 3 nouvelles options)
J'ai quitté le mode BAPR (ralentissement retardé en début de canton coché au début) quelques temps après avoir commencé sur la V7.01, car j'ai eu quelques dépassement de la zone d'arrêt des trains réels (je pense 2 ou 3 mais sans y porter vraiment attention à ce moment là, il y avait quelques temps que je n'avais pas lancé de RUN d'où problème de voies sale ? ! alors sans trop chercher j'ai voulu vérifier qu'en BAL ça ne se produisait pas ... et sur les trains réels, c'est vrai que ça ne s'est pas reproduit !!)
Je pense qu'il va falloir que je reprenne des essais en BAPR pour voir vraiment le comportement avec les trains réels !!

Autrement dit, si c'est une régression sur le mode de fonctionnement antérieur?

Ce que je peux redire, c'est que ça m'était déjà arrivé auparavant sur des versions antérieures, mais extrêmement rarement (peut-être 2 fois en tout, depuis des mois ou plutôt années de RUN, je n'y avais pas vraiment prêté attention non plus !

Par ailleurs, je ne comprends pas d'où sort cette violation de signal. Peux-tu expliquer?

Le train simulé dépasse réellement le signal voir photo à la fin

Est-ce que le problème arrive en Simu aussi?

Justement ce matin j'ai lancé deux simulations (toujours BAL) de près d'une heure et à la 2ème OUI j'ai eu cette violation (encore une fois avec un train (là un autorail) et un canton différents par rapport aux RUN d'hier !! voir photo à la fin

Je pense que ça va être "chercher une aiguille dans une meule de foin" si on cherche à comprendre ce qui se passe sur ton .lay.
Si ta réponse à ma première question amène la conclusion qu'il s'agit d'une régression sur le mode par défaut, je referai une version V7.004 identique à la V7.01 hors modif BAL/BAPR, et je te demanderai (si tu es d'accord) de refaire l'essai sur cette version, pour voir si ça se passe encore

Je peux peut-être déjà continuer (tout de suite) des essais simulation en BAPR, puis après réessayer en RUN BAPR
A noter : n'y a-t-il pas un moyen d'éviter le crash de CDM en sortant de la fenêtre pour récupérer des infos dans le debug ?

C'est pas très visible mais le signal est bien dépassé de quelques "cm"

[jpp38]

Merci Michel.

Michel CC72000 a déjà corrigé (chez lui) le crash après violation de signal… Donc ce sera fait.
Par contre, ce que je voudrais comprendre, c'est pourquoi tu as plus de violations de signal qu'avant, alors que par défaut (sans activer de nouvelles options), tu te trouves (maintenant) en mode BAL, et donc les trains devraient aller plus lentement.

Je vais essayer de refaire un cdr.exe qui revient au mode antérieur, pour vérifier si tu retrouves le fonctionnement d'avant... Autrement dit vérifier que cette augmentation de violations de signal vient bien de la modif faire sur le BAPR. Et je t'enverrai le lien quand ce sera prêt.


JP

[midav91]

J'étais passé en mode BAPR et je viens d'avoir au bout d'1/4 d'heure de simulation une autre fenêtre "impossibilité de s'arrêter ..."
Encore un autre train et un autre canton, apparemment sans justification ? (je me souviens l'avoir eu, extrêmement rarement, avec des "itinéraires à la volée" où, je pense, le train arrivait trop vite effectivement !!)

Par contre cette fenêtre là n'a pas scratché CDM, on peut arrêter la simu et fermer le réseau puis redémarrer

Viol signal3.jpg (126.41 Kio) Consulté 922 fois

[midav91]

On s'est croisé

Pas de problème pour me renvoyer ce lien




EDIT : encore un viol après une bonne heure de simu en mode BAPR (et encore un nouveau train et un nouveau canton, bon ... statistiquement pourquoi pas .. 17 trains, plus de 50 cantons !!)

EDIT à 0h15
Ce soir, 2h1/2 de simu en mode BAPR : aucune violation de signal

SUITE à 0h20 : les 2h1/2 c'est avec la V7.01, je viens seulement de voir que tu m'avais mis le lien en MP. Je fais l'essai demain matin

[jpp38]

Bonjour Michel.

Merci pour ce test.
J'avoue que je ne comprends pas pourquoi ce comportement n'est pas plus répétitif en simulation.

Dans l'exe que je t'ai envoyé, je suis revenu au mode antérieur (donc, celui que tu utilisais maintenant depuis des années sur ton réseau), qui n'est ni le BAL ni le BAPR, mais un ralentissement retardé avec un palier intermédiaire à vitesse moitié….Juste pour voir si ça arrive aussi sur ce mode natif et à quelle fréquence.

JP

[CC72000]

Salut JP, Salut Michel,

Par contre, ce que je voudrais comprendre, c'est pourquoi tu as plus de violations de signal qu'avant, alors que par défaut (sans activer de nouvelles options), tu te trouves (maintenant) en mode BAL, et donc les trains devraient aller plus lentement.

C'est plus complexe qu'un problème de vitesse, je m'explique : en fonctionnement BAPR (celui de la V7.01, ou qq soit les versions précédentes) le ralentissement se fait en une durée DeltaTemps. En mode BAL, le ralentissement se fait théoriquement (celui calculé par CDM) en 2 fois ( DeltaTemps / 2 ) mais dans la pratique, il se fait en DeltaTemps1 + DeltaTemps 2,
qui sont bien dans la relation DeltaTemps = DeltaTemps1 + DeltaTemps2.
Ce qui implique que le décalage de DeltaTemps1, lui on s'en moque, le train roule dans le canton, l'écart virtuel /réel n'a pas d'importance. Mais pour ce qui est de DeltaTemps2, lui va entraîner une violation de signal si DeltaTemps2 (réel) > DeltaTemps/2 et cela bien que l'on roule moins vite.

Je vais expérimenter différents scénario avec différentes valeurs de CV3/4 et de courbe de vitesse pour chercher les violations de signal.

Et du même coup, valider que CDM n'aille pas aux fraises après l'avertissement de la violation.

[CC72000]

J'avoue que je ne comprends pas pourquoi ce comportement n'est pas plus répétitif en simulation.

Voir mon post précédent, je pense que cela ne peut venir qu'en RUN à cause du décalage virtuel / réel.

En simulation, le calcul théorique est toujours bon, il ne peut pas être mis en défaut sauf si l'ordi fait des erreurs dans ses additions et multiplications
En dehors de la plaisanterie, dans ce cas purement théorique, je ne vois que des erreurs d'arrondis... mais je n'y crois pas beaucoup, et puis là, je ne sais où cela nous mène.

[midav91]

Bonjour Michel, bonjour Jean Pierre, (je ne suis pas un matinal ! )

Hier (enfin ce matin de très bonne heure, je vous disais que j'avais une simu de 2h1/2 sans viol, MAIS quand je suis retourné (avant de me coucher) la fermer par le bouton "arrêt de tous les trains au prochain signal" alors crac : viol de signal !!!!

(sur un nouveau train, mais sur un canton où c'était déjà arrivé au début)

Viol signal5.jpg (75.63 Kio) Consulté 860 fois

J'essaie avec l'exe de JP en simu ce matin

[jpp38]

J'avoue que je ne comprends pas pourquoi ce comportement n'est pas plus répétitif en simulation.

Voir mon post précédent, je pense que cela ne peut venir qu'en RUN à cause du décalage virtuel / réel.

En simulation, le calcul théorique est toujours bon, il ne peut pas être mis en défaut sauf si l'ordi fait des erreurs dans ses additions et multiplications
En dehors de la plaisanterie, dans ce cas purement théorique, je ne vois que des erreurs d'arrondis... mais je n'y crois pas beaucoup, et puis là, je ne sais où cela nous mène.

Relis bien les derniers messages de Michel: il parle de simu, pas de RUN.