Projekt Stellwerk Raspberry

  • Hallo liebe Raspberry-Community,

    danke für eure schnelle Hilfe bei meinen ersten Testversuchen.
    Jetzt geht es bei meinen Projekt weiter und mir fehlen ein paar Denkanstöße wie ich es realisieren soll.
    Meine Aufgabe ist es eine Datenbank auf den Raspberry Pi zu hinterlegen oder abrufbar zu machen.
    Wenn ich einen gewissen Taster oder ähnliches betätige, soll die dafür in der Datenbank hinterlegte Abfolge erfolgen, wenn die dafür festgelegten Voraussetzungen erfüllt sind( z.B. Schalter 1 und Schalter 2 wurden betätigt).
    Im Grundzustand soll eine Rote LED brennen. Wenn der Taster betätigt wurde soll der Raspberry so lange warten bis die anderen 2 Schalter betätigt werden und dann soll ein Servo umlaufen (Gradzahl muss in der Datenbank hinterlegt sein). Wenn der Servo in der richtigen Stellung ist, soll die rote LED aus gehen und dafür die Grüne LED angehen. Wenn ich den Taster nochmal drücke, soll die Grüne LED ausgehen und die Rote LED wieder an.

    Wie realisiere ich das, dass der Respberry Pi Zero W mit der Datenbank (MySQL) dieses kleine Projekt realisiert?

    Bin leider ein Anfänger aber mir wurde das Projekt jetzt in den Schoss gelegt.

    Habt ihr kleine Hilfen für mich?

    Danke schon mal im voraus.

    PS.: Ich möchte nicht das ihr den ganzen Quellcode für mich schreibt. Aber mir vlt ein paar Hilfen gibt im Bezug auf die Datenbankabfrage.

    Einmal editiert, zuletzt von DB Nico (12. Juni 2020 um 11:50)

  • Warum das in einer DB sein soll erschließt sich mir nicht, das ganze könnte man doch auch als Attribute in einer Klasse (Python) fest halten. Aber ok, so ist es nunmal gefordert

    Als Programmiersprache würd ich dir Python empfehlen,

    zum Ansprechen der Datenbank Peewee und zum steuern der LED und Servo gpiozero

  • Warum das in einer DB sein soll erschließt sich mir nicht

    Nach dem Titel und wem "(radzahl muss in der Datenbank hinterlegt sein)" scheint es eine Datenbank zu sein,in der Zugbewegungen und Fahrstraßen hinterlegt sind. (Ich würde, wenn ich denn wüsste, wie die DB für die Fahrstraßen aufgebaut werden sollte) drei Datenbanken nehmen.

    Eine, in der die Züge hinterlegt werden. Mit Anzahl der gefahrenen Wagen, und so weiter, und eine andere mit den Fahrstraßen, und die dritte für die Für die Verknüpfung Zug, Start, Ziel und Fahrstraße.

    Diese wäre die sich am häufigsten ändernde DB

    Es wird ein Fahrplan erstellt, der in der dritten DB hinterlegt wird.

    Dann wird die Fahrstraße eingestellt und der Zug gestartet.

    So, und jetzt das ganze noch umsetzen ;)

    Computer ..... grrrrrr

  • Es ist ja nur der erste Schritt. Am Ende sollen hinter einer ID in der Datenbank mehrere Servos und LEDs stehen. Und es sollen mehrere Taster geben die unterschiedliche ID abrufen sollen.
    Ja das ist mir klar, nur wie baue ich das in den Quellcode ein?
    Wie rufe ich z.B wenn Taster 1 gedrückt ist die ID 5 von der Datenbank ab und die ID 5 gibt dem Raspberry vor welcher Servo und welche LED angesteuert werden müssen?
    Klar als Attribute in einer klasse wäre das möglich für diesen fall aber wenn ich 100 klassen habe mit jeweils 10 Attributen wird das irgendwann unübersichtlich.

    Einmal editiert, zuletzt von DB Nico (12. Juni 2020 um 11:57)

  • Ungefähr so sollte es am Ende auch sein. Nur ich möchte jetzt erstmal nur die Stellwerkslogik im Rapberry Pi simulieren.
    Der Raspberry gibt dann die Befehle an einen Arduino Uno weiter und der Stellt dann den Servo (Weiche) und die LED(Signal) um.
    Ich brauche jetzt bloß einen Ansatz wie ich aus der Datenbank mit der ID den Raspberry sage:" ID 5 aktiviert... warte auf Schalter 1 und 2.... gebe dann die Befehle weiter an Arduino das Servo und LED umgeschalten werden."

    Und das war ein Schreibfehler... sollte Gradzahl heißen

  • aktivier_Taster (primary Key)IDbenötigte Schalter
    151, 2

    In der Funktion wo du die callback erhältst, ließt du die Tasternummer aus

    Die Tasternummer setzt du in die WHERE Klausel und sucht damit die aktivier_Taster

    Dadurch, da es ein primary Key ist, erhältst du genau einen Datensatz -> Die ID und die benötigten Schalter

    Die Ausgabe der Schalter jagst du durch eine split Funktion so dass es eine Liste mit Schaltern ergibt

    Und damit baust du die Logik zusammen auf welche Schalter du wartest

  • aktivier_Taster (primary Key)IDbenötigte Schalter
    151, 2

    In der Funktion wo du die callback erhältst, ließt du die Tasternummer aus

    Die Tasternummer setzt du in die WHERE Klausel und sucht damit die aktivier_Taster

    Dadurch, da es ein primary Key ist, erhältst du genau einen Datensatz -> Die ID und die benötigten Schalter

    Die Ausgabe der Schalter jagst du durch eine split Funktion so dass es eine Liste mit Schaltern ergibt

    Und damit baust du die Logik zusammen auf welche Schalter du wartest

    Danke
    Ich arbeite an den Quellcode und wenn ich da weitergekommen bin poste ich den hier rein :)

  • Ich wuerde da erstmal noch einen Schritt zuruecktreten, und das grosse und Ganze betrachten. Du hast hier offensichtlich vor, eine Ablaufsteuerung zu programmieren, die abhaengig von diversen Eingaben, aber auch der Zeit ist. Denn sowas wie zB das Servo, da bekommst du ja gar kein Feedback. Ausser du hast einen End/Positionsschalter.

    Und auch wenn man dazu eine Datenbank nehmen kann, die Konfiguration fuer sowas abzulegen, wuerde ich zuerstmal damit beginnen, eine datengetriebene Steuerung zu machen. Denn so vermischst du hier die Persistenzschicht mit der eigentlichen Logik - und ich bin mir sehr sicher, dass du dich verheddern wirst.

    Die Modellierung von Hofei ist aus meiner Sicht auch nicht zielfuehrend (sorry).

    Denn sie modelliert nicht, was wirklich noetig ist: nur ein aktiver Taster ist offensichlich nicht ausreichend.

    Du hast einen ist-Zustand des Systems (ZB IDLE). Aus dem kommst du mit bestimmten Bedingungen (in diesem Fall 1 Taster) in einen naechsten Zustand, zB FAHRT_FREI. Und aus dem FAHRT_FREI Zustand kommst du unter bestimmten Bedingunen in eine dritten Zustand, FAHRT_AUFGENOMMEN. Aber das sind schon mehrere Taster! Und aus dem wieder zurueck nach IDLE. Oder aehnliches. Und waehrend des ganzen rumgewechsels muessen ja auch noch Dinge ausgeloest werden

    Und damit kommen wir in der Modellierung auf vier Aspekte:

    - Aktueller Zustand

    - Bedingungen zum Wechsel in einen anderen Zustand

    - Zielzustand

    - Seiteneffekte

    Sowohl die Bedingungen als auch die Seiteneffekte stehen dabei in ein 1:n-Beziehung zum aktuellen Zustand. Und das modelliert man mit 1:n-Tabellen, nicht Feldiern, in denen man frei Strings mit Kommas trennt. Wenn man das macht, kann man auch gleich eine Konfigurationsdatei statt Datenbank nehmen. Was ich im uebrigen auch fuer besser halte, aber es soll ja augenscheinlich zwingend eine DB sein.

    Und die verschiedenen Effekte und Bedingungen haben auch noch verschiedene Typen: es gibt binaere Eingaben (Schalter), es gibt Timeouts, es gibt binaere Ausgaben, es gibt reellwertige Ausgaben (Servo). Da muss also auch bei den Tabellen ein bisschen mehr Hirnschmalz rein.

    Und damit man sich dessen ueberhaupt gewahr wird, und dafuer ein Gefuehl bekommt, baut man sich *erstmal* eine Steuerung. Und denkt dann darueber nach, wie man die Daten in einer DB darstellt.

    Einmal editiert, zuletzt von MistyFlower59469 (12. Juni 2020 um 13:21)

  • Wie komplex und realitätsnah soll das Ganze denn werden? Wie viele Elemente wird das Ganze haben, wenn es fertig ist? Hast Du die Logik schon fertig und willst dies nun "nur noch" in Software umsetzen? Was haben denn die Schalter1&2 welche du betätigen willst und der Servo für einen Zweck? Eigentlich müsste es doch so ablaufen: Man drückt einen Taster für den Start und das Ziel. Dann muss geprüft werden, welche Elemente für diese Fahrstraße und in welchem Zustand gebraucht werden. Sind alle Bedingungen erfüllt, müssen alle Elemente die Bestandteil dieser Fahrstraße sind, gegen versehentliche Bedienung geschützt und auf ordnungsgemäße Funktion überwacht werden, erst kann das Signal auf Fahrt geschaltet werden.

  • Hallo :)
    danke für den Denkanstoß @__deets__ .
    Ich habe mir dazu Gedanken gemacht und am Wochenende die Gesamtlogik betrachtet und einen Programmablaufplan erstellt.
    Diesen muss ich jetzt in Phyton umsetzten nur fehlen mir dazu die Skills. Leider muss ich diese Woche schon ein Ergebnis vorlegen. Die Stellwerkslogik soll schon funktionieren.
    Ich versuche mich gerade durch die ganzen Basics zu hangeln aber komme leider nicht weiter.


    Den Programmablaufplan kann ich hier leider nicht reinstellen weil er die Endung pap hat :/
    Sonst würde ich den euch gerne zeigen.
    Wenn jemand dennoch Interesse daran hat mir intensiver zu helfen, sende ich den gerne per eMail.
    Edit: Habe jetzt eine PDF angefügt.

    Fliegenhals das ganze soll sehr größ werden. Ich habe mal den Gesamtaufbau des Models im Anhang gelegt. Und dafür soll ich mit dem Raspberry Pi und den Arduino Uno die Stellwerkslogiken realisieren. Es soll am ende eine Schulungsumgebung für Fdl und LST werden. Diese Stellwerke sollen mit Pulten geschalten werden und darunter sollen die 2 Controller alles steuern.
    Aber erstmal soll ein Stellwerk funktionieren damit ich was vorzuweisen habe.

  • Wenn das Ganze für die Ausbildung gedacht ist, so sollte sich die Anlage ziemlich nahe an der Realität orientieren. Im Rahmen von was einer (deiner) Ausbildung soll dieses Projekt denn entstehen? K.A. wieviel Zeit du schon für die Umsetzung hattest, aber ich vermute mal das eine Woche sehr optimistisch ( eigentlich eher unrealistisch ) bei dem aktuellen Stand und der Komplexität ist. Soll es denn eine Simulation für ein ESTW o. ein Drucktasten STW werden? Ich kann mit den Schaltern welche du betätigen willst bzw. dem Servo nichts anfangen. Gibt es denn schon so etwas wie einen Verschlußplan oder eine Signaltabelle?

    Einmal editiert, zuletzt von Fliegenhals (15. Juni 2020 um 18:46)

  • Ein Bahnhof soll ein ESTW simulieren das über ein Pult gesteuert wird. Ein anderes soll ein Mechanisches Stellwerk simulieren und die 2 anderen ein GS2 Stellwerk. Pläne sind alle schon vorhanden. Jetzt muss die Planung nur auf die Pulte übertragen werden und die Controller Programmiert werden.

    Programmablauf ist auch schon bekannt...nur die Umsetzung bereitet mir Schwierigkeiten.

  • Mit einer solchen Beschreibung kann man da auch leider nicht mehr beitragen. Auch nicht im Zusammenhang mit den oben präsentierten PAPs, die konfus und lückenhaft sind. Selbst wenn hier jemand die Zeit hätte, dir das hinzuschreiben - es reicht nicht. Dazu ist das viel zu dünn.

    Wir können Fehler besprechen, wir können Konzepte erklären, aber das geht nur, wenn du konkret wirst. Welche Sensoren und aktuatoren hast du? Kannst du die alle einlesen und ansteuern? Brauchst du obendrein Nutzer Eingaben am Bildschirm? Das sind erstmal die Basics, ohne die zu meistern du nirgends hinkommst.

    Einmal editiert, zuletzt von MistyFlower59469 (16. Juni 2020 um 10:19)

  • Ein Bahnhof soll ein ESTW simulieren das über ein Pult gesteuert wird. Ein anderes soll ein Mechanisches Stellwerk simulieren und die 2 anderen ein GS2 Stellwerk. Pläne sind alle schon vorhanden. Jetzt muss die Planung nur auf die Pulte übertragen werden und die Controller Programmiert werden.

    Programmablauf ist auch schon bekannt...nur die Umsetzung bereitet mir Schwierigkeiten.

    Ich befürcht mal, das Du ( Ihr ) das Pferd von hinten aufzäumt, auch sind die Konzepte der Sicherungstechnik im ESTW bzw. zwischen anderen Techniken unterschiedlich. Ich hab mir mal den Programmablauf angesehen und so einige Dinge gesehen, welche mich etwas verwundern. Da kann ich nur __deets__ Aussage zustimmen.

    Mit einer solchen of Beschreibung kann man da auch leider nicht mehr beitragen. Auch nicht im Zusammenhang mit den oben präsentierten PAPs, die konfus und lückenhaft sind. Selbst wenn hier jemand die Zeit hätte, dir das hinzuschreiben - es reicht nicht. Dazu ist das viel zu dünn.

    Wir können Fehler besprechen, wir können Konzepte erklären, aber das geht nur, wenn du konkret wirst. Welche Sensoren und aktuatoren hast du? Kannst du die alle einlesen und ansteuern? Brauchst du obendrein Nutzer Eingaben am Bildschirm? Das sind erstmal die Basics, ohne die zu meistern du nirgends hinkommst.

  • Ok ich versuche euch das ganze Projekt nochmal näher zu bringen.

    Das Projekt soll für die Zukünftige Ausbildung Für FDL und LST MA werden, daher sehr realitätsnah.
    Den Gesamtaufbau habt Ihr von mir schon bekommen.
    Es gibt eine Zugleitstrecke (Strecke 1342) und 2 "normale Strecken.
    Die "Hauptbahnhöfe" sind daher Chausen, Fheim und Eburg.
    Chausen soll ein mechnanisches Stellwerk Simulieren, Fheim ein ESTW und Eburg ein GS II.
    Für jeden Bahnhof wurden die erforderlichen Dokemente erstellt.

    Wie stellen wir uns die Realisierung vor?

    Es gibt einen Master Raspberry und pro Bahnhof einen Raspberry(MASTER) geben der dort die Befehle an den Arduino Uno(SLAVE) erteilt. Dieser Arduino stellt die ganzen Komponenten(erstmal nur Weichen und SIgnale). Die Eingabe erfolgt durch Pulte. Für den Bahnhof Fheim und Eburg wurden Pulte angefertigt. Diese werden mit Taster versehen die die Eingänge vom Raspberry Pi sind. Dieser gibt dann den Befehl weiter zum Arduino und dieser stellt dann die Weichen und Signale um. Davor muss der Fahrtweg frei sein (durch drücken einen Tasters realisiert [später bei Fheim mit Achszählern und bei Eburg mit Iso Schiene realisiert]). Also der Ablauf: Befehlsempfang - prüfen des Fahrwegs - Weichen stellen - Fahrstraße festlegen - Fahrweg prüfen - Signal geht auf Fahrt. Jeder Schritt bedarf einer Eingabe durch 1 oder 2 Taster. Danach wird die Fahrstraße aufgelöst und das Signal geht auf Halt. Die Weichen bleiben in der Stellung. Anlage wartet auf den nächsten Befehl. Die Programmierung der beiden Bahnhöfe ist identisch, da wir beim ESTW die grafische Oberfläche erstmal weglassen. Es wird wie beim GS II mit einen Pult geschalten.

    In Chausen werden mechanische Hebel mit Schiebeschaltern realisiert. Der Bahnhofsblock wird mithilfe von Drucktastern und LEDs simuliert. Die Fahrstraßenfestlegung wird mit 3 Stufen Schalter realisiert die die 3 Stellungen des Fahrstraßenhebels wiederspiegeln.

    Dort ist die Abfolge so: Befehlsempfang - B1 prüfen des Fahrwegs - Weichen stellen - Fahrstraße festlegen - Befehl für die Fahrstraße an W2 senden - prüfen des Fahrtwegs - Weichen stellen - Fahrstraße festgelegt - Prüfen der Fahrstraße - Rückmeldung an B1 - Signal geht auf Fahrt.

    Wer gibt den Befehl?
    Jede Fahrt bekommt eine ID. Die ID muss beim Master Raspberry hinterlget sein. Er gibt nach Eingabe der ID nach und nach den anderen Raspberrys den Befehl welche Fahrstraße gerade gebraucht wird. Diese geben das dann den Arduino weiter und der wartet auf die Eingabe von außen. Danach muss eine Rückmeldung zum Master Raspberry kommen das die Fahrstraße eingestellt wurde und das Signal auf Fahrt gestellt ist. Die verschiedenen ID sind in einer Datenbank hinterlegt der den weiteren Ablauf festlegt.
    Gesamtablauf:

    ID Eingabe am Master Raspberry - Gibt Befehl weiter an den Bahnhof (Raspberry) - Befehlsempfang Fahrstraße XYZ - Abruf der benötigten Weichen und Signalen - Weitergabe an Arduino - Befehlsumsetzung - Rückmeldung an Raspberry Fahrstraße eingestellt und Signal auf Fahrt gestellt - Raspberry gibt an MAster Raspberry eine Befehlsbestätigung - MAster Raspberry bereit für nächste ID.

    So sol es erstmal am Anfang aussehen. Später kommen noch dazu:

    Zugbeeinflussung, Störungen, Mehrere Fahrten gleichzeitig

    Ich hoffe ich konnte euch das Projekt etwas genauer Beschreiben.

    Ich bin gerade über den Bahnhof Chausen und versuche den erstmal hinzubekommen.

  • Ich finde das sehr verwirrend. Nicht nur gibt es mehrere PIs von denen wierderum eine der Master ist, und dann die Arduinos als Slaves. Warum noch ein Master-PI, und warum dann mehrere Nicht-so-ganz-Master-PIs? Und wofuer die Arduinos, wenn die Tasten dann doch schon wieder am PI direkt haengen? Warum wird das nicht alles an den viel robusteren Arduino gehangen? Klingt alles deutlich komplizierter als notwendig.

    Und dann fehlt da natuerlich so manches, wie zB wie Arduino und PI kommunizieren, wie die PIs untereinander kommunizieren. Seriell, I2C, SPI, und WIFI oder LAN?

    Ich wuerde mir die ganze Ebene der PIs in der Mitte sparen.

  • Hallo DB Nico,

    als aufmerksamer Leser dieses Threads muss ich @__deets__ Recht geben: Das Projekt ist unnötig komplex (geworden).

    Eigentlich funktioniert es doch meistens so:

    1. System A will was von System B

    2. System B setzt um und meldet einen Vollzug zurück

    - System B prüft, ob System A überhaupt berechtigt ist, irgendwas zu wollen

    - System B prüft, ob der Wunsch von System A überhaupt erlaubt ist und wenn ja, ob es dann gerade sinnvoll ist

    - System B kommuniziert mit System A über seine Befindlichkeiten

    - im optimalen Fall ist System A berechtigt und der Wunsch in Ordnung - System B setzt um

    3. System A informiert betroffene Systeme von Änderungen

    4. Zurück zu 1 mit wechselnden Systemen

    Sowohl ein "Übersystem" als auch jedes einzelne System ist in der Lage, die aktuelle Situation im Sinne eines Prozessleitsystems anzuzeigen und zu bewerten.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!