Intervalle entre aiguillages

Bonjour,

Larist a écrit:

... Une centrale peu chère type TAMS (ou autre) pourrait peut-être faire l'affaire ?...

DiCoS69 a écrit:

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

En ajoutant un booster à la Tams EasyControl, on ne doit pas être loin du prix d'une centrale LENZ avec son interface ? ... De plus pour moi, avec une Lenz j'aurais l'avantage d'avoir un backup ... J'ai regardé sur Ebay mais les possesseurs de LZV100 ne s'en séparent pas tous les jours !...

A+
Georges

Geo69 a écrit:

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

D'après description du protocole Zimo le 1er ordre est ON (ce que je traduis par Activate) et le 2ème est OFF (qui reçoit toujours un code retour "busy").

Bon ca fonctionne quand même

A+

Alain

Geo69 a écrit:

De plus pour moi, avec une Lenz j'aurais l'avantage d'avoir un backup ... J'ai regardé sur Ebay mais les possesseurs de LZV100 ne s'en séparent pas tous les jours !...

A+
Georges

regarde ici en neuf sans manette : http://www.modellbahnshop-lippe.com/produkt/Lenz/9-7-0-62744-003003-0-0-0-0-2-0-grp-fr-p-0/ein_produkt.html
si tu la commandes ce soir elle sera chez toi vendredi... en gros !

Mais dis moi, tu as l'air extrêmement balèze en analyse des échanges PC centrale, je te passerais volontiers mon usine Massoth pour voir ce qui pêche, et peut-être qu'après, j'aurais une centrale Lenz en trop !

Geo69 a écrit:

 ... Tiens, dans ma configuration, je ne vois plus de fichier Railroad.ini ???  

Il est un peu caché. Chez moi, sous W7, il est là:

C:\Users\Jean\AppData\Local\VirtualStore\Program Files\Train_Controller_V8_Gold\Gold_V8.D1

Ce doit être un peu pareil sous Vista

Jean

Bonjour,

Christophe a écrit:

... Mais dis moi, tu as l'air extrêmement balèze en analyse des échanges PC centrale ...

Balèze, non, mais avec le protocole d'un côté et la trace de l'autre et de la persévérance on y arrive ...

A+
Georges

Bonjour,

Jean_01 a écrit:

...

Il est un peu caché. Chez moi, sous W7, il est là:

C:\Users\Jean\AppData\Local\VirtualStore\Program Files\Train_Controller_V8_Gold\Gold_V8.D1

Ce doit être un peu pareil sous Vista

Jean

Effectivement, il est bien caché !... Sous Vista j'ai une vieille version Silver ou il est dans le répertoire standard "Programme Files". Il est aussi toujours là en Gold sous XP ...  

A+
Georges

Freiwald m'a répondu que le problème ne pouvait être corrigé.  
D'abord il a interrogé Zimo pour connaître la signification des codes erreurs, notamment le "busy". Il lui aurait été répondu que dans ce cas il faut réinitialiser la centrale !
Mais il a insisté sur le fait que la programmation d'une réémission se heurtait à la détermination du nombre de tentatives. Je le comprends, car rien ne permet de le prévoir et il ne faudrait pas que cela entraîne une boucle sans fin.

Conclusion de Freiwald : augmenter l'intervalle aiguillage. J'étais à 700 ms et j'ai encore eu un raté, maintenant j'en suis à 800.

Mais la V8.D02 vient de sortir avec le support du SPROG pour les accessoires. Je vais me rabattre sur cette solution.

A+

Alain

Bonjour,

Larist a écrit:

... Mais il a insisté sur le fait que la programmation d'une réémission se heurtait à la détermination du nombre de tentatives. Je le comprends, car rien ne permet de le prévoir et il ne faudrait pas que cela entraîne une boucle sans fin...

Ouais, pas convaincu ... Avec une centrale LENZ, le protocole Xpressnet prévoit juste une réémission de l'émetteur en cas de "busy". Je n'ai pas vu un nombre de tentatives mentionné dans la doc, et là Freiwald fait bien une réémission ... Visiblement ce n'est pas encore le grand amour entre Zimo et lui ...

A+
Georges

Geo69 a écrit:

