|
|
| Zeile 1: |
Zeile 1: |
| − | ''' Torsten Vogt, Martin Ostermann, Kurt Haders, Olaf Schlachter, Matthias Trute, Tobias Schlottke, Edbert van Eimeren, Stefan Bormann, Michael Reukauff '''
| + | ..hier kommt erstmal die Beta-Version für die neue Gleisübersicht hin, bevor es der alten an den Kragen geht. Das Radienangebot muss da imho nicht rein, da zur Not durch Flexgleise lösbar. |
| | | | |
| − | Juli 2000
| + | Zu den Weichentypen: |
| | + | EW = Einzelweiche oder "normale" Weiche, angegeben ist der Winkel und der Abzweigradius. |
| | + | BW = Bogenweiche, angegeben ist der Winkel und der innere Radius. Das äußere ist idr. einfach ein um einen Parallelgleisabstand verschobener identischer Bogen. |
| | + | DKW = Doppelkreuzweiche, angeben ist der Winkel und die Länge, stellenweise auch der Radius (r=). |
| | + | EKW = Einzelkreuzweiche, angeben ist der Winkel und die Länge, stellenweise auch der Radius (r=). |
| | + | DWW = versetzte Dreiwegweiche, angegeben ist der Winkel und der Abzweigradius. |
| | + | S-DWW = symmetrische Dreiwegweiche, angegeben ist der Winkel und der Abzweigradius. |
| | + | ABW = Außenbogenweiche oder Y-Weiche, angegeben ist der Winkel und der Abzweigradius. |
| | | | |
| | + | Für Räder nach NEM 311 taugen derzeit (noch?) alle käuflichen Gleissysteme. |
| | | | |
| − | | + | {|border="1" |
| − | == 1. Einleitung ==
| + | !Hersteller, Produkt |
| − | | + | !Tauglichkeit RP25 Code 110 / NEM 311.1 |
| − | Das SRCP beschreibt einen Befehlssatz zur Client-Server-Kommunikation zwischen Serverprozessen zur Steuerung von digitalen Modelleisenbahnen und deren Clients. Serverprozesse sind entweder Software-Signalgeneratoren oder Treiber für HW-Interfaces. Clients sind typischerweise Steuerungsprogramme.
| + | !Tauglichkeit RP25 Code 88 |
| − | | + | !Parallel- gleis- abstand |
| − | Der SRCP-Befehlssatz besteht aus Kommandos, die direkt das Verhalten des Servers betreffen und aus Kommandos, die für die Dekoder der Modellbahnanlage bestimmt sind. Weiterhin werden Kommandos, die die Verarbeitung von Rückmeldungen betreffen spezifiziert.
| + | !Weichensortiment |
| − | | + | !Bemerkungen |
| − | Der Server kann über ein Zeitgebermodul verfügen, das alle Clients mit einer einheitlichen Modellzeit versorgen kann.
| + | |- |
| − | | + | !colspan="6"|Profilhöhe 2,7mm |
| − | | + | |- |
| − | === 1.1 Konventionen ===
| + | |Fleischmann Modellgleis |
| − | | + | |mit Einknicken |
| − | Die Übertragung der Kommandos von den Clients zum Server erfolgt via tcp/ip. Alle Kommandos werden mit dem Zeichen '\n' (line feed (LF), #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return (CR), #13) wird akzeptiert. Jedes Kommando besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.
| + | |nur große Weiche |
| − | | + | |58mm |
| − | Die Worte der Kommandos können aus der Menge der Zeichen { "0".."9", "*", "-", "A".."Z", "a".."z" } gebildet werden.
| + | |BW 36°/357mm<br/> EW/DWW 15°/357mm<br/> EW 15°/738mm<br/> DKW 15°/219,5mm |
| − | | + | |sehr hohes und breites Messingprofil, sehr enge Radien auch und gerade der Weichen. Bewegliche Herzstücke bei den größeren Weichen. Zahnstange zum Nachrüsten. |
| − | Der Server wertet die Kommandos case-sensitive aus, d.h. zwischen Groß- und Kleinbuchstaben wird unterschieden.
| + | |- |
| − | | + | !colspan="6"|Profilhöhe 2,5mm |
| − | Zahlen sind Ganzzahlen. Eine Beschränkung des Wertebereiches besteht nicht generell.
| + | |- |
| − | | + | |Fleischmann Profi-Gleis |
| − | Kommandos, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert.
| + | |mit Einknicken |
| − | | + | |nein |
| − | | + | |63,5mm |
| − | === 1.2 Übertragungskanäle === | + | |BW 36°/356mm<br/> EW, S-DWW 18°/647mm<br/> EW 18°/?<br/> DKW 18°/200mm |
| − | | + | |Angespritztes, flaches Schotterbett. Sehr breites Profil. Bewegliche Herzstücke bei den größeren Weichen. Zahnstange zum Nachrüsten. |
| − | Ein SRCP-konformer Server stellt den Clients drei Ports zur Verfügung.
| + | |- |
| − | | + | |Mehano Hobbygleis |
| − | # Kommandoport
| + | |mit Einknicken |
| − | # Rückmeldepollport
| + | |nein |
| − | # Informationsport
| + | |nur ein Radius |
| − | | + | |EW 20°/457mm |
| − | Der Kommandoport dient den Clients dazu, dem Server Kommandos übermitteln. Der Server versucht die Kommandos auszuführen. Bei manchen Kommandos erwartet der Client eine Antwort. Die Antwort des Servers wird ebenfalls über den Kommandoport abgewickelt.
| + | |Nur ein rudimentäres Grundsortiment. Wurde einige Zeit (zwischen Hohlprofil und A-Gleis) auch von Piko angeboten. |
| − | | + | |- |
| − | Der Rückmeldepollport wird nur unidirektional vom Server zum Client benutzt. Meldet sich ein Client am Rückmeldepollport an, so sendet der Server jede Statusänderung einer Rückmeldeeinheit an den Client zurück. Mit diesem Mechanismus ist es möglich, Rückmeldungen beim Client ereignisgesteuert zu bearbeiten.
| + | |Peco Streamline |
| − | | + | |mit Einknicken |
| − | Auch der Informationsport wird nur unidirektional von Server zu den Clients benutzt. Er ist eine Art Broadcast-Kanal, der ständig vom Server mit Statusänderungen von Lokdekodern und Schaltdekodern gefüttert wird. Er dient dem asynchronen Abgleich mehrerer Clients am selben Server.
| + | |nein |
| − | | + | |52mm |
| − | Der Server bestimmt die Portnummern. Standardportnummer für den Kommandoport ist 12345. Der Rückmeldepollport und der Informationsport sind die beiden unmittelbar folgenden Portnummern. Standardmässig ergeben sich somit folgende Portnummern:
| + | |EW 12°/610mm<br/> EW 12°/914mm<br/> EW 12°/1219mm<br/> S-DWW 12°/914mm<br/> ABW12°/1828mm<br/> ABW 24°/610mm<br/> DKW 12°/r=800mm<br/> echte BW 12°/762mm |
| − | | + | |Typisch englischer, enger Gleisabstand, sehr viele Weichentypen. Die Weichen sind mechanisch und elektrisch leicht problematisch. Nur Flexgleis (Hold und Beton) |
| − | * Kommandoport : 12345
| + | |- |
| − | * Rückmeldepollport: 12346
| + | |Piko A-Gleis |
| − | * Informationsport : 12347
| + | |mit Einknicken |
| − | | + | |nein |
| − | Nimmt ein Client zum Kommandoport Kontakt auf, muß der Server zunächst einen einzeiligen Informationstext über diesen Port zum Client schicken. Dieser Text sollte den Namen des Servers, dessen Versionsnummer und die implementierte SRCP-Version enthalten.
| + | |61,9mm |
| − | | + | |EW, ABW 15°/908mm<br/> BW 30°/422mm<br/> BW 30°/484mm<br/> DKW 15°/231mm |
| − | Beispiel:
| + | |Extrem preisgünstiges Gleis. |
| − | | + | |- |
| − | ----
| + | |Roco 2,5mm |
| − | erddcd v0.9.511; SRCP 0.5.0
| + | |mit Einknicken |
| − | ----
| + | |nein |
| − | | + | |57mm |
| − | Anschliesend wartet der Server auf Kommandos des Client. Der Client muß den Informationstext lesen und kann nun seinerseits Kommandos an den Server schicken.
| + | |EW/<s>S-DWW</s> 12,5°/700mm<br/> <s>EW9,5°/1010mm<br/> DKW 12,5°/228mm</s><br/> BW 30°/457mm. |
| − | | + | |Wird seit Jahren systematisch reduziert. |
| − | | + | |- |
| − | | + | |Tillig Standard |
| − | == 2. Allgemeine Kommandos zur Serversteuerung ==
| + | |mit Einknicken |
| − | | + | |nein |
| − | Kommunikationsports
| + | |55mm |
| − | | + | |EW, DWW, ABW, DKW 15°/600mm<br/> EW 7,5°/800mm<br/> echte BW 30°/435mm |
| − | * Client -> Server: Kommandoport
| + | |Großes Angebot an Weichen. Herzstücke nicht sehr schön. Durch die Möglichkeit Weichen und Gleise selbst zu montieren sehr preiswert. Flexgleis Holz, Beton und Stahl. |
| − | * Server -> Client: entfällt
| + | |- |
| − | | + | !colspan="6"|Profilhöhe 2,1mm |
| − | Kommandos
| + | |- |
| − | | + | |RocoLine |
| − | * SHUTDOWN : Der Server beendet sich
| + | |mit Einknicken, kleine Bogenweiche nicht |
| − | * LOGOUT : Dem Server wird angzeigt, dass sich ein Client ausloggt
| + | |nein |
| − | * RESET : Der Server re-initialisiert sich
| + | |62mm |
| − | | + | |EW, DWW 15°/874mm<br/> EKW, DKW 15°/r=531mm<br/> EW 10°/1946mm<br/> EKW, DKW 10°/959<br/> BW 30°/358mm<br/> BW 30°/543mm<br/> BW 30°/826mm |
| − | Folgende Kommandos sind von Clients nicht mehr zu verwenden, müssen vom Server jedoch implementiert werden
| + | |Bettung inzwischen nicht mehr abgeboten, Einlagen für RP25 verfügbar. |
| − | | + | |- |
| − | * STARTVOLTAGE identisch mit SET POWER ON
| + | |Roco GeoLine |
| − | * STOPVOLTAGE identisch mit SET POWER OFF
| + | |mit Einknicken |
| − | | + | |nein |
| − | | + | |76,5mm |
| − | | + | |EW, DWW, DKW 22,5°/502,7mm<br/> BW 30°/434,5mm |
| − | == 3. Kommandos zur Digitalsteuerung ==
| + | |Angespritztes Schotterbett mit Hohlraum unter dem Gleis, (viel zu) riesiger Parallelgleisabstand, nur sehr enge Weichen. |
| − | | + | |- |
| − | === 3.1 Befehle und Gerätegruppen ===
| + | |Tillig Elite |
| − | | + | |ja |
| − | SRCP definiert 8 generelle Befehle, die über den Kommandoport abgewickelt werden.
| + | |"Spurführung durch Wegsehen" |
| − | | + | |59mm |
| − | ; '''SET'''
| + | |EW 15°/484mm<br/> EW 15°/866mm<br/> EW 12°/1350mm<br/> ABW 15°/1739mm<br/> ABW 12°/2707mm<br/> EKW, DKW 15°/r=484mm<br/> EKW, DKW 15°/r=1050mm<br/>echte BW 29,3°/377mm<br/>echte BW 30°/425mm<br/>echte BW 32°/484mm<br/>echte BW 29°/543mm<br/> EW 9,4°/2200mm<br/> EW 6,34°/2200mm<br/> ABW 9,4°/4403mm<br/> ABW 6,34°/4403mm |
| − | : Setzt einen Wert vom Client über den Server zum Gerät.
| + | |Schienen brüniert, großes Angebot an teilweise riesigen Weichen-Typen. Durch Selbstbau von Weichen und Gleisen relativ preiswert. Gelenklose Zungen (==> Motorantrieb) und sehr feine Herzstücke. Weichen in Grenzen flexibel. Elektrisch (wie auch Peco) problematisch. Nicht für fliegenden Aufbau nutzbar, da die Weichen einen Antrieb erzwingen und es kaum Fertigkurven gibt. Flexgleis Holz, Beton und Stahl. Dreischienengleise und -Weichen für H0/H0m und H0/H0e. |
| − | ; '''GET'''
| + | |- |
| − | : Ermittelt den aktuellen Zustand eines Gerätes.
| + | |Trix C-Gleis |
| − | ; '''WAIT'''
| + | |mit Einknicken |
| − | : Wartet, bis ein Gerät einen bestimmten Zustand erreicht hat.
| + | |nein |
| − | ; '''INIT'''
| + | |77,5mm (bei größeren Radien: 64,3mm) |
| − | : Falls Geräte explizit initialisiert werden müssen.
| + | |EW, DKW 24,3°/437mm<br/> BW 30°/360mm<br/> EW 12,1°/1114,6mm |
| − | ; '''TERM'''
| + | |Angespritztes Schotterbett mit Hohlraum unter dem Gleis, (viel zu) riesiger und schwankender Parallelgleisabstand, nur sehr enge Bogenweichen, sehr sichere Verbindung. '''kein Flexgleis'''. |
| − | : Falls die mit INIT getroffenen Einstellungen wieder entfernt werden sollen.
| + | |- |
| − | ; '''READ'''
| + | !colspan="6"|Profilhöhe 1,9mm |
| − | : Liest einen Wert aus, Ergänzung zum WRITE
| + | |- |
| − | ; '''WRITE'''
| + | |Peco Finescale |
| − | : Setzt einen Wert vom Client und liefert eine Antwort (Quittung) zurück.
| + | |ja |
| − | ; '''VERIFY'''
| + | |? |
| − | : Überprüft, ob ein Wert einen bestimmten Wert hat.
| + | |52mm |
| − | | + | |EW 12°/610mm<br/> EW 12°/914mm<br/> EW 12°/1219mm<br/> DWW 12°/914mm<br/> ABW 12/1829mm<br/> ABW 24°/610mm<br/> EKW, DKW 12°/800mm<br/> echte BW 12°/762mm |
| − | Geräte entstammen den Gerätegruppen Lokdekoder, Schaltdekoder, Rückmeldeeinheiten und sonstigen Bereichen.
| + | |Typisch englischer, enger Gleisabstand, sehr viele Weichentypen. Die Weichen sind mechanisch und elektrisch leicht problematisch. Dieses Gleissystem ist eher für den fortgeschrittenen Modellbahner. Nur Flexgleis (Holz und Beton). |
| − | | + | |- |
| − | Über Parameter wird festgelegt, auf welche Gerätegruppe sich ein Befehl bezieht. Der erste Parameter legt immer die Gerätegruppe fest:
| + | |} |
| − | | + | |
| − | Die Befehle WRITE, VERIFY und READ sind für die Verwendung von Programmierinterfaces (Dekoder) vorgesehen.
| + | |
| − | | + | |
| − | ; '''GL'''
| + | |
| − | : Lok- und Funktionsdekoder (generic loco)
| + | |
| − | ; '''GA'''
| + | |
| − | : Schaltdekoder (generic accessory)
| + | |
| − | ; '''FB'''
| + | |
| − | : Rückmeldeeinheit (feedback)
| + | |
| − | ; '''TIME'''
| + | |
| − | : Zeitnormal
| + | |
| − | ; '''POWER'''
| + | |
| − | : Energieversorgung der Modellanlage
| + | |
| − | | + | |
| − | Anwendbarkeit der Befehle auf Gerätegruppen:
| + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | | SET GET WAIT INIT TERM
| + | |
| − | ---+----------------------------
| + | |
| − | |
| + | |
| − | GL | x x - - -
| + | |
| − | |
| + | |
| − | GA | x x - - -
| + | |
| − | |
| + | |
| − | FB | - x x x -
| + | |
| − | |
| + | |
| − | TIME | x x x x -
| + | |
| − | |
| + | |
| − | POWER | x x - - -
| + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | Bei den Befehlen GET und WAIT erwartet der Client vom Server eine Antwort. Es kann nun vorkommen, daß der Server zur gestellten Anfrage keine Antwort geben kann. In diesen Fällen muß der Server eine Zeichenkette zum Client senden, die folgendem Format genügt:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO <error code> \n
| + | |
| − | ----
| + | |
| − | | + | |
| − | Als "error code" muß eine negative Zahl übergeben werden. Folgende Konventionen gelten:
| + | |
| − | | + | |
| − | INFO -1 ==> Befehl wird nicht unterstützt (not supported)
| + | |
| − | | + | |
| − | INFO -2 ==> Keine Information vorhanden (no data)
| + | |
| − | | + | |
| − | INFO -3 ==> Zeitlimit überschritten (vgl. WAIT) (timeout)
| + | |
| − | | + | |
| − | | + | |
| − | === 3.2 Weitere Befehlsparameter ===
| + | |
| − | | + | |
| − | Die weiteren Befehlsparameter legen genau fest, welches konkrete Gerät und welche Eigenschaften beeinflußt oder abgefragt werden sollen.
| + | |
| − | | + | |
| − | | + | |
| − | ==== Befehlsparameter des Befehls SET ====
| + | |
| − | | + | |
| − | <a name="SET GL"></a>
| + | |
| − | ===== Gerätegruppe GL =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | SET GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: entfällt
| + | |
| − | | + | |
| − | Bedeutung der Argumente:
| + | |
| − | | + | |
| − | ; '''protocol'''
| + | |
| − | : M1, M2, M3, M4, MF, NB, N1, N2, N3, N4, PS
| + | |
| − | :* M1: Märklin alt (rel. FRU, 80 Adr., 1 Funkt., 14 FS)
| + | |
| − | :* M2: Märklin neu (abs. FRU, 80 Adr., 5 Funkt., 14 FS)
| + | |
| − | :* M3: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 28 FS)
| + | |
| − | :* M4: M2 erweitert (abs. FRU, 256 Adr., 5 Funkt., 14 FS)
| + | |
| − | :* M5: M2 erweitert nach Märklin (abs. FRU, 80 Adr, 5 Funkt., 27 FS)
| + | |
| − | :* MF: altes Märklin Format für Funktionsdekoder
| + | |
| − | :* NB: NMRA-DCC Basisprotokoll (abs. FRU, 7-bit-Adr., 14 FS)
| + | |
| − | :* N1: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5/9/13 Funkt., 28 FS)
| + | |
| − | :* N2: NMRA-DCC erweitert (abs. FRU, 7-bit-Adr., 5/9/13 Funkt., 128 FS)
| + | |
| − | :* N3: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr.,5/9/13 Funkt., 28 FS)
| + | |
| − | :* N4: NMRA-DCC erweitert (abs. FRU, 14-bit-Adr., 5/9/13 Funkt., 128 FS)
| + | |
| − | :* PS: protocol by server, der Server bestimmt den Protokolltyp
| + | |
| − | ; '''addr'''
| + | |
| − | : Zahl >= 0
| + | |
| − | ; '''direction'''
| + | |
| − | : 0 (= rückwärts), 1 (= vorwärts), 2 (= Nothalt)
| + | |
| − | ; '''V'''
| + | |
| − | : 0 .. V_max ((virtuelle) Geschwindigkeit)
| + | |
| − | ; '''V_max'''
| + | |
| − | : 0 .. 999 (maximale (virtuelle) Geschwindigkeit) V_max=0 ==> virtuelle Fahrstufe = reale Fahrstufe
| + | |
| − | ; '''func'''
| + | |
| − | : 0 (= aus), 1 (= an)
| + | |
| − | ; '''nro_f'''
| + | |
| − | : 0 .. x (Anzahl der Zusatzfunktionen (number of functions))
| + | |
| − | ; '''f1 .. fn'''
| + | |
| − | : 0 (= aus), 1 (= an)
| + | |
| − | | + | |
| − | Beispiel
| + | |
| − | | + | |
| − | ---- | + | |
| − | SET GL N2 1 1 50 250 1 4 0 1 0 0
| + | |
| − | ----
| + | |
| − | | + | |
| − | Umrechnung der virtuellen Geschwindigkeit in echte Fahrstufen:
| + | |
| − | | + | |
| − | gegeben sind
| + | |
| − | | + | |
| − | * DEC_fs (Anzahl der realen Dekoderfahrstufen, implizit bekannt)
| + | |
| − | * V (virtuelle Geschwindigkeit, Argument)
| + | |
| − | * V_max (maximale virtuelle Geschwindigkeit, Argument)
| + | |
| − | | + | |
| − | gesucht
| + | |
| − | | + | |
| − | * V_fs (reale Fahrstufe, die der virtuellen Geschw. entspricht)
| + | |
| − | | + | |
| − | Algorithmus: V_fs = round((V * DEC_fs)/V_max)
| + | |
| − | | + | |
| − | ''' Hinweise für Entwickler von SRCP-konformen Servern '''
| + | |
| − | | + | |
| − | Es ist darauf zu achten, daß wirklich nur dann die reale Fahrstufe 0 (Stillstand) errechnet wird, wenn das Argument V gleich Null ist. Die Funktion "round" ist deshalb hinreichend intelligent zu implementieren.
| + | |
| − | | + | |
| − | V_fs darf nur als Geschwindigkeitsangabe interpretiert werden. Manche Dekoder reagieren z.B. bei Fahrstufe 1 mit einem Nothalt, andere mit einem Richtungswechsel, wieder andere mit einer Selbstzerstörungssequenz ;-). Sollen solche Dekoder unterstützt werden, dann hat der Server dafür zu sorgen, daß V_fs entsprechend angepaßt wird, bevor das Kommando an den Dekoder gesendet wird. Aus Sicht der Clients müssen die Fahrstufen sukzessive von 0 bis zur maximalen Fahrstufenanzahl durchnummeriert sein.
| + | |
| − | | + | |
| − | Wird V_max auf 0 gesetzt, dann darf keine Umrechnung der Fahrstufe vorgenommen werden. D.h. die mit V übermittelte Fahrstufe ist direkt an die Dekoder weiterzusenden. Dies erlaubt Clients den direkten Zugriff auf die Dekoder.
| + | |
| − | | + | |
| − | Sendet der Client den Protokolltyp PS (protocol by server), dann muß der Server entscheiden, welches Protokoll er für die übermittelte Adresse wählt. Die anderen Protokolltypen stellen für den Server natürlich auch nur Empfehlungen des Clients dar. Der Server hat immer die Freiheit, einer Adresse ein anderes, geeigneteres Protokoll zuzuweisen.
| + | |
| − | | + | |
| − | Beispiele
| + | |
| − | | + | |
| − | ----
| + | |
| − | (50*28)/250 = 5.7 ==> V_fs = 6
| + | |
| − | (4*28)/250 = 0.448 ==> V_fs = 1 (!!!)
| + | |
| − | (0*28)/250 = 0 ==> V_fs = 0
| + | |
| − | ----
| + | |
| − | | + | |
| − | | + | |
| − | <a name="SET GA"></a> | + | |
| − | ===== Gerätegruppe GA =====
| + | |
| − | | + | |
| − | ---- | + | |
| − | SET GA <protocol> <acc_nr> <acc_port> <action> <delay>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: entfällt
| + | |
| − | | + | |
| − | Bedeutung der Argumente
| + | |
| − | | + | |
| − | ; '''protocol'''
| + | |
| − | :
| + | |
| − | :* M: Märklin/Motorola-Format
| + | |
| − | :* N: NMRA-DCC-Format
| + | |
| − | ; '''acc_nr'''
| + | |
| − | : Zahl >= 0 (Nummer der Weiche/des Signals)
| + | |
| − | ; '''acc_port'''
| + | |
| − | : 0, 1 (Ausgang des Dekoders)
| + | |
| − | ; '''action'''
| + | |
| − | : 0, 1 (0 = deaktiviert, 1 = aktiviert)
| + | |
| − | ; '''delay'''
| + | |
| − | : Wert in Millisekunden (1000stel-Sekunden). Gibt an, nach welcher Zeit der Daemon einen aktivierten Ausgang automatisch deaktivieren soll. Wird "-1" als delay übergeben, dann wird der Ausgang nicht automatisch deaktiviert. Ist action=0 (Deaktivierung) wird delay ignoriert, muß aber angegeben werden (sinnvoller Wert: "-1").
| + | |
| − | | + | |
| − | Belegung der Dekoderausgänge:
| + | |
| − | | + | |
| − | * 0 = Weiche abbiegen, Signal Hp0, ...
| + | |
| − | * 1 = Weiche gerade, Signal Hp1, ...
| + | |
| − | | + | |
| − | Beispiel:
| + | |
| − | | + | |
| − | ----
| + | |
| − | SET GA M 0023 1 1 20
| + | |
| − | ----
| + | |
| − | | + | |
| − | | + | |
| − | ===== TIME =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | SET TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: entfällt
| + | |
| − | | + | |
| − | Bedeutung der Argumente
| + | |
| − | | + | |
| − | Die aktuelle Modellzeit und die Verzerrung gegenüber der Realzeit wird festgelegt. Bei erstmaligen Aufruf vergleichbar mit einem INIT TIME.
| + | |
| − | | + | |
| − | ; '''Tag'''
| + | |
| − | : sequentielle Folge von Tageszahlen (julianisch)
| + | |
| − | ; '''Stunde'''
| + | |
| − | : 0..23, besteht aus 60 MINUTEN
| + | |
| − | ; '''Minute'''
| + | |
| − | : 0..59, besteht aus 60 SEKUNDEN
| + | |
| − | ; '''Sekunde'''
| + | |
| − | : 0..59
| + | |
| − | ; '''FX, FY'''
| + | |
| − | : Ganzzahlige Bestandteile der Zeitverzerrung
| + | |
| − | | + | |
| − | Beispiel:
| + | |
| − | | + | |
| − | ----
| + | |
| − | SET TIME 1 23 55 0 1 1
| + | |
| − | ----
| + | |
| − | | + | |
| − | setzt auf den Abend des ersten Tages mit Modellzeit gleich Realzeit. (vgl. [[#INIT TIME | INIT TIME]])
| + | |
| − | | + | |
| − | | + | |
| − | <a name="SET POWER"></a> | + | |
| − | ===== POWER =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | SET POWER <state> <freetext>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: entfällt
| + | |
| − | | + | |
| − | Bedeutung der Argumente
| + | |
| − | | + | |
| − | ; '''State'''
| + | |
| − | :
| + | |
| − | :; '''ON'''
| + | |
| − | :: Schaltet die Energieversorgung ein
| + | |
| − | :; '''OFF'''
| + | |
| − | :: Schaltet die Energieversorgung ab
| + | |
| − | ; '''Freetext'''
| + | |
| − | : Ein optionaler Text mit maximal 100 Zeichen, der an das INFO Packet angehängt wird und nähere Informationen geben kann. Es werden ausdrücklich keine Vorgaben über den Inhalt gemacht.
| + | |
| − | | + | |
| − | | + | |
| − | ==== Befehlsparameter des Befehls GET ====
| + | |
| − | | + | |
| − | <a name="GET GL"></a> | + | |
| − | ===== Gerätegruppe GL =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | GET GL <protocol> <addr>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Bedeutung der Argumente: siehe [[#SET GL | SET GL]]
| + | |
| − | | + | |
| − | Der Server sendet an den Client alle verfügbare Info zu dem mit >protocol> und <addr> spezifizierten Lok- oder Funktionsdekoder. Diese Info muß wie folgt formatiert werden:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
| + | |
| − | ----
| + | |
| − | | + | |
| − | (vgl. [[#SET GL | SET GL]])
| + | |
| − | | + | |
| − | Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. [[#3. Kommandos zur Digitalsteuerung | Digitalsteuerung]]).
| + | |
| − | | + | |
| − | | + | |
| − | <a name="GET GA"></a>
| + | |
| − | ===== Gerätegruppe GA =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | GET GA <protocol> <acc_nr> <acc_port>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Bedeutung der Argumente: siehe [[#SET GA | SET GA]]
| + | |
| − | | + | |
| − | Der Server sendet an den Client alle verfügbare Info zu dem mit <protocol> und <acc_nr> spezifizierten Schaltdekoder. Diese Info muß wie folgt formatiert werden:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO GA <protocol> <acc_nr> <acc_port> <state>
| + | |
| − | ----
| + | |
| − | | + | |
| − | (vgl. [[#SET GA | SET GA]], ersetze <state> durch <action>)
| + | |
| − | | + | |
| − | Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. [[#3. Kommandos zur Digitalsteuerung | Digitalsteuerung]]).
| + | |
| − | | + | |
| − | | + | |
| − | <a name="GET FB"></a> | + | |
| − | ===== Gerätegruppe FB =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | GET FB <module_type> <portnr>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Bedeutung der Argumente
| + | |
| − | | + | |
| − | ; '''module_type'''
| + | |
| − | :
| + | |
| − | :* S88 (Märklin s88-Bus am Parallelport des PC)
| + | |
| − | :* I8255 (i8255 Karte)
| + | |
| − | :* M6051 (Märklin s88-Bus via Interface 6051)
| + | |
| − | ; '''portnr'''
| + | |
| − | : konkreter Eingang eines Räckmeldemoduls oder "*" für alle verfügbaren Eingänge
| + | |
| − | | + | |
| − | Der Server sendet auf dem Rückmeldekanal an den Client den aktuellen Status des mit <module_type> und <portnr> spezifizierten Rückmeldemoduleingangs. Diese Info muß wie folgt formatiert werden:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO FB <module_type> <portnr> <state>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Wobei state entweder "0" oder "1" sein darf.
| + | |
| − | | + | |
| − | Wurde als portnummer der Platzhalter "*" angegeben, so sendet der Server als portnummer den "*" (ohne Hochkomma), gefolgt von den Zuständen aller angeschlossenen Ports. Diese Zustände werden NICHT durch Leerzeichen getrennt.
| + | |
| − | | + | |
| − | Beispiel
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO FB M6051 * 1100110010101111
| + | |
| − | ----
| + | |
| − | | + | |
| − | Sollte keine Information vorhanden sein, oder der Server den Befehl GET nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden (vgl. [[#3.1 Befehle und Gerätegruppen | Befehle und Gerätegruppen]]).
| + | |
| − | | + | |
| − | | + | |
| − | <a name="GET TIME"></a>
| + | |
| − | ===== Zeit =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | GET TIME
| + | |
| − | ----
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Liefert die aktuelle Modellzeit und die Verzerrungsfaktoren als INFO-Zeile
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO TIME <Tag> <Stunde> <Minute> <Sekunde <fx> <fy>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Sollte keine Modellzeit definiert sein, so muß der Server dies mit "INFO -2" (no data) an den Client senden (vgl. [[#3.1 Befehle und Gerätegruppen | Befehle und Gerätegruppen]]).
| + | |
| − | | + | |
| − | | + | |
| − | ===== Power =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | GET POWER
| + | |
| − | ----
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Ermittelt den aktuellen Zustand der Energieversorgung. Als Antwort erscheint
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO POWER [ON|OFF] <Message_Text>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Messagetext ist hierbei der zuletzt gesetzte Wert (vgl. [[#SET POWER | SET POWER]])
| + | |
| − | | + | |
| − | | + | |
| − | ==== Befehlsparameter des Befehls WAIT ====
| + | |
| − | | + | |
| − | ===== Gerätegruppe FB =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | WAIT FB <module_type> <portnr> <value> <timeout>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Wartet, bis der angegebene Port den Wert value (0,1) annimmt. Wartet aber höchstens timeout Sekunden. Sendet falls der timeout nicht eingetreten ist, die gleiche Information wie GET FB. Sollte der timeout überschritten werden, wird "INFO -3" an den Client gesendet.
| + | |
| − | | + | |
| − | Sollte keine Information vorhanden sein, oder der Server den Befehl WAIT nicht unterstützen, dann muß der Server "INFO <error code>" an den Client senden.
| + | |
| − | | + | |
| − | | + | |
| − | ===== TIME =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | WAIT TIME <Tag> <Stunde> <Minute> <Sekunde>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Wartet, bis die Modellzeit den angegebenen Zeitpunkt mind. erreicht hat und liefert einen INFO-String mit der aktuellen Modellzeit.
| + | |
| − | | + | |
| − | bei nicht initialisiertem Zeitgeber wird "INFO -1" geliefert. Ist die aktuelle Modellzeit bereits später als die übergebende Zeit ist die Bedingung ohne weitere Wartezeit erfüllt. Offensichtlich falsche Zeitangaben werden durch "INFO -1" an den anfordernden Client ignoriert.
| + | |
| − | | + | |
| − | | + | |
| − | ==== Befehlsparameter des Befehls INIT ==== | + | |
| − | | + | |
| − | ===== Feedback Module =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | INIT FB <module_type>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: entfällt
| + | |
| − | | + | |
| − | Initialisiert die entsprechenden Rückmeldeeinheiten. Keine Nachricht an den Client.
| + | |
| − | | + | |
| − | | + | |
| − | <a name="INIT TIME"></a> | + | |
| − | ===== TIME =====
| + | |
| − | | + | |
| − | ----
| + | |
| − | INIT TIME <Tag> <Stunde> <Minute> <Sekunde> <fx> <fy>
| + | |
| − | ---- | + | |
| − | | + | |
| − | startet den Zeitgeber mit der Verzerrung FX/FY am angegeben Zeitpunkt. Jede volle Modellminute wird sodann als INFO Paket auf dem INFO-Port aller aktiven und zukünftigen Clients ausgesendet.
| + | |
| − | | + | |
| − | Die Modellzeit errechnet sich wie folgt:
| + | |
| − | | + | |
| − | ----
| + | |
| − | (Delta) Modellzeit = (Delta) Realzeit * FX / FY
| + | |
| − | ----
| + | |
| − | | + | |
| − | Beispiel:
| + | |
| − | | + | |
| − | * FX=10 FY=1 -> Jede Realminute werden 10 Modellminuten generiert (also alle 6 Sekunden eine).
| + | |
| − | * FX=1 FY=10 -> Alle 10 Realminuten läuft eine Modellminute ab.
| + | |
| − | * FX=1 FY=1 -> Jede Realminute läuft eine Modellminute ab
| + | |
| − | | + | |
| − | Die Tageszahl wird fortlaufend alle 24 Modellstunden hochgezählt.
| + | |
| − | | + | |
| − | | + | |
| − | ==== Befehlsparameter des Befehls TERM ====
| + | |
| − | | + | |
| − | Keine bislang
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == 4. Kommandos zur Dekoderprogrammierung ==
| + | |
| − | | + | |
| − | Es gibt Dekoder, die auf einem Programmiergleis oder "on-track" programmierbar sind. Diese Dekoder erlauben die Änderung von "Speicherzellen" (Register, CV (configuration variable), Bit). Diese Dekoder können auch von SRCP-Servern unterstützt werden. Dazu werden die Befehle WRITE, VERIFY und READ spezifiziert.
| + | |
| − | | + | |
| − | In INFO Zeilen wird als Gerätegruppe das Wort SM benutzt: ServiceMode.
| + | |
| − | | + | |
| − | | + | |
| − | === 4.1 Dekodereinstellungen ändern ===
| + | |
| − | | + | |
| − | ----
| + | |
| − | WRITE GL <protocol> <dest-type> <dest-addr> <value>
| + | |
| − | WRITE GA <protocol> <dest-type> <dest-addr> <value>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Einzeilig, Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Bedeutung der Argumente
| + | |
| − | | + | |
| − | ; '''protocol'''
| + | |
| − | : NMRA, ...
| + | |
| − | ; '''dest-type'''
| + | |
| − | : Art der zu ändernden Dekoderspeicherzelle (destination type)
| + | |
| − | :; '''CV''' | + | |
| − | :: NMRA-DCC configuration variable
| + | |
| − | :; '''CVBIT'''
| + | |
| − | :: ein Bit einer NMRA-DCC configuration variable, dest-addr enthält dann zwei Worte: Speicherzelle und Bitnummer (0-7) in dieser Speichezelle
| + | |
| − | :; '''REG'''
| + | |
| − | :: Ein Register eines NMRA-DCC-Dekoders
| + | |
| − | ; '''dest-addr'''
| + | |
| − | : Adresse der Speicherzelle, die geändert werden soll (ggf. enthält sie die Bitnummer (0-7, bei CVBIT) als zweites Wort der Adresse.
| + | |
| − | ; '''value'''
| + | |
| − | : neuer Wert der Speicherzelle
| + | |
| − | | + | |
| − | Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines WRITE-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO GL SM <value>
| + | |
| − | INFO GA SM <value>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Wobei <value> folgende Werte annehmen kann:
| + | |
| − | | + | |
| − | * 0: WRITE ist fehlgeschlagen
| + | |
| − | * 1: WRITE wurde erfolgreich ausgeführt
| + | |
| − | * 2: Der Server weiss nicht, ob WRITE erfolgreich war
| + | |
| − | | + | |
| − | Sollte WRITE oder ein bestimmter Parameter von WRITE nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".
| + | |
| − | | + | |
| − | | + | |
| − | === 4.2 Dekodereinstellungen verifizieren ===
| + | |
| − | | + | |
| − | ----
| + | |
| − | VERIFY GL <protocol> <dest-type> <dest-addr> <value>
| + | |
| − | VERIFY GA <protocol> <dest-type> <dest-addr> <value>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Länge eines Kommandos (variabel): Befehlsendezeichen ist "\n"
| + | |
| − | | + | |
| − | Kommunikationsports:
| + | |
| − | | + | |
| − | * Client -> Server: Kommandoport
| + | |
| − | * Server -> Client: Kommandoport
| + | |
| − | | + | |
| − | Bedeutung der Argumente
| + | |
| − | | + | |
| − | ; '''protocol'''
| + | |
| − | : NMRA, ...
| + | |
| − | ; '''dest-type'''
| + | |
| − | : Art der zu verifizierenden Dekoderspeicherzelle (destination type)
| + | |
| − | :; '''CV'''
| + | |
| − | :: NMRA-DCC configuration variable
| + | |
| − | :; '''REG'''
| + | |
| − | :: Ein Register eines NMRA-DCC-Dekoders
| + | |
| − | ; '''dest-addr'''
| + | |
| − | : Adresse der Speicherzelle, die verifiziert werden soll
| + | |
| − | ; '''value'''
| + | |
| − | : zu verifizierender Wert der Speicherzelle
| + | |
| − | | + | |
| − | Ein SRCP-Server sendet immer nach dem Empfang und der Abarbeitung eines VERIFY-Kommandos eine Information an den Client. Diese Information muss folgendes Format haben:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO GL SM <value>
| + | |
| − | INFO GA SM <value>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Wobei <value> folgende Werte annehmen kann:
| + | |
| − | | + | |
| − | * 0: Der mit <value> angegebene Wert ist nicht der aktuelle Wert der Speicherzelle.
| + | |
| − | * 1: Der mit <value> angegebene Wert wurde verifiziert.
| + | |
| − | * 2: Der Server kann kein VERIFY durchführen.
| + | |
| − | | + | |
| − | Sollte VERIFY oder ein bestimmter Parameter von VERIFY nicht vom Server unterstützt werden, so sendet der Server auf dem Kommandoport die Information "INFO -1".
| + | |
| − | | + | |
| − | | + | |
| − | === 4.3 Dekodereinstellungen auslesen === | + | |
| − | | + | |
| − | Reserviert für zukünftige Erweiterungen.
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == 5. Datenformate der Serverinformationen ==
| + | |
| − | | + | |
| − | === 5.1 Rückmeldepollport ===
| + | |
| − | | + | |
| − | Die Datenübertragung auf dem Rückmeldepollport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgendem Format übertragen werden:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO FB <module_type> <portnr> <state>
| + | |
| − | ----
| + | |
| − | | + | |
| − | (vgl. [[#GET FB | GET FB]])
| + | |
| − | | + | |
| − | Beim Öffnen des Ports werden sofort alle aktuell ''belegten'' (state == 1) FB-Ports an den Client übermittelt. Anschließend alle Veränderungen.
| + | |
| − | | + | |
| − | | + | |
| − | === 5.2 Informationsport ===
| + | |
| − | | + | |
| − | Die Datenübertragung auf dem Informationsport unterliegt den gleichen Beschränkungen wie die des Kommandoports (plain text, "\n" als Endezeichen). Die Daten müssen mit folgenden Formaten - abhängig von der Gerätegruppe - übertragen werden:
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO GL <protocol> <addr> <direction> <V> <V_max> <func> <nro_f> <f1> .. <fn>
| + | |
| − | ----
| + | |
| − | | + | |
| − | (vgl. [[#GET GL | GET GL]])
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO GA <protocol> <acc_nr> <acc_port> <state>
| + | |
| − | ----
| + | |
| − | | + | |
| − | (vgl. [[#GET GA | GET GA]])
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO TIME <TAG> <STUNDE> <MINUTE> <SEKUNDE> <FX> <FY>
| + | |
| − | ----
| + | |
| − | | + | |
| − | (vgl. [[#GET TIME | GET TIME]])
| + | |
| − | | + | |
| − | ----
| + | |
| − | INFO POWER ON|OFF <erläuternder Text>
| + | |
| − | ----
| + | |
| − | | + | |
| − | Der Zustand der Energierversorgung: Aktiv oder nicht aktiv. Der optionale "erläuternde Text" kann Hinweise auf die Ursache der Veränderung enthalten, er wird ggf. dem begleitenden Text des "SET POWER" Befehls entnommen. Bei automatisch erzeugten Texten ist sicherzustellen, das die Textlänge 100 Zeichen nicht übersteigt.
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == 6. Ausblicke, zukünftige Erweiterungen ==
| + | |
| − | | + | |
| − | Ich habe bewußt einige Ideen, die andiskutiert wurden, nicht mit aufgenommen. Ich bin der Meinung, daß wir einen vorläufigen Schlußstrich ziehen und die ganzen netten Dinge implementieren sollten. Damit die anderen guten Ideen nicht verloren gehen, werde ich sie in diesem Abschnitt aufführen.
| + | |
| − | | + | |
| − | | + | |
| − | === 6.1 Zentrale Konfiguration ===
| + | |
| − | | + | |
| − | Von Kurt Haders stammt der Vorschlag einer zentralen Konfigurationsdatei. Hauptanliegen ist es, mehr "Wissen" von den Clients in den Server zu verlagern. Ein Format, wie eine solche Konfigurationsdatei aussehen soll, liegt noch nicht vor. Das Übertragungsprotokoll ist duch den Protokollbezeichner "PS" (protocol by server) bereits darauf vorbereitet.
| + | |
| − | | + | |
| − | | + | |
| − | === 6.2 Erweiterung der Befehle auf andere Gerätegruppen ===
| + | |
| − | | + | |
| − | Von Matthias Trute kommt der Vorschlag den Befehl WAIT auch für die Gerätegruppen GL und GA zuzulassen. Allerdings kann es hierbei zu Inkonsistenzen kommen. Weiterhin könnte man man bei WAIT Wildcards ("*") zulassen.
| + | |
| − | | + | |
| − | | + | |
| − | === 6.3 Quittierung von Befehlen ===
| + | |
| − | | + | |
| − | Martin Ostermann hängt an einer Befehlsquittierung. Dieses könnte über den Rückkanal des Kommandoports realisiert werden.
| + | |
| − | | + | |
| − | | + | |
| − | === 6.4 Konfiguration des Servers auslesen ===
| + | |
| − | | + | |
| − | Von Edbert van Eimeren kommt der Vorschlag, daß Clients die Konfiguration des Servers abfragen können sollten (neuer Befehl: CONFGET).
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == 7. Glossar ==
| + | |
| − | | + | |
| − | ; '''Julianische Tageszahl'''
| + | |
| − | : Laufende Tageszählung anstelle eines strukturierten Kalenders. Ausgehend von einem festgelegten Starttag und -zeitpunkt wird alle 24 Stunden der folgende Tag begonnen. Gebräuchlich sind als Startzeitpunkt wiederkehrend Neujahr 0h:0:0 (wie in der C Runtime) bzw. einmalig der 1.1.4713 v.Chr. 12-00 GMT in der Astronomie (daher der Name!).
| + | |
| − | Es existieren Algorithmen zur Umrechung von Kalenderinformationen in diese Darstellungsform und umgekehrt (z.B. in Collected Algorithms from CACM #199)
| + | |
| − | | + | |
| − | [[Kategorie:SRCP]]
| + | |
..hier kommt erstmal die Beta-Version für die neue Gleisübersicht hin, bevor es der alten an den Kragen geht. Das Radienangebot muss da imho nicht rein, da zur Not durch Flexgleise lösbar.
Zu den Weichentypen:
EW = Einzelweiche oder "normale" Weiche, angegeben ist der Winkel und der Abzweigradius.
BW = Bogenweiche, angegeben ist der Winkel und der innere Radius. Das äußere ist idr. einfach ein um einen Parallelgleisabstand verschobener identischer Bogen.
DKW = Doppelkreuzweiche, angeben ist der Winkel und die Länge, stellenweise auch der Radius (r=).
EKW = Einzelkreuzweiche, angeben ist der Winkel und die Länge, stellenweise auch der Radius (r=).
DWW = versetzte Dreiwegweiche, angegeben ist der Winkel und der Abzweigradius.
S-DWW = symmetrische Dreiwegweiche, angegeben ist der Winkel und der Abzweigradius.
ABW = Außenbogenweiche oder Y-Weiche, angegeben ist der Winkel und der Abzweigradius.
