SRCP 0.5.0 (plain text): Unterschied zwischen den Versionen

aus DerMoba, der Wissensdatenbank für Modellbahner
Wechseln zu: Navigation, Suche
K (neu)
 
K (Leerzeichen oder Fata Morgana?)
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
                SRCP - Simple Railroad Command Protocol
+
                    SRCP - Simple Railroad Command Protocol
                            Version 0.5.0
+
                            Version 0.5.0
 
+
              Torsten Vogt, Martin Ostermann, Kurt Haders,  
+
                Torsten Vogt, Martin Ostermann, Kurt Haders,  
            Olaf Schlachter, Matthias Trute, Tobias Schlottke
+
              Olaf Schlachter, Matthias Trute, Tobias Schlottke
                          Edbert van Eimeren
+
                            Edbert van Eimeren
 
+
  1. Einleitung
+
  1. Einleitung
 
+
  Das SRCP beschreibt einen Befehlssatz zur Client-Server-Kommunikation
+
  Das SRCP beschreibt einen Befehlssatz zur Client-Server-Kommunikation
  zwischen Serverprozessen zur Steuerung von digitalen Modelleisenbahnen
+
  zwischen Serverprozessen zur Steuerung von digitalen Modelleisenbahnen
  und deren Clients. Serverprozesse sind entweder Software-Signalgeneratoren
+
  und deren Clients. Serverprozesse sind entweder Software-Signalgeneratoren
  oder Treiber für HW-Interfaces. Clients sind typischerweise  
+
  oder Treiber für HW-Interfaces. Clients sind typischerweise  
  Steuerungsprogramme.
+
  Steuerungsprogramme.
 
+
  Der SRCP-Befehlssatz besteht aus Kommandos, die direkt das Verhalten
+
  Der SRCP-Befehlssatz besteht aus Kommandos, die direkt das Verhalten
  des Servers betreffen und aus Kommandos, die für die Dekoder der  
+
  des Servers betreffen und aus Kommandos, die für die Dekoder der  
  Modellbahnanlage bestimmt sind. Weiterhin werden Kommandos, die die
+
  Modellbahnanlage bestimmt sind. Weiterhin werden Kommandos, die die
  Verarbeitung von Rückmeldungen betreffen spezifiziert.
+
  Verarbeitung von Rückmeldungen betreffen spezifiziert.
 
+
  1.1 Konventionen
+
  1.1 Konventionen
 
+
  Die Übertragung der Kommandos von den Clients zum Server erfolgt via
+
  Die Übertragung der Kommandos von den Clients zum Server erfolgt via
  tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF),
+
  tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF),
  #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR),
+
  #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR),
  #13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch
+
  #13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch
  Whitespace (Leerzeichen, Tabulatoren) getrennt sind.  
+
  Whitespace (Leerzeichen, Tabulatoren) getrennt sind.  
 
+
  Die Worte der Kommandos können aus der Menge der Zeichen  
+
  Die Worte der Kommandos können aus der Menge der Zeichen  
  { '0', .., '9', '-', 'A', .., 'Z', 'a', .., 'z' } gebildet werden.  
+
  { '0', .., '9', '-', 'A', .., 'Z', 'a', .., 'z' } gebildet werden.  
  Der Server wertet die Kommandos case-sensitive aus, d.h. zwischen
+
  Der Server wertet die Kommandos case-sensitive aus, d.h. zwischen
  Groß- und Kleinbuchstaben wird unterschieden.
+
  Groß- und Kleinbuchstaben wird unterschieden.
 
+
  Kommandos, die unvollständig oder offensichtlich falsch sind werden
+
  Kommandos, die unvollständig oder offensichtlich falsch sind werden
  vom Server ignoriert.   
+
  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.
 +
 
 +
      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.  
 
    
 
    
      1. Kommandoport
+
  Der Rückmeldepollport wird nur unidirektional vom Server zum Client benutzt.
      2. Rückmeldepollport
+
  Meldet sich ein Client am Rückmeldepollport an, so sendet der Server
      3. Informationsport
