OpenDCC Z1 - Station de commande pour DCC - Commentaires

Introduction

Voici un résumé des divers aspects (plages d'adresses et correspondance, taux de rafraichissement, etc.) relatives à la station de commande OpenDCC Z1.

Mise en œuvre physique et synchronisation du bus S88 de rétrosignalisation

Les bus de données et d'horloge S88 sont générés par «bit-banging» dans le logiciel de la station de commande. Les réponses des modules de rétrosignalisation sont lues périodiquement par un processus, qui est appelé en boucle. La fréquence minimum de synchronisation est garantie par une horloge matérielle. La fréquence maximale peut varier, en fonction de la charge en cours du processeur, de sorte que les signaux CLK, LOAD, RESET puissent être légèrement désynchronisés (jitter) une certaine instabilité. Mais ce n’est pas critique.
Le timing est réglable par pas de 10 us, le réglage par défaut est 20μs pour une grande ou plus petite largeur d'impulsion. OpenDCC Z1 est donc probablement l'un des la mise en œuvre de s88 plus rapide.
Les trois sorties sont lues en même temps, de sorte que la plus longue chaîne de S88 détermine le nombre d'impulsions d'horloge. Exemple: en considérant 288 modules de Feedback connecté, qui sont divisés en trois chaînes: un cycle de lecture complète durera 5ms.

Protocole avec l’ordinateur de contrôle

Il ya trois différents protocoles disponibles pour envoyer des données à l'ordinateur, ceux-ci ont les caractéristiques suivantes:


Protocole

Intellibox (p50xb)

Lenz (XpressNet)

Littfinski HSI88

max. Nombre de Bits:

1024

1024

496

divisé en:

je 8

je 4

je 16

ordre des bits:

inversé

normale

normale

la technologie:

interrogation

poussée Service

poussoir

L'un de ces protocoles peut être sélectionné comme le protocole préféré lors de la compilation, (évidemment, avec HSI88 il n’y a pas de sortie en DCC) normalement, je réalise mes tests avec p50xb.

Note sur la méthode d’interrogation du protocole Intellibox:
OpenDCC tente de collecter les états des détecteurs dès que possible pour assurer une réponse immédiate par l’ordinateur de contrôle. Donc généralement les bits de rétrosignalisation à l'intérieur du poste de commande (logiciel sur l’ordinateur de contrôle – rocrail par exemple)  sont un miroir des bits du détecteur. Il peut arriver que le bit de détection remonte à 0 avant que l'évènement n’ait été capté par l’ordinateur de contrôle. Dans ce cas, cet évènement sera manqué. La station de commande n’intègre pas de bits de détection. Mais le bit d’information comme quoi un changement de bits de rétrosignalisation à eu lieu sera signalé de toute façon !  Cela conduit à une contraint: La fréquence d’interrogation du logiciel du poste de commande doit être supérieure au temps de maintien des détecteurs ou à la fréquence de lecture du bus S88.

Affectation d'adresses
Il y a quatre plages d'adresses au sein de la station de commande pour la rétrosignalisation. Ces zones sont séquentielles, il est permis qu'une zone ait une longueur de 0 octet.


gamme

1

2

3

4

Assigné à:

S88-1

S88-2

S88-3

 position des aiguilles

définie par:

CV9

CV10

CV11

CV16


Les plages d’adresse des S88-1, -2 et -3 sont définies chacune par leur taille (nombre de bits de rétrosignalisation en unités de 8 bits chacun) et se rejoigne. Il est important de s’assurer que les tailles respectives soient définies correctement, sinon les bits de rétrosignalisation seront mal interprétés. Le début de la fourchette pour  le retour de positionnement des aiguillages est défini par CV16, il est donc possible, qu'il existe un écart dans les bits de rétrosignalisation. Avantage: Lorsque vous ajoutez un autre module S88, les adresses de rétrosignalisation des aiguillages ne changeront pas.

Lors de l'utilisation p50xb les quatre plages sont portées dans les commandes de rétrosignalisation standard, les bits pour le retour de positionnement des aiguillages sont tout simplement mis dans la plage normale de bits de rétrosignalisation. L'analyse si une aiguille a atteint sa position finale doit alors être faite par le programme du poste de commande.

XPressNet et l’information de positionnement des  aiguillages et de rétrosignalisation

Dans le cas de XPressNet, des limitations surviennent, car les aiguillages et la rétrosignalisation partagent l'espace d'adressage. D’après la documentation de chez Lenz,  il y a 1024 adresses de rétrosignalisation, qui sont codées comme suit: octet 1 dispose d'une gamme 0..127 et chaque octet couvre 8 bits de rétrosignalisation (1024 = 128 * 8).
D'autre part, cette plage est destinée aux 1024 aiguillages possibles, octet 1 dispose d'une plage de 0..255, et quatre aiguillages sont adressés avec les octets (256 * 4 = 1,024). Les plages d'adresses se chevauchent les unes les autres, de sorte qu'il  aura un maximum de 2048 bits adressés.
0                                                  1024                                         2048
| -------- --------- rétrosignalisation |
| ----------------------- --------------------- aiguillages------------------- |

En regardant ce graphique, on peut voir que seuls 512 aiguillages peuvent avoir signal de retour de position et cette plage chevauche avec la détection d'occupation de voies.

Quelles sont les conséquences pour OpenDCC?

OpenDCC peut gérer rétrosignalisation externe / dispositifs d'occupation (comme S88) et rétrosignalisation interne en parallèle, donc il faut affecter l'utilisation de l'espace d'adresse commun:
• Si une commande d’aiguillage est confirmée par un message diffusé (Broadcast comportement standard Expressnet  ), ce message d’acquittement se superpose nécessairement aux détecteurs S88, si l'adresse de l’aiguillage est <512. La conséquence : lors de l'utilisation des périphériques de s88, est qu’il n’est pas possible d'attribuer des adresses pour les aiguillages > = 512, ce qui est désagréable.
• Si toutefois l'on tente d'échanger les rôles (c.-à commencer l'espace d'adresse pour les aiguillages à l'adresse 0 et un décalage des bits de rétrosignalisation), puis une différenciation sur la base de l'octet 1 est nécessaire. Cela conduira à des restrictions suivantes:


Octet 1:

sens

0..63

Cette plage 0..63 est affectée aux accessoires DCC et est remplie de l’information de rétrosignalisation des décodeurs (plage 4). Cela signifie que 256 adresses d’aiguillages sont disponibles.

64 127 ..

Cette plage est interprétée comme plage de retour (ce est à dire les détecteurs d'occupation commencent à 513 ou à l'unité 65-1). Cela signifie que 512 adresses possibles pour les détecteurs.

Mise en œuvre dans OpenDCC

J’ai opté pour le deuxième choix: les détecteurs matériels externes (bus S88, les rangs 1, 2 et 3 ci-dessus) sont envoyés comme broadcast de rétrosignalisation (avec les bits TT = 10) en commençant par l'adresse 513. Modifier la position d’un aiguillage va induire la diffusion (Broadcast)  d’une information de commutation d’accessoire, mais seulement 256 aiguillages seront supportés. Ce Broadcast est émis lorsque la bobine est désactivée et que l’information de position correspondante est arrivée à la station de commande.
La plage 4 est indexée avec l'adresse de l’aiguillage.

Il est possible de changer ce mode d’adressage pour des cas spéciaux (c’est à dire très si vous avez un grand nombre de bits de rétrosignalisation) au moyen du CV29.

Fonctionnement en multiprotocole

OpenDCC (version OpenDCC_XP) et peut gérer le protocole p50xb et XPressNet ™ en parallèle. A cet effet, les indicateurs de changements correspondants aux deux interfaces sont maintenus en double. Cela permet d’avoir à la fois le mode « poussée » (utilisé par XPressNet) et le mode d’interrogation du p50xb. Aucun évènement de détection d'occupation ou de rétrosignalisation est perdu quel que soit le protocole.