Intervalle entre aiguillages

DiCoS69 a écrit:

Il y a pourtant un délai par défaut de 2 sec. avant le départ du train... qui est d'ailleurs modifiable dans les règles du trajet... et qui peut également être ajusté par un temps d'attente (en temps accéléré) dans le canton de départ...

Avec les deux secondes basiques... le train part avant que le feu ne passe à voie libre pour peu qu'il y ait 5 ou 6 aiguillages à commuter !

Christophe a écrit:

Avec les deux secondes basiques... le train part avant que le feu ne passe à voie libre pour peu qu'il y ait 5 ou 6 aiguillages à commuter !

Tout à fait vrai, même en augmentant le délai dans les règles du trajet ca ne change rien.
Mais je n'ai pas essayé au départ du canton. A voir.

A+

Alain

Larist a écrit:

...
Donc dès que TC doit gérer des trajets et des itinéraires il perd des basculements.

Je vais faire un compte rendu pour Freiwald.

D'après ton message précédent, le basculement au TCO est fait, mais pas sur le réseau. J'aurais donc tendance à penser que le logiciel ne perd rien du tout.

Si c'est TC, c'est à dire le logiciel, qui perd des basculements, comme tu l'affirmes, j'en déduis que le phénomène doit être reproductible sur un autre réseau avec un autre système numérique.

J'ai donc reproduit les tests sur mon réseau, avec 6 trajets lancés simultanément soit 11 aiguillages à mettre en place pour les itinéraires.

Je ne perds rien du tout, les aiguillages sont corrects sur le TCO et sont faits sur le réseau (PC sous W7, Intellibox I, convertisseur série USB entre PC et centrale).

J'en déduis donc que sur ton réseau, c'est la centrale qui se mord la queue et oublie de transmettre des ordres.

J'ai bien peur que la réponse de Freiwald soit peu éloignée de la mienne.

Jean

Bonjour,

Je prends le train en marche , mais lorsque j'avais fait quelques essais de TC avec mon matériel Zimo par liaison RS232, j'avais constaté de temps à autres ce genre de problèmes sur mon petit réseau d'essais, cela a participé d'ailleurs à ce que j'abandonne Zimo au profit de Lenz...

Jean_01 a écrit:

J'aurais donc tendance à penser que le logiciel ne perd rien du tout.

TC ne perd rien dans son processus de décision mais quid dans son process de transmission à la centrale ?

Bon comme je semble être le seul j'ai effectivement un doute.

Lors de tous mes tests je me suis arrangé pour avoir toujours les mêmes infos transmises à la centrale, et rien que cela, dans un scénario ou TC est le maître et la centrale l'esclave.
Le maître ne semble pas avoir la même procédure pour effectuer le même travail selon l'origine de la demande. Et sur l'une de ces procédures la centrale peut effectivement défaillir et pas sur l'autre.

Mon raisonnement bute sur l'incapacité à tracer ce qui s'échange physiquement.

Jean_01 a écrit:

J'ai bien peur que la réponse de Freiwald soit peu éloignée de la mienne.

Moi aussi j'ai bien peur que tu ais raison.

A+

Alain

kvb a écrit:

Bonjour,

Je prends le train en marche

Le comble pour un conducteur...

Me voici de retour après 2 mois d'absence. 

J'ai eu un échange avec Freiwald pour lui faire part de mes observations sur les pertes de basculement d'aiguillage à savoir :
- Trajets et itinéraires qui s'établissent en mêmes temps : tout est ok à 500 ms d'intervalle et vitesse mini de la liaison avec la centrale de 9600 bps
- trajets dans un 1er temps puis établissement des itinéraires en décalé : ok avec 400 ms et 9600 bps
- uniquement le basculement de tous les aiguillages avec un seul bouton poussoir : ok avec 200 ms et 4800 bps

Ce constat ne le fait pas réagir plus que ça. Au contraire il admet que les actions de TC peuvent être variables en durée selon les circonstances et à chacun de s'y adapter. A t-il cherché à évacuer le problème  

Je m'attendais à ce qu'il mette en cause la centrale, eh bien non .

Je ne suis pas plus avancé et vais en rester là jusqu'à la sortie de la prochaine centrale Lenz (rien n'a l'air de bouger de ce côté là)

A+

Alain

Bonjour à tous,
Cela fait bien longtemps que je n'ai pas pris le temps de revenir sur le forum ... Et ce matin, je suis venu voir ce qui s'y était dit depuis. Sur le présent fil, je prends donc moi aussi le train en marche. Je n'ai pas tout lu en détail mais, d'emblée, ça me rappelle le fil que j'avais ouvert en janvier et que Jean avait sagement clôturé en juin :
https://traincontroller.forum-actif.net/t2011-probleme-lors-de-l-execution-simultanee-de-2-trajets
Du coup, je vais regarder ça de plus près ...

