Intervalle entre aiguillages

dudule a écrit:

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?

Et bien, il faut en choisir une qui se raccorde en USB ou en LAN, si tu as des ports USB ou LAN, bien sûr, sinon, il y a la solution du convertisseur.
Pour TC, ce n'est pas un problème, pourvu que dans les onglets "connexion" des propriétés de chaque élément à commander, tu aies bien affecté la bonne centrale.

bonjour Elie
merci pour la réponse, dans mon cas les centrales étant identiques, je suppose que l'affectation se fait par le choix du port?

Larist a écrit:

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

Bonjour Alain,

Diagnostic non validé alors ! Désolé

Ceci dit, il me semblait que tes aiguilles étaient commandées par des LS150 donc en DCC

Bon de toute façon ça ne donne pas la solution

Teddy Bear a écrit:

Ceci dit, il me semblait que tes aiguilles étaient commandées par des LS150 donc en DCC

Je te rassure mes aiguilles bien que pilotées par des Switchpilot sont bien commandées par du DCC.

A+

Alain

dudule a écrit:

bonjour Elie
merci pour la réponse, dans mon cas les centrales étant identiques, je suppose que l'affectation se fait par le choix du port?

Si tu as bien déclaré les 2 centrales dans "configuration des systèmes numériques", il y en a une qui est en 1 et l'autre en 2 (ou plus s'il y a d'autres systèmes), il faut donc veiller à indiquer la bonne... et pour TC, c'est, bien sûr, le port COM qui le guide.

Larist a écrit:

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

Alain

Le DCC est constamment en activité, même quand rien ne bouge, les octets d'adresse et de vitesse des locos sont permanents (vitesse 0), de même que l'état des fonctions.
Il faut bien qu'il y ai du courant sur la voie...
A mon avis, le flux PC/centrale est permanent et on peut se demander si ce n'est pas un problème de capacité mémoire du PC qui perturbe les échanges, ou quelque chose comme ça...
Mais je dis peut-être une co....ie

J'ai analysé ce que j'ai appelé la rafale de commandes envoyées par TC à la centrale juste avant le basculement des aiguillages.
Il s'agit, principalement, de commandes destinées uniquement à la centrale pour qu'elle "verrouille" en interne chaque aiguillage (ceux concernés par les basculements et qui suivent juste derrière). Ce verrouillage a pour but d'informer la centrale qu'elle ne doit plus accepter de commandes sur chaque aiguillage sauf celles venant de TC bien sûr. Ce processus est donc logique, il vise à interdire une manœuvre depuis une commande à main. S'y ajoute une commande pour chaque loco au départ qui positionne le cran de vitesse à 0. Chacune de ces commandes est acquittée par la centrale sans restriction.
Et ensuite la première commande de basculement physique d'un aiguillage qui suit, reçoit systématiquement un code retour d'erreur (busy) si "l'intervalle aiguillage" est à moins de 700 ms. A contrario toutes les aiguilles suivantes (une bonne dizaine) basculent bien si "l'intervalle" est au moins à 200 ms.

Vu le peu de travail demandé à la centrale, il est incompréhensible qu'il lui faille 700 ms pour prendre en compte le premier aiguillage qui suit la rafale. J'ai cherché dans les CV de la centrale et fait quelques tests mais rien. Et je ne vais pas poser la question au fabricant qui m'a déjà fait comprendre (peu diplomatiquement) que cette version est figée, place à la nouveauté qui se fait attendre ... depuis 4 ans.

J'en reste là, il me reste donc à attendre une réponse de Freiwald, sinon laisser les 700 ms.

