SRCP - Simple Railroad Command Protocol 0.7.1: Unterschied zwischen den Versionen

aus DerMoba, der Wissensdatenbank für Modellbahner
Wechseln zu: Navigation, Suche
K (neu)
 
(Hierarchie Überschriften, interne Links entfernt)
 
Zeile 1: Zeile 1:
 
+
''' Torsten Vogt, Martin Ostermann, Kurt Haders, Olaf Schlachter, Matthias Trute, Tobias Schlottke, Edbert van Eimeren, Stefan Bormann, Michael Reukauff '''
== Torsten Vogt, Martin Ostermann, Kurt Haders, Olaf Schlachter, Matthias Trute, Tobias Schlottke, Edbert van Eimeren, Stefan Bormann, Michael Reukauff ==
+
  
 
Juni 2000
 
Juni 2000
 +
 +
  
 
== 1. Einleitung ==
 
== 1. Einleitung ==
Zeile 12: Zeile 13:
 
Der Server kann über ein Zeitgebermodul verfügen, das alle Clients mit einer einheitlichen Modellzeit versorgen kann.
 
Der Server kann über ein Zeitgebermodul verfügen, das alle Clients mit einer einheitlichen Modellzeit versorgen kann.
  
== 1.1 Konventionen ==
+
 
 +
=== 1.1 Konventionen ===
  
 
Die Übertragung der Kommandos von den Clients zum Server erfolgt via tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF), #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR), #13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.
 
Die Übertragung der Kommandos von den Clients zum Server erfolgt via tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF), #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR), #13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.
Zeile 20: Zeile 22:
 
Kommandos, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert.
 
Kommandos, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert.
  
== 1.2 Übertragungskanäle ==
+
 
 +
=== 1.2 Übertragungskanäle ===
  
 
Ein SRCP-konformer Server stellt den Clients drei Ports zur Verfügung.
 
Ein SRCP-konformer Server stellt den Clients drei Ports zur Verfügung.
Zeile 45: Zeile 48:
  
 
----
 
----
 
 
 
  erddcd v0.9.511; SRCP 0.5.0
 
  erddcd v0.9.511; SRCP 0.5.0
 
 
----
 
----
  
 
Anschliesend wartet der Server auf Kommandos des Client. Der Client muß den Informationstext lesen und kann nun seinerseits Kommandos an den Server schicken.
 
Anschliesend wartet der Server auf Kommandos des Client. Der Client muß den Informationstext lesen und kann nun seinerseits Kommandos an den Server schicken.
 +
 +
  
 
== 2. Allgemeine Kommandos zur Serversteuerung ==
 
== 2. Allgemeine Kommandos zur Serversteuerung ==
Zeile 70: Zeile 72:
 
* STARTVOLTAGE identisch mit SET POWER ON
 
* STARTVOLTAGE identisch mit SET POWER ON
 
* STOPVOLTAGE identisch mit SET POWER OFF
 
* STOPVOLTAGE identisch mit SET POWER OFF
 +
 +
  
 
== 3. Kommandos zur Digitalsteuerung ==
 
== 3. Kommandos zur Digitalsteuerung ==
  
== 3.1 Befehle und Gerätegruppen ==
+
=== 3.1 Befehle und Gerätegruppen ===
  
 
SRCP definiert 8 generelle Befehle, die über den Kommandoport abgewickelt werden.
 
SRCP definiert 8 generelle Befehle, die über den Kommandoport abgewickelt werden.
  
 
; '''SET'''
 
; '''SET'''
: Setzt einen Wert vom Client über den Server zum Gerät.
+
:   Setzt einen Wert vom Client über den Server zum Gerät.
 
; '''GET'''
 
; '''GET'''
: Ermittelt den aktuellen Zustand eines Gerätes.
+
:   Ermittelt den aktuellen Zustand eines Gerätes.
 
; '''WAIT'''
 
; '''WAIT'''
: Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
+
:   Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
 
; '''INIT'''
 
; '''INIT'''
: Falls Geräte explizit initialisiert werden müssen.
+
:   Falls Geräte explizit initialisiert werden müssen.
 
; '''TERM'''
 
; '''TERM'''
: Falls die mit INIT getroffenen Einstellungen wieder entfernt werden sollen.
+
:   Falls die mit INIT getroffenen Einstellungen wieder entfernt werden sollen.
 
; '''WRITE'''
 
; '''WRITE'''
: Setzt einen Wert vom Client und liefert eine Antwort zurück.
+
:   Setzt einen Wert vom Client und liefert eine Antwort zurück.
 
; '''VERIFY'''
 
; '''VERIFY'''
: Überprüft, ob ein Wert einen bestimmten Wert hat.
+
:   Überprüft, ob ein Wert einen bestimmten Wert hat.
 
; '''READ'''
 
; '''READ'''
: Liest einen Wert aus, ist das GET-Pendant zu WRITE.
+
:   Liest einen Wert aus, ist das GET-Pendant zu WRITE.
  
 
Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder, Rückmeldeeinheiten und sonstigen Bereichen.
 
Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder, Rückmeldeeinheiten und sonstigen Bereichen.
Zeile 101: Zeile 105:
  
 
; '''GL'''
 
; '''GL'''
: Lok- und Funktionsdekoder (generic loco)
+
:   Lok- und Funktionsdekoder (generic loco)
 
; '''GA'''
 
; '''GA'''
: Schaltdekoder (generic accessory)
+
:   Schaltdekoder (generic accessory)
 
; '''FB'''
 
; '''FB'''
: Rückmeldeeinheit (feedback)
+
:   Rückmeldeeinheit (feedback)
 
; '''TIME'''
 
; '''TIME'''
: Zeitnormal
+
:   Zeitnormal
 
; '''POWER'''
 
; '''POWER'''
: Energieversorgung der Modellanlage
+
:   Energieversorgung der Modellanlage
  
 
Anwendbarkeit der Befehle auf Gerätegruppen:
 
Anwendbarkeit der Befehle auf Gerätegruppen:
Zeile 115: Zeile 119:
 
----
 
----
  
 
 
         |  SET  GET  WAIT  INIT TERM
 
         |  SET  GET  WAIT  INIT TERM
 
       ---+----------------------------
 
       ---+----------------------------
Zeile 134: Zeile 137:
  
 
----
 
----
 
 
 
   INFO <error code> \n
 
   INFO <error code> \n
 
 
----
 
----
  
Zeile 148: Zeile 148:
 
INFO -3 ==> Zeitlimit überschritten (vgl. WAIT) (timeout)
 
INFO -3 ==> Zeitlimit überschritten (vgl. WAIT) (timeout)
  
== 3.2 Weitere Befehlsparameter ==
+
 
 +
=== 3.2 Weitere Befehlsparameter ===
  
 
Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät und welche Eigenschaften beeinflußt oder abgefragt werden sollen.
 
Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät und welche Eigenschaften beeinflußt oder abgefragt werden sollen.
  
=== Befehlsparameter des Befehls SET ===
 
  
=== Gerätegruppe GL ===
+
==== Befehlsparameter des Befehls SET ====
 +
 
 +
''' Gerätegruppe GL '''
  
 
----
 
----
 
 
 
   SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
   SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
 
----
 
----
  
Zeile 173: Zeile 172:
  
 
; '''protocol'''
 