Avec une centrale LENZ, le protocole Xpressnet prévoit juste une réémission de l'émetteur en cas de "busy". Je n'ai pas vu un nombre de tentatives mentionné dans la doc, et là Freiwald fait bien une réémission

J'avais oublié ce point que tu avais mentionné. Je lui en parle.

A+

Alain

Freiwald ne veut pas développer de processus de réémission tant qu'il n'a pas l'aval de Zimo sur la signification du code retour et sur la certitude que cela ne va pas aggraver l'état de la centrale en la saturant davantage. La solution d'augmenter l'intervalle fonctionne alors qu'une boucle de réémission peut conduire à pire. Il se base sur une discussion avec un "expert" de chez Zimo qui préconise le reset de la centrale.

On tombe là dans le dialogue de sourd entre développeurs. Je ne vais pas me prendre la tête avec ça, j'ai commandé un SPROG à 75€ qui devrait faire l'affaire.

A+

Alain

Larist a écrit:

alors qu'une boucle de réémission peut conduire à pire.

On n'est pas obligé de boucler à l'infini. Même un développeur débutant sait qu'un simple compteur permet de limiter les réémissions. On va ranger plutôt ça dans le "bottage en touche". Heureusement que c'est pas Freiwald qui a développé TCP/IP, sinon Internet marcherait moins bien.

Pas vraiment d'accord sur ton point de vue...
Le problème vient du "hard" qui va sans arrêt renvoyer des "busy" déclenchant de nouvelles réemissions.
Même si tu limites avec un compteur, tu auras un maximum de chances pour que, en fin de compte, la commande rejetée initialement ne soit pas passée ainsi qu'un certain nombre d'autres...

En fait tout le dilemme pour le développeur c'est :
- je réémets et ca finira bien par passer
- je réémets mais en fait je risque de charger un peu plus la centrale donc pas d'issue

Et le développeur veut donc savoir exactement à quoi correspond le statut busy pour adapter sa programmation. D'autant que ce code retour peut prendre d'autres valeurs (une dizaine de mémoire).
La tendance c'est effectivement de croire que la centrale est occupée et va bien finir par se libérer si on espace les réémissions avec une butée. Mais est-ce bien cela ? Perso je ne comprends pas ce statut qui est illogique dans ce contexte où aucune surcharge n'est avérée. La réponse de la centrale interpelle.

Et comme la réponse de Zimo est complètement à côté de la plaque, un développeur qui met sur le marché un logiciel à large diffusion, se doit d'être prudent, ce que je comprends. C'est une question comportementale avant d'être une question technique. D'autant qu'il a une solution qui fonctionne, même si ce n'est pas élégant.

A+

Alain

J'ai reçu et installé mon SPROG (SPROGIIV3) et je pilote tous mes aiguillages sans aucune perte même avec un intervalle à 0 ms !!  Waouh la fin d'emm... depuis des mois !!!