A part ça quelques remarques:
- TC interroge le port COM environ 100 fois par seconde pour avoir son statut
- TC interroge la centrale toutes les 2 secondes pour avoir son statut
- sur l'établissement d'un trajet, TC envoie un ordre de basculement de toutes les aiguilles concernées, même si elles sont déjà bien positionnées
- en dehors des demandes de statut TC ne communique avec la centrale que pour envoyer des ordres justifiés (incrément vitesse de loco, mise en route fonction de loco, etc). Donc échanges réduits au strict nécessaire.
- chaque envoi d'une commande à la centrale est toujours suivi de la lecture de la réponse (mais quid du traitement)
- une commande envoyée par TC c'est, en moyenne, entre 10 et 12 octets (octets de contrôle compris) et une réponse de 9 à 10. Attention chiffres valables pour le protocole Zimo. Cela engendre une charge moyenne de 1500 à 2000 b/s lors de l'établissement d'un trajet avec un intervalle aiguillage de 200 ms (que l'aiguille bascule ou pas !) et lors de la "rafale" 2500 à 3000 b/s. Mais ca reste théorique car après il y a la gestion de la ligne physique (port série) et là je ne sais pas comment cela fonctionne (y a t-il des délais de retournement entre écriture et lecture ?).

A+

Alain

J'ajoute une petite mise en garde sur une anomalie que j'avais signalée dans mon post du 25 mai 2013 à 12h37 dans le fil :
https://traincontroller.forum-actif.net/t2011p45-probleme-lors-de-l-execution-simultanee-de-2-trajets
Au passage de la version 7 à la version 8 l'intervalle de temps que j'avais paramétré dans la version 7 était repassé tout seul à sa valeur par défaut, soit 0. J'y ai laissé quelques plumes et je n'avais pas apprécié la plaisanterie ...

Larist a écrit:

Et ensuite la première commande de basculement physique d'un aiguillage qui suit, reçoit systématiquement un code retour d'erreur (busy) si "l'intervalle aiguillage" est à moins de 700 ms. A contrario toutes les aiguilles suivantes (une bonne dizaine) basculent bien si "l'intervalle" est au moins à 200 ms.
J'en reste là, il me reste donc à attendre une réponse de Freiwald, sinon laisser les 700 ms.
A+

Alain

Tu ferais bien de lui adresser cette conclusion de tes essais, cela pourrait peut-être l'inciter à ne pas prendre le problème à la légère...

juste comme cela, mes soucis d'aiguilles qui ne se font des fois pas ne viendraient'ils pas de la ???
(post informations perdues)

DiCoS69 a écrit:

Tu ferais bien de lui adresser cette conclusion de tes essais, cela pourrait peut-être l'inciter à ne pas prendre le problème à la légère...

Je lui ai envoyé un descriptif de mes observations avec un fichier des traces. Il a tout ce qu'il faut.

A+

Alain

double a écrit:

juste comme cela, mes soucis d'aiguilles qui ne se font des fois pas ne viendraient'ils pas de la ???
(post informations perdues)

Pour le savoir tu peux essayer de faire une série de tests comme décrits dans mon post du Dim 21 Sep 2014, 23:24 de ce fil.

Bon diag.

A+

Alain

double a écrit:

juste comme cela, mes soucis d'aiguilles qui ne se font des fois pas ne viendraient'ils pas de la ???
(post informations perdues)

Ce serait curieux que ça le fasse chez toi et pas chez moi... avec la même centrale et la même version de TC...
La tendance serait alors plutôt à mettre TC hors de cause et à reporter le problème sur la chaine de transmission PC/centrale...
De plus tu es en USB, pas en RS232.

Bonjour,

double a écrit:

juste comme cela, mes soucis d'aiguilles qui ne se font des fois pas ne viendraient'ils pas de la ???
(post informations perdues)

En complément de la réponse d'Elie, je pense que tes aiguilles non faites sont trop systématiques et hors charge pour entrer dans le cadre décrit par Larist ...

