defaut de commande de certain aiguillage en mode auto

Bonjour,

Faisant des essais de trajets, j'ai constaté que certains aiguillages (TJD notamment) ne sont pas commandés par TC : sur le TCO l'aiguillage reste dans sa position initiale . La représentation de l'aiguillage sur le TCO correspond bien a celle de l' aiguillage. le train part donc dans une mauvaise direction. ET elle ne correspond pas à l'itinéraire programmé dans le Dispatcher.

Ce qui est curieux c'est que :

- lorsque je fais des tests en simulation, la position de ces aiguillages sur le TCO est parfaitement modifiée.
- Lorsque je fais des tests en manuel sur le TCO de cet aiguillage non commandé en auto  répond bien et dans la direction demandée.
- j'ai allongé l'intervalle a 100ms dans la fenètre "digital system" sans effet sur le TCO

Ceci est très curieux : si le temps de réponse de l'aiguillage en question était trop long il serait possible de mon point de vue que l'aiguillage change de position après le passage du train, mais ce n'est pas le cas.

Existe t'il d'autre paramètre que je n'aurai pas découvert ? ( j'exclu en effet un bug).

Merci pour vos conseils.

jD3D

Ce sont toujours les mêmes aiguillages qui ne sont pas déviés, ou c'est aléatoire... ?

Il y a de mon point de vue un paramètre à prendre en compte... DR5000 ! Qui n'est pas supporté par TC... Je vais être accusé de faire du mauvais esprit !  

Mais tout de même, si TC commute au TCO la position des aiguillages lors de "l'établissement des trajets" (on ne parle pas de "mode auto" ! car il y a beaucoup de choses qui sont automatiques ou automatisées dans TC ! ), et que le moteur n'est pas actionné, le problème se situe : soit dans le moteur de l'aiguillage, soit dans le décodeur, soit dans la centrale, soit entre la centrale et le logiciel.

Essaye de passer l'intervalle à 200 ou 500 ms, et vois si c'est mieux. Je ne sais pas combien de moteurs sont commandés simultanément, mais avec 100 ms d'intervalle plus une commande d'une durée d'1' sur le décodeur, il se peut aussi que la pointe d'intensité dépasse sa capacité...

Bonjour,

Jd3d a écrit:

... Faisant des essais de trajets, j'ai constaté que certains aiguillages (TJD notamment) ne sont pas commandés par TC : sur le TCO l'aiguillage reste dans sa position initiale . La représentation de l'aiguillage sur le TCO correspond bien a celle de l' aiguillage. le train part donc dans une mauvaise direction. ET elle ne correspond pas à l'itinéraire programmé dans le Dispatcher.

Ce qui est curieux c'est que :

- lorsque je fais des tests en simulation, la position de ces aiguillages sur le TCO est parfaitement modifiée...

Si je comprends bien :
- Tu démarres un trajet en simulation : tout se passe passe bien (l'itinéraire se met en surbrillance, l'aiguillage bouge sur le TCO, le train démarre).
- Tu fais la même chose en réel : l'itinéraire se met en surbrillance ?, le train démarre mais l'aiguillage n'a pas bougé sur le TCO ?
A mon avis, ce n'est pas possible ... il y a un problème dans ta description (ou dans ma compréhension) du problème ...

A+
Georges

Bonjour la petite communauté,
Eh bien moi j'ai le même souci et voulais justement en faire cas ici. J'ai aussi essayé comme le propose Christophe d'allonger l'intervalle, jusqu'à 1000ms même, et c'est sans effet.... En cliquant sur l'aiguille elle réagit bien, mais sur 1 itinéraire en mode auto pas moyen. J'ai essayé aussi de mettre un marqueur d'action sur le parcours de ces itinéraires à fin d'agir sur l'aiguille mais c'est peine perdue car une grande partie de l'itinéraire VU est en section critique et une fois réservé les aiguilles sont bien sûr verrouillées. Pas de souci sur mes 80 autres aiguilles actionnées par des DR Digikeijs, mystère donc.
Merci pour vos lumières.

Bonsoir,

sergio 77 a écrit:

...  Pas de souci sur mes 80 autres aiguilles actionnées par des DR Digikeijs...

