Heimautomatisierung für Hardwarebastler (Teil 3)
In den ersten beiden Teilen dieser losen Artikelserie ging es um erste kleine Projekte und dann um die Skriptfähigkeiten, um auch komplexere Steuerungsaufgaben mit OpenAPC zu lösen. In dieser Folge wird ein eigenes Plug-In erstellt.
In den ersten beiden Teilen dieser Artikelserie wurde gezeigt, wie es mittels der OpenAPC-Software möglich ist, kleine und auch größere Projekte samt der zugehörigen HMI zu erstellen. Die dort exemplarisch vorgestellte Rollladensteuerung hat mit der Außenwelt über die Parallelschnittstelle kommuniziert. Nach dem der Parallelport ein mittlerweile ziemlich veraltetes Stück Hardware ist, welches – wenn überhaupt – nur noch als Pfostenleiste auf dem Mainboard zu finden ist, liegt der Wunsch nahe, hier etwas anderes einzusetzen.
Alternativen gibt es viele, so kann die Kommunikation mit der Außenwelt per USB, per PCI-IO-Karte oder vielleicht sogar per Contoller an der seriellen Schnittstelle erfolgen.
Egal welche Lösung bevorzugt wird, es ergibt sich das Problem, dass die OpenAPC-Software diese neue Hardwareschnittstelle möglicherweise nicht von Haus aus unterstützt. Dank des Plug-In Konzeptes ist es aber leicht möglich, solche neuen Devices einzubinden und damit über die OpenAPC-Steuerungssoftware nutzbar zu machen.
Ganz in der Tradition der ersten beiden Teile soll auch hier nun wieder mit dem Software-Part, sprich der Implementierung eines neuen Plug-Ins, der Teil eines Projektes im Vordergrund stehen, der für den Hardwareentwickler nicht nur ein fremdes Fachgebiet, sondern meist auch ein ungeliebtes aber notwendiges Übel ist.
Baukastenprinzip
){kind=small}
Hans Müller
Leichter Zugriff auf HMI-und Flow-Elemente per Foldbar – Plug-Ins inklusive
Plug-Ins sind ein elementarer Bestandteil der OpenAPC-Visualisierungssoftware. Innerhalb der Applikation ist das nicht so ohne weiteres zu erkennen, aber sehr viele Funktionalitäten sind bereits in externen Plug-Ins implementiert und gar nicht Teil des Hauptprogrammes.
Ein Vorteil, der sich daraus ergibt, ist die Möglichkeit, auf dem Zielsystem nur die Plug-Ins zu installieren, welche auch wirklich benötigt werden. Das spart Platz und beschränkt eine solche Installation auf das absolut notwendige Minimum.
Doch zuerst ein Blick in die neue Version 1.5. Auffälligste Änderung hier sind Foldbars jeweils am rechten Rand des Fensters, in der die vorhandenen Funktionen und Elemente verfügbar sind und in denen man auch leicht erkennen kann, welche dieser Elemente als externe Plug-Ins realisiert sind. Sowohl im HMI- als auch im Flow-Editor sind all diejenigen Objekte, welche sich in den Foldbars unterhalb der kleinen, horizontalen Trennlinie befinden, als externe Softwarekomponenten realisiert. In den Flowelementgruppen »Daten«, »Bewegung«, »Eingang/Ausgang« sind das sogar alle, hier existieren gar keine Funktionen, welche vom Hauptprogramm ausgeführt werden.
An dieser Stelle ist bereits zu erahnen, dass zwischen den einzelnen Typen von Flow-Plug-Ins kein großer Unterschied besteht, die Schnittstelle nach oben hin ist für alle gleich, es ist nur eine Frage der Implementierung, was diese genau tun.
Aus diesem Grund soll hier in einem ersten Schritt ein einfaches, allgemein nutzbares Plug-In entwickelt werden, welches gar nicht zur Kategorie »Eingang/Ausgang« gehört, sondern in der Kategorie »Daten« Zufallszahlen erzeugt. Dies ist eine Funktionalität, welche dem OpenAPC-Paket noch fehlt, das fertige Plug-In wird dem Projekt anschließend zur Verfügung gestellt. Die Weiterentwicklung auf ein Plug-In, welches dann tatsächlich irgend eine sehr spezielle Hardware ansteuert (und damit zu einer anderen Kategorie gehört) bedarf dann nur noch weniger Änderungen.
Die Werkzeuge
Um mit der Entwicklung eines eigenen Plug-Ins zu beginnen, werden einige Tools und Pakete benötigt. Das wären zum einen gcc und make, welche Teil jeder Linux-Distribution ist und im Zweifelsfall leicht nachinstalliert werden können. Zum anderen ist das das OpenAPC-Entwicklungspaket. Dieses findet sich z.B. unter http://www.openapc.com/download.php im SDK. Alternativ kann der aktuelle Stand aller Sourcen und Header aber auch per git von der Projektseite auf fedorahosted.org beschafft werden. Ein Kommandozeilenaufruf
git clone http://git.fedorahosted.org/git/OpenAPC.git
erzeugt dabei eine lokale Kopie des Sourcenarchives inklusive der benötigten Headerfiles. Kleiner Nachteil hier: Das Handbuch, welches alle Programmierschnittstellen beschreibt, ist dort nicht enthalten, dieses ist nur im SDK zu finden.
In der mittels git clone erzeugten Verzeichnisstruktur findet sich im Unterverzeichnis plugins gleich eine ganze Sammlung von Sourcen, welche innerhalb des OpenAPC-Paketes diverse Plug-Ins realisieren. Das ist auch ein guter Platz, um ein eigenes Verzeichnis libio_random anzulegen und ein Makefile zu erzeugen. Dabei ist es das einfachste, sich eines der existierenden Makefiles der anderen Plug-Ins zu bedienen und lediglich die Namen der Sourcedateien anzupassen.
Zwei Eigenheiten dieser Makefiles ist jedoch zu beachten: Zum einen wird ein Verzeichnis ../../flowplugins erwartet, in dem das Plug-In erzeugt wird, welches aber nicht existiert und deswegen von Hand mittels mkdir ../../flowplugins angelegt werden muss. Und zum anderen wird als letzter Schritt im Makefile ein
sudo cp $(EXECUTABLE) /usr/lib/openapc/flowplugins/
aufgerufen, was dazu führt, dass das eben generierte Plug-In in das flowplugins-Verzeichnis der aktuellen OpenAPC-Installation kopiert wird, so dass man es nach einem Neustart der Applikation sofort testen kann. Damit dass klappt, muss sudo allerdings so eingerichtet sein, dass der lokale Benutzer auch cp mit root-Rechten ausführen darf. Ein Eintrag
username ALL = NOPASSWD: /bin/cp
in der Datei /etc/sudoers sorgt dafür, dass das auch klappt. Hier muss username natürlich durch den Namen des Users ersetzt werden, welcher cp per sudo ausführen können soll.
