JMRI et connexion DR4088RB

[Suzdal]

J'ai rencontré un petit problème chez un copain. Il possède un DR5000 connecté à un DR4088RB. Le DR5000 est connecté par câble USB à un PC (Windows 10). Le DR4088RB est bien connecté au DR5000 par un câble réseau à la prise XN+FB/BUS. Le tout fonctionne parfaitement. On place une locomotive sur un canton; il est bien détecté à l'adresse qu'il faut dans la fenêtre du Monitor du FB-Bus.

Jusqu'ici tout est parfait !

JMRI contrôle bien l'alimentation et les aiguillages.

Le problème se situe au niveau du DR4088RB. Pour JMRI les rails ne sont pas occupés. J'ai l'impression que JMRI n'arrive pas à lire les sortie du DR4088RB à travers le DR5000. Je pense que c'est un problème de paramétrage de JMRI, vis à vis le DR5000, utilisé un XpressNet.

Les paramètres que j'ai retiré du manuel (en français), si j'avais bien compris, étaient:

System manufacturer: Roco
System connection: Lenz LIUSB
Serial port: COM13
Connection Prefix: X
Connection Name: XpressNet

Avec LocoNet et un DR4088LN, aucun problème.

Quelqu'un a-t-il quelques idées pour nous aider ?

Richard

Edited on Thursday, 11 November 2021 at 12:44 (GMT + 1) à Blainville s/mer Normandy, France;
sent later.

[jc59]

Bonjour,

Il s'agit peut-être du décalage de 512 pour les adresses en XPressNet, la DR5000 étant "vue" comme une Lenz.

Pour l'adresse 1 du DR4088 et bien reconnue par le moniteur de la DR5000, essaie de déclarer l'adresse 513 sous JMRI.

Jean-Claude

[Suzdal]

Jean_Claude,

J'ai transmit les informations vers mon copain On va essayer.

D'où vient cette décalage de 512. Je ne l'ai vu documenter nul part.

Merci,

Richard

Edited on Thursday, 11 November 2021 at 14:55 (GMT + 1) à Blainville s/mer Normandy, France;
sent later.

[jc59]

Rebonjour,

Lenz démarre ses adresses de rétro en XPressNet à 513.

Pas mal de systèmes ont conservé ce standard Lenz-XPressNet. J'avais cherché aussi lorsque j'avais fait des essais avec CDM-Rail et la DR5000 ("vue" comme une Lenz) ; pour les rétros en s88, je devais tenir compte de ce décalage de 512.

Mon réseau fonctionne en Loconet avec TrainController, sans cette gymnastique de décalage d'adresse.

Jean-Claude

[Suzdal]

Jean-Claude,

Dès que mon copain revient de son dîner d'anciens combattants, nous essayerons.

C'est à arracher ses cheveux.

Mon réseau fonctionne en LocoNet aussi.

Richard

Edited on Thursday, 11 November 2021 at 16:57 (GMT + 1) à Blainville s/mer Normandy, France;
sent later.

[PhilHO95]

Rebonjour,

Lenz démarre ses adresses de rétro en XPressNet à 513.

Jean-Claude

Ce n'est pas exact: le bus RS permet de retro-signaler des adresses à partir de 1 jusqu'à 1024.
Mais le fait est que LENZ avait réservé les adresses de retro de 1 à 512 pour la retro signalisation des positions d’aiguillages, en commun avec les adresse accessoires DCC de 1 à 512, et avait donc décalé les adresses pour les modules de retro-signalisation de cantonnement de 513 à 1024.

Mais les protocoles du bus RS et des bus Xpressnet ne font pas la différence, ni de "décalage" automatique.

Donc si vous voyez l'activation des modules de retro à partir de l'adresse 1 sur la DR5000, vous devriez le voir aussi à l'adresse 1 sur votre logiciel de gestion de train.

[jc59]

Bonjour,

Ce décalage est nécessaire pour certains logiciels, par exemple pour CDM-Rail comme je le citais plus haut. La DR5000 y étant déclarée comme une Lenz, une occupation de canton à l'adresse 1 d'un module DR4088 apparaît bien à l'adresse 513 dans CDM-Rail.

Jean-Claude

[PaulXpress]

Bonjour,

Ce que j'ai trouvé à ce sujet sur un autre forum semble confirmer les propos de Jean-Claude :
Le problème réside dans la façon dont JMRI interprète le signal provenant du DR40088RB. La façon dont cela fonctionne a été définie à l'origine par LENZ dans XpressNet, puis suivie par ce qui semble être TOUS les développeurs de logiciels (JMRI, RocRail, iTrain, ...).
Ce qui se passe est le suivant : Supposons que j'ai un DR40088RB avec l'adresse de départ 17, et que la broche 5 est connectée à un bloc occupé.
Cette occupation s'affiche correctement sur le moniteur à l'adresse 22 (17+5). Ceci n'est cependant pas reconnu par JMRI. Le logiciel ajoute 512 à l'adresse. En d'autres termes, je dois spécifier l'adresse de bloc pour le capteur comme 534 (22+512) dans JMRI. En faisant cela, JMRI répond correctement à l'occupation de bloc définie comme 22 dans la paire DR40088RB, DR5000. Il en va de même pour RocRail.

Après d'autres recherches, j'ai trouvé que dans le protocole XpressNet, les 512 premières adresses de rétro-signalisation sont réservées au retour de commutation des aiguillages. C'est pour ne pas avoir de chevauchement, que les adresses de rétro-signalisation d'occupation sont décalées de 512.

Jean-Paul

[Jacques26]

Bonjour,
On est bien d'accord que le décalage de 512 adresses est le fait du protocole XPressnet.
Si on remplace le protocole XPressnet par un protocole LocoNet, les adresses sur la centrale et dans le logiciel, sont alors identiques.
Slt.
Jacques

[PhilHO95]

Bonjour,
On est bien d'accord que le décalage de 512 adresses est le fait du protocole XPressnet.
Si on remplace le protocole XPressnet par un protocole LocoNet, les adresses sur la centrale et dans le logiciel, sont alors identiques.
Slt.
Jacques

NON, pas d'accord. Moi j'arrive à utiliser la retro-signalisation à partir de l'adresse 1 avec RocRail.
Centrale Paco NanoX88, interface RS2PC, module de retro sur bus RS.
Donc la limitation n'est pas du au bus XpressNet ni au bus RS.

Et autant que je me souvienne, dans mon premier club, avec la DR5000 et des modules de retro-signalisation sur bus RS, il était aussi possible de choisir des adresses de retro-signalisation à partir de l'adresse 1 (protocole XpressNet-USB et logiciel maison en Visual Basic).

ATTENTION que la DR5000 est configurée par défaut pour décaler les adresses des entrées de retro-signalisation du bus RB de 64x8 = 512 avant des les envoyer sur le bus XpressNet-USB vers le PC.
Configurer le paramètre 11 à 0 ou 1 devrait résoudre le pb.