Programmierschnittstelle im Vorfeld klären
Der Aufwand, eine eigene Messapplikation zu erstellen, die eine bestimmte Hardware ansteuert, ist direkt und umgekehrt proportional mit dem Aufwand verknüpft, den der Hardwarehersteller betrieben hat, eine durchdachte Programmierschnittstelle zu realisieren. Es lohnt sich im Vorfeld einer Investition in neue Hardware immer genau zu klären, wie viel Arbeit an dieser Stelle noch selbst zu leisten ist.
Der Kunde beschränkt sich bei der Entscheidung für oder gegen eine bestimmte Messtechnik-Hardware oft darauf zu klären, ob seine Lieblingsprogrammiersprache bzw. die in der bestehenden Software bereits verwendete, unterstützt wird, oder ob zur Verfügung stehende Softwareentwickler diese beherrschen. Betriebswirtschaftlich gesehen ist dieses Vorgehen recht kurzsichtig, denn durch eine unergonomische Programmierschnittstelle kann teuere Entwicklungszeit bei der Neuerstellung, Änderung und Erweiterung eigener Messapplikationen vergeudet werden. Außerdem macht es auch keinen Spaß, eine schlecht designte Programmierschnittstelle zu verwenden.
MS-DotNet-Technologie ist Favorit
Bei der Neuerstellung einer Messapplikation, die auf MS-Windows-Rechnern eingesetzt werden soll, da sind sich alle Softwareexperten einig, ist es der beste Weg, die MS-DotNet-Technologie zu verwenden. Das Visual Studio unter C# ist mit Sicherheit das produktivste Rapid Application Development Tool, das zurzeit erhältlich ist. Das gilt sowohl und vor allem für den Entwurf grafischer Benutzeroberflächen (GUI) mittels der WinForms oder der WPF-Technologie, aber auch im besonderem Maße für den im Visual Studio enthaltenen Debugger. Doch was nützt die neueste objektorientierte Programmiersprache, wenn die Schnittstelle, über die die Messhardware angesteuert wird, aus einer einfachen Wrapperklasse um eine Sammlung unzähliger kryptischer c-Funktionen besteht? Der erste Schritt bei der Entwicklung größerer Softwareprojekte ist es dann stets, ein eigenes objektorientiertes Wrapperdesign zu implementieren. Das kostet viel Zeit und ist nicht unbedingt der Ausnahmefall. Aber sollte es nicht selbstverständlich sein, dass der Aufwand, die teuer gekaufte Hardware über ein klar strukturiertes, logisch aufgebautes und objektorientiertes Interface ansprechen zu können, beim Hardwareanbieter liegt? Die DotNet-Technologie bietet dem Hersteller bei konsequenter Verwendung der XML-Kommentare die Möglichkeit, ein Interface zu schaffen, das selbst seine eigene Dokumentation ist, das heißt, der Kunde kann Messapplikationen programmieren, ohne einen Blick ins Handbuch werfen zu müssen. Bild 1 zeigt die IntelliSense-Fenster des MS Visual Studio: Dem Programmierer werden die für das gerade betrachtete Objekt zur Verfügung stehenden Methoden und Eigenschaften inklusive einer Erklärung angezeigt, er braucht nur die gewünschte auszuwählen. Ein gutes objektorientiertes Design der Schnittstelle hat zur Folge, dass die meisten selbst geschriebenen Funktionen aus nur wenigen Zeilen bestehen.
Auch aus graphikbasierten Anwendungen verwendbar
Ein weiterer wichtiger Vorteil eines von Anfang an sorgfältig desig-nten Interfaces ist, dass eine solche DotNet-Schnittstelle auch bequem aus graphikbasierten Anwendungen, wie National Instruments LabVIEW oder Agilent VEE verwendbar ist, und das meistens komplett mausgesteuert und ohne die Schnittstelle vorher zu kennen (Bild 2).
Für Ingenieure sind LabVIEW und Matlab Standardsoftware. Es liegt also nahe, ein Interface auch dahingehend zu entwerfen, den Datenaustausch mit solchen Anwendungen mit möglichst wenig Code zu ermöglichen.
Man stelle sich zum Beispiel eine analoge Datenerfassungskarte vor, die die Möglichkeit bietet, die erfassten Daten direkt auf der Karte durch einen digitalen Filter zu verändern. Der erste Gedanke des Entwicklers wird sein, den Filterentwurf dafür mit Matlab zu machen und eventuell das grafische FDA-Tool von Matlab zu verwenden. So hat er vollen Überblick über die Ergebnisse und kommt schnell zum gewünschten Resultat. Aber wie kommen die so errechneten Filterkoeffizienten in die Hardware? Am einfachsten wäre es, wenn die Schnittstelle dasselbe Datenformat verstehen könnte.
Selbstprogrammierschnittstelle
Die von der Firma Goldammer aus Wolfsburg seit diesem Herbst ausgelieferte und auf ihrer Webseite auch für alle älteren Karten zum Download angebotene Selbstprogrammierschnittstelle ist im Hinblick auf alle diese Aspekte überarbeitet worden. Bild 3 zeigt den oben angerissenen Fall, einen in Matlab entworfenen IIR-Filter an eine Goldammer-Messkarte zu übertragen. Neben einer neu entworfenen DotNet-Schnittstelle steht auch eine neu implementierte native Win32-DLL zur Verfügung, die einerseits weitgehend abwärtskompatibel zur bisher ausgelieferten Schnittstelle ist, andererseits aber auch die oben gezeigte Integration der Standardanwendung Matlab bietet. Ein weiteres Bonbon der Schnittstelle ist: Es gibt nur eine, und die funktioniert bei allen Goldammer-Karten gleich. Eine DotNet-Messapplikation, die zum Beispiel für eine Karte aus der Serie MC4USB erstellt wurde, funktioniert ohne Änderungen auch mit einer über Ethernet angeschlossenen Messkarte.
Hans-Joachim Goldammer
(jj)
