Quelltext der Seite SRCP 0.7.0 (plain text)

 SRCP - Simple Railroad Command Protocol 0.7.0
   Torsten Vogt, Martin Ostermann, Kurt Haders, Olaf
   Schlachter, Matthias Trute, Tobias Schlottke, Edbert van
   Eimeren, Stefan Bormann, Michael Reukauff
   Mai 2000
   ____________________________________________________________
 
   Table of Contents
 
 
   1. Einleitung
 
      1.1 Konventionen
      1.2 Übertragungskanäle
 
   2. Allgemeine Kommandos zur Serversteuerung
 
   3. Kommandos zur Digitalsteuerung
 
      3.1 Befehle und Gerätegruppen
      3.2 Weitere Befehlsparameter
         3.2.1 Befehlsparameter des Befehls SET
            3.2.1.1 Gerätegruppe GL
               3.2.1.1.1 Hinweise für Entwickler von SRCP-konformen Servern
            3.2.1.2 Gerätegruppe GA
            3.2.1.3 TIME
            3.2.1.4 POWER
         3.2.2 Befehlsparameter des Befehls GET
            3.2.2.1 Gerätegruppe GL
            3.2.2.2 Gerätegruppe GA
            3.2.2.3 Gerätegruppe FB
            3.2.2.4 Servicemode
            3.2.2.5 Zeit
            3.2.2.6 Power
         3.2.3 Befehlsparameter des Befehls WAIT
            3.2.3.1 Gerätegruppe FB
            3.2.3.2 TIME
         3.2.4 Befehlsparameter des Befehls INIT
            3.2.4.1 Feeback Module
            3.2.4.2 TIME
         3.2.5 Befehlsparameter des Befehls TERM
 
   4. Kommandos zur Dekoderprogrammierung
 
      4.1 Dekodereinstellungen ändern
      4.2 Dekodereinstellungen verifizieren
      4.3 Dekodereinstellungen auslesen
 
   5. Datenformate der Serverinformationen
 
      5.1 Rückmeldepollport
      5.2 Informationsport
 
   6. Ausblicke, zukünftige Erweiterungen
 
      6.1 Zentrale Konfiguration
      6.2 Erweiterung der Befehle auf andere Gerätegruppen
      6.3 Quittierung von Befehlen
      6.4 Konfiguration des Servers auslesen
 
 
   ______________________________________________________________________
 
 
 
 
   1�1.�.  E�Ei�in�nl�le�ei�it�tu�un�ng�g
 
   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.�.1�1.�.  K�Ko�on�nv�ve�en�nt�ti�io�on�ne�en�n
 
   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�1.�.2�2.�.  Ü�Üb�be�er�rt�tr�ra�ag�gu�un�ng�gs�sk�ka�an�nä�äl�le�e
 
   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�2.�.  A�Al�ll�lg�ge�em�me�ei�in�ne�e K�Ko�om�mm�ma�an�nd�do�os�s z�zu�ur�r S�Se�er�rv�ve�er�rs�st�te�eu�ue�er�ru�un�ng�g
 
   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�3.�.  K�Ko�om�mm�ma�an�nd�do�os�s z�zu�ur�r D�Di�ig�gi�it�ta�al�ls�st�te�eu�ue�er�ru�un�ng�g
 
   3�3.�.1�1.�.  B�Be�ef�fe�eh�hl�le�e u�un�nd�d G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�en�n
 
   SRCP definiert 5 generelle Befehle, die über den Kommandoport
   abgewickelt werden.
 
 
      S�SE�ET�T
         Setzt einen Wert vom Client über den Server zum Gerät.
 
      G�GE�ET�T
         Ermittelt den aktuellen Zustand eines Gerätes.
 
      W�WA�AI�IT�T
         Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
 
 
      I�IN�NI�IT�T
         Falls Geräte explizit initialisiert werden müssen.
 
      T�TE�ER�RM�M
         Falls die mit INIT getroffenen Einstellungen wieder entfernt
         werden sollen.
 
      W�WR�RI�IT�TE�E
         Setzt einen Wert vom Client und liefert eine Antwort zurück.
 
      V�VE�ER�RI�IF�FY�Y
         Überprüft, ob ein Wert einen bestimmten Wert hat.
 
      R�RE�EA�AD�D
         Liest einen Wert aus, ist das 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 vorgesehen.
 
 
      G�GL�L Lok- und Funktionsdekoder (generic loco)
 
      G�GA�A Schaltdekoder (generic accessory)
 
      F�FB�B Rückmeldeeinheit (feedback)
 
      T�TI�IM�ME�E
         Zeitnormal
 
      P�PO�OW�WE�ER�R
         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�3.�.2�2.�.  W�We�ei�it�te�er�re�e B�Be�ef�fe�eh�hl�ls�sp�pa�ar�ra�am�me�et�te�er�r
 
   Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät
   und welche Eigenschaften beeinflußt oder abgefragt werden sollen.
 
   3�3.�.2�2.�.1�1.�.  B�Be�ef�fe�eh�hl�ls�sp�pa�ar�ra�am�me�et�te�er�r d�de�es�s B�Be�ef�fe�eh�hl�ls�s S�SE�ET�T
 
   3�3.�.2�2.�.1�1.�.1�1.�.  G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�e G�GL�L
 
 
   ______________________________________________________________________
     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:
 
      p�pr�ro�ot�to�oc�co�ol�l
         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
 
      a�ad�dd�dr�r
         0 .. 9999
 
      d�di�ir�re�ec�ct�ti�io�on�n
         0 (= rückwärts), 1 (= vorwärts), 2 (= Nothalt)
 
      V�V  0 .. V_max ((virtuelle) Geschwindigkeit)
 
      V�V_�_m�ma�ax�x
         0 .. 999   (maximale (virtuelle) Geschwindigkeit) V_max=0 ==>
         virtuelle Fahrstufe = reale Fahrstufe
 
      f�fu�un�nc�c
         0 (= aus), 1 (= an)
 
      n�nr�ro�o_�_f�f
         0 .. x  (Anzahl der Zusatzfunktionen (number of functions))
 
      f�f1�1 .�..�. f�fn�n
         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)
 
   3�3.�.2�2.�.1�1.�.1�1.�.1�1.�.  H�Hi�in�nw�we�ei�is�se�e f�fü�ür�r E�En�nt�tw�wi�ic�ck�kl�le�er�r v�vo�on�n S�SR�RC�CP�P-�-k�ko�on�nf�fo�or�rm�me�en�n S�Se�er�rv�ve�er�rn�n
 
   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�3.�.2�2.�.1�1.�.2�2.�.  G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�e G�GA�A
 
 
   ______________________________________________________________________
     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
 
 
      p�pr�ro�ot�to�oc�co�ol�l
 
      ·  M: Märklin/Motorola-Format
 
      ·  N: NMRA-DCC-Format
 
      a�ac�cc�c_�_n�nr�r
         1 .. 4096    (Nummer der Weiche/des Signals)
 
      a�ac�cc�c_�_p�po�or�rt�t
         0, 1         (Ausgang des Dekoders)
 
      a�ac�ct�ti�io�on�n
         0, 1         (0 = deaktiviert, 1 = aktiviert)
 
      d�de�el�la�ay�y
         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�3.�.2�2.�.1�1.�.3�3.�.  T�TI�IM�ME�E
 
 
   ______________________________________________________________________
 
         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.
 
 
      T�Ta�ag�g
         sequentielle Folge von Tageszahlen (julianisch)
 
      S�St�tu�un�nd�de�e
         0..23, besteht aus 60 MINUTEN
 
      M�Mi�in�nu�ut�te�e
         0..59, besteht aus 60 SEKUNDEN
 
      S�Se�ek�ku�un�nd�de�e
         0..59
 
      F�FX�X,�, F�FY�Y
         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'')
 
   3�3.�.2�2.�.1�1.�.4�4.�.  P�PO�OW�WE�ER�R
 
 
 
   ______________________________________________________________________
 
         SET POWER <state> <freetext>
   ______________________________________________________________________
 
 
 
   Kommunikationsports:
 
   ·  Client -> Server: Kommandoport
 
   ·  Server -> Client: entfällt
 
   Bedeutung der Argumente
 
 
      S�St�ta�at�te�e
 
         O�ON�N Schaltet die Energieversorgung ein
 
         O�OF�FF�F
            Schaltet die Energieversorgung ab
 
      F�Fr�re�ee�et�te�ex�xt�t
         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.
 
   3�3.�.2�2.�.2�2.�.  B�Be�ef�fe�eh�hl�ls�sp�pa�ar�ra�am�me�et�te�er�r d�de�es�s B�Be�ef�fe�eh�hl�ls�s G�GE�ET�T
 
   3�3.�.2�2.�.2�2.�.1�1.�.  G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�e G�GL�L
 
 
   ______________________________________________________________________
     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'').
   3�3.�.2�2.�.2�2.�.2�2.�.  G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�e G�GA�A
 
 
   ______________________________________________________________________
     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'').
 
 
   3�3.�.2�2.�.2�2.�.3�3.�.  G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�e F�FB�B
 
 
   ______________________________________________________________________
     GET FB <module-type> <portnr>
   ______________________________________________________________________
 
 
 
   Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
 
 
   Kommunikationsports:
 
   ·  Client -> Server: Kommandoport
 
   ·  Server -> Client: Kommandoport
 
 
   Bedeutung der Argumente
 
 
      m�mo�od�du�ul�le�e-�-t�ty�yp�pe�e
 
      ·  S88       (Märklin s88-Bus am Parallelport des PC)
 
      ·  I8255     (i8255 Karte)
 
      ·  M6051     (Märklin s88-Bus via Interface 6051)
 
      p�po�or�rt�tn�nr�r
         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'').
 
   3�3.�.2�2.�.2�2.�.4�4.�.  S�Se�er�rv�vi�ic�ce�em�mo�od�de�e
 
   Hier könnte man spezielle Kommandos zum Auslesen von Konfigurations-
   variablen diverser Dekoder spezifizieren.
 
   3�3.�.2�2.�.2�2.�.5�5.�.  Z�Ze�ei�it�t
 
 
   ______________________________________________________________________
     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'').
 
 
   3�3.�.2�2.�.2�2.�.6�6.�.  P�Po�ow�we�er�r
 
 
   ______________________________________________________________________
     GET POWER
   ______________________________________________________________________
 
 
 
   Kommunikationsports:
 
   ·  Client -> Server: Kommandoport
 
   ·  Server -> Client: Kommandoport
 
   Ermittelt den aktuellen Zustand der Energieversorgung als INFO POWER
 
   3�3.�.2�2.�.3�3.�.  B�Be�ef�fe�eh�hl�ls�sp�pa�ar�ra�am�me�et�te�er�r d�de�es�s B�Be�ef�fe�eh�hl�ls�s W�WA�AI�IT�T
 
   3�3.�.2�2.�.3�3.�.1�1.�.  G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�e F�FB�B
 
 
   ______________________________________________________________________
     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�3.�.2�2.�.3�3.�.2�2.�.  T�TI�IM�ME�E
 
 
   ______________________________________________________________________
     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.
 
   3�3.�.2�2.�.4�4.�.  B�Be�ef�fe�eh�hl�ls�sp�pa�ar�ra�am�me�et�te�er�r d�de�es�s B�Be�ef�fe�eh�hl�ls�s I�IN�NI�IT�T
 
   3�3.�.2�2.�.4�4.�.1�1.�.  F�Fe�ee�eb�ba�ac�ck�k M�Mo�od�du�ul�le�e
 
 
   ______________________________________________________________________
     INIT FB <module-type>
   ______________________________________________________________________
 
 
 
   Kommunikationsports:
 
   ·  Client -> Server: Kommandoport
 
   ·  Server -> Client: entfällt
 
 
   Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht
   an den Client.
 
 
   3�3.�.2�2.�.4�4.�.2�2.�.  T�TI�IM�ME�E
 
 
   ______________________________________________________________________
     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.
 
   3�3.�.2�2.�.5�5.�.  B�Be�ef�fe�eh�hl�ls�sp�pa�ar�ra�am�me�et�te�er�r d�de�es�s B�Be�ef�fe�eh�hl�ls�s T�TE�ER�RM�M
 
   Keine bislang
 
   4�4.�.  K�Ko�om�mm�ma�an�nd�do�os�s z�zu�ur�r D�De�ek�ko�od�de�er�rp�pr�ro�og�gr�ra�am�mm�mi�ie�er�ru�un�ng�g
 
   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�4.�.1�1.�.  D�De�ek�ko�od�de�er�re�ei�in�ns�st�te�el�ll�lu�un�ng�ge�en�n ä�än�nd�de�er�rn�n
 
 
   ______________________________________________________________________
     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
 
      p�pr�ro�ot�to�oc�co�ol�l
         NMRA, ...
 
      d�de�es�st�t-�-t�ty�yp�pe�e
         Art der zu ändernden Dekoderspeicherzelle (destination type)
 
         C�CV�V NMRA-DCC configuration variable
 
         C�CV�VB�BI�IT�T
            ein Bit einer NMRA-DCC configuration variable
 
         R�RE�EG�G
            Ein Register eines NMRA-DCC-Dekoders
 
      d�de�es�st�t-�-a�ad�dd�dr�r
         Adresse der Speicherzelle, die geändert werden soll
 
      v�va�al�lu�ue�e
         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�4.�.2�2.�.  D�De�ek�ko�od�de�er�re�ei�in�ns�st�te�el�ll�lu�un�ng�ge�en�n v�ve�er�ri�if�fi�iz�zi�ie�er�re�en�n
 
 
   ______________________________________________________________________
     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
 
      p�pr�ro�ot�to�oc�co�ol�l
         NMRA, ...
 
      d�de�es�st�t-�-t�ty�yp�pe�e
         Art der zu verifizierenden Dekoderspeicherzelle (destination
         type)
 
         C�CV�V NMRA-DCC configuration variable
 
         R�RE�EG�G
            Ein Register eines NMRA-DCC-Dekoders
 
      d�de�es�st�t-�-a�ad�dd�dr�r
         Adresse der Speicherzelle, die verifiziert werden soll
 
      v�va�al�lu�ue�e
         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�4.�.3�3.�.  D�De�ek�ko�od�de�er�re�ei�in�ns�st�te�el�ll�lu�un�ng�ge�en�n a�au�us�sl�le�es�se�en�n
 
   Reserviert für zukünftige Erweiterungen.
 
   5�5.�.  D�Da�at�te�en�nf�fo�or�rm�ma�at�te�e d�de�er�r S�Se�er�rv�ve�er�ri�in�nf�fo�or�rm�ma�at�ti�io�on�ne�en�n
 
   5�5.�.1�1.�.  R�Rü�üc�ck�km�me�el�ld�de�ep�po�ol�ll�lp�po�or�rt�t
 
   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�5.�.2�2.�.  I�In�nf�fo�or�rm�ma�at�ti�io�on�ns�sp�po�or�rt�t
 
   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�6.�.  A�Au�us�sb�bl�li�ic�ck�ke�e,�, z�zu�uk�kü�ün�nf�ft�ti�ig�ge�e E�Er�rw�we�ei�it�te�er�ru�un�ng�ge�en�n
 
   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�6.�.1�1.�.  Z�Ze�en�nt�tr�ra�al�le�e K�Ko�on�nf�fi�ig�gu�ur�ra�at�ti�io�on�n
 
   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�6.�.2�2.�.  E�Er�rw�we�ei�it�te�er�ru�un�ng�g d�de�er�r B�Be�ef�fe�eh�hl�le�e a�au�uf�f a�an�nd�de�er�re�e G�Ge�er�rä�ät�te�eg�gr�ru�up�pp�pe�en�n
 
   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�6.�.3�3.�.  Q�Qu�ui�it�tt�ti�ie�er�ru�un�ng�g v�vo�on�n B�Be�ef�fe�eh�hl�le�en�n
 
   Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über
   den Rückkanal des Kommandoports realisiert werden.
 
 
   6�6.�.4�4.�.  K�Ko�on�nf�fi�ig�gu�ur�ra�at�ti�io�on�n d�de�es�s S�Se�er�rv�ve�er�rs�s a�au�us�sl�le�es�se�en�n
 
   Von Edbert van Eimeren kommt der Vorschlag, daß Clients die
   Konfiguration des Servers abfragen können sollten (neuer Befehl:
   CONFGET).


[[Kategorie:SRCP]]