+
  jede Statusänderung einer Rückmeldeeinheit an den Client zurück. Mit
 
+
  diesem Mechanismus ist es möglich, Rückmeldungen beim Client
   Der Kommandoport dient den Clients dazu, dem Server Kommandos
+
  ereignisgesteuert zu bearbeiten.
  übermitteln. Der Server versucht die Kommandos auszuführen. Bei
+
    
  manchen Kommandos erwartet der Client eine Antwort. Die Antwort des
+
  Auch der Informationsport wird nur unidirektional von Server zu den
  Servers wird ebenfalls über den Kommandoport abgewickelt.  
+
  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 Rückmeldepollport wird nur unidirektional vom Server zum Client benutzt.
+
  Der Server bestimmt die Portnummern. Standardportnummer für den
  Meldet sich ein Client am Rückmeldepollport an, so sendet der Server
+
  Kommandoport sollte 12345 sein. Der Rückmeldepollport und der
  jede Statusänderung einer Rückmeldeeinheit an den Client zurück. Mit
+
  Informationsport sollten die beiden unmittelbar folgenden
  diesem Mechanismus ist es möglich, Rückmeldungen beim Client
+
  Portnummern sein. Standardmässig ergeben sich somit folgende
  ereignisgesteuert zu bearbeiten.
+
  Portnummern:
 
   
 
   
  Auch der Informationsport wird nur unidirektional von Server zu den
+
      Kommandoport    : 12345
  Clients benutzt. Er ist eine Art Broadcast-Kanal, der ständig vom Server
+
      Rückmeldepollport: 12346
  mit Statusänderungen von Lokdekodern und Schaltdekodern gefüttert
+
      Informationsport : 12347
  wird. Er dient dem asynchronen Abgleich mehrerer Clients am selben
+
  Server.
+
  Nimmt ein Client zum Kommandoport Kontakt auf und wird vom Server
 
+
  akzeptiert, muß der Server zunächst einen einzeiligen Informationstext  
  Der Server bestimmt die Portnummern. Standardportnummer für den
+
  über diesen Port zum Client schicken. Dieser Text sollte den Namen des  
  Kommandoport sollte 12345 sein. Der Rückmeldepollport und der
+
  Servers, dessen Versionsnummer und die implementierte SRCP-Version
  Informationsport sollten die beiden unmittelbar folgenden
+
  enthalten.   
  Portnummern sein. Standardmässig ergeben sich somit folgende
+
  Portnummern:
+
  Beispiel:    erddcd v0.9.511; SRCP 0.5.0
 
+
    Kommandoport    : 12345
+
  Anschliesend wartet der Server auf Kommandos des Client. Der Client
    Rückmeldepollport: 12346
+
  muß den Informationstext lesen und kann nun seinerseits Kommandos
    Informationsport : 12347
+
  an den Server schicken.
 
+
  Nimmt ein Client zum Kommandoport Kontakt auf und wird vom Server
+
                             
  akzeptiert, muß der Server zunächst einen einzeiligen Informationstext  
+
  2. Kommandos zur Serversteuerung:
  über diesen Port zum Client schicken. Dieser Text sollte den Namen des  
+
  Servers, dessen Versionsnummer und die implementierte SRCP-Version
+
  Kommunikationsports: Client -> Server: Kommandoport
  enthalten.   
+
                        Server -> Client: entfällt
 
+
  Beispiel:    erddcd v0.9.511; SRCP 0.5.0
+
  Kommandos:
 
+
  Anschliesend wartet der Server auf Kommandos des Client. Der Client
+
  SHUTDOWN    : Der Server beendet sich
  muß den Informationstext lesen und kann nun seinerseits Kommandos
+
  LOGOUT      : Dem Server wird angzeigt, dass sich ein Client ausloggt
  an den Server schicken.
+
  STARTVOLTAGE: Der Server schaltet den Digitalstrom am Booster ein
 
+
  STOPVOLTAGE : Der Server schaltet den Digitalstrom am Booster aus
                           
