Aiguille non faite avec Roco Z21

Bonjour à tous,

Je viens de m’équiper d’une centrale Roco Z21 XL pour remplacer une Zimo MX1 et je rencontre un problème d’aiguille non faite.
De manière aléatoire une aiguille est non faite physiquement alors que sur le TCO elle est correctement positionnée. Cela survient lorsqu’il y a établissement d’un itinéraire impliquant 3 aiguilles. Aléatoire sur le réseau et indépendant de la charge.

Avec la Zimo j’avais eu ce problème insoluble malgré un « intervalle aiguillage » jusqu’à 1500 ms.
La trace des échanges entre la centrale et TC montrait que TC envoyait bien les ordres mais qu’à un moment la centrale en refusait un en répondant « busy ». Problème soumis à Zimo qui avait répondu « fin de maintenance » et à Freiwald qui lui disait ne pas savoir ce que cette réponse signifiait, l’ignorait et bien sûr ne voulait pas faire une modif pour réemettre l’ordre. Conséquence achat centrale SPROG dédiée au pilotage des aiguilles et je n’ai jamais plus eu de soucis avec un intervalle de 50 ms.

Avec la Z21 je suis monté progressivement jusqu’à 200 ms et avec un seul train actif le problème se produit. N’ayant pas envie de tester indéfiniment j’aimerais savoir si certains ont rencontré ce problème et comment ils l’ont éventuellement résolu.

Autre interrogation : dans la configurations des systèmes numériques il y a 2 paramètres concernant les intervalles. Que signifie celui libellé « intervalle d’envoi » ?  Je l’ai laissé à 0 ne connaissant pas son impact. Je subodore que c’est un intervalle concernant tous les ordres, indistinctement, qui sont envoyés à la centrale. Si c’est le cas, en l’augmentant cela va réduire le débit et forcément il y a une limite. Mais cela peut, peut-être, éviter un potentiel conflit type « busy ». Y a t-il des retours d’expériences avant de me lancer à jouer avec ?

A+

Bonjour,
Utilisateur de Z21 (pas XL) je n'ai jamais rencontré ce type de problémes.
Quels décodeurs utilises tu pour commander les moteurs d'aiguilles et quel type sont ils?
Quel est le mode raccordement de la Z21 à l'ordi?

Claude

Bonjour Claude,

Les aiguilles sont pilotées par des servos commandés par des SwitchPilot ESU. Le raccordement en sortie de la Z21 se fait sur voie principale qui ensuite se divise en 2, bus traction et bus accessoires.
Mais j'ai tendance à écarter un problème de config matérielle niveau câblage et décodeurs compte tenu de mes déboires passé.
Qu'as-tu comme paramètres d'intervalle ?

A+

Alain

Voila ma config de la Z21:


C'est celle par défaut.
Pour les branchements c'est comme toi.
Claude

Moi aussi j'ai les paramètres par défaut sur la Z21. Mais je vais vérifier par rapport aux tiens.
Ce qui m'intéresse ce sont les 2 paramètres intervalle que l'on renseigne dans la configuration des systèmes numériques dans TC "intervalle d'envoi" et "intervalle aiguillage". J'ai respectivement 0 et 200.

A+

Alain

Bonjour,
J'avais eu le même problème mais avec la multicentrale de roco et TC V7. Pour corriger ce défaut j'avais mis 200ms dans l'intervalle d'envoi. Depuis je suis passé sur la Z21 et TC V10 et je suis a 0 en intervalle d'envoi et 200 pour les aiguilles mais mon expérience avec cette configuration est nouvelle donc peut etre qu'avec du recul je mettrai 200 dans l'intervalle d'envoi aussi.

Larist a écrit:

Moi aussi j'ai les paramètres par défaut sur la Z21. Mais je vais vérifier par rapport aux tiens.
Ce qui m'intéresse ce sont les 2 paramètres intervalle que l'on renseigne dans la configuration des systèmes numériques dans TC "intervalle d'envoi" et "intervalle aiguillage". J'ai respectivement 0 et 200.
A+
Alain