Dans ton cas, j'imagine que tout se passe bien en simulation et qu'avec le réseau connecté l'aiguille bouge bien (si besoin) sur le TCO ?
Pour l'aiguille qui ne bouge pas sur le réseau, c'est systématique ou aléatoire ?
As-tu essayé de changer de sortie (intervertir avec celle d'un aiguillage qui va bien par exemple) sur le décodeur d'accessoires voir de permuter avec un autre décodeur ?

A+
Georges

sergio 77 a écrit:

Pas de souci sur mes 80 autres aiguilles actionnées par des DR Digikeijs, mystère donc.
Merci pour vos lumières.

Bonsoir, s'il n'y a qu'une aiguille qui ne bouge pas TC n'est probablement pas en cause...
- Tu supprimes et recrée l'aiguille sur TC;
- tu permutes le branchement avec une aiguille qui fonctionne bien sur le décodeur d'aiguille;
- tu changes le moteur;
- tu changes l'aiguille.
Après tout ça, en général cela fonctionne...
A+

Bonsoir,

coquelicot94 a écrit:

... Après tout ça, en général cela fonctionne... ...

Moi, par sécurité, je reconstruirai le réseau autour de la nouvelle aiguille !...

A+
Georges

sergio 77 a écrit:

j'ai le même souci et voulais justement en faire cas ici. J'ai aussi essayé comme le propose Christophe d'allonger l'intervalle, jusqu'à 1000ms même, et c'est sans effet....  En cliquant sur l'aiguille elle réagit bien, mais sur 1 itinéraire en mode auto pas moyen.

Perso je n'ai jamais rencontré ce genre de souci d'aiguillage, mais parfois des situations similaires. Soit il s'agit d'un problème de décodeur, de détection, et l'inversion d'un élément défectueux avec un élément "valide" permet de déterminer l'origine du défaut.

Ensuite si on a pas obtenu de résultat probant, le mieux est effectivement de supprimer le point qui ne va pas. D'enregistrer le fichier purgé puis de recréer l'élément ...

Un truc aussi, l'arrêt complet du logiciel et le redémarrage de windows permet souvent de faire rentrer les choses dans l'ordre, comme pour les erreurs de calcul de points d'arrêt !

Bonjour la petite communauté,
Merci à Christophe et Coquelicot de vous pencher sur mon souci. Si j'ai un peu tardé à répondre c'est que j'ai essayé plusieurs alternatives et l'insomnie portant conseil, c'est vers 3h ce matin que j'ai enfin trouvé la solution à ces problèmes de trajets (et non d'itinéraires comme mentionné par erreur dans mon précédent message .
En fait ce qui empêchait l'aiguille d'être actionnée dans certains trajets c'était que l'ensemble du trajet était réservé dés que je l'enclenchait. L'aiguille (en plus Peco actionnée par des relais vu la conso importante de ces moteurs) n'avait pas le temps d'être activée physiquement alors qu'elle l'était virtuellement sur le TCO. J'ai décoché "canton critique" dans le canton précédent l'aiguille empêchant ainsi le réservation du canton où se trouve l'aiguille récalcitrante et tout est rentré en ordre. J'espère que je suis assez clair et que cela pourra aussi aider Jd3d dont le message est en haut de page.
Grand merci à nouveau à Christophe et Coquelicot d'avoir pris le temps de me répondre sans avoir tous les éléments sous les yeux n'est pas évident.....

Geo69 a écrit:

Bonsoir,

sergio 77 a écrit:

...  Pas de souci sur mes 80 autres aiguilles actionnées par des DR Digikeijs...

Dans ton cas, j'imagine que tout se passe bien en simulation et qu'avec le réseau connecté l'aiguille bouge bien (si besoin) sur le TCO ?
Pour l'aiguille qui ne bouge pas sur le réseau, c'est systématique ou aléatoire ?
As-tu essayé de changer de sortie (intervertir avec celle d'un aiguillage qui va bien par exemple) sur le décodeur d'accessoires voir de permuter avec un autre décodeur ?

A+
Georges

Réponses un peu tardive :
1)Oui tout se passe bien en simulation et l'aiguille bouge bien sur le TCO
2) c'est systématique
3)Oui bien sûr j'ai essayé d'intervertir avec un autre aiguillage, pas avec un autre décodeur mais une autre adresse.
Bonne journée