; '''protocol'''
: M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS
+
:   M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS
:* M1: Märklin alt (rel. FRU, 80 Adr., 1 Funkt., 14 FS)
+
:*     M1: Märklin alt (rel. FRU, 80 Adr., 1 Funkt., 14 FS)
:* M2: Märklin neu (abs. FRU, 80 Adr., 5 Funkt., 14 FS)
+
:*     M2: Märklin neu (abs. FRU, 80 Adr., 5 Funkt., 14 FS)
:* M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)
+
:*     M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)
:* M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)
+
:*     M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)
:* M5: M2 erweitert nach Märklin (abs. FRU, 80 Adr, 5 Funkt., 27 FS)
+
:*     M5: M2 erweitert nach Märklin (abs. FRU, 80 Adr, 5 Funkt., 27 FS)
:* MF: altes Märklin Format für Funktionsdekoder
+
:*     MF: altes Märklin Format für Funktionsdekoder
:* NB: NMRA-DCC Basisprotokoll (abs. FRU, 7-bit-Adr., 14 FS)
+
:*     NB: NMRA-DCC Basisprotokoll (abs. FRU, 7-bit-Adr., 14 FS)
:* N1: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 28 FS)
+
:*     N1: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 28 FS)
:* N2: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 128 FS)
+
:*     N2: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 128 FS)
:* N3: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 28 FS)
+
:*     N3: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 28 FS)
:* N4: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 128 FS)
+
:*     N4: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 128 FS)
:* PS: protocol by server, der Server bestimmt den Protokolltyp
+
:*     PS: protocol by server, der Server bestimmt den Protokolltyp
 
; '''addr'''
 
; '''addr'''
: Zahl >= 0
+
:   Zahl >= 0
 
; '''direction'''
 
; '''direction'''
: 0 (= rückwärts), 1 (= vorwärts), 2 (= Nothalt)
+
:   0 (= rückwärts), 1 (= vorwärts), 2 (= Nothalt)
 
; '''V'''
 
; '''V'''
: 0 .. V_max ((virtuelle) Geschwindigkeit)
+
:   0 .. V_max ((virtuelle) Geschwindigkeit)
 
; '''V_max'''
 
; '''V_max'''
: 0 .. 999 (maximale (virtuelle) Geschwindigkeit) V_max=0 ==> virtuelle Fahrstufe = reale Fahrstufe
+
:   0 .. 999 (maximale (virtuelle) Geschwindigkeit) V_max=0 ==> virtuelle Fahrstufe = reale Fahrstufe
 
; '''func'''
 
; '''func'''
: 0 (= aus), 1 (= an)
+
:   0 (= aus), 1 (= an)
 
; '''nro_f'''
 
; '''nro_f'''
: 0 .. x (Anzahl der Zusatzfunktionen (number of functions))
+
:   0 .. x (Anzahl der Zusatzfunktionen (number of functions))
 
; '''f1 .. fn'''
 
; '''f1 .. fn'''
: 0 (= aus), 1 (= an)
+
:   0 (= aus), 1 (= an)
  
 
Beispiel
 
Beispiel
  
 
----
 
----
 
 
 
   SET GL N2 1 1 50 250 1 4 0 1 0 0
 
   SET GL N2 1 1 50 250 1 4 0 1 0 0
 
 
----
 
----
  
Zeile 224: Zeile 220:
 
Algorithmus: V_fs = round((V * DEC_fs)/V_max)
 
Algorithmus: V_fs = round((V * DEC_fs)/V_max)
  
=== Hinweise für Entwickler von SRCP-konformen Servern ===
+
''' Hinweise für Entwickler von SRCP-konformen Servern '''
  
 
Es ist darauf zu achten, daß wirklich nur dann die reale Fahrstufe 0 (Stillstand) errechnet wird, wenn das Argument V gleich Null ist. Die Funktion "round" ist deshalb hinreichend intelligent zu implementieren.
 
Es ist darauf zu achten, daß wirklich nur dann die reale Fahrstufe 0 (Stillstand) errechnet wird, wenn das Argument V gleich Null ist. Die Funktion "round" ist deshalb hinreichend intelligent zu implementieren.
Zeile 237: Zeile 233:
  
 
----
 
----
 
 
 
       (50*28)/250 = 5.7  ==> V_fs = 6
 
       (50*28)/250 = 5.7  ==> V_fs = 6
 
       (4*28)/250  = 0.448 ==> V_fs = 1 (!!!)
 
       (4*28)/250  = 0.448 ==> V_fs = 1 (!!!)
 
       (0*28)/250  = 0    ==> V_fs = 0
 
       (0*28)/250  = 0    ==> V_fs = 0
 
 
----
 
----
  
=== Gerätegruppe GA ===
+
 
 +
''' Gerätegruppe GA '''
  
 
----
 
----
 
 
 
   SET GA <protocol> <acc_nr> <acc_port> <action> <delay>
 
   SET GA <protocol> <acc_nr> <acc_port> <action> <delay>
 
 
----
 
----
  
Zeile 264: Zeile 255:
  
 
; '''protocol'''
 
; '''protocol'''
: :* M: Märklin/Motorola-Format
+
:  
:* N: NMRA-DCC-Format
+
:*     M: Märklin/Motorola-Format
 +
:*     N: NMRA-DCC-Format
 
; '''acc_nr'''
 
; '''acc_nr'''
: Zahl >= 0 (Nummer der Weiche/des Signals)
+
:   Zahl >= 0 (Nummer der Weiche/des Signals)
 
; '''acc_port'''
 
; '''acc_port'''
: 0, 1 (Ausgang des Dekoders)
+
:   0, 1 (Ausgang des Dekoders)
 
; '''action'''
 
; '''action'''
: 0, 1 (0 = deaktiviert, 1 = aktiviert)
+
:   0, 1 (0 = deaktiviert, 1 = aktiviert)
 
; '''delay'''
 
; '''delay'''
: Wert in Millisekunden (1000stel-Sekunden). Gibt an, nach welcher Zeit der Daemon einen aktivierten Ausgang automatisch deaktivieren soll. Wird "-1" als delay übergeben, dann wird der Ausgang nicht automatisch deaktiviert. Ist action=0 (Deaktivierung) wird delay ignoriert, muß aber angegeben werden (sinnvoller Wert: "-1").
+
:   Wert in Millisekunden (1000stel-Sekunden). Gibt an, nach welcher Zeit der Daemon einen aktivierten Ausgang automatisch deaktivieren soll. Wird "-1" als delay übergeben, dann wird der Ausgang nicht automatisch deaktiviert. Ist action=0 (Deaktivierung) wird delay ignoriert, muß aber angegeben werden (sinnvoller Wert: "-1").
  
 
Belegung der Dekoderausgänge:
 
Belegung der Dekoderausgänge:
Zeile 283: Zeile 275:
  
 
----
 
----
 
 
 
   SET GA M 0023 1 1 20
 
   SET GA M 0023 1 1 20
 
 
----
 
----
  
=== TIME ===
+
 
 +
''' TIME '''
  
 
----
 
----
 
 
 
 
       SET TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>
 
       SET TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>
 
 
----
 
----
  
Zeile 309: Zeile 295:
  
 
; '''Tag'''
 
; '''Tag'''
: sequentielle Folge von Tageszahlen (julianisch)
+
:   sequentielle Folge von Tageszahlen (julianisch)
 
; '''Stunde'''
 
; '''Stunde'''
: 0..23, besteht aus 60 MINUTEN
+
:   0..23, besteht aus 60 MINUTEN
 
; '''Minute'''
 
; '''Minute'''
: 0..59, besteht aus 60 SEKUNDEN
+
:   0..59, besteht aus 60 SEKUNDEN
 
