Benutzer:Edbert van Eimeren/Test2: Unterschied zwischen den Versionen

aus DerMoba, der Wissensdatenbank für Modellbahner
Wechseln zu: Navigation, Suche
(Neu erstellt für wechselnde Tests. Hier CRCF 0.1)
 
(CRCF 0.2)
Zeile 1: Zeile 1:
Erster Entwurf zur Diskussion
+
Zweiter Entwurf zur Diskussion - 11.7.2000
 +
 
 +
''' von Edbert van Eimeren, Martin Ostermann, Matthias Trute'''
  
''' von Edbert van Eimeren '''
 
  
  
Zeile 9: Zeile 10:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
 
Die CRCF beschreiben einen Reihe von Dateien zur Konfiguration von Serverprozessen zur Steuerung von digitalen Modelleisenbahnen. Clientprozesse können auf diese Informationen über einen entsprechenden Auskunftsbefehl zugreifen.
 
Die CRCF beschreiben einen Reihe von Dateien zur Konfiguration von Serverprozessen zur Steuerung von digitalen Modelleisenbahnen. Clientprozesse können auf diese Informationen über einen entsprechenden Auskunftsbefehl zugreifen.
  
Zeile 16: Zeile 17:
 
Ziel ist es eine klare, auch vom Menschen lesbare Basis für die Fähigkeiten einer konkreten Serverimplementierung einerseits und eine Beschreibung der verwendeten Dekoder mit ihren spezifischen Eigenschaften andererseits zu schaffen.
 
Ziel ist es eine klare, auch vom Menschen lesbare Basis für die Fähigkeiten einer konkreten Serverimplementierung einerseits und eine Beschreibung der verwendeten Dekoder mit ihren spezifischen Eigenschaften andererseits zu schaffen.
  
Diese Fassung basiert auf [[SRCP - Simple Railroad Command Protocol 0.7.0 | SRCP Version 0.7.0]].
+
Diese Fassung basiert auf [[SRCP - Simple Railroad Command Protocol 0.7.1 | SRCP Version 0.7.1]].
|   
+
| 
|  bgcolor="#666666" |    
+
 
|}
 
|}
 +
  
  
Zeile 27: Zeile 28:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
 
Alle Informationen werden einzeilig mit variabler Länge gespeichert. Eine Zeile wird mit dem Zeichen '\n' (line feed, LF, #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return, CR, #13) wird akzeptiert. Jede Informationszeile besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.
 
Alle Informationen werden einzeilig mit variabler Länge gespeichert. Eine Zeile wird mit dem Zeichen '\n' (line feed, LF, #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return, CR, #13) wird akzeptiert. Jede Informationszeile besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.
  
Zeile 36: Zeile 37:
 
Einzelne Bereiche werden durch Überschriften getrennt. Diese beginnen (Zeilenanfang) mit '= ' und enden mit ' ='. Weiterer Text in der Überschriftzeile ist Kommentar und wird ignoriert.
 
Einzelne Bereiche werden durch Überschriften getrennt. Diese beginnen (Zeilenanfang) mit '= ' und enden mit ' ='. Weiterer Text in der Überschriftzeile ist Kommentar und wird ignoriert.
  
Alle Informationszeilen beginnen mit einer Kennung aus vier Buchstaben, die die Art der Information kennzeichnet. Die weiteren Angaben sind je nach Art der Information unterschiedlich. Informationen über Protokolle enthalten eine weitere Angabe zur genauen Identifizierung (Protokoll/Modultype). Informationen über Dekoder und Rückmelder enthalten zwei weitere Angaben zur genauen Identifizierung (Protokoll/Modultype + Adresse/Portnummer). Für jede vom Server unterstützte Funktion / Eigenschaft gibt es eine Informationszeile. Für jeden dem Server bekannten Dekoder / Rückmelder gibt es eine Informationszeile.
+
Alle Informationszeilen beginnen mit einer Kennung aus vier Buchstaben, die die Art der Information kennzeichnet. Die weiteren Angaben sind je nach Art der Information unterschiedlich. Informationen über Protokolle enthalten eine weitere Angabe zur genauen Identifizierung (Protokoll/Modultyp). Informationen über Dekoder und Rückmelder enthalten zwei weitere Angaben zur genauen Identifizierung (Protokoll/Modultyp + Adresse/Portnummer). Für jede vom Server unterstützte Funktion / Eigenschaft gibt es eine Informationszeile. Für jeden dem Server bekannten Dekoder / Rückmelder gibt es eine Informationszeile.
  
 
Informationszeilen, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert. Eine (summarische) Fehlermeldung sollte in diesem Fall vom Server beim Start ausgegeben werden. In Protokoll- oder Trace-Dateien kann ggfs. jeder Fehler einzeln aufgeführt werden.
 
Informationszeilen, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert. Eine (summarische) Fehlermeldung sollte in diesem Fall vom Server beim Start ausgegeben werden. In Protokoll- oder Trace-Dateien kann ggfs. jeder Fehler einzeln aufgeführt werden.
Zeile 43: Zeile 44:
  
 
An einigen Stellen sind Werte reserviert, die im SRCP noch nicht festgelegt sind, da es zur Zeit noch keine Server gibt, die das unterstützen. Diese Werte sind als Platzhalter zu betrachten, sie können sich noch ändern. Solche reservierten Werte sind mit ''kursiver Schrift'' markiert.  
 
An einigen Stellen sind Werte reserviert, die im SRCP noch nicht festgelegt sind, da es zur Zeit noch keine Server gibt, die das unterstützen. Diese Werte sind als Platzhalter zu betrachten, sie können sich noch ändern. Solche reservierten Werte sind mit ''kursiver Schrift'' markiert.  
|   
+
| 
|  bgcolor="#666666" |    
+
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" bgcolor="#DDDDDD" |  
Änderungen gegenüber der vorherigen Version werden mit einem farbigen Strich am rechten Rand markiert. Dabei bedeutet <font color="#FF0000"> '''rot'''</font> Neues oder wesentliche (inhaltliche) Änderungen, <font color="#00FF00">'''grün'''</font> kleinere (textliche) Änderungen, und <font color="#0000FF">'''blau'''</font> Weglassungen. Unveränderte Abschnitte haben eine <font color="#666666">'''graue'''</font> Markierung. Korrekturen von Tipfehlern werden nicht markiert. <br />
+
Änderungen gegenüber der vorherigen Version werden mit einem farbigen Strich am rechten Rand markiert. Dabei bedeutet <font color="#CC0000">'''rot''' </font> Neues, <font color="#00CC00">'''grün'''</font> wesentliche (inhaltliche) Änderungen, und <font color="#0000CC">'''blau'''</font> Weglassungen. Alle geänderten Abschnitte sind grau hinterlegt. Dies gilt auch für Abschnitte mit textlichen Korrekturen, die keine extra Randmarkierung haben. Korrekturen von Tipfehlern werden nicht markiert.
Da diese Version komplett neu ist, sind alle Abschnitte grau markiert. Die rote Markierung dieses Abschnittes, ebenso wie die grüne Markierung des Abschnitts [[#8 Änderungsprotokoll]] dient ledigich als Beispiel.
+
|  bgcolor="#00CC00" |&nbsp;
|  &nbsp;
+
|  bgcolor="#FF0000" | &nbsp;  
+
 
|}
 
|}
  
Zeile 63: Zeile 61:
 
|  colspan="3" |  
 
|  colspan="3" |  
 
Hier werden die Eigenschaften beschrieben, die eine Serverimplementierung ausmachen, das heißt, welche Möglichkeiten ein Server seinen Clients zur Verfügung stellt.
 
Hier werden die Eigenschaften beschrieben, die eine Serverimplementierung ausmachen, das heißt, welche Möglichkeiten ein Server seinen Clients zur Verfügung stellt.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 73: Zeile 70:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | '''Überschrift: '= Version =' '''
+
|  colspan="3" bgcolor="#DDDDDD" | '''Überschrift: '= Version =' '''
  
Es gibt genau eine Zeile mit der Information über die Version des Servers und des verwendeten SRCP.
+
Es gibt genau eine Zeile mit den Informationen über die Version des Servers, des verwendeten SRCP und CRCF.
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
Format: '''VERS <name> <vers> SRCP <srcp> CRCF <crcf>'''
|  &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
|  colspan="2" nowrap="NOWRAP" | '''VERS <name> <vers> SRCP <srcp>'''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;
+
| '''<name> <br /> <vers> <br /> <srcp>'''
<name> ||  Name des Servers
+
colspan="2" | Name des Servers <br /> Version des Servers <br /> Version des verwendeten SRCP
&nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<crcf>'''
| <vers> ||  Version des Servers
+
colspan="2" bgcolor="#DDDDDD" | Version des verwendeten CRCF
|  &nbsp;
+
|  bgcolor="#CC0000" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
nowrap="NOWRAP" width="12%" | Hinweis:
|  <srcp> || Version des verwendeten SRCP
+
colspan="2" nowrap="NOWRAP" |  
|  &nbsp;
+
Die Versionsinformation sollte als erstes in einer Konfigurationsdatei stehen.
|  bgcolor="#666666" | &nbsp;
+
|&nbsp;
 
+
|- valign="Top"
+
| &nbsp;
+
nowrap="NOWRAP" | Hinweis:
+
nowrap="NOWRAP" | Die Versionsinformation sollte als erstes in einer Konfigurationsdatei stehen.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 117: Zeile 100:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
Welche Kanäle werden von einer Serverimplementierung zur Kommunikation mit Clients benutzt. Dies ist durch das SRCP weitgehend festgelegt.
+
Welche Kanäle werden von einer Serverimplementierung zur Kommunikation mit Clients benutzt. <br />
 +
Dies ist durch das SRCP weitgehend festgelegt.
  
'''Überschrift: '= Ports =' '''
+
'''Überschrift: '= Ports =''''
  
Für jeden Kanal gibt es eine Zeile des Formats:
+
Format: '''PORT <port> <source>'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;
+
| '''<port>'''
|  colspan="2" nowrap="NOWRAP" | '''PORT <port> <direction> '''
+
|  nowrap="NOWRAP" | COMMAND <br /><br /> FEEDBACK <br /><br /> INFO
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Werte für '''<port>''' sind:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  nowrap="NOWRAP" | COMMAND  
+
 
|  nowrap="NOWRAP" | Kommando Port <br />
 
|  nowrap="NOWRAP" | Kommando Port <br />
Befehle des Clients an den Server, direkte Antworten des Servers darauf.
+
Befehle des Clients an den Server, direkte Antworten des Servers darauf. <br />
|  &nbsp;
+
Rückmelde Port <br />
|  bgcolor="#666666" | &nbsp;
+
Statusänderungen von Rückmelde Modulen. <br />
 
+
Info Port (Broadcast Kanal) <br />
|- valign="Top"
+
Statusänderungen von Lok- und Schaltdekodern, Modellzeit.  
|  &nbsp;
+
|&nbsp;
|  FEEDBACK
+
Rückmelde Port <br /> Statusänderungen von Rückmelde Modulen.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  INFO
+
Info Port (Broadcast Kanal) <br /> Statusänderungen von Lok- und Schaltdekodern, Modellzeit.  
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Werte für '''<direction>''' sind:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  CLIENT ||  Unidirektional vom Client zum Server
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  SERVER ||  Unidirektional vom Server zum Client
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
nowrap="NOWRAP" | '''<source>'''
BOTH ||  Bidirektional
+
nowrap="NOWRAP" | CLIENT <br /> SERVER <br /> BOTH
&nbsp;
+
Unidirektional vom Client zum Server <br />
|  bgcolor="#666666" | &nbsp;  
+
Unidirektional vom Server zum Client <br />
 +
Bidirektional
 +
|&nbsp;
 
|}
 
|}
  
Zeile 189: Zeile 135:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
Welche Befehle werden von einer Server zu seiner Steuerung akzeptiert. Dies ist durch das SRCP weitgehend festgelegt.
+
Welche Befehle werden von einer Server zu seiner Steuerung akzeptiert. <br />
 +
Dies ist durch das SRCP weitgehend festgelegt.
  
'''Überschrift: '= Server Commands =' '''
+
'''Überschrift: '= Server Commands =''''
  
Für jeden Befehl gibt es eine Zeile des Formats:
+
Format: '''SCMD <command> '''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  nowrap="NOWRAP" | '''<command>'''
|  colspan="2" nowrap="NOWRAP" | '''SCMD <command> '''
+
nowrap="NOWRAP" | LOGOUT <br /> RESET <br /> SHUTDOWN
&nbsp;
+
|  Befehl zum Beenden der Verbindung zu einem Client. <br />
|  bgcolor="#666666" | &nbsp;  
+
Befehl zur Neu-Initialisieung des Servers. <br />
 +
Befehl zum Beenden des Servers.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| colspan="3" | Werte für '''<command>''' sind:
+
|&nbsp;
|  &nbsp;
+
|  nowrap="NOWRAP" | POWER <br /><br />VOLTAGE
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  LOGOUT ||  Befehl zum Beenden der Verbindung zu einem Client.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  RESET ||  Befehl zur Neu-Initialisieung des Servers.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  nowrap="NOWRAP" | SHUTDOWN
+
|  Befehl zum Beenden des Servers.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
&nbsp;  
+
|  nowrap="NOWRAP" | VOLTAGE
+
 
|  nowrap="NOWRAP" |  
 
|  nowrap="NOWRAP" |  
Ein-/Ausschalten des Digitalstroms über STARTVOLTAGE/STOPVOLTAGE <br />
+
Digitalstrom über SET POWER [ON/OFF] ein-/ausschalten <br />
 +
Aktueller Befehl in SRCP (ab Version 0.???) <br />
 +
Digitalstrom über STARTVOLTAGE/STOPVOLTAGE schalten <br />
 
Kompatibilität zu früheren Versionen des SRCP
 
Kompatibilität zu früheren Versionen des SRCP
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
nowrap="NOWRAP" | POWER
+
bgcolor="#DDDDDD" | TIME
nowrap="NOWRAP" |  
+
bgcolor="#DDDDDD" | Server unterstützt Modellzeit
Ein-/Ausschalten des Digitalstroms über SET POWER [ON/OFF] <br />
+
|  bgcolor="#CC0000" |&nbsp;
Aktueller Befehl in SRCP (ab Version 0.???)
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 253: Zeile 175:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" bgcolor="#DDDDDD" |
Welche Befehle werden von einer Server zu seiner Steuerung akzeptiert. Dies ist durch das SRCP weitgehend festgelegt.
+
Welche Befehle werden von einer Server zur Steuerung der Digitalanlage akzeptiert. <br />
 +
Dies ist durch das SRCP weitgehend festgelegt.
  
'''Überschrift: '= General Commands =' '''
+
'''Überschrift: '= General Commands =''''
  
Für jeden Befehl gibt es eine Zeile des Formats:
+
Format: '''GCMD <command> <group>'''
|  &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  nowrap="NOWRAP" | '''<command>'''
|  colspan="2" nowrap="NOWRAP" | '''GCMD <command> '''
+
SET <br /> GET <br /> WAIT <br /> INIT <br /> TERM
&nbsp;
+
nowrap="NOWRAP" |
bgcolor="#666666" | &nbsp;  
+
Befehl zum Setzen eines Wertes. <br />
 +