Tu peux déjà mettre 100ms dans "intervalle d'envoi" sans conséquence fâcheuse.
Sinon, si le problème survient toujours sur le même moteur d'aiguille, essaie de permuter la sortie décodeur avec celle d'un autre moteur qui fonctionne correctement.
Si le problème persiste sur le même moteur, il faut mettre en cause le moteur ou l'aiguille.
Si le problème est déplacé avec la sortie décodeur, essaie de changer l'adresse du décodeur et, bien sûr, celle des moteurs raccordés à ce décodeur, au TCO.
Autre possibilité : un mauvais contact au niveau de la (ou des, si rallonge) prise(s) de commande du servo... insidieusement, au niveau du sertissage d'un contact sur son fil...

Claude j’ai le même paramétrage que le tien.
Elie le problème ne se produit jamais avec la même aiguille, c’est complètement aléatoire. Et quand je reviens avec le SPROG plus de problème.

Je rapproche ce type d’incident d’un autre que j’ai depuis longtemps : de temps en temps j’ai un train qui ne s’arrête jamais, roulant sur sa vitesse de seuil. Dans ce cas soit TC n’a pas envoyé l’ordre d’arrêt, soit c’est la centrale qui ne l’a pas fait. Je rapproche cela du constat fait avec la Zimo qui refusait certains ordres, répondant à TC qu’elle était saturée et TC n’en tenait pas compte. La Z21 étant d’origine Zimo, je pencherais pour le même problème.

Je vais donc essayer de modifier « intervalle d’envoi ». Et je pense qu’augmenter « intervalle aiguillage » n’est d’aucune utilité dans ce défaut, ce paramètre étant là pour éviter qu’un décodeur d’aiguilles ne reçoive trop rapidement des ordres consécutifs.

A+

Alain

Bonjour,
La capture d'écran de TC pour les deux paramétres:


J'avais eu le même problème avec des LS 150, virés et remplacés par des décodeurs LDT.

Bien qu'utilisateurs de Switch pilot servos je n'ai pas le recul car c'est pour un réseau en construction.

Et en cherchant si Railcom ne perturberait pas les messages?

Claude

Larist a écrit:

Elie le problème ne se produit jamais avec la même aiguille, c’est complètement aléatoire. Et quand je reviens avec le SPROG plus de problème.
A+
Alain

Ben déjà, tu as la solution au problème... conserve le Sprog en second système numérique pour la commande des aiguilles... ça ne gêne en rien l'utilisation de la Z21 pour le reste et je pense que c'est même mieux...
J'utilise personnellement une centrale différente pour les accessoires et la rétro et ça fonctionne bien.

J’ai fait différents essais en incrémentant progressivement l’intervalle d’envoi jusqu’à 200 et 400 pour les aiguillages mais rien n’y fait, toujours des ratés d’aiguillages au-delà d’une certaine charge (que je ne sais pas quantifier, au moins 6 trains en mouvement).

Ras le pompon je reviens au SPROG pour les aiguillages et là avec 50 ms aucun problème.

Sur le forum officiel il y a plusieurs topics sur le sujet. Freiwald soutient que la Z21 est trop rapide et envoie en rafale les ordres vers les décodeurs qui n’arrivent pas à suivre c’est pourquoi il faut mettre un délai. Certains tcistes ont résolu le problème en augmentant ce délai, d’autres non et ont fait comme moi.

Je suis enclin à penser que TC ne traite pas un ordre de rejet de la centrale sur certains ordres comme je l’avais tracé et mis en évidence avec ma précédente centrale Zimo.

A+

Alain

Bonjour à tous,

J'ai eu le même problème avec une centrale LZV100 et un switchpilot servo
l'itinéraire concerné, une zone d'aiguille toujours la même  , aiguillage triple, TJD, TJD
le problème survenait toujours sur la TJD du milieu
je précise que je dispose de deux centrales LZV100 , une affectée à la circulation, et l'autre dédiée exclusivement aux aiguillages, ce n'est donc pas un problème de charge
le paramétrage n'a rien changé au problème
j'ai changé de switch pilot, et avec les mêmes paramétrages le défaut a disparu !
aller comprendre