; '''Sekunde'''
 
; '''Sekunde'''
: 0..59
+
:   0..59
 
; '''FX, FY'''
 
; '''FX, FY'''
: Ganzzahlige Bestandteile der Zeitverzerrung
+
:   Ganzzahlige Bestandteile der Zeitverzerrung
  
 
Beispiel:
 
Beispiel:
  
 
----
 
----
 
 
 
   SET TIME 1 23 55 0 1 1
 
   SET TIME 1 23 55 0 1 1
 
 
----
 
----
  
setzt auf den Abend des ersten Tages mit Modellzeit gleich Realzeit. (vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-init-time INIT TIME])
+
setzt auf den Abend des ersten Tages mit Modellzeit gleich Realzeit. (vgl. INIT TIME)
  
=== POWER ===
+
 
 +
''' POWER '''
  
 
----
 
----
 
 
 
 
       SET POWER <state> <freetext>
 
       SET POWER <state> <freetext>
 
 
----
 
----
  
Zeile 348: Zeile 328:
  
 
; '''State'''
 
; '''State'''
: ;; '''ON'''
+
:
:: Schaltet die Energieversorgung ein
+
:;   '''ON'''
;; '''OFF'''
+
::     Schaltet die Energieversorgung ein
:: Schaltet die Energieversorgung ab
+
:;   '''OFF'''
 +
::     Schaltet die Energieversorgung ab
 
; '''Freetext'''
 
; '''Freetext'''
: Ein optionaler Text mit maximal 100 Zeichen, der an das INFO Packet angehängt wird und nähere Informationen geben kann. Es werden ausdrücklich keine Vorgaben über den Inhalt gemacht.
+
:   Ein optionaler Text mit maximal 100 Zeichen, der an das INFO Packet angehängt wird und nähere Informationen geben kann. Es werden ausdrücklich keine Vorgaben über den Inhalt gemacht.
  
=== Befehlsparameter des Befehls GET ===
 
  
=== Gerätegruppe GL ===
+
==== Befehlsparameter des Befehls GET ====
 +
 
 +
''' Gerätegruppe GL '''
  
 
----
 
----
 
 
 
   GET GL <protocol> <addr>
 
   GET GL <protocol> <addr>
 
 
----
 
----
  
Zeile 373: Zeile 352:
 
* Server -> Client: Kommandoport
 
* Server -> Client: Kommandoport
  
Bedeutung der Argumente: siehe [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-set-gl SET GL]
+
Bedeutung der Argumente: siehe SET GL
  
 
Der Server sendet an den Client alle verfügbare Info zu dem mit >protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder. Diese Info muß wie folgt formatiert werden:
 
Der Server sendet an den Client alle verfügbare Info zu dem mit >protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder. Diese Info muß wie folgt formatiert werden:
  
 
----
 
----
 
 
 
   INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
   INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
 
----
 
----
  
(vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-set-gl SET GL])
+
(vgl. SET GL)
  
Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd Digitalsteuerung]).
+
Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. Digitalsteuerung).
  
=== Gerätegruppe GA ===
+
 
 +
''' Gerätegruppe GA '''
  
 
----
 
----
 
 
 
   GET GA <protocol> <acc_nr> <acc_port>
 
   GET GA <protocol> <acc_nr> <acc_port>
 
 
----
 
----
  
Zeile 404: Zeile 378:
 
* Server -> Client: Kommandoport
 
* Server -> Client: Kommandoport
  
Bedeutung der Argumente: siehe [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-set-ga SET GA]
+
Bedeutung der Argumente: siehe SET GA
  
 
Der Server sendet an den Client alle verfügbare Info zu dem mit <protocol> und <acc_nr> spezifizierten Schaltdekoder. Diese Info muß wie folgt formatiert werden:
 
Der Server sendet an den Client alle verfügbare Info zu dem mit <protocol> und <acc_nr> spezifizierten Schaltdekoder. Diese Info muß wie folgt formatiert werden:
  
 
----
 
----
 
 
 
   INFO GA <protocol> <acc_nr> <acc_port> <state>
 
   INFO GA <protocol> <acc_nr> <acc_port> <state>
 
 
----
 
----
  
(vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-set-ga SET GA], ersetze <state> durch <action>)
+
(vgl. SET GA, ersetze <state> durch <action>)
  
Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd Digitalsteuerung]).
+
Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. Digitalsteuerung).
  
=== Gerätegruppe FB ===
+
 
 +
''' Gerätegruppe FB '''
  
 
----
 
----
 
 
 
   GET FB <module-type> <portnr>
 
   GET FB <module-type> <portnr>
 
 
----
 
----
  
Zeile 438: Zeile 407:
  
 
; '''module-type'''
 
; '''module-type'''
: :* S88 (Märklin s88-Bus am Parallelport des PC)
+
:  
:* I8255 (i8255 Karte)
+
:*     S88 (Märklin s88-Bus am Parallelport des PC)
:* M6051 (Märklin s88-Bus via Interface 6051)
+
:*     I8255 (i8255 Karte)
 +
:*     M6051 (Märklin s88-Bus via Interface 6051)
 
; '''portnr'''
 
; '''portnr'''
: konkreter Eingang eines Rückmeldemoduls oder "*" für alle verfügbaren Eingänge
+
:   konkreter Eingang eines Rückmeldemoduls oder "*" für alle verfügbaren Eingänge
  
 
Der Server sendet auf dem Rückmeldekanal an den Client den aktuellen Status des mit <module-type> und <portnr> spezifizierten Rückmeldemoduleingangs. Diese Info muß wie folgt formatiert werden:
 
Der Server sendet auf dem Rückmeldekanal an den Client den aktuellen Status des mit <module-type> und <portnr> spezifizierten Rückmeldemoduleingangs. Diese Info muß wie folgt formatiert werden:
  
 
----
 
----
 
 
 
   INFO FB <module-type> <portnr> <state>
 
   INFO FB <module-type> <portnr> <state>
 
 
----
 
----
  
Zeile 460: Zeile 427:
  
 
----
 
----
 
 
 
   INFO FB M6051 * 1100110010101111
 
   INFO FB M6051 * 1100110010101111
 
 
----
 
----
  
Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-basics Befehle und Gerätegruppen]).
+
Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. Befehle und Gerätegruppen).
  
=== Servicemode ===
+
 
 +
''' Servicemode '''
  
 
Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations- variablen diverser Dekoder spezifizieren.
 
Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations- variablen diverser Dekoder spezifizieren.
  
=== Zeit ===
 
  
----
+
''' Zeit '''
  
+
----
 
   GET TIME
 
   GET TIME
 
 
----
 
----
  
Zeile 489: Zeile 452:
  
 
----
 
----
 
 
 
   INFO TIME 7 23 00 01 10 1
 
   INFO TIME 7 23 00 01 10 1
 
 
----
 
----
  
Sollte keine Modellzeit definiert sein, so muß der Server dies mit "INFO -2" (no data) an den Client senden (vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-basics Befehle und Gerätegruppen]).
+
Sollte keine Modellzeit definiert sein, so muß der Server dies mit "INFO -2" (no data) an den Client senden (vgl. Befehle und Gerätegruppen).
  
=== Power ===
+
 
 +
''' Power '''
  
 
----
 
----
 
 
 
   GET POWER
 
   GET POWER
 
 
----
 
----
  
Zeile 513: Zeile 471:
 
Ermittelt den aktuellen Zustand der Energieversorgung als INFO POWER
 