Larist a écrit:

Me voici de retour après 2 mois d'absence. 

J'ai eu un échange avec Freiwald pour lui faire part de mes observations sur les pertes de basculement d'aiguillage à savoir :
- Trajets et itinéraires qui s'établissent en mêmes temps : tout est ok à 500 ms d'intervalle et vitesse mini de la liaison avec la centrale de 9600 bps
- trajets dans un 1er temps puis établissement des itinéraires en décalé : ok avec 400 ms et 9600 bps
- uniquement le basculement de tous les aiguillages avec un seul bouton poussoir : ok avec 200 ms et 4800 bps

Ce constat ne le fait pas réagir plus que ça. Au contraire il admet que les actions de TC peuvent être variables en durée selon les circonstances et à chacun de s'y adapter. A t-il cherché à évacuer le problème  

Je m'attendais à ce qu'il mette en cause la centrale, eh bien non .

Je ne suis pas plus avancé et vais en rester là jusqu'à la sortie de la prochaine centrale Lenz (rien n'a l'air de bouger de ce côté là)

A+

Alain

Je viens de trouver sur le forum que Larist avait un problème similaire avec sa centrale Zimo que moi avec une roco

Le réseau utilise une centrale Roco Multicentrale Pro ref  10786, des décodeurs aiguilles CDF et des moteurs Tortoise.

J’ai un souci, principalement, avec la commande des aiguilles.

De façon récurrente lorsque TC lance un trajet et envoie donc les commandes au aiguilles par l’intermédiaire des décodeurs cdf, le moteur n’est pas activé et l’aiguille reste dans la position initiale alors que pour TC celle ci a bougé.
Résultat, le train démarre et se plante sur le cœur de l’aiguille ou part dans la mauvaise direction.

Précision, les décodeurs d’aiguilles CDF ont leur propre alimentation auxiliaire.

Je pense que les décodeurs CDF ne sont pas en cause car en parallèle à ce problème j’ai des erreurs sur la signalisation avec les décodeurs « Elie » qui ressemblent beaucoup à mon problème d’aiguilles non actionnées.
Parfois quand tc calcule au tco un état pour un signal, sur le réseau le signal ne change pas et il faut que j’actionne plusieurs fois « actualiser le réseau » pour que le feu change d’état.

Je soupçonne donc que TC envoie bien l’info pour actionner l’aiguille ou changer l’état du signal via l’interface USB mais que la centrale, elle ne répercute pas l’info sur le signal Dcc dans le rail.

J’ai , sur les conseils de Mr Thomas de CDF , réglé dans la centrale le codage de la vitesse des loco sur 28 crans seulement, afin de limiter la quantité d’infos qu’a à transmettre la centrale et tenter de la soulager.

J’ai placé dans la section « configuration des systèmes numériques » un intervalle aiguillage de 100.

mais c'est vrai que je ne suispas monté jusqu'à 500 ou 600.

et mes soucis arrivent parfois qd il y a seulement une aiguille à bouger dans l'itinéraire.

Malgré cela , le problème demeure.

Dans le fil, je vois que en Lenz et en Zimo au moins vous êtes capables de régler la vitesse de transmission entre TC et la centrale, avec la roco je ne sais ou intervenir pour régler ce paramètre.

bonjour, j'ai déjà eu les mêmes problèmes, je ne sais toujours pas si c'est la centrale qui est en cause  souvent ce sont les mêmes aiguilles qui ne fonctionnent pas et d'autres fonctionnent toujours, ce qui permet de penser que c'est un problème mécanique d'aiguille ou de moteur d'aiguille, voire de connectique  

- pour éliminer le maximum de dysfonctionnement avant de lancer une grande séquence, je manœuvre chaque aiguille dans les deux sens (manuellement ou avec l'aide d'une macro).

- mon intervalle est à 200, en 128 crans, mais le 100% n'est pas systématique... je n'ai rien vu sur la possibilité d'agir sur la vitesse de transmission  

A+

J'ai eu parfois des commandes d'aiguillage qui ont mis deux secondes à activer. Je mets cela sur le compte de mon PC qui a je pense effectué une tache autre pendant ce temps. Donc dorénavent je coupe la liaison wifi, et depuis pas de problème.

Eh eh d'où vient la Z21 ?  ... de chez ZIMO.

Ceci dit j'ai retravaillé sur le pb des aiguilles qui ne basculent pas et mon opinion a évolué. Je ne suis plus aussi certain de la responsabilité de la centrale. Car basculer 9 aiguilles en rafale se passe bien hors trajet si intervalle de 200ms mais si inclus dans un trajet il faut 500ms. Et Freiwald ne trouve pas cela anormal.

Fildemer incrémente l'intervalle par pas de 100 pour trouver le bon réglage. Tu n'y couperas pas.

