délais de tansmission des commandes

Bonsoir à tous,
Après une longue période de travail exclusivement en simulation j'ai pu mettre en service les parties restaurées de mon réseau démontable (parties centrale et de droite du TCO ci-après).


Tout semblait marcher parfaitement (les essais en simulation hors ligne correspondant bien aux essais en réel) lorsque j'ai constaté certains retards aléatoires dans le déclenchement des signaux sur le réseau physique.
En multipliant les tests j'ai constaté que la manœuvre des aiguilles ou la commande d'allumage de feux de locomotive pouvaient également être retardées. Je précise que j'ai vérifié qu'au TCO les déclenchements étaient toujours immédiats (comme en simulation) et de même en commande directe par la centrale.
Comme c'est aléatoire je soupçonne que le flux des informations qui remonte à la centrale est parfois long. Pour autant la taille de mon réseau et les équipements en service sont modestes quand je les compare aux réalisations présentées dans notre forum.
Certains ont-ils déjà rencontré une telle situation? Je ne vois pas sur quoi agir (logiciel, décodeurs - CDF-, ordinateur - VAIO W8, ...).
Merci de votre aide.

W8 n'était pas renommé pour sa stabilité, me semble-t-il...
Ton problème doit effectivement venir d'une communication quelque peu déficiente au niveau de la connexion PC --> centrale.
En tous cas, la seule fois où j'ai rencontré ce type de problème, cela venait de là, et était du à une mauvaise communication de la part de la centrale avec le PC, mais là, avec une Ecos2, c'est pratiquement exclu... à moins d'un souci de câble ou de prise, tout simplement...

Merci Elie de ta réponse si rapide (comme toujours...) De toute façon mon ordi portable de 7 ans arrive en bout de course. Pour tester la piste de la prise J 45, je vais déplacer mon ordi de bureau (w10) pour essayer. A suivre.

Bonsoir,
les essais avec un ordi puissant et en pleine forme ainsi qu'un nouveau câble n'ont strictement rien changé. Les délais de manœuvre des aiguilles, de l'allumage/extinction des feux de locos sont notablement allongés lorsqu'il y a de la circulation. Sur le TCO les commandes sont toujours immédiates.
J'ai également essayé de faire rouler avec l'ensemble des signaux non alimentés, mais aucun changement.
Ces exercice m'ont simplement permis de valider la permanence et l'importance du défaut et que le problème de flux viendrait donc seulement de la centrale. Je précise que les commandes effectuées directement de la centrales sont toujours immédiates.
En l'état ce phénomène va m'empêcher de faire rouler les trains pendant les fêtes car rien de pire qu'un déraillement pour une aiguille non manœuvrée à temps.
Je suis preneur de toute idée, merci d'avance.

Bonsoir,

Est-ce qu'en manipulant un aiguillage depuis le pupitre TCO ou une locomotive depuis une fenêtre de train des retards similaires apparaissent?
Comment est relié la connexion entre l'ECoS et le PC?
Il faudrait peut-être faire un tour dans les paramètres de Windows et voir les softs installés et supprimer tout ce qui n'est plus utilisé.
N'aurriez-vous pas un anti-virus qui tourne en tâche de fond...

Quelle est l'utilité des nombreux tableaux affichés au TCO ?

Bonsoir Yann,

Yann a écrit:

Est-ce qu'en manipulant un aiguillage depuis le pupitre TCO ou une locomotive depuis une fenêtre de train des retards similaires apparaissent?

Oui et j'ai essayé dans une multitude de configurations (manipulations diverses d'aiguillages et/ou allumages/extinctions de lumières pendant des trajets ou des pilotages depuis une fenêtre de train).

Yann a écrit:

Comment est relié la connexion entre l'ECoS et le PC?

Par le serveur DFCP (adresse IP manuelle).
Avec un ordi portable sony VAIO sous W8 (normalement utilisé) utilisation d'un câble croisé.
Lors de l'essai avec l'ordi de bureau plus puissant sous W10, utilisation d'un câble standard.

Yann a écrit:

Il faudrait peut-être faire un tour dans les paramètres de Windows et voir les softs installés et supprimer tout ce qui n'est plus utilisé.

J'entends la piste mais je ne sais pas faire.  

Yann a écrit:

N'aurriez-vous pas un anti-virus qui tourne en tâche de fond...

J'utilise "Advanced System Care Pro". J'ai fait un essai de roulage en coupant le maximum des opérations et je n'ai constaté aucun changement. J'hésite à faire un essai après l'avoir désinstallé car l'ordi ne sert pas qu'au train.
Comme vous le voyez je suis loin d'être un expert informatique mais j'ai le sentiment que la difficulté intervient après l'ordi, la centrale ne "digérant" pas le flux en temps réel.
Merci pour votre intérêt

Le firmware de ton Ecos est-il à jour ?
Les problèmes ont-ils été présents dès que tu as commencé à exploiter le réseau en réel ?
Si non :
As-tu réfléchi à ce que tu aurais pu modifier juste avant d'avoir les problèmes ?

Bonjour,

Pascal 92 a écrit:

Par le serveur DFCP (adresse IP manuelle).

Ah non c'est soit le serveur DHCP qui attribue une adresse IP automatiquement (ce que je déconseillerais pour un système numérique) ou alors une IP entrée manuellement dans les paramètres de l'ECoS.

Pascal 92 a écrit:

Yann a écrit:

Il faudrait peut-être faire un tour dans les paramètres de Windows et voir les softs installés et supprimer tout ce qui n'est plus utilisé.

J'entends la piste mais je ne sais pas faire.

Sous Win10 aller dans le menu Windows puis cliquer sur l'engrenage et puis "Applications".

Pascal 92 a écrit:

J'utilise "Advanced System Care Pro".

Alors commencez par le supprimer, Freiwald l'as dit maintes fois que ce genre de logiciel pouvait perturber le bon fonctionnement de TrainController.

Combien de fenêtre de Train avez-vous d'ouverte simultanément? Souvent les utilisateurs à chaque fois qu'ils veulent piloter une locomotive ouvrent une nouvelle fenêtre de train car la précédente a été cachées par une fenêtre de TCO ou autre, résultat plus de 50 fenêtres de train ouverte simultanément! Ceci prend des ressources à TrainController car il doit rafraîchir l'affichage de toutes ces fenêtres même si elles ne sont pas visible par l'utilisateur. C'est une des raison de l'ajout de l'entrée Fenêtre > Fenêtre de train > Fermer toutes les fenêtres de Train.

Merci Elie et Yann pour votre aide,

DiCoS69 a écrit:

Quelle est l'utilité des nombreux tableaux affichés au TCO ?

Cinq tableaux contiennent les boutons poussoirs qui permettent d'enclencher des circulations (séquences de trajets reliant les gares, séquences "scénario de circulation", etc.) Le sixième suit le niveau d'occupation.

DiCoS69 a écrit:

Le firmware de ton Ecos est-il à jour ?

j'ai vérifié et je suis toujours bien à jour (v4.2.8 installée il a quelques mois grâce au tuto que Yann a mis en ligne)

DiCoS69 a écrit:

Les problèmes ont-ils été présents dès que tu as commencé à exploiter le réseau en réel ? As-tu réfléchi à ce que tu aurais pu modifier juste avant d'avoir les problèmes ?

Je précise que j'ai réassemblé ce réseau (démontable) à l'issue d'une longue période de travaux portant sur tous les modules avec notamment des adaptations de câblage de certains cantons et l'installation des signaux, décodeurs et câblages liés. Les tests ont confirmé point par point que tout ce qui marchait en simulation marchait également en réel et donc que tout était correctement câblé et programmé (ECOS et TC). Ce n'est qu'avant hier que j'ai recommencé à exploiter et que j'ai constaté ces décalages.

Yann a écrit:

c'est soit le serveur DHCP qui attribue une adresse IP automatiquement (ce que je déconseillerais pour un système numérique) ou alors une IP entrée manuellement dans les paramètres de l'ECoS. .

en effet c'est bien DHCP que je voulais écrire et ma configuration est la suivante:

Yann a écrit:

Il faudrait peut-être faire un tour dans les paramètres de Windows et voir les softs installés et supprimer tout ce qui n'est plus utilisé.

J'ai mal interprété dans ma réponse le sens de "soft", mais j'avais bien procédé à ce tour dans Windows8 qui est installé sur l'ordi portable qui sert notamment pour TC. L'usage de l'autre ordi sous W10 était ponctuel et avait pour seul but d'écarter des hypothèses suite au 1er message d'Elie.

Yann a écrit:

Pascal 92 a écrit:

J'utilise "Advanced System Care Pro".

Alors commencez par le supprimer, Freiwald l'as dit maintes fois que ce genre de logiciel pouvait perturber le bon fonctionnement de TrainController.

Message reçu. Je vais tester après avoir désinstallé. A terme il faudra que je consacre un ordi dédié àTC et hors le web, comme certains le font sur ce forum. La motivation sera  totale si une fois désinstallé TC fonctionne normalement...

Yann a écrit:

Combien de fenêtre de Train avez-vous d'ouverte simultanément? Souvent les utilisateurs à chaque fois qu'ils veulent piloter une locomotive ouvrent une nouvelle fenêtre de train car la précédente a été cachées par une fenêtre de TCO ou autre, résultat plus de 50 fenêtres de train ouverte simultanément! Ceci prend des ressources à TrainController car il doit rafraîchir l'affichage de toutes ces fenêtres même si elles ne sont pas visible par l'utilisateur. C'est une des raison de l'ajout de l'entrée Fenêtre > Fenêtre de train > Fermer toutes les fenêtres de Train.

Non je n'en ai pas tant mais seulement celles nécessaires aux circulations, soit actuellement 4 maxi.

Merci encore et à suivre

Yann a écrit:

Pascal 92 a écrit:

J'utilise "Advanced System Care Pro".

Alors commencez par le supprimer, Freiwald l'as dit maintes fois que ce genre de logiciel pouvait perturber le bon fonctionnement de TrainController.