+
  RESET      : Der Server re-initialisiert sich
  2. Kommandos zur Serversteuerung:
+
 
+
  Kommunikationsports: Client -> Server: Kommandoport
+
  3. Kommandos zur Digitalsteuerung
                      Server -> Client: entfällt
+
 
+
  3.1 Befehle und Gerätegruppen
  Kommandos:
+
 
+
  SRCP definiert 4 generelle Befehle:
  SHUTDOWN    : Der Server beendet sich
+
  LOGOUT      : Dem Server wird angzeigt, dass sich ein Client ausloggt
+
      SET      : Setzt einen Wert vom Client über den Server zum Gerät.
  STARTVOLTAGE: Der Server schaltet den Digitalstrom am Booster ein
+
  STOPVOLTAGE : Der Server schaltet den Digitalstrom am Booster aus
+
      GET      : Ermittelt den aktuellen Zustand eines Gerätes.
  RESET      : Der Server re-initialisiert sich
+
 
+
      WAIT    : Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
 
+
  3. Kommandos zur Digitalsteuerung
+
      INIT    : Falls Geräte explizit initialisiert werden müssen.
 
+
  3.1 Befehle und Gerätegruppen
+
  Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder und  
 
+
  Rückmeldeeinheiten.
  SRCP definiert 4 generelle Befehle:
+
 
+
  Über Parameter wird festgelegt, auf welche Gerätegruppe sich ein Befehl
    SET      : Setzt einen Wert vom Client über den Server zum Gerät.
+
  bezieht. Der erste Parameter legt immer die Gerätegruppe fest:
 
+
    GET      : Ermittelt den aktuellen Zustand eines Gerätes.
+
      GL: Lok- und Funktionsdekoder (generic loco)
 
+
      GA: Schaltdekoder (generic accessory)
    WAIT    : Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
+
      FB: Rückmeldeeinheit (feedback)
 
+
    INIT    : Falls Geräte explizit initialisiert werden müssen.
+
  Anwendbarkeit der Befehle auf Gerätegruppen:
 
+
  Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder und  
+
        |  SET  GET  WAIT  INIT
  Rückmeldeeinheiten.
+
      ---+----------------------
 
+
        |
  Über Parameter wird festgelegt, auf welche Gerätegruppe sich ein Befehl
+
      GL |  x    x    -    -   
  bezieht. Der erste Parameter legt immer die Gerätegruppe fest:
+
        |
 
+
      GA |  x    x    -    -
    GL: Lok- und Funktionsdekoder (generic loco)
+
        |
    GA: Schaltdekoder (generic accessory)
+
      FB |  -    x    x    x
    FB: Rückmeldeeinheit (feedback)
+
        |
 
+
  Anwendbarkeit der Befehle auf Gerätegruppen:
+
  Bei einigen Befehlen (GET, WAIT) erwartet der Client vom Server eine
 
+
  Antwort. Es kann nun vorkommen, daß der Server zur gestellten Anfrage
        |  SET  GET  WAIT  INIT
+
  keine Antwort geben kann. In diesen Fällen muß der Server eine  
    ---+----------------------
+
  Zeichenkette zum Client senden, die folgendem Format genügt:
        |
+
    GL |  x    x    -    -   
+
  INFO <error code> \n
        |
+
    GA |  x    x    -    -
+
  Als 'error code' muß eine negative Zahl übergeben werden. Folgende  
        |
+
  Konventionen gelten:
    FB |  -    x    x    x
+
        |
+
  INFO -1    ==> Befehl wird nicht unterstützt      (not supported)
 
+
  INFO -2    ==> Keine Information vorhanden        (no data)
  Bei einigen Befehlen (GET, WAIT) erwartet der Client vom Server eine
+
  INFO -3    ==> Zeitlimit überschritten (vgl. WAIT) (timeout)
  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:
+
  3.2 Weitere Befehlsparameter  
 
+
  INFO <error code> \n
+
  Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät
 
+
  und welche Eigenschaften beeinflußt oder abgefragt werden sollen.
  Als 'error code' muß eine negative Zahl übergeben werden. Folgende  