Befehl zum Ermitteln eines Wertes. <br />
 +
Befehl zum Warten bis ein bestimmter Zustand erreicht wird. <br />
 +
Befehl zum Initialisieren von Geräte(gruppen). <br />
 +
Befehl zum Aufheben von mit INIT getroffenen Einstellungen.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| colspan="3" | Werte für '''<command>''' sind:
+
|&nbsp;
&nbsp;  
+
|  nowrap="NOWRAP" | WRITE <br /> READ <br /> VERIFY <br /><br /> CONFGET
|  bgcolor="#666666" | &nbsp;
+
|  nowrap="NOWRAP" |  
 
+
Befehl zum Programmieren eines Wertes eines Dekoders. <br />
|- valign="Top"
+
Befehl zum Lesen eines Wertes eines Dekoders. <br />
|  &nbsp;
+
Befehl zum Überprüfen eines Wertes eines Dekoders. <br /><br />
|  SET ||  Befehl zum Setzen eines Wertes.
+
Befehl zum Ermitteln von Konfigurationsinformationen.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  GET ||  Befehl zum Ermitteln eines Wertes.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  WAIT
+
|  nowrap="NOWRAP" | Befehl zum Warten bis ein bestimmter Zustand erreicht wird.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  INIT ||  Befehl zum Initialisieren von Geräte(gruppen).
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  TERM
+
|  nowrap="NOWRAP" | Befehl zum Aufheben von mit INIT getroffenen Einstellungen.  
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  WRITE
+
|  nowrap="NOWRAP" | Befehl zum Programmieren eines Wertes eines Dekoders.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  READ ||  Befehl zum Lesen eines Wertes eines Dekoders.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<group>'''
|  nowrap="NOWRAP" | VERIFY
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | GL <br /> GA <br /> FB <br /> TIME <br /> POWER
|  nowrap="NOWRAP" | Befehl zum Überprüfen eines Wertes eines Dekoders.
+
bgcolor="#DDDDDD" nowrap="NOWRAP" |  
|  &nbsp;
+
Generic Loco (Lokdekoder) [SET, GET, WRITE, READ, VERIFY] <br />
|  bgcolor="#666666" | &nbsp;  
+
Generic Acessory (Schaltdekoder) [SET, GET, WRITE, READ, VERIFY] <br />
 +
Feedback (Rückmelder) [GET, WAIT, INIT] <br />
 +
Zeitnormal (Modellzeit) [SET, GET, WAIT, INIT] <br />
 +
Energieversorgung der Modellanlage [SET, GET]
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
nowrap="NOWRAP" | CONFGET
+
colspan="2" bgcolor="#DDDDDD" |
|  nowrap="NOWRAP" | Befehl zum Ermitteln von Konfigurationsinformationen.  
+
Beim Befehl CONFGET werden statt der Gerätegruppen die Konfigurationstypen als Argument verwendet. Siehe dazu den Abschnitt [[#5.1 Konfigurationstypen]].  
|  &nbsp;
+
|  bgcolor="#CC0000" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
 
|  colspan="3" |  
 
|  colspan="3" |  
Ein Befehl, der nicht eingetragen ist, wird nicht unterstützt. Lediglich der Befehl SET ist zwingend vorgeschrieben, alle anderen können implementiert werden. <br />
+
Eine Kombination Befehl - Argument, die nicht eingetragen ist, wird nicht unterstützt. Lediglich der Befehl SET ist zwingend vorgeschrieben, alle anderen können implementiert werden. <br />
Der Befehl GET wird meistens unterstützt, der Befehl WAIT falls Rückmelder oder Modellzeit unterstützt werden. Die Befehle WRITE, READ, VERIFY dienen dem Programmieren von Dekodern. Sie werden nur dann unterstützt, wenn ein Server diese Funktionalität bereitstellt.
+
Der Befehl GET wird meistens unterstützt, der Befehl WAIT falls Rückmelder oder Modellzeit unterstützt werden. Die Befehle WRITE, READ, VERIFY dienen dem Programmieren von Dekodern. Sie werden nur dann unterstützt, wenn ein Server diese Funktionalität bereitstellt. Der Befehl CONFGET wird natürlich nur dann unterstützt, wenn ein Server das CRCF für die zentrale Konfiguration benutzt.
|  &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 346: Zeile 235:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
Welche Protokolle für Lokdekoder werden von einem Server akzeptiert. Funktionsdekoder werden wie Lokdekoder behandelt. <br />
+
Welche Protokolle für Lokdekoder werden von einem Server akzeptiert. (Funktionsdekoder werden wie Lokdekoder behandelt.) <br />
 
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert.
 
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert.
  
'''Überschrift: '= Protocols Loco & Function =' '''
+
'''Überschrift: '= Protocols Loco & Function =''''
  
Für jedes unterstützte Protokoll gibt es eine Zeile des Formats:
+
Format: '''PRGL <prot> <addr_max> <step_max> <dir> <nro_f>'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  '''<prot>'''
|  colspan="2" nowrap="NOWRAP" | '''PRGL <prot> <addrmax> <speedmax> <dir> <n-func>'''
+
M. <br /> N.
&nbsp;
+
nowrap="NOWRAP" |
bgcolor="#666666" | &nbsp;  
+
Protokolle nach den Märklin/Motorola Standards. <br />
 +
Protokolle nach den NMRA-DCC Standards.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<prot>''' sind:
+
bgcolor="#DDDDDD" | &nbsp;
&nbsp;  
+
|  bgcolor="#DDDDDD" | PS
|  bgcolor="#666666" | &nbsp;  
+
|  bgcolor="#DDDDDD" nowrap="NOWRAP" | Protocol by Server: Der Server wählt ein geeignetes Protokoll aus.
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;  
+
|&nbsp;
M.  
+
''S.'' <br /> ''F.'' <br /> ''Z.''
nowrap="NOWRAP" | Protokolle nach den Märklin/Motorola Standards.
+
|   
|  &nbsp;
+
''Protokolle nach den Trix Selectrix Standards.'' <br />
|  bgcolor="#666666" | &nbsp;  
+
''Protokolle nach den Fleischmann FMZ Standards.'' <br />
 +
''Protokolle nach den ZIMO Standards.''
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;
+
|&nbsp;
|  N. ||  Protokolle nach den NMRA-DCC Standards.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''S.''
+
|  nowrap="NOWRAP" | ''Protokolle nach den Trix Selectrix Standards.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''F.''
+
|  nowrap="NOWRAP" | ''Protokolle nach den Fleischmann FMZ Standards.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''Z.'' ||  ''Protokolle nach den ZIMO Standards.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
&nbsp;  
+
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Punkt ist durch geeignete Buchstaben/Ziffern zu ersetzen. Siehe dazu die aktuelle Spezifikation des SRCP. <br />
+
Der Punkt ist durch geeignete Buchstaben/Ziffern zu ersetzen. Siehe dazu die aktuelle Spezifikation des SRCP. Die Werte für Selectrix, FMZ und ZIMO sind reserviert für zukünftige Entwicklungen (Intellibox, Twin-Box, ...).  
Die Werte für Selectrix, FMZ und ZIMO sind reserviert für zukünftige Entwicklungen (Intellibox, Twin-Box, ...).
+
|&nbsp;
 
+
PS (= Protocol by Server) ist hier nicht aufgeführt, da es kein reales Protokoll ist, sondern eine Anweisung an den Server, selbständig ein geeignetes Protokoll zu wählen.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert für '''<addrmax>''':
+
nowrap="NOWRAP" | '''<addr_max>'''
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Wert für <addrmax> gibt die höchste Adresse an, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind 80, 99, 256, 9999. Ein Adressbereich beginnt immer bei der Adresse 0.  
+
Höchste Adresse, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind 80, 99, 256, 9999. Ein Adressbereich beginnt immer bei der Adresse 0.  
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Wert für '''<speedmax>''':
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
nowrap="NOWRAP" | '''<step_max>'''
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Wert für <speedmax> gibt die höchste Fahrstufen an, die von diesem Protokoll unterstützt wird. Aktuelle Werte für die höchste Fahrstufe sind 14, 27, 28, 128. Ein Fahrstufenbereich beginnt immer bei der Fahrstufe 0.  
+
Höchste Fahrstufen, die von diesem Protokoll unterstützt wird. Aktuelle Werte für die höchste Fahrstufe sind 14, 27, 28, 30, 128. Ein Fahrstufenbereich beginnt immer bei der Fahrstufe 0.  
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<dir>''' sind:
+
|  '''<dir>'''
&nbsp;
+
abs <br /> rel
bgcolor="#666666" | &nbsp;  
+
Absolute Fahrtrichtungsangabe. <br /> Relative Fahrtrichtungsangabe.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  '''<nro_f>'''
|  abs ||  Absolute Fahrtrichtungsangabe.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  rel ||  Relative Fahrtrichtungsangabe.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Wert für '''<n-func>''':
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Wert für <n-func> gibt an wieviele Zusatzfunktionen von diesem Protokoll unterstützt werden. Aktuelle Dekoder untertützen 0, 2, 4, 8 Zusatzfunktionen. Es wird implizit davon ausgegeangen, dass eine Standardfunktion immer implementiert ist.
+
Zahl der Zusatzfunktionen, die von diesem Protokoll unterstützt werden. Aktuelle Dekoder untertützen 0, 2, 4, 8 Zusatzfunktionen. Es wird implizit davon ausgegeangen, dass eine Standardfunktion immer implementiert ist.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 470: Zeile 304:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
Welche Protokolle für Schaltdekoder werden von einem Server akzeptiert. <br />
+
Welche Protokolle für Schaltdekoder werden von einem Server akzeptiert. <br /> Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert.
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert.
+
  
'''Überschrift: '= Protocols Accessory =' '''
+
'''Überschrift: '= Protocols Accessory =''''
  
Für jedes unterstützte Protokoll gibt es eine Zeile des Formats:  
+
Format: '''PRGA <prot> <addr_max>'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  '''<prot>'''
|  colspan="2" nowrap="NOWRAP" | '''PRGA <prot> <addrmax>'''
+
M <br /> N
&nbsp;
+
nowrap="NOWRAP" |
bgcolor="#666666" | &nbsp;  
+
Protokoll nach den Märklin/Motorola Standards. <br />
 +
Protokoll nach den NMRA-DCC Standards.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| colspan="3" | Werte für '''<prot>''' sind:
+
|&nbsp;
&nbsp;
+
| ''S'' <br /> ''F'' <br /> ''Z''
|  bgcolor="#666666" | &nbsp;  
+
|   
 +
''Protokoll nach den Trix Selectrix Standards.''<br />
 +
''Protokoll nach den Fleischmann FMZ Standards.''<br />
 +
''Protokoll nach den ZIMO Standards.''
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;
+
|  nowrap="NOWRAP" | '''<addr_max>'''
|  N
+
|  nowrap="NOWRAP" | Protokoll nach den Märklin/Motorola Standards.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  M ||  Protokoll nach den NMRA-DCC Standards.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''S''
+
|  nowrap="NOWRAP" | ''Protokoll nach den Trix Selectrix Standards.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''F''
+
|  nowrap="NOWRAP" | ''Protokoll nach den Fleischmann FMZ Standards.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''Z'' ||  ''Protokoll nach den ZIMO Standards.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Wert für '''<addrmax>''':
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Wert für <addrmax> gibt die höchste Adresse an, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind ???, 4096. Ein Adressbereich beginnt bei der Adresse 1.
+
Höchste Adresse, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind ???, 4096. Ein Adressbereich beginnt bei der Adresse 1.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 543: Zeile 342:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
 
Welche Rückmelde Module und Anschlussarten werden von einem Server akzeptiert. <br />
 
Welche Rückmelde Module und Anschlussarten werden von einem Server akzeptiert. <br />
 
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Module oder Arten unterstützen. Weiter sind bereits Werte für noch nicht definierte Protokolle reserviert.
 
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Module oder Arten unterstützen. Weiter sind bereits Werte für noch nicht definierte Protokolle reserviert.
Zeile 549: Zeile 348:
 
'''Überschrift: '= Feedback Types =' '''
 
'''Überschrift: '= Feedback Types =' '''
  
Für jeden unterstützten Modultyp gibt es eine Zeile des Formats:
+
Format: '''PRFB <module-type> <port_max> <port_inc>'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  nowrap="NOWRAP" | '''<module-type>'''
|  colspan="2" nowrap="NOWRAP" | '''PRFB <module-type> <port-max> <port-inc>'''
+
S88 <br /> I8255 <br /> M6051
&nbsp;
+
Märklin s88-Bus am Parallelport des PC. <br /> i8255 Karte. <br /> Märklin s88-Bus via Interface 6051.
bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<module-type>''' sind:
+
|&nbsp;
&nbsp;
+
nowrap="NOWRAP" | ''LENZFB <br /> LOCOFB <br /> SELFB <br /> FMZFB <br /> ZIMOFB''
|  bgcolor="#666666" | &nbsp;
+
nowrap="NOWRAP" |  
 
+
''Rückmelde-Module aus dem Lenz System. <br />
|- valign="Top"
+
Rückmelde-Module aus dem Digitrax System (LocoNet). <br />
|  &nbsp;
+
Rückmelde-Module aus dem Trix Selectrix System. <br />
|  S88 ||  Märklin s88-Bus am Parallelport des PC.
+
Rückmelde-Module aus dem Fleischmann FMZ System. <br />
|  &nbsp;
+
Rückmelde-Module aus dem ZIMO System.''
|  bgcolor="#666666" | &nbsp;
+
|&nbsp;
 
