Affichage cantons occupés à la mise en route de TC

Bonjour,
Mon réseau utilise une Z21 associée à des modules de rétro signalisation de deux types:
- Des Roco 10808 (transmission avec la centrale par bus CAN).
- Des Roco 10787 associés à des modules LDT GBM8 (transmission avec la centrale par bus Roco).

Lors de la mise en service du réseau l'affichage de l'occupation des cantons s'affiche immédiatement pour les 10808 (bus CAN), la communication TC avec la centrale se fait immédiatement.
Par contre pour les 10787 il faut attendre qu'un événement se passe sur le réseau, la communication entre la centrale et TC via le bus Roco n'est pas immédiate.

La commande "actualiser le réseau est sans effet pour ce problème.

Existe t il un moyen d'avoir l'affichage immédiat à la mise en service des cantons occupés pour le bus Roco?

Claude

Peut-être en modifiant le choix proposé dans la fenêtre de "Configuration des systèmes numériques"...

Bonjour, le fait d'avoir deux Bus de rétro différents y est peut-être pour quelque chose?
As tu essayé de connecter les 10808 sur le R-Bus?
A+

Merci pour vos réponses.

- La "Configuration des systèmes numériques" malgré l'utilisation de la commande "envoyer toutes les fonctions actives à la centrale" ne permet pas d'avoir cet affichage à la mise en service.
- Ce problème existait déjà lors de l'utilisation de 10887 sans 10808, aussi bien avec la Z21 qu'avec la multicentrale. Cela me semblait normal puisque tout les cantons régissaient de la même manière à la mise en service.

Cela ne gène pas le fonctionnement une fois un train parti, mais c'est frustrant!!!




Claude

Bonjour, bizarre, jamais vu ce genre de situation. Quand je ferme TC, je me mets en mode édition, je déconnecte et j'enregistre.
A la remise en route dès que je me reconnecte les cantons occupés sont immédiatement détectés...
A+

claude1 a écrit:

Merci pour vos réponses.

- La "Configuration des systèmes numériques" malgré l'utilisation de la commande "envoyer toutes les fonctions actives à la centrale" ne permet pas d'avoir cet affichage à la mise en service.
- Ce problème existait déjà lors de l'utilisation de 10887 sans 10808, aussi bien avec la Z21 qu'avec la multicentrale. Cela me semblait normal  puisque tout les cantons régissaient de la même manière à la mise en service.

Cela ne gène pas le fonctionnement une fois un train parti, mais c'est frustrant!!!Claude

Est-ce que c'est le démarrage de TC qui enclenche la mise en route de la centrale ou est-ce que tu la démarres avant de lancer TC ?

claude1 a écrit:

Bonjour,
Mon réseau utilise une Z21 associée à des modules de rétro signalisation de deux types:
- Des Roco 10808 (transmission avec la centrale par bus CAN).
- Des Roco 10787 associés à des modules LDT GBM8 (transmission avec la centrale par bus Roco).

Lors de la mise en service du réseau l'affichage de l'occupation des cantons s'affiche immédiatement pour les 10808 (bus CAN), la communication TC avec la centrale se fait immédiatement.
Par contre pour les 10787 il faut attendre qu'un événement se passe sur le réseau, la communication entre la centrale et TC via le bus Roco n'est pas immédiate.

La commande "actualiser le réseau est sans effet pour ce problème.

Existe t il un moyen d'avoir l'affichage immédiat à la mise en service des cantons occupés pour le bus Roco?

Claude

C'est presque idem chez moi : j'utilise le bus loconet et le bus Rbus.
Pour le Rbus, il faut qu'il y ait un changement d'état pour qu'il soit rafraichi.
Pour le bus loconet c'est plus étrange : le premier module de la chaine loconet est bien mis à jour au démarrage, mais pour mettre à jours les modules suivants, il faut faire un coup de "fleche verte" et là tous les détecteurs loconet sont rafraichis.
Comme chez toi cela ne gène en rien le fonctionnement.

Bonjour,
Cela fait plaisir de ne pas être le seul à avoir le même comportement.
Pour le moment le réseau est à 810 km, pas possible de faire des tests.

Dés que possible l'exploitation des pistes proposées sera faite.
La centrale est mise sous tension avant l'exécution de TC pour répondre à Elie, si ce n'est pas fait dans cet ordre TC grogne en indiquent "pas de système numérique".

Par contre je sors à "la sauvage" de TC en fermant la fenêtre de TC, je pense que je vais essayer suivant les indications de Coquelicot de faire une sortie plus propre de TC.

