Incidence du debit sur le bus DCC pour les accessoires

Bonjour,
Rencontrant des problèmes pour commander un signal complexe via un décodeur de signaux, je me demande si le problème ne pourrait pas être lié au débit sur le bus DCC.
Le décodeur est commandé via un accessoire  étendu de TC utilisant trois inters afin de pouvoir contrôler les huit états possibles du signal.
Je précise que le signal pris à part  du réseau fonctionne parfaitement avec le contrôle par un TCO permettant
la configuration des déclencheurs de l'accessoire étendu.
Par curiosité j'ai regardé via un sniffer DCC les commandes envoyées par la centrale (Z21) et le temps nécessaire pour la commande de cet accessoire étendu est de l'ordre de 0.5s.
C'est la répétition des ordres par la centrale (10 fois pour une seule adresse) plus les préambules et les "idle packet" qui impose ce temps.
Je me demande vu ces ordres de temps si cela ne provoque pas des problèmes pour la transmission des ordres quand le réseau est au complet.
Hors signalisation aucun problème n'existe.
Un TC iste aurait il rencontré ce type de problème?
Claude

Est-ce ta première expérience de commande de signal complexe avec accessoire étendu ?
Comment se manifeste les problèmes ?
Quel décodeur utilises-tu ?
Quels sont les différents états du signal ?
Peux-tu nous mettre des copies d'écran du paramétrage des inters de l'accessoire étendu ?
C'est cet ensemble de choses qui assure ou non la réussite de l'entreprise...
Je pense que tu cherches beaucoup trop loin la cause du problème, mais il faut avoir toutes les données précédentes en main pour en juger.

Bonjour,
Mettez-nous aussi à disposition votre accessoire étendu pour qu'ont puisse voir ce qu'il fait précisément.

Bonjour,
Je vais commencer par la description de l'accessoire étendu faite par la commande gérer de TC.
Les signal est un signal à huit états présentant M, A, RR, S, A+RR, VL, R, C.

Le décodeur est un décodeur "maison" fait pour commander un signal complexe utilisant trois adresses accessoires successives (2048 adresses possibles), cela correspond aux signaux de commande accessoires envoyés par la Z21 ou la Multicentrale.


" />


Le premier état M:



Le deuxiéme état A:
" />


Le troisiéme état RR:
" />


Le quatriéme état S:
" />


Le cinqiéme état A+RR:
" />


Le sixiéme état VL:
" />


Le septiéme état R:
" />

Le huitiéme état C:
" />

La suite à venir.

Claude

La suite avec ce qui marche pour commencer:
Pour procéder aux essais j'ai le TCO suivant:

" />

