Überlegungen und Working an eigener Standsoftware

Hallo liebes Forum,

ich bin jetzt gerade an einem neuen Projekt dran, einer eigenen Software für die alten Meyton-Stände, die über RS232 angeschlossen wurden (der runde Amphenol-Tuchel-Stecker).

wie ich hier schon geschrieben habe, plane ich die Umsetzung so, dass im Endeffekt nur der aktuelle Rechner am Stand ersetzt werden soll, um die Stände auch ohne Meyton-Software nutzbar zu bekommen. An dieser Stelle wird es vmtl. ein Raspberry Pi 3 oder 4 werden, was genau weis ich noch nicht, dazu dann ein Zusatzboard für die ganze Peripherie, alles in allem aber recht überschaubar der Hardware-Aufwand.

Im weiteren ist natürlich dann auch eine Management-Software geplant, die vmtl. auch auf einem Pi oder einem kleinen Rechner als Server laufen soll und dann von einem beliebigen Endgerät aus über den Browser gesteuert werden kann. Dazu soll es dann auch eine Visuallisierungssoftware geben, die dann für TV oder Beamer das Bild macht.

Das Problem ist für mich aktuell eher die Software. Das ist ein dicker Fisch.

Und daher poste ich hier auch meine Fortschritte, damit die Motivation hoch genug bleibt, damit was draus werden kann.

Aktuell bin ich dran, mir einen passenden Adapter zu bauen, der die RS232-Kommunikation auslesbar macht.
Parallel baue ich gerade ein Webinterface, dass über eine API-Schnittstelle die Daten für die Standanzeige bekommt.

Hier mal ein Bild davon:

Die Schüsse sind absolut willkürlich, da durch eine Zufallsfunktion erstellt, alles andere funktioniert auch schon. Momentan noch auf LG beschränkt, aber ich baue auch schon an einer allgemeinen Version, die dann das Scheibenbild unabhängig zeichnet.

Die ganze Umsetzung wird von mir am Ende/wenn was sinnvoll veröffentlicht werden kann, unter der AGPL veröffentlicht. Dafür muss aber mindestens mal ein Stand ohne alles funktionieren.

Wenn jetzt jemand sagt, die Idee ist gut, dann freue ich mich gerne über Hilfe. Schreibt mir dann einfach eine PN.

Mich würden eure Eindrücke freuen, am liebsten so, dass ich auch weiterhin motiviert bleibe, und das ganze auch zu Ende bringen kann.
In diesem Sinne, kritisiert, am besten Konstruktiv, gerne das Interface für den Schützen am Stand, damit das besser werden kann.


Gruß

SebastianL

Hallo Omega,

das wäre super, momentan fehlt mir nämlich leider selbst der Direktzugang, da ich der Liebe wegen ca 200km von meinem Verein weg bin, und ich hier noch in keinem Verein bin (und die mich dann vermutlich erstmal nicht an ihre Anlagen lassen werden).

Hast du denn Linux-Kenntnisse, das wäre für mich am Anfang wichtig zu wissen, denn je mehr du da kannst, desto früher kann ich dich einbinden.


Ich kann gerne nochmal eine Neukonstruktion des Webinterfaces machen, das näher an Meyton ist. Da alle dargestellten Daten aber eh aus dem API-Aufruf kommt, ist das wahrscheinlich kein großer Akt.
Und noch zu den Serien, das sind tatsächlich Zehnerserieen, nur schießt der Zufall ziemlich miserabel.

Gruß

Sebastian

Omega24v

und da alle Infos aus der Api kommen, ist der Neubau des Interfaces auch kein großes Thema, sind nur ein wenig Javascript und CSS:



hier mal eine etwas dunklere Version, aber ich bin auch kein Grafiker, das sollten andere mal stimmig machen,

Gruß

Sebastian

Hallo,