+
  Konventionen gelten:
+
  3.2.1 Befehlsparameter des Befehls SET
 
+
  INFO -1    ==> Befehl wird nicht unterstützt      (not supported)
+
  3.2.1.1 Gerätegruppe GL
  INFO -2    ==> Keine Information vorhanden        (no data)
+
  INFO -3    ==> Zeitlimit überschritten (vgl. WAIT) (timeout)
+
  SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
 
+
 
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
  3.2 Weitere Befehlsparameter  
+
 
+
  Kommunikationsports: Client -> Server: Kommandoport
  Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät
+
                        Server -> Client: entfällt
  und welche Eigenschaften beeinflußt oder abgefragt werden sollen.
+
 
+
  Bedeutung der Argumente:
  3.2.1 Befehlsparameter des Befehls SET
+
 
+
      protocol : M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS
  3.2.1.1 Gerätegruppe GL
+
               
 
+
                M1: Märklin alt  (rel. FRU, 80 Adr., 1 Funkt., 14 FS)
  SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
+
                M2: Märklin neu  (abs. FRU, 80 Adr., 5 Funkt., 14 FS)
 
+
                M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
+
                M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)
 
+
                MF: altes Märklin Format für Funktionsdekoder
  Kommunikationsports: Client -> Server: Kommandoport
+
                NB: NMRA-DCC Basisprotokoll (abs. FRU, 7-bit-Adr., 14 FS)
                      Server -> Client: entfällt
+
                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)
  Bedeutung der Argumente:
+
                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)
    protocol : M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS
+
                PS: protocol by server, der Server bestimmt den Protokolltyp
 +
 +
      addr    : 0 .. 9999
 +
      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: 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:
 
                
 
                
                 M1: Märklin alt  (rel. FRU, 80 Adr., 1 Funkt., 14 FS)
+
                 Es ist darauf zu achten, daß wirklich nur dann die reale
                M2: Märklin neu  (abs. FRU, 80 Adr., 5 Funkt., 14 FS)
+
                Fahrstufe 0 (Stillstand) errechnet wird, wenn das Argument
                M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)
+
                V gleich Null ist. Die Funktion 'round' ist deshalb  
                M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)
+
                hinreichend intelligent zu implementieren.  
                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    : 0 .. 9999
+
    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: 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
+
 
+
  3.2.1.2 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, N
+
 
+
              M: Märklin/Motorola-Format
+
              N: NMRA-DCC-Format
+
 
+
    acc_nr  : 1 .. 4096    (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
+
 
+
  3.2.1.3 Servicemode
+
 
+
  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 dienen die folgenden Befehle.
+
 
+
  SET GL SM <protocol> <dest-type> <dest-addr> [bitnr] <value>
+
  SET GA SM <protocol> <dest-type> <dest-addr> [bitnr] <value>
+
 
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
+
 
   
 
   
  Kommunikationsports: Client -> Server: Kommandoport
+
                V_fs darf nur als Geschwindigkeitsangabe interpretiert
                      Server -> Client: entfällt
+
                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.
 
   
 
   
  Bedeutung der Argumente:
+
                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.
 
   
 
   
    protocol : NMRA, ...
+
                Sendet der Client den Protokolltyp PS (protocol by server),
    dest-type: Art der zu ändernden Dekoderspeicherzelle (destination type)
+
                dann muß der Server entscheiden, welches Protokoll er für
 
+
                die übermittelte Adresse wählt. Die anderen Protokolltypen
                 CV  : NMRA-DCC configuration variable
+
                 stellen für den Server natürlich auch nur Empfehlungen des
                 CVBIT: ein Bit einer NMRA-DCC configuration variable
+
                 Clients dar. Der Server hat immer die Freiheit, einer Adresse
                 REG  : Ein Register eines NMRA-DCC-Dekoders
+
                 ein anderes, geeigneteres Protokoll zuzuweisen.
 
+
    dest-addr: Adresse der Speicherzelle, die geändert werden soll
+
    bitnr    : nur in Verbindung mit CVBIT sinnvoll
+
    value    : neuer Wert der Speicherzelle
+
 
   
 
   
 
+
      Beispiele: (50*28)/250 = 5.7   ==> V_fs = 6
   3.2.1.4 sonstiges
+
                (4*28)/250  = 0.448 ==> V_fs = 1 (!!!)
 +
                (0*28)/250  = 0    ==> V_fs = 0
 
   
 
   
  Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.
+
  3.2.1.2 Gerätegruppe GA
   für Drehscheiben) spezifizieren.   