Si le comportement reste le même je bricolerai une macro déclenchée au lancement de TC en commutant une entrée libre d'un 10787.

Claude

claude1 a écrit:

La centrale est mise sous tension avant l'exécution de TC pour répondre à Elie, si ce n'est pas fait dans cet ordre TC grogne en indiquent "pas de système numérique".

Par contre je sors à "la sauvage" de TC en fermant la fenêtre de TC, je pense que je vais essayer suivant les indications de Coquelicot de faire une sortie plus propre de TC.
Claude

Je ne parle pas de la mise sous tension, mais de la mise en route du DCC (GO). Normalement, TC s'en charge au moment de l'ouverture pour établir la connexion.

Je ferme également TC en cliquant sur la croix de fermeture, en haut à droite, mais j'ai sélectionner "Arrêt à la fermeture" dans la fenêtre de "configuration des systèmes numériques".

Bonjour,

J'ai constaté le même problème depuis le début. Comme je n'ai que le Rbus, je n'ai pas pu observer de différences avec d'autres bus.
J'ai "résolu" le problème en cliquant (après chaque démarrage de RRTC) sur le bouton "connexion au système digital", bien que l'état "connecté" est indiqué en bas à droite de l'écran.L’ordre d'allumage RRTC / PC n' aucune influence sur le sujet, pas plus que la façon d’arrêter RRTC.
J'ai également noté une difficulté plus gênante, et toujours pas résolue à ce jour : je dispose d'une table tournante ROCO, commandée par un décodeur LDT, et qui fonctionne parfaitement en régime permanent. Lors du démarrage de RRTC, la table est bien synchronisée sur sa position physique, tant que je n'appuie pas sur le bouton "connexion". Dès que j'appuie sur ce bouton, les voies occupées apparaissent... et la table se met systématiquement en position "voie principale" sur le TCO, et quelle que soit sa position physique! Pour éviter les problèmes, je range toujours "physiquement" la table sur sa positon "voie principale" avant d’arrêter RRTC!
Un peu pénible...
François.

Retour tardif sur le sujet mais il fallait être au réseau pour essayer.
Les essais avec diverses solutions ne changent rien....
Seule solution trouvée: le doigt mouillé appliqué sur un canton utilisant le bus R.
Cela marche impec!!! Tout s'affiche correctement.
Claude

Cela s'appelle de la programmation au doigt mouillé. C'est une méthode parfois aléatoire mais quand ça marche il ne faut pas chercher à comprendre pourquoi...
Mort de rire

Bonjour,
Je reviens aussi sur ce sujet.
Lors du démarrage de RRTC, tout se lance correctement (programme "online" et "running", synchronisation de la table tournante OK), sauf l'état de l'occupation des cantons : aucune couleur d'occupation affichée.
Pour "rafraichir" l'état de l'occupation des cantons, j'ai essayé plusieurs solutions :
1/ appui sur le bouton "connexion" : les occupations apparaissent, mais la table se désynchronise.
2/ modification de l'occupation d'un canton : soit par déplacement d'un train, soit par dépose d'un wagon (essieux résistifs) sur un canton : les occupations apparaissent, mais la table se désynchronise.
3/ modification de la position de la table tournante par un bouton de commande sur la fenêtre de la table dans le TCO : les occupations apparaissent, et la table reste synchronisée!!!
Je reste perplexe....
Pour info, ma table tournante est une ROCO42615, commandée par un décodeur TT-DEC-R, et en dehors de ce souci au démarrage, le fonctionnement est parfait.
Suis je le seul confronté à ce problème?
Je continue d'autres essais pour tenter de trouver une explication et surtout une solution plus simple si elle existe.

Je pense que ce comportement est du au système Roco qui ne fait pas de "check up" de la rétro à la mise sous tension, ou qui n'envoie pas l'information tant qu'un état ne se modifie pas sur une entrée...
Cela pourrait être signalé au SAV Roco...

DiCoS69 a écrit:

Je pense que ce comportement est du au système Roco qui ne fait pas de "check up" de la rétro à la mise sous tension, ou qui n'envoie pas l'information tant qu'un état ne se modifie pas sur une entrée...
Cela pourrait être signalé au SAV Roco...

Bonne idée!!!
En espérant qu'ils ne disent pas que c'est TC qui oublie de lire la rétro....
Claude

J’ai cru comprendre que le problème n’existe pas avec le bus CAN. Est ce donc lié à ROCO?
Ce serait de le savoir avant de les traîner au tribunal pour les 63 prochaines années...