Ermittelt den aktuellen Zustand der Energieversorgung als INFO POWER
  
=== Befehlsparameter des Befehls WAIT ===
 
  
=== Gerätegruppe FB ===
+
==== Befehlsparameter des Befehls WAIT ====
 +
 
 +
''' Gerätegruppe FB '''
  
 
----
 
----
 
 
 
   WAIT FB <module-type> <portnr> <value> <timeout>
 
   WAIT FB <module-type> <portnr> <value> <timeout>
 
 
----
 
----
  
Zeile 535: Zeile 491:
 
Sollte keine Information vorhanden sein, oder der Server den Befehl WAIT nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. 3.1).
 
Sollte keine Information vorhanden sein, oder der Server den Befehl WAIT nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. 3.1).
  
=== TIME ===
+
 
 +
''' TIME '''
  
 
----
 
----
 
 
 
   WAIT TIME TAG STUNDE MINUTE SEKUNDE
 
   WAIT TIME TAG STUNDE MINUTE SEKUNDE
 
 
----
 
----
  
Zeile 553: Zeile 507:
 
bei nicht initialisiertem Zeitgeber wird "INFO -1" geliefert. Ist die aktuelle Modellzeit bereits später als die übergebende Zeit ist die Bedingung ohne weitere Wartezeit erfüllt. Offensichtlich falsche Zeitangaben werden durch "INFO -1" an den anfordernden Client ignoriert.
 
bei nicht initialisiertem Zeitgeber wird "INFO -1" geliefert. Ist die aktuelle Modellzeit bereits später als die übergebende Zeit ist die Bedingung ohne weitere Wartezeit erfüllt. Offensichtlich falsche Zeitangaben werden durch "INFO -1" an den anfordernden Client ignoriert.
  
=== Befehlsparameter des Befehls INIT ===
 
  
=== Feeback Module ===
+
==== Befehlsparameter des Befehls INIT ====
 +
 
 +
''' Feedback Module '''
  
 
----
 
----
 
 
 
   INIT FB <module-type>
 
   INIT FB <module-type>
 
 
----
 
----
  
Zeile 571: Zeile 523:
 
Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht an den Client.
 
Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht an den Client.
  
=== TIME ===
 
  
----
+
''' TIME '''
  
+
----
 
   INIT TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>
 
   INIT TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>
 
 
----
 
----
  
Zeile 585: Zeile 535:
  
 
----
 
----
 
 
 
 
   (Delta) Modellzeit = (Delta) Realzeit * FX / FY
 
   (Delta) Modellzeit = (Delta) Realzeit * FX / FY
 
 
----
 
----
  
Zeile 600: Zeile 546:
 
Die Tageszahl wird fortlaufend alle 24 Modellstunden hochgezählt.
 
Die Tageszahl wird fortlaufend alle 24 Modellstunden hochgezählt.
  
=== Befehlsparameter des Befehls TERM ===
+
 
 +
==== Befehlsparameter des Befehls TERM ====
  
 
Keine bislang
 
Keine bislang
 +
 +
  
 
== 4. Kommandos zur Dekoderprogrammierung ==
 
== 4. Kommandos zur Dekoderprogrammierung ==
Zeile 608: Zeile 557:
 
Es gibt Dekoder, die auf einem Programmiergleis oder "on-track" programmierbar sind. Diese Dekoder erlauben die Änderung von "Speicherzellen" (Register, CV (configuration variable), Bit). Diese Dekoder können auch von SRCP-Servern unterstützt werden. Dazu werden die Befehle WRITE, VERIFY und READ spezifiziert.
 
Es gibt Dekoder, die auf einem Programmiergleis oder "on-track" programmierbar sind. Diese Dekoder erlauben die Änderung von "Speicherzellen" (Register, CV (configuration variable), Bit). Diese Dekoder können auch von SRCP-Servern unterstützt werden. Dazu werden die Befehle WRITE, VERIFY und READ spezifiziert.
  
== 4.1 Dekodereinstellungen ändern ==
 
  
----
+
=== 4.1 Dekodereinstellungen ändern ===
  
+
----
 
   WRITE GL <protocol> <dest-type> <dest-addr> <value>
 
   WRITE GL <protocol> <dest-type> <dest-addr> <value>
 
   WRITE GA <protocol> <dest-type> <dest-addr> <value>
 
   WRITE GA <protocol> <dest-type> <dest-addr> <value>
 
 
----
 
----
  
Zeile 628: Zeile 575:
  
 
; '''protocol'''
 
; '''protocol'''
: NMRA, ...
+
:   NMRA, ...
 
; '''dest-type'''
 
; '''dest-type'''
: Art der zu ändernden Dekoderspeicherzelle (destination type)
+
:   Art der zu ändernden Dekoderspeicherzelle (destination type)
;; '''CV'''
+
:;   '''CV'''
:: NMRA-DCC configuration variable
+
::     NMRA-DCC configuration variable
;; '''CVBIT'''
+
:;   '''CVBIT'''
:: ein Bit einer NMRA-DCC configuration variable
+
::     ein Bit einer NMRA-DCC configuration variable
;; '''REG'''
+
:;   '''REG'''
:: Ein Register eines NMRA-DCC-Dekoders
+
::     Ein Register eines NMRA-DCC-Dekoders
 
; '''dest-addr'''
 
; '''dest-addr'''
: Adresse der Speicherzelle, die geändert werden soll
+
:   Adresse der Speicherzelle, die geändert werden soll
 
; '''value'''
 
; '''value'''
: neuer Wert der Speicherzelle
+
:   neuer Wert der Speicherzelle
  
 
Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines WRITE-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:
 
Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines WRITE-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:
  
 
----
 
----
 
 
 
   INFO GL SM <value>
 
   INFO GL SM <value>
 
   INFO GA SM <value>
 
   INFO GA SM <value>
 
 
----
 
----
  
Zeile 660: Zeile 604:
 
Sollte WRITE oder ein bestimmter Parameter von WRITE nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".
 
Sollte WRITE oder ein bestimmter Parameter von WRITE nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".
  
== 4.2 Dekodereinstellungen verifizieren ==
+
 
 +
=== 4.2 Dekodereinstellungen verifizieren ===
  
 
----
 
----
 
 
 
   VERIFY GL <protocol> <dest-type> <dest-addr> <value>
 
   VERIFY GL <protocol> <dest-type> <dest-addr> <value>
 
   VERIFY GA <protocol> <dest-type> <dest-addr> <value>
 
   VERIFY GA <protocol> <dest-type> <dest-addr> <value>
 
 
 
----
 
----
  
Zeile 681: Zeile 622:
  
 
; '''protocol'''
 
; '''protocol'''
: NMRA, ...
+
:   NMRA, ...
 
; '''dest-type'''
 
; '''dest-type'''
: Art der zu verifizierenden Dekoderspeicherzelle (destination type)
+
:   Art der zu verifizierenden Dekoderspeicherzelle (destination type)
;; '''CV'''
+
:;   '''CV'''
:: NMRA-DCC configuration variable
+
::     NMRA-DCC configuration variable
;; '''REG'''
+
:;   '''REG'''
:: Ein Register eines NMRA-DCC-Dekoders
+
::     Ein Register eines NMRA-DCC-Dekoders
 
; '''dest-addr'''
 
; '''dest-addr'''
: Adresse der Speicherzelle, die verifiziert werden soll
+
:   Adresse der Speicherzelle, die verifiziert werden soll
 
; '''value'''
 