+
 
+
  SET GA <protocol> <acc_nr> <acc_port> <action> <delay>
   3.2.2 Befehlsparameter des Befehls GET
+
 
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
  3.2.2.1 Gerätegruppe GL
+
 
+
  Kommunikationsports: Client -> Server: Kommandoport
  GET GL <protocol> <addr>
+
                        Server -> Client: entfällt
 
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
+
  Bedeutung der Argumente:
 +
 +
      protocol: M, N
 +
 +
                M: Märklin/Motorola-Format
 +
                N: NMRA-DCC-Format
 +
 +
      acc_nr  : 1 .. 4096    (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
 +
 +
  3.2.1.3 Servicemode
 +
 +
  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 dienen die folgenden Befehle.
 +
 +
  SET GL SM <protocol> <dest-type> <dest-addr> [bitnr] <value>
 +
  SET GA SM <protocol> <dest-type> <dest-addr> [bitnr] <value>
 +
 +
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
 
    
 
    
  Kommunikationsports: Client -> Server: Kommandoport
+
  Kommunikationsports: Client -> Server: Kommandoport
                      Server -> Client: Kommandoport
+
                        Server -> Client: entfällt
 
+
 
  Bedeutung der Argumente: siehe 3.2.1.1
+
  Bedeutung der Argumente:
 
+
    
   Der Server sendet an den Client alle verfügbare Info zu dem mit
+
      protocol : NMRA, ...
  <protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder.
+
      dest-type: Art der zu ändernden Dekoderspeicherzelle (destination type)
  Diese Info muß wie folgt formatiert werden:
+
 
+
  INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
+
 
+
  (vgl. 3.2.1.1)
+
 
+
  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. 3.1).
+
 
   
 
   
   3.2.2.2 Gerätegruppe GA
+
                CV   : NMRA-DCC configuration variable
 
+
                CVBIT: ein Bit einer NMRA-DCC configuration variable
  GET GA <protocol> <acc_nr> <acc_port>
+
                REG  : Ein Register eines NMRA-DCC-Dekoders
 
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
+
 
+
  Kommunikationsports: Client -> Server: Kommandoport
+
                      Server -> Client: Kommandoport
+
 
+
  Bedeutung der Argumente: siehe 3.2.1.2
+
 
+
  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>
+
      dest-addr: Adresse der Speicherzelle, die geändert werden soll
 +
      bitnr    : nur in Verbindung mit CVBIT sinnvoll
 +
      value    : neuer Wert der Speicherzelle
 +
    
 
   
 
   
  (vgl. 3.2.1.2, ersetze <state> durch <action>)
+
  3.2.1.4 sonstiges
 +
 
 +
  Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.
 +
  für Drehscheiben) spezifizieren. 
 
   
 
   
  Sollte keine Information vorhanden sein, oder der Server den Befehl
+
  3.2.2 Befehlsparameter des Befehls GET
  GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den
+
  Client senden (vgl. 3.1).
+
 
+
  3.2.2.3 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)
+
  3.2.2.1 Gerätegruppe GL
                  I8255    (i8255 Karte)
+
                  M6051    (Märklin s88-Bus via Interface 6051)
+
 
+
    portnr    : konkreter Eingang eines Rückmeldemoduls
+
 
+
  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>
+
  GET GL <protocol> <addr>
 
+
  Wobei state entweder '0' oder '1' sein darf.
+
 
   
 
   
  Sollte keine Information vorhanden sein, oder der Server den Befehl
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
   GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den  
