Configuration du DR5088RC de Digikeijs pour TrainController

Bonjour,

Voulant évaluer ce qu'il était possible de faire avec le RailCom et module de rétrosignalisation DR5088RC de Digikeijs et l'intégration dans TrainController, je m'en suis procuré un pour essais. Après beaucoup de temps passé autant à faire des essais que des recherche sur internet ou des mails, j'ai pris mon courage à deux mains et j'ai essayé de faire une description de ma configuration qui semble fonctionner.
J'aimerai bien que d'autres personnes relisent, au cas où ça ne serait pas clair. Vous êtes donc les bienvenus à me faire un retour après votre lecture. J'ai eu beaucoup de peine à expliquer cela de manière simple tout en essayant d'être assez complet et rigoureux...
Maintenant je vais faire une pause!  

Bonne lecture!

http://www.digi-train.ch/modelisme/DR5088RC.html

Bonsoir,

merci de ton étude qui m' interesse.

En Janvier 2020, nous avons fait des test, dans le groupe "cousin" espagnol, à propos du DR5088, la DR5000 (dernière mise à jour) et Lenz LZV100. Le tout sous TC9. Pour moi les résultats ont été très décevants.

Je vous laisse le liens. Si quelqu' un est vraiement très interessé je peux le traduire. mais je pense qu'il est compréhensible.

En fait, sous un ensemble tecnologique hétérogène, Railcom ne fonctionne pas de façon satisfaisante. En plus, TC9 ne fait aucun traitement des données par rapport aux réservation, seulement pour les occupations.

http://www.ctms1.com/forum/viewtopic.php?f=4&t=4282

A+

Merci Yann de ce travail.
Je n'ai pas encore tout lu en détail.
Concernant la gestion du retour railcom par TC, il y a un souci lors des empilages. Je crois que CAPITOLE l'avait déjà signalé.
Quand plusieurs locos sont sur le même canton, les retours d'information doivent se combiner et TC est amené à afficher des rames "fantômes" si la combinaison correspond à une loco en mémoire.
En l'état TC et railcom lors d'empilage est inutilisable. Ce n'est pas lié au DR5088 j'ai le même phénomène avec le module BLUECHER.
Peut être à noter en commentaire dans le document.

Vous croyez au père Noël...!
RailCom n'est qu'un système de communication remontant des infos délivrées en continu par chaque décodeur de loco qui en est équipé... ce n'est pas une application de gestion...!
Même sans RailCom, TC à du mal à isoler plusieurs trains sur le même canton, hors la fonction d'empilage, et encore, avec, c'est sous conditions...
Avant de demander la lune, essayez de comprendre la logique d'exploitation de TC, et essayez de l'utiliser au mieux, dans l'esprit de son créateur.
Il y a des moyens d'exploiter son réseau de façon réaliste et automatique, sans confier toutes les décisions au logiciel. La base de celui-ci, ce sont les trajets, ne jamais l'oublier... une exploitation de type "humain" (qui tient compte du visuel et de l'adaptation réfléchie), ce n'est pas de son ressort.

xaviermbcn a écrit:

Bonsoir,

merci de ton étude qui m' interesse.

En Janvier 2020, nous avons fait des test, dans le groupe "cousin" espagnol, à propos du DR5088, la DR5000 (dernière mise à jour) et Lenz LZV100. Le tout sous TC9. Pour moi les résultats ont été très décevants.

Je vous laisse le liens. Si quelqu' un est vraiement très interessé je peux le traduire. mais je pense qu'il est compréhensible.

En fait, sous un ensemble tecnologique hétérogène, Railcom ne fonctionne pas de façon satisfaisante. En plus, TC9 ne fait aucun traitement des données par rapport aux réservation, seulement pour les occupations.

http://www.ctms1.com/forum/viewtopic.php?f=4&t=4282

Bonjour Xavier,

Merci pour ton message. Malheureusement il faut être enregistré sur ton forum pour pouvoir visualiser le sujet. Si besoin, tu peux toujours me contacter par mp pour me transmettre un pdf du sujet de ton forum.
Le RailCom fonctionne très bien. Le problème c'est l'intégration dans TrainController qui est faible. Je connais et pratique d'autres configurations où l'implantation du RailCom est plus poussée et fonctionne bien. Un des problème de TrainController est sa notion de "Canton" dans lequel il ne peut reconnaitre qu'un seul véhicule, bien que le RailCom (avec l'activation du Channel 2) soit capable de reconnaitre jusqu'à 4 adresses par section de voie. Malheureusement aujourd'hui très peu de hardware savent exploiter le Channel 2 du RailCom et donc la reconnaissance de plusieurs véhicules sur une même section. De plus le RailCom ne se limite pas à cela, il permet aussi de lire les CV sur la voie principale, avoir un feedback de la qualité du signal (QoS), etc. Freiwald pourrait pousser plus loin l'intégration du RailCom dans son logiciel mais je crois que vu les part de marché que cela représente il n'as pas trop la motivation je crois bien...