De mon côté, j'ai fait quelques essais ...
Rappel de mon problème :
Aiguilles non faites de manière très aléatoire (mais très ch…..) qui apparaissent lors de l’établissement d’itinéraires dans les trajets avec une charge DCC (7/8 locos en accélération/décélération).
Rappel de ma config : 2 bus DCC, 1 en sortie de la centrale LENZ LZV100 pour les aiguillages avec décodeurs LS150/switchpilot et moteurs SEEP/servo, et 1 en sortie du booster LV102 pour la voie. Alimentation des décodeurs d’aiguillages par transfo 2x15volts 160VA.
Intervalle entre aiguillages dans TC : 50ms.
Interface centrale/PC via LI-USB donc avec vitesse non paramétrable de 57600 bauds.
Le montage rapide du test :
- Un inter M/A qui manœuvre 19 aiguillages avec moteurs SEEP répartis sur 4 LS150 + 1 aiguillage avec servo sur switchpilot.
- Un BP qui déclenche l’allumage et l’extinction des feux de tous les véhicules (une vingtaine de locos sur le réseau) en boucle.
- Un inter M/A pour sortir de la boucle.
Le positionnement des 20 aiguillages est facilement repérables car il s’agit de 4 cascades de 5 situées dans mes gares cachées.
- Démarrage de la trace Portmon
- Impression des 80 pages du protocole Xpressnet (!)
Premiers résultats :
1 - Hors charge, les bascules d’aiguillages sont régulières. Sur 10 essais, aucune défaillance.
2 – Allumage et extinction des feux de tous les véhicules toutes les secondes :
- L’arrêt de la boucle est immédiat.
- Les commandes des aiguillages sont saccadées par groupe de 2 ou 3.
- Pas de défaillance sur les commandes des aiguilles (5 essais).
3 - Allumage et extinction des feux de tous les véhicules toutes les 500 ms :
- Arrêt de la boucle de clignotement des feux environ 10 secondes après appui sur le BP de fin.
- Les saccades de commandes des aiguillages sont plus espacées.
- Aucun manque dans les commandes d’aiguilles (5 essais).
4 - Allumage et extinction des feux de tous les véhicules toutes les 100 ms :
- Arrêt de la boucle après plusieurs minutes.
- Les commandes des aiguillages ne se font pas tant que je n’appui pas sur le BP de fin de boucle d’allumage/extinction des feux.
- Les commandes d’aiguilles se font alors une par une toutes les 1 à 2 secondes
- L’allumage/extinction des feux continuent pendant de très très longues minutes.
- J’ai eu 1 cas d’aiguille non faite au 3° essai …

Dans les traces Portmon, je ne vois rien de particulier pour les cas 1 à 3.
Dans la trace du cas 4, je vois quelques « command station busy » mais la commande d’aiguille qui précède ces « status busy » est bien répétée comme prévu dans le protocole Xpressnet. Il faut encore que je décode l’adressage des accessoires dans le protocole Xpressnet afin de voir ce qu’il est advenu de la commande de l’aiguille non faite … mais à priori le compte est bon (nombre de commande d’aiguilles envoyées en tenant compte des états busy), alors, la centrale qui suit pas  ou ????????

Bien que cela me rajeunisse de quelques dizaines d’années, je n’ai pas trop envie de rentrer plus à fond dans ces analyses de protocole de com … J’ai depuis quelques temps une idée derrière la tête … Comme j’ai déjà les bus DCC voies et aiguillages séparés :
Revente de mon booster LV102 et de mes 8 décodeurs LS150.
Achat d’une centrale LZV100 réservée pour la commande des aiguillages avec un bus de rétro-signalisation dédié et des décodeurs LS100 qui ont le feedback. Après, si une aiguille ne se fait pas, cela devrait être forcément entre le décodeur et l’aiguille … Mais la solution est onéreuse et quand même pas fiable à 100% …  

A+
Georges

Bonjour Georges,

Geo69 a écrit:

Un inter M/A qui manœuvre 19 aiguillages avec moteurs SEEP répartis sur 4 LS150 + 1 aiguillage avec servo sur switchpilot.

Peut-être faudrait-il que tes aiguillages soient basculés dans le cadre de l'établissement d'un trajet si tu as des pbs dans cette config ?

Geo69 a écrit:

- Impression des 80 pages du protocole Xpressnet (!)

Dans Portmon tu as la possibilité de faire une sélection dans la capture. Perso j'ai enlevé tout ce qui touchait aux demandes de statut du port Com (100/secondes!)