J’ai tracé les échanges entre TC et la Z21. Il en ressort que TC fonctionne correctement et que la Z21 a des ratés. Ma présomption précédente envers TC était donc non fondée.

Un ordre de bascule d’un aiguillage entraîne 4 échanges :

1- TC envoie l’ordre (adresse et position) en précisant que c’est une activation
2- Z21 répond aussitôt à TC (sous 1 ms environ)  que c’est pris en compte en rappelant l’adresse et la position
3- Z21 confirme quelques ms plus tard en envoyant à nouveau exactement le même message de bonne prise en compte
4- TC envoie un ordre de désactivation x ms plus tard

L’ordre de désactivation est obligatoire et destiné à couper les moteurs d’aiguillages à base de solénoïde. Il doit impérativement être présent avant tout nouvel ordre d’activation d’un autre aiguillage.

Constat sur mon réseau : un aiguillage non fait en moins de 2 minutes. TC a envoyé l’ordre qui a bien été acquitté par la Z21 selon schéma des 4 échanges. A priori ils ont tous 2 fait leur boulot. Mais je n’ai pas de « sniffer DCC » pour regarder ce qui se balade sur les rails. Qu’a donc fait la Z21 ? Elle a très probablement bouffé l’ordre car à chaque session ça se termine ainsi alors qu’avec le SPROG pour piloter les aiguillages je n’ai jamais eu une seule perte depuis plusieurs années.

J’ai cherché à comprendre si une surcharge temporaire avait pu perturber, mais rien d’anormal. Le trafic entre TC et Z21 est très majoritairement constitué d’ordres de vitesse loco et dans le cas présent il n’y avait aucune surcharge. On peut même penser que la capacité de travail de la Z21 est loin d’être atteinte car elle répond systématiquement à TC sous 1 à 2 ms maxi (souvent moins de 1 ms) alors que les ordres qu’elle reçoit arrivent tous les 10 ms au grand maxi quand le trafic est au plus haut (environ 10 à 15 locos actives).

Dans la doc ROCO sur le protocole d’échange avec un logiciel PC, le chapitre sur les ordres d’aiguillages indique qu’à partir d’une certaine version la philosophie a évoluée. A partir de la V1.24 (03/2014) il est proposé de confier à la Z21 la mise en file d’attente des ordres d’aiguillages et de s’affranchir de l’ordre impératif « activation-désactivation » d’un même aiguillage avant un nouvel ordre. Désormais les ordres d’activation peuvent arriver avant les désactivations d’ordres précédents et les ordres de désactivation ne sont plus obligatoires. Cette nouvelle technique doit être demandée par TC … qui ne l’a pas implémentée (à la connexion TC demande à la Z21 son état qui lui renvoie tout un tas de paramètres dont la version firmware). Solutionnerait-elle le problème ? Je vais essayer de sonder Freiwald.

Remarques qui valent quelle que soit la centrale :
- dans la fenêtre de configuration des systèmes numériques l’intervalle d’envoi des ordres par TC est respecté quel que soit l’ordre à envoyer
- point important : l’intervalle entre 2 envois d’ordre d’aiguillage court après l’envoi de l’ordre de désactivation de l’ordre précédent. Lequel ordre de désactivation se déclenche un certain temps après l’activation. Il est fixé par le paramètre « temps » dans l’onglet « connexion » de chaque aiguillage. Attention par défaut il est à 0 mais TC impose 80 ms. Si on met une autre valeur elle est prise en compte mais TC ne descendra jamais sous 10 ms.
Donc si vous avez 50 ms entre 2 envois d’aiguillages et 0 dans « temps »  de vos aiguillages, le délai entre 2 ordres sera de 80 + 50 =130 ms

Je voulais simplifier ma config en me passant du SPROG, c’est raté. Le numérique c’est bluffant quand ça fonctionne mais ça reste quand même un assemblage perfectible.