Pour commencer (sans s'occuper des déclencheurs) des clics sur l'icône du signal permettent de faire dérouler tous les états.

Puis des conditions liées à la position des aiguilles sont mises pour les déclencheurs (pas de conditions)
Aiguille A1 adresse 1, etc....

" />

" />

" />

" />

" />

" />

" />

" />

Le changement de position des aiguilles provoquent bien l'affichage désiré du signal via le décodeur, il correspond parfaitement à celui affiché sur le TCO.
Aussi bien avec la Z21 que la multizentrale.

Voila pour ce qui fonctionne correctement.

La suite à venir.

Claude

claude1 a écrit:

Les signal est un signal à huit états présentant M, A, RR, S, A+RR, VL, R, C.

Le décodeur est un décodeur "maison" fait pour commander un signal complexe utilisant trois adresses accessoires successives (2048 adresses possibles), cela correspond aux signaux de commande accessoires envoyés par la Z21 ou la Multicentrale.
Claude

Généralement avec TC, un tel signal mobilise 4 adresses... pas seulement 3...

Bonjour,

DiCoS69 a écrit:

Généralement avec TC, un tel signal mobilise 4 adresses... pas seulement 3...

Pourquoi avoir quatre adresses quand trois suffisent!
Un signal deux feux: une adresse.
Un signal trois ou quatre feux: deux adresses.

C'est bien ce fait TC avec ses signaux tout faits.

Après avec les accessoires étendus un inter: une adresse, deux inters: deux adresses, trois inters: trois adresses, etc....

Donc pour différentier les huit états de mon signal trois adresses suffissent.
(Ce signal correspond à la signalisation lumineuse SNCF avant 1975, hors pré avertissement vert+jaune).

Claude

claude1 a écrit:

Bonjour,

DiCoS69 a écrit:

Généralement avec TC, un tel signal mobilise 4 adresses... pas seulement 3...

Pourquoi avoir quatre adresses quand trois suffisent!
Un signal deux feux: une adresse.
Un signal trois ou quatre feux: deux adresses.

C'est bien ce fait TC avec ses signaux tout faits.

Après avec les accessoires étendus un inter: une adresse, deux inters: deux adresses, trois inters: trois adresses, etc....

Donc  pour différentier les huit états de mon signal trois adresses suffissent.
(Ce signal correspond à la signalisation lumineuse SNCF avant 1975, hors pré avertissement vert+jaune).

Claude

Les signaux tout faits de TC fonctionnent avec 2 adresses pour 4 états (VL, A, S, C), donc 4 adresses pour 8 états... parce qu'il utilise des contacteurs inverseurs (il y a toujours un des 2 états qui est actif), et pas des interrupteurs qui peuvent  mettre chacun un état actif ou inactif...
C'est ce que tu fais également dans le paramétrage de ton accessoire étendu.

DiCoS69 a écrit:

C'est ce que tu fais également dans le paramétrage de ton accessoire étendu.

Oui mais avec trois adresses.
Trois messages consécutifs sont émis par la centrale via ordres de TC aux adresses n, n+1, n+2
Chaque message contient en dehors de l'adresse une donnée, cela fait donc un mot de trois bits de données qui correspond à la description de huit combinaisons qui correspondent aux états du signal.

Claude

claude1 a écrit:

DiCoS69 a écrit:

C'est ce que tu fais également dans le paramétrage de ton accessoire étendu.

Chaque message contient en dehors de l'adresse une donnée, cela fait donc un mot de trois bits de données qui correspond à la description de huit combinaisons qui correspondent aux états du signal.
Claude

Oui, mais les accessoires DCC "classiques" ne fonctionnent pas comme ça...
Sauf Zimo qui permet l'utilisation du package "accessoires étendus" de la norme, permettant le contrôle ON/OFF de chaque sortie, les autres travaillent toujours avec le principe de base Marklin... sur une commutation par paire (1 ON/ 2 OFF ou 1 OFF/ 2 ON)).

DiCoS69 a écrit:

Oui, mais les accessoires DCC "classiques" ne fonctionnent pas comme ça...
Sauf Zimo qui permet l'utilisation du package "accessoires étendus" de la norme, permettant le contrôle ON/OFF de chaque sortie, les autres travaillent toujours avec le principe de base Marklin... sur une commutation par paire (1 ON/ 2 OFF ou 1 OFF/ 2 ON)).

Je plussoie pour en avoir été "victime" au printemps dernier avec les décodeurs CDF... Seule la centrale Zimo sait "éteindre" un état A ou B déjà commuté.
(à priori, car je n'ai pas cherché à savoir si d'autres centrales d'autres fabricants peuvent exécuter cette fonction dont il semblerait qu'elle soit consubstantielle au DCC mis au point par... Lenz ! Peut-être la LZV 200 désormais... mais je n'ai pas encore fait l'échange !)

Bonjour,
C'est l'anarchie!!!!
J'ai du mal à comprendre que la centrale soit impliquée dans l'histoire.

La norme RCN-213 , extrait de la norme allemande qui explique avec rigueur, le format pour un accessoire de base ( pour 2048 adresses):

[img][/img]

Le bit D correspond à l'activation du fonctionnement de la sortie concernée, le bit R à la donnée de la sortie concernée.

En analysant les trames de la Z21 et la multizentrale, des Roco toutes les deux, je constate que cela correspond exactement à la norme.

Ces deux centrales émettent pour une commande dix messages, la seule différence se situe au niveau du bit D qui est à 1 pour les premiers puis à 0 pour les derniers.

Ce serait donc au décodeur, via son logiciel, d'exploiter les commandes de la centrale.

La commande par paires ne serait elle pas issue des début du DCC avec les premières centrales?

Claude

PS: Je poursuis bientôt avec le problème du départ.

La suite:

Le TCO concerné:

" />

Les déclencheurs du signal S1 (accessoires étendus décrit précédemment)

" />

" />

" />

" />" />

" />

" />

" />

Voila décrit ce qui me pose problème.

Claude

claude1 a écrit:

Ce serait donc au décodeur, via son logiciel, d'exploiter les commandes de la centrale.

Et oui... sauf nouveauté c'est bien ça...

claude1 a écrit:

La commande par paires ne serait elle pas issue des début du DCC avec les premières centrales?
Claude

Même plus loin... début du numérique avec Marklin Motorola.

claude1 a écrit:

La suite:

Le TCO concerné:

Voila décrit ce qui me pose problème.
Claude

Désolé Claude, mais les déclencheurs ne nous disent pas où est le problème...
Je suppose que tu as des défauts dans l'exécution, mais lesquels et à quel niveau ...?!

Bonjour,
J'ai peut être un début de piste:
Sur le réseau les zones d'aiguilles sont dans un canton qui comprend deux zones de détection.
Par exemple C7 comprend deux détection, idem pour les trois autres cas.
(Un vieux débat!!!!!)
En fonctionnement réel tout fonctionne correctement, hormis le signal!

Par contre en simulation, pour les zones prises en pointe, le train s'arrête et reste bloqué.

Le docteur signale ce genre de configuration comme ne lui plaisant pas.
En mettant une seule zone de détection cela marche en simulation.
Le signal fonctionne bien en simulation.

Malheureusement étant à 800km du réseau je ne peux pas procéder à des tests, il faudra attendre.  

Claude

PS: Je n'ai pas réussi à planter le décodeur avec la commande des déclencheurs avec le TCO décrit au début du sujet.

Ce qu'il y a de bien avec toi, Claude, c'est que c'est un monologue...
Finalement on ne sait plus de quoi on parle... l'essentiel, est que tu te comprennes ...

Je termine le monologue

Le manque de débit était bien la cause du problème avec mon décodeur "exotique" made in France fait par moi même.
En utilisant une centrale dédiée à la signalisation pas de problème, tout fonctionne très bien.
Le décodeur doit attendre trois ordres consécutifs DCC avant de prendre en compte la modification, cela n'est pas compatible avec le trafic dans le cas d'une seule centrale.
Reste à reprendre la programmation du décodeur pour le rendre standard.

Dommage que la norme correspondant au format
preambule 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1 pour les accessoires étendus
ne soit pas utilisée sur la Z21, elle l'est peut être sur d'autres centrales.

Claude

PS:Au moins cela oblige à réfléchir, il parait que c'est bon pour les neurones.

claude1 a écrit:

Dommage que la norme correspondant au format
preambule 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1 pour les accessoires étendus
ne soit pas utilisée sur la Z21, elle l'est peut être sur d'autres centrales.

Claude

Zimo sans aucun doute. A part cette marque, je ne vois pas.

claude1 a écrit:

Le décodeur doit attendre trois ordres consécutifs DCC avant de prendre en compte la modification, cela n'est pas compatible avec le trafic dans le cas d'une seule centrale.
Reste à reprendre la programmation du décodeur pour le rendre standard.
Claude

Il me semble que les commandes DCC pour les accessoires ne sont pas répétées par les centrales, seules les commandes loco le sont...

Bonjour,

Dans la gestion des images de signaux je ne comprend pas vraiment pourquoi beaucoup utilisent la position des aiguillages. Perso. j'utilise plutôt les itinéraires associés aux cantons avec le test du sens de circulation dans le canton, mais je n'utilise jamais la position direct des aiguillages.

DiCoS69 a écrit:

Il me semble que les commandes DCC pour les accessoires ne sont pas répétées par les centrales, seules les commandes loco le sont...

Pour la Z21 ou la multizentrale les commandes des accessoires sont répétées.

Au niveau des aiguilles et autres accessoires la commande délai dans TC augmente le nombre de répétitions.

Constat fait avec DCShow, logiciel qui permet de visualiser les trames DCC.

Claude

Yann a écrit:

Bonjour,

Dans la gestion des images de signaux je ne comprend pas vraiment pourquoi beaucoup utilisent la position des aiguillages. Perso. j'utilise plutôt les itinéraires associés aux cantons avec le test du sens de circulation dans le canton, mais je n'utilise jamais la position direct des aiguillages.

Il est intéressant d'utiliser la position des aiguilles si on veut faire fonctionner les signaux correctement pour une circulation hors trajet.
On place pour ça un groupe ET composé uniquement des indicateurs et des aiguilles.
Évidemment, la gestion est moins fine qu'avec un trajet, mais néanmoins reste fonctionnelle en manuel.
Ce qui n'empêche pas de prévoir également un fonctionnement avec trajet en positionnant un OU en tête de liste, suivi des différents groupes ET, OU, etc...

claude1 a écrit:

DiCoS69 a écrit:

Il me semble que les commandes DCC pour les accessoires ne sont pas répétées par les centrales, seules les commandes loco le sont...

Pour la Z21 ou la multizentrale les commandes des accessoires sont répétées.
Au niveau des aiguilles et autres accessoires la commande délai dans TC augmente le nombre de répétitions.
Constat fait avec DCShow, logiciel qui permet de visualiser les trames DCC.
Claude

Ce cas n'étant pas une généralité, je ne vois pas pourquoi le décodeur doit attendre une triple commande pour envoyer le changement d'état... si l'ordre est clair, il le passe, s'il ne l'est pas, il s'abstient, et si, comme tu le dis, il y a répétition, il passera l'ordre au coup suivant...
Si l'objectif est d'éviter d'éventuels "bagodements", le problème est plutôt dans le paramétrage des déclencheurs.

De quelle commande "délai" dans TC parles-tu ?

DiCoS69 a écrit:

Il est intéressant d'utiliser la position des aiguilles si on veut faire fonctionner les signaux correctement pour une circulation hors trajet.
On place pour ça un groupe ET composé uniquement des indicateurs et des aiguilles.
Évidemment, la gestion est moins fine qu'avec un trajet, mais néanmoins reste fonctionnelle en manuel.
Ce qui n'empêche pas de prévoir également un fonctionnement avec trajet en positionnant un OU en tête de liste, suivi des différents groupes ET, OU, etc...

Ah oui ok je vois... mais pour moi ce n'est pas parce que les aiguillages sont dans une position pour une voie et que le canton est occupé que le signal doit pour autant indiquer une voie libre. J'ai un autre concept de la chose. Pour moi, dans une zone gérée par TrainController il y a mouvement de train que si un trajet ou au moins un itinéraire est établi. Ce qui n'empêche pas de conduire son train manuellement depuis une commande à main.