Suppression faite et strictement aucun changement. Il me faut donc encore chercher une autre cause.

Il arrive parfois qu'un fichier .yrrg soit corrompu.
La solution dans ce cas, est de reprendre un fichier antérieur sauvegardé, et de repartir dessus.
Si tu en possèdes un rangé dans le dossier : "Documents"/ "Railroad & Co"/ "TrainController", il serait bien de faire un essai avec.

Pascal 92 a écrit:

Yann a écrit:

Pascal 92 a écrit:

J'utilise "Advanced System Care Pro".

Alors commencez par le supprimer, Freiwald l'as dit maintes fois que ce genre de logiciel pouvait perturber le bon fonctionnement de TrainController.

Suppression faite et strictement aucun changement. Il me faut donc encore chercher une autre cause.

Suppression ou désinstallation...?!
Il faut absolument "désinstaller"...!

Désolé Elie pour mon imprécision: pour retirer une application, en effet je désinstalle toujours.
J'ai déjà essayé avec une version antérieure, avec le même résultat. Cependant cette version était relativement récente et comme je dispose par ailleurs de toutes les sauvegardes effectuées à chaque étape depuis le début du projet, je vais faire demain des essais en remontant le temps.

DiCoS69 a écrit:

Il arrive parfois qu'un fichier .yrrg soit corrompu.
La solution dans ce cas, est de reprendre un fichier antérieur sauvegardé, et de repartir dessus.

Bonjour Elie,
bingo!
Il a fallu que je remonte assez loin dans mes copies de sauvegarde pour identifier une copie qui tournait mais ne permettait pas de déplacer un train (changement de canton attribué). Et en en utilisant la copie précédente les délais de transmission ont disparu.
Cela veut dire que depuis, j'ai longtemps continué à développer des nouvelles données sur un fichier corrompu que j'utilisai sans problème en simulation. A 2 reprises depuis le début de mon projet j'ai rencontré un pb de fichier corrompu, mais même en simulation je m'en suis rendu compte immédiatement et j'ai repris le précédent.
Il me reste à décider à partir de quel fichier antérieur j'entre à nouveau mes données pour m'assurer que tout le travail n'est pas fait à nouveau pour rien. Il faudrait pouvoir disposer d'un système de contrôle de fichier qui..., selon mes recherches sur internet, n'existe pas.
Ma seule satisfaction c'est d'être récompensé de sauvegarder systématiquement et fréquemment une copie du fichier (en notant les travaux exécutés) et de tout archiver. Je recommande cette pratique qui ne coûte pas de place sur un disque, compte tenu du volume d'un fichier. Pour info je la pratique de longue date en montage vidéo, mais là il faut être sélectif car les volumes sont importants.
Merci à toi et à Yann pour l'aide apportée.

Il va falloir faire des essais chaque fois que tu auras fait des modifications importantes... ce sont parfois celles-ci qui engendrent la corruption.
Quand on modifie notamment des valeurs dimensionnelles au niveau des marqueurs de ralentissement et d'arrêt, sur des signaleurs, des délais, des macros, il est souhaitable d'enregistrer en fermant TC, et pour finir en fermant Windows ou en faisant un redémarrage.

DiCoS69 a écrit:

Je n'ai parlé nul part de modifications "SANS ENREGISTRER"... au contraire, certaines modifications comme celles que j'ai citées, ne sont pas toujours prises en compte en cliquant seulement sur "enregistrer", il est nécessaire de fermer TC pour les voir effectivement appliquées. Il peut donc arriver qu'un essai immédiat après modification de données, ne donne pas satisfaction... par sécurité, il vaut donc mieux ne pas tester des modifications conséquentes, sans avoir effectué une fermeture préalable de TC.

Bonjour,

J'ai en effet dans une situation vu ce comportement mais c'était à l'époque de la version 8. C'était dans la modification des groupes de véhicules. J'en avais parlé à Freiwald et il m'avait dit que c'était une cache interne de TrainController qui n'était pas mise à jour et que du coup il fallait fermer le logiciel et le réouvrir pour que ça prenne effet. La version suivante de TC avait résolu le problème.

Merci de vos retours.
je peux comprendre (difficilement tout de même  :| )  que l'enregistrement de modification ne fasse pas un "REFRESH" automatique de la session et que donc, certaines modifications ne soient pas effectives sans devoir "rebooter" TC.
mais ce "problème" semble résolu dans la V9 selon Yann.

ce qui me "chagrine" un peu, c'est le fait qu'un fichier puisse être corrompu simplement par des modifications appliquées via l'interface.
cela m'est arrivé au début de mes tests, lors de la personnalisation du TCO. j'avais modifié pas mal de propriétés : couleurs de voie / d'itinéraires /etc. et me suis retrouvé dans l'impossibilité de revenir en arrière par l'action du bouton "DEFAUT". après un échange avec Jean, il s'est avéré que le fichier était bien corrompu. :|

bref... vive les sauvegardes du projet fréquentes !!!

La seule vraie question qui vaille est "pourquoi les sauvegardes ne sont pas automatiques... ?"
Nous sommes en 2021... 22