A+

Alain

Bonjour,
J'ai eu aussi ce genre de problème mais chez moi cela était du à des courts circuits furtifs lors du passages de certaines locos sur des cœurs d'aiguillage isolés. Certaines marques (TRIX, REE) me font ce genre de court circuit. Si l'ordre est envoyé pendant ce CC furtif c'est donc un échec.
Depuis j'ai séparé la traction sur une z21 qui ne fait que ça et tous le reste (accessoires, signalisations, retro signalisation) est fait par une Z21.
Le fait de ne ne confier au SPROG que la commande des aiguillages permet donc de s'affranchir de tous les soucis du à la traction.

Bonjour,

philippech a écrit:

Le fait de ne ne confier au SPROG que la commande des aiguillages permet donc de s'affranchir de tous les soucis du à la traction.

Oui c'est la solution qui est utilisée depuis environs 20 ans sur les grands réseaux.

philippech a écrit:

Si l'ordre est envoyé pendant ce CC furtif c'est donc un échec.

Si on utilise des décodeurs d'accessoires DCC/Motorola j'ai eu mis en oeuvre une autre solution qui consiste à utiliser un booster dédié. Ainsi le signal n'est pas perturbé par les courts-circuits du circuit traction. Dans cette configuration il est aussi important de pouvoir configurer le Booster pour qu'il ne propage pas le court-circuit à la centrale, ce qui n'est pas le cas de tout les systèmes numériques mais dans mon cas les ECoSBoost de ESU ont cette option.

philippech a écrit:

Si l'ordre est envoyé pendant ce CC furtif c'est donc un échec.

Comment as-tu détecté cela ?

La doc Roco cite un exemple en listant la répétition des ordres DCC suite à une commande de basculement d’un aiguillage. Il y a environ 14 envois du même ordre DCC pour un basculement. Ce qui n’est pas indiqué c’est l’intervalle d’envoi. La durée d’un CC furtif peut-elle couvrir la durée de transmission des 14 ordres ?

Séparer ou pas traction et accessoires, il y a des avantages et inconvénients dans les 2 mais le chacun chez soi l’emporte sur le plan de la fiabilité. Dommage pour la simplicité.

A+

Alain

Bonjour,

Larist a écrit:

La doc Roco cite un exemple en listant la répétition des ordres DCC suite à une commande de basculement d’un aiguillage. Il y a environ 14 envois du même ordre DCC pour un basculement.

Les centrales ne se comportent pas toutes de la même manière car la norme DCC n'indique rien pour cela.
Le seul moyen pour un décodeur DCC de renvoyer un ordre de quittance est le RailCom et très peu de décodeurs d'accessoires le font.

Bonsoir Alain,

je ne peux qu'abonder dans le sens d'Elie, Philippech et Yann (dans l'ordre alphabétique). N'oublions pas que nos commandes numériques terminent toujours en signaux analogiques, avec la complexité induite.

Les court-circuits ne sont remontés à la centrale (ou pas, suivant la configuration) qu'après un délai significatif (1,5 seconde pour mon ECoS et mes LDT DB-2). On peut donc avoir un court circuit très bref qui viendra écraser le ou les ordres destinés aux aiguilles, sans que la centrale puisse le détecter.

Personnellement, j'ai mis en œuvre depuis 15 ans (pour des raisons un peu différentes à l'époque) la solution proposée par Yann, à savoir un booster séparé, et ne puis que m'en féliciter.

C'est probablement le prix à payer pour un fonctionnement fiable, au détriment, certes, de la simplicité.

Bonne soirée à tous,
Nicolas

Ah oui Nicolas, je n'avais pas percuté sur la solution de Yann avec un booster mais effectivement c'est aussi une solution alternative à une 2ème centrale.