mich hat heute noch eine Nachricht erreicht, dass auch Disag bei seinen Messrahmen RS232 einsetzt.
Das bedeutet, dass evtl. dann auch die Daten aus RS232 von Disag ausgewertet werden könnten, wodurch mit der Idee meines Systems unter Umständen sogar mehr als nur Meyton-Anlagen mit einem gemeinsamen System gekoppelt werden können.

Gruß
Sebastian

Zitat von Lanfear

Das wäre wäre sicherlich mal ein richtiges Brett. Wenn Du es dann noch schaffst die SETA-Anlagen zu integrieren, feier ich Dich.

eine kurze Internetrecherche hat ergeben, dass die auch mit einer seriellen Schnittstelle Arbeiten, diese aber dann gleich schon auf USB übersetzen (zu sehen an dem Treiber für den Stand, der installiert werden muss CH341 ist ein klassischer USB-Seriell-Wandler) also theoretisch wirklich möglich.

Gruß
Sebastian

PS: aber bitte nicht in nächster Zeit erwarten, dass es so etwas dann tatsächlich auch von mir geben wird, meine erste Priorität sind die alten Meyton-Anlagen! Einzig, wenn der Hersteller mitspielen würde, dann wäre auch eine frühere Einbindung denkbar, weil dann die ganze Arbeit mit dem Protokoll reverse engineeren wegfällt.

Zitat von Omega24v

Im Prinzip geben alle Messrahmen ein Protokoll mit X/Y Koordinaten raus.

Genau darauf baue ich.

In erster Linie werde ich mich jetzt mal um Meyton-Stände kümmern, aber wenn ich ehrlich bin, das Auswerten der direkten Kommunikation ist im Endeffekt nur ca. 1% der Arbeit.

Wenn dann also mal ein lauffähiges System für LG/LP mit Standbelegung und Auswertung da ist, inkl. der ganzen Schützinnenverwaltung, dann kann man sich das gerne als nächstes Vornehmen.

ABER: solange ich keinen funktionierenden Einzelstand habe(Anzeige und RS232-Auswertung), werde ich auch das Projekt nicht veröffentlichen, um dem ganzen nicht von vorn herein die Möglichkeit zu nehmen, sich zu entwickeln.

Gruß
Sebastian

Hallo,

Zitat von FloM

Man könnte die Software in komponenten aufbauen.

Also z.B. den Rahmen mit rs232 auslesen und dazu eine REST schnittstelle bereitstellen.

Die könnte man ja standardisieren, sodass dies dann der einzige Verknüpfungspunkt für die Messrahmen anderer Hersteller ist.

Genau das ist der Plan.

Zitat von FloM

Daran angeschlossen könnte es eine ganze Palette an verschiedener open source software geben.

Dein Auswertungsprogramm,

Ein Präsentationsprogramm,

Echtzeitdaten auf der HP. etc.

Auch das soll es alles geben

Zitat von FloM

Bezüglich des Auslesen hatte ich gestern noch den Einfall einfach einen ESP32 am Messrahmen zu platzieren.

Dieser verbraucht quasi keinen Strom und kann die Daten per Wlan nach vorne schicken.

Der Kabelsalat entfällt.

Am wuerde dann ein Tablet genügen.

Jaein, ich persönlich halte nicht viel von WLAN, vor allem, wenn schon Kabel da sind. Ich weis jetzt nicht wie viele Kabel es bei euch sind, aber bei uns ist es pro Stand ein Kabel.
Daher baue ich gerade einfach darauf auf, dass man die alten Industrierechner mit einem Raspberry ersetzt, und dann von mir ein RPI-HAT kommt, der mit den Steckern, die auch aktuell intern verbaut sind, die Konnektivität herstellt.

Der RPi hat halt eine einigermaßen große Kapazität wodurch damit auch einfach gleich schon die Anzeigeeinheit da wäre. Dabei soll auch die Möglichkeit bestehen, das Interface auf andere Geräte zu streamen, ein Zusätzliches Tablet wäre also möglich. (oder evtl. den Pi vorne zu verstecken und dann wieder per WLAN an den Schützenstand zu gehen.)

