Intervalle entre aiguillages

Suite à des aiguillages non faits de manière aléatoire je cherche à comprendre la logique du paramètre "Intervalle aiguillage" dans la configuration des systèmes numériques. Quand on l'augmente cela améliore les choses. Quel est le (ou les composants) qui freine ? TC ? la liaison avec la centrale ? la centrale ? le décodeur d'aiguillage ?

Pour essayer de comprendre j'ai fait une batterie de tests pour basculer 11 aiguillages d'un seul coup. Les aiguillages sont manœuvrés par des servos pilotés par SwitchPilot ESU.

Cas 1
Aucun train ne circule seuls les aiguillages basculent sur déclenchement simultané de 4 itinéraires. Tests avec intervalle à partir de 100 ms par pas de 100
Constats
- avec une vitesse de liaison PC-centrale en dessous de 9600 bps une bonne moitié des aiguilles ne basculent pas quelle que soit la valeur du paramètre intervalle (je me suis arrêté à 500 ms)
- à partir de 9600 et au delà (maxi 38400) tout bascule avec un intervalle mini de 300 ms. Au delà de 9600 le gain n'est pas significatif.

Cas 2
Mêmes tests avec 9 trains circulant en navette continuellement sur des zones non concernées par les 11 aiguillages.
Constats
- pas d'erreurs à partir de l'intervalle 600 ms avec une liaison à 9600 bps
- pas d'erreurs à partir de l'intervalle 500 ms avec une liaison à 38400 bps


Autres constats:
- la vitesse de rotation des servos n'a aucun impact
- le basculement d'un aiguillage par TC consomme du processeur PC. Pic notable quand on bascule un seul aiguillage manuellement, le reste étant au repos. Quand tous les trains circulent la moyenne est aux alentours de 20 30% de conso avec pointes 50 60% maxi. Dès le déclenchement des aiguillages arrive une pointe à 100% pendant 1 à 2 secondes puis 60% pendant tous les déclenchements en rafale.

Mes interrogations
- j'ai l'impression que TC envoie ses ordres à la centrale, à son rythme, sans se soucier s'ils sont correctement pris en compte.
- si je mets un intervalle conservatoire de plus de 600 ms cela entraine un délai de plusieurs secondes pour basculer les aiguillages d'un itinéraire en entrée de gare cachée. Or le train part dès l'établissement de l'itinéraire. Là TC manque d'à propos !

A+

Alain

Tes tests sont intéressants. Mais malheureusement, on ne peut pas en tirer grand chose...

Quand tu dis que TC envoie ses ordres à la centrale sans se soucier si ils sont pris en compte, je pense que c'est normal, puisque une centrale n'est pas prévue pour renvoyer le feedback à TC.

Voilà, je ne sais pas quoi conclure!

Je rejoins Rico , étude intéressante mais qui débouche sur des questions, malheureusement.
J'ai volontairement bridé ma connexion TC - centrale via le bus USB à 9600 bauds car j'avais quelques problèmes de cantons qui restaient désespérément allumés malgré la sortie de la rame. Le passage à 9600 bauds a réglé mon problème. (allez comprendre !)
En revanche, je n'ai pas remarqué de refus de mouvement d'aiguillage causé par TC.

De même, j'ai bridé ma connexion avec la centrale au mini (19200 bit/s) car au delà, j'avais l'impression que ça devenait instable.

Je ne sais pas si cela fait sens, mais pour connaître des déboires différents, je commence sérieusement à mettre en cause l'association, TC, USB RS 232, centrale !

Car selon le convertisseur utilisé les soucis ne sont pas les mêmes ! Par exemple, avec un convertisseur Prolific, les défauts de détection sont fréquents (trains pas détectés) alors qu'avec un convertisseur Dacomex ils sont extrêmement rares...

Dans les deux cas, j'utilise le réglage normal sur 9600 bauds.

J'ai abandonné le convertisseur USB RS232 au profit d'une carte PCI dans ma tour.

Avec l'adaptateur USB, ça marchait quand ça voulait! Et c'était pas souvent!

Une centrale remonte de l'info : la rétrosignalisation, sa config à l'initialisation.

J'ai regardé le protocole de la centrale Zimo. Tout est prévu pour faire de l'acquittement, de la détection d'erreur (avec code auto correcteur) sur tous les messages échangés des 2 côtés. Sur le papier ca semble bien sécurisé. TC reçoit systématiquement un acquittement sur chaque message qu'il envoie. Et sur ceux qu'il reçoit s'il n'acquitte pas la centrale va réémettre.
La vitesse de la liaison PC-centrale ne devrait avoir aucun impact.

Maintenant c'est du logiciel de part et d'autre avec les imperfections de cette matière ...
Je sais que la centrale Zimo présente des dysfonctionnements avec TC (info site Zimo). Mais quoi ?
Si des comportements analogues se produisent avec d'autres types de centrale le doute s'élargit.