Le probléme n'existe pas avec le bus CAN et les 10808 associés à la Z21....
Le tout en matériel Roco!

Pas évident de savoir d'où vient le probléme... Bus R ou non lecture par TC?

Claude

François_74 a écrit:

J’ai cru comprendre que le problème n’existe pas avec le bus CAN. Est ce donc lié à ROCO?
Ce serait de le savoir avant de les traîner au tribunal pour les 63 prochaines années...

C'est bien le R-bus qui serait en cause, non...:?
Hors, ce bus n'est qu'un dérivé du S88...

J'ai craqué : je suis passé en bus CAN. Du coup, tout mon TCO fonctionne dès l'ouverture de RRTC, je n'ai plus aucune désynchronisation de ma plaque tournante à l'ouverture de RRTC, je n'ai plus aucune détection "furtive" (voir un de mes post précédents), et cerise sur le gâteau (mais pas très utile j'en conviens), RRTC détecte mes locomotives dotées d'un décodeur railcom (ça fait bien dans le tableau, et selon M. Freiwald, c'est une sécurité supplémentaire dans le cas ou un train entre dans un canton où il n'est pas attendu : le trajet s'arrête).
A faire pour ceux qui aiment bien que tout marche.... et qui acceptent de casser un peu leur tirelire, j'en conviens aussi!

Bonjour,

François_74 a écrit:

RRTC détecte mes locomotives dotées d'un décodeur railcom

Ah donc les modules 10808 avec RailCom, et comment cela se comporte-t-il quand 2 décodeurs ou plus (une traction multiples par exemple) rentre dans un canton sans que le train soit sous un trajet ?

François_74 a écrit:

...selon M. Freiwald, c'est une sécurité supplémentaire dans le cas ou un train entre dans un canton où il n'est pas attendu : le trajet s'arrête

Ah, tiens, Freiwald a maintenant changé son discours...? lui qui disait mordicus que le RailCom ne servait rien et a toujours méprisé les apports que pouvait avoir le RailCom, est-ce que Roco y serait pour quelque chose dans sa réponse ...

En UM, c'est la première loco arrivée sur le canton qui est affichée comme détection : la seconde n'est pas affichée. Mais la "sécurité" fonctionne bien.
Dans le manuel, le mot "railcom" n'est pas prononcé. Il n'est fait mention que de "détection de train".
L'honneur est sauf?

François_74 a écrit:

En UM, c'est la première loco arrivée sur le canton qui est affichée comme détection : la seconde n'est pas affichée.

Ok mais quand on fait une UM dans TrainController on a bien l'icône des 2 machines dans le canton et dès lors que l'on rentre dans un canton avec RailCom alors la deuxième est virée et on perd l'UM au niveau de TC... je comprend pas comment cela peut bien fonctionner...

Je précise le sens du mot "détection" dans ce contexte :
La détection au sens railcom dans ma phrase correspond à l'infobulle du bloc qui indique quelle locomotive est détectée au sens "identification de train de RRTC", et ce via railcom.
Sur le dispatcher, on a toujours bien les 2 locomotives.
Je confirme que cette détection de train relève plus du gadget pas très utile.
Ma vraie motivation du passage au bus CAN relève des problèmes cités précédemment.

François_74 a écrit:

RRTC détecte mes locomotives dotées d'un décodeur railcom (ça fait bien dans le tableau, et selon M. Freiwald, c'est une sécurité supplémentaire dans le cas ou un train entre dans un canton où il n'est pas attendu : le trajet s'arrête).

Enfin ! Car mince alors, TC ne prend jamais en compte le fait qu'une loco échappe au trajet prévu, elle continue, l'icône plantée dans le dernier canton connu. En dépit du fameux chien de garde ou je ne sais quoi. Heureusement qu'en général les aiguillages fonctionnent... En IIm je ne suis jamais à l'abri d'une brindille ou d'un gravillon qui bloque une lame.

Ne reste plus qu'à changer la rétrosignalisation ...

François_74 a écrit:

Je précise le sens du mot "détection" dans ce contexte :
La détection au sens railcom dans ma phrase correspond à l'infobulle du bloc qui indique quelle locomotive est détectée au sens "identification de train de RRTC", et ce via railcom.
Sur le dispatcher, on a toujours bien les 2 locomotives.
Je confirme que cette détection de train relève plus du gadget pas très utile.
Ma vraie motivation du passage au bus CAN relève des problèmes cités précédemment.

Ok, merci François pour ces précision, je comprend mieux.
Encore une petite question, combien de contacts de rétro. avez-vous par canton?