RailPi - Warum mit Kanonen auf Spatzen schießen?

[_DB_]

Hallo Gerd,

ist in Ordnung. Ich denke mal, damit sind die allermeisten Fälle abgedeckt. Dann nehme ich es auch auf. Ich bin sehr froh, Hinweise erfahrener und programmierender Modellbahner mit aufnehmen zu können.

Frei nach dem Motto: es kann nur besser werden...

RailPi Vers.2.1.1.pdf

(3.67 MiB) Downloaded 514 times

Apropos besser werden:
Eine Routine um den RailPi herunterzufahren wird noch nachgereicht
(das Diet-Pi-OS kennt den reboot-p bzw. den shutdown-Befehl offensichtlich nicht - auch nicht als root! - momentan funktioniert leider nur der sudo reboot - Befehl)

Vielleicht kann mir jemand einen guten Tip geben wie ich den RailPi sicher herunterfahren kann?
Alte Erfahrungen - selbst die einfachsten - müssen leider nicht immer funktionieren...

Viele Grüße aus Herne - Detlef

[machmalpause]

Hallo Detlef,

deine neue RailPi Dokumentation ist spitze ! Vielen Dank dafür !

Bei mir arbeitet der RailPi (DietPi OS und Waveshare CAN-HAT) sehr stabil zusammen mit 1) RailControl + CAN2LAN oder 2) Rocrail + Direktansteuerung des CAN-HAT. Funktioniert prächtig. Und ich lerne täglich 'was Neues dazu

Jetzt versuche ich seit einigen Tagen, auch den CANguru Server (die neue V2.3 von Gustav) auf dem DietPi OS laufen zu lassen ... also headless ... und das ist mit meinen kläglichen Linux-Kenntnissen bislang gescheitert:

Um die 'CANguru.exe" auszuführen zu können, habe ich mono und den VNC-Server auf dem DietPi OS installiert. Ein Aufruf des CANguru-Servers im virtuellen VNC-Desktop funktioniert prinzipiell (und die Decoder beginnen zu blinken), aber:
- Ich schaffe es nicht, den CANguru-Server per Steuerungs-Software (auf dem RailPi oder per LAN-Client) anzusprechen ?
- Wie kann man denn ein .exe-Programm mit mono aus dem Terminal des DietPI OS heraus starten (bei mir hagelt es da Fehlermeldungen) ?
- Wäre es prinzipiell möglich, den CANguru-Server auch ohne VNC auszuführen, um Ressourcen auf dem DietPi zu sparen ?

Hast du schon Erfahrungen mit Gustav's CANguru-Server auf einem Raspberry gemacht ? Auch in Kombination mit dem DietPi OS ?

Ich hoffe, ich habe das Problem trotz meines nicht vorhandenen Linux-Wissens halbwegs verständlich geschildert, und ich würde mich riesig freuen, wenn du helfen könntest ... ich weiss als Laie nämlich garnicht, wo ich mit der Fehlersuche starten soll.

Viele Grüße,

Franky

[machmalpause]

Hallo Detlef,

ich habe es geschafft, den CANguru Server V2.3 auf dem DietPi OS zu starten

Fündig wurde ich hier:
https://ivanderevianko.com/2020/02/xvfb ... y-browser
http://manpages.ubuntu.com/manpages/tru ... run.1.html

Also 'xvfb' als root installieren mit:
sudo apt-get install xvfb

und dann den CANguru Server im CANguru-Verzeichnis (mit den in 'C:\CANguru\...' umbenannten Dateien) starten mit:
xvfb-run mono ./CANguru.exe &

Weil die neue Version des CANguru-Servers die Bridge selbständig findet und startet, funktioniert das ganz prima. Ansonsten lässt sich der CANguru Server natürlich auch über einen VNC Desktop steuern.

Da ganze scheint mit Rocrail ganz gut zu funktionieren. Railcontrol werde ich die Tage testen.

Viele Grüße,

Franky

[_DB_]

Hallo Franky,

vielen Dank für Deine Infos. Ich werde das bei Gelegenheit einmal probieren und in die RailPi-Doku einarbeiten.