Geo69 a écrit:

Dans la trace du cas 4, je vois quelques « command station busy » mais la commande d’aiguille qui précède ces « status busy » est bien répétée comme prévu dans le protocole Xpressnet.

Donc là TC a bien réagit en réémettant la commande. C'est un point majeur.

Geo69 a écrit:

Bien que cela me rajeunisse de quelques dizaines d’années, je n’ai pas trop envie de rentrer plus à fond dans ces analyses de protocole de com …

Bienvenue au club.

Geo69 a écrit:

Achat d’une centrale LZV100 réservée pour la commande des aiguillages avec un bus de rétro-signalisation dédié et des décodeurs LS100 qui ont le feedback.

A condition que le feedback soit mieux traité que certains "command busy" ...

A+

Alain

Bonsoir,

Larist a écrit:

...

Geo69 a écrit:

Un inter M/A qui manœuvre 19 aiguillages avec moteurs SEEP répartis sur 4 LS150 + 1 aiguillage avec servo sur switchpilot.

Peut-être faudrait-il que tes aiguillages soient basculés dans le cadre de l'établissement d'un trajet si tu as des pbs dans cette config ? ...

Oui, il faudrait que je fasse comme toi pour me rapprocher d'une exploitation réelle (si j'en ai le courage !...). J'ai fait au plus rapide pour voir si le problème était bien lié à la charge ...  

Larist a écrit:

...

Geo69 a écrit:

- Impression des 80 pages du protocole Xpressnet (!)

Dans Portmon tu as la possibilité de faire une sélection dans la capture. Perso j'ai enlevé tout ce qui touchait aux demandes de statut du port Com (100/secondes!) ...

Oui, j'ai bien mis des filtres et utilisé le loging à l'écran avec les fonctions recherche du bloc-notes. Pour les 80 pages, je parlais de la documentation Lenz sur le protocole Xpressnet ...  

A+
Georges

Geo69 a écrit:

Pour les 80 pages, je parlais de la documentation Lenz sur le protocole Xpressnet ...  

Oups autant pour moi.  J'ai lu trop vite pensant qu'il s'agissait des traces.

A+

A+

Bonjour Elie
merci pour ta réponse  désolé pour le  retard mais j'étais occupé avec mon coffret pour boosters

Alors, ça bosse dur....

Bonjour,

Geo69 a écrit:

... Dans la trace du cas 4, je vois quelques « command station busy » mais la commande d’aiguille qui précède ces « status busy » est bien répétée comme prévu dans le protocole Xpressnet. Il faut encore que je décode l’adressage des accessoires dans le protocole Xpressnet afin de voir ce qu’il est advenu de la commande de l’aiguille non faite … mais à priori le compte est bon (nombre de commande d’aiguilles envoyées en tenant compte des états busy), alors, la centrale qui suit pas  ou ???????? ...

Je suis arrivé au bout de l’analyse de mes traces Portmon. Mes constats :
L’interface LI-USB de Lenz est un composant Xpressnet à part entière. Il « bufferise » les messages et rend compte au PC de la bonne transmission ou pas à la centrale.
Pour chaque commande d’aiguille, TC envoi deux ordres à la centrale (« Deactivate » et « activate »).  
L’interface acquitte donc chacun de ces ordres de même que sur toutes les commandes d’allumage/extinction des feux.
Dans la trace ou j’ai une commande d’aiguille pas faite, l’interface renvoi 5 états « busy » à TC. Sur les 5 cas, j’ai la séquence suivante :
Envoi « deactivate » position aiguille par TC
Réponse OK par LI-USB
Envoi « activate » position d’aiguille par TC
Réponse « busy » par LI-USB
Ré-envoi « activate » position d’aiguille par TC
Réponse OK par LI-USB
La séquence pour l’adresse d’aiguille qui n’a pas fonctionnée est identique aux 4 autres états « busy »…
Mes conclusions :
Dans ma configuration et avec mon paramétrage, le problème arrive bien de façon aléatoire avec la charge des commandes DCC.
TC respecte bien le protocole Xpressnet et est donc hors de cause (reste juste un petit doute sur le délai de réémission mais dans la trace tout est dans la même seconde …).
Pour éviter les états « busy », il suffirait que j’alimente mon bus DCC accessoires (aiguillages et signaux) avec un nouveau couple centrale/interface.
Pour avoir des commandes d’aiguillages complètement indépendantes, je pourrais même basculer mes signaux sur le bus DCC voies (2 fils par signaux à déplacer sur le feeder d’à côté …   ).
Si quelqu’un a une centrale en trop, je suis preneur …  