+
 
   Client senden (vgl. 3.1).               
+
  Kommunikationsports: Client -> Server: Kommandoport
 
+
                        Server -> Client: Kommandoport
  3.2.2.4 Servicemode
+
 
+
  Bedeutung der Argumente: siehe 3.2.1.1
  Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations-
+
  variablen diverser Dekoder spezifizieren.
+
  Der Server sendet an den Client alle verfügbare Info zu dem mit
 
+
  <protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder.
  3.2.2.5 sonstiges
+
  Diese Info muß wie folgt formatiert werden:
 
+
  Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.
+
  INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
  für Drehscheiben) spezifizieren.
+
 
+
  (vgl. 3.2.1.1)
  3.2.3 Befehlsparameter des Befehls WAIT
+
 
+
  Sollte keine Information vorhanden sein, oder der Server den Befehl
  3.2.3.1 Gerätegruppe FB
+
  GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den
 
+
  Client senden (vgl. 3.1).
  WAIT FB <module-type> <portnr> <value> <timeout>
+
    
 
+
  3.2.2.2 Gerätegruppe GA
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'   
+
 
+
  GET GA <protocol> <acc_nr> <acc_port>
  Kommunikationsports: Client -> Server: Kommandoport
+
                      Server -> Client: Kommandoport
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
 
+
  Wartet, bis portnr den Wert value (0,1) annimmt. Wartet
+
  Kommunikationsports: Client -> Server: Kommandoport
  aber höchstens timeout Sekunden. Sendet falls der timeout nicht
+
                        Server -> Client: Kommandoport
  eingetreten ist, die gleiche Information wie GET FB.
+
  Sollte der timeout überschritten werden, wird 'INFO -3' an den  
+
  Bedeutung der Argumente: siehe 3.2.1.2
  Client gesendet.
+
 
+
  Der Server sendet an den Client alle verfügbare Info zu dem mit
  Sollte keine Information vorhanden sein, oder der Server den Befehl
+
  <protocol> und <acc_nr> spezifizierten Schaltdekoder.
  WAIT nicht unterstützen, dann muß der Server 'INFO <error code>' an den  
+
  Diese Info muß wie folgt formatiert werden:
  Client senden (vgl. 3.1).
+
 
 
+
  INFO GA <protocol> <acc_nr> <acc_port> <state>
  3.2.6 Befehlsparameter des Befehls INIT
+
 
 
+
  (vgl. 3.2.1.2, ersetze <state> durch <action>)
  INIT FB <module-type>
+
 
 
+
  Sollte keine Information vorhanden sein, oder der Server den Befehl
  Kommunikationsports: Client -> Server: Kommandoport
+
  GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den  
                      Server -> Client: entfällt
+
  Client senden (vgl. 3.1).
 
+
  Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht
+
  3.2.2.3 Gerätegruppe FB
  an den Client.
+
 
+
  GET FB <module-type> <portnr>
 
+
  4. Datenformate der Serverinformationen
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
 
+
  4.1 Rückmeldepollport
+
  Kommunikationsports: Client -> Server: Kommandoport
 
+
                        Server -> Client: Kommandoport
  Die Datenübertragung auf dem Rückmeldepollport unterliegt den gleichen
+
  Beschränkungen wie die des Kommandoports (plain text, '\n' als Endezeichen).
+
  Bedeutung der Argumente:
  Die Daten müssen mit folgendem Format übertragen werden:   
+
    
 
+
      module-type: S88      (Märklin s88-Bus am Parallelport des PC)
  INFO FB <module-type> <portnr> <state>
+
                  I8255    (i8255 Karte)
  (vgl. 3.2.2.3)
+
                  M6051    (Märklin s88-Bus via Interface 6051)
 
+
  4.2 Informationsport   
+
      portnr    : konkreter Eingang eines Rückmeldemoduls
 
+
  Die Datenübertragung auf dem Informationsport unterliegt den gleichen