Aber ich warte eigentlich darauf, daß Gustav den Schritt vollzieht, und den CANguru Server optional nutzt und die Programmierung der Bridge in einer Art und Weise anpasst, daß es dem can2lan-Dienst von Gerd entspricht.

Das wäre dann - in meinen Augen - echte Modularität. Und für das CANguru-System ein wirklicher Fortschritt/Vorzug.

Mal gucken, was passiert...

... bis dahin noch ein schönes Wochenende - Detlef

[machmalpause]

Hi Detlef,

Jaja, die eigentümliche CAN-Guru Bridge und ihr bockiger Companion (Server) .
Also ... wenn ich mir was wünschen könnte ... :

eine "abgespeckte" CANguru-Bridge, die gänzlich ohne zusätzliche Software arbeiten kann:
- die Bridge initialisiert sich und die Decoder selbstständig, ohne Hilfe externer Programme
- arbeitet als "Daten-Switch" zwischen dem ESPnow der Decoder und der CAN- und/oder LAN-Schnittstelle der Bridge
- zeigt auf dem großen Display live die CAN-Befehle & Infos an

Dazu ein Windows/Linux Programm, das die Bridge & Decoder konfiguriert, und optional eine CS2 Emulation (evtl. mit Lokliste ?) anbietet. Letzteres nutze ich nicht (mehr), denn ich verwende inzwischen für die Gleissignale den Rasperry-CAN-HAT und steuere den direkt in Rocrail an. Bisher ein echtes Dream-Team, ich hatte noch keinerlei hickups.

Viele Grüße,

Franky

PS Meine Test-Anlage nimmt langsam Gestalt an. Du hattest mal erwähnt, dass du einen Masse-Gleisbesetztmelder entworfen hast, der mit dem CANguru-ESP32 Decoder zusammenarbeitet ? Daran hätte großes Interesse ! Momentan bastele ich an dem Strom-Sniffer von Gustav. Der funktioniert gut, allerdings möchte ich noch 3A Dioden austesten, bevor ich en Masse löte.

[bertr2d2]

Hallo Detlef,

Aber ich warte eigentlich darauf, daß Gustav den Schritt vollzieht, und den CANguru Server optional nutzt und die Programmierung der Bridge in einer Art und Weise anpasst, daß es dem can2lan-Dienst von Gerd entspricht.

welchen Vorteil bietet den der CANguru Server ?

Ich fände es besser wenn RailControl SocketCAN direkt unterstützen würde. Dann wäre can2lan für RailControl obsolet.

Gruß

Gerd

[_DB_]

Hallo Gerd,

ich denke mal, daß das genau das ist, was ich meine:

die CANguru-Bridge sollte Socket-CAN direkt unterstützen um die gleiche Aufgabe zu erfüllen, die auch can2lan für das LAN erledigt. Sozusagen als can2esp-now...

Gustav nutzt win-digipet und nach meinem Verständnis kommuniziert Win-Digipet mit dem Webserver des CANguru-Servers - nicht mit der Bridge direkt.

Die Bridge arbeitet bereits jetzt weitgehend selbständig parallel zum CANguru-Server, kann jedoch keine Steuerspannung ein- oder ausschalten. Das z.B. übernimmt der CANguru-Server z.Zt. noch.

Um ein konkretes Beispiel zu nennen:
Auf meiner Anlage werden die CdB-Komponenten (Gleisbesetztmelder) über das Welectron-CAN-Hat und Deiner can2lan-Software ausgelesen. Und zusätzlich wird mindestens der Befehl Steuerspannung EIN/AUS (oder auch Booster ein/aus) über diesen Weg übertragen.

Die Weichen mit Märklin- bzw. Viessmann-Dekoder und die Loks fahre ich zur Zeit bereits über die CANguru-Bridge (mehr ist momentan vom CANguru-System bei mir auch nicht vorhanden).