; '''value'''
: zu verifizierender Wert der Speicherzelle
+
:   zu verifizierender Wert der Speicherzelle
  
 
Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines VERIFY-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:
 
Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines VERIFY-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:
  
 
----
 
----
 
 
 
     INFO GL SM <value>
 
     INFO GL SM <value>
 
     INFO GA SM <value>
 
     INFO GA SM <value>
 
 
 
----
 
----
  
Zeile 712: Zeile 649:
 
Sollte VERIFY oder ein bestimmter Parameter von VERIFY nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".
 
Sollte VERIFY oder ein bestimmter Parameter von VERIFY nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".
  
== 4.3 Dekodereinstellungen auslesen ==
+
 
 +
=== 4.3 Dekodereinstellungen auslesen ===
  
 
Reserviert für zukünftige Erweiterungen.
 
Reserviert für zukünftige Erweiterungen.
 +
 +
  
 
== 5. Datenformate der Serverinformationen ==
 
== 5. Datenformate der Serverinformationen ==
  
== 5.1 Rückmeldepollport ==
+
=== 5.1 Rückmeldepollport ===
  
 
Die Datenübertragung auf dem Rückmeldepollport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgendem Format übertragen werden:
 
Die Datenübertragung auf dem Rückmeldepollport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgendem Format übertragen werden:
  
 
----
 
----
 
 
 
   INFO FB <module-type> <portnr> <state>
 
   INFO FB <module-type> <portnr> <state>
 
 
----
 
----
  
(vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-get-fb GET FB])
+
(vgl. GET FB)
  
 
Beim Öffnen des Ports werden sofort alle aktuell _belegten_ (state == 1) FB-Ports an den Client übermittelt. Anschließend alle Veränderungen.
 
Beim Öffnen des Ports werden sofort alle aktuell _belegten_ (state == 1) FB-Ports an den Client übermittelt. Anschließend alle Veränderungen.
  
== 5.2 Informationsport ==
+
 
 +
=== 5.2 Informationsport ===
  
 
Die Datenübertragung auf dem Informationsport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgenden Formaten - abhängig von der Gerätegruppe - übertragen werden:
 
Die Datenübertragung auf dem Informationsport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgenden Formaten - abhängig von der Gerätegruppe - übertragen werden:
  
 
----
 
----
 
 
 
   INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
   INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
 
----
 
----
  
(vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-get-gl GET GL])
+
(vgl. GET GL)
  
 
----
 
----
 
 
 
   INFO GA <protocol> <acc_nr> <acc_port> <state>
 
   INFO GA <protocol> <acc_nr> <acc_port> <state>
 
 
----
 
----
  
(vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-get-ga GET GA])
+
(vgl. GET GA)
  
 
----
 
----
 
 
 
   INFO TIME <TAG> <STUNDE> <MINUTE> <SEKUNDE> <FX> <FY>
 
   INFO TIME <TAG> <STUNDE> <MINUTE> <SEKUNDE> <FX> <FY>
 
 
----
 
----
  
