Intervalle entre aiguillages

Il est vrai qu"au début j'ai souvent resserré cette p----n de vis, mais maintenant, elle ne bouge plus.

Capitole a écrit:

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.

Le type de PC ? c'est le pc du club,il tourne sous windows XP, pour le reste il va falloir que je me renseigne.

Étant en déplacement pour le boulot je ne pourrais regarder cela et faire des tests que vers le 10 dec...

mais je suis le conseil et je testerais avec mon mac émulant le PC, pour voir!

merci à vous tous pour ces infos et remarques.

fildemer a écrit:

Étant en déplacement pour le boulot je ne pourrais regarder cela et faire des tests que vers le 10 dec...

mais je suis le conseil et je testerais avec mon mac émulant le PC, pour voir!

merci à vous tous pour ces infos et remarques.

bonjour à tous!

j'ai repris des tests en modifiant le réglage "intervalle aiguillage" et en le portant à 500 et cela semble avoir résolu le problème, même avec 5 trains tournant tous plus ou moins en même temps aucune aiguille "oubliée" pour le moment.

merci pour vos conseils.

Bjr à tous ,
pour Claude1

J'ai eu soucis avec mes LS100 + moteurs péco, je l'ai grillait les uns apres les autres donc à éviter
je m'en suis sorti après réparation en les alimentant avec un vieux transfo jouef et ça ne grille plus
mais à éviter!!
sur mon new réseau en cours je passe en Conrad + LS100 qui posent moins de soucis d'après ce forum.

Cordialement
J.Dominique

J'ai fini par mettre le doigt sur l'origine de mes problèmes d'aiguillages qui ne se font pas de temps en temps sauf à mettre un "intervalle d'aiguillage" élevé dans la configuration du système numérique.

J'ai tracé ce qui s'échange sur le port COM et constaté que TC envoie bien les bons ordres à la centrale. Mais que celle ci reçoit à un moment précis une rafale de commandes diverses (autres que aiguillages) venant de TC et s'en trouve probablement saturée. Car elle répond à la commande d'aiguillage qui suit cette rafale qu'elle est occupée et n'a pas pu la traiter. Et TC ignorant ce code retour ne réémet pas la commande mais passe aux suivantes.

D'où le délai entre aiguillage qui sert à absorber la rafale de commandes diverses. J'ai du monter à 700 ms pour le basculement sans erreur de 16 aiguillages sur le déclenchement de 4 trajets en sortie de gares cachées.

Je vais faire un courriel à Freiwald avec les traces.
En tout cas centrale et interface USB-série sont hors de cause.

A+

Alain

Bonsoir,

Super intéressant, Alain. Merci pour ce retour ...    Cela confirme mon intuition pour des symptômes identiques. J'ai l'intention de faire des tests de basculements d'aiguillages sur mon réseau sans et avec charge DCC. Tu utilises quel logiciel pour tracer le port COM ?

A+
Georges

Geo69 a écrit:

Tu utilises quel logiciel pour tracer le port COM ?