Wenn ich es richtig verstanden habe, benötige ich den CANguru-Server, sobald ich das CANguru-System (über ESP-now) weiter ausbauen würde. Oder, ganz anderer Ansatz: ich müsste neben der CANguru-Bridge eine zweite Zentrale vorhalten, nur um darüber die Steuerspannung ein- bzw. auszuschalten.

Der CANguru-Server stellt sich somit für mich zur Zeit als eine ziemlich störende (aber lebensnotwendige) Software dar, wenn ich ausschließlich die CANguru-Bridge als Zentrale nutzen möchte. Darüber hinaus ist der CANguru-Server für Windows geschrieben und unter Linux nur mittels zusätzlicher Software nutzbar.

Es wäre natürlich phantastisch, wenn sich Gustav einmal mit Dir (oder umgekehrt) in Verbindung setzen würde... ein CAN2ESP analog zu Deinem CAN2LAN wäre ein echter Fortschritt in Sachen Modularität und Erweiterung der Vielfalt einsetzbarer Komponenten...

Ich versuche das mal einzustielen und schreibe Gustav einmal. Für Dich an dieser Stelle: Du kannst ihn gern über Github unter 'CANguru-System' erreichen.

Das wär's erst einmal für heute - ein schönes Rest-Wochenende noch! - Detlef

[machmalpause]

Hallo,

Ich klinke mich mal eben ein.

Also so wie ich das jetzige CANguru-System als Newbie verstehe, hat die "CANguru Server Software" (Windows only !) ganz grob zwei Aufgabenbereiche:

1. Initialisierung der Bridge sowie der Decoder und deren Konfigurierung
2. Im Betrieb: eine quasi "Can2Lan"-Funktion, nämlich die CAN-Daten, die die Bridge von ihrem hardwareseitigen CAN-Anschluß sowie dem ESPnow-Funknetz (zwischen Bridge und Decodern) zur LAN-Schnittstelle schickt, als eine CS2 Emulation anzubieten.

Einen Zugriff auf das CANguru-System hat man derzeit also ausschließlich über die CS2-Emulation, die dummerweise ausschließlich unter Windows läuft (bzw. mit Ressourcen-hungrigen Kniffen auch unter Linux).

Was ich mir für zukünftige Versionen vorstellen könnte bzw. wünschen würde:

1. "CANguru Server Soft": eine abgespeckte Version für Linux

2. Bridge-Firmware: die Bridge könnte, nach dem Einschalten, sich und die Decoder eigenständig initialisieren. Praktisch wäre eine Synchronisation der CAN-Daten zwischen dem ESPnow-Funknetz und dem Hardware-CAN-Anschluß (anstelle oder zusätzlich zum LAN). Das würde Steuerprogrammen, die direkt auf den CAN-Bus zugreifen können, einen Betrieb gänzlich ohne Emulation ermöglichen.

Ich bin gespannt, wie sich dieses super spannende Projekt weiter entwickeln wird. Derweil bastele ich weiter an meiner Testanlage ... Baustellen ohne Ende !

Schönes Wochenende & viele Grüße,

Franky

[_DB_]

Ich fände es besser wenn RailControl SocketCAN direkt unterstützen würde. Dann wäre can2lan für RailControl obsolet.

Hallo Gerd,

sorry, in meiner letzten Antwort habe ich 'ein wenig' an der Fragestellung vorbei geantwortet.

Wenn ich Dich richtig verstanden habe, dann sollte Teddy RailControl um die SocketCAN-Funktionalität erweitern.

Auf der einen Seite fände ich es für meine Anlage optimal, auf der anderen Seite würde ich generell eine Modularität bevorzugen: derjenige, der SocketCAN nicht benötigt, wird ein mächtigeres RailControl nicht benötigen. Und - ich bin wahrhaftig kein Programmierer: Ein modularer Ansatz zieht von der Hardware (konkret einem Pi) immer nur die Ressourcen, die tatsächlich benötigt werden.

Ich meine, daß es in der Modellbahnwelt viel zu viele Standards gibt. Aber es gibt sie halt. Und sie lassen sich eben nicht durch eine allumfassende Lösung unter einen Hut bringen, oder? Aber es sollten genügend viele modulare Lösungen existieren, um so ziemlich jede mögliche Anlagenkonfiguration abbilden zu können.