Wichtig bei diesen Überlegungen ist auch, dass es nicht einfach zu manipulieren ist, damit die Rahmen die Zulassung nicht verlieren (Anfrage beim Bundesverband Schießstätten e.V. läuft gerade, ob es überhaupt von denen abgesegnet wird.)

Gruß
Sebastian

Hallo FloM,

der Charme hinter meiner Lösung wäre, dass der Stand auch einzeln, ohne einen Single Point of Failure funktioniert. Wenn wir z.B. MQTT verwenden, dann wäre der Broker ein SPoF, was ich für den Server aber durchaus OK fände, nur eben nicht für den Stand selbst, der auch dann funktionieren soll, wenn der Server eben nicht läuft.

Aber, was mir an deiner Idee sehr gut gefällt, ist die Tatsache, dass man nur eine Kleinigkeit (also den MCU) tauschen muss, um einen Meyton zu einem Disag-Stand kompatibel zu machen. Allerdings ist das auch durch das bloße Tauschen einer Software-Komponente möglich.

Des weiteren fehlt mir aktuell noch die Decodierung eines Protokolls z.B. von Meyton, da läuft am Anfang auch einiges in Richtung Kalibration über die Schnittstelle, da bin ich mir aktuell nicht sicher, wie viel der Rahmen da selbst mach, und wie viel da vom Standrechner kommen muss, evtl. wäre das auch zu viel für eine MCU.

Wie gesagt, mir gefällt die Idee im Prinzip gut, nur ist der SPoF für mich ein Problem.

Hast du des weiteren noch eine Idee, wie man verhindern könnte, dass unberechtigte an den MQTT-Broker Daten senden?
Nur Passwort und User dürfte evtl. nicht ausreichen und ssl können die wenigsten MCUs.

Bei meinem Konzept nimmt der Stand diese Infos aktuell nur von Lokal (127.0.0.1) direkt entgegen, wodurch ein Manipulieren von außen nicht möglich sein sollte.

Ich werde evtl. die Tage mal eine Datagramm erstellen, in dem die ganzen Zusammenhänge hoffentlich klarer werden.

Gruß
Sebastian

Hallo,

hier mal das Diagramm, wie ich es aktuell geplant habe:

Nach ersten Tests schafft ein RPi mindestens 3 Anzeigeeinheiten gleichzeitig, bei Aktualisierungen im Bereich von 200ms.

Denn das was mir bei der Lösung über die MCU noch komplett fehlt ist die Visualisierung, die ja wieder extern über ein zusätzliches Gerät gehen müsste und für dieses Gerät müsste man dann die Daten aus MQTT wieder aufbereiten und z.B. über eine JSON-API für die Anzeige in einem Browser formatieren.

Gruß
Sebastian

Ah, jetzt wird ein Schuh draus, ihr habt einen Gateway verbaut.

In unserer Anlage gibt es keinen solchen, wir haben pro Messrahmen eine Leitung an den Schützenstand, wo dann der runde Stecker in den Standrechner geht.
Hier ein Bild dazu:

Das Bild ist leider nicht ganz gut, geworden, aber das hab ich mal bei einer Reparatur gemacht.

Daher strebe ich aktuell eine etwas andere Lösung an, als bei euch.

Mal überlegen, ich denke es wäre möglich, dass man einfach einen RPi für z.B. 4-6 Stände zu verwenden. Dafür wäre es wahrscheinlich gut, die Software in einen Container zu verpacken und dann jeweils einen Seriellen Port durchzumappen. Dann könnten z.B. Tablets über einen Port pro Stand darauf zugreifen. Der Vorteil dabei wäre, dass man einfach bei dem Gateway den RPi einbauen kann, ohne groß bei euch umzubauen.

Gruß
Sebastian

Hallo,

und nochmal ich,

heute habe ich mir mal noch Gedanken zum Aufbau der Steuerung über den Server gemacht.
Dabei hat mir tatsächlich der Ansatz von FloM über MQTT zu gehen sehr gut gefallen, daher habe ich die Infos mal dahingehend ergänzt.

Gruß
Sebastian