Zitat von st-oldie ... Wenn es mit Patricks Setup läuft, dann könnte man meine Software sogar auf einem Linux PC mit CC-Schnitte laufen lassen.
auch ich hatte mal das Vergnügen, die Schnitte zu integrieren - hier ein paar Hinweise. Ich kann daher von der Schnitte nur abraten wenn man Linux verwendet. Zumal solidere und weitaus preiswertere Lösungen wie BBB und BPi existierten.
Ich weiß. Und der API zur CC-Schnitte sieht man diese zu erwartenden Probleme auch direkt an. Patrick wollte auch nur vorübergehend damit spielen, bis er ein Cape/Shield mit CAN Transceiver hat. Bei mir war es nur wenig Aufwand, mal Code dafür vorzusehen, ich hab einfach nur andere Read, Write, Open und Close Funktionen nehmen müssen und benutze ansonsten den selben Code wie der Daemon für SocketCAN. Ein Timeout Handling zur Neusynchronisation ist auch vorgesehen. Das hatte ich mal vor ein paar Monaten so nebenbei gemacht.
Es scheint aber außerdem auch Leute zu geben, die unbedingt daran festhalten wollen, weil die CC-Schnitte schon da ist. Ich hatte ja in Mannheim mal mit jemanden gesprochen, der gern deren Clubanlage digitalisieren wollte und jeden Bediener ein Tablet oder Smartphone in die Hand drücken wollte. Und natürlich eine vorhandene CC-Schnitte mit vorhandenen RPi benutzen wollte. Allerdings hab ich von da noch keine weitere Rückmeldung bekommen.
Zitat von st-oldie Es wäre auch möglich, die Daemons weniger verbose zu machen, dann wird weniger geschrieben und schont nebenbei auch das Flash. Oder man packt das /var/log und /var/run Verzeichnis in eine Ramdisk, wie ich es auf einem alten Notebook mit SSD und ähnlich bei unseren Switchen gemacht habe. Dann sind die Verzeichnisse, in die viel geschrieben wird im RAM. Bei /var/log ist natürlich bei einem Neustart das alte logfile weg.
Zitat von st-oldie So 7. Feb 2016, 15:12 Hallo Gerd,
Zitat von bertr2d2- OpenWRT schreibt keine Dateien und kann daher zu jeder Zeit ausgeschaltet werden ohne das Dateisystem zu zerstören
Das kann man auch ohne besondere Vorkehrungen oder Verzicht auf Schreiben erreichen. Man verwendet einfach ein journaling Filesystem. Wir haben in der Firma bei unserem Projekt das /tmp und das /var in eine RAM Disk gelegt, weil dort nur zur Laufzeit benötigt Dateien liegen. Und dann ext3 benutzt, das gegenüber ext2 journaling beherrscht. Bei den ersten Tests mit ext2 gab es oft korrupte Dateisystem. Nach dem Umstieg haben wir das nie gehabt, obwohl wir unsere Geräte einfach ausschalten.
SCNR
IMHO ist das der Weg - einzig auf das Journaling zu verlassen, das machen so große Hersteller wie Cisco und Juniper aus gutem Grund auch nicht um ein paar Beispiele aus Deinem Metier mal zu nennen. Geloggt wird in RAM bzw übers Netzwerk - nur wenn man unbedingt will, wird auf das interne Flash geschrieben.
Natürlich ist Logging zu Fehleranalyse sehr wichtig, aber alte Log-Files interessiert Modellbahner wahrscheinlich herzlich wenig
Zitat von st-oldieEs wäre auch möglich, die Daemons weniger verbose zu machen, dann wird weniger geschrieben und schont nebenbei auch das Flash. Oder man packt das /var/log und /var/run Verzeichnis in eine Ramdisk, wie ich es auf einem alten Notebook mit SSD und ähnlich bei unseren Switchen gemacht habe. Dann sind die Verzeichnisse, in die viel geschrieben wird im RAM. Bei /var/log ist natürlich bei einem Neustart das alte logfile weg.
Nö überhaupt nicht. Das ganze mit Einbeziehung der Ramdisk hab ich schon vor ein paar Jahren bei einem alten Notebook und bei meinem Netbook so umgesetzt. Und auch bei unseren Switchen liegt /var in einer Ramdisk, allerdings mit 2 Logdateien auf der SD Karte. Aber das ist nicht meine Entscheidung gewesen. Und das alles deutlich vor deinem Beitrag und auch völlig anabhängig von anderen Lösungen. Und das ich die Tricks kenne siehst du ja daran, daß ich sie selbst vorschlage.
Zitat von bertr2d2IMHO ist das der Weg - einzig auf das Journaling zu verlassen, das machen so große Hersteller wie Cisco und Juniper aus gutem Grund auch nicht um ein paar Beispiele aus Deinem Metier mal zu nennen. Geloggt wird in RAM bzw übers Netzwerk - nur wenn man unbedingt will, wird auf das interne Flash geschrieben.
Diese Kritik ist bei mir aber an der völlig falschen Adresse! Das mußt du an diejenigen richten, die die SD Karten Images gebaut haben. Die haben das ja so vorgegeben, wie es ist. Ich habe nicht den Aufbau der Images erstellt. Ganz im Gegenteil möchte ich mich eigentlich darauf verlassen können, daß das Image vernünftig erstellt wurden und ich nicht als erstes daran rumbasteln muß.
Wobei ich für mein BBB unter Ubuntu 14.04 das sogar auch so geändert habe, daß ich einige Verzeichnisse in die RAM Disk gelegt habe.
Ja, die hat ja Märklin dokumentiert. Auch wenn die sich da nicht richtig an die eigene Doku halten.
die Diskussion hatten wir ja bereits schon mal. Ich halte die Nutzung von Prios auch weiterhin für nicht sinnvoll. In dem obigen Ausschnitt sieht man einen Grund: nur die Gleisbox antwortet auf den Ping mit Prio - die MS2 hingegen nicht.
Zitat von bertr2d2die Diskussion hatten wir ja bereits schon mal. Ich halte die Nutzung von Prios auch weiterhin für nicht sinnvoll. In dem obigen Ausschnitt sieht man einen Grund: nur die Gleisbox antwortet auf den Ping mit Prio - die MS2 hingegen nicht.
Sinn würde es schon machen, z.B. für eine bevorzugte Behandlung des Stop Befehls. Da die Gleisbox anscheinend keinen großen Puffer für Lokk- und Magnetartikelbefehle hat, wurde mir vorgeschlagen, die Befehle in einer Queue zu speichern und dann, wenn der Befehl mit gesetztem Response Bit acknowledged ist, den nächsten Befehl zu versenden. Mittels Prio können höher priorisierte Befehle dann vorgezogen werden und niedriger auch in einer Queue landen. Das wäre z.B. für den Stop Befehl für Nothalt interessant, der dann schneller bearbeitet werden kann.
Die MS2 unterstüzt auch anderes aus der Märklin CAN Doku nicht. Wie z.B. die Folgenummer, damit ich die Lokinfos auch als CS2 kompatible CAN Pakete erkennen kann.
Aber irgendwie scheint das wohl eine Philospie Frage zu sein.
es wurde nach ein paar Änderungen und Erweiterungen mal wieder Zeit, eine neue Version zu veröffentlichen. Es sind die folgenden Fehler behoben:
Ein Fehler im client_cs2eth wurde behoben, der in seltenen Fällen zu einer Endlosschleife führen kann.
Die Initialisierung für WakeUpS88 wurde geäendert, da sonst ohne Parameter oder Eintrag in /etc/mrsystm ein Absturz der Zentrale erfolgt.
Ein Fehler im Ablauf für das Aufwecken der S88 Module wurde behoben.
Ein Fehler beim Einschalten von DCC in der Gleisbox wurde behoben.
Zusätzlich wurden die folgenden Erweiterungen eingebaut:
Die Reihenfolge der Felder beim Schreiben der lokomotive.cs2 wurde von uid,name zu name,uid geändert, da es für die RemoteCS2 anscheinend auf die Reihenfolge ankommt. Jetzt funktioniert auch RemoteCS2 mit dem mrsystem.
Es wurde im client_ms2 noch ein Timeouthandling für gequeuete Messages hinzugefügt, damit das System im Fehlerfall nicht blockiert
Die MS2 wird im Mode "master" periodisch gepollt, um neu angelegt Loks zu erkennen.
Eine Konfiguration der seriellen USB Schnittstelle für CC-Schnitte wurde hinzugefügt.
Für den Modus Proxy kann konfiguriert werden, welche Dateien von der Master CS2.exe synchronisiertr werden.
Ein Timeout Handling für die Abfrage der MS2 wurde eingebaut.
Auf "ping member request" wird auch mit Kennung CS2GUI geantwortet, da WDP dies erwartet.
Für das BananaPi wurden noch folgende Änderungen im Image vorgenommen:
Auf der Konsole wird nicht mit dem Start eine XSession gestartet, da speziell der Bildschirmschoner zuviel REchenzeit verbraucht.
Es wurde ein neuer Kernel mit einem (noch inoffiziellen) Patch von Gerhard Bertelsmann für den CAN Treiber verwendet. Der Patch startet den CAN Controller im Fehlerfall neu. Andernfalls kann es unter hoher Last selten zu einem Überlauf im Controller kommen und als Folge kann der CAN Bus blockieren.
Images für BBB und BPi und Sourcen gibt es wie üblich über meine Homepage.
und die Software zur Übertragung der CAN Pakete zwischen CAN Bus und Ethernet gibt es wie üblich auf meiner Homepage!
Ich wollte mal wieder ein Lebenszeichen von mir geben, damit nicht der Eindruck aufkommt, mein Projekt wäre tot. Ich hab mal mein BBB auf den gleichen Kernel wie das BPi aktualsiert, damit beide System ähnlicher werden und auch mehr Treiber für WLAN Sticks zur Verfügung stehen. Und dann meine Software intern umstrukturiert, um zwischen den Clients mehr Code wiederzuverwenden. Als "Fingerübung" hab ich nach der Umstrukturierung neue Clients hinzugefügt, die sich nun schneller implementieren lassen. Hinzu kamen User für die CC-Schnitte, so daß dieser Client auch für mich getestet und korrigiert wurde. Damit habe ich jetzt eine neue Version veröffentlicht. Es gibt die folgenden Änderungen in meiner Software:
Die log Clients für CAN und Ethernet wurden von drehscheibe entkoppelt und lassen sich damit auch ohne das mrsystem verwenden.
Ein Client für den CAN log für den CS2 Ethernet port wurde hinzugefügt
Client für virtuellen COM Port von HW group hinzugefügt
Client für serielle Schnittstelle (TTY) hinzugefügt
Client für SRCP hinzugefügt (noch unvollständig, aber die SRCP Clients spdrs60 und TrackONE funktionieren schon)
Fehler in der gpio S88 Konfig behoben
Fehler für Konfig Start der Gleisbox behoben
Pollen der MS2 entzerrt, damit keine grossen Burst von CAN Nachrichten entstehen
Pollen der MS2 ist nun optional in der Konfig einstellbar
Den Timeout für verlorenen Messages bei hoher Last optimiert, damit keine langen "Hänger" beim Steuern entstehen
Fehler für Magnetartikel behoben
Fehler, der die Übertragnung speziellere Befehle (z.B. Dekoder, ...) unterdrückt, behoben, damit sollten nun alle CAN Messages funktionieren
Fehler im Client der CC-Schnitte behoben, die CC-Schnitte läuft erfolgreich bei anderen Modellbahnern
Doku des Quellcodes hinzugefügt, um Interessenten den Einstieg zu erleichtern.
Ich hab wieder Images für BBB und BPi erstellt. Die Änderungen dort sind:
Unterstützung von Win-Digipet
Samba (Windows Freigabe) eingerichtet mit Zugriff auf Icons und CS2 Config über das Homedirectory
Experten können die Logfiles in das RAM legen um weniger Schreibzugriffe auf die SD Karte zu haben
Images für BBB und BPi und Sourcen gibt es wie üblich über meine Homepage.
Zitatdas klingt alles sehr interessant, wird Zeit, dass ich mir ein frisches Image ziehe und teste!
Danke für dein Interesse. Ich feue mich, daß auch andere meine Arbeit interessant finden.
Mit den Fehlerbehebungen funktionieren jetzt auch die Magnetartikel. Da fehlte noch der Stromwert. Da ich noch keine Decoder für Magnetartikel hab, konnte ich das bisher nie testen. Jetzt sollte auch die Decoderprogrammierung oder auch die Konfiguration der CDB Module funktionieren.
Mit dieser Version sollten auch deine Problem auf dem Stammtisch gelöst sein. Da war das Timeout für verloren gegangene CAN Frames auf der Gleisbox bei hoher Last deutlich zu lang.
Zitatich habe mir nun ein Image gezogen und das läuft schon ganz gut.
Bis auf einen Fehler beim Erzeugen der lokomotive.cs2, da hab ich einen Fehler in der Abfrage der Konfig gemacht. Als Folge werden möglicherweise keine Lokfunktionen geschrieben.
ZitatGibt es irgendwo Erfahrungsberichte im Netz?
Ich kenne da nichts. Aber ich hab bisher auch nicht danach gesucht. Ich hab aber ein paar Mails als Rückmeldung bekommen.
Genau. Damit ist die Trix MS2 mit der Trix Gleisbox auch über einen CAN Bus verbunden. Ich würde deshalb erwarten, daß auch das gleiche Protokoll gesprochen wird. Kann nicht auch die Trix MS2 an die Märklin Komponenten angeschlossen werden? Ich meine, ja. Ich glaub ich hab da schon gelesen, daß der hauptsächliche Unterschied die Farbe Rot durch Grün ersetzt wird. Die Märklin Gleisbox kann ja auch schon DCC als Gleissignal erzeugen.
Dann wären dann beide Versionen auch vom Protokoll auf dem CAN Bus identisch. Und damit kannst du das Ganze auch mit den Trix Komponenten kombinieren.
Genau. Damit ist die Trix MS2 mit der Trix Gleisbox auch über einen CAN Bus verbunden. Ich würde deshalb erwarten, daß auch das gleiche Protokoll gesprochen wird. Kann nicht auch die Trix MS2 an die Märklin Komponenten angeschlossen werden? Ich meine, ja. Ich glaub ich hab da schon gelesen, daß der hauptsächliche Unterschied die Farbe Rot durch Grün ersetzt wird. Die Märklin Gleisbox kann ja auch schon DCC als Gleissignal erzeugen.
Dann wären dann beide Versionen auch vom Protokoll auf dem CAN Bus identisch. Und damit kannst du das Ganze auch mit den Trix Komponenten kombinieren.
Der Unterschied zw. MS2 von Tr*x (grün) und M*rklin (rot) ist die Farbe des Drehknopfes und natürlich die Bestellnummer. Da meine Tr*x-MS2 eine niedrigere Serenennummer als die M*rklin-MS2 hatte, wurde die Tr*x, sobald sie angestöpsenlt wurde, zum Master (obwohl später gekauft) und ich musste alle Loks im Tr*x-Master neu anlegen, die standen dann auch am M*rklin-Slave zur Verfügung. Die Gleisbox ist identisch.
Gruß Alf
Pickel-Bahner seit 1958 / K-Gleis + ZIMO-Decoder (MX633P22/MX645P22) RocRail & RocNetNode jeweils auf RasPi Email bezüglich MobaLedLib-Belange: LedLib@yahoo.com
„Es hat nie einen Mann gegeben, der für die Behandlung von Einzelheiten so begabt gewesen wäre. Wenn er sich mit den kleinsten Dingen abgab, so tat er das in der Überzeugung, daß ihre Vielheit die großen zuwege bringt.“ Friedrich II. über Fr. Wilhelm I.
Servus Erich [quote="Erich Müller" post_id=1921053 time=1546844226 user_id=26147] Du darfst Märklin und Trix gern ausschreiben. https://stummiforum.de/viewtopic.php?f=14&t=157628 [/quote] danke das ich darf, werde aber trotzdem nicht
Gruß Alf
Pickel-Bahner seit 1958 / K-Gleis + ZIMO-Decoder (MX633P22/MX645P22) RocRail & RocNetNode jeweils auf RasPi Email bezüglich MobaLedLib-Belange: LedLib@yahoo.com
ZitatDer Unterschied zw. MS2 von Tr*x (grün) und M*rklin (rot) ist die Farbe des Drehknopfes und natürlich die Bestellnummer. Da meine Tr*x-MS2 eine niedrigere Serenennummer als die M*rklin-MS2 hatte, wurde die Tr*x, sobald sie angestöpsenlt wurde, zum Master (obwohl später gekauft) und ich musste alle Loks im Tr*x-Master neu anlegen, die standen dann auch am M*rklin-Slave zur Verfügung. Die Gleisbox ist identisch.
Dake für die Info. Dann hab ich das richtig in Erinnerung gehabt.
Damit ist klar, daß das Ganze auch mit den Trix Komponenten funktioniert.
Genau. Damit ist die Trix MS2 mit der Trix Gleisbox auch über einen CAN Bus verbunden. Ich würde deshalb erwarten, daß auch das gleiche Protokoll gesprochen wird. Kann nicht auch die Trix MS2 an die Märklin Komponenten angeschlossen werden? Ich meine, ja. Ich glaub ich hab da schon gelesen, daß der hauptsächliche Unterschied die Farbe Rot durch Grün ersetzt wird. Die Märklin Gleisbox kann ja auch schon DCC als Gleissignal erzeugen.
Dann wären dann beide Versionen auch vom Protokoll auf dem CAN Bus identisch. Und damit kannst du das Ganze auch mit den Trix Komponenten kombinieren.
Tschüß Michael
ok ich danke für die Antworten... dann schaue ich mir dieses projekt hier nochmal genauer an
Zitatok ich danke für die Antworten... dann schaue ich mir dieses projekt hier nochmal genauer an
Gern. Bitte berücksichtige, daß die aktuelle Version einen Fehler im Erzeugen der lokomotive.cs2 aus den Lokinfos der MS2 hat. Die Lokfunktionen werden noicht korrekt geschrieben. Eine aktualisierte Version ist zur Zeit im Test. Dort kommt auch die Konfiguration von CAN Geräten hinzu, wenn sie ihre Konfigwerte melden.
Zitatok ich danke für die Antworten... dann schaue ich mir dieses projekt hier nochmal genauer an
Gern. Bitte berücksichtige, daß die aktuelle Version einen Fehler im Erzeugen der lokomotive.cs2 aus den Lokinfos der MS2 hat. Die Lokfunktionen werden noicht korrekt geschrieben. Eine aktualisierte Version ist zur Zeit im Test. Dort kommt auch die Konfiguration von CAN Geräten hinzu, wenn sie ihre Konfigwerte melden.
Bei Problemen kannst du mich gern ansprechen.
Tschüß Michael
Alles gut...das wird wohl auch noch ein wenig dauern bis ich mir das system anschaffe...und wenn will ich sehr wahrscheinlich das ganze mit nem zweileiter system in Spur N nutzen. Dazu kommt dann wohl nix von märklin zum einsatz...
ZitatAlles gut...das wird wohl auch noch ein wenig dauern bis ich mir das system anschaffe...
Dann hab ich bestimmt schon ein neues Release mit dem Bugfix veröffentlicht. Und wie in der Softwareentwicklung üblich, mit neuen Fehlern
Ich hab aber auch Anwender, die bewreit sind, neue Version testen. Damit kann ich dann Rückmeldung über dinge bekommen, an die ich beim Test bisher nicht gedacht hab.
Zitatund wenn will ich sehr wahrscheinlich das ganze mit nem zweileiter system in Spur N nutzen. Dazu kommt dann wohl nix von märklin zum einsatz...
Dann hast du keine mfx Anmeldung, was (bisher) der wichtigste Grund ist, die Lokliste von der MS2 zu holen. Denn dann macht sie auch die mfx Anmeldung. Aber auch für DCC kann es eine Option sein, die Loks von der MS2 zu holen.
Ich bin dann sehr gespannt auf deine Erfahrungen. Bisher hab ich keine Erfahrungen oder Rückmeldungen für einen Einsatz im Zweileiter System.
:
)
Ja, die die Rentenversicherung meinen "Vertrag" einsietig von 65 auf 67 - 2 Monate verlängert hat, kann ich mir Kalk noch lange nicht leisten.