A+
Georges

Geo69 a écrit:

Si quelqu’un a une centrale en trop, je suis preneur …  
Georges

J'ai une grosse Massoth 1200Z, 24 V, 12 A qui décore une étagère...
Euh j'ai dit une grosseu c...rie ?

Geo69 a écrit:

Pour chaque commande d’aiguille, TC envoi deux ordres à la centrale (« Deactivate » et « activate »).  
L’interface acquitte donc chacun de ces ordres

Bonsoir Georges,

J'ai aussi constaté ces 2 ordres qui se suivent mais je pencherais pour "activate" envoyé en premier. Car sur le 1er ordre quand j'ai un code retour 0 l'aiguille est faite mais si code retour "busy" (code 04) elle n'est pas faite. Alors que sur le 2ème ordre j'ai systématiquement un code retour "busy" alors que l'aiguille est faite !
La seule fois où j'ai un code retour 0 sur le 2ème ordre, c'est quand il y a d'autres ordres (locos, verrouillages des aiguilles) entre les 2. C'est à dire que le délai s'allonge entre l'envoi "activate" et "déactivate".  Très curieux que ça fonctionne néanmoins. Dans TC il y a un paramètre "temps de connexion" dans l'onglet connexion de chaque aiguillage. Je me demande si cela a un rapport ?

Dans ton cas il me semble que tu as mis 50 ms dans "intervalle aiguillage". Peut-être pourrais-tu l'incrémenter pour test ou observation sur longue période ?

Sinon je te rejoins sur l'idée d'une centrale dédiée. Une centrale peu chère type TAMS (ou autre) pourrait peut-être faire l'affaire ?

A+

Alain

Pour la Tams EasyControl, vous pouvez y aller les doigts dans le nez, elle est super fiable et très facile d'utilisation, mais il faut un booster (B-2 Tams ou DB2 de LDT).

Bonjour,

Christophe a écrit:

... J'ai une grosse Massoth 1200Z, 24 V, 12 A qui décore une étagère...  

C'est une idée ... Je soude les aiguilles en positions droites et je fais un circuit de slot racing !...

A+
Georges

Bonjour,

Larist a écrit:

... J'ai aussi constaté ces 2 ordres qui se suivent mais je pencherais pour "activate" envoyé en premier ...

Je viens de vérifier et, sous réserve du bon décodage des commandes Xpressnet, j'ai bien "deactivate" puis "activate" ??? ...

Larist a écrit:

... Dans TC il y a un paramètre "temps de connexion" dans l'onglet connexion de chaque aiguillage. Je me demande si cela a un rapport ?...

A ma connaissance, ce paramètre en liaison avec le fichier Railroad.ini sert à paramétrer une durée d'impulsion pour des décodeurs d'accessoires qui ne géreraient pas ce paramètre ... Tiens, dans ma configuration, je ne vois plus de fichier Railroad.ini ???  

Larist a écrit:

... Dans ton cas il me semble que tu as mis 50 ms dans "intervalle aiguillage". Peut-être pourrais-tu l'incrémenter pour test ou observation sur longue période ? ...

Au delà de 50ms, cela met le bronx dans l'allumage de mes signaux   ... C'est pour cela qu'avec une deuxième centrale, j'envisageais de basculer mes signaux sur le bus DCC voies afin d'isoler les décodeurs d'aiguillages et de pouvoir éventuellement modifier ce paramètre sans interaction sur les décodeurs de signaux ...

A+
Georges