+
  Der Server sendet auf dem Rückmeldekanal an den Client den aktuellen
  Beschränkungen wie die des Kommandoports (plain text, '\n' als Endezeichen).
+
  Status des mit <module-type> und <portnr> spezifizierten
  Die Daten müssen mit folgenden Formaten - abhängig von der Gerätegruppe -
+
  Rückmeldemoduleingangs. Diese Info muß wie folgt formatiert werden:
  übertragen werden:
+
 
 
+
  INFO FB <module-type> <portnr> <state>
  INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
+
  (vgl. 3.2.2.1)
+
  Wobei state entweder '0' oder '1' sein darf.
 
+
 
  INFO GA <protocol> <acc_nr> <acc_port> <state>  
+
  Sollte keine Information vorhanden sein, oder der Server den Befehl
  (vgl. 3.2.2.2)
+
  GET nicht unterstützen, dann muß der Server 'INFO <error code>' an den
 
+
  Client senden (vgl. 3.1).               
 
+
  5. Ausblicke, zukünftige Erweiterungen  
+
  3.2.2.4 Servicemode
 
+
  Ich habe bewußt einige Ideen, die andiskutiert wurden, nicht mit  
+
  Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations-
  aufgenommen. Ich bin der Meinung, daß wir einen vorläufigen
+
  variablen diverser Dekoder spezifizieren.
  Schlußstrich ziehen und die ganzen netten Dinge implementieren  
+
  sollten. Damit die anderen guten Ideen nicht verloren gehen, werde
+
  3.2.2.5 sonstiges
  ich sie in diesem Abschnitt aufführen.
+
 
+
  Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.
  5.1 Zentrale Konfiguration
+
  für Drehscheiben) spezifizieren.
 
+
  Von Kurt Haders stammt der Vorschlag einer zentralen Konfigurationsdatei.
+
  3.2.3 Befehlsparameter des Befehls WAIT
  Hauptanliegen ist es, mehr "Wissen" von den Clients in den Server zu
+
  verlagern. Ein Format, wie eine solche Konfigurationsdatei aussehen soll,
+
  3.2.3.1 Gerätegruppe FB
  liegt noch nicht vor. Das Übertragungsprotokoll ist duch den  
+
  Protokollbezeichner 'PS' (protocol by server) bereits darauf vorbereitet.
+
  WAIT FB <module-type> <portnr> <value> <timeout>
 
+
  5.2 Erweiterung der Befehle auf andere Gerätegruppen
+
  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'   
 
+
  Von Matthias Trute kommt der Vorschlag den Befehl WAIT auch für die
+
  Kommunikationsports: Client -> Server: Kommandoport
  Gerätegruppen GL und GA zuzulassen. Allerdings kann es hierbei zu
+
                        Server -> Client: Kommandoport
  Inkonsistenzen kommen. Weiterhin könnte man man bei WAIT Wildcards
+
  ('*') zulassen.
+
  Wartet, bis portnr den Wert value (0,1) annimmt. Wartet
 
+
  aber höchstens timeout Sekunden. Sendet falls der timeout nicht
  5.3 Quittierung von Befehlen
+
  eingetreten ist, die gleiche Information wie GET FB.
 
+
  Sollte der timeout überschritten werden, wird 'INFO -3' an den  
  Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über
+
  Client gesendet.
  den Rückkanal des Kommandoports realisiert werden.
+
 +
  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).
 +
 +
  3.2.6 Befehlsparameter des Befehls INIT
 +
 +
  INIT FB <module-type>
 +
 +
  Kommunikationsports: Client -> Server: Kommandoport
 +
                        Server -> Client: entfällt
 +
 +
  Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht
 +
  an den Client.
 +
 +
 +
  4. Datenformate der Serverinformationen
 +
 +
  4.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. 3.2.2.3)
 +
 +
  4.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. 3.2.2.1)
 +
 +
  INFO GA <protocol> <acc_nr> <acc_port> <state>  
 +
  (vgl. 3.2.2.2)
 +
 +
 +
  5. 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.
 +
 +
  5.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.
 +
 +
  5.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.
 +
 +
  5.3 Quittierung von Befehlen
 +
 +
  Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über
 +
  den Rückkanal des Kommandoports realisiert werden.
 +
 +
  5.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).
  
  5.4 Konfiguration des Servers auslesen
 
  
  Von Edbert van Eimeren kommt der Vorschlag, daß Clients die Konfiguration
