[Uwe Post]

Guten Tag allerseits,

da dies mein erstes Posting hier ist, schicke ich eine ultrakurze Selbstvorstellung voraus:
Ich bin seit etwa 40 Jahren Modellbahner, die letzten 25 Jahre Spur N, demnächst wieder H0 (dazu dann an anderer Stelle mehr), und beruflich Software-Entwickler und unverbesserlicher Bastler. Bisher habe ich hier viel mitgelesen, aber das Thema, um das es mir hier geht, ist es glaube ich wert, geteilt zu werden. Wenn nicht, werdet ihr mir das sicher sagen Genug der Vorrede.

Ich habe mir schon lange in den Kopf gesetzt, eine Software-Zentrale zu verwenden und die Anlage per Smartphone oder Tablet zu steuern. Nun kommt man mit z.B. Rocrail, srcpd und DDL (Digital Direct for Linux) ja schon ziemlich weit, aber ich wollte nicht immer extra einen PC (mit serieller Schnittstelle! Auch nicht selbstverständlich heutzutage) booten müssen, um Züge zu fahren. Deshalb kam ich auf die Idee, die Zentrale auf einen Einplatinencomputer zu verlegen, und dafür bot sich der Raspberry Pi an (der startet in unter 20 Sekunden). Die ganze Sache ist noch ganz fürchterlich unausgereift, aber als eine Art Diskussionsgrundlage präsentiere ich euch hier mal den momentanen, funktionierenden Testaufbau:

Standard-Roco-Weiche mit E-Antrieb ...
... hängt an ...
Standard Vierfach-Magnetartikeldecoder von IEK ...
... hängt an ...
Märklin Delta Control/Transformer (verwendet als Booster) ...
... hängt an ...
TTL-nach-RS232-Pegel-Konverter (für ein paar Euro bei ebay besorgt) ...
... hängt an ...
Raspberry Pi Model B+, GPIO-Ausgang.
Auf dem Ding läuft ein Debian Linux und ein SRCP-Server, der am GPIO-Ausgang DCC-Signale ausgibt (mit Pegel von nur 3,3 Volt, daher vorgenannter Konverter). Der SRCP-Server ist ein Open Source-Projekt, das ursprünglich nur das Steuern von Loks unterstützte (und nicht einmal Power on/off), und das ich weiterentwickelt habe (zu finden hier: https://github.com/upost/gpiodcc)
...hängt an...
Lokalem Netzwerk.
Auf meinem Smartphone läuft eine selbst geschriebene Stellwerk-App, die simple SRCP-Befehle an den Raspberry Pi schickt. Natürlich könnte ich jede andere SRCP-fähige Software verwenden, für Android gibt es beispieltweise auch eine SRCP-App, mit der man Loks steuern kann (aber keine Weichen stellen). Mit meiner App wiederum kann man keine Loks fahren.

Nach längeren, immer wieder unterbrochenen Entwicklungsarbeiten, bei denen ein Digital-Oszilloskop von großer Hilfe war, kann ich seit einigen Tagen tatsächlich mit meinem Smartphone die Test-Weiche stellen.

Natürlich bleibt noch viel zu tun, und das ganze System ist weder zu Rückmeldungen fähig noch besitzt es einen Anschluss für ein Programmiergleis - aber dafür kostet es auch nur einen Bruchteil einer echten Zentrale (knapp 30 Euro für den Raspberry, 5 für den Konverter und wie wenig ich für das Delta Control bezahlt habe, weiß ich nicht mehr) und das "Selbstmachen" ist halt eine besondere Herausforderung

Sobald ich dazu komme, mache ich mal Fotos von meinem Testaufbau.

Jetzt habt ihr erstmal die Möglichkeit, diese kleine Story zu kommentieren oder mir Fragen zu stellen.

Schönen Gruß in die Runde!
Uwe

[ICN]

Hi Uwe

Also zuerst einmal meinen grossen Respekt zur Umsetzung/Erweiterung von DCC-Signalen via GPIO !
Ich bin selbst Informatik-Student und deshalb auch schon länger daran, mit dem RaspberryPi eine Art "Gateway" (oder eben Software-Zentrale) zu realisieren. Allerdings habe ich den Weg via Märklin Gleisbox <-CAN-> Arduino (https://code.google.com/p/railuino/) <-USB-> RaspberryPi mit SRCP-Server in Python gewählt. Eigentlich aus dem Grund, weil ich mir das Programmieren von DCC-Gleissignalen nicht ganz zutraute und auf die relativ ausgereifte Gleisbox von Märklin (zusammen mit einer MS2 (ca. 80-100€ in der Bucht). Aber ich finde es super, dass wir beide das SRCP-Protokoll verwenden. In meinen Augen wird es in kommerziellen Anwendungen viel zu wenig angeboten.

Ein Problem an dem viele solcher Bastler-Lösungen kranken sind aus meiner Sicht die Rückmeldungen.. hast du dazu schon irgendwelche Pläne?
Momentan laufen diese bei mir über einen separaten SRCP-Server der mit einem Arduino am S88-Bus hängt, aber ich möchte das ganze möglichst bald auf den Raspberry Pi migrieren...

Viele Grüsse
Matthias

[Uwe Post]

Hallo Matthias,

nein, für die Rückmeldung habe ich noch keine Pläne. Leider habe ich für das ganze Projekt wenig Zeit und bin schon froh, dass ich es soweit hinbekommen habe... aber wir können uns da gerne mal austauschen.

Das mit den DCC-Gleissignalen ist in der Tat nicht so einfach. Zum Glück konnte ich auf vorhandenen Code zurückgreifen und mit dem Oszi sehr genau sehen, was hinten rauskommt, und der Vergleich mit den Signalen des srcpd auf PC war auch hilfreich. Du kannst einen Blick auf die Implementierung werfen, der Link zum Projekt steht oben, und es sind nur zwei C-Dateien (dcc.c generiert die GPIO-Signale).

Hier noch das versprochene Foto:



Links oben sieht man die Test-Weiche, verdeckt durch mein Handy, auf dem meine simple App "Stellwerk" läuft. Rechts liegt der Decoder, an dem die Weiche angeschlossen ist, wie man gut sehen kann. Oben rechts führt die Rundleitung aus dem Bild hinaus zum Delta-Control (nicht im Bild). Unten sieht man rechts die beiden Litzen, die ebenfalls zum Delta-Control führen (mit dem DCC-Signal auf RS232-Pegel). Links der Raspberry Pi. Von großer Bedeutung ist auch die Schraubzwinge, die ganz rechts zu sehen ist und das widerspenstige Netzwerkkabel festhält. Natürlich kann man auch einen WLAN-Stick in den Raspberry stöpseln; ich habe auch irgendwo einen rumfliegen, aber der ist nicht so richtig kompatibel und ich hatte noch keinen Nerv, den zum Laufen zu bringen.

In den nächsten Tagen werde ich mal versuchen, eine Lok in Bewegung zu setzen. Allerdings habe ich im Moment keine mit Decoder (meine N-Anlage war analog). Immerhin habe ich mir aber schonmal einen TAMS-Decoder beschafft, der noch darauf wartet, in eine meiner neuen H0-Loks eingesetzt zu werden...

[stephan_bauer]

Hallo Uwe,

Du kannst auch mit Rocrail die Software-Zentrale auf dem Raspberry verwenden:
http://wiki.rocrail.net/doku.php?id=dcc232-en
Rocrail ist auch ein SRCP-Server.

Noch einfacher wäre es natürlich, eine Hardware-Zentrale per USB anzuschliesen.
Mit dem BiDiB-GBMBoost hättest Du eine günstige Zentrale mit 4A-Booster und das Thema Rückmeldung wäre auch schon erledigt:
http://www.fichtelbahn.de/gbm_index.html

Grüße
Stephan

[bertr2d2]

Hallo Mathias,

Zitat

---

Ein Problem an dem viele solcher Bastler-Lösungen kranken sind aus meiner Sicht die Rückmeldungen.. hast du dazu schon irgendwelche Pläne?
Momentan laufen diese bei mir über einen separaten SRCP-Server der mit einem Arduino am S88-Bus hängt, aber ich möchte das ganze möglichst bald auf den Raspberry Pi migrieren...

---

Ggf. ist das http://www.s88udp.de was für Euch ...

Gruß

Gerd

[Uwe Post]

@Stephan: Aber kann Rocrail denn direkt DCC-Signale ausgeben? Dein Link führt zum dcc232-Modul, mit dem Vermerk: "DCC signal is generated using a serial device." Das läuft doch nicht auf dem Raspberry, oder? Der hat ja streng genommen keine RS232-Schnittstelle. DCC über RS232 ist außerdem ein Notbehelf. Man muss ja ziemlich mit dem RS232-Protokoll tricksen, um das richtige Signal zu bekommen. Meine direkte Methode über GPIO ist da völlig flexibel. Ich kann leicht jedes Signal erzeugen, das ich will. Ich muss es nur richtig machen, sonst bewegt sich gar nichts

Und eine Hardware-Zentrale will ich ja gerade nicht, das wäre zu leicht

Danke, Gerd, für den Link zum s88udp. Das könnte man verwenden. Werde ich mir mal ansehen, sobald ich überhaupt das Thema Rückmeldung angehe. Als nächstes ist erstmal der Plan, Lok-Decoder korrekt zu unterstützen und sicherzustellen, dass das SRCP-Protokoll - soweit sinnvoll - komplett unterstützt wird. Außerdem muss meine App Fahrstraßen schalten lernen, und über Signale, Bahnschranken oder Beleuchtung habe ich überhaupt noch nicht nachgedacht...

Ich werde meine neue Anlage mit meinem Selbstbau-System zu steuern versuchen - sie wird eher klein, ca. 8 Weichen, 5 Loks, selten mal zwei gleichzeitig in Bewegung - und schaue mal, wie weit ich komme.

[stephan_bauer]

Hallo Uwe,

das geht auf dem Raspberry. DCC wird über RS232 erzeugt. Hatte ich im Rocrail-Forum gelesen. Kann sein, dass noch ein USB-RS232-Adapter benötigt wird.
DCC über RS232 ist nicht 100% konform, scheint aber meistens zu funktionieren.

Grüße
Stephan

[Uwe Post]

Hallo Stephan,

danke für den Hinweis. Man kann sich ja bei funktionierenden Lösungen immer mal was abgucken.
Vor allem, wenn man sehr langsam vorgeht, wie ich es tue.
Da ich mir gerade eben eine DCC-Lok ersteigert habe, ist es nur noch eine Frage von Tagen, bis ich berichten kann, ob meine Lösung dazu in der Lage ist, sie in Bewegung zu versetzen...

Gruß
Uwe

[diddi]

Hallo,

ich verwende auch einen Raspberry mit srcpd als Zentrale. Als Rückmeldung verwende ich seit einiger Zeit CAN-Bus Module vom CAN Digitalbahnprojekt.
Das funktioniert einwandfrei. Dort habe ich auch einen kleinen Betrag geschrieben wie es funktioniert. Ist simpel. Als Clients verwende ich selbst geschriebene Programme in Free Pascal. Da auf dem Raspberry nur der srcpd läuft, ohne Grafik, funktioniert DLL auch recht zuverlässig.

Mit freundlichen Grüßen

Dietmar

[Uwe Post]

Hallo Dietmar,

verwendest Du denn einen RS232-Adapter oder was genau hängt bei Dir zwischen Raspberry und Gleis?

Ich habe mittlerweile eine erste digitale Lok auf den Testkreis gestellt, und sie bewegt sich zwar, aber es gibt noch irgendein Problem mit den Kommandos, das ich noch nicht in Ruhe untersuchen konnte. Außerdem funktionieren die Funktionstasten nicht, jedenfalls kann ich das Licht der Lok nicht anschalten. Die verwendete App (Android SRCP Client, also diesmal nicht meine eigene), scheint außerdem nicht ganz sauber programmiert zu sein, jedenfalls hängt sie sich immer mal ein bisschen auf. Die Lok-Steuerung will ich aber sowieso noch in meine eigene App integrieren (und eine Fahrstraßensteuerung).
Da die Sache aber grundsätzlich zu funktionieren scheint, fühle ich mich weiterhin auf dem richtigen Weg. Für meine geplante Klein-Anlage (ca. 8 Weichen, max. 10 Loks, davon höchstens 2 gleichzeitig unterwegs) wird es reichen.
Wobei ich eigentlich noch die gerne die verbliebene "Fremdkomponente" (das Delta-Control) ersetzen würde, nämlich durch einen selbstgebauten Booster, aber mit Leistungselektronik kenne ich mich nicht so aus, deshalb werde ich es wohl bleiben lassen.

Anleitung und App werde ich an geeigneter Stelle veröffentlichen, sobald alles läuft.

Gruß
Uwe

[bertr2d2]

Hallo,

Zitat von stephan_bauer

---

Hallo Uwe,

das geht auf dem Raspberry. DCC wird über RS232 erzeugt. Hatte ich im Rocrail-Forum gelesen. Kann sein, dass noch ein USB-RS232-Adapter benötigt wird.
DCC über RS232 ist nicht 100% konform, scheint aber meistens zu funktionieren.

---

weiss jemand warum RS232 nicht 100% konform ist ?

Gruß

Gerd

[cab]

Hallo bertr2d2,

ja die Impulsbreite läßt sich nicht genau auf die laut NEM vorgeschriebene einstellen. Das liegt an den Teilerfaktoren der RS232 Impulsgewinnung auf dem Basistakt.

Viele Grüße
Carsten

[Uwe Post]

Hallo allerseits,

genau so ist es. Bei DCC über RS232 (aka DDL/DDW) wird die serielle Schnittstelle auf recht komplizierte Weise mit "künstlichen" Daten beschickt, so dass am Ende "ziemlich genau" ein NMRA-konformes DCC-Signal herauskommt. Dieses "ziemlich genau" ist halt der Knackpunkt. Diese Schwäche hat mein Bastelsystem nicht, weil der Raspberry das Signal ohne Umwege mit dem exakt richtigen Timing erzeugt!

Heute habe ich meine App um Steuerelemente für die entsprechenden DCC-Kommandos erweitert, weil ich mit dem für Android öffentlich verfügbaren SRCP-Client kein zufriedenstellendes Ergebnis erzielt habe.

Nebenbei habe ich den Lötkolben angeworfen und eine Roco Br. 290 mit einem TAMS-Decoder versehen. Programmieren kann ich den wohlgemerkt noch nicht, das gibt meine Software noch nicht her. Aber bekanntermaßen ist die Standard-Adresse die Nr. 3 und auf die hört die Lok tatsächlich

So sieht meine App jetzt im Moment aus:



Ich kann meine 290 damit prima steuern und auch das Spitzensignal an- und ausschalten (mehr Funktionen hat sie nicht). Bisher kann ich mit der App noch nicht zu einer anderen Lok wechseln. Steckt alles noch in den Kinderschuhen, aber ist ja eher eine einfache Aufgabe. Und beim Starten und Beenden des Dienstes auf dem Raspberry macht die Lok einen sehr unschönen Sprung. Weiß noch nicht genau, wieso. Sie muss sich wohl kurzzeitig in einem Analog-Stromkreis wähnen. Und das bei 18 Volt. Aua.

Meine 260 möchte sich allerdings nicht (mehr) bewegen. Zunächst tat sie es, aber im Laufe der Versuche hat sie irgendwann damit aufgehört. Ich kann mir eigentlich nicht vorstellen, dass ich den Decoder geschrottet habe. Zumal sie im Analog-Stromkreis noch läuft. Oder heißt das nichts? Werde wohl mal den PC mit dem "richtigen" DDL drauf anwerfen müssen, damit müsste ja alles gehen...

Grüße aus der Werkstatt,
Uwe

[bertr2d2]

Hallo Carsten,

Zitat von cab

---

Hallo bertr2d2,

ja die Impulsbreite läßt sich nicht genau auf die laut NEM vorgeschriebene einstellen. Das liegt an den Teilerfaktoren der RS232 Impulsgewinnung auf dem Basistakt.

Viele Grüße
Carsten

---

halbwegs moderne serielle UARTs können doch nahezu jede beliebige Baudrate verwenden. Beispiele (USB-UARTs):

PL2303HXD (pl2303.c):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 

363 static speed_t pl2303_encode_baud_rate_divisor(unsigned char buf[4],
364                                                                 speed_t baud)
365 {
366         unsigned int tmp;
367 
368         /*
369          * Apparently the formula is:
370          * baudrate = 12M * 32 / (2^buf[1]) / buf[0]
371          */
372         tmp = 12000000 * 32 / baud;
373         buf[3] = 0x80;
374         buf[2] = 0;
375         buf[1] = (tmp >= 256);
376         while (tmp >= 256) {
377                 tmp >>= 2;
378                 buf[1] <<= 1;
379         }
380         buf[0] = tmp;
381 
382         return baud;
383 }
 
 

CP2104 (cp210x.c):

1
2
3
4
5
6
7
8
9
10
11
12
13
 

633  * CP2104, CP2105 and CP2110 support most rates up to 2M, 921k and 1M baud,
634  * respectively, with an error less than 1%. The actual rates are determined
635  * by
636  *
637  *      div = round(freq / (2 x prescale x request))
638  *      actual = freq / (2 x prescale x div)
639  *
640  * For CP2104 and CP2105 freq is 48Mhz and prescale is 4 for request <= 365bps
641  * or 1 otherwise.
642  * For CP2110 freq is 24Mhz and prescale is 4 for request <= 300bps or 1
643  * otherwise.
644  */
 
 

Zitat von Uwe Post

---

Hallo allerseits,
genau so ist es. Bei DCC über RS232 (aka DDL/DDW) wird die serielle Schnittstelle auf recht komplizierte Weise mit "künstlichen" Daten beschickt, so dass am Ende "ziemlich genau" ein NMRA-konformes DCC-Signal herauskommt. Dieses "ziemlich genau" ist halt der Knackpunkt. Diese Schwäche hat mein Bastelsystem nicht, weil der Raspberry das Signal ohne Umwege mit dem exakt richtigen Timing erzeugt!

---

wie ich sehe, arbeitest Du mit Timern. Kurz vor Ablauf des Timers kann aber ein anderer Prozess mit höherer Priorität
(z.B. Kernel Prozess) dazwischen kommen. Das Timing wird wahrscheinlich meistens passen, aber eben nicht immer.
Oder verwendest Du eine Realtime-Erweiterung ?

Der Umweg über UART (incl Fifo) umgeht das Problem: Die Daten werden in einem Bitstrom raus gesendet, ohne das die
CPU eingreifen muss.

BTW:
Das UI sieht wirklich ansprechend aus

Gruß

Gerd

[Uwe Post]

Guten Abend,

Zitat

---

Das Timing wird wahrscheinlich meistens passen, aber eben nicht immer.
Oder verwendest Du eine Realtime-Erweiterung ?

---

Das nicht, aber auf dem Raspberry läuft ansonsten nichts, was "stören" könnte.

Mein Hauptproblem ist im Moment ehrlich gesagt, dass beide Loks nicht mehr fahren, d.h. nur analog; ich habe zu allem Überfluss gerade Probleme mit dem Linux-Rechner, auf dem der SRCP-Server läuft (er will nicht ins Netz), so dass ich das nicht probieren kann.

Hat schonmal jemand erlebt, dass ein Decoder so "kaputt" ist, dass er noch das Licht anschalten kann und analog fährt, aber nicht digital? Klingt eher unwahrscheinlich, oder?

Danke für die Blumen, was die UI angeht. Da wird aber sicher noch einiges passieren, z.B. sind die Farben und Button-Größen nicht einheitlich, und es gibt noch nicht alle nötigen Elemente für das Gleisbildstellpult. Aber es stellt schonmal das westliche Ende meiner geplanten Anlage dar

Gute Nacht!
Uwe

[Uwe Post]

Hallo allerseits,

ich antworte mir mal selbst mit dem aktuellen Stand der Experimente:
Gestern habe ich den "Original"-srcpd auf dem Raspberry installiert, was nach dieser Anleitung recht einfach machbar ist. Die Steuerung meiner Test-Weiche via RocRail oder meiner eigenen App funktioniert jedenfalls. Bloß sehe ich während des Bootvorgangs des Raspberry kurze Signale auf dem Gleis (mit dem Oszilloskop), obwohl ich dem Betriebssystem gesagt habe, dass es nichts über diesen Port ausgeben soll.

Wenn die Steuerung mit srcp weiterhin gut klappt, erspart mir das die Implementierung der noch fehlenden Funktionen mit GPIO und konzentriere mich auf meine App.


Gruß
Uwe

[Rainer Müller]

Hallo,

Zitat von Uwe Post

---

Guten Abend,

Zitat

---

Das Timing wird wahrscheinlich meistens passen, aber eben nicht immer.
Oder verwendest Du eine Realtime-Erweiterung ?

---

Das nicht, aber auf dem Raspberry läuft ansonsten nichts, was "stören" könnte.

---

Zumindest schreibt dein "Altmeister" brianwiddas im Rapi-Forum:

Zitat von BrianW

---

My code runs itself at the highest possible priority and it does consume a lot of CPU, but it works. I wouldn't be surprised to learn that some DCC packets get ignored because of timing faults, but most of them seem to be accepted.

---

Gruß
Rainer

[Uwe Post]

Nabend,

da die DCC-Pakete ja ständig wiederholt werden (bei einer Handvoll Loks und Weichen zigmal pro Sekunde) dürfte das nicht auffallen.
WAS aber auffällt ist, dass der srcpd deutlich langsamer ist. Zwischen Antippen der Weiche in meiner App und dem elektromagnetischen "Klick!" der Zungen vergeht eine geschätzte Sekunde. "Mein" gpio-Dingsbums ist merklich schneller. Warum, weiß ich nicht genau.

Kann vielleicht jemand über eine träge Steuerung insbes. von Fahrzeugen per raspi/srcpd berichten? Beim Rangieren kann es ja schon mal auf eine Sekunde mehr oder weniger ankommen, oder?

Gruß
Uwe

[Uwe Post]

Tag allerseits,

meine Bastelveranstaltung hat gewisse Fortschritte gemacht. Nach längerer Suche habe ich herausgefunden, warum meine Loks alle nicht mehr fuhren. Keineswegs hatte ich die Decoder geschrottet (puh!), sondern es gibt ein Problem, wenn man 128 Fahrstufen verwenden will. Ich habe noch nicht rausgefunden, was für eins, aber mit 28 Fahrstufen geht's.
Daraufhin habe ich jetzt meiner App eine Art Lokdatenbank beigebracht, sowie einen einfachen Programmiermodus. Damit konnte ich jetzt zwei Loks mit Tams-Decoder auf eine andere als die Standardadresse programmieren. Bei der 260 mit Lemke Silver Mini muss ich noch nachsehen, wie man die Adresse ändert, offenbar geht es da anders.
Die Steuerung mit dem Slider (siehe Screenshot oben) ist noch nicht hundertprozentig gelungen, aber ich kann prima durch die Gegend fahren. Die nächste Hürde wird der Trix-Schienenbus, der derzeit zu mir unterwegs ist. Der hat nämlich Sound...

In absehbarer Zeit stelle ich meine App gerne für interessierte Alpha-Tester zur Verfügung.

LG
Uwe

[diddi]

Hallo Uwe,

Zwischen raspberry und Gleis hängt bei mir ein Pegelwandler für die serielle Schnittstelle und ein LV 102 der Fa. Lenz.

So langsam ist der srcpd bei weitem nicht. In einer Sekunde schalte ich eine ganze Fahrstraße. Für eine Weiche vielleicht 0,2 Sekunden.

Allerdings verwende ich keine App, sonder Ditrail.

Gruß
Dietmar

[Uwe Post]

Hallo Dietmar,

dann ist unser Aufbau jetzt sehr ähnlich Den Pegelwandler habe ich ja auch, als Booster dient das alte Delta Control 6604 mit Trafo.

Wo die Sekunde verlorengeht, werde ich auch noch herausfinden. Beim Fahren der Loks fällt das nicht sonderlich ins Gewicht, bei meiner Testweiche merke ich die Verzögerung. Fahrstraßen hab ich nicht nicht, brauche erstmal einen Stapel Weichenantriebe - das ist die nächste Baustelle

Schönen Gruß
Uwe

[diddi]

Hallo Uwe,

und nicht vergessen bei DDL dem srcpd die höchste Priorität zu geben. Kann nicht schaden, auch wenn sonnst nichts weiter läuft auf der Beere.

schönes WE

Dietmar

[Uwe Post]

Hallo Dietmar,

danke für den Hinweis. Möglicherweise hilft das ja schon gegen die Verzögerung. Ich werde es nachher mal ausprobieren. Auch wenn an sich sonst nichts auf dem Raspberry läuft... man weiß ja nie.

Sag einmal, lässt Du den Raspberry dauernd laufen? Denn wenn man ihn ausschaltet, "vergisst" er (bzw. der SRCPd) alle Lok- oder Weichenzustände.

Schönen Gruß
Uwe

[diddi]

Hallo Uwe,

ja ich schalte den Raspberry aus. Das geschieht mittels eines Scriptes übers Netz. Das Script wird von meinem Stellwerkprogramm gestartet.
Wenn ich mein Stellwerkprogramm starte, werden gleich alle Weichenzustände ausgelesen. Sollte eine Weiche nicht an der Rückmeldung hängen, Neueinbau z.B., wird sie auf gerade gestellt. Dann starte ich die Locksteuerung und die Locks werden initialisiert. Wenn der Server dh. der srcpd neu gestartet wird, müssen auch die Clients neu gestartet werden - logisch. Ein Serverneustart ist aber nur in Ausnahmefällen notwendig.

Schöne Woche

Dietmar

[Uwe Post]

Hm.

Hallo Dietmar,

ohne Rückmeldesystem wäre es also hilfreich, wenn meine App (also der SRCP-Client) bei Beenden der Verbindung alle Zustände speichern würde, um sie beim nächsten Verbinden mit dem SRCP-Server genau so wiederherzustellen. Mal vorausgesetzt, dass zwischendurch niemand eine Weiche per Hand umgestellt hat, dürfte ja nichts passieren, außer dass der Server wieder im gleichen Zustand wie vor dem letzten Abschalten ist.
Mich wundert eigentlich ein bisschen, dass der SRCPd kein Feature hat, um alle Zustände zu speichern und wiederherzustellen. Rückmeldung ist ja grundsätzlich optional, und so wäre ein Reboot sozusagen Status-neutral.

Gruß
Uwe