OpenDCC - Zentrale für DCC - Rückmeldungen
Einleitung
-
Hier ist eine Zusammenfassung der verschiedenen Aspekte (Adressbereiche, Updateraten usw.) bei der Rückmeldung in OpenDCC.
Physikalische Implementierung, Timing
-
Die Kontrolle der S88-Leitungen erfolgt per 'Bit-Bang' durch Software.
Die Rückmelder werden innerhalb des Task-Schemas von OpenDCC mittels zylischer Abfrage eingelesen,
wobei die eingestellten Mindestzeiten durch eine Timerüberwachung garantiert werden. Die Maximalzeiten können
je nach aktuelle Prozessorlast etwas streuen, so dass die Signale CLK, LOAD, RESET etwas Jitter enthalten.
Dieser ist aber ohne Belang.
Die Zeiten sind in Schritten von 10µs einstellbar, in der Defaulteinstellung werden je 20µs für High und Lowzeit des Clocks verwendet. OpenDCC ist damit vermutlich eine der schnellsten s88-Implementierung.
Es werden immer alle 3 Stränge simultan eingelesen, wobei der längste Strang die Anzahl der Taktpulse bestimmt. Beispiel: 288 angeschlossene Rückmelder, welche auf 3 Stränge aufgeteilt sind werden ca. alle 5ms komplett eingelesen.
Hostprotokoll (zum PC)
-
Zum Absenden der Rückmeldungen sind 3 verschiedene Protokolle implementiert, diese haben folgende Merkmale:
Protokoll: | Intellibox (p50xb) | Lenz (xpressnet) | Littfinski HSI88 |
---|---|---|---|
max. Anzahl: | 1024 | 1024 | 496 |
unterteilt in: | je 8 | je 4 | je 16 |
Bitorder: | invers | normal | normal |
Technik: | Polling | Pushing | Pushing |
Eine Anmerkung zur Polling-Methode des IB-Protokolls:
OpenDCC versucht, möglichst zeitnah die Zustände der Melder einzulesen, um eine möglichst direkte Reaktion des PC zu gewährleisten. Dadurch entspricht der Zustand der Rückmeldebits in der Zentrale i.d.R. direkt den Zuständen der Melder. Wenn nun der Melder 'draußen' wieder auf 0 geht, bevor das interne Ereignis vom PC abgeholt worden ist, dann wird bei der PC-Abfrage der aktuelle Zustand (also 0) gemeldet. Die Zentrale macht kein 'Aufsammeln' der Melder, dies ist auch im Protokoll nicht vorgesehen. Der Wechsel des Rückmeldebits wird jedoch immer gemeldet, auch wenn es nur ganz kurz aktiv war.
Daraus ergibt sich bei Verwendung der IB-Syntax folgende Bedingung: der PC muß einfach öfter fragen als die Haltezeit der HW-Melder bzw. das Busintervall des S88-Busses.
Adresszuordnung
- Es gibt innerhalb der Zentrale vier Adressbereiche für Rückmelder. Diese Bereiche folgen aufeinander, jeder
Bereich darf auch 0 Byte groß sein:
Bereich | 1 | 2 | 3 | 4 |
---|---|---|---|---|
Zuordnung | S88-1 | S88-2 | S88-3 | Weichenrückmeldung |
festgelegt durch: | CV9 | CV10 | CV11 | CV16 |
Beim Protokoll p50xb werden immer alle vier Bereiche über den normalen Rückmeldeweg zurückgemeldet, die Bits für die Weichenrückmeldung sind hier einfach in die normalen Rückmeldebits einsortiert. Die Auswertung, ob eine Weiche umgelaufen ist, muß dann am PC erfolgen.
Xpressnet und Schaltinformationen
- Beim Xpressnet ergeben sich Einschränkungen, weil die Rückmelder und Weichenbefehle sich den Adressbereich teilen.
(Anmerkung: Das ist m.E. ein erheblicher Mangel des Xpressnetprotokolls.)
Laut Lenz-Doku gibt es 1024 Rückmelder, dabei wird das Byte 1 der Xpressnet-Anfrage von 0..127 kodiert und es
werden je 8 Rückmelder damit erfaßt. Des weiteren sind 1024 Weichen vorgesehen, hier deckt das Byte 1 einen
Bereich von 0..255 ab, es werden je 4 Weichen adressiert.
Die Adressbereiche liegen übereinander, es werden also max. 2048 Bits addressiert.
0 1024 2048 |-------- Feedback ---------| |----------------------- Weichen ---------------------|Anhand der Graphik wird auch klar, warum das Xpressnet nur auf dem ersten 512 Weichen Schaltdekoder mit Rückmeldung kann.
Was bedeutet das nun für OpenDCC?
Bei OpenDCC gibt es ja externe Rückmelder (S88) und interne Rückmeldungen (eben die Weichenrückmeldung) und man muß sich nun entscheiden, wie man das in den gemeinsamen Adressraum einsortiert:
Byte 1: | Bedeutung |
---|---|
0..63 | Dieser Bereich wird DCC-Accessory zugeordnet und mit einer Schaltdecoder-Rückmeldung aus dem Bereich 4 (Turnout-Buffer) geladen. Das bedeutet 256 mögliche Weichen |
64 .. 127 | Dieser Bereich wird als Feedback-Bereich interpretiert (d.h. die Melder beginnen bei 513 bzw. Baustein 65-1). Das bedeutet 512 mögliche Melder |
Ich habe die zweite Alternative genommen: Die S88-Rückmelder (also die Bereiche 1, 2 und 3) werden beim Xpressnet-Protokoll als Feedback-Broadcasts (TT = 10) beginnend bei 513 gemeldet. Das Schalten von Weichen wird mit Broadcast einer Schaltinformation gemeldet, allerdings nur bis Weiche 256. Diese Meldung erfolgt beim Abschalten des Antriebes einer Weiche und Eintreffen der entsprechenden Rückmeldung, wobei die gemeldete (Schalt-)Adresse innerhalb des Bereiches 4 neu beginnend gezählt wird.
Für Sonderanwendungen (z.B. extrem viele Rückmeldungen) kann diese Zuordnung mit CV29 verändert werden.
Multi-Protokollbetrieb
- OpenDCC Z1 (in der Version OpenDCC_XP) kann p50xb und Xpressnet parallel bedienen.
Hierzu sind die entsprechenden Change-Flags für die beiden
Protokolle doppelt ausgeführt, um trotz eines per Push-Dienst am Xpressnet abgesandten Ereignisses dieses auch noch
für die event-Abfrage am p50xb vorzuhalten. Die Rückmeldungen werden also verlustfrei parallel in beiden
Protokollbereichen verteilt.