coquelicot94 a écrit:

sergio 77 a écrit:

Pas de souci sur mes 80 autres aiguilles actionnées par des DR Digikeijs, mystère donc.
Merci pour vos lumières.

Bonsoir, s'il n'y a qu'une aiguille qui ne bouge pas TC n'est probablement pas en cause...
- Tu supprimes et recrée l'aiguille sur TC;
- tu permutes le branchement avec une aiguille qui fonctionne bien sur le décodeur d'aiguille;
- tu changes le moteur;
- tu changes l'aiguille.
Après tout ça, en général cela fonctionne...
A+

Je n'ai changé ni l'aiguille ni le moteur ni l'ensemble du réseau mais j'ai essayé de modifier le TCO à fin de changer sa localisation sur le TCO et le Dispatcher des fois qu'il "manquerait une case" à ce logiciel

Bonjour, j'ai déjà eu des soucis similaires, TC est rarement en cause.
Certains moteurs ou aiguilles, ou les deux, réagissent moins vite pour de nombreuses raisons, ainsi sur mon réseau même hors TC, une simple impulsion ne suffit pas à faire bouger l’aiguille mais il faut faire un appuyé long.
- A ta place j'essaierai de résoudre le problème en me penchant sur le matériel...
A+

Bonjour,

coquelicot94 a écrit:

...  A ta place j'essaierai de résoudre le problème en me penchant sur le matériel...

T'inquiètes pas Marc, le problème de Sergio est résolu :

sergio 77 a écrit:

... c'est vers 3h ce matin que j'ai enfin trouvé la solution  ...

Reste le problème de Jd3d dont on a plus de nouvelle ...

A+
Georges

Geo69 a écrit:

T'inquiètes pas Marc, le problème de Sergio est résolu :

sergio 77 a écrit:

... c'est vers 3h ce matin que j'ai enfin trouvé la solution  ...

A+
Georges

Ah oui, et peut-on connaitre cette solution, si c'est pas trop lui demander:?:
A+

Bonjour,

coquelicot94 a écrit:

Ah oui, et peut-on connaitre cette solution, si c'est pas trop lui demander:?: ...

Marc, tu peux lire la solution quelques posts plus haut ... Allez, pour t'éviter des efforts pendant cette période estivale, je te fais un copie/coller :

sergio 77 a écrit:

... En fait ce qui empêchait l'aiguille d'être actionnée dans certains trajets c'était que l'ensemble du trajet était réservé dés que je l'enclenchait. L'aiguille (en plus Peco actionnée par des relais vu la conso importante de ces moteurs) n'avait pas le temps d'être activée physiquement alors qu'elle l'était virtuellement sur le TCO. J'ai décoché "canton critique" dans le canton précédent l'aiguille empêchant ainsi le réservation du canton où se trouve l'aiguille récalcitrante et tout est rentré en ordre...

A+
Georges

Woui depuis l'aiguille récalcitrante réagit désormais. Merci encore Georges, Coquelicot n'avait pas lu mon message avec la solution car j'ai envoyé 2 messages ensuite.
Belle soirée à vous deux

c'est bien ça, j'avais loupé deux cases...
A+

Bonjour a tous et merci pour vos suggestions.

J'ai refait des tests ce week end.

apparemment plus de problème sur la TJD qui avait le pb systématiquement : cela semblerait aléatoire.

Par contre j'ai récupéré un autre problème similaire sur un aiguillage : cette fois sur le TCO l'aiguillage est bien positionné, sur le dispatcher également mais la loco part tjrs dans la mauvaise direction donc l'aiguillage n'est pas commandé.

Bien sur commandé manuellement l'aiguillage fonctionne bien.

Je me pose la question pour comprendre a quoi servent les temps de commutation des aiguilles , puisqu'on les retrouve au niveau :

- du paramètrage du port loconet : intervalle d'envoi et intervalle ....
- de l'aiguillage lui même avec le paramètre temps,
- de l'itinéraire avec le paramètre : délai entre aiguillages.

Tout ceci me parait redondant et la doc RRTC n'est pas très précise sur ce sujet.