(vgl. [http://www.der-moba.de/old/Digital/srcp-0.7.1/srcp.html#sec-cmd-parm-get-time GET TIME])
+
(vgl. GET TIME)
  
 
----
 
----
 
 
 
   INFO POWER ON|OFF <erläuternder Text>
 
   INFO POWER ON|OFF <erläuternder Text>
 
 
----
 
----
  
 
Der Zustand der Energierversorgung: Aktiv oder nicht aktiv. Der optionale "erläuternde Text" kann Hinweise auf die Ursache der Veränderung enthalten, er wird ggf. dem begleitenden Text des "SET POWER" Befehls entnommen. Bei automatisch erzeugten Texten ist sicherzustellen, das die Textlänge 100 Zeichen nicht übersteigt.
 
Der Zustand der Energierversorgung: Aktiv oder nicht aktiv. Der optionale "erläuternde Text" kann Hinweise auf die Ursache der Veränderung enthalten, er wird ggf. dem begleitenden Text des "SET POWER" Befehls entnommen. Bei automatisch erzeugten Texten ist sicherzustellen, das die Textlänge 100 Zeichen nicht übersteigt.
 +
 +
  
 
== 6. Ausblicke, zukünftige Erweiterungen ==
 
== 6. Ausblicke, zukünftige Erweiterungen ==
Zeile 777: Zeile 705:
 
Ich habe bewußt einige Ideen, die andiskutiert wurden, nicht mit aufgenommen. Ich bin der Meinung, daß wir einen vorläufigen Schlußstrich ziehen und die ganzen netten Dinge implementieren sollten. Damit die anderen guten Ideen nicht verloren gehen, werde ich sie in diesem Abschnitt aufführen.
 
Ich habe bewußt einige Ideen, die andiskutiert wurden, nicht mit aufgenommen. Ich bin der Meinung, daß wir einen vorläufigen Schlußstrich ziehen und die ganzen netten Dinge implementieren sollten. Damit die anderen guten Ideen nicht verloren gehen, werde ich sie in diesem Abschnitt aufführen.
  
== 6.1 Zentrale Konfiguration ==
+
 
 +
=== 6.1 Zentrale Konfiguration ===
  
 
Von Kurt Haders stammt der Vorschlag einer zentralen Konfigurationsdatei. Hauptanliegen ist es, mehr "Wissen" von den Clients in den Server zu verlagern. Ein Format, wie eine solche Konfigurationsdatei aussehen soll, liegt noch nicht vor. Das Übertragungsprotokoll ist duch den Protokollbezeichner "PS" (protocol by server) bereits darauf vorbereitet.
 
Von Kurt Haders stammt der Vorschlag einer zentralen Konfigurationsdatei. Hauptanliegen ist es, mehr "Wissen" von den Clients in den Server zu verlagern. Ein Format, wie eine solche Konfigurationsdatei aussehen soll, liegt noch nicht vor. Das Übertragungsprotokoll ist duch den Protokollbezeichner "PS" (protocol by server) bereits darauf vorbereitet.
  
== 6.2 Erweiterung der Befehle auf andere Gerätegruppen ==
+
 
 +
=== 6.2 Erweiterung der Befehle auf andere Gerätegruppen ===
  
 
Von Matthias Trute kommt der Vorschlag den Befehl WAIT auch für die Gerätegruppen GL und GA zuzulassen. Allerdings kann es hierbei zu Inkonsistenzen kommen. Weiterhin könnte man man bei WAIT Wildcards ("*") zulassen.
 
Von Matthias Trute kommt der Vorschlag den Befehl WAIT auch für die Gerätegruppen GL und GA zuzulassen. Allerdings kann es hierbei zu Inkonsistenzen kommen. Weiterhin könnte man man bei WAIT Wildcards ("*") zulassen.
  
== 6.3 Quittierung von Befehlen ==
+
 
 +
=== 6.3 Quittierung von Befehlen ===
  
 
Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über den Rückkanal des Kommandoports realisiert werden.
 
Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über den Rückkanal des Kommandoports realisiert werden.
  
== 6.4 Konfiguration des Servers auslesen ==
+
 
 +
=== 6.4 Konfiguration des Servers auslesen ===
  
 
Von Edbert van Eimeren kommt der Vorschlag, daß Clients die Konfiguration des Servers abfragen können sollten (neuer Befehl: CONFGET).
 
Von Edbert van Eimeren kommt der Vorschlag, daß Clients die Konfiguration des Servers abfragen können sollten (neuer Befehl: CONFGET).

Aktuelle Version vom 1. März 2006, 01:01 Uhr

Torsten Vogt, Martin Ostermann, Kurt Haders, Olaf Schlachter, Matthias Trute, Tobias Schlottke, Edbert van Eimeren, Stefan Bormann, Michael Reukauff

Juni 2000


1. Einleitung

Das SRCP beschreibt einen Befehlssatz zur Client-Server-Kommunikation zwischen Serverprozessen zur Steuerung von digitalen Modelleisenbahnen und deren Clients. Serverprozesse sind entweder Software-Signalgeneratoren oder Treiber für HW-Interfaces. Clients sind typischerweise Steuerungsprogramme.

Der SRCP-Befehlssatz besteht aus Kommandos, die direkt das Verhalten des Servers betreffen und aus Kommandos, die für die Dekoder der Modellbahnanlage bestimmt sind. Weiterhin werden Kommandos, die die Verarbeitung von Rückmeldungen betreffen spezifiziert.

Der Server kann über ein Zeitgebermodul verfügen, das alle Clients mit einer einheitlichen Modellzeit versorgen kann.


1.1 Konventionen

Die Übertragung der Kommandos von den Clients zum Server erfolgt via tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF), #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR), #13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.

Die Worte der Kommandos können aus der Menge der Zeichen { "0".."9", "*", "-", "A".."Z", "a".."z" } gebildet werden. Der Server wertet die Kommandos case-sensitive aus, d.h. zwischen Groß- und Kleinbuchstaben wird unterschieden.

Kommandos, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert.


1.2 Übertragungskanäle

Ein SRCP-konformer Server stellt den Clients drei Ports zur Verfügung.

  1. Kommandoport
  2. Rückmeldepollport
  3. Informationsport

Der Kommandoport dient den Clients dazu, dem Server Kommandos übermitteln. Der Server versucht die Kommandos auszuführen. Bei manchen Kommandos erwartet der Client eine Antwort. Die Antwort des Servers wird ebenfalls über den Kommandoport abgewickelt.

Der Rückmeldepollport wird nur unidirektional vom Server zum Client benutzt. Meldet sich ein Client am Rückmeldepollport an, so sendet der Server jede Statusänderung einer Rückmeldeeinheit an den Client zurück. Mit diesem Mechanismus ist es möglich, Rückmeldungen beim Client ereignisgesteuert zu bearbeiten.

Auch der Informationsport wird nur unidirektional von Server zu den Clients benutzt. Er ist eine Art Broadcast-Kanal, der ständig vom Server mit Statusänderungen von Lokdekodern und Schaltdekodern gefüttert wird. Er dient dem asynchronen Abgleich mehrerer Clients am selben Server.

Der Server bestimmt die Portnummern. Standardportnummer für den Kommandoport ist 12345. Der Rückmeldepollport und der Informationsport sind die beiden unmittelbar folgenden Portnummern. Standardmässig ergeben sich somit folgende Portnummern:

  • Kommandoport : 12345
  • Rückmeldepollport: 12346
  • Informationsport : 12347

Nimmt ein Client zum Kommandoport Kontakt auf, muß der Server zunächst einen einzeiligen Informationstext über diesen Port zum Client schicken. Dieser Text sollte den Namen des Servers, dessen Versionsnummer und die implementierte SRCP-Version enthalten.

Beispiel:


erddcd v0.9.511; SRCP 0.5.0

Anschliesend wartet der Server auf Kommandos des Client. Der Client muß den Informationstext lesen und kann nun seinerseits Kommandos an den Server schicken.


2. Allgemeine Kommandos zur Serversteuerung

Kommunikationsports

  • Client -> Server: Kommandoport
  • Server -> Client: entfällt

Kommandos

  • SHUTDOWN : Der Server beendet sich
  • LOGOUT : Dem Server wird angzeigt, dass sich ein Client ausloggt
  • RESET : Der Server re-initialisiert sich

Folgende Kommandos sind von Clients nicht mehr zu verwenden, müssen vom Server jedoch implementiert werden

  • STARTVOLTAGE identisch mit SET POWER ON
  • STOPVOLTAGE identisch mit SET POWER OFF


3. Kommandos zur Digitalsteuerung

3.1 Befehle und Gerätegruppen

SRCP definiert 8 generelle Befehle, die über den Kommandoport abgewickelt werden.

SET
Setzt einen Wert vom Client über den Server zum Gerät.
GET
Ermittelt den aktuellen Zustand eines Gerätes.
WAIT
Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
INIT
Falls Geräte explizit initialisiert werden müssen.
TERM
Falls die mit INIT getroffenen Einstellungen wieder entfernt werden sollen.
WRITE
Setzt einen Wert vom Client und liefert eine Antwort zurück.
VERIFY
Überprüft, ob ein Wert einen bestimmten Wert hat.
READ
Liest einen Wert aus, ist das GET-Pendant zu WRITE.

Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder, Rückmeldeeinheiten und sonstigen Bereichen.

Über Parameter wird festgelegt, auf welche Gerätegruppe sich ein Befehl bezieht. Der erste Parameter legt immer die Gerätegruppe fest:

Die Befehle WRITE, VERIFY und READ sind für die Verwendung von Programmierinterfaces (Dekoder) vorgesehen.

GL
Lok- und Funktionsdekoder (generic loco)
GA
Schaltdekoder (generic accessory)
FB
Rückmeldeeinheit (feedback)
TIME
Zeitnormal
POWER
Energieversorgung der Modellanlage

Anwendbarkeit der Befehle auf Gerätegruppen:


        |  SET  GET  WAIT  INIT TERM
     ---+----------------------------
        |
     GL |   x    x    -     -    -
        |
     GA |   x    x    -     -    -
        |
     FB |   -    x    x     x    -
        |
   TIME |   x    x    x     x    -
        |
  POWER |   x    x    -     -    -

Bei den Befehlen GET und WAIT erwartet der Client vom Server eine Antwort. Es kann nun vorkommen, daß der Server zur gestellten Anfrage keine Antwort geben kann. In diesen Fällen muß der Server eine Zeichenkette zum Client senden, die folgendem Format genügt:


  INFO <error code> \n

Als "error code" muß eine negative Zahl übergeben werden. Folgende Konventionen gelten:

INFO -1 ==> Befehl wird nicht unterstützt (not supported)

INFO -2 ==> Keine Information vorhanden (no data)

INFO -3 ==> Zeitlimit überschritten (vgl. WAIT) (timeout)


3.2 Weitere Befehlsparameter

Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät und welche Eigenschaften beeinflußt oder abgefragt werden sollen.


Befehlsparameter des Befehls SET

Gerätegruppe GL


  SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports

  • Client -> Server: Kommandoport
  • Server -> Client: entfällt

Bedeutung der Argumente:

protocol
M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS
  • M1: Märklin alt (rel. FRU, 80 Adr., 1 Funkt., 14 FS)
  • M2: Märklin neu (abs. FRU, 80 Adr., 5 Funkt., 14 FS)
  • M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)
  • M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)
  • M5: M2 erweitert nach Märklin (abs. FRU, 80 Adr, 5 Funkt., 27 FS)
  • MF: altes Märklin Format für Funktionsdekoder
  • NB: NMRA-DCC Basisprotokoll (abs. FRU, 7-bit-Adr., 14 FS)
  • N1: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 28 FS)
  • N2: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5 Funkt., 128 FS)
  • N3: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 28 FS)
  • N4: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5 Funkt., 128 FS)
  • PS: protocol by server, der Server bestimmt den Protokolltyp
