Séparation flux DCC pour locos et accessoires ?

Bonjour,

En jetant un oeil sur la doc de la Redbox Tams pour vérifier son alimentation, un paragraphe m'a interpelé :
"As a standard, the commands to control the vehicle decoders are sent continuously via thecentral unit ́s booster output, whereas the commands to control the accessory decoders are sent only when required. For that purpose the transmission of vehicle decoder commands is interrupted shortly, to transfer the accessory decoder commands during the resulting cutout.   In PC controlled (larger) layouts, this kind of data transfer can cause problems, e.g. whenvehicle decoders receive stop commands too late and this results in locomotives passing stopsignals. Usually two central units are used to solve this problem. They control vehicle andaccessory decoders separately (and are controlled by the PC software accordingly).   With MasterControl and RedBox you can switch off the transmission of accessory decodercommands at the booster output. Then, only vehicle decoder commands will be transferred andthe delay caused by the transmittsion of accessory decoder commands is excluded.That way, MasterControl and RedBox (versions "Booster" and "Booster-R") allow to control vehicle and accessory seperately with one central unit."
En synthèse, dans le cadre d'une commande par PC, il est conseillé de séparer les commandes des locos des commandes des accessoires pour ne pas retarder la réception d'une commande de vitesse d'une loco. Cette option devrait intéresser ceux qui sont pointilleux sur la précision des arrêts de leurs trains...  
Perso, je sépare déjà les flux DCC/locos et DCC/accessoires via deux centrales (Lenz+Sproc). Avec une centrale Tams, si je comprends bien, on peut paramétrer le choix DCC/locos ou DCC/accessoires au niveau de chaque booster (interne ou externes).
A condition de prévoir des bus séparés pour le "DDC voies" et le "DCC accessoires", cette option me paraît intéressante ...

A+
Georges

Voilà qui prouve que Mr Tams, il réfléchit quand il conçoit sa centrale...

Et ça, ça va intéresser Bernard pour le club de Lille Modélisme...

Euhhhhh ... Les gars ... Je ne suis pas tout à fait d'accord sur la rapide synthèse de Georges.

Dans le texte en anglais, il n'est question que de:

1) grands réseaux pilotés par un logiciel

2) ordres d'arrêt de locos qui pourraient parvenir un peu en retard et provoqueraient un arrêt après le signal.

Dans le cas d'une exploitation avec TC, le délai de réception de la commande d'arrêt pour une loco à vitesse de seuil ne doit guère provoquer qu'un arrêt décalé de 1 ou 2 cm ... très facilement récupérable dans le paramètre de distance du marqueur d'arrêt.

Cela limite quand même pas mal l'intérêt de la suggestion de séparation des flux.

Pour faire court, le texte cité me paraît plus un argument commercial pour vanter la fonctionnalité offerte par TAMS qu'un argument décisif pour la prise de décision d'achat d'une centrale digitale.

Jean

Bonjour,

Pour les (grands) réseaux à gros trafic il est fortement conseillé de séparer rétrosignalisation / commandes accessoires / commandes trains. Ceci peut se faire physiquement par 3 systèmes indépendant ou dans le cadre de la MasterControl/RedBox, qui possède 2 sorties Booster, en paramétrant les sorties Booster. Possédant aussi une MasterControl j'ai pu mettre cette séparation en pratique car j'avais dès le départ câblé un bus pour les accessoires (signaux et aiguillages) de manière séparée par rapport au câblage de la voie (courant traction). Je trouve que cela est une très bonne idée et devrait être également proposé chez ESU par exemple.

Jean_01 a écrit:

...le délai de réception de la commande d'arrêt pour une loco à vitesse de seuil ne doit guère provoquer qu'un arrêt décalé de 1 ou 2 cm ...

Bonjour,
Il ne faut pas oublier tout les autres ordres de vitesses envoyés par la centrale pour arriver à la vitesse de seuil, là aussi il peut y avoir quelques retard surtout quand des commutation d'accessoires sont faites à ce moment même... et pas seulement le passage de la vitesse de seuil à l'arrêt.

Et si on pousse un peu plus loin le raisonnement:

Les retards de commutation d'accessoires ralentissent aussi la libération des cantons et par conséquent l'application des ordres de vitesse aux locos.

Et si on veut vraiment qu'il n'y ait aucun retard sur les bus, il faut que le bus accessoires ne reçoive que les ordres le concernant. Donc, il faut que tous les systèmes digitaux équipant le réseau soient capables de faire le tri des ordres émis par la centrale sinon le bus accessoires qui reçoit aussi les ordres envoyés aux locos va prendre du retard sur les commutations d'accessoires

Moralité, équipez votre réseau de centrales TAMS car les autres ne savent pas faire le tri.

Jean toujours très sceptique sur ce coup là.

P.S: quelqu'un a-t-il une idée de l'ordre de grandeur réel des retards d'exécution de commandes?

Bonjour,

Jean_01 a écrit:

... Dans le cas d'une exploitation avec TC, le délai de réception de la commande d'arrêt pour une loco à vitesse de seuil ne doit guère provoquer qu'un arrêt décalé de 1 ou 2 cm ... très facilement récupérable dans le paramètre de distance du marqueur d'arrêt...

Le problème est qu'il y a plus ou moins d'envoi de commandes d'accessoires ou pas du tout lors d'une commande d'arrêt. Donc difficile de récupérer un écart ponctuel aux niveau des marqueurs virtuels ...

Yann a écrit:

... Je trouve que cela est une très bonne idée et devrait être également proposé chez ESU par exemple.

Sur le principe moi aussi bien que ce soit pour une autre contrainte que j'ai séparé les flux ...  

Jean_01 a écrit:

...  quelqu'un a-t-il une idée de l'ordre de grandeur réel des retards d'exécution de commandes?

...      

A+
Georges

Il faut dissocier les choses à mon sens:
Le bus de rétro n'est pas concerné par des retards important car le dialogue se fait directement entre la centrale et le PC via USB, Ethernet ou autres.
De plus le dialogue est bidirectionnel.

Pour le bus DCC, point de retour ( exclu Railcom….), on envoi en espérant que cela marche!
Par exemple avec une Z21 un accessoire reçoit à la suite 20 messages ( il y répétition pour être sur du coup et encore!).
Les 20 messages se composent de 10 messages avec activation du décodeur et 10 messages de désactivation du décodeur.
Sachant qu'un message comporte 5 octets, cela fait 100 octets transmis soit 800 bits à transmettre.
Le temps moyen pour transmettre un bit étant de 160 µs, il faut 800 x 160 µs=128000 µs soit 0,128 s.
Cela me semble le retard maxi possible à partir du moment où la commande est envoyée par la centrale.

Claude

Geo69 a écrit:

Yann a écrit:

... Je trouve que cela est une très bonne idée et devrait être également proposé chez ESU par exemple.

Sur le principe moi aussi bien que ce soit pour une autre contrainte que j'ai séparé les flux ...  
A+
Georges

Oui, et dans ton cas, c'est TC qui se charge de la répartition, cela ne se fait pas au niveau des centrales.

DiCoS69 a écrit:

Geo69 a écrit:

Yann a écrit:

... Je trouve que cela est une très bonne idée et devrait être également proposé chez ESU par exemple.

Sur le principe moi aussi bien que ce soit pour une autre contrainte que j'ai séparé les flux ...  
A+
Georges

Oui, et dans ton cas, c'est TC qui se charge de la répartition, cela ne se fait pas au niveau des centrales.

TC ne sait pas prioriser les ordres qu'il confectionne vers les décodeurs. Je ne suis donc pas certain que TC fasse une quelconque répartition selon les types d'ordres envoyés. En êtes-vous si sûrs que ça?

Jean

Jean_01 a écrit:

DiCoS69 a écrit:

Geo69 a écrit:

Yann a écrit:

... Je trouve que cela est une très bonne idée et devrait être également proposé chez ESU par exemple.

Sur le principe moi aussi bien que ce soit pour une autre contrainte que j'ai séparé les flux ...  
A+
Georges

Oui, et dans ton cas, c'est TC qui se charge de la répartition, cela ne se fait pas au niveau des centrales.

TC ne sait pas prioriser les ordres qu'il confectionne vers les décodeurs. Je ne suis donc pas certain que TC fasse une quelconque répartition selon les types d'ordres envoyés. En êtes-vous si sûrs que ça?

Jean

Jean, dans le cas de Georges, la répartition se fait lors de l'indication fournie au niveau du système numérique de chaque élément.
Pour la Tams, cela se passe au niveau du µC de la centrale.

DiCoS69 a écrit:

Jean, dans le cas de Georges, la répartition se fait lors de l'indication fournie au niveau du système numérique de chaque élément.

Certes le système numérique est indiqué, mais je pense que les paquets sont envoyés par TC en masse et que chaque système prend ce qui lui revient et cela avec ou sans retard. Le flux qui va vers les accessoires peut rester un certain temps à attendre des ordres au beau milieu des ordres pour les locos et vice versa. Bref il peut y avoir des retards soit pour les uns soit pour les autres.

Du genre: "tuez les tous, Dieu reconnaîtra les siens".

Jean

Chaque "système numérique" ayant sa connexion, je ne vois pas pourquoi TC enverrait tout en bloc à tous les systèmes simultanément, ou alors, indiquer le système ne sert à rien...

Demande à Freiwald comment il envoie

De toutes façons, TC travaille en séquence ... donc, si les envois sont séparés, c'est chacun son tour.

Jean

DiCoS69 a écrit:

Chaque "système numérique" ayant sa connexion, je ne vois pas pourquoi TC enverrait tout en bloc à tous les systèmes simultanément, ou alors, indiquer le système ne sert à rien...

Tout à fait d'accord, la centrale reçoit les ordres de TC qui lui sont destinées.
J'ai pu le vérifier récemment en utilisant une centrale pour les signaux et une centrale pour le reste.
Les trames émises par la centrale signaux ne comporte que des messages signaux.
Cela veut dire que TC échange des requêtes avec uniquement avec la centrale concernée.
C'est très logique chaque centrale ayant son adresse IP dans TC (pour les Z21).

Claude

claude1 a écrit:

DiCoS69 a écrit:

Chaque "système numérique" ayant sa connexion, je ne vois pas pourquoi TC enverrait tout en bloc à tous les systèmes simultanément, ou alors, indiquer le système ne sert à rien...

Cela veut dire que TC échange des requêtes avec uniquement avec la centrale concernée.  

Et pendant ce temps, l'autre ou les autres centrale(s) attend(ent) son(leur) tour.

Avant de dégainer les arsenaux utiles pour piloter le Miniatur Wunderland de Hambourg ne serait-il pas mieux d'optimiser le paramétrage de vos réseaux?

Mais bon ... ce que j'en dis.

Jean

Ben là Jean, on discute seulement... je n'ai personnellement pas grand-chose à reprocher au fonctionnement de TC ni de ma centrale.
Mais, il arrive quelque fois qu'un arrêt soit franchement décalé dans une séquence de circulations, sans en saisir la raison, ce qui pourrait être expliqué par le phénomène évoqué par Tams... bien qu'il puisse y avoir d'autres raisons...
J'ai plusieurs boosters dont un pour les accessoires, mais, pour l'instant, je n'ai pas séparé les envois tel qu'il est possible de le faire.