Pour bien comprendre, l'idéal serait d'avoir un chronogramme qui décrit précisément comment s’enchaînent ces temps lorsqu'on commande un aiguillage ou deux successivement, en auto, et notamment avec des moteurs a déplacement lent comme les Cobalt digital IP. et l'impact avec le passage de loco sur l'aiguille....

En tout cas ceci me parait remettre en cause la fiabilité du logiciel !....

Merci pour vos retours

Joel

Bonjour, la fiabilité du logiciel est très rarement en cause...
- les paramétrages possibles sont nombreux, c'est ce qui fait l'attrait de TC pour essayer de répondre aux besoins les plus divers  
A+

Jd3d a écrit:

Pour bien comprendre, l'idéal serait d'avoir un chronogramme qui décrit précisément comment s’enchaînent ces temps lorsqu'on commande un aiguillage ou deux successivement, en auto, et notamment avec des moteurs a déplacement lent comme les Cobalt digital IP. et l'impact avec le passage de loco sur l'aiguille....

En tout cas ceci me parait remettre en cause la fiabilité du logiciel !

Je ne suis pas un spécialiste de l'informatique et ne je saurais pas "décortiquer" la programmation dans TC. Mais ton propos me parait... à côté !

Certes je ne mets pas en cause la réalité de tes soucis. Mais !
Tu es le seul à les rencontrer...

Autrement dit, le logiciel ne serait pas en situation de faire fonctionner ton réseau, alors que chez tout le monde... ça marche !
Le problème se situe sur ton réseau.

Ou peut-être dans l'utilisation que tu fais de TC... Une question, que veux tu dire précisément par "en auto", ça n'existe pas dans le vocabulaire de TC, on ne connait que le lancement de trajet, pour lesquels TC commute les aiguillages, avec ou sans délai comme on veut, puis fait démarrer le train.
Quel rapport fais tu entre, mouvement de la loco, et mouvement de l'aiguillage. Que je sache, il n'y en a aucun ! Nous utilisons tous des moteurs lents... et nos réseaux fonctionnent !

Je me demande si tu n'as pas "conditionné" abusivement ton trajet et dans ce cas tu obtiendrais, si c'est bien le cas, des effets de bord aberrants.

Bonjour,

Jd3d a écrit:

... Par contre j'ai récupéré un autre problème similaire sur un aiguillage : cette fois sur le TCO l'aiguillage est bien positionné, sur le dispatcher également mais la loco part tjrs dans la mauvaise direction donc l'aiguillage n'est pas commandé...

En tout cas ceci me parait remettre en cause la fiabilité du logiciel !....

Je trouve ta conclusion pour le moins hâtive !... Si tu trouves un logiciel plus fiable, tiens nous au courant ...  
Jusqu'à preuve du contraire, en connexion avec le(s) système(s) numérique(s), si TC "bouge" un aiguillage sur le TCO il envoi la commande au système numérique concerné ... Par contre, pour que l'aiguille bouge physiquement, il faut :
- Que la centrale envoi l'ordre  DCC au décodeur d'accessoires.
- Que le décodeur d'accessoires reconnaisse l'ordre et le transforme en commande électrique au moteur.
- Que le moteur recoive les bonnes impulsions électriques
Les différents délais dans le logiciel sont là justement pour faire face, à différents niveaux, à des "contraintes" hardware. Mais tout ne peux pas être résolu par le logiciel ...
J'ai cherché pendant 2 ans des problèmes d'aiguilles non faites de façon aléatoire (j'avais même fait une trace pour vérifier que TC envoyait bien l'ordre à la centrale). Le problème se situait entre le décodeur d'accessoires et les moteurs d'aiguilles (environ 1 fois sur 20). J'ai résolu le problème en changeant de décodeurs d'accessoires ...  

A+
Georges

Jd3d a écrit:

Par contre j'ai récupéré un autre problème similaire sur un aiguillage : cette fois sur le TCO l'aiguillage est bien positionné, sur le dispatcher également mais la loco part tjrs dans la mauvaise direction donc l'aiguillage n'est pas commandé

Bon là, le coup de la loco qui part dans la "mauvaise" direction, on l'a tous eu ! En fait elle part dans la direction que tu as demandée à TC.