philippech a écrit:

Concernant la gestion du retour railcom par TC, il y a un souci lors des empilages. Je crois que CAPITOLE l'avait déjà signalé.

Merci pour ton commentaire. Oui ça me dis vaguement qqch mais je n'ai pas pu retrouver le sujet, si qqun a un lien...?

philippech a écrit:

En l'état TC et railcom lors d'empilage est inutilisable.

Fort probable mais l'empilage est déjà une fonction avancée dans TrainController. Mon but était de voir si dans une configuration et une exploitation simple cela fonctionnait et la réponse est oui.

Bonjour,
Yann merci de toutes ces infos.

Sinon, est ce que quelqu'un sait à quoi sert le champ  "module number" dans l'onglet de configuration du module DR5088RC?


Le renvoi  3 indique la légende :
"module address in loconet"

Car ni TC, ni la centrale (Z21 pour moi) n'a besoin de ce nombre pour acquérir les informations de retrosignalisation.
Qui, au sens équipement, a besoin de ce renseignement sur un bus loconet ?

Avec 3 modules, en les reliant les uns aux autres, il n'y a nul besoin de modifier ce champ pour que ça marche.
Mais suite aux récents échanges concernant ce module, j'ai finalement mis 3 valeurs différentes sur mes 3 modules. Aucun impact sur les configurations des signaleurs dans TC et les retour de retro.

Est ce que ce "module number" défini un intervalle de temps propre à chaque module pour "parler" sur le réseau ?
Je ne sais absolument pas comment est conçu un bus loconet.

Si quelqu'un en sait plus sur le loconet sur ce sujet.
Merci

Bonjour,

philippech a écrit:

est ce que quelqu'un sait à quoi sert le champ  "module number" dans l'onglet de configuration du module DR5088RC?

Il s'agit simplement de l'adresse du module pour le paramétrer via le LocoNet uniquement, à aucun moment on a besoin de cette adresse du LNCV0 dans TrainController. Vu que le DR5088RC a un port USB exactement pour cela je trouve plus convivial de le faire via ce moyen. Néanmoins je suppose que l'on pourrait paramétrer ce module depuis une centrale ou un logiciel qui supporte la programmation via LNCV, mais je n'ai pas essayé cette méthode. La liste des LNCV est donnée en page 8 du manuel. Aussi, je ne sais pas si tout les paramètres que l'on trouve via l'interface USB et le logiciel de Digikeijs sont également tous présent dans la liste de la page 8.

Merci Yann de tes explications.
C'est très clair, j'ai compris.

Bonne journée

Yann,
Ma tablette sur laquelle est installée l'application Z21 étant avec un ancien androïd, (4.2.2) j'ai installé un émulateur d'android pour PC, et j'ai pu installer la nouvelle appli Z21.
L'avantage de la nouvelle application Z21 est qu'elle propose un possibilité de configuration des LNCV des modules à travers loconet.
Jusqu'à présent je configure les DR5088 via le port USB, mais deux modules sont difficiles d'accès pour aller y brancher un câble USB.
La possibilité d'aller modifier un paramètre via loconet, donc accessible depuis le PC "central", peut être intéressant
A+

Bonjour "philippech"

philippech a écrit:

L'avantage de la nouvelle application Z21 est qu'elle propose un possibilité de configuration des LNCV des modules à travers loconet.

Ok et vous avez essayé? ça fonctionne?

Bonjour Yann,
Tout d'abord je viens de m'apercevoir que l'ancienne appli Z21 proposait déjà la configuration des LNCV !
Je n'avais jamais fait attention à cette fonctionnalité.

Donc oui à prioiri ça fonctionne, mais cela reste moins pratique qu'à partir du port USB car il faut faire valeur par valeur.
Par contre, en ce qui concerne les adresses,  je constate un décalage de 1 entre la valeur du LNCV et la valeur de l'adresse.




Exemple :
Sur mon module qui possède l'adresse loconet 3, le premier détecteur à qui j'ai mis l'adresse 33 est vu à travers loconet LNCV 101 à 32 et tous sont décalés de 1.
Le premier détecteur de mon module 1 à qui j'ai mis l'adresse 1 est retourné en 0 avec le LNCV 101.

Hormis l'accès à la conf du module à partir du "poste central" de commande du réseau, la configuration via le port USB est bien plus pratique.

Bonne journée

philippech a écrit:

Hormis l'accès à la conf du module à partir du "poste central" de commande du réseau, la configuration via le port USB est bien plus pratique.

En configurant les modules sur la table, en USB, avant de les mettre en service, c'est très pratique...