+
[[Kategorie:SRCP]]
  des Servers abfragen können sollten (neuer Befehl: CONFGET).
+

Aktuelle Version vom 17. Januar 2006, 10:57 Uhr

                    SRCP - Simple Railroad Command Protocol
                            Version 0.5.0

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

  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.

  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 sollte 12345 sein. Der Rückmeldepollport und der
  Informationsport sollten die beiden unmittelbar folgenden 
  Portnummern sein. Standardmässig ergeben sich somit folgende
  Portnummern:

     Kommandoport     : 12345
     Rückmeldepollport: 12346
     Informationsport : 12347

  Nimmt ein Client zum Kommandoport Kontakt auf und wird vom Server
  akzeptiert, 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. 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
  STARTVOLTAGE: Der Server schaltet den Digitalstrom am Booster ein
  STOPVOLTAGE : Der Server schaltet den Digitalstrom am Booster aus
  RESET       : Der Server re-initialisiert sich


  3. Kommandos zur Digitalsteuerung

  3.1 Befehle und Gerätegruppen

  SRCP definiert 4 generelle Befehle:

     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.

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

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

     GL: Lok- und Funktionsdekoder (generic loco)
     GA: Schaltdekoder (generic accessory)
     FB: Rückmeldeeinheit (feedback)

  Anwendbarkeit der Befehle auf Gerätegruppen:

        |  SET  GET  WAIT  INIT
     ---+----------------------
        |
     GL |   x    x    -     -  
        |
     GA |   x    x    -     -
        |
     FB |   -    x    x     x
        |

  Bei einigen Befehlen (GET, 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.

  3.2.1 Befehlsparameter des Befehls SET

  3.2.1.1 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)
                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     : 0 .. 9999
     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: 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

  3.2.1.2 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, N

               M: Märklin/Motorola-Format
               N: NMRA-DCC-Format

     acc_nr  : 1 .. 4096    (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

  3.2.1.3 Servicemode

  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 dienen die folgenden Befehle.

  SET GL SM <protocol> <dest-type> <dest-addr> [bitnr] <value>
  SET GA SM <protocol> <dest-type> <dest-addr> [bitnr] <value>

  Länge eines Kommandos (variabel): Befehlsendezeichen ist '\n'
 
  Kommunikationsports: Client -> Server: Kommandoport
                       Server -> Client: entfällt
 
  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
     bitnr    : nur in Verbindung mit CVBIT sinnvoll
     value    : neuer Wert der Speicherzelle
 

  3.2.1.4 sonstiges
 
  Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.
  für Drehscheiben) spezifizieren.  

  3.2.2 Befehlsparameter des Befehls GET

  3.2.2.1 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 3.2.1.1

  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. 3.2.1.1)

  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. 3.1).
 
  3.2.2.2 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 3.2.1.2

  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. 3.2.1.2, 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. 3.1). 

  3.2.2.3 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 

  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. 
 
  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. 3.1).              

  3.2.2.4 Servicemode

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

  3.2.2.5 sonstiges

  Hier könnte man spezielle Kommandos für Spezialdekoder (z.B.
  für Drehscheiben) spezifizieren.

  3.2.3 Befehlsparameter des Befehls WAIT

  3.2.3.1 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).

  3.2.6 Befehlsparameter des Befehls INIT

  INIT FB <module-type>

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

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


  4. Datenformate der Serverinformationen

  4.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. 3.2.2.3)

  4.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. 3.2.2.1)

  INFO GA <protocol> <acc_nr> <acc_port> <state> 
  (vgl. 3.2.2.2)


  5. 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.

  5.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.

  5.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.

  5.3 Quittierung von Befehlen

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

  5.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).