Plusieurs solutions pour obtenir le sens désiré :
Inverse la sur les rails et elle partira dans la direction souhaitée.
Ajoute 1 à la CV29 et sans la retourner elle partira dans la direction souhaitée.
Et encore inverse la dans TC et elle partira dans la direction souhaitée !

Mais le rapport avec l'aiguillage... il n'y en a pas. Encore une fois lors du lancement du trajet TC commande les aiguillages sans ordre apparent pour ce que j'observe, et ensuite démarre le train...



Une anecdote, au début j'utilisais une centrale Massoth, pour laquelle il n'y a pas de champ d'intervalle d'envoi. TC traçait les itinéraires avec une belle régularité et même logique. L'aiguillage 1 en premier, le 4 en deuxième etc. De mon point de vue !

Quand je suis passé à centrale Lenz, je n'ai pas rempli le champ intervalle d'envoi... et la centrale a splitté ! Bonne fille elle a tout simplement commuté tous les aiguillages en même temps. Et comme un moteur d'aiguillage LGB grimpe à 2,5 A pendant 1 seconde... Forcément ça dépassait la capacité de la centrale. J'ai donc ajouté 500 ms...
J'ignorais qu'avec la centrale MAssoth, TC envoyait le "paquet" d'infos, et que la centrale ordonnait et espaçait ensuite d'1" les commandes de son propre chef !
Et depuis tout va bien, mais je constate que "l'aiguillage 1" n'est pas forcément le premier mis en mouvement. Mais ça n'a pas d'importance.

Bonjour,

Jd3d a écrit:

... Je me pose la question pour comprendre a quoi servent les temps de commutation des aiguilles , puisqu'on les retrouve au niveau :

- du paramètrage du port loconet : intervalle d'envoi et intervalle ....
- de l'aiguillage lui même avec le paramètre temps,
- de l'itinéraire avec le paramètre : délai entre aiguillages.

Les explications se trouvent dans l'aide contextuelle (F1) lors du paramétrage de chacun des objets.

Pour un système numérique:

"Intervalle d'envoi:
Dans certaines configurations (par exemple l'ancien système Marklin 6050 ou Lionel TrainMaster), chaque commande envoyée au système numérique doit être séparée des autres par une fraction de seconde. Sinon, les signaux se mélangent sur la ligne série et aucune action n'est déclenchée ou le système ne répond plus. Entrer une valeur supérieure à 0 dans ce cas.
La valeur saisie est interprétée en millisecondes.
Pour le système Marklin 6050, la valeur 80 donne de bons résultats dans la plupart des cas, mais une valeur supérieure peut être nécessaire.  
Pour Lionel TrainMaster le valeur 600 est recommandée.

Intervalle Aiguillage:
Dans quelques configurations, les commandes d'aiguillages envoyées au système numérique doivent être séparées entre elles de quelques fractions de secondes. Si on ne le fait pas, les aiguillages ne sont pas actionnés correctement. Dans ce cas, entrer une valeur supérieure à 0.
La valeur saisie est interprétée en millisecondes."

"Pour un itinéraire :

Délai entre aiguillages:
On peut spécifier ici, un délai (en millisecondes) qui sera inséré entre les commandes envoyées aux aiguillages de l'itinéraire. Cette option peut être utilisée pour empêcher le logiciel d'envoyer des commandes trop rapprochées aux différents aiguillages de l'itinéraire."

"Pour un aiguillage :

Temps connex.:
Indiquer la durée de la procédure de connexion en millisecondes. Accroître cette valeur si l'aiguillage ou le signal ne fonctionne pas correctement avec la durée par défaut."

Perso, avec ma configuration (dont 1 Cobalt), j'ai laissé les défauts partout (100ms au niveau des itinéraires  et 0 ailleurs) ...

A+
Georges

Bonjour,

Christophe a écrit:

... Bon là, le coup de la loco qui part dans la "mauvaise" direction, on l'a tous eu ! .

Je ne pense pas que la loco de jd3d parte dans le mauvais sens mais plutôt qu'elle n'emprunte pas l'itinéraire voulu puisqu'une  aiguille n'a pas "bougée" ???

A+
Georges