+
|- valign="Top"
+
|  &nbsp;
+
|  I8255 ||  i8255 Karte.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  M6051 ||  Märklin s88-Bus via Interface 6051.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''LENZFB'' ||  ''Rückmelde-Module aus dem Lenz System.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''DTFB''
+
|  nowrap="NOWRAP" | ''Rückmelde-Module aus dem Digitrax System (LocoNet).''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''SELFB''
+
|  nowrap="NOWRAP" | ''Rückmelde-Module aus dem Trix Selectrix System.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''FMZFB''
+
|  nowrap="NOWRAP" | ''Rückmelde-Module aus dem Fleischmann FMZ System.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  ''ZIMOFB'' ||  ''Rückmelde-Module aus dem ZIMO System.''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  Hinweis: ||  Die letzten fünf sind reservierte Namen, die sich ggfs. noch ändern können.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
| colspan="3" | Wert von '''<port-max>'''
+
|&nbsp;
&nbsp;  
+
Hinweis:
bgcolor="#666666" | &nbsp;  
+
|  Die letzten fünf sind reservierte Namen, die sich ggfs. noch ändern können.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
'''<port_max>'''
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Wert von <port-max> gibt die höchste Adresse an, die für diesen Modultype zulässig ist. Ein Nummerbereich beginnt mit (0 | 1) ???.  
+
Höchste Adresse, die für diesen Modultyp zulässig ist. Ein Nummerbereich beginnt mit (0 | 1) ???.  
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<port-inc>'''
+
|  '''<port_inc>'''
|  &nbsp;
+
|  colspan="2" | Anzahl der Ports, die in einem Modul dieses Typs zusammengefasst sind.
|  bgcolor="#666666" | &nbsp;
+
|&nbsp;
 
+
|- valign="Top"
+
|  &nbsp;
+
|  colspan="2" | Der Wert von <port-inc> gibt an wieviele Ports in einem Modul dieses Typs zusammengefasst sind.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 648: Zeile 389:
 
=== 2.8 Sonstige Gerätetypen ===
 
=== 2.8 Sonstige Gerätetypen ===
  
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
+
{| width="98%" cellpadding="2" align="Center" cellspacing="0" border="0"
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Dies kann erst dann spezifiziert werden, wenn entsprechende Definitionen in SRCP vorliegen.
+
|  colspan="3" |  
|  &nbsp;
+
Dies kann erst dann spezifiziert werden, wenn entsprechende Definitionen in SRCP vorliegen.
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
 
|}
 
|}
  
  
  
== 3 Geräte und ihre Eigenschaften ==
+
== 3 Geräte und Eigenschaften ==
  
 
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
 
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
Zeile 664: Zeile 405:
 
|- valign="Top"
 
|- valign="Top"
 
|  colspan="3" |  
 
|  colspan="3" |  
Hier werden die Eigenschaften beschrieben, die ein tatsächliches Gerät (Lok-, Schaltdekoder, Rückmeldemodul) hat. Das heißt, welche Funktionen von einem Dekoder oder Modul tatsächlich realisiert werden. Dies kann ggfs. weniger sein, als das Protokoll erlaubt.
+
Hier werden die Eigenschaften beschrieben, die ein tatsächliches Gerät (Lok-, Schaltdekoder, Rückmelde Modul) hat. Das heißt, welche Funktionen von einem Dekoder oder Modul tatsächlich realisiert werden. Dies kann ggfs. weniger sein, als das Protokoll erlaubt. Weiter gibt es einige Parameter, die nur für die Clients von Interesse sind (<d_type>, <name>, ...). Solche Parameter stehen am Ende der Parameterliste.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 675: Zeile 415:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | '''Überschrift: '= Locomotive & Function =' '''
+
|  colspan="3" nowrap="NOWRAP" | '''Überschrift: '= Locomotive & Function =''''
  
Für jeden definierten Lok- und Funktionsdekoder gibt es eine Zeile des Formats:
+
Format: '''DCGL <prot> <addr> <step> <dir> <func> <prog> <ps_addr> <V_max> <d_type> <name>'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
|  '''<prot>'''
|  colspan="2" nowrap="NOWRAP" | '''DCGL <name> <prot> <addr> <speed> <dir> <n-func> <prog> [<type>]'''
+
colspan="2" |
&nbsp;
+
Wie im Abschnitt [[#2.5 Protokolle Lokdekoder]] definiert. Dekoder, die über mehrere Protokolle angesprochen werden können, haben für jedes Protokoll einen Eintrag. PS (Protocol by Server) ist hier nicht zulässig, da es sich um reale Dekoder handelt.
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<name>'''
+
|  '''<addr>'''
&nbsp;
+
colspan="2" |
|  bgcolor="#666666" | &nbsp;  
+
Adresse dieses Dekoders unter dem gewählten Protokoll. Multiprotokoll-Dekoder dürfen für jedes Protokoll eine andere Adressen benutzen.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
'''<step>'''
 
|  colspan="2" |  
 
|  colspan="2" |  
Der Wert von <name> ist ein eindeutiger Name für diesen Lok-/Funktions- Dekoder (z.B. die Loknummer). Der Name muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen . Beispiele: "V188-003", "Berghexe", "Zuckersusi". <br />
+
Höchste Fahrstufen, die von diesem Dekoder unterstützt wird. Für Funktionsdekoder ist dieser Wert ggfs. auf 0 zu setzen.  
Soll keine Name angegeben werden, ist stattdessen das Zeichen '-' zu verwenden.  
+
|&nbsp;
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<prot>'''<nowiki>: </nowiki>
+
|  '''<dir>'''
&nbsp;
+
|  nowrap="NOWRAP" | abs <br /> rel
|  bgcolor="#666666" | &nbsp;  
+
Absolute Fahrtrichtungsangabe. <br /> Relative Fahrtrichtungsangabe.
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<func>'''
|  colspan="2" nowrap="NOWRAP" |  
+
|  colspan="2" bgcolor="#DDDDDD" |
Die Werte für <prot> sind wie in [[#2.5 Protokolle Lokdekoder]] definiert.  
+
Die Funktionen werden durch ein Wort <func> beschrieben, das aus Zeichenpaaren aufgebaut ist: <br />
|  &nbsp;
+
Das erste Zeichenpaar besteht aus zwei Ziffern und gibt die Zahl m der verfügbaren Funktionen inkl. der Standardfunktion an. Die Zeichenpaare 2 bis m+1 sind jeweils ein Kürzel für die Art der Verwendung der Funktionen F0 - Fn. [ m = n+1 ! ]. F0 ist dabei die Standardfunktion, F1 -Fn sind die Zusatzfunktionen. Das zweite Zeichenpaar bezeichnet also die Verwendung der Standardfunktion, das dritte der ersten Zusatzfunktion. Wird eine Funktion nicht benutzt so steht an der Stelle des Kürzels das Zeichenpaar '--'. Damit ist sowohl klar, wieviele Funktionen verfügbar sind, als auch, welche davon wirklich benutzt werden. Das minimale Wort für Funktion ist damit das Zeichenpaar '00' (keinerlei Funktion). <br />
|  bgcolor="#666666" | &nbsp;  
+
Den Kürzeln wird in der Tabelle FTXT ein Langtext zugeordnet. Siehe dazu den Abschnitt [[#4.1 Langtexte]].  
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<addr>''':
+
|  '''<prog>'''
&nbsp;
+
colspan="2" | Der Wert von <prog> ist ein Wort mit 7 Buchstaben:
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;  
+
|&nbsp;
colspan="2" |  
+
nowrap="NOWRAP" | 1) <br /> 2) <br /> 3) <br /> 4)
Der Wert von <addr> gibt die Adresse dieses Dekoders unter dem gewählten Protokoll an. Multiprotokolldekoder können demgemäss mehrere Einträge haben.
+
nowrap="NOWRAP" |
&nbsp;
+
Modus (P = Programmiergleis, F = on the Fly [im Betrieb]) <br />
|  bgcolor="#666666" | &nbsp;  
+
WRITE- Befehl (W = unterstützt) <br />
 +
READ- Befehl (R = unterstützt) <br />
 +
VERIFY-Befehl (V = unterstützt)
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| colspan="3" | Wert für '''<speed>'''<nowiki>: </nowiki>
+
|&nbsp;
&nbsp;
+
| 5) <br /> 6) <br /> 7)
|  bgcolor="#666666" | &nbsp;  
+
REGISTER (R = unterstützt) <br /> VARIABLE (V = unterstützt) <br /> BIT (B = unterstützt)
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
|  colspan="2" |  
+
|  colspan="2" bgcolor="#DDDDDD" |  
Der Wert von <speed> gibt die höchste Fahrstufen an, die von diesem Dekoder unterstützt wird. Für Funktionsdekoder ist dieser Wert ggfs. auf 0 zu setzen.  
+
Wird eine Funktion nicht unterstützt, so ist statt dessen das Zeichen '-' (= none) zu setzen. Beispiele: <br />
|  &nbsp;
+
"PW--R--" Nur Register auf dem Programmiergleis schreiben. <br />
|  bgcolor="#666666" | &nbsp;  
+
"FWR-RV-" Register + Variablen im laufenden Betrieb lesen + schreiben. <br />
 +
"-------" Nicht über Digitalbefehle programmierbar.
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<dir>''' sind:
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | '''<ps_addr>'''
&nbsp;
+
colspan="2" bgcolor="#DDDDDD" |
|  bgcolor="#666666" | &nbsp;  
+
Adresse, unter der dieser Dekoder mit "Protocol by Server" angesprochen wird. Dekoder, die über mehrere Protokolle / Adressen angesprochen werden, sollen jeweils die selbe PS-Adresse verwenden. <br />
 +
Durch <ps_addr> wird eine virtuelle Adresse definiert. Da im SRCP (ab 0.7.1) keine Beschränkung für die Größe einer Adresse besteht, kann man die in Deutschland ab Epoche IV übliche sechstellige Zahl für eine Lok verwenden. Dies völlig unabhängig davon, wieviel Adressen der Dekoder real unterstützt.
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<V_max>'''
abs ||  Absolute Fahrtrichtungsangabe.
+
colspan="2" bgcolor="#DDDDDD" |  
|  &nbsp;
+
Virtuelle Höchstgeschwindigkeit: Dieser Wert wird in einem Server zusammen mit einem Wert V (<= V_Max) für die Soll-Geschwindigkeit dazu benutzt die reale Fahrstufe zu berechnen. Im SRCP wird keine Vorgabe über die Masseinheit dieses Wertes gemacht. Empfehlenswert ist eine Orientierung an der Vorbild-Geschwindigkeit, also in km/h. <br />
|  bgcolor="#666666" | &nbsp;  
+
Hinweis: Wird dieser Wert auf 0 gesetzt, so verwendet der Server den Wert von V als reale Fahrstufe.
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<d_type>'''
rel ||  Relative Fahrtrichtungsangabe.  
+
colspan="2" bgcolor="#DDDDDD" |  
|  &nbsp;
+
Kennung für den Dekodertype: Dekoder eines Typs erhalten die gleiche Kennung. Die Kennung muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. <br />
|  bgcolor="#666666" | &nbsp;  
+
Soll keine Kennung angegeben werden, ist statt dessen das Wort "---" zu verwenden.
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<n-func>'''<nowiki>: </nowiki>
+
bgcolor="#DDDDDD" | '''<name>'''
|  &nbsp;
+
|  colspan="2" bgcolor="#DDDDDD" |
|  bgcolor="#666666" | &nbsp;  
+
Eindeutiger Name für diesen Lok-/Funktions-Dekoder: Der Name muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Beispiele: "V188-003", "Berghexe", "Zuckersusi". <br />
 +
Soll keine Name angegeben werden, ist statt dessen das Wort "---" zu verwenden. <br />
 +
Dekoder, die über mehrere Protokolle angesprochen werden können, dürfen den gleichen Namen verwenden.
 +
|  bgcolor="#00CC00" |&nbsp;
 +
|}
  
|- valign="Top"
 
|  &nbsp;
 
|  colspan="2" |
 
Der Wert für <n-func> gibt an wieviele Zusatzfunktionen von diesem Dekoder unterstützt werden.
 
Es wird implizit davon ausgegeangen, dass eine Standardfunktion immer implementiert ist.
 
|  &nbsp;
 
|  bgcolor="#666666" | &nbsp;
 
  
|- valign="Top"
+
=== 3.2 Schaltdekoder ===
|  colspan="3" | Der Wert von '''<prog>''' ist ein Wort mit 7 Buchstaben:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
|  &nbsp;
+
1)
+
|  nowrap="NOWRAP" | Modus (P = Programmiergleis, F = on the Fly [im Betrieb])
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
colspan="3" | '''Überschrift: '= Accessory =''''
|  2) ||  WRITE- Befehl (W = unterstützt)
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
Format: '''DCGA <prot> <addr_min> <addr_max> <d_type> <name>'''
|  &nbsp;
+
|&nbsp;
|  3) ||  READ- Befehl (R = unterstützt)
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
'''<prot>'''
4) ||  VERIFY-Befehl (V = unterstützt)
+
colspan="2" nowrap="NOWRAP" | Wie im Abschnitt [[#2.6 Protokolle Schaltdekoder]] angegeben.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
nowrap="NOWRAP" width="12%" | '''<addr_min>'''
|  5) ||  REGISTER (R = unterstützt)
+
colspan="2" nowrap="NOWRAP" | Adresse des ersten verwendeten Ausgang dieses Dekoders.
| &nbsp;
+
|&nbsp;
bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
nowrap="NOWRAP" width="12%" | '''<addr_max>'''
|  6) ||  VARIABLE (V = unterstützt)
+
colspan="2" nowrap="NOWRAP" | Adresse des letzten verwendeten Ausgang dieses Dekoders.
| &nbsp;
+
|&nbsp;
bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<d_type>'''
7) ||  BIT (B = unterstützt)
+
colspan="2" bgcolor="#DDDDDD" |  
| &nbsp;
+
Kennung für den Dekodertype: Dekoder eines Typs erhalten die gleiche Kennung. Die Kennung muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. <br />
|  bgcolor="#666666" | &nbsp;  
+
Soll keine Kennung angegeben werden, ist statt dessen das Wort "---" zu verwenden.
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<name>'''
|  colspan="2" |  
+
|  colspan="2" bgcolor="#DDDDDD" |  
Wird eine Funktion nicht unterstützt, so ist statt dessen das Zeichen N (= none) zu setzen. <br />
+
Eindeutiger Name für diesen Schaltdekoder: Der Name muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen . Beispiele: "Bahnhof-Links", "Gleis-1-2", "Abzweig-Abc". <br />
Beispiele: Ein Dekoder, der nur Register auf dem Programmiergleis schreiben kann, erhält die Zeichenkette "PWNNRNN". <br />
+
Soll keine Name angegeben werden, ist statt dessen das Wort "---" zu verwenden.  
Ein Dekoder, der Register und Variablen im laufenden Betrieb lesen und schreiben kann, erhält die Zeichenkette "FWRNRVN". <br />
+
|  bgcolor="#00CC00" |&nbsp;
Ein Dekoder, der nur über Mäuseklavier und Potis eingestellt wird, erhält die Zeichenkette "NNNNNNN".  
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<type>'''<nowiki>: </nowiki>
+
bgcolor="#DDDDDD" | Hinweis:
&nbsp;
+
colspan="2" bgcolor="#DDDDDD" |  
|  bgcolor="#666666" | &nbsp;
+
Für einen Einzeldekoder gilt <addr_min> = <addr_max> Auf diese Art kann je nach Wunsch eine Gruppendefiniton aller Ausgänge des Schaltdekoders oder eine Einzeldefinition eines Ausgangs erfolgen.
 
+
|  bgcolor="#00CC00" |&nbsp;
|- valign="Top"
+
| &nbsp;
+
|  colspan="2" |
+
Der Wert von <type> ist eine Kennung für den Dekodertype. Dekoder des gleichen Typs erhalten den gleichen Wert für <type>. Der Wert von <type> muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. Die Angabe dient zur Zeit nur der Dokumentation und ist daher optional.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
  
=== 3.2 Schaltdekoder ===
+
=== 3.3 Rückmelde Module ===
  
 
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
 
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | '''Überschrift: '= Accessory =' '''
+
|  colspan="3" | '''Überschrift: '= Feedback Units =''''
  
Für jeden definierten Schaltdekoder gibt es eine Zeile des Formats:  
+
Format: '''DCGA <modul-type> <port_min> <port_max> <d_type> <name>'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
nowrap="NOWRAP" width="12%" | '''<modul-type>'''
|  colspan="2" nowrap="NOWRAP" | '''DCGA <name> <prot> <addrmin> <addrmax> [<type>]'''
+
colspan="2" nowrap="NOWRAP" | Wie im Abschnitt [[#2.7 Protokolle Rückmelde Module]] definiert.
&nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<name>'''<nowiki>: </nowiki>
+
|  '''<port_min>'''
&nbsp;
+
colspan="2" nowrap="NOWRAP" | Portnummer des ersten verwendeten Eingang dieses Modules.
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
'''<port_max>'''
|  colspan="2" |
+
|  colspan="2" nowrap="NOWRAP" | Portnummer des letzten verwendeten Eingang dieses Modules.  
Der Wert von <name> ist ein eindeutiger Name für diesen Lok-/Funktions- Dekoder (z.B. die Loknummer). Der Name muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen . Beispiele: "V188-003", "Berghexe", "Zuckersusi". <br />
+
|&nbsp;
Soll keine Name angegeben werden, ist stattdessen das Zeichen '-' zu verwenden.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<prot>''' sind:
+
bgcolor="#DDDDDD" | '''<d_type>'''
&nbsp;
+
colspan="2" bgcolor="#DDDDDD" |
|  bgcolor="#666666" | &nbsp;  
+
Kennung für den konkreten Typ eines Rückmelde Modules: Hier dient sie hauptsächlich zur Unterscheidung verschiedener Lieferanten eines Modultyps. Rückmelder eines Typs erhalten die gleiche Kennung. Die Kennung muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. <br />
 +
Soll keine Kennung angegeben werden, ist statt dessen das Wort "---" zu verwenden.
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" | '''<name>'''
|  colspan="2" nowrap="NOWRAP" |  
+
|  colspan="2" bgcolor="#DDDDDD" |  
Die Werte für <prot> sind wie in [[#2.6 Protokolle Schaltdekoder]] angegeben.  
+
Eindeutiger Name für dieses Rückmelde Modul: Der Name muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Beispiele: "GBM-Bonn", "GBM-Strecke", "Weichen-Bhf". <br />
|  &nbsp;
+
Soll keine Name angegeben werden, ist statt dessen das Wort "---" zu verwenden.  
|  bgcolor="#666666" | &nbsp;  
+
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Wert von '''<addrmin>'''<nowiki>: </nowiki>
+
|  Hinweis:
| &nbsp;  
+
|  colspan="2" | Mit <port_min> = <port_max> kann man ggfs. auch jeden Port einzeln definieren.
| bgcolor="#666666" | &nbsp;
+
|&nbsp;
 +
|}
  
|- valign="Top"
 
|  &nbsp;
 
|  colspan="2" | Der Wert von <addrmin> gibt die die Adresse des ersten verwendeten Ausgang dieses Dekoders an.
 
|  &nbsp;
 
|  bgcolor="#666666" | &nbsp;
 
  
|- valign="Top"
+
== 4 Sonstiges ==
|  colspan="3" | Wert von '''<addrmax>'''<nowiki>: </nowiki>
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
|  &nbsp;
+
|  colspan="2" | Der Wert von <addrmax> gibt die die Adresse des letzten verwendeten Ausgang dieses Dekoders an.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Wert von '''<type>'''<nowiki>: </nowiki>
+
|  colspan="3" bgcolor="#DDDDDD" |  
|  &nbsp;
+
Dies ist der Platz für Festlegungen, die übergreifend sind. <br />
bgcolor="#666666" | &nbsp;
+
Als erstes wird ein Bereich für die Zuordnung von Kurzformen zu Langtexten definiert. <br />
 
+
Weitere übergreifende Funktionen folgen nach Bedarf.
|- valign="Top"
+
|  bgcolor="#00CC00" |&nbsp;
|  &nbsp;
+
|  colspan="2" |
+
Der Wert von <type> ist eine Kennung für den Dekodertype. Dekoder des gleichen Typs erhalten den gleichen Wert für <type>. Der Wert von <type> muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. Die Angabe dient zur Zeit nur der Dokumentation und ist daher optional.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Hinweis:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  colspan="2" |
+
Für einen Einzeldekoder gilt <addrmin> = <addrmax> Auf diese Art kann je nach Wunsch eine Gruppendefiniton oder eine Einzeldefinition der Schaltdekoderausgänge erfolgen.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
  
=== 3.3 Rückmelde Module ===
+
=== 4.1 Langtexte ===
  
 
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
 
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | '''Überschrift: '= Feedback Units =' '''
+
|  colspan="3" bgcolor="#DDDDDD" |
 +
Im Laufe der Diskussion um das CRCF hat sich gezeigt, dass es notwendig ist sowohl Kurzformen (=Abkürzungen), als auch Langformen (=Text) für bestimmte Informationen zur Verfügung zu stellen. Mit den Tabellen in diesem Abschnitt wird eine Zuordnung zwischen Abkürzungen und zugehörigen Text hergestellt. <br />
 +
Je nach Art der Information kann diese Tabelle zwingend sein, das heißt nur Werte in der Tabelle sind zulässig, oder optional, das heißt es können auch Abkürzungen verwendet werden, die nicht in der Tabelle enthalten sind.
  
Für jede definierte Rückmelde Modul gibt es eine Zeile des Formats:  
+
'''Überschrift: '= Messages =''''
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
Format: '''<TEXT-TYPE> <short> <lang> <freetext>'''
|  &nbsp;
+
|  bgcolor="#CC0000" |&nbsp;
|  colspan="2" nowrap="NOWRAP" | '''DCGA <name> <modul-type> <port-min> <port-max> [<type>]'''
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Wert von '''<name>''':
+
nowrap="NOWRAP" width="12%" bgcolor="#DDDDDD" | '''<TEXT-TYPE>'''
&nbsp;
+
colspan="2" bgcolor="#DDDDDD" nowrap="NOWRAP" |
|  bgcolor="#666666" | &nbsp;  
+
Kennung für die Art der Zuordnung. <br />
 +
Für den Befehl CONFGET ist dies ein Konfigurationstyp. (Siehe [[#5.1 Konfigurationstypen]])
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | '''<short>'''
|  colspan="2" |  
+
colspan="2" bgcolor="#DDDDDD" | Abkürzung,
Der Wert von <name> ist ein eindeutiger Name für dieses Rückmelde Modul. Der Name muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Beispiele: "V188-003", "Berghexe", "Zuckersusi". <br />
+
|  bgcolor="#CC0000" |&nbsp;
Soll keine Name angegeben werden, ist stattdessen das Zeichen '-' zu verwenden.
+
&nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" | Werte für '''<modul-type>''':
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | '''<lang>'''
&nbsp;
+
colspan="2" bgcolor="#DDDDDD" |
|  bgcolor="#666666" | &nbsp;  
+
Sprache (z.B. de := deutsch, en := englisch). Für <lang> werden die im Internet üblichen zwei Zeichen Abkürzungen verwendet.
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
|  colspan="2" |  
+
|  colspan="2" bgcolor="#DDDDDD" |  
Der Wert von <modul-type> gibt Art des verwendeten Modules an. Es gelten die Werte, die in [[#2.7 Protokolle Rückmelde Module]] dafür definiert sind.
+
Alle weiteren Worte in dieser Zeile sind dann der Meldungstext. <br />
|  &nbsp;
+
Die Reihenfolge innerhalb einer Tabelle ist ohne Bedeutung. Sinnvollerweise wird man jedoch die Einträge für eine Sprache zusammenhalten und alphabetisch nach den Kürzeln sortieren.  
|  bgcolor="#666666" | &nbsp;  
+
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Wert von '''<port-min>''':
+
|  colspan="3" bgcolor="#DDDDDD" | Bisher sind die folgenden Zuordnungstabellen definiert.
|  &nbsp;
+
|  bgcolor="#CC0000" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
|  colspan="2" | Der Wert von <port-min> gibt die Portnummer des ersten verwendeten Eingang dieses Modules an.  
+
|  colspan="2" bgcolor="#DDDDDD" | '''FTXT''' '''<short> <lang> <freetext>''' (Funktionen in Lokdekodern) <br />
|  &nbsp;
+
'''ITXT''' '''<short> <lang> <freetext>''' (INFO liefert eine Zahl zurück) <br />
|  bgcolor="#666666" | &nbsp;  
+
'''LTXT''' '''<short> <lang> <freetext>''' (Zuordnung der Sprachen) <br /><br />
 +
FTXT ist eine optionale Tabelle, insbesondere werden in verschiedenen Sprachen unterschiedliche Abkürzungen verwendet. <br />
 +
ITXT und LTXT sollen vollständig sein.
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Wert von '''<port-max>''':
+
|  colspan="3" bgcolor="#DDDDDD" | Einige Beispiele mögen zur Verdeutlichung dienen.
|  &nbsp;
+
|  bgcolor="#CC0000" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
|  colspan="2" | Der Wert von <port-max> gibt die Portnummer des letzten verwendeten Eingang dieses Modules an.
+
|  colspan="2" bgcolor="#DDDDDD" |
|  &nbsp;
+
'''FTXT''' '''<short> <lang> <freetext>''' (Funktionen in Lokdekodern)
bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
  FTXT    Da    de    Dampf
|  colspan="3" | Wert von '''<type>'''<nowiki>: </nowiki>
+
  FTXT    Sl    de    Spitzlicht
|  &nbsp;
+
  FTXT    Pf    de    Pfeife
|  bgcolor="#666666" | &nbsp;
+
  FTXT    Gl    de    Glocke
 +
  FTXT    Tl    de    Triebwerksbeleuchtung
 +
  FTXT    Lu    de    Lüfter
 +
  FTXT    Sa    de    Stromabnehmer
 +
  ...
 +
  FTXT    ST    en    Steam        (Dampf)
 +
  FTXT    Hl    en    Headlight    (Spitzlicht)
 +
  FTXT    Wh    en    Whistle      (Pfeife)
 +
  FTXT    Bl    en    Bell          (Glocke)
 +
  FTXT    Nb    en    Numberboard  (Nummerntafel)
 +
  ...
  
|- valign="Top"
+
'''ITXT''' '''<short> <lang> <freetext>''' (INFO liefert eine Zahl zurück)
|  &nbsp;
+
|  colspan="2" |
+
Der Wert von <type> ist eine Kennung für den konkreten Typ eines Rückmelde Modules. Hier dient er hauptsächlich zur Unterscheidung verschiedener Lieferanten eines Modultypes. Rückmelder des gleichen Typs erhalten den gleichen Wert für <type>. Der Wert von <type> muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. Die Angabe dient zur Zeit nur der Dokumentation und ist daher optional.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
  
|- valign="Top"
+
  ITXT    -1    de    nicht unterstützt
|  colspan="3" | Hinweis:
+
  ITXT    -2    de    keine Daten
|  &nbsp;
+
  ITXT    -3    de    Zeitlimit überschritten
|  bgcolor="#666666" | &nbsp;
+
   
 
+
  ITXT    -1   en    unsupported
|- valign="Top"
+
  ITXT    -2    en    no data
| &nbsp;
+
  ITXT    -3   en    timeout
|  colspan="2" | Mit <port-min> = <port-max> kann man falls gewünscht auch jeden Port einzeln definieren.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
|}
+
 
+
 
+
 
+
== 4 Sonstiges ==
+
 
+
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
+
 
+
|- valign="Top"
+
|  colspan="3" |
+
Dies ist erst einmal ein Platzhalter für zukünftige Erweiterungen oder Festlegungen, die übergreifend sind. Beispielsweise könnte ich mir hier eine Liste von Rückgabewerten vorstellen, wenn das INFO Statement als Antwort auf einen GET Befehl keine Daten zur Verfügung stellen kann.
+
  
'''Beispiel: INFO <value> <lang> <Text>'''
+
'''LTXT''' '''<short> <lang> <freetext>''' (Zuordnung der Sprachen)
  
Dabei ist <value> der Rückgabewert (eine Zahl, in der Regel negativ), <lang> eine Sprache (z.B. de := deutsch, en := englisch). Alle weiteren Worte in dieser Zeile sind dann der Meldungstext. Das Paar <value>, <lang> muss eindeutig sein. Werden mehrere Sprachen angeboten, so sind für jede Sprache alle möglichen Werte von <value> mit Text zu versehen.
+
  LTXT    de   de    deutsch
|  &nbsp;
+
  LTXT    en   de    englisch
|  bgcolor="#666666" | &nbsp;  
+
  LTXT    fr    de    franzoesisch
 +
 
 +
  LTXT    en    en    english
 +
  LTXT    fr    en    french
 +
  LTXT    de    en    german
 +
 
 +
  LTXT    en    fr    anglais
 +
  LTXT    fr    fr    francais
 +
  LTXT    de    fr    allemand
 +
|  bgcolor="#CC0000" |&nbsp;
 
|}
 
|}
  
Zeile 1.040: Zeile 728:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
Der Befehl CONFGET dient dazu, Clients die Möglichkeit zu geben beim Server nachzufragen, welche Fähigkeiten er hat (siehe [[#2 Servereigenschaften]]). Diese Angaben sind '''verbindlich'''.
+
Der Befehl CONFGET dient dazu, Clients die Möglichkeit zu geben beim Server nachzufragen, welche Fähigkeiten er hat (Siehe [[#2 Servereigenschaften]]). Diese Angaben sind '''verbindlich'''.
  
Als zweites kann mit diesem Befehl abgefragt werden, welche Lok-, Funktions-, Schalt-Dekoder und Rückmelde Module dem Server bekannt sind (siehe [[#3 Geräte und ihre Eigenschaften]]). Diese Information dient (mehreren) Clients dazu einen gleichen Informationsstand zu haben. Diese Informationen sind jedoch '''nicht verbindlich'''.
+
Als zweites kann mit diesem Befehl abgefragt werden, welche Lok-, Funktions-, Schalt-Dekoder und Rückmelde Module dem Server bekannt sind. (Siehe [[#3 Geräte und Eigenschaften]]) Diese Information dient (mehreren) Clients dazu einen gleichen Informationsstand zu haben. Diese Informationen sind jedoch '''nicht verbindlich'''.
  
 
* Die Informationen müssen nicht vollständig sein.
 
* Die Informationen müssen nicht vollständig sein.
Zeile 1.049: Zeile 737:
 
* Es können sich "Fremdloks" auf der Anlage befinden, die natürlich nicht in der Konfigurationsdatei beschrieben sind.
 
* Es können sich "Fremdloks" auf der Anlage befinden, die natürlich nicht in der Konfigurationsdatei beschrieben sind.
  
Informationen zu Schaltdekodern und Rückmeldern als ortsfeste Bauteile hingegen sollten (in der Regel) korrekt und vollständig sein.
+
Informationen zu Schaltdekodern und Rückmeldern als ortsfeste Bauteile hingegen sollten (in der Regel) korrekt und vollständig sein.  
 +
|&nbsp;
  
Anmerkung:
+
|- valign="Top"
| &nbsp;
+
colspan="3" bgcolor="#DDDDDD" | Anmerkungen: <br />
|  bgcolor="#666666" | &nbsp;
+
Die Spezifikation des Befehl CONFGET gehört eigentlich in das SRCP (Simple Railroad Command Protocol). Da der Befehl CONFGET jedoch unmittelbar von den Festlegungen im CRCF abhängt, wird er vorerst hier beschrieben. Der Befehl CONFGET hat nur dann Sinn, wenn die Konfigurations Dateien existieren und nach dem CRCF gestaltet sind.
  
|- valign="Top"
+
Ein Befehl CONFSET zum Setzen von Konfigurations Informationen ist zur Zeit nicht definiert. Es ist nicht klar, ob dafür ein Bedarf existiert. Wie auch immer, sinnvoll wäre ein solcher Befehl nur für die Informationen zu Lokdekodern wie sie in [[#3.1 Lok- und Funktionsdekoder]] festgelegt sind. Die Servereigenschaften (siehe [[#2 Servereigenschaften]]) ändern sich nicht, solange ein Server läuft. Auch die Angaben zu einer (zukünftigen) Beschreibung des Anlagenlayouts ändern sich nicht während des laufenden Betriebs. Ein Lok jedoch kann ohne weiteres hinzugefügt, entfernt oder umprogrammiert werden.
|  &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
|  colspan="2" nowrap="NOWRAP" |
+
Die Spezifikation des Befehl CONFGET gehört eigentlich in das SRCP <br />
+
(Simple Railroad Command Protocol). Dies hier ist nur der erste Vorschlag.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.070: Zeile 754:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Zur Zeit sind 10 verschiedene '''Konfigurationstypen''' definiert.
+
|  colspan="3" |  
|  &nbsp;
+
Zur Zeit sind folgende '''Konfigurationstypen''' definiert. Sie sind hier zusammen mit ihren Parametern aufgelistet. Parameter, die zur genaueren Identifikation dienen, sind unterstrichen.
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;  
+
|&nbsp;
|  VERS ||  <name> <vers> SRCP <srcp>
+
nowrap="NOWRAP" | VERS <br /> PORT <br /> SCMD
|  &nbsp;
+
|  <name> <vers> SRCP <srcp> CRCF <crcf> <br /> <port> <source> <br /> <command>
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
PORT ||  <port> <direction>
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | GCMD
|  &nbsp;
+
bgcolor="#DDDDDD" | <<u>command</u>> <<u>group</u>>  
|  bgcolor="#666666" | &nbsp;  
+
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;  
+
|&nbsp;
SCMD || <command>
+
nowrap="NOWRAP" | PRGL <br /> PRGA <br /> PRFB
&nbsp;
+
|   
|  bgcolor="#666666" | &nbsp;  
+
<<u>prot</u>> <addr_max> <step_max> <dir> <nro_f> <br />
 +
<<u>prot</u>> <addr_max> <br />
 +
<<u>module-type</u>> <port_max> <port_inc>
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
GCMD |<command>  
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | DCGL <br /> DCGA <br /> DCFB
&nbsp;
+
bgcolor="#DDDDDD" nowrap="NOWRAP" |
|  bgcolor="#666666" | &nbsp;  
+
<<u>prot</u>> <<u>addr</u>> <step> <dir> <func> <prog> <ps_addr> <V_max> <d_type> <name> <br />
 +
<<u>prot</u>> <<u>addr_min</u>> <addr_max> <d_type> <name> <br />
 +
<<u>module-type</u>> <<u>port_min</u>> <port_max> <d_type> <name>
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
PRGL || <prot> <addrmax> <speedmax> <dir> <n-func>
+
bgcolor="#DDDDDD" nowrap="NOWRAP" | FTXT <br /> ITXT <br /> LTXT
|  &nbsp;
+
| bgcolor="#DDDDDD" |
|  bgcolor="#666666" | &nbsp;  
+
<<u>short</u>> <<u>lang</u>> <freetext> <br />
 +
<<u>short</u>> <<u>lang</u>> <freetext> <br />
 +
<<u>short</u>> <<u>lang</u>> <freetext>
 +
|  bgcolor="#CC0000" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
colspan="3" bgcolor="#DDDDDD" |  
|  PRGA ||  <prot> <addrmax>
+
Dabei haben die ersten drei [Servereigenschaften] keine weitere Identifikation. <br />
|  &nbsp;
+
GCMD [allgemeine Befehle] hat Befehl und Gerätegruppe als genauere Identifikation. <br />
|  bgcolor="#666666" | &nbsp;
+
Die nächsten drei [Protokolle] haben Protokoll/Modultyp als genauere Identifikation. <br />
 
+
Die folgenden drei [Dekoder/Rückmelder] haben Protokoll/Modultyp + Adresse/Portnummer als genauere Identifikation. <br />
|- valign="Top"
+
Die letzten drei [Textzuordnung] haben Kürzel und Sprache als genauere Identifikation.
|  &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
|  PRFB || <module-type> <port-max> <port-inc>
+
|  &nbsp;
+
bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  DCGL
+
|  nowrap="NOWRAP" | <name> <prot> <addr> <spmax> <dir> <n-func> <prog> [<type>]
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  DCGA ||  <name> <prot> <addrmin> <addrmax> [<type>]
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  DCFB ||  <name> <module-type> <port-min> <port-max> [<type>]  
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" |
+
Dabei haben die ersten vier keine weitere Identifikation, die nächsten drei Protokoll/Modultype als genauere Identifikation. Die letzten drei haben Protokoll/Modultype + Adresse/Portnummer als genauere Identifikation. Bei diesen ist jedoch als Besonderheit zwischen dem Konfigurationstyp und der genaueren Identifikation ein frei wählbarer - allerdings eindeutiger - Name eingefügt.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.145: Zeile 810:
 
=== 5.2 Befehl CONFGET ===
 
=== 5.2 Befehl CONFGET ===
  
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
+
{| width="98%" cellpadding="2" align="Center" cellspacing="0" border="0"
  
 
|- valign="Top"
 
|- valign="Top"
 
|  colspan="3" | Das generelle Format des Befehls ist:
 
|  colspan="3" | Das generelle Format des Befehls ist:
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
| &nbsp;  
+
|&nbsp;
|  colspan="2" nowrap="NOWRAP" | '''CONFGET <conf-type> [<spec-1>] [<spec-2>]'''
+
|  colspan="2" | '''CONFGET <conf-type> [<spec_1>] [<spec_2>]'''
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Der Wert von <conf-type> ist der Typ der Information der angefordert wird (vier Zeichen Code):
+
|  colspan="3" |  
|  &nbsp;
+
Der Wert von <conf-type> ist der Typ der Information der angefordert wird (vier Zeichen Code). Dahinter steht jeweils, was zur genaueren Identifikation benutzt wird :
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
|  VERS, PORT, SCMD, GCMD, ||  Servereigenschaften
+
bgcolor="#DDDDDD" nowrap="NOWRAP" |
|  &nbsp;
+
VERS, PORT, SCMD, <br />
|  bgcolor="#666666" | &nbsp;  
+
PRGL, PRGA, PRFB, <br />
 +
GCMD <br />
 +
DCGL, DCGA, DCFB, <br />
 +
FTXT, ITXT, LTXT
 +
bgcolor="#DDDDDD" nowrap="NOWRAP" |
 +
Servereigenschaften <br />
 +
unterstützte Protokolle [Protokoll/Modultyp] <br />
 +
unterstützte Befehle [Befehl] [Gerätegruppe] <br />
 +
Dekoder, Rückmelder [Protokoll/Modultyp] [Adresse/Portnummer] <br />
 +
Zuordnung Langtext [Kürzel] [Sprache]
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
&nbsp;
+
colspan="3" |
|  PRGL, PRGA, PRFB, ||  unterstützte Protokolle [<spec-1>]
+
[<spec_1>] und [<spec_2>] dienen zur genaueren Identifikationen von Befehlen, Langtext, Protokollen, Dekodern und Rückmeldern :
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
bgcolor="#DDDDDD" | &nbsp;
DCGL, DCGA, DCFB, ||  Dekoder, Rückmelder [<spec-1>] [<spec-2>]
+
bgcolor="#DDDDDD" nowrap="NOWRAP" |  
|  &nbsp;
+
Protokoll/Modultyp <br />
|  bgcolor="#666666" | &nbsp;  
+
Befehl + Gerätegruppe <br />
 +
Protokoll + Adresse <br />
 +
Protokoll + Portnummer <br />
 +
Modultyp + Portnummer <br />
 +
Kürzel + Sprache
 +
bgcolor="#DDDDDD" nowrap="NOWRAP" |
 +
für Protokolle, (PRGL, PRGA, PRFB) <br />
 +
für allgemeine Befehle, (GCMD) <br />
 +
für Lokdekoder, (DCGL) <br />
 +
für Schaltdekoder, (DCGA) <br />
 +
für Rückmelder. (DCFB) <br />
 +
für Langtext, (FTXT, ITXT, LTXT)
 +
|  bgcolor="#00CC00" |&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
| colspan="3" | [<spec-1>] und [<spec-2>] sind genauere Identifikationen von Protokollen, Dekodern und Rückmeldern:
+
|&nbsp;
&nbsp;  
+
colspan="2" | Für die anderen Informationenstypen sind sie ohne Belang.
bgcolor="#666666" | &nbsp;  
+
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;
+
|  colspan="3" bgcolor="#DDDDDD" | Hinweis: <br />
|  Protokoll / Modultype ||  für Protokolle, (PRGL, PRGA, PRFB)
+
Für [<spec_1>], [<spec_2>] kann ein '*' als Wildcard verwendet werden. Als Beispiel liefert "CONFGET GCMD * FB" alle Befehle zurück, mit denen Rückmelder angesprochen werden. <br />
|  &nbsp;
+
Bei VERS, PORT und SCMD werden grundsätzlich alle zugehörigen Infozeilen zurück geliefert.
|  bgcolor="#666666" | &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
 
+
|- valign="Top"
+
|  &nbsp;
+
|  Protokoll + Adresse ||  für Lokdekoder, (DCGL)
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  Protokoll + Portnummer ||  für Schaltdekoder, (DCGA)
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  Modultype + Portnummer ||  für Rückmelder. (DCFB)
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  colspan="2" nowrap="NOWRAP" | Für die anderen Informationenstypen sind sie ohne Belang.
+
|  &nbsp;
+
bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Hinweis:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  colspan="2" |
+
Für [<spec-1>], [<spec-2>] kann ein '*' als Wildcard verwendet werden. Als Beispiel liefert "CONFGET DCGL NB *" alle Lokdekoder zurück, die mit dem NMRA-DCC Basic Protokoll angesprochen werden.
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.232: Zeile 880:
 
=== 5.3 Antwort auf CONFGET ===
 
=== 5.3 Antwort auf CONFGET ===
  
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
+
{| width="98%" cellpadding="2" align="Center" cellspacing="0" border="0"
  
 
|- valign="Top"
 
|- valign="Top"
 
|  colspan="3" | Das generelle Format der Antwort ist:
 
|  colspan="3" | Das generelle Format der Antwort ist:
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;  
+
nowrap="NOWRAP" width="10%" |&nbsp;
|  colspan="2" nowrap="NOWRAP" |  
+
|  colspan="2" nowrap="NOWRAP" | '''INFO CONF <conf-type> [<spec_1>] [<spec_2>] [.*] '''
'''INFO CONF <conf-type> [<spec-1>] [<spec-2>] [.*] '''
+
  
 
[.*] steht dabei für alle weiteren Angaben entsprechend dem Konfigurationstyp.  
 
[.*] steht dabei für alle weiteren Angaben entsprechend dem Konfigurationstyp.  
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" | Wird der Befehl CONFGET nicht unterstützt, lautet die Antwort:
+
|  colspan="3" |  
|  &nbsp;
+
Wird der Befehl CONFGET nicht unterstützt, lautet die Antwort: INFO -1 <br />
|  bgcolor="#666666" | &nbsp;  
+
Sind keine Daten zu <conf-type> oder [<spec_x>] vorhanden, ist die Antwort: INFO -2
 +
|&nbsp;
  
 
|- valign="Top"
 
|- valign="Top"
|  &nbsp;
+
|  colspan="3" bgcolor="#DDDDDD" | Hinweise: <br />
|  colspan="2" | INFO -1
+
[<conf-type>] ist wie im Abschnitt [[#5.1 Konfigurationstypen]] definiert. <br />
|  &nbsp;
+
[<spec_1>] und [<spec_2>] sind wie im Abschnitt [[#5.2 Befehl CONFGET]] definiert. <br />
bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Sind keine Daten zu <conf-type> oder [<spec-x>] vorhanden, ist die Antwort:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  colspan="2" | INFO -2
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  colspan="3" | Hinweis:
+
|  &nbsp;
+
|  bgcolor="#666666" | &nbsp;
+
 
+
|- valign="Top"
+
|  &nbsp;
+
|  colspan="2" |
+
 
Die Antwort auf einen Befehl CONFGET kann mehrere Zeilen "INFO CONF ..." umfassen. Ein Client muss darauf vorbereitet sein, diese sinnvoll zu verarbeiten.
 
Die Antwort auf einen Befehl CONFGET kann mehrere Zeilen "INFO CONF ..." umfassen. Ein Client muss darauf vorbereitet sein, diese sinnvoll zu verarbeiten.
|  &nbsp;
+
|  bgcolor="#00CC00" |&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.291: Zeile 915:
 
|  colspan="3" |  
 
|  colspan="3" |  
 
Auf der Basis des SRCP sind ja schon viele Entwicklungen angedacht. Hier ist der Platz um ihr Informationsbedürfnis festzulegen. Denkbar sind z.B Beschreibung einer Anlage und ihrer logischen Struktur (Blöcke, Fahrstrassen, Besetztmelder, ...) oder Informationen für den Fahrplanbetrieb (Züge, Fahrstrecke, Fahrzeittrassen, ...) und vieles andere.
 
Auf der Basis des SRCP sind ja schon viele Entwicklungen angedacht. Hier ist der Platz um ihr Informationsbedürfnis festzulegen. Denkbar sind z.B Beschreibung einer Anlage und ihrer logischen Struktur (Blöcke, Fahrstrassen, Besetztmelder, ...) oder Informationen für den Fahrplanbetrieb (Züge, Fahrstrecke, Fahrzeittrassen, ...) und vieles andere.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.302: Zeile 925:
 
|- valign="Top"
 
|- valign="Top"
 
|  colspan="3" | Hier will ich kurz Erklärungen zu einigen von mir vorgeschlagenen Punkten geben.
 
|  colspan="3" | Hier will ich kurz Erklärungen zu einigen von mir vorgeschlagenen Punkten geben.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.312: Zeile 934:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
In der Diskussion um das SRCP wurde mehrfach der Wunsch nach einer zentralen Konfigurationsbasis geäussert. Dies ist für eine einzige Serverimplementierung sicher nicht zwingend. Werden jedoch unterschiedliche Serverimplementierung angeboten, so ist es für alle weiteren Programme (Clients, Middleware, ...) sinnvoll, die Eigenschaften eines Servers ermitteln zu können.
+
In der Diskussion um das SRCP wurde mehrfach der Wunsch nach einer Datei für die Konfiguration geäussert. Dies ist für eine einzige Serverimplementierung sicher nicht zwingend. Werden jedoch unterschiedliche Server angeboten, so ist es für alle weiteren Programme (Clients, Middleware, ...) sinnvoll, die Eigenschaften eines Servers ermitteln zu können.
  
Weiter wurde angeregt eine gemeinsame Datenbasis für alle Clients bezüglich Lokdekoder, Schaltdekoder und Rückmelder zu haben.
+
Weiter wurde angeregt eine gemeinsame Datenbasis für alle Clients bezüglich Lokdekoder, Schaltdekoder und Rückmelder zu haben. Diese Datenbasis, soll ebenso wie die Informationen über die Eigenschaften des Servers über einen SRCP-konformen Befehl abgefragt werden können.
  
Beiden Wünschen soll mit dieser Definition Rechnung getragen werden.
+
Diesen Wünschen soll mit dieser Definition Rechnung getragen werden.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.328: Zeile 949:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
Bisher ist nichts zur Aufteilung der Konfigurationsdaten auf Dateien gesagt worden. Dieser Punkt ist bewusst offengelassen, da ich dafür keinen Vorschlag machen will. Sinnvoll ist sicherlich eine Aufteilung in eine Datei für die Servereigenschaften (siehe [[#2 Servereigenschaften | Kapitel 2]]) und eine Datei für die Dekoder und Rückmelder (siehe [[#3 Geräte und ihre Eigenschaften | Kapitel 3]]). Sollte eines Tages Informationen über das Layout definiert werden, so ist dafür sicher eine weitere Datei sinnvoll.
+
Bisher ist nichts zur Aufteilung der Konfigurationsdaten auf Dateien gesagt worden. Dieser Punkt ist bewusst offengelassen, da ich dafür keinen Vorschlag machen will. Sinnvoll ist sicherlich eine Aufteilung in eine Datei für die Servereigenschaften (siehe [[#2 Servereigenschaften]]) und eine Datei für die Dekoder und Rückmelder (siehe [[#3 Geräte und Eigenschaften]]). Sollte eines Tages Informationen über das Layout einer Modellbahn Anlage definiert werden, so ist dafür ebenso eine weitere Datei sinnvoll.
  
Ob eine weitere Aufteilung wünschenswert ist soll die Diskussion zeigen.
+
Ob eine weitere Aufteilung wünschenswert ist soll die Diskussion zeigen. <br />
|  &nbsp;
+
'''Um Namensvorschläge wird gebeten!'''
|  bgcolor="#666666" | &nbsp;  
+
|&nbsp;
 
|}
 
|}
  
Zeile 1.342: Zeile 963:
  
 
|- valign="Top"
 
|- valign="Top"
|  colspan="3" |  
+
|  colspan="3" |
 
Für die Definition der Dekoder und Rückmelder sind Namen eingeführt worden. Dies ist ein Konzept, dass im SRCP bisher nicht existiert und dort auch nicht notwendig ist. Es dient dazu, dass alle Clients Dekoder und Rückmelder mit gleichen Namen darstellen können. <br />
 
Für die Definition der Dekoder und Rückmelder sind Namen eingeführt worden. Dies ist ein Konzept, dass im SRCP bisher nicht existiert und dort auch nicht notwendig ist. Es dient dazu, dass alle Clients Dekoder und Rückmelder mit gleichen Namen darstellen können. <br />
 
Namen wie "V188-003" oder "Abzweig-Valkenburg" sind für einen Mensch als Benutzer der Clients sicherlich einfacher zuzuordnen als M3-17 oder N-327.
 
Namen wie "V188-003" oder "Abzweig-Valkenburg" sind für einen Mensch als Benutzer der Clients sicherlich einfacher zuzuordnen als M3-17 oder N-327.
  
 
Ebenso sind Typen zur Klassifizierung verschiedener Dekoder- / Rückmeldertypen eingeführt worden. Auch diese sind in SRCP weder definiert noch notwendig. Sie dienen hauptsächlich der Dokumentation. Inwieweit ein Client diese Information verwendet bleibt ihm überlassen.
 
Ebenso sind Typen zur Klassifizierung verschiedener Dekoder- / Rückmeldertypen eingeführt worden. Auch diese sind in SRCP weder definiert noch notwendig. Sie dienen hauptsächlich der Dokumentation. Inwieweit ein Client diese Information verwendet bleibt ihm überlassen.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.359: Zeile 979:
 
|  colspan="3" |  
 
|  colspan="3" |  
 
Genauso wie im SRCP werden in der formalen Definition englische Begriffe bzw. Abkürzungen davon verwendet. Dies wurde in SRCP in Hinblick auf eine mögliche internationale Verbreitung so beschlossen. Ich schliesse mich diesem Vorgehen an.
 
Genauso wie im SRCP werden in der formalen Definition englische Begriffe bzw. Abkürzungen davon verwendet. Dies wurde in SRCP in Hinblick auf eine mögliche internationale Verbreitung so beschlossen. Ich schliesse mich diesem Vorgehen an.
|  &nbsp;
+
|&nbsp;
|  bgcolor="#666666" | &nbsp;  
+
 
|}
 
|}
  
Zeile 1.366: Zeile 985:
 
== 8 Änderungsprotokoll ==
 
== 8 Änderungsprotokoll ==
  
{| width="98%" cellpadding="1" align="Center" cellspacing="0" border="0"
+
 
 +
=== Änderungen von CRCF 0.1 nach CRCF 0.2.0 ===
 +
 
 +
{| width="98%" cellpadding="2" align="Center" cellspacing="0" border="0"
  
 
|- valign="Top"
 
|- valign="Top"
colspan="3" |  
+
bgcolor="#DDDDDD" |
Hier wird in späteren Versionen eine Übersicht über die wichtigsten Änderungen von Version zu Version stehen.
+
'''[[#2 Servereigenschaften]] , [[#3 Geräte und Eigenschaften]] :'''<br />
|  &nbsp;
+
Einige Parameternamen geändert: Das Zeichen '-' durch '_' ersetzt, sowie in einigen Parameternamen das Zeichen '_' eingefügt. Die Abschnitte [[#5.1 Konfigurationstypen]] und [[#5.2 Befehl CONFGET]] wurden entsprechend angepasst.
|  bgcolor="#00FF00" | &nbsp;  
+
 
 +
'''[[#2.1 Serverversion]] :'''<br />
 +
Angabe der verwendeten CRCF Version hinzugefügt
 +
 
 +
'''[[#2.3 Serverbefehle]] :'''<br />
 +
TIME (= Unterstützung einer Modellzeit) hinzugefügt
 +
 
 +
'''[[#2.4 Allgemeine Befehle]] :'''<br />
 +
Argument <group> hinzugefügt. Damit können Befehle und die Gerätegruppen auf die sie angewendet werden definiert werden. Die Abschnitte [[#5.1 Konfigurationstypen]] und [[#5.2 Befehl CONFGET]] wurden entsprechend angepasst.
 +
 
 +
'''[[#2.5 Protokolle Lokdekoder]] :'''<br />
 +
Das Protokoll PS (Protocol by Server) hinzugefügt.
 +
 
 +
'''[[#3.1 Lok- und Funktionsdekoder]] , [[#3.2 Schaltdekoder]] , [[#3.3 Rückmelde Module]] :'''<br />
 +
Parameter <name> an das Ende der Liste gerückt. <br />
 +
Soll kein Name angegeben werden, so ist das Wort "---" statt des Zeichens '-' zu verwenden. <br />
 +
Der Parameter <d_type> ist nicht mehr optional. <br />
 +
Soll keine Typkennung angegeben werden, so ist jetzt das Wort "---" zu verwenden.
 +
 
 +
'''[[#3.1 Lok- und Funktionsdekoder]] :'''<br />
 +
Beim Parameter <prog> wird nun das Zeichen '-' statt 'N' für eine nicht vorhandene Funktion verwendet. (besser zu erkennen) <br />
 +
Parameter <ps_addr> als Adresse für das "Protocol by Server" eingeführt. (Vorschlag Martin Ostermann) <br />
 +
Parameter <V_max> für eine virtuelle Höchstgeschwindigkeit eingeführt. <br />
 +
Die Funktionen werden jetzt im Parameter <func> detailiert beschrieben, (Vorschlag Martin Ostermann und Matthias Trute)
 +
 
 +
'''[[#4.1 Langtexte]] :'''<br />
 +
Dieser Abschnitt ist neu. Er definiert, was in Version 0.1 als Idee vorgeschlagen wurde. <br />
 +
Ziel ist eine Zuordnung zwischen Abkürzungen und Langtext einzuführen. Dies ist als Ergänzung zur Definition der Funktionen aus Abschnitt [[#3.1 Lok- und Funktionsdekoder]] notwendig geworden. Bei dieser Gelegenheit wurden gleich Definition für INFO und Sprache mit eingeführt. Die Abschnitte [[#5.1 Konfigurationstypen]] und [[#5.2 Befehl CONFGET]] wurden entsprechend angepasst.
 +
 
 +
'''[[#5.1 Konfigurationstypen]] , [[#5.2 Befehl CONFGET]] :'''<br />
 +
Diese Abschnitte wurden an die Änderungen in den Abschnitten [[#2 Servereigenschaften]] (Parameternamen, TIME, neue Parameter, neues Protokoll, ...), [[#3 Dekoder und Eigenschaften]] (Parameternamen, neue Parameter, Änderung von Parametern, neues Protokoll, ...), [[#4 Sonstiges]] (Zuordnung von Langtexten) angepasst.
 +
 
 +
Vieles an der internen Struktur vereinfacht, so dass dies Dokument jetzt etwas kleiner ist und damit schneller zu laden und darzustellen ist.
 +
|  bgcolor="#CC0000" |&nbsp;
 
|}
 
|}
  
 
[[Kategorie:SRCP]]
 
[[Kategorie:SRCP]]

Version vom 20. Februar 2006, 15:04 Uhr

Zweiter Entwurf zur Diskussion - 11.7.2000

von Edbert van Eimeren, Martin Ostermann, Matthias Trute


1 Einleitung

Die CRCF beschreiben einen Reihe von Dateien zur Konfiguration von Serverprozessen zur Steuerung von digitalen Modelleisenbahnen. Clientprozesse können auf diese Informationen über einen entsprechenden Auskunftsbefehl zugreifen.

Die in CRCF zu speichernden Informationen ergeben sich aus dem Bedarf des SRCP (Simple Railroad Command Protocol) wie von Torsten Vogt & anderen definiert. In diesem Sinne sind die CRCF eine Ergänzung zum SRCP.

Ziel ist es eine klare, auch vom Menschen lesbare Basis für die Fähigkeiten einer konkreten Serverimplementierung einerseits und eine Beschreibung der verwendeten Dekoder mit ihren spezifischen Eigenschaften andererseits zu schaffen.

Diese Fassung basiert auf SRCP Version 0.7.1.

 


1.1 Konventionen

Alle Informationen werden einzeilig mit variabler Länge gespeichert. Eine Zeile wird mit dem Zeichen '\n' (line feed, LF, #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return, CR, #13) wird akzeptiert. Jede Informationszeile besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.

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

Kommentarzeilen beginnen mit dem Zeichen '#' und enden mit dem Zeilenende. Sie werden ebenso ignoriert wie Leerzeilen (nur White Spaces und CR, LF). Sie dürfen alle druckbaren Zeichen des ASCII Zeichensatzes enthalten. Sie dienen ausschliesslich der besseren Lesbarkeit durch einen Menschen.

Einzelne Bereiche werden durch Überschriften getrennt. Diese beginnen (Zeilenanfang) mit '= ' und enden mit ' ='. Weiterer Text in der Überschriftzeile ist Kommentar und wird ignoriert.

Alle Informationszeilen beginnen mit einer Kennung aus vier Buchstaben, die die Art der Information kennzeichnet. Die weiteren Angaben sind je nach Art der Information unterschiedlich. Informationen über Protokolle enthalten eine weitere Angabe zur genauen Identifizierung (Protokoll/Modultyp). Informationen über Dekoder und Rückmelder enthalten zwei weitere Angaben zur genauen Identifizierung (Protokoll/Modultyp + Adresse/Portnummer). Für jede vom Server unterstützte Funktion / Eigenschaft gibt es eine Informationszeile. Für jeden dem Server bekannten Dekoder / Rückmelder gibt es eine Informationszeile.

Informationszeilen, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert. Eine (summarische) Fehlermeldung sollte in diesem Fall vom Server beim Start ausgegeben werden. In Protokoll- oder Trace-Dateien kann ggfs. jeder Fehler einzeln aufgeführt werden.

Die Informationen sind in Bereiche aufgeteilt. Jeder Bereich hat eine Überschrift. Alle Informationen aus einem Bereich müssen hinter dieser Überschrift stehen. Stehen sie an einer anderen Stelle, so werden sie als Fehler gewertet. Innerhalb eines Bereichs ist eine angemessene Ordnung sinnvoll (Name | Protokoll | Adresse | ...). Diese Ordnung ist für die bessere Lesbarkeit und daher nicht zwingend vorgeschrieben. Es steht im Ermessen des Erstellers, welche Ordnung, wenn überhaupt, er/sie benutzt.

An einigen Stellen sind Werte reserviert, die im SRCP noch nicht festgelegt sind, da es zur Zeit noch keine Server gibt, die das unterstützen. Diese Werte sind als Platzhalter zu betrachten, sie können sich noch ändern. Solche reservierten Werte sind mit kursiver Schrift markiert.

 

Änderungen gegenüber der vorherigen Version werden mit einem farbigen Strich am rechten Rand markiert. Dabei bedeutet rot Neues, grün wesentliche (inhaltliche) Änderungen, und blau Weglassungen. Alle geänderten Abschnitte sind grau hinterlegt. Dies gilt auch für Abschnitte mit textlichen Korrekturen, die keine extra Randmarkierung haben. Korrekturen von Tipfehlern werden nicht markiert.

 


2 Servereigenschaften

Hier werden die Eigenschaften beschrieben, die eine Serverimplementierung ausmachen, das heißt, welche Möglichkeiten ein Server seinen Clients zur Verfügung stellt.

 


2.1 Serverversion

Überschrift: '= Version ='

Es gibt genau eine Zeile mit den Informationen über die Version des Servers, des verwendeten SRCP und CRCF.

Format: VERS <name> <vers> SRCP <srcp> CRCF <crcf>

 
<name>
<vers>
<srcp>
Name des Servers
Version des Servers
Version des verwendeten SRCP
 
<crcf> Version des verwendeten CRCF  
Hinweis:

Die Versionsinformation sollte als erstes in einer Konfigurationsdatei stehen.

 


2.2 Übertragungskanäle

Welche Kanäle werden von einer Serverimplementierung zur Kommunikation mit Clients benutzt.
Dies ist durch das SRCP weitgehend festgelegt.

Überschrift: '= Ports ='

Format: PORT <port> <source>

 
<port> COMMAND

FEEDBACK

INFO
Kommando Port

Befehle des Clients an den Server, direkte Antworten des Servers darauf.
Rückmelde Port
Statusänderungen von Rückmelde Modulen.
Info Port (Broadcast Kanal)
Statusänderungen von Lok- und Schaltdekodern, Modellzeit.

 
<source> CLIENT
SERVER
BOTH
Unidirektional vom Client zum Server

Unidirektional vom Server zum Client
Bidirektional

 


2.3 Serverbefehle

Welche Befehle werden von einer Server zu seiner Steuerung akzeptiert.
Dies ist durch das SRCP weitgehend festgelegt.

Überschrift: '= Server Commands ='

Format: SCMD <command>

 
<command> LOGOUT
RESET
SHUTDOWN
Befehl zum Beenden der Verbindung zu einem Client.

Befehl zur Neu-Initialisieung des Servers.
Befehl zum Beenden des Servers.

 
  POWER

VOLTAGE

Digitalstrom über SET POWER [ON/OFF] ein-/ausschalten
Aktueller Befehl in SRCP (ab Version 0.???)
Digitalstrom über STARTVOLTAGE/STOPVOLTAGE schalten
Kompatibilität zu früheren Versionen des SRCP

 
  TIME Server unterstützt Modellzeit  


2.4 Allgemeine Befehle

Welche Befehle werden von einer Server zur Steuerung der Digitalanlage akzeptiert.
Dies ist durch das SRCP weitgehend festgelegt.

Überschrift: '= General Commands ='

Format: GCMD <command> <group>

 
<command> SET
GET
WAIT
INIT
TERM

Befehl zum Setzen eines Wertes.
Befehl zum Ermitteln eines Wertes.
Befehl zum Warten bis ein bestimmter Zustand erreicht wird.
Befehl zum Initialisieren von Geräte(gruppen).
Befehl zum Aufheben von mit INIT getroffenen Einstellungen.

 
  WRITE
READ
VERIFY

CONFGET

Befehl zum Programmieren eines Wertes eines Dekoders.
Befehl zum Lesen eines Wertes eines Dekoders.
Befehl zum Überprüfen eines Wertes eines Dekoders.

Befehl zum Ermitteln von Konfigurationsinformationen.

 
<group> GL
GA
FB
TIME
POWER

Generic Loco (Lokdekoder) [SET, GET, WRITE, READ, VERIFY]
Generic Acessory (Schaltdekoder) [SET, GET, WRITE, READ, VERIFY]
Feedback (Rückmelder) [GET, WAIT, INIT]
Zeitnormal (Modellzeit) [SET, GET, WAIT, INIT]
Energieversorgung der Modellanlage [SET, GET]

 
 

Beim Befehl CONFGET werden statt der Gerätegruppen die Konfigurationstypen als Argument verwendet. Siehe dazu den Abschnitt #5.1 Konfigurationstypen.

 

Eine Kombination Befehl - Argument, die nicht eingetragen ist, wird nicht unterstützt. Lediglich der Befehl SET ist zwingend vorgeschrieben, alle anderen können implementiert werden.
Der Befehl GET wird meistens unterstützt, der Befehl WAIT falls Rückmelder oder Modellzeit unterstützt werden. Die Befehle WRITE, READ, VERIFY dienen dem Programmieren von Dekodern. Sie werden nur dann unterstützt, wenn ein Server diese Funktionalität bereitstellt. Der Befehl CONFGET wird natürlich nur dann unterstützt, wenn ein Server das CRCF für die zentrale Konfiguration benutzt.

 


2.5 Protokolle Lokdekoder

Welche Protokolle für Lokdekoder werden von einem Server akzeptiert. (Funktionsdekoder werden wie Lokdekoder behandelt.)
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert.

Überschrift: '= Protocols Loco & Function ='

Format: PRGL <prot> <addr_max> <step_max> <dir> <nro_f>

 
<prot> M.
N.

Protokolle nach den Märklin/Motorola Standards.
Protokolle nach den NMRA-DCC Standards.

 
  PS Protocol by Server: Der Server wählt ein geeignetes Protokoll aus.  
  S.
F.
Z.

Protokolle nach den Trix Selectrix Standards.
Protokolle nach den Fleischmann FMZ Standards.
Protokolle nach den ZIMO Standards.

 
 

Der Punkt ist durch geeignete Buchstaben/Ziffern zu ersetzen. Siehe dazu die aktuelle Spezifikation des SRCP. Die Werte für Selectrix, FMZ und ZIMO sind reserviert für zukünftige Entwicklungen (Intellibox, Twin-Box, ...).

 
<addr_max>

Höchste Adresse, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind 80, 99, 256, 9999. Ein Adressbereich beginnt immer bei der Adresse 0.

 
<step_max>

Höchste Fahrstufen, die von diesem Protokoll unterstützt wird. Aktuelle Werte für die höchste Fahrstufe sind 14, 27, 28, 30, 128. Ein Fahrstufenbereich beginnt immer bei der Fahrstufe 0.

 
<dir> abs
rel
Absolute Fahrtrichtungsangabe.
Relative Fahrtrichtungsangabe.
 
<nro_f>

Zahl der Zusatzfunktionen, die von diesem Protokoll unterstützt werden. Aktuelle Dekoder untertützen 0, 2, 4, 8 Zusatzfunktionen. Es wird implizit davon ausgegeangen, dass eine Standardfunktion immer implementiert ist.

 


2.6 Protokolle Schaltdekoder

Welche Protokolle für Schaltdekoder werden von einem Server akzeptiert.
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert.

Überschrift: '= Protocols Accessory ='

Format: PRGA <prot> <addr_max>

 
<prot> M
N

Protokoll nach den Märklin/Motorola Standards.
Protokoll nach den NMRA-DCC Standards.

 
  S
F
Z

Protokoll nach den Trix Selectrix Standards.
Protokoll nach den Fleischmann FMZ Standards.
Protokoll nach den ZIMO Standards.

 
<addr_max>

Höchste Adresse, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind ???, 4096. Ein Adressbereich beginnt bei der Adresse 1.

 


2.7 Protokolle Rückmelde Module

Welche Rückmelde Module und Anschlussarten werden von einem Server akzeptiert.
Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Module oder Arten unterstützen. Weiter sind bereits Werte für noch nicht definierte Protokolle reserviert.

Überschrift: '= Feedback Types ='

Format: PRFB <module-type> <port_max> <port_inc>

 
<module-type> S88
I8255
M6051
Märklin s88-Bus am Parallelport des PC.
i8255 Karte.
Märklin s88-Bus via Interface 6051.
 
  LENZFB
LOCOFB
SELFB
FMZFB
ZIMOFB

Rückmelde-Module aus dem Lenz System.
Rückmelde-Module aus dem Digitrax System (LocoNet).
Rückmelde-Module aus dem Trix Selectrix System.
Rückmelde-Module aus dem Fleischmann FMZ System.
Rückmelde-Module aus dem ZIMO System.

 
  Hinweis: Die letzten fünf sind reservierte Namen, die sich ggfs. noch ändern können.  
<port_max>

Höchste Adresse, die für diesen Modultyp zulässig ist. Ein Nummerbereich beginnt mit (0 | 1) ???.

 
<port_inc> Anzahl der Ports, die in einem Modul dieses Typs zusammengefasst sind.  


2.8 Sonstige Gerätetypen

Dies kann erst dann spezifiziert werden, wenn entsprechende Definitionen in SRCP vorliegen.

 


3 Geräte und Eigenschaften

Hier werden die Eigenschaften beschrieben, die ein tatsächliches Gerät (Lok-, Schaltdekoder, Rückmelde Modul) hat. Das heißt, welche Funktionen von einem Dekoder oder Modul tatsächlich realisiert werden. Dies kann ggfs. weniger sein, als das Protokoll erlaubt. Weiter gibt es einige Parameter, die nur für die Clients von Interesse sind (<d_type>, <name>, ...). Solche Parameter stehen am Ende der Parameterliste.

 


3.1 Lok- und Funktionsdekoder

Überschrift: '= Locomotive & Function ='

Format: DCGL <prot> <addr> <step> <dir> <func> <prog> <ps_addr> <V_max> <d_type> <name>

 
<prot>

Wie im Abschnitt #2.5 Protokolle Lokdekoder definiert. Dekoder, die über mehrere Protokolle angesprochen werden können, haben für jedes Protokoll einen Eintrag. PS (Protocol by Server) ist hier nicht zulässig, da es sich um reale Dekoder handelt.

 
<addr>

Adresse dieses Dekoders unter dem gewählten Protokoll. Multiprotokoll-Dekoder dürfen für jedes Protokoll eine andere Adressen benutzen.

 
<step>

Höchste Fahrstufen, die von diesem Dekoder unterstützt wird. Für Funktionsdekoder ist dieser Wert ggfs. auf 0 zu setzen.

 
<dir> abs
rel
Absolute Fahrtrichtungsangabe.
Relative Fahrtrichtungsangabe.
 
<func>

Die Funktionen werden durch ein Wort <func> beschrieben, das aus Zeichenpaaren aufgebaut ist:
Das erste Zeichenpaar besteht aus zwei Ziffern und gibt die Zahl m der verfügbaren Funktionen inkl. der Standardfunktion an. Die Zeichenpaare 2 bis m+1 sind jeweils ein Kürzel für die Art der Verwendung der Funktionen F0 - Fn. [ m = n+1 ! ]. F0 ist dabei die Standardfunktion, F1 -Fn sind die Zusatzfunktionen. Das zweite Zeichenpaar bezeichnet also die Verwendung der Standardfunktion, das dritte der ersten Zusatzfunktion. Wird eine Funktion nicht benutzt so steht an der Stelle des Kürzels das Zeichenpaar '--'. Damit ist sowohl klar, wieviele Funktionen verfügbar sind, als auch, welche davon wirklich benutzt werden. Das minimale Wort für Funktion ist damit das Zeichenpaar '00' (keinerlei Funktion).
Den Kürzeln wird in der Tabelle FTXT ein Langtext zugeordnet. Siehe dazu den Abschnitt #4.1 Langtexte.

 
<prog> Der Wert von <prog> ist ein Wort mit 7 Buchstaben:  
  1)
2)
3)
4)

Modus (P = Programmiergleis, F = on the Fly [im Betrieb])
WRITE- Befehl (W = unterstützt)
READ- Befehl (R = unterstützt)
VERIFY-Befehl (V = unterstützt)

 
  5)
6)
7)
REGISTER (R = unterstützt)
VARIABLE (V = unterstützt)
BIT (B = unterstützt)
 
 

Wird eine Funktion nicht unterstützt, so ist statt dessen das Zeichen '-' (= none) zu setzen. Beispiele:
"PW--R--" Nur Register auf dem Programmiergleis schreiben.
"FWR-RV-" Register + Variablen im laufenden Betrieb lesen + schreiben.
"-------" Nicht über Digitalbefehle programmierbar.

 
<ps_addr>

Adresse, unter der dieser Dekoder mit "Protocol by Server" angesprochen wird. Dekoder, die über mehrere Protokolle / Adressen angesprochen werden, sollen jeweils die selbe PS-Adresse verwenden.
Durch <ps_addr> wird eine virtuelle Adresse definiert. Da im SRCP (ab 0.7.1) keine Beschränkung für die Größe einer Adresse besteht, kann man die in Deutschland ab Epoche IV übliche sechstellige Zahl für eine Lok verwenden. Dies völlig unabhängig davon, wieviel Adressen der Dekoder real unterstützt.

 
<V_max>

Virtuelle Höchstgeschwindigkeit: Dieser Wert wird in einem Server zusammen mit einem Wert V (<= V_Max) für die Soll-Geschwindigkeit dazu benutzt die reale Fahrstufe zu berechnen. Im SRCP wird keine Vorgabe über die Masseinheit dieses Wertes gemacht. Empfehlenswert ist eine Orientierung an der Vorbild-Geschwindigkeit, also in km/h.
Hinweis: Wird dieser Wert auf 0 gesetzt, so verwendet der Server den Wert von V als reale Fahrstufe.

 
<d_type>

Kennung für den Dekodertype: Dekoder eines Typs erhalten die gleiche Kennung. Die Kennung muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller.
Soll keine Kennung angegeben werden, ist statt dessen das Wort "---" zu verwenden.

 
<name>

Eindeutiger Name für diesen Lok-/Funktions-Dekoder: Der Name muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Beispiele: "V188-003", "Berghexe", "Zuckersusi".
Soll keine Name angegeben werden, ist statt dessen das Wort "---" zu verwenden.
Dekoder, die über mehrere Protokolle angesprochen werden können, dürfen den gleichen Namen verwenden.

 


3.2 Schaltdekoder

Überschrift: '= Accessory ='

Format: DCGA <prot> <addr_min> <addr_max> <d_type> <name>

 
<prot> Wie im Abschnitt #2.6 Protokolle Schaltdekoder angegeben.  
<addr_min> Adresse des ersten verwendeten Ausgang dieses Dekoders.  
<addr_max> Adresse des letzten verwendeten Ausgang dieses Dekoders.  
<d_type>

Kennung für den Dekodertype: Dekoder eines Typs erhalten die gleiche Kennung. Die Kennung muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller.
Soll keine Kennung angegeben werden, ist statt dessen das Wort "---" zu verwenden.

 
<name>

Eindeutiger Name für diesen Schaltdekoder: Der Name muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen . Beispiele: "Bahnhof-Links", "Gleis-1-2", "Abzweig-Abc".
Soll keine Name angegeben werden, ist statt dessen das Wort "---" zu verwenden.

 
Hinweis:

Für einen Einzeldekoder gilt <addr_min> = <addr_max> Auf diese Art kann je nach Wunsch eine Gruppendefiniton aller Ausgänge des Schaltdekoders oder eine Einzeldefinition eines Ausgangs erfolgen.

 


3.3 Rückmelde Module

Überschrift: '= Feedback Units ='

Format: DCGA <modul-type> <port_min> <port_max> <d_type> <name>

 
<modul-type> Wie im Abschnitt #2.7 Protokolle Rückmelde Module definiert.  
<port_min> Portnummer des ersten verwendeten Eingang dieses Modules.  
<port_max> Portnummer des letzten verwendeten Eingang dieses Modules.  
<d_type>

Kennung für den konkreten Typ eines Rückmelde Modules: Hier dient sie hauptsächlich zur Unterscheidung verschiedener Lieferanten eines Modultyps. Rückmelder eines Typs erhalten die gleiche Kennung. Die Kennung muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller.
Soll keine Kennung angegeben werden, ist statt dessen das Wort "---" zu verwenden.

 
<name>

Eindeutiger Name für dieses Rückmelde Modul: Der Name muss ein Wort sein. Das heisst es darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Beispiele: "GBM-Bonn", "GBM-Strecke", "Weichen-Bhf".
Soll keine Name angegeben werden, ist statt dessen das Wort "---" zu verwenden.

 
Hinweis: Mit <port_min> = <port_max> kann man ggfs. auch jeden Port einzeln definieren.  


4 Sonstiges

Dies ist der Platz für Festlegungen, die übergreifend sind.
Als erstes wird ein Bereich für die Zuordnung von Kurzformen zu Langtexten definiert.
Weitere übergreifende Funktionen folgen nach Bedarf.

 


4.1 Langtexte

Im Laufe der Diskussion um das CRCF hat sich gezeigt, dass es notwendig ist sowohl Kurzformen (=Abkürzungen), als auch Langformen (=Text) für bestimmte Informationen zur Verfügung zu stellen. Mit den Tabellen in diesem Abschnitt wird eine Zuordnung zwischen Abkürzungen und zugehörigen Text hergestellt.
Je nach Art der Information kann diese Tabelle zwingend sein, das heißt nur Werte in der Tabelle sind zulässig, oder optional, das heißt es können auch Abkürzungen verwendet werden, die nicht in der Tabelle enthalten sind.

Überschrift: '= Messages ='

Format: <TEXT-TYPE> <short> <lang> <freetext>

 
<TEXT-TYPE>

Kennung für die Art der Zuordnung.
Für den Befehl CONFGET ist dies ein Konfigurationstyp. (Siehe #5.1 Konfigurationstypen)

 
<short> Abkürzung,  
<lang>

Sprache (z.B. de := deutsch, en := englisch). Für <lang> werden die im Internet üblichen zwei Zeichen Abkürzungen verwendet.

 
 

Alle weiteren Worte in dieser Zeile sind dann der Meldungstext.
Die Reihenfolge innerhalb einer Tabelle ist ohne Bedeutung. Sinnvollerweise wird man jedoch die Einträge für eine Sprache zusammenhalten und alphabetisch nach den Kürzeln sortieren.

 
Bisher sind die folgenden Zuordnungstabellen definiert.  
  FTXT <short> <lang> <freetext> (Funktionen in Lokdekodern)

ITXT <short> <lang> <freetext> (INFO liefert eine Zahl zurück)
LTXT <short> <lang> <freetext> (Zuordnung der Sprachen)

FTXT ist eine optionale Tabelle, insbesondere werden in verschiedenen Sprachen unterschiedliche Abkürzungen verwendet.
ITXT und LTXT sollen vollständig sein.

 
Einige Beispiele mögen zur Verdeutlichung dienen.  
 

FTXT <short> <lang> <freetext> (Funktionen in Lokdekodern)

 FTXT    Da    de    Dampf
 FTXT    Sl    de    Spitzlicht
 FTXT    Pf    de    Pfeife
 FTXT    Gl    de    Glocke
 FTXT    Tl    de    Triebwerksbeleuchtung
 FTXT    Lu    de    Lüfter
 FTXT    Sa    de    Stromabnehmer
 	...
 FTXT    ST    en    Steam         (Dampf)
 FTXT    Hl    en    Headlight     (Spitzlicht)
 FTXT    Wh    en    Whistle       (Pfeife)
 FTXT    Bl    en    Bell          (Glocke)
 FTXT    Nb    en    Numberboard   (Nummerntafel)
 ...

ITXT <short> <lang> <freetext> (INFO liefert eine Zahl zurück)

 ITXT    -1    de    nicht unterstützt
 ITXT    -2    de    keine Daten
 ITXT    -3    de    Zeitlimit überschritten

 ITXT    -1    en    unsupported
 ITXT    -2    en    no data
 ITXT    -3    en    timeout

LTXT <short> <lang> <freetext> (Zuordnung der Sprachen)

 LTXT    de    de    deutsch
 LTXT    en    de    englisch
 LTXT    fr    de    franzoesisch
 
 LTXT    en    en    english
 LTXT    fr    en    french
 LTXT    de    en    german
 
 LTXT    en    fr    anglais
 LTXT    fr    fr    francais
 LTXT    de    fr    allemand
 


5 Abfrage der Konfiguration

Der Befehl CONFGET dient dazu, Clients die Möglichkeit zu geben beim Server nachzufragen, welche Fähigkeiten er hat (Siehe #2 Servereigenschaften). Diese Angaben sind verbindlich.

Als zweites kann mit diesem Befehl abgefragt werden, welche Lok-, Funktions-, Schalt-Dekoder und Rückmelde Module dem Server bekannt sind. (Siehe #3 Geräte und Eigenschaften) Diese Information dient (mehreren) Clients dazu einen gleichen Informationsstand zu haben. Diese Informationen sind jedoch nicht verbindlich.

  • Die Informationen müssen nicht vollständig sein.
  • Nicht alle bekannten Loks müssen sich auf einer Anlage befinden.
  • Es können sich "Fremdloks" auf der Anlage befinden, die natürlich nicht in der Konfigurationsdatei beschrieben sind.

Informationen zu Schaltdekodern und Rückmeldern als ortsfeste Bauteile hingegen sollten (in der Regel) korrekt und vollständig sein.

 
Anmerkungen:

Die Spezifikation des Befehl CONFGET gehört eigentlich in das SRCP (Simple Railroad Command Protocol). Da der Befehl CONFGET jedoch unmittelbar von den Festlegungen im CRCF abhängt, wird er vorerst hier beschrieben. Der Befehl CONFGET hat nur dann Sinn, wenn die Konfigurations Dateien existieren und nach dem CRCF gestaltet sind.

Ein Befehl CONFSET zum Setzen von Konfigurations Informationen ist zur Zeit nicht definiert. Es ist nicht klar, ob dafür ein Bedarf existiert. Wie auch immer, sinnvoll wäre ein solcher Befehl nur für die Informationen zu Lokdekodern wie sie in #3.1 Lok- und Funktionsdekoder festgelegt sind. Die Servereigenschaften (siehe #2 Servereigenschaften) ändern sich nicht, solange ein Server läuft. Auch die Angaben zu einer (zukünftigen) Beschreibung des Anlagenlayouts ändern sich nicht während des laufenden Betriebs. Ein Lok jedoch kann ohne weiteres hinzugefügt, entfernt oder umprogrammiert werden.

 


5.1 Konfigurationstypen

Zur Zeit sind folgende Konfigurationstypen definiert. Sie sind hier zusammen mit ihren Parametern aufgelistet. Parameter, die zur genaueren Identifikation dienen, sind unterstrichen.

 
  VERS
PORT
SCMD
<name> <vers> SRCP <srcp> CRCF <crcf>
<port> <source>
<command>
 
  GCMD <command> <group>  
  PRGL
PRGA
PRFB

<prot> <addr_max> <step_max> <dir> <nro_f>
<prot> <addr_max>
<module-type> <port_max> <port_inc>

 
  DCGL
DCGA
DCFB

<prot> <addr> <step> <dir> <func> <prog> <ps_addr> <V_max> <d_type> <name>
<prot> <addr_min> <addr_max> <d_type> <name>
<module-type> <port_min> <port_max> <d_type> <name>

 
  FTXT
ITXT
LTXT

<short> <lang> <freetext>
<short> <lang> <freetext>
<short> <lang> <freetext>

 

Dabei haben die ersten drei [Servereigenschaften] keine weitere Identifikation.
GCMD [allgemeine Befehle] hat Befehl und Gerätegruppe als genauere Identifikation.
Die nächsten drei [Protokolle] haben Protokoll/Modultyp als genauere Identifikation.
Die folgenden drei [Dekoder/Rückmelder] haben Protokoll/Modultyp + Adresse/Portnummer als genauere Identifikation.
Die letzten drei [Textzuordnung] haben Kürzel und Sprache als genauere Identifikation.

 


5.2 Befehl CONFGET

Das generelle Format des Befehls ist:  
  CONFGET <conf-type> [<spec_1>] [<spec_2>]  

Der Wert von <conf-type> ist der Typ der Information der angefordert wird (vier Zeichen Code). Dahinter steht jeweils, was zur genaueren Identifikation benutzt wird :

 
 

VERS, PORT, SCMD,
PRGL, PRGA, PRFB,
GCMD
DCGL, DCGA, DCFB,
FTXT, ITXT, LTXT

Servereigenschaften
unterstützte Protokolle [Protokoll/Modultyp]
unterstützte Befehle [Befehl] [Gerätegruppe]
Dekoder, Rückmelder [Protokoll/Modultyp] [Adresse/Portnummer]
Zuordnung Langtext [Kürzel] [Sprache]

 

[<spec_1>] und [<spec_2>] dienen zur genaueren Identifikationen von Befehlen, Langtext, Protokollen, Dekodern und Rückmeldern :

 
 

Protokoll/Modultyp
Befehl + Gerätegruppe
Protokoll + Adresse
Protokoll + Portnummer
Modultyp + Portnummer
Kürzel + Sprache

für Protokolle, (PRGL, PRGA, PRFB)
für allgemeine Befehle, (GCMD)
für Lokdekoder, (DCGL)
für Schaltdekoder, (DCGA)
für Rückmelder. (DCFB)
für Langtext, (FTXT, ITXT, LTXT)

 
  Für die anderen Informationenstypen sind sie ohne Belang.  
Hinweis:

Für [<spec_1>], [<spec_2>] kann ein '*' als Wildcard verwendet werden. Als Beispiel liefert "CONFGET GCMD * FB" alle Befehle zurück, mit denen Rückmelder angesprochen werden.
Bei VERS, PORT und SCMD werden grundsätzlich alle zugehörigen Infozeilen zurück geliefert.

 


5.3 Antwort auf CONFGET

Das generelle Format der Antwort ist:  
  INFO CONF <conf-type> [<spec_1>] [<spec_2>] [.*]

[.*] steht dabei für alle weiteren Angaben entsprechend dem Konfigurationstyp.

 

Wird der Befehl CONFGET nicht unterstützt, lautet die Antwort: INFO -1
Sind keine Daten zu <conf-type> oder [<spec_x>] vorhanden, ist die Antwort: INFO -2

 
Hinweise:

[<conf-type>] ist wie im Abschnitt #5.1 Konfigurationstypen definiert.
[<spec_1>] und [<spec_2>] sind wie im Abschnitt #5.2 Befehl CONFGET definiert.
Die Antwort auf einen Befehl CONFGET kann mehrere Zeilen "INFO CONF ..." umfassen. Ein Client muss darauf vorbereitet sein, diese sinnvoll zu verarbeiten.

 


6 Zukünftige Entwicklungen

Auf der Basis des SRCP sind ja schon viele Entwicklungen angedacht. Hier ist der Platz um ihr Informationsbedürfnis festzulegen. Denkbar sind z.B Beschreibung einer Anlage und ihrer logischen Struktur (Blöcke, Fahrstrassen, Besetztmelder, ...) oder Informationen für den Fahrplanbetrieb (Züge, Fahrstrecke, Fahrzeittrassen, ...) und vieles andere.

 


7 Einige Anmerkungen

Hier will ich kurz Erklärungen zu einigen von mir vorgeschlagenen Punkten geben.  


7.1 Hintergrund

In der Diskussion um das SRCP wurde mehrfach der Wunsch nach einer Datei für die Konfiguration geäussert. Dies ist für eine einzige Serverimplementierung sicher nicht zwingend. Werden jedoch unterschiedliche Server angeboten, so ist es für alle weiteren Programme (Clients, Middleware, ...) sinnvoll, die Eigenschaften eines Servers ermitteln zu können.

Weiter wurde angeregt eine gemeinsame Datenbasis für alle Clients bezüglich Lokdekoder, Schaltdekoder und Rückmelder zu haben. Diese Datenbasis, soll ebenso wie die Informationen über die Eigenschaften des Servers über einen SRCP-konformen Befehl abgefragt werden können.

Diesen Wünschen soll mit dieser Definition Rechnung getragen werden.

 


7.2 Aufteilung

Bisher ist nichts zur Aufteilung der Konfigurationsdaten auf Dateien gesagt worden. Dieser Punkt ist bewusst offengelassen, da ich dafür keinen Vorschlag machen will. Sinnvoll ist sicherlich eine Aufteilung in eine Datei für die Servereigenschaften (siehe #2 Servereigenschaften) und eine Datei für die Dekoder und Rückmelder (siehe #3 Geräte und Eigenschaften). Sollte eines Tages Informationen über das Layout einer Modellbahn Anlage definiert werden, so ist dafür ebenso eine weitere Datei sinnvoll.

Ob eine weitere Aufteilung wünschenswert ist soll die Diskussion zeigen.
Um Namensvorschläge wird gebeten!

 


7.3 Namen und Typen

Für die Definition der Dekoder und Rückmelder sind Namen eingeführt worden. Dies ist ein Konzept, dass im SRCP bisher nicht existiert und dort auch nicht notwendig ist. Es dient dazu, dass alle Clients Dekoder und Rückmelder mit gleichen Namen darstellen können.
Namen wie "V188-003" oder "Abzweig-Valkenburg" sind für einen Mensch als Benutzer der Clients sicherlich einfacher zuzuordnen als M3-17 oder N-327.

Ebenso sind Typen zur Klassifizierung verschiedener Dekoder- / Rückmeldertypen eingeführt worden. Auch diese sind in SRCP weder definiert noch notwendig. Sie dienen hauptsächlich der Dokumentation. Inwieweit ein Client diese Information verwendet bleibt ihm überlassen.

 


7.4 Englische Begriffe

Genauso wie im SRCP werden in der formalen Definition englische Begriffe bzw. Abkürzungen davon verwendet. Dies wurde in SRCP in Hinblick auf eine mögliche internationale Verbreitung so beschlossen. Ich schliesse mich diesem Vorgehen an.

 


8 Änderungsprotokoll

Änderungen von CRCF 0.1 nach CRCF 0.2.0

#2 Servereigenschaften , #3 Geräte und Eigenschaften :
Einige Parameternamen geändert: Das Zeichen '-' durch '_' ersetzt, sowie in einigen Parameternamen das Zeichen '_' eingefügt. Die Abschnitte #5.1 Konfigurationstypen und #5.2 Befehl CONFGET wurden entsprechend angepasst.

#2.1 Serverversion :
Angabe der verwendeten CRCF Version hinzugefügt

#2.3 Serverbefehle :
TIME (= Unterstützung einer Modellzeit) hinzugefügt

#2.4 Allgemeine Befehle :
Argument <group> hinzugefügt. Damit können Befehle und die Gerätegruppen auf die sie angewendet werden definiert werden. Die Abschnitte #5.1 Konfigurationstypen und #5.2 Befehl CONFGET wurden entsprechend angepasst.

#2.5 Protokolle Lokdekoder :
Das Protokoll PS (Protocol by Server) hinzugefügt.

#3.1 Lok- und Funktionsdekoder , #3.2 Schaltdekoder , #3.3 Rückmelde Module :
Parameter <name> an das Ende der Liste gerückt.
Soll kein Name angegeben werden, so ist das Wort "---" statt des Zeichens '-' zu verwenden.
Der Parameter <d_type> ist nicht mehr optional.
Soll keine Typkennung angegeben werden, so ist jetzt das Wort "---" zu verwenden.

#3.1 Lok- und Funktionsdekoder :
Beim Parameter <prog> wird nun das Zeichen '-' statt 'N' für eine nicht vorhandene Funktion verwendet. (besser zu erkennen)
Parameter <ps_addr> als Adresse für das "Protocol by Server" eingeführt. (Vorschlag Martin Ostermann)
Parameter <V_max> für eine virtuelle Höchstgeschwindigkeit eingeführt.
Die Funktionen werden jetzt im Parameter <func> detailiert beschrieben, (Vorschlag Martin Ostermann und Matthias Trute)

#4.1 Langtexte :
Dieser Abschnitt ist neu. Er definiert, was in Version 0.1 als Idee vorgeschlagen wurde.
Ziel ist eine Zuordnung zwischen Abkürzungen und Langtext einzuführen. Dies ist als Ergänzung zur Definition der Funktionen aus Abschnitt #3.1 Lok- und Funktionsdekoder notwendig geworden. Bei dieser Gelegenheit wurden gleich Definition für INFO und Sprache mit eingeführt. Die Abschnitte #5.1 Konfigurationstypen und #5.2 Befehl CONFGET wurden entsprechend angepasst.

#5.1 Konfigurationstypen , #5.2 Befehl CONFGET :
Diese Abschnitte wurden an die Änderungen in den Abschnitten #2 Servereigenschaften (Parameternamen, TIME, neue Parameter, neues Protokoll, ...), #3 Dekoder und Eigenschaften (Parameternamen, neue Parameter, Änderung von Parametern, neues Protokoll, ...), #4 Sonstiges (Zuordnung von Langtexten) angepasst.

Vieles an der internen Struktur vereinfacht, so dass dies Dokument jetzt etwas kleiner ist und damit schneller zu laden und darzustellen ist.