J'utilise Portmon que l'on trouve sur un site de Microsoft (je n'ai plus la ref mais Google a de la mémoire). Mais il ne fonctionne que sous XP. Facile à utiliser. juste prévoir de fermer toutes les applis avant de le lancer.
Dans ton cas il va être nécessaire de connaître le protocole de Lenz et t'armer de patience car les traces sont en hexadécimal et la volumétrie grimpe vite. Pour me soulager le travail j'ai importé les traces sous Excel et fait des sélections avec des fonctions logiques de recherche de caractères. J'ai ainsi isolé les commandes d'aiguillages avec les adresses.

Ce que je crains c'est que la gestion des erreurs soit inexistante dans TC car difficile à programmer. Ainsi l'octet d'erreur que j'ai relevé peut prendre 10 valeurs différentes qui sont autant de cas à traiter. De plus il faut avoir stocké le message origine, l'identifier parmis ses semblables, lui donner un traitement adéquat par exemple dans le cas présent le réemettre un nombre limité de fois (sinon ca boucle) et avec un intervalle à calculer. La gestion des erreurs dans une transmission c'est vite complexe et il faut l'avoir intégré lors de la conception.

J'ai soumis le problème à Freiwald, mais je ne suis pas très optimiste.

A+

Alain

Bonoir,

Merci Alain pour ta réponse ... Avant de me lancer dans l'étude du protocole Xpressnet de Lenz (!), je ferai déjà des essais en fonction de la charge ... Je crains aussi que tu ais mis le doigt sur le problème de non ou mauvaise prise en compte des erreurs entre TC et centrale(s). Reste à voir si c'est le cas pour toutes les centrales ... Selon la réponse de Freiwald pour Zimo, tu pourras peut-être lui poser la question ? ...

A+
Georges

Geo69 a écrit:

Reste à voir si c'est le cas pour toutes les centrales ... Selon la réponse de Freiwald pour Zimo, tu pourras peut-être lui poser la question ?

Bonsoir Georges,

Pas de problème.    

S'il est coopératif, j'ai l'intention de le sonder sur la gestion des erreurs en général. Car j'ai aussi constaté des anomalies du genre : un train à la vitesse de seuil qui ne s'arrête jamais (rare).

A tout hasard, pour ceux que ca intéresserait, voici ma méthode pour déterminer la bonne valeur de l'intervalle :
- définir un max de trajets qui vont chevaucher un max d'aiguillages. Ne pas couvrir tout le réseau non plus. Il faut imaginer le max de trajets qui peuvent se déclencher simultanément dans un fonctionnement normal du réseau.
- pour chaque trajet mettre un délai au départ à 999 pour que le train ne parte jamais.
- mettre une loco sur chaque canton de départ
- positionner tous les aiguillages dans la position inverse nécessaire à chaque trajet
- définir un bouton poussoir qui déclenche tous les trajets.
- Je met l'intervalle à 100 ms
- j'appuie sur le bouton poussoir
- quand c'est fini je vérifie si tous les aiguillages ont basculé. Pour cela depuis le TCO je repositionne chaque aiguillage un par un dans son état d'avant et j'écoute le bruit. S'il n'y a aucun bruit ca veut dire que l'aiguillage n'a pas été basculé lors de l'établissement du trajet et donc qu'il faut recommencer le test en incrémentant l'intervalle.

A+

Alain

Ta recherche est effectivement très méthodique, mais me semble assez vaine.
La vitesse de transmission du DCC est relativement lente et les échanges TC/centrale aussi (je note 9600 bauds avec une centrale Tams à 200€), donc je vois mal une centrale Zimo ne pas parvenir à transmettre les ordres en temps voulu. Évidemment, un PC ça va plus vite que les doigts sur des touches, mais quand même...
Mon réseau d'essai n'est pas très grand, mais il arrive fréquemment que 3 ou 4 aiguilles se fassent dans la seconde au départ de plusieurs trajets.
J'ai un temps d'intervalle 0 et en plus, la centrale assure la rétro en S88.

Je vois que tu utilises un convertisseur USB/série, le problème ne viendrait-il pas de là...?
Qu'utilises-tu comme décodeur pour tes moteurs d'aiguilles et quels sont-ils ?

Christophe a écrit:

le signal étant commuté... quand TC y pense ! Des fois il tarde, surtout pour la fermeture après le passage du train...

Voilà voilà...

Bien que ce que tu dis là pourrait être imputé à la commutation plutôt qu'au relâchement... je te rappelle que les modules de rétro fournis sont retardés au relâchement (1 à 2 sec.), donc, les cantons contrôlés par ces modules n'ont pas besoin de temporisation dans l'onglet "mémoire" des indicateurs...

Bonjour,

DiCoS69 a écrit:

... je vois mal une centrale Zimo ne pas parvenir à transmettre les ordres en temps voulu. Évidemment, un PC ça va plus vite que les doigts sur des touches, mais quand même...

Oui Elie, mais si Alain a bien décortiquer la trace du port COM, sa centrale émet quand même un code erreur ... En principe dans un protocole de communication, des cas d'erreurs sont prévus par le récepteur afin que l'émetteur puisse réémettre ... Ici il ne s'agit pas du protocole DCC mais du protocole de communication entre le logiciel du PC et la centrale qui encapsule le DCC (Xpressnet pour Lenz par exemple). Ceci étant, le non traitement d'un message par la centrale (cela peut-être suite à un simple contrôle de parité) qui la conduit à émettre un code d'erreur peut effectivement venir d'un mauvais fonctionnement de l'interface PC/centrale ...

A+
Georges

DiCoS69 a écrit:

Christophe a écrit:

le signal étant commuté... quand TC y pense ! Des fois il tarde, surtout pour la fermeture après le passage du train...

Voilà voilà...

Bien que ce que tu dis là pourrait être imputé à la commutation plutôt qu'au relâchement... je te rappelle que les modules de rétro fournis sont retardés au relâchement (1 à 2 sec.), donc, les cantons contrôlés par ces modules n'ont pas besoin de temporisation dans l'onglet "mémoire" des indicateurs...

Élie, quand j'indique que parfois TC tarde à refermer le signal, ce n'est pas lié au relâchement de la zone d'occupation. C'est juste le logiciel qui doit être occupé ailleurs à ce moment là... et semble finir le chantier plus tard !
Mais ça n'a pas d'incidence sur la gestion du trafic.

DiCoS69 a écrit:

Mon réseau d'essai n'est pas très grand, mais il arrive fréquemment que 3 ou 4 aiguilles se fassent dans la seconde au départ de plusieurs trajets.
J'ai un temps d'intervalle 0 et en plus, la centrale assure la rétro en S88

Quand un ou deux aiguillages ne se font pas, ce sont toujours ceux qui sont traités juste derrière la rafale envoyée par TC à la centrale. Les autres fonctionnent toujours très bien, y compris quand je mets l'intervalle à 100 (je n'ai pas essayé à 0). Donc la centrale a une puissance normale. Toutefois on peut émettre l'idée qu'elle supporte mal la rafale. Mais on ne peut lui reprocher puisqu'elle en informe TC

DiCoS69 a écrit:

je vois mal une centrale Zimo ne pas parvenir à transmettre les ordres en temps voulu.

C'est aussi ce que je me dis. Pourquoi sature t-elle ? Et sature t-elle vraiment ? Il faudrait que j'explore les ordres qu'elle reçoit en rafale pour mieux cerner le problème, mais j'avoue qu'il y a du boulot. Si j'ai du courage je m'y collerai.
Il y a aussi une solution de riche : acheter une petite centrale uniquement pour piloter les accessoires.

DiCoS69 a écrit:

Je vois que tu utilises un convertisseur USB/série, le problème ne viendrait-il pas de là...?

Non car j'ai fait un test avec un PC en W7 avec interface série et le comportement est le même.

DiCoS69 a écrit:

Qu'utilises-tu comme décodeur pour tes moteurs d'aiguilles et quels sont-ils ?

Ce sont des SwitchPilot servo. Les servos sont tout ce qu'il y a de plus basique.
Sur un réseau de test j'avais déjà observé ce phénomène avec un SwitchPilot pilotant des moteurs Fulgurex et CDF.

A+

Alain

Larist a écrit:

Il y a aussi une solution de riche : acheter une petite centrale uniquement pour piloter les accessoires.

Cela suppose aussi que tu doubles ton bus traction car on ne peut pas mélanger les signaux de deux centrales sur un même bus.

Jean

Jean_01 a écrit:

Cela suppose aussi que tu doubles ton bus traction car on ne peut pas mélanger les signaux de deux centrales sur un même bus.

Exact.    
C'est ce que j'ai fait sur le réseau en construction.

Freiwald vient de me répondre qu'il prenait ma remarque en compte et qu'il développerait une correction si c'est possible et nécessaire après plus d'investigation.

A+

Alain

Bonjour Alain,

La lecture de ce fil m'inspire l'idée de diagnostic suivant. Je vous en livre le cheminement :

Selon la norme DCC le bit 1 dure 116µs et le bit 0 au moins 200µs (il peut être beaucoup plus long mais restons simple). Transmettre un bit dure donc en moyenne 158µs (dans les cas idéaux). On peut donc espérer une vitesse de transmission d'environ 6329 bits par seconde.
Dans un autre fil, Alain, tu nous a expliqué que ton interface avec le PC était réglé sur 19200 bauds (soit dans le cas d'une liaison série avec le PC 19200 bits par seconde).

Larist a écrit:

Ma MX1 est en 3.06. j'ai essayé une version supérieure mais elle est incompatible avec TC (ce que le site Zimo ne dit pas). Je suis en liaison 19200, c'est le meilleur compromis que j'ai trouvé après plusieurs tests comparatifs.

Lorsque tu parles de l'arrivée d'une "rafale" de commandes, si celles-ci sont toutes destinées au DCC (à la voie) la centrale les reçoit à la vitesse de 19200 bps et doit les retransmettre à 6300 bps environ. La centrale place alors les commandes dans un buffer (une mémoire) en attendant de pouvoir les transmettre. Lorsque le buffer est plein, la centrale dit "stop ! attendez un peu et renvoyez moi la suite plus tard..." ce qui pourrait être la provenance du code erreur.
Le faible débit permis par la norme DCC est la raison pour laquelle j'ai tenu, pour mon réseau, à n'y faire passer que les commandes de locomotives.
Pour voir si ce diagnostic est plausible, tu pourrais refaire le test que tu as décris en abaissant la vitesse de transmission de ton interface (dans la MX1 et dans le PC). Tu auras alors peut-être des retards dans les commandes (c'est un diagnostic pas une solution) mais peut-être les pertes auront-elles disparu (teste avec ton moniteur de port série).

Jean_01 a écrit:

Larist a écrit:

Il y a aussi une solution de riche : acheter une petite centrale uniquement pour piloter les accessoires.

Cela suppose aussi que tu doubles ton bus traction car on ne peut pas mélanger les signaux de deux centrales sur un même bus.

Jean

Il suffit seulement de ne connecter les accessoires qu'a la centrale dédiée...
Il n'y a pas besoin de mélanger les sorties DCC voies.

DiCoS69 a écrit:

Jean_01 a écrit:

Larist a écrit:

Il y a aussi une solution de riche : acheter une petite centrale uniquement pour piloter les accessoires.

Cela suppose aussi que tu doubles ton bus traction car on ne peut pas mélanger les signaux de deux centrales sur un même bus.

Jean

Il suffit seulement de ne connecter les accessoires qu'a la centrale dédiée...
Il n'y a pas besoin de mélanger les sorties DCC voies.

Cela, c'est ce que j'appelle enfoncer une porte ouverte.

Jean

Teddy Bear a écrit:

Selon la norme DCC le bit 1 dure 116µs et le bit 0 au moins 200µs (il peut être beaucoup plus long mais restons simple). Transmettre un bit dure donc en moyenne 158µs (dans les cas idéaux). On peut donc espérer une vitesse de transmission d'environ 6329 bits par seconde.

Tu es même optimiste pour le calcul de la vitesse car avec les "time out" entre paquets, la moyenne de temps est bien supérieure.
Les "salves" repérées par Alain sont, sans doute, des instructions "locomotive" dont la répétition charge la ligne, les commandes "accessoires" étant délivrées en interligne et non répétées.
Si mes souvenirs sont bons, le protocole DCC ne comporte pas d'octet de vérification, juste des bits de parité.
En toute logique, l'abaissement de la vitesse de transmission PC/centrale à 4300 bauds, par exemple, devrait améliorer le fonctionnement.

Jean_01 a écrit:

DiCoS69 a écrit:

Jean_01 a écrit:

Larist a écrit:

Il y a aussi une solution de riche : acheter une petite centrale uniquement pour piloter les accessoires.

Cela suppose aussi que tu doubles ton bus traction car on ne peut pas mélanger les signaux de deux centrales sur un même bus.

Jean

Il suffit seulement de ne connecter les accessoires qu'a la centrale dédiée...
Il n'y a pas besoin de mélanger les sorties DCC voies.

Cela, c'est ce que j'appelle enfoncer une porte ouverte.

Jean

Si tu veux, mais la tournure de phrase me semblait prêter à confusion...

DiCoS69 a écrit:

Teddy Bear a écrit:

Selon la norme DCC le bit 1 dure 116µs et le bit 0 au moins 200µs (il peut être beaucoup plus long mais restons simple). Transmettre un bit dure donc en moyenne 158µs (dans les cas idéaux). On peut donc espérer une vitesse de transmission d'environ 6329 bits par seconde.

Tu es même optimiste pour le calcul de la vitesse car avec les "time out" entre paquets, la moyenne de temps est bien supérieure.
Les "salves" repérées par Alain sont, sans doute, des instructions "locomotive" dont la répétition charge la ligne, les commandes "accessoires" étant délivrées en interligne et non répétées.
Si mes souvenirs sont bons, le protocole DCC ne comporte pas d'octet de vérification, juste des bits de parité.
En toute logique, l'abaissement de la vitesse de transmission PC/centrale à 4300 bauds, par exemple, devrait améliorer le fonctionnement.

Tu as tout à fait raison Elie, j'ai juste voulu rester simple et rapide pour un calcul "d'évaluation" d'ordre de grandeur. Dans le même ordre d'idée on ne peut pas comparer le protocole DCC et le protocole RS232. Le nombre d'information (je ne parle pas de bit) transmis par seconde dans le premier est variable en fonction des circonstances et le deuxième est plus verbeux
Il s'agissait juste de se donner un ordre de grandeur et de voir si c'était plausible  A mon avis ça l'est

Teddy Bear a écrit:

Il s'agissait juste de se donner un ordre de grandeur et de voir si c'était plausible  A mon avis ça l'est

Je le pense aussi...

Teddy Bear a écrit:

Lorsque tu parles de l'arrivée d'une "rafale" de commandes, si celles-ci sont toutes destinées au DCC (à la voie) la centrale les reçoit à la vitesse de 19200 bps et doit les retransmettre à 6300 bps environ

Normalement aucune commande n'est destinée au DCC puisqu'aucun train ne part (délai de 999 au départ de chaque trajet) et rien en dehors du mouvement des aiguillages n'est visible sur le réseau. Je vais essayer par sondage de voir ce que sont ces commandes rafale.

J'ai essayé la vitesse de 4800 sur la liaison centrale-PC. C'est encore pire. Je me suis arrêté à  1500 en intervalle et j'avais toujours 3 aiguillages non basculés!

A+

Alain

bonsoir
je viens de lire (Il y a aussi une solution de riche : acheter une petite centrale uniquement pour piloter les accessoires.)
ce qui veut dire, si j'ai bien compris, qu'il y a deux centrales raccordées au PC.
dans ce cas comment fait on physiquement pour raccorder les deux centrales, je n'ai qu'un port série sur mon PC.
et comment fait TC pour communiquer avec les deux centrales?