A+

Alain

coquelicot94 a écrit:

bonjour, j'ai déjà eu les mêmes problèmes, je ne sais toujours pas si c'est la centrale qui est en cause  souvent ce sont les mêmes aiguilles qui ne fonctionnent pas et d'autres fonctionnent toujours, ce qui permet de penser que c'est un problème mécanique d'aiguille ou de moteur d'aiguille, voire de connectique  

- pour éliminer le maximum de dysfonctionnement avant de lancer une grande séquence, je manœuvre chaque aiguille dans les deux sens (manuellement ou avec l'aide d'une macro).

- mon intervalle est à 200, en 128 crans, mais le 100% n'est pas systématique... je n'ai rien vu sur la possibilité d'agir sur la vitesse de transmission  

A+

bonsoir et merci pour cette réponse.

chez moi ce ne sont pas toujours les mêmes aiguilles qui sont "oubliées" , de plus à chaque fois que j'actionne ensuite l'aiguille oubliée , soit à partir du tco, soit directement sur une des multimaus, le moteur est mis en action et l'aiguille change de position.

ceci me fait penser que le problème n'est pas à chercher du coté : moteur/aiguille mais en amont.

je retiens ce qu'a dit Elie un peu plus haut : seules les commandes envoyées aux décodeurs type locos sont répétées en dcc, les commandes vers les décodeurs d'aiguilles ne le sont pas.

Pour ce qui est des intervalles pour les aiguilles : je suppose que l'on parle, pour un itinéraire comprtant par exemple 3 aiguilles,  du laps de temps entre l'envoi dans le signal dcc de la commande pour l'aiguille N, et l'envoi de la commande  N+1 , puis du laps de temps entre la commande n+1 et N+2 ?

ais je bien compris ? ou suis je à coté de la plaque ?

je viens de lire le message de Alain et je vais suivre son conseil.

N'ayant pas poussé mes tests jusqu'à des valeurs de 400 ou 500ms je vais de toutes façons essayer cette solution là, même si parallèlement je ne peux avec l'interface intégrée à ma centrale roco avoir accès à un réglage de la vitesse de connexion ( puisque au vu des tests de Larist il y aurait une interaction entre ces deux paramètres)

Richard-Joel a écrit:

J'ai eu parfois des commandes d'aiguillage qui ont mis deux secondes à activer. Je mets cela sur le compte de mon PC qui a je pense effectué une tache autre pendant ce temps. Donc dorénavent je coupe la liaison wifi, et depuis pas de problème.

bonsoir joël ! tu dis "parfois des commandes qui..." est ce rare ou assez récurrent ?

chez moi c'est quand même , peut être toute les 10 minutes en expo avec un trafic soutenu.

fildemer a écrit:

...
chez moi ce ne sont pas toujours les mêmes aiguilles qui sont "oubliées" , de plus à chaque fois que j'actionne ensuite l'aiguille oubliée , soit à partir du tco, soit directement sur une des multimaus, le moteur est mis en action et l'aiguille change de position.

Ces observations sont tout à fait normales.

Ce n'est pas la même aiguille qui est concernée car TC n'actionne pas toujours dans le même ordre les aiguilles du même itinéraire. Pour un itinéraire contenant les aiguilles A1, A2, A3 visibles dans cet ordre, soit de gauche à droite soit de bas en haut,TC les actionnera une fois dans cet ordre peut être, et le coup d'après A3, A1, A2.

Il y a des dizaines d'interventions dans ce sens dans le forum de Freiwald où il a indiqué qu'on ne peut absolument pas fixer une priorité de déclenchement des aiguilles dans TC ni essayer de mettre des conditions se fondant sur l'ordre des aiguilles dans un itinéraire.

C'est ainsi depuis que je connais TC    

Jean

fildemer a écrit:

Pour ce qui est des intervalles pour les aiguilles : je suppose que l'on parle, pour un itinéraire comprtant par exemple 3 aiguilles,  du laps de temps entre l'envoi dans le signal dcc de la commande pour l'aiguille N, et l'envoi de la commande  N+1 , puis du laps de temps entre la commande n+1 et N+2 ?

ais je bien compris ?

Oui sous réserve que l'ordre est aléatoire comme l'indique Jean. Donc 3 aiguilles avec 500 ms, la dernière basculera au bout d'une seconde (0 +500 +500)

A+

Alain

Mes problèmes sont résolus, mise de tempo sur certains aiguillages (alimentation moteur peco), vérification de bonne mise en place des aiguilles (problèmes mécaniques), et tension d'alimentation a bien dimensionner.

Bonjour,

fildemer a écrit:

... Je pense que les décodeurs CDF ne sont pas en cause car en parallèle à ce problème j’ai des erreurs sur la signalisation avec les décodeurs « Elie » qui ressemblent beaucoup à mon problème d’aiguilles non actionnées.
Parfois quand tc calcule au tco un état pour un signal, sur le réseau le signal ne change pas et il faut que j’actionne plusieurs fois « actualiser le réseau » pour que le feu change d’état...

Pour les commandes d'aiguillages, il y a beaucoup de paramètres qui entrent en jeu (nombre d'aiguilles sur le ou les itinéraires, type de moteurs pour manoeuvrer les aiguilles, alim de ces moteurs, type de décodeurs) mais pour les signaux avec les décodeurs d'Elie, je comprends moins ... Ceux-ci sont alimentés et reçoivent les commandes par le courant DCC  pour alimenter des leds ... Perso, j'ai 22 signaux qui sont physiquement "synchros" avec le TCO. Malheureusement je ne peux pas plus t'aider sur ton problème de liaison TC/centrale/"voie" mais je ne vois pas ce que le paramètre "intervalle aiguillages" peut améliorer pour les signaux ? Peut-être améliorer le traitement et l'envoi des commandes DCC dans la centrale ...

A+
Georges

Bonjour.
J'utilise des Tortoises avec des Switchpilot's ESU et des interfaces "façon Italienne" le tout piloté par une vielle Ecos N&B, pas à jour du tout, je n'ai jamais rencontré ce genre de problème. L'intervalle est réglé à 100, et suivant les itinéraires jusqu'à 7 aiguilles sont basculées, même en réduisant l'intervalle, pas de problème. Pas de problème non plus avec les décodeurs d'Elie.

Nous ne connaissons pas le type de PC utilisé par "fildemer", mais c'est peut être une piste.
Les décodeurs CDF, je ne connais pas, mais il ne faut éliminer aucun piste, donc peut être faire un essai avec un autre type de décodeur.

J'utilise du matériel divers (et avariés!) que ce soit du côté PC que du côté DCC. Je n'ai jamais constaté de défaut de ce genre. Tous mes décodeurs sont des LDT et de Elie pour la signalisation.

Le seul constat, c'est le délai qui augmente quand la charge de la centrale est élevée. C'est surtout visible sur la signalisation qui passe au carré avec une petite seconde de retard.

Mon témoignage vaut ce qu'il vaut, je n'ai jamais eu un défaut d'aiguillage depuis 4 ans ! D'autres soucis oui ! Mais pas celui là. Sur la configuration de la centrale, le champ intervalle entre aiguillages est à 0 ". Sur le réseau, les aiguillages sont commutés avec un intervalle d'1" environ. Généralement dans l'ordre de l'établissement de l'itinéraire, le signal étant commuté... quand TC y pense ! Des fois il tarde, surtout pour la fermeture après le passage du train...

Voilà voilà...

Moi, j'ai viré la première moitié de mes moteurs Péco (qui commençaient à m'énerver) pour les remplacer par des Conrad. J'ai fait ce choix parce que je n'ai pas eu a modifier le câblage et j'ai conservé mes LS 150. Je n'ai rien modifié à la programmation tant au niveau des décodeurs qu'au niveau de TC. C'est nickel, et quel silence appréciable. Il ne me reste plus qu'à changer les dix autres!.
Seul bémol, on a du mal à bloquer la tige de réglage sur le levier de commande au risque de foirer la vis. Peut-être serait-il prudent de solidariser ces deux éléments à l'époxy quand tout est bien calé

Bonsoir,
Suite à des problèmes avec des moteurs d'aiguilles Lemaco et Fulgurex entrainés par des M-DEC,
le manque de fiabilité de ces moteurs m'a conduit à les remplacer par des Tortoises nettement plus fiables et plus silencieux.
Lors des essais des Tortoises connectés sur les MS-DC (avec la centrale hors TC) j'ai constaté que je devais maintenir l'appui sur la commande de l'aiguille branché sur la sortie 3 du M-DC et de plus le fonctionnement sur cette sortie 3 reste assez aléatoire , le moteur n'est pas en cause car il fonctionne parfaitement sur une autre sortie.
Le même problème se reproduit sur deux modules M-DEC
La commande par TC sur ces sorties 3 ne se fait pas.
Quand à la cause du problème je l'ignore, une possibilité serait que le module M-DEC ne déclenche la tempo sur la sortie 3 mais pourquoi?
Par chance je n'utilise que 3 sorties sur chaque module, mais...
Pour les prochaines aiguilles je vais prendre des LS 150 (qui permettent de commander 6 sorties et semblent offrir des possibilités de réglage et sont en boitiers) ou bien des LS 100.
Ce problème a des ressemblances avec ceux rencontrés par d'autres, c'est pour cela que je l'ai décrit.
Claude

Pour Momo, tu peux y aller, la vis des Conrad elle est solide!

Je verrai bien avec le temps, pour le moment je touche plus rien.