addr
Zahl >= 0
direction
0 (= rückwärts), 1 (= vorwärts), 2 (= Nothalt)
V
0 .. V_max ((virtuelle) Geschwindigkeit)
V_max
0 .. 999 (maximale (virtuelle) Geschwindigkeit) V_max=0 ==> virtuelle Fahrstufe = reale Fahrstufe
func
0 (= aus), 1 (= an)
nro_f
0 .. x (Anzahl der Zusatzfunktionen (number of functions))
f1 .. fn
0 (= aus), 1 (= an)

Beispiel


  SET GL N2 1 1 50 250 1 4 0 1 0 0

Umrechnung der virtuellen Geschwindigkeit in echte Fahrstufen:

gegeben sind

  • DEC_fs (Anzahl der realen Dekoderfahrstufen, implizit bekannt)
  • V (virtuelle Geschwindigkeit, Argument)
  • V_max (maximale virtuelle Geschwindigkeit, Argument)

gesucht

  • V_fs (reale Fahrstufe, die der virtuellen Geschw. entspricht)

Algorithmus: V_fs = round((V * DEC_fs)/V_max)

Hinweise für Entwickler von SRCP-konformen Servern

Es ist darauf zu achten, daß wirklich nur dann die reale Fahrstufe 0 (Stillstand) errechnet wird, wenn das Argument V gleich Null ist. Die Funktion "round" ist deshalb hinreichend intelligent zu implementieren.

V_fs darf nur als Geschwindigkeitsangabe interpretiert werden. Manche Dekoder reagieren z.B. bei Fahrstufe 1 mit einem Nothalt, andere mit einem Richtungswechsel, wieder andere mit einer Selbstzerstörungssequenz ;-). Sollen solche Dekoder unterstützt werden, dann hat der Server dafür zu sorgen, daß V_fs entsprechend angepaßt wird, bevor das Kommando an den Dekoder gesendet wird. Aus Sicht der Clients müssen die Fahrstufen sukzessive von 0 bis zur maximalen Fahrstufenanzahl durchnummeriert sein.

Wird V_max auf 0 gesetzt, dann darf keine Umrechnung der Fahrstufe vorgenommen werden. D.h. die mit V übermittelte Fahrstufe ist direkt an die Dekoder weiterzusenden. Dies erlaubt Clients den direkten Zugriff auf die Dekoder.

Sendet der Client den Protokolltyp PS (protocol by server), dann muß der Server entscheiden, welches Protokoll er für die übermittelte Adresse wählt. Die anderen Protokolltypen stellen für den Server natürlich auch nur Empfehlungen des Clients dar. Der Server hat immer die Freiheit, einer Adresse ein anderes, geeigneteres Protokoll zuzuweisen.

Beispiele


      (50*28)/250 = 5.7   ==> V_fs = 6
      (4*28)/250  = 0.448 ==> V_fs = 1 (!!!)
      (0*28)/250  = 0     ==> V_fs = 0


Gerätegruppe GA


  SET GA <protocol> <acc_nr> <acc_port> <action> <delay>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: entfällt

Bedeutung der Argumente

protocol
  • M: Märklin/Motorola-Format
  • N: NMRA-DCC-Format
acc_nr
Zahl >= 0 (Nummer der Weiche/des Signals)
acc_port
0, 1 (Ausgang des Dekoders)
action
0, 1 (0 = deaktiviert, 1 = aktiviert)
delay
Wert in Millisekunden (1000stel-Sekunden). Gibt an, nach welcher Zeit der Daemon einen aktivierten Ausgang automatisch deaktivieren soll. Wird "-1" als delay übergeben, dann wird der Ausgang nicht automatisch deaktiviert. Ist action=0 (Deaktivierung) wird delay ignoriert, muß aber angegeben werden (sinnvoller Wert: "-1").

Belegung der Dekoderausgänge:

  • 0 = Weiche abbiegen, Signal Hp0, ...
  • 1 = Weiche gerade, Signal Hp1, ...

Beispiel:


 SET GA M 0023 1 1 20


TIME


      SET TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: entfällt

Bedeutung der Argumente

Die aktuelle Modellzeit und die Verzerrung gegenüber der Realzeit wird festgelegt. Bei erstmaligen Aufruf vergleichbar mit einem INIT TIME.

Tag
sequentielle Folge von Tageszahlen (julianisch)
Stunde
0..23, besteht aus 60 MINUTEN
Minute
0..59, besteht aus 60 SEKUNDEN
Sekunde
0..59
FX, FY
Ganzzahlige Bestandteile der Zeitverzerrung

Beispiel:


  SET TIME 1 23 55 0 1 1

setzt auf den Abend des ersten Tages mit Modellzeit gleich Realzeit. (vgl. INIT TIME)


POWER


      SET POWER <state> <freetext>

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: entfällt

Bedeutung der Argumente

State
ON
Schaltet die Energieversorgung ein
OFF
Schaltet die Energieversorgung ab
Freetext
Ein optionaler Text mit maximal 100 Zeichen, der an das INFO Packet angehängt wird und nähere Informationen geben kann. Es werden ausdrücklich keine Vorgaben über den Inhalt gemacht.


Befehlsparameter des Befehls GET

Gerätegruppe GL


  GET GL <protocol> <addr>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Bedeutung der Argumente: siehe SET GL

Der Server sendet an den Client alle verfügbare Info zu dem mit >protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder. Diese Info muß wie folgt formatiert werden:


  INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>

(vgl. SET GL)

Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. Digitalsteuerung).


Gerätegruppe GA


  GET GA <protocol> <acc_nr> <acc_port>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Bedeutung der Argumente: siehe SET GA

Der Server sendet an den Client alle verfügbare Info zu dem mit <protocol> und <acc_nr> spezifizierten Schaltdekoder. Diese Info muß wie folgt formatiert werden:


  INFO GA <protocol> <acc_nr> <acc_port> <state>

(vgl. SET GA, ersetze <state> durch <action>)

Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. Digitalsteuerung).


Gerätegruppe FB


  GET FB <module-type> <portnr>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Bedeutung der Argumente

module-type
  • S88 (Märklin s88-Bus am Parallelport des PC)
  • I8255 (i8255 Karte)
  • M6051 (Märklin s88-Bus via Interface 6051)
portnr
konkreter Eingang eines Rückmeldemoduls oder "*" für alle verfügbaren Eingänge

Der Server sendet auf dem Rückmeldekanal an den Client den aktuellen Status des mit <module-type> und <portnr> spezifizierten Rückmeldemoduleingangs. Diese Info muß wie folgt formatiert werden:


  INFO FB <module-type> <portnr> <state>

Wobei state entweder "0" oder "1" sein darf.

Wurde als portnummer der Platzhalter "*" angegeben, so sendet der Server als portnummer den "*" (ohne Hochkomma), gefolgt von den Zuständen aller angeschlossenen Ports. Diese Zustände werden NICHT durch Leerzeichen getrennt.

Beispiel


  INFO FB M6051 * 1100110010101111

Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. Befehle und Gerätegruppen).


Servicemode

Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations- variablen diverser Dekoder spezifizieren.


Zeit


  GET TIME

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Liefert die aktuelle Modellzeit und die Verzerrungsfaktoren als INFO-Zeile


 INFO TIME 7 23 00 01 10 1

Sollte keine Modellzeit definiert sein, so muß der Server dies mit "INFO -2" (no data) an den Client senden (vgl. Befehle und Gerätegruppen).


Power


  GET POWER

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Ermittelt den aktuellen Zustand der Energieversorgung als INFO POWER


