Deine Visualisierung gefällt mir übrigens sehr gut.
Ich hatte damals mal einen Renderer für Zielscheiben in der Optik der Papierscheiben gebaut ,der die RMIII Daten ausgewertet hat. Aber davon würde ich eigentlich bei einer elektronischen Anlage absehen.
Wir könnten ja mal versuchen das Protokoll für den Messrahmen zu analysieren und zu dokumentieren. Was hälst du davon? SebastianL
Der erste Schritt wäre jetzt glaube ich erstmal die Daten aus dem Messrahmen zu bekommen per RS232. Danach die Anbindung der Handsteuerung. Dann kann man sich um die Anzeige kümmern etc. Bei dem Bedienteil mache ich mir weniger sorgen, im Notfall ließe sich sowas auch mit einer Numpad-Tastatur über USB und einer eigenen Abdeckung aus dem 3D Drucker abbilden.
Also für mich Prio 1, das Auslesen des Rahmens.
Hi SebastianL , das mit dem SPoF verstehe ich. Über die Transportverschlüsselung hab ich mir erstmal weniger Gedanken gemacht, da ich davon ausgegangen bin, dass die Anlage in einem isolierten Netzwerk betrieben wird. MQTT mit USER/PW sollte daher erstmal genügen (meine Meinung).
An die Kalibrierung habe ich auch schon gedacht, ich frage mich ob der Stand-Computer dies tatsächlich macht oder der Rahmen selbst. Kenne das Protokoll auch noch nicht, weil einfach keine Zeit dagewesen ist. Wir haben ja erst am Freitag von Papierscheibe auf die Rahmen umgestellt.
Falls der Rahmen noch "dümmer" ist und nur einen Haufen Lichtschrankendaten über die Leitung bläst und das dann am StandPC ausgerechnet wird wäre es natürlich blöd.
Bei uns ist es aktuell so: Es gibt 4 Stände, mit Messrahmen, die laufen in ein Meyton Gateway. Das hat diese runden Stecker für Stromversorgung und Datenkommunikation. Von der Kiste aus geht dann eine Netzwerkleitung ab zum Switch. Der ist auf höhe der Schießstände, dort gibt es unter jedem Tisch jeweils einen StandPC mit Bildschirm und Steuerung. Im StandPC ist auch noch ein DisplaySplitter verbaut. Der SteuerPC mit Suse Linux ist auch am Switch mit einem Kabel angeschlossen, genau wie der Drucker.
Wenn ich dich richtig verstehe, dann bekommt der StandPC einen RPI als ersatz, der direkt mit dem Rahmen kommuniziert?
Bei meiner PV-Anlage habe ich z.b. einen RS232-Adapter von Waveshare, der die Schnittstelle über TCP-IP bereitstellt. Auch sowas wäre z.B. denkbar, wenn man eine Lösung (Nur ein Kabel nach vorne) präferiert.
Man könnte den PI auch gleich am Messrahmen anschließen, geht natürlich auch. aber dann entweder mit langen Kabel, oder mit UI über http und z.B. nen Tablet vorne am Stand (per WLAN)...
Jetzt zu der Variante die ich im Kopf hatte:
Messrahmen -> MCU -> (WIFI/LAN) --> RPI --> Bildschirm/Steuerung am Stand)
Auf dem RPI läuft dann jeweils pro Stand ein Broker z.B. Mosquito, eine UI Anwendung, oder ein HTTP Endpunkt der das UI anzeigt. (Denkbar wäre hier den PI im Kioskmodus zu booten und dann automatisch den Browser mit der UI direkt zu starten.
Vorteil dieser Lösung wäre, dass man komplett auf die Kabel verzichten kann (nicht muss), weil jeder Messrahmen sich über die MCU per WLAN mit dem jeweiligen RPI verbinden würde. Die Stände funktionieren dann autark.
Bei MQTT gibt es QoS Stufe 2, die sicherstellt, dass die Nachricht (Treffer) nur 1mal auf jeden Fall zugestellt wird. Damit würde ich starten.
Natürlich könnte man auch noch stumpfer ran gehen, und einfach die serielle Schnittstelle bis zum PI brücken. Z.B. mit Waveshare Adapter oder einer MCU ginge das sicher auch. (Da gibt es sicher schon was fertiges)
Guten Morgen.
Wenn wlan wirklich ein Problem wäre, nimmt man halt ein Kabelgebundenes Gerät.
Kostet keine 5€ pro Stand.
Was die Grundidee dahinter ist. Dass es kein Betriebssystem dafür gibt, sondern nur ein Programm welches ausgeführt wird und genau diese eine Aufgabe, die Trefferdaten digital über TCP/IP bereitzustellen, mit welchen Protokoll auch immer.
Nach 3 Sekunden ist so ein Gerät nach dem Einschalten startklar.
Und die schnittstelle dafür wird gleich bereitgestellt.
Zu der Api noch etwas.
Man könnte z.b. MQTT nutzen, das bereits Millionenfach in der Hausautomatisierung genutzt wird. Dann pusht jeder Stand seine Daten direkt an einen Broker.
Api/ Clients usw..gibt es dafür massenweise.
Tooling um die Daten zu sichten und live zu analysieren ebenfalls. Das ist extrem hilfreich bei der Entwicklung. Und vorallem offen und leicht für andere etwas daran anzuschließen.
Wie geil ist das denn.
Wir haben gestern in unserem Verein von Scheiben auf eine aeltere Meytonanlage umgestellt.
Ich habe genau das gleiche gesagt, was man machen könnte, was du hier vorgestellt hast.
Eine kleine Anregung hätte ich noch.
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.
Daran angeschlossen könnte es eine ganze Palette an verschiedener open source software geben.
Dein Auswertungsprogramm,
Ein Präsentationsprogramm,
Echtzeitdaten auf der HP. etc.
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.