Teddy ist - so denke ich - auf einem guten Weg. Und Du bist es ebenfalls mit can2lan. Und - ich hoffe es jedenfalls - daß das CANguru-System in dieser Hinsicht ebenfalls weitgehend kompatibel wird (wie bereits gepostet: die CANguru-Bridge läuft schon jetzt in meiner Anlage vollständig OHNE CANguru-Server - nur die Funktionalität Steuerspannung EIN/AUS fehlt noch).

Wie mehrfach erwähnt bin ich kein Programmierer, deshalb möchte ich an dieser Stelle die Frage stellen:
Was bedeutet die SocketCAN-Funktionalität denn konkret überhaupt? Nicht, daß ich schon wieder voll am Ziel vorbeisause...

Einen windgeschützten angenehmen Sonntag noch - Detlef

[machmalpause]

Hallo Detlef,

Ich bin zwar erst seit wenigen Wochen mit dabei, aber ich versuche, den Datenfluss nach meinem Verständnis mal "grafisch" zu skizzieren:

Can2Lan ermöglicht RailControl, einen CAN-Bus als emulierte CS2 anzusteuern:

RailControl [CS2] <-> Can2Lan <-> CAN

Gerd schlägt nun vor, dass RailControl um SocketCan erweitert wird, denn dann könnte das Programm DIREKT auf den CAN-Bus zugreifen, und Can2Lan wäre obsolet. (übrigens macht Rocrail genau das: Rocrail [SocketCan] <-> CAN )

Bezüglich dem CANguru-System: Hier übernimmt die Firmware der CANguru-Bridge den Austausch der CAN-Daten zwischen ihrem LAN-Anschluss und 1) ihrer CAN-Schnittstelle und 2) der Funk(ESPnow)-Decoder.
Extrem lästig ist dabei der Umstand, dass die CANguru-Bridge eigens mit der Windows-Software "CANguru-Server" vom Zielrechner aus (!) gestartet werden muss, denn sie "lernt" bei der Initialisierung die IP-Ziel-Adresse. Danach kann der "CANguru-Server" ggf. beendet werden, wenn man auf einige "Live"-Features wie CS2-Emulation, Loklisten etc verzichten kann.

Momentan scheint die CANguru-Bridge die CAN-Funkdaten der Decoder leider nur an ihrem LAN-Anschluss bereitzustellen. Würde die CANguru-Bridge ihre Daten wahlweise auch zu ihrem CAN-Anschluss "durchreichen", dann wäre (irgendwann ?) folgendes sehr smarte (Zukunfts-?)Szenario möglich:

RailControl [SocketCan] <-> CAN-Port der CANguru-Bridge

Das wäre dann ein DIREKTER Datenaustausch, ganz ohne Can2Lan oder CANguru-Server !!!

Ich hoffe, meine kleine Skizzierung ist hilfreich und in meinem Denkansatz steckt kein grober Fehler ... ???

Viele Grüße,

Franky

[bertr2d2]

Hallo Franky,

vielen Dank für Deine Erläuterungen. So habe ich es auch verstanden.

SocketCAN ist der Standard unter Linux zur Verwendung der CAN Schnittstelle. Durch die breite Masse der unterstützen Interfaces und die große Anzahl der Nutzer ergibt sich eine einfache Verwendung und ein hohe Qualität der Treiber.

Ich kann Teddy verstehen, das er SocketCAN (noch) nicht verwenden will - es läuft ja auch ohne prima. Aber die direkte Unterstützung hätte den Vorteil das mögliche Fehlerquellen (can2lan oder CANguru Server) eliminiert wären.

Gruß

Gerd

[Modellbauhütte]

Bei neueren Versionen von can2lan (akt. 1.5) kann man mehrere Interfaces angeben:

Code: Select all

...
can2lan ... -b wlan0,eth0
...

Die Interfaces wlan0 (Wifi) und eth0 (LAN) werden dann reihum abgefragt, ob bzw. bis sie eine gültige Adresse haben. Das erleichtert etwas die Konfiguration und ggf. Wechsel der Anschlussart.

