http://der-moba.de/index.php?title=SRCP_0.5.0_(plain_text)&feed=atom&action=history
SRCP 0.5.0 (plain text) - Versionsgeschichte
2024-03-29T01:11:53Z
Versionsgeschichte dieser Seite in DerMoba
MediaWiki 1.25.1
http://der-moba.de/index.php?title=SRCP_0.5.0_(plain_text)&diff=10421&oldid=prev
Werner Falkenbach: Leerzeichen oder Fata Morgana?
2006-01-17T10:57:23Z
<p>Leerzeichen oder Fata Morgana?</p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Nächstältere Version</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Version vom 17. Januar 2006, 10:57 Uhr</td>
</tr><tr><td colspan="2" class="diff-lineno" id="L1" >Zeile 1:</td>
<td colspan="2" class="diff-lineno">Zeile 1:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                     SRCP - Simple Railroad Command Protocol</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                     SRCP - Simple Railroad Command Protocol</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Version 0.5.0</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Version 0.5.0</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline"> </ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                 Torsten Vogt, Martin Ostermann, Kurt Haders,  </div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                 Torsten Vogt, Martin Ostermann, Kurt Haders,  </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>               Olaf Schlachter, Matthias Trute, Tobias Schlottke</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>               Olaf Schlachter, Matthias Trute, Tobias Schlottke</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Edbert van Eimeren</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Edbert van Eimeren</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline"> </ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   1. Einleitung</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   1. Einleitung</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   </div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   </div></td></tr>
</table>
Werner Falkenbach
http://der-moba.de/index.php?title=SRCP_0.5.0_(plain_text)&diff=10420&oldid=prev
Werner Falkenbach: Leerzeichen
2006-01-17T10:56:44Z
<p>Leerzeichen</p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Nächstältere Version</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Version vom 17. Januar 2006, 10:56 Uhr</td>
</tr><tr><td colspan="2" class="diff-lineno" id="L1" >Zeile 1:</td>
<td colspan="2" class="diff-lineno">Zeile 1:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                     SRCP - Simple Railroad Command Protocol</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                     SRCP - Simple Railroad Command Protocol</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Version 0.5.0</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Version 0.5.0</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline"> </del></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                 Torsten Vogt, Martin Ostermann, Kurt Haders,  </div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                 Torsten Vogt, Martin Ostermann, Kurt Haders,  </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>               Olaf Schlachter, Matthias Trute, Tobias Schlottke</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>               Olaf Schlachter, Matthias Trute, Tobias Schlottke</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Edbert van Eimeren</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>                             Edbert van Eimeren</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline"> </del></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   1. Einleitung</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   1. Einleitung</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   </div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>   </div></td></tr>
</table>
Werner Falkenbach
http://der-moba.de/index.php?title=SRCP_0.5.0_(plain_text)&diff=10419&oldid=prev
Werner Falkenbach: kat
2006-01-17T10:55:41Z
<p>kat</p>
<a href="http://der-moba.de/index.php?title=SRCP_0.5.0_(plain_text)&diff=10419&oldid=10418">Änderungen zeigen</a>
Werner Falkenbach
http://der-moba.de/index.php?title=SRCP_0.5.0_(plain_text)&diff=10418&oldid=prev
Werner Falkenbach: neu
2006-01-17T10:52:33Z
<p>neu</p>
<p><b>Neue Seite</b></p><div> SRCP - Simple Railroad Command Protocol<br />
Version 0.5.0<br />
<br />
Torsten Vogt, Martin Ostermann, Kurt Haders, <br />
Olaf Schlachter, Matthias Trute, Tobias Schlottke<br />
Edbert van Eimeren<br />
<br />
1. Einleitung<br />
<br />
Das SRCP beschreibt einen Befehlssatz zur Client-Server-Kommunikation<br />
zwischen Serverprozessen zur Steuerung von digitalen Modelleisenbahnen<br />
und deren Clients. Serverprozesse sind entweder Software-Signalgeneratoren<br />
oder Treiber für HW-Interfaces. Clients sind typischerweise <br />
Steuerungsprogramme.<br />
<br />
Der SRCP-Befehlssatz besteht aus Kommandos, die direkt das Verhalten<br />
des Servers betreffen und aus Kommandos, die für die Dekoder der <br />
Modellbahnanlage bestimmt sind. Weiterhin werden Kommandos, die die<br />
Verarbeitung von Rückmeldungen betreffen spezifiziert.<br />
<br />
1.1 Konventionen<br />
<br />
Die Übertragung der Kommandos von den Clients zum Server erfolgt via<br />
tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF),<br />
#10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR),<br />
#13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch<br />
Whitespace (Leerzeichen, Tabulatoren) getrennt sind. <br />
<br />
Die Worte der Kommandos können aus der Menge der Zeichen <br />
{ '0', .., '9', '-', 'A', .., 'Z', 'a', .., 'z' } gebildet werden. <br />
Der Server wertet die Kommandos case-sensitive aus, d.h. zwischen<br />
Groß- und Kleinbuchstaben wird unterschieden.<br />
<br />
Kommandos, die unvollständig oder offensichtlich falsch sind werden<br />
vom Server ignoriert. <br />
<br />
1.2 Übertragungskanäle<br />
<br />
Ein SRCP-konformer Server stellt den Clients drei Ports zur Verfügung.<br />
<br />
1. Kommandoport<br />
2. Rückmeldepollport<br />
3. Informationsport<br />
<br />
Der Kommandoport dient den Clients dazu, dem Server Kommandos<br />
übermitteln. Der Server versucht die Kommandos auszuführen. Bei<br />
manchen Kommandos erwartet der Client eine Antwort. Die Antwort des<br />
Servers wird ebenfalls über den Kommandoport abgewickelt. <br />
<br />
Der Rückmeldepollport wird nur unidirektional vom Server zum Client benutzt.<br />
Meldet sich ein Client am Rückmeldepollport an, so sendet der Server<br />
jede Statusänderung einer Rückmeldeeinheit an den Client zurück. Mit<br />
diesem Mechanismus ist es möglich, Rückmeldungen beim Client<br />
ereignisgesteuert zu bearbeiten.<br />
<br />
Auch der Informationsport wird nur unidirektional von Server zu den<br />
Clients benutzt. Er ist eine Art Broadcast-Kanal, der ständig vom Server<br />
mit Statusänderungen von Lokdekodern und Schaltdekodern gefüttert<br />
wird. Er dient dem asynchronen Abgleich mehrerer Clients am selben<br />
Server.<br />
<br />
Der Server bestimmt die Portnummern. Standardportnummer für den<br />
Kommandoport sollte 12345 sein. Der Rückmeldepollport und der<br />
Informationsport sollten die beiden unmittelbar folgenden <br />
Portnummern sein. Standardmässig ergeben sich somit folgende<br />
Portnummern:<br />
<br />
Kommandoport : 12345<br />
Rückmeldepollport: 12346<br />
Informationsport : 12347<br />
<br />
Nimmt ein Client zum Kommandoport Kontakt auf und wird vom Server<br />
akzeptiert, muß der Server zunächst einen einzeiligen Informationstext <br />
über diesen Port zum Client schicken. Dieser Text sollte den Namen des <br />
Servers, dessen Versionsnummer und die implementierte SRCP-Version<br />
enthalten. <br />
<br />
Beispiel: erddcd v0.9.511; SRCP 0.5.0<br />
<br />
Anschliesend wartet der Server auf Kommandos des Client. Der Client<br />
muß den Informationstext lesen und kann nun seinerseits Kommandos<br />
an den Server schicken.<br />
<br />
<br />
2. Kommandos zur Serversteuerung:<br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: entfällt<br />
<br />
Kommandos:<br />
<br />
SHUTDOWN : Der Server beendet sich<br />
LOGOUT : Dem Server wird angzeigt, dass sich ein Client ausloggt<br />
STARTVOLTAGE: Der Server schaltet den Digitalstrom am Booster ein<br />
STOPVOLTAGE : Der Server schaltet den Digitalstrom am Booster aus<br />
RESET : Der Server re-initialisiert sich<br />
<br />
<br />
3. Kommandos zur Digitalsteuerung<br />
<br />
3.1 Befehle und Gerätegruppen<br />
<br />
SRCP definiert 4 generelle Befehle:<br />
<br />
SET : Setzt einen Wert vom Client über den Server zum Gerät.<br />
<br />
GET : Ermittelt den aktuellen Zustand eines Gerätes.<br />
<br />
WAIT : Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.<br />
<br />
INIT : Falls Geräte explizit initialisiert werden müssen.<br />
<br />
Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder und <br />
Rückmeldeeinheiten.<br />
<br />
Über Parameter wird festgelegt, auf welche Gerätegruppe sich ein Befehl<br />
bezieht. Der erste Parameter legt immer die Gerätegruppe fest:<br />
<br />
GL: Lok- und Funktionsdekoder (generic loco)<br />
GA: Schaltdekoder (generic accessory)<br />
FB: Rückmeldeeinheit (feedback)<br />
<br />
Anwendbarkeit der Befehle auf Gerätegruppen:<br />
<br />
| SET GET WAIT INIT<br />
---+----------------------<br />
|<br />
GL | x x - - <br />
|<br />
GA | x x - -<br />
|<br />
FB | - x x x<br />
|<br />
<br />
Bei einigen Befehlen (GET, WAIT) erwartet der Client vom Server eine<br />
Antwort. Es kann nun vorkommen, daß der Server zur gestellten Anfrage<br />
keine Antwort geben kann. In diesen Fällen muß der Server eine <br />
Zeichenkette zum Client senden, die folgendem Format genügt:<br />
<br />
INFO <error code> \n<br />
<br />
Als 'error code' muß eine negative Zahl übergeben werden. Folgende <br />
Konventionen gelten:<br />
<br />
INFO -1 ==> Befehl wird nicht unterstützt (not supported)<br />
INFO -2 ==> Keine Information vorhanden (no data)<br />
INFO -3 ==> Zeitlimit überschritten (vgl. WAIT) (timeout)<br />
<br />
<br />
3.2 Weitere Befehlsparameter <br />
<br />
Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät<br />
und welche Eigenschaften beeinflußt oder abgefragt werden sollen.<br />
<br />
3.2.1 Befehlsparameter des Befehls SET<br />
<br />
3.2.1.1 Gerätegruppe GL<br />
<br />
SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'<br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: entfällt<br />
<br />
Bedeutung der Argumente:<br />
<br />
protocol : M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS<br />
<br />
M1: Märklin alt (rel. FRU, 80 Adr., 1 Funkt., 14 FS)<br />
M2: Märklin neu (abs. FRU, 80 Adr., 5 Funkt., 14 FS)<br />
M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)<br />
M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)<br />
MF: altes Märklin Format für Funktionsdekoder<br />
NB: NMRA-DCC Basisprotokoll (abs. FRU, 7-bit-Adr., 14 FS)<br />
N1: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 28 FS)<br />
N2: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 128 FS)<br />
N3: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 28 FS)<br />
N4: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 128 FS)<br />
PS: protocol by server, der Server bestimmt den Protokolltyp <br />
<br />
addr : 0 .. 9999<br />
direction: 0 (= rückwärts), 1 (= vorwärts), 2 (= Nothalt)<br />
V : 0 .. V_max ((virtuelle) Geschwindigkeit)<br />
V_max : 0 .. 999 (maximale (virtuelle) Geschwindigkeit)<br />
V_max=0 ==> virtuelle Fahrstufe = reale Fahrstufe<br />
func : 0 (= aus), 1 (= an)<br />
nro_f : 0 .. x (Anzahl der Zusatzfunktionen (number of functions))<br />
f1 .. fn : 0 (= aus), 1 (= an) <br />
<br />
Beispiel: SET GL N2 1 1 50 250 1 4 0 1 0 0<br />
<br />
Umrechnung der virtuellen Geschwindigkeit in echte Fahrstufen:<br />
<br />
gegeben: DEC_fs (Anzahl der realen Dekoderfahrstufen, implizit bekannt)<br />
V (virtuelle Geschwindigkeit, Argument)<br />
V_max (maximale virtuelle Geschwindigkeit, Argument)<br />
<br />
gesucht: V_fs (reale Fahrstufe, die der virtuellen Geschw. entspricht)<br />
<br />
Algorithmus: V_fs = round((V * DEC_fs)/V_max) <br />
<br />
Hinweise für Entwickler von SRCP-konformen Servern:<br />
<br />
Es ist darauf zu achten, daß wirklich nur dann die reale<br />
Fahrstufe 0 (Stillstand) errechnet wird, wenn das Argument<br />
V gleich Null ist. Die Funktion 'round' ist deshalb <br />
hinreichend intelligent zu implementieren. <br />
<br />
V_fs darf nur als Geschwindigkeitsangabe interpretiert<br />
werden. Manche Dekoder reagieren z.B. bei Fahrstufe 1<br />
mit einem Nothalt, andere mit einem Richtungswechsel,<br />
wieder andere mit einer Selbstzerstörungssequenz ;-).<br />
Sollen solche Dekoder unterstützt werden, dann hat <br />
der Server dafür zu sorgen, daß V_fs entsprechend angepaßt<br />
wird, bevor das Kommando an den Dekoder gesendet wird.<br />
Aus Sicht der Clients müssen die Fahrstufen sukzessive<br />
von 0 bis zur maximalen Fahrstufenanzahl durchnummeriert<br />
sein.<br />
<br />
Wird V_max auf 0 gesetzt, dann darf keine Umrechnung der<br />
Fahrstufe vorgenommen werden. D.h. die mit V übermittelte<br />
Fahrstufe ist direkt an die Dekoder weiterzusenden. Dies<br />
erlaubt Clients den direkten Zugriff auf die Dekoder.<br />
<br />
Sendet der Client den Protokolltyp PS (protocol by server),<br />
dann muß der Server entscheiden, welches Protokoll er für<br />
die übermittelte Adresse wählt. Die anderen Protokolltypen<br />
stellen für den Server natürlich auch nur Empfehlungen des<br />
Clients dar. Der Server hat immer die Freiheit, einer Adresse<br />
ein anderes, geeigneteres Protokoll zuzuweisen.<br />
<br />
Beispiele: (50*28)/250 = 5.7 ==> V_fs = 6<br />
(4*28)/250 = 0.448 ==> V_fs = 1 (!!!)<br />
(0*28)/250 = 0 ==> V_fs = 0<br />
<br />
3.2.1.2 Gerätegruppe GA<br />
<br />
SET GA <protocol> <acc_nr> <acc_port> <action> <delay><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'<br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: entfällt<br />
<br />
Bedeutung der Argumente:<br />
<br />
protocol: M, N<br />
<br />
M: Märklin/Motorola-Format<br />
N: NMRA-DCC-Format<br />
<br />
acc_nr : 1 .. 4096 (Nummer der Weiche/des Signals)<br />
acc_port: 0, 1 (Ausgang des Dekoders)<br />
action : 0, 1 (0 = deaktiviert, 1 = aktiviert) <br />
delay : Wert in Millisekunden (1000stel-Sekunden). Gibt an,<br />
nach welcher Zeit der Daemon einen aktivierten Ausgang<br />
automatisch deaktivieren soll. Wird '-1' als delay übergeben,<br />
dann wird der Ausgang nicht automatisch deaktiviert. Ist<br />
action=0 (Deaktivierung) wird delay ignoriert, muß aber<br />
angegeben werden (sinnvoller Wert: '-1').<br />
<br />
Belegung der Dekoderausgänge:<br />
<br />
0 = Weiche abbiegen, Signal Hp0, ...<br />
1 = Weiche gerade, Signal Hp1, ...<br />
<br />
Beispiel: SET GA M 0023 1 1 20<br />
<br />
3.2.1.3 Servicemode<br />
<br />
Es gibt Dekoder, die auf einem Programmiergleis oder 'on-track' <br />
programmierbar sind. Diese Dekoder erlauben die Änderung von<br />
'Speicherzellen' (Register, CV (configuration variable), Bit).<br />
Diese Dekoder können auch von SRCP-Servern unterstützt werden.<br />
Dazu dienen die folgenden Befehle.<br />
<br />
SET GL SM <protocol> <dest-type> <dest-addr> [bitnr] <value><br />
SET GA SM <protocol> <dest-type> <dest-addr> [bitnr] <value><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'<br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: entfällt<br />
<br />
Bedeutung der Argumente:<br />
<br />
protocol : NMRA, ...<br />
dest-type: Art der zu ändernden Dekoderspeicherzelle (destination type)<br />
<br />
CV : NMRA-DCC configuration variable<br />
CVBIT: ein Bit einer NMRA-DCC configuration variable<br />
REG : Ein Register eines NMRA-DCC-Dekoders<br />
<br />
dest-addr: Adresse der Speicherzelle, die geändert werden soll<br />
bitnr : nur in Verbindung mit CVBIT sinnvoll<br />
value : neuer Wert der Speicherzelle<br />
<br />
<br />
3.2.1.4 sonstiges<br />
<br />
Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.<br />
für Drehscheiben) spezifizieren. <br />
<br />
3.2.2 Befehlsparameter des Befehls GET<br />
<br />
3.2.2.1 Gerätegruppe GL<br />
<br />
GET GL <protocol> <addr><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'<br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: Kommandoport<br />
<br />
Bedeutung der Argumente: siehe 3.2.1.1<br />
<br />
Der Server sendet an den Client alle verfügbare Info zu dem mit<br />
<protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder.<br />
Diese Info muß wie folgt formatiert werden:<br />
<br />
INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn><br />
<br />
(vgl. 3.2.1.1)<br />
<br />
Sollte keine Information vorhanden sein, oder der Server den Befehl<br />
GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den <br />
Client senden (vgl. 3.1).<br />
<br />
3.2.2.2 Gerätegruppe GA <br />
<br />
GET GA <protocol> <acc_nr> <acc_port><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'<br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: Kommandoport <br />
<br />
Bedeutung der Argumente: siehe 3.2.1.2<br />
<br />
Der Server sendet an den Client alle verfügbare Info zu dem mit<br />
<protocol> und <acc_nr> spezifizierten Schaltdekoder.<br />
Diese Info muß wie folgt formatiert werden:<br />
<br />
INFO GA <protocol> <acc_nr> <acc_port> <state><br />
<br />
(vgl. 3.2.1.2, ersetze <state> durch <action>)<br />
<br />
Sollte keine Information vorhanden sein, oder der Server den Befehl<br />
GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den <br />
Client senden (vgl. 3.1). <br />
<br />
3.2.2.3 Gerätegruppe FB<br />
<br />
GET FB <module-type> <portnr><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n' <br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: Kommandoport<br />
<br />
Bedeutung der Argumente:<br />
<br />
module-type: S88 (Märklin s88-Bus am Parallelport des PC)<br />
I8255 (i8255 Karte)<br />
M6051 (Märklin s88-Bus via Interface 6051)<br />
<br />
portnr : konkreter Eingang eines Rückmeldemoduls <br />
<br />
Der Server sendet auf dem Rückmeldekanal an den Client den aktuellen <br />
Status des mit <module-type> und <portnr> spezifizierten <br />
Rückmeldemoduleingangs. Diese Info muß wie folgt formatiert werden:<br />
<br />
INFO FB <module-type> <portnr> <state><br />
<br />
Wobei state entweder '0' oder '1' sein darf. <br />
<br />
Sollte keine Information vorhanden sein, oder der Server den Befehl<br />
GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den <br />
Client senden (vgl. 3.1). <br />
<br />
3.2.2.4 Servicemode<br />
<br />
Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations-<br />
variablen diverser Dekoder spezifizieren.<br />
<br />
3.2.2.5 sonstiges<br />
<br />
Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.<br />
für Drehscheiben) spezifizieren.<br />
<br />
3.2.3 Befehlsparameter des Befehls WAIT<br />
<br />
3.2.3.1 Gerätegruppe FB<br />
<br />
WAIT FB <module-type> <portnr> <value> <timeout><br />
<br />
Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n' <br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: Kommandoport<br />
<br />
Wartet, bis portnr den Wert value (0,1) annimmt. Wartet<br />
aber höchstens timeout Sekunden. Sendet falls der timeout nicht<br />
eingetreten ist, die gleiche Information wie GET FB.<br />
Sollte der timeout überschritten werden, wird 'INFO -3' an den <br />
Client gesendet.<br />
<br />
Sollte keine Information vorhanden sein, oder der Server den Befehl<br />
WAIT nicht unterstützen, dann muß der Server 'INFO <error code>' an den <br />
Client senden (vgl. 3.1).<br />
<br />
3.2.6 Befehlsparameter des Befehls INIT<br />
<br />
INIT FB <module-type><br />
<br />
Kommunikationsports: Client -> Server: Kommandoport<br />
Server -> Client: entfällt<br />
<br />
Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht<br />
an den Client.<br />
<br />
<br />
4. Datenformate der Serverinformationen<br />
<br />
4.1 Rückmeldepollport<br />
<br />
Die Datenübertragung auf dem Rückmeldepollport unterliegt den gleichen<br />
Beschränkungen wie die des Kommandoports (plain text, '\n' als Endezeichen).<br />
Die Daten müssen mit folgendem Format übertragen werden: <br />
<br />
INFO FB <module-type> <portnr> <state><br />
(vgl. 3.2.2.3)<br />
<br />
4.2 Informationsport <br />
<br />
Die Datenübertragung auf dem Informationsport unterliegt den gleichen<br />
Beschränkungen wie die des Kommandoports (plain text, '\n' als Endezeichen).<br />
Die Daten müssen mit folgenden Formaten - abhängig von der Gerätegruppe -<br />
übertragen werden:<br />
<br />
INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn><br />
(vgl. 3.2.2.1)<br />
<br />
INFO GA <protocol> <acc_nr> <acc_port> <state> <br />
(vgl. 3.2.2.2)<br />
<br />
<br />
5. Ausblicke, zukünftige Erweiterungen <br />
<br />
Ich habe bewußt einige Ideen, die andiskutiert wurden, nicht mit <br />
aufgenommen. Ich bin der Meinung, daß wir einen vorläufigen<br />
Schlußstrich ziehen und die ganzen netten Dinge implementieren <br />
sollten. Damit die anderen guten Ideen nicht verloren gehen, werde<br />
ich sie in diesem Abschnitt aufführen.<br />
<br />
5.1 Zentrale Konfiguration<br />
<br />
Von Kurt Haders stammt der Vorschlag einer zentralen Konfigurationsdatei.<br />
Hauptanliegen ist es, mehr "Wissen" von den Clients in den Server zu<br />
verlagern. Ein Format, wie eine solche Konfigurationsdatei aussehen soll,<br />
liegt noch nicht vor. Das Übertragungsprotokoll ist duch den <br />
Protokollbezeichner 'PS' (protocol by server) bereits darauf vorbereitet.<br />
<br />
5.2 Erweiterung der Befehle auf andere Gerätegruppen<br />
<br />
Von Matthias Trute kommt der Vorschlag den Befehl WAIT auch für die<br />
Gerätegruppen GL und GA zuzulassen. Allerdings kann es hierbei zu<br />
Inkonsistenzen kommen. Weiterhin könnte man man bei WAIT Wildcards<br />
('*') zulassen.<br />
<br />
5.3 Quittierung von Befehlen<br />
<br />
Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über<br />
den Rückkanal des Kommandoports realisiert werden.<br />
<br />
5.4 Konfiguration des Servers auslesen<br />
<br />
Von Edbert van Eimeren kommt der Vorschlag, daß Clients die Konfiguration<br />
des Servers abfragen können sollten (neuer Befehl: CONFGET).</div>
Werner Falkenbach