Par contre j'ai patiné pour entrer les adresses.
Car dans TC si on définit SPROG Family pour un aiguillage on ne peut pas entrer une adresse en 2 parties comme pour une centrale. Il n'y a qu'une seule case "adresse". La case "sortie" dans laquelle on indique un numéro n'existe pas (je suis avec des SwitchPilot servo qui ont 4 sorties). Raison : le SPROG ne connait que le niveau de base du DCC (dixit Freiwald). Il faut donc faire une transpo d'adresse comme suit (je n'ai trouvé nulle part cette formule et bonjour les essais pour la mettre au point) :

Nouvelle adresse = ((ancienne adresse - 1) * 4) + no de sortie

ex: avant 314/2    après ((314-1)*4)+2=1254

Attention l'adresse résultante ne peut dépasser 2048, donc pas de transpo possible pour des adresses origines supérieures à 510


Vu le prix je ne regrette pas l'opération.    

A+

Alain

Donc, en fait, chaque sortie a une adresse...?
Il y a intérêt à démarrer bas...
Pourquoi ne pas ré-adresser tes décodeurs..?

Eh oui j'ai découvert que chaque sortie a une adresse.
Je n'ai pas de problème de plage d'adresse puisque mes décodeurs avait des adresses qui commençait à 300. Y'a de la marge.

J'ai aussi essayé le SPROG avec DecoderPro pour lire les CV de mes SwitchPilot, mais ne n'y suis pas arrivé.

A+

Alain

Larist a écrit:

Par contre j'ai patiné pour entrer les adresses.
Car dans TC si on définit SPROG Family pour un aiguillage on ne peut pas entrer une adresse en 2 parties comme pour une centrale. Il n'y a qu'une seule case "adresse".

Ta remarque m'a fait sursauter  

Pour les centrales, comme tu dis, on donne une adresse spécifique à chaque sortie du décodeur d'aiguillage.

Je viens de vérifier avec Intellibox, Lenz et ECOS, on donne une adresse à chaque aiguillage et pas du tout un couple Adresse/Sortie.

Sprog family n'est donc pas une exception sur ce point ... c'est plutôt Zimo qui le serait.

Je pense que tu es allé chercher une formule très savante pour pas grand chose. Essaye de donner à ton premier décodeur d'aiguillage la plage d'adresses 1 à 4. A mon avis les sorties vont prendre chacune de ces adresses et le Sprog va les bouffer sans aucune peine.

Voici l'onglet "Connexion" d'une de mes aiguilles



Jean

Jean_01 a écrit:

Pour les centrales, comme tu dis, on donne une adresse spécifique à chaque sortie du décodeur d'aiguillage.

Je ne connaissais que le système du couple adresse du décodeur et no de sortie. J'ai toujours travaillé avec car tant la doc d'ESU que celle de TC avec Zimo fonctionnent ainsi. En cherchant je m'aperçois qu'effectivement il y a la notion d'adresse d'aiguillage directe.

Je n'ai pas pensé à changer l'adresse de mes aiguillages mais de toute façon je ne l'aurais pas fait pour différentes raisons :
- il aurait fallu changer les étiquettes sur mes décodeurs (17) et mes servos (57)
- pour les mises à jour des CV sur mes SwitchPilot, je suis toujours obligé de passer par la commande à main de ma centrale (pas trouvé de possibilité logicielle avec le SPROG, pas même DecoderPro) et mon système d'adressage actuel est un point de repère familier,
- j'ai entré dans un fichier la valeur de mes CV pour chaque SwitchPilot et là aussi il aurait fallu transposer.

A+

Alain

Pour la valeur des CVs des SwitchPilots, je ne suis pas sûr que ce soit bien utile... si tu dois changer un servo, ça m'étonnerait que le réglage soit le même...

DiCoS69 a écrit:

Pour la valeur des CVs des SwitchPilots, je ne suis pas sûr que ce soit bien utile...

Je m'en sert (rarement) pour un réglage complémentaire (servo qui se met à grésiller en butée ou aiguille qui plaque mal).

A+

Alain

Là d'accord...!
C'est vrai qu'il n'y a pas de lecture possible... mais, ne sont-ils pas aussi réglables avec les µ-switchs ?

DiCoS69 a écrit:

ne sont-ils pas aussi réglables avec les µ-switchs ?

C'est quoi les µ-switchs ?
Les butées de déplacement des servos sont dans les CV du SwitchPilot. Je ne vois pas d'autre  solution que de modifier ces CV.

A+

Alain

bonjour Alain
bon je n'ai pas trouver le signe MU  sur mon ordi mais tu doit lire:  micro-switch ce que l'on peut traduire par: très petit interrupteur
PS on les trouve aussi sous l’appellation: DIP-switch

Larist a écrit:

DiCoS69 a écrit:

ne sont-ils pas aussi réglables avec les µ-switchs ?

C'est quoi les µ-switchs ?
Les butées de déplacement des servos sont dans les CV du SwitchPilot. Je ne vois pas d'autre  solution que de modifier ces CV...

Les switchs de programmation des déplacements des servos ne sont, à ma connaissance, disponibles que sur les "Switchpilot Servo" ... Je trouve effectivement ces switchs plus pratiques que de mofifier les CV's ...  

A+
Georges

Geo69 a écrit:

Les switchs de programmation des déplacements des servos ne sont, à ma connaissance, disponibles que sur les "Switchpilot Servo" ... Je trouve effectivement ces switchs plus pratiques que de mofifier les CV's ...  

Effectivement en relisant la doc il y a 2 boutons pour le réglage du débattement. Je vais essayer la prochaine fois.

Merci pour le tuyau.

A+

Alain