Maintenant est-ce que mes problèmes viennent de CC ou autres interférences sur le bus traction ou d'une gestion disons perfectible dans la Z21? Dans le doute je vais revenir à la solution bus séparés qui m'a toujours donné satisfaction sur le plan fiabilité. Ce qui me gêne le plus avec le SPROG c'est sa gestion en port COM sous Windows avec des aléas qui nécessitent quelquefois de redémarrer le PC (parfois 2 à 3 fois de suite) alors qu'avec la Z21 il n'y a jamais de soucis de ce côté là.

A+

Alain

Larist a écrit:

philippech a écrit:

Si l'ordre est envoyé pendant ce CC furtif c'est donc un échec.

Comment as-tu détecté cela ?



Alain

Je n'ai pas de mesure pour affirmer mais constat fait suite à différentes observations. Le défaut se produisant toujours en concomitance quand une machine (CC40110 TRIX) était en roulement sur le réseau.
On peut voir les étincelles au niveau des roues lors du passage sur les cœurs, et les feux de la machine ont le temps de d'éteindre.
En terme de durée, pas facile à estimer, car comme l'indique Nicolas en plus du temps réel du CC, il faut ajouter le comportement de la centrale pour la détection et pour le retour.
A la louche entre la perception du flash sur les roues et le temps d'extinction des feux, je dirais de l'ordre de 300ms.
Si on considère en gros que la fréquence du DCC est 5 khz, on doit pouvoir calculer le temps nécessaire pour envoyer 14 paquets DCC. Je ne sais pas combien de bit comporte un paquet DCC.

J'ai donc acheté une "petite" z21 pour la traction et depuis tout marche beaucoup mieux y compris la rétrosignalisation via loconet qui devait aussi  perturber la centrale  sur son port Loconet par ces CC furtif. L'avantage des centrales avec un port LAN avec TC, c'est vraiment simple à mettre en œuvre, on branche le RJ45, on donne l'adresse IP et ça marche; pas besoin d'interface ou de port com

Bonjour,
Il me semble que dans vos suppositions, vous oubliez les récepteurs...!?
J'ai vu des décodeurs d'accessoires qui supportaient mal une adresse, le simple fait d'en changer faisait disparaitre le défaut récurrent...
Il arrive aussi que 2 ordres quasi simultanés arrivant sur un même décodeur lui fasse perdre la tête...

Merci Philippe pour cette réponse. Cela pourrait aussi expliquer que des ordres de vitesse de loco soient aussi perdus comme un roulage sans fin à vitesse de seuil. Pour contrer cela dans TC je renforce l’ordre d’arrêt pour chaque loco en le répétant une fois. J’ai mis un ordre d’arrêt loco déclenché au bout de 2 secondes après survenance d’un arrêt programmé par TC. Cela n’engendre pas une boucle infinie et pour l’instant je n’ai pas constaté d’ennui.

A+

Alain

Bonjour Elie,

Je ne le pense pas car dans mon cas les décodeurs sont des SwitchPilot qui supportaient un cadencement des ordres tous les 50 ms avec le SPROG sans aucune défaillance pendant longtemps alors que d’un coup passer à la Z21 avec des essais jusqu’à un intervalle de 400 ms ne le faisait plus et sur des décodeurs différents à chaque fois. Et revenir au SPROG fonctionne à nouveau.

A+

Alain

Larist a écrit:

Bonjour Elie,

Je ne le pense pas car dans mon cas les décodeurs sont des SwitchPilot qui supportaient un cadencement des ordres tous les 50 ms avec le SPROG sans aucune défaillance pendant longtemps alors que d’un coup passer à la Z21 avec des essais jusqu’à un intervalle de 400 ms ne le faisait plus et sur des décodeurs différents à chaque fois. Et revenir au SPROG fonctionne à nouveau.
A+
Alain

Il faut donc considérer que le problème vient d'une différence de traitement des signaux entre le Sprog et la Z21... je ne suis pas loin de penser qu'il s'agit du RailCom qui impose une constitution différente des paquets DCC.
As-tu la possibilité de supprimer le RailCom sur la Z21 ?

Elie j'ai désactivé RailCom depuis le départ.

A+

Alain