Vous avez raison on ne pas conclure grand chose si ce n'est choisir les valeurs de paramètres qui nous causent le moins de soucis. Mais quand c'est aléatoire dans le temps ...

Pour info j'ai fait un test à partir de la commande à main en basculant 4 aiguillages d'un coup. En moins d'une demi seconde tout bascule sans erreur (fait plusieurs fois avec tous les trains en mouvement sous contrôle de TC)

A+

Alain

Concernant le convertisseur USB-RS232 il est neutre dans mon cas. J'ai rencontré les mêmes pbs avec un convertisseur ATEN puis un Connectland. En désespoir de cause j'ai récupéré un PC avec un port série : idem !

La rétro via USB (LDT) ne m'a jamais causé le moindre soucis. Ni celle qui remonte par la liaison série (depuis les modules Zimo MX9 reliés à la centrale)

A+

Alain

Donc, tu nous dit qu'il peut y avoir un réel dialogue, mais que TC ignorerait les remontées d'informations de la centrale. Ça semble pas sérieux tout ça! Surtout si le feedback est dispo, c'est bête de ne pas l'utiliser. Maintenant, peut-être que les autres centrales ne remontent pas les infos... et donc TC va au plus simple!

Ma centrale affiche un règlage de 1200 à 57400 bauds.
Je fonctionne depuis bien longtemps sur 2400 bauds sans problème de vitesse d’exécution des commandes.
L'enchainement des mouvements d'aiguilles n'est pas modifié par le débit des échanges, mais, avec un temps d'intervalle augmenté au niveau de TC, l'établissement des itinéraires comportant plusieurs aiguilles est d'autant retardé.
TC n'enclenche pas non plus obligatoirement, les aiguilles dans l'ordre de l'agencement physique, mais selon son bon vouloir.
Certains décodeurs gèrent aussi les enclenchements, et quand le même décodeur est sollicité pour activer plusieurs de ses sorties, il stocke en mémoire tampon et exécute ensuite au fur et à mesure avec son propre intervalle.
Il y a effectivement échange entre la centrale et TC au niveau contrôle des données, mais, entre la centrale et le réseau, seuls les ordres envoyés aux décodeurs type locos sont répétés, pour tout ce qui est décodeurs type accessoires, il faut que ça passe du premier coup, sinon, c'est cuit...

Larist a écrit:

La rétro via USB (LDT) ne m'a jamais causé le moindre soucis. Ni celle qui remonte par la liaison série (depuis les modules Zimo MX9 reliés à la centrale)

A+

Alain

C'est pourtant un point sensible de l'installation, mais, cela prouve que ton câblage est bon et que ta voie et ton matériel ont un bon contact...

rico a écrit:

Donc, tu nous dit qu'il peut y avoir un réel dialogue, mais que TC ignorerait les remontées d'informations de la centrale.

Ah non jamais dis ca !

Les infos qui remontent de la centrale : TC doit les acquitter sinon la centrale va réémettre.
Les infos que TC envoie à la centrale : la centrale envoie un acquittement (ou pas) en retour, comment TC le gère t-il (ou son absence) ?

A+

Alain

Bref, c'est le flou artistique. Et selon le protocole de Com de chaque centrale, cela doit être sans doute différent.

DiCoS69 a écrit:

Il y a effectivement échange entre la centrale et TC au niveau contrôle des données, mais, entre la centrale et le réseau, seuls les ordres envoyés aux décodeurs type locos sont répétés, pour tout ce qui est décodeurs type accessoires, il faut que ça passe du premier coup, sinon, c'est cuit...