Befehlsparameter des Befehls WAIT

Gerätegruppe FB


  WAIT FB <module-type> <portnr> <value> <timeout>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Wartet, bis portnr den Wert value (0,1) annimmt. Wartet aber höchstens timeout Sekunden. Sendet falls der timeout nicht eingetreten ist, die gleiche Information wie GET FB. Sollte der timeout überschritten werden, wird "INFO -3" an den Client gesendet.

Sollte keine Information vorhanden sein, oder der Server den Befehl WAIT nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. 3.1).


TIME


  WAIT TIME TAG STUNDE MINUTE SEKUNDE

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Wartet, bis die Modellzeit den angegebenen Zeitpunkt mind. erreicht hat und liefert einen INFO-String mit der aktuellen Modellzeit.

bei nicht initialisiertem Zeitgeber wird "INFO -1" geliefert. Ist die aktuelle Modellzeit bereits später als die übergebende Zeit ist die Bedingung ohne weitere Wartezeit erfüllt. Offensichtlich falsche Zeitangaben werden durch "INFO -1" an den anfordernden Client ignoriert.


Befehlsparameter des Befehls INIT

Feedback Module


  INIT FB <module-type>

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: entfällt

Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht an den Client.


TIME


  INIT TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>

startet den Zeitgeber mit der Verzerrung FX/FY am angegeben Zeitpunkt. Jede volle Modellminute wird sodann als INFO Paket auf dem INFO-Port aller aktiven und zukünftigen Clients ausgesendet.

Die Modellzeit errechnet sich wie folgt:


  (Delta) Modellzeit = (Delta) Realzeit * FX / FY

Beispiel:

  • FX=10 FY=1 -> Jede Realminute werden 10 Modellminuten generiert (also alle 6 Sekunden eine).
  • FX=1 FY=10 -> Alle 10 Realminuten läuft eine Modellminute ab.
  • FX=1 FY=1 -> Jede Realminute läuft eine Modellminute ab

Die Tageszahl wird fortlaufend alle 24 Modellstunden hochgezählt.


Befehlsparameter des Befehls TERM

Keine bislang


4. Kommandos zur Dekoderprogrammierung

Es gibt Dekoder, die auf einem Programmiergleis oder "on-track" programmierbar sind. Diese Dekoder erlauben die Änderung von "Speicherzellen" (Register, CV (configuration variable), Bit). Diese Dekoder können auch von SRCP-Servern unterstützt werden. Dazu werden die Befehle WRITE, VERIFY und READ spezifiziert.


4.1 Dekodereinstellungen ändern


  WRITE GL <protocol> <dest-type> <dest-addr> <value>
  WRITE GA <protocol> <dest-type> <dest-addr> <value>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Bedeutung der Argumente

protocol
NMRA, ...
dest-type
Art der zu ändernden Dekoderspeicherzelle (destination type)
CV
NMRA-DCC configuration variable
CVBIT
ein Bit einer NMRA-DCC configuration variable
REG
Ein Register eines NMRA-DCC-Dekoders
dest-addr
Adresse der Speicherzelle, die geändert werden soll
value
neuer Wert der Speicherzelle

Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines WRITE-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:


  INFO GL SM <value>
  INFO GA SM <value>

Wobei <value> folgende Werte annehmen kann:

  • 0: WRITE ist fehlgeschlagen
  • 1: WRITE wurde erfolgreich ausgeführt
  • 2: Der Server weiss nicht, ob WRITE erfolgreich war

Sollte WRITE oder ein bestimmter Parameter von WRITE nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".


4.2 Dekodereinstellungen verifizieren


  VERIFY GL <protocol> <dest-type> <dest-addr> <value>
  VERIFY GA <protocol> <dest-type> <dest-addr> <value>

Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"

Kommunikationsports:

  • Client -> Server: Kommandoport
  • Server -> Client: Kommandoport

Bedeutung der Argumente

protocol
NMRA, ...
dest-type
Art der zu verifizierenden Dekoderspeicherzelle (destination type)
CV
NMRA-DCC configuration variable
REG
Ein Register eines NMRA-DCC-Dekoders
dest-addr
Adresse der Speicherzelle, die verifiziert werden soll
value
zu verifizierender Wert der Speicherzelle

Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines VERIFY-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:


    INFO GL SM <value>
    INFO GA SM <value>

Wobei <value> folgende Werte annehmen kann:

  • 0: Der mit <value> angegebene Wert ist nicht der aktuelle Wert der Speicherzelle.
  • 1: Der mit <value> angegebene Wert wurde verifiziert.
  • 2: Der Server kann kein VERIFY durchführen.

Sollte VERIFY oder ein bestimmter Parameter von VERIFY nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".


4.3 Dekodereinstellungen auslesen

Reserviert für zukünftige Erweiterungen.


5. Datenformate der Serverinformationen

5.1 Rückmeldepollport

Die Datenübertragung auf dem Rückmeldepollport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgendem Format übertragen werden:


  INFO FB <module-type> <portnr> <state>

(vgl. GET FB)

Beim Öffnen des Ports werden sofort alle aktuell _belegten_ (state == 1) FB-Ports an den Client übermittelt. Anschließend alle Veränderungen.


5.2 Informationsport

Die Datenübertragung auf dem Informationsport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgenden Formaten - abhängig von der Gerätegruppe - übertragen werden:


  INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>

(vgl. GET GL)


  INFO GA <protocol> <acc_nr> <acc_port> <state>

(vgl. GET GA)


  INFO TIME <TAG> <STUNDE> <MINUTE> <SEKUNDE> <FX> <FY>

(vgl. GET TIME)


 INFO POWER ON|OFF <erläuternder Text>

Der Zustand der Energierversorgung: Aktiv oder nicht aktiv. Der optionale "erläuternde Text" kann Hinweise auf die Ursache der Veränderung enthalten, er wird ggf. dem begleitenden Text des "SET POWER" Befehls entnommen. Bei automatisch erzeugten Texten ist sicherzustellen, das die Textlänge 100 Zeichen nicht übersteigt.


6. Ausblicke, zukünftige Erweiterungen

Ich habe bewußt einige Ideen, die andiskutiert wurden, nicht mit aufgenommen. Ich bin der Meinung, daß wir einen vorläufigen Schlußstrich ziehen und die ganzen netten Dinge implementieren sollten. Damit die anderen guten Ideen nicht verloren gehen, werde ich sie in diesem Abschnitt aufführen.


6.1 Zentrale Konfiguration

Von Kurt Haders stammt der Vorschlag einer zentralen Konfigurationsdatei. Hauptanliegen ist es, mehr "Wissen" von den Clients in den Server zu verlagern. Ein Format, wie eine solche Konfigurationsdatei aussehen soll, liegt noch nicht vor. Das Übertragungsprotokoll ist duch den Protokollbezeichner "PS" (protocol by server) bereits darauf vorbereitet.


6.2 Erweiterung der Befehle auf andere Gerätegruppen

Von Matthias Trute kommt der Vorschlag den Befehl WAIT auch für die Gerätegruppen GL und GA zuzulassen. Allerdings kann es hierbei zu Inkonsistenzen kommen. Weiterhin könnte man man bei WAIT Wildcards ("*") zulassen.


6.3 Quittierung von Befehlen

Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über den Rückkanal des Kommandoports realisiert werden.


6.4 Konfiguration des Servers auslesen

Von Edbert van Eimeren kommt der Vorschlag, daß Clients die Konfiguration des Servers abfragen können sollten (neuer Befehl: CONFGET).