Kommunikation
Wie ich zu Beginn meines MOBA-Projektes bereits erwartet hatte ergeben sich für den Raspberry immer wieder neue Anwendungsmöglichkeiten. Dies hat letztlich auch dazu geführt, dass mittlerweile mehrere dieser kleinen Mini-Computer zum Einsatz kommen.
Die aktuelle Aufgabenverteilung zwischen den verschiedenen Raspberries ist im Bild aufgeführt.
Problembeschreibung
Relativ schnell tat sich dabei dann aber ein kleines Problem auf. Für den Haupt-Raspberry (RaspPi2) hatte ich sehr früh ein kleines Farbdisplay inkl. einer Funktastatur in mein Bedienkonzept integriert (siehe hier). Einen ähnlichen Schritt wollte ich nun aber für die weiteren Raspberries nicht vollziehen. Zum einen hatte ich in meinem Bedienpult keinen Platz für die zusätzlichen Displays, zum anderen hatte ich schon während meiner beruflichen Praxis das Hantieren mit mehreren Tastaturen an einem Arbeitsplatz als äußerst lästig empfunden. Daher habe ich verschiedene Alternativen beleuchtet.
Variante 1:
Grundsätzlich ist die Bedienung eines Raspberry natürlich auch remote über einen anderen Computer möglich. Ich nutzte diese Möglichkeit z.B. wenn ich Programme für meine Raspberries entwickele und teste. Ich arbeite dann über einen remote-Zugang von meinem PC aus. Ich könnte natürlich auch die weiteren Raspberries über den RaspPi2 remote bedienen. Ein Nachteil wäre bei dieser Variante, dass ich zwischen verschiedenen Fenstern auf dem kleinen Display des RaspPi2s hin und her schalten müsste.
Variante 2:
Diese Variante geht davon aus, dass ich keine direkten Bedienungen und Visualisierungsaufgaben über Display und Tastatur auf den PiZeros vorsehe. Vielmehr soll der RaspPi2 als Schnittstelle zu den PiZeros fungieren. Alle Visualisierungsaufgaben, die sich auf die PiZeros beziehen, sollen in das bereits an verschiedenen Stellen beschriebene Bedienfenster auf dem RaspPi2 integriert werden, alle Bedienungen sollen über die vorhandene Funktastatur bzw. über Klicks auf den Display-Button ausgeführt werden. Hierzu ist dann allerdings eine Kommunikation zwischen den Raspberries erforderlich.
Entschieden habe ich mich für Variante 2, die ich hier nun etwas ausführlicher beschreiben möchte.
Um Rechner miteinander kommunizieren zu lassen gibt es verschiedene Transport-Protokolle. Ein sehr einfach zu implementierendes Protokoll ist UDP (User Datagram Protocol). Für die IT-affinen unter euch gebe ich hier einmal die Definition dieses Protokolls wider (entnommen aus www.elektronik-kompendium.de):
"UDP ist ein verbindungsloses Transport-Protokoll und arbeitet auf der Schicht 4, der Transportschicht, des OSI-Schichtenmodells. Es hat damit eine vergleichbare Aufgabe, wie das verbindungsorientierte TCP. Allerdings arbeitet es verbindungslos und damit unsicher. Das bedeutet, der Absender weiß nicht, ob seine verschickten Datenpakete angekommen sind. Während TCP Bestätigungen beim Datenempfang sendet, verzichtet UDP darauf. Das hat den Vorteil, dass der Paket-Header viel kleiner ist und die Übertragungsstrecke keine Bestätigungen übertragen muss."
Mit der beschriebenen Einschränkung kann ich in meiner Anwendung gut leben, da ich ja unmittelbar an der Anlage erkennen kann, ob die Kommunikation zwischen meinen Raspberries funktioniert.
In der Grafik sind die erforderlichen Definitionen aufgeführt, die zur Einrichtung einer Kommunikation zwischen dem RaspPi2 und einem PiZero erforderlich sind. Wichtig ist, dass die beiden Rechner in einem gemeinsamen WLAN-Netz eingebunden sind und man durch Einstellungen am Router dafür gesorgt hat, dass die IP-Adressen (xxx.xxx.xxx.xxx) und (yyy.yyy.yyy.yyy) dieser Rechner statisch sind, sich also nicht sporadisch ändern. Da man die UDP-Definitionen erst auf dem Partner-Rechner anlegen kann wenn dieser im Netz erreichbar ist, wird die Warteschleife am Anfang des Python-Programmes erforderlich.
Die Kommunikationsinhalte sind in meiner Anwendung leicht zu definieren. Die von dem einen Rechner gesendeten kurzen Texte (z.B. "Position 1" oder "DS5") können auf dem anderen Rechner leicht interpretiert werden und in die entsprechenden Aktionen umgesetzt werden. Die Grafik zeigt beispielhaft den Kommunikationsverlauf für die Drehscheibe.
Das Prinzip ist universell erweiterbar, und zwar im Hinblick auf die Einbindung weiterer Raspberries, aber auch mit Blick auf zusätzliche Funktionalitäten.
Natürlich bleiben die Kipptaster-Bedienungen, wie im Abschnitt Drehscheibe beschrieben, erhalten, da man z.B. die Justierung nur durchführen kann, wenn man wirklich dicht an der Drehscheibe sitzt.
Für die Visualisierung habe ich auf meinem Raspberry-Display unten links Button für die Drehscheiben-Positionen ergänzt.
Die aktuelle Position erkennt man an der kräftig grünen Einfärbung des Button-Hintergrundes. Außerdem werden zwischen den Tasten noch Statusinformationen zur Drehscheibe ausgegeben.
Eine neue Position der Drehscheibe kann durch Klick auf den entsprechenden Button oder durch Drücken einer Zahlentasten zwischen 1 und 6 auf der Tastatur angewählt werden. Die „Motorengeräusche“ des Drehscheibenantriebes sowie die verschiedenen Ansagen und Warnhinweise werden vom RaspPi2 zeitlich stimmig abgespielt.