Je ne connais pas cette partie du protocole, mais ce que j'ai constaté :
- ayant eu un autre logiciel de pilotage avant TC je n'ai jamais rencontré de problème d'ordres perdus.
- pour lever le doute sur les décodeurs d'accessoires j'en ai doublé un (j'en ai mis au autre sur le réseau avec la même adresse) Tous les 2 ont présenté les mêmes oublis de basculement au même moment.
- quand j'envoie une volée de basculement via la commande à main en beaucoup moins de temps que TC je n'ai aucune anomalie.

A+

Alain

rico a écrit:

selon le protocole de Com de chaque centrale, cela doit être sans doute différent.

Je pense que mes pbs viennent de l'implémentation de ce protocole :
- dans la centrale ? (oui dans mon cas mais à quel degré ?)
- dans TC ? (Zimo étant peu représenté le panel de test est réduit)

Bref tant que je n'aurai pas changé de centrale pour une Lenz je ne saurais pas. Ca commence à me chauffer pour passer commande.

A+

Alain

Jamais d'ordres perdus? En DCC?

Cela voudrait dire qu'il y a retour d'infos. Or comme le précise Elie, il n'y a pas de dialogue entre un décodeur et la centrale, c'est à dire côté DCC. Même si côté PC centrale, le dialogue est parfait, comment savoir si l'ordre de la centrale arrive bien au décodeur?

Tiens, changer de centrale! Tu n'es pas le seul, n'est ce pas Christophe!

De mon côté, avec mon système hybride globalement Lenz, je n'ai jamais eu de commandes non réalisées. Les problèmes que j'ai eu était plutôt côté PC récent avec adaptateur USB et W7. A l'époque de mes vieux PC présentant encore des vrais port com et sous XP, tout était toujours nickel! Mais bon, faut bien évoluer.

Ma centrale est multiprotocole (DCC et Motorola II), et il m'est arrivé d'avoir un problème avec une adresse "basse" (<128) de décodeur "accessoire", qui pour je ne sais quelle raison s'est bloquée (plus aucun ordre ne passait à cette adresse).
J'ai refait le paramétrage de choix du protocole dans la centrale, et le problème a disparu.
Cela pour dire que les aléas de codification ne sont pas une vue de l'esprit et que nos systèmes n'étant que des jeux sont bien peu sécurisés sur ce point...

J'ai fait l'essai de paramétrer le port à 19200 bits/s, je suis vite revenu à 9600 (valeur par défaut) car ça cafouillait grave et j'ai mis 400ms dans l'intervalle entre aiguillages.
Par contre, dans l'onglet "Setup" de CV-Editor, system status il est indiqué 57600 Baud !.
Est-ce que Bits/s et Baud sont la même chose

momo13 a écrit:

Est-ce que Bits/s et Baud sont la même chose :?

le Baud est une information qui contient plusieurs bits;
voir ici:
http://fr.wikipedia.org/wiki/Baud_%28mesure%29

momo13 a écrit:

Est-ce que Bits/s et Baud sont la même chose

Oui, le Baud est l'unité de mesure usuelle pour le débit binaire.

Dans la continuité de mes tests je viens de voir un curieux comportement.

J'ai 4 trajets que je lance simultanément par un bouton poussoir. Chacun déclenche un itinéraire composé d'aiguillages (il y en a 11 au total). J'ai mis une condition pour que les locos en attente ne partent jamais. Le but est de tester le basculement des aiguillages sans aucune autre action sur le réseau où rien ne circule.

Une première série de tests montre que je n'ai aucun oubli de basculement des aiguillages si je met un intervalle de 500 ms. Si je mets 400 j'ai systématiquement un aiguillage, et toujours le même, qui ne bascule pas, alors que sur le TCO il est bon.

Deuxième série de test : les itinéraires s'établissent en différé des trajets sur conditionnement d'un bouton M/A. Décalage de quelques secondes entre les 2 actions. Surprise : cette fois à 400 ms tous mes aiguillages basculent.

Donc si trajets et itinéraires sont simultanés : un aiguillage ne bascule pas à 400 ms. Mais si trajets et itinéraires sont décalés j'ai toujours un aiguillage en rade tout est bon.

Ces tests ont été faits de multiples fois, de plus avec des ordis différents (puissance de 1 a 5). Les résultats sont invariables.
Comme sur le réseau il n'y a que les aiguillages de concernés, les échanges avec la centrale doivent toujours être les mêmes. Entre les 2 séries de tests il n'y a que le comportement de TC qui est différent.

Voilà c'est le doute du jour concernant TC.

A+

Alain

Pour moi, l'affaire est claire.
Il y a une non harmonisation des échanges entre le PC et la centrale.
A mon avis, c'est là que l'info se perd.
As-tu essayé de diminuer la vitesse de transmission PC > centrale ?

J'ai diminué la vitesse de la ligne (de 38400 bps à 9600) le comportement est identique. A 4800 l'instabilité est générale, même en mettant un délai de 3000 ms.
Et comme à chaque fois il n'y a que le basculement des aiguillages qui est véhiculé sur cette ligne j'ai fait une autre série de tests.

Un bouton poussoir déclenche le basculement des mêmes aiguillages mais de manière directe comme lorsqu'on clique sur l'aiguillage sur le TCO. Dans ce cas on est donc hors établissement d'itinéraires. Tout bascule sans faute dès 4800 bps avec un intervalle de 200 ms !! J'ai même changé plusieurs fois l'ordre des basculements, tout est nickel. La ligne et la centrale traitent donc bien ces commandes.

En résumé:
- Trajets et itinéraires en mêmes temps : tout est ok à 500 ms d'intervalle et vitesse mini de 9600 bps
- Trajets dans un 1er temps puis itinéraire en décalé : ok avec 400 ms et 9600 bps
- aiguillages seuls : ok avec 200 ms et 4800 bps

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.

A+

Alain

Larist a écrit:

- si je mets un intervalle conservatoire de plus de 600 ms cela entraine un délai de plusieurs secondes pour basculer les aiguillages d'un itinéraire en entrée de gare cachée. Or le train part dès l'établissement de l'itinéraire. Là TC manque d'à propos !
A+
Alain

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...