Warum lese ich das denn erst jetzt? Das ist ja viel besser, weil man sich dann nicht entscheiden muss, ob man den SRSEII oder BananaPi über LAN, WLAN oder als AP betreibt.

Das werde ich mal testen!

Gruß
Moritz

[ddebahn]

Hallo zusammen,
habe die Doku von Detlef betreff Rasberry Pi mit DietPi für meine Belange abgeändert. Ich benutze für meine kleine Anlage noch ein TwinCenter. Im Anhang die Doku dazu.

wie immer schöne Grüße aus dem Emsland
Dieter

[_DB_]

Moin Agent Smith,

fein, Dich jetzt auf dem RailControl-Forum zu treffen.

Ich habe bei dieser Antwort festgestellt, daß die PDF-Dateien meiner Beiträge nicht mehr bzw. nur noch sehr schlecht lesbar sind.

@Teddy: Ist da ein Kompressor über die Daten gelaufen?

Ich hänge erst einmal die beiden wichtigsten Dateien neu an und möchte Dich bitten, sie einmal zu sichten. Vermutlich werden Deine Fragen dort beantwortet. Und wenn weitere Fragen aufkommen, stehe ich Dir gern zur Verfügung.

Ich leite meine S88-Signale auf Dekoder von CdB (CANdigitalBahn - Projekt - http://can-digital-bahn.com/modul.php?s ... 26#Mod_Top). Hier werden die Signale nicht nur von binär auf CAN-Protokoll umgesetzt, sondern, wie Gerd das zuvor bereits angemerkt hat, galvanisch entkoppelt.

Das Schöne am CAN-Bus ist ja, daß jeder Teilnehmer mit jedem anderem Teilnehmer sprechen kann. Und Gerds CAN2LAN sorgt dafür, daß der Raspberry Pi mit der WAVESHARE-Schnittstelle auch RailControl am Gespräch beteiligen kann. Tolle Sache!

Und da RailControl wiederum vielerlei Systeme nutzen kann, habe ich zum bestehenden System (ohne Gleisbox) einfach mal das auf dem Arduino laufende DCC-EX hinzugenommen. Streiche Gleisbox, setze Arduino —> super. Allerdings nur noch mit dem DCC-Protokoll. MFX geht dann nicht mehr (irgendwie fehlt die Gleisbox dann doch .

Viele Grüße aus Herne - Detlef

[teddy]

Ich habe bei dieser Antwort festgestellt, daß die PDF-Dateien meiner Beiträge nicht mehr bzw. nur noch sehr schlecht lesbar sind.

@Teddy: Ist da ein Kompressor über die Daten gelaufen?

Ich hab zumindest nichts extra eingebaut oder aktiv komprimiert...

Gruss
Teddy

[_DB_]

Hallo Teddy,

ich habe mal ein ScreenCopy des heutigen Beitrages gemacht:

und dann ein ScreenCopy des alten Beitrages:

Auch das PDF von Dieter ist ähnlich 'verhunzt'.

Viele Grüße aus Herne, Detlef

[teddy]

Hoi Detlef

Also das einzige was ich mir vorstellen könnte ist, dass etwas schief gegangen ist, als ich die Hompage inkl. Forum auf einen neuen Server zügeln musste im Juni. Da hab ich mir ehrlich gesagt nicht angeschaut, ob die PDFs auch korrekt übertragen wurden.
Aber das wäre dann definitiv nicht mit Absicht entstanden.

Gruss
Teddy

[_DB_]

Hallo Teddy,

bitte nicht falsch verstehen: es sollte nur eine Meldung sein, daß da etwas falsch gelaufen ist - ganz ohne Wertung!

Ich habe aus diesem Grund die beiden mir 'wichtigen' PDF-Dateien erneuert. Das sollte dann auch Dieter tun, er hat ja auch schon viel Arbeit in seine Anleitungen investiert. Ich informiere ihn mal...

Viele Grüße aus Herne - Detlef