Messapplikation erstellen Messdaten mit LabVIEW erfassen und aufbereiten

Wie gelangen Messdaten aus Sensoren und Messmodulen in eine PC-Applikation und wie werden sie dort weiterverarbeitet? Dieser Beitrag zeigt, welche Rolle Treiber und Datenformate dabei spielen und wie sich Messdaten in LabVIEW per Parsing aus USB-Datenströmen und Modbus-Telegrammen extrahieren lassen.

Um Messdaten von den Messkomponenten beziehungsweise Bussystemanschlüssen in eine Applikation zu übertragen, müssen in der Regel zunächst entsprechende Treiber installiert werden (Bild 1). Grob lassen sich Kommunikations- und Gerätetreiber unterscheiden. Kommunikationstreiber ermöglichen den generellen Zugriff auf die im System verwendete Kommunikationsschnittstelle.

Wird beispielsweise ein Feldbus eingesetzt, der über eine Einsteckkarte oder ein externes Koppelmodul an den Computer angebunden ist, muss ein vom jeweiligen Hersteller mitgelieferter Treiber installiert werden. Bei USB oder Ethernet ist der Kommunikationstreiber dagegen in der Regel bereits im Betriebssystem vorhanden. Bei Industrial Ethernet hängt es vom jeweiligen System ab: Bei den meisten Systemen ist Koppelhardware erforderlich, zu der auch ein entsprechender Treiber gehört. Bei Varianten, die stärker auf die Standard-Ethernet-Welt setzen, reicht zunächst der computerinterne Ethernetanschluss. Für die spezifischen Protokolle höherer Schichten ist jedoch trotzdem ein zusätzlicher Treiber erforderlich.

Gerätetreiber unterstützen ein konkretes Gerät mit seinen spezifischen Funktionen oder eine bestimmte Geräteart. Letzteres ist der Fall, wenn bei Feldbussen oder Industrial-Ethernet-Systemen Geräteprofile existieren oder wenn USB-Geräteklassen verwendet werden. Ob es für ein Gerät einen spezifischen Treiber gibt, hängt vom Hersteller ab. Grundsätzlich kann jedes Gerät auch ohne Gerätetreiber angesprochen werden, sofern der Hersteller die entsprechenden Zugriffsinformationen veröffentlicht. In aller Regel ist das jedoch mit einem gewissen Programmieraufwand verbunden.

Elektronische Datenblätter vereinfachen den Buszugriff

Eine Zwischenlösung sind elektronische Datenblätter, wie sie einige Feldbusse und Industrial-Ethernet-Systeme für Gerätehersteller vorschreiben. In ihnen werden die Geräte, ihre Funktionalitäten und die für den Buszugriff relevanten Parameter in standardisierter Form beschrieben. Üblicherweise werden diese Datenblätter von entsprechenden Engineering-Tools verwendet. Sie können aber auch bei der Entwicklung einer Messdatenapplikation hilfreich sein, weil sie den Aufwand für das Ansprechen einzelner Busknoten verringern. Beispiele sind die GSD-Dateien (Gerätestammdaten-Dateien) bei PROFIBUS und PROFINET sowie die EDS-Dateien (Electronic Data Sheet) bei CANopen.

Verfügt man über keine gerätespezifischen Treiber, müssen die Nutzdaten, die beispielsweise von einem Sensor oder Messgerät über ein Bussystem eingelesen werden, noch programmatisch interpretiert werden. Dazu liest man anhand der vom Hersteller verwendeten Datencodierung die interessierenden Messdaten aus und wandelt sie gegebenenfalls in ein Datenformat um, das die Applikation verarbeiten kann. Diesen Vorgang bezeichnet man als Parsing. Darauf wird im weiteren Verlauf näher eingegangen.

Die Applikation verbindet Bedienoberfläche und Messdatenverarbeitung

Nach der Installation der entsprechenden Treiber kann man mit der Erstellung der eigentlichen Applikation beginnen. Diese umfasst zum einen die grafische Bedienoberfläche, auch GUI („Graphical User Interface“) oder MMI („Man-Machine Interface“) genannt. Zum anderen gehören dazu die im Hintergrund ablaufenden Programmfunktionen zum Einlesen und Verarbeiten der Messdaten. Auch die Steuerung der Programmabläufe muss implementiert werden.

Für den Entwurf der Applikation gibt es verschiedene Möglichkeiten. Liegt der Schwerpunkt vor allem auf der Gestaltung einer Bedienoberfläche, zu der nur elementare Messdatenverarbeitungsfunktionen hinzukommen, bietet sich der Einsatz einer Prozessvisualisierungssoftware an. Sie verfügt über eine Reihe häufig benötigter grafischer Anzeige- und Bedienelemente, die zu einem oder mehreren Prozessbildschirmen kombiniert werden können. Für die Messdatenverarbeitung lassen sich mathematische Grundfunktionen, meist aber auch sogenannte Makros in einer tool-spezifischen Schreibweise verwenden. Die im englischen Sprachraum übliche Bezeichnung für solche Tools lautet SCADA-Software („Supervisory Control and Data Acquisition“). Der Begriff deutet bereits an, dass diese Software meist mehr kann, als Daten lediglich zu visualisieren.

Eine passende Bedienoberfläche erstellen

Sind dagegen komplexere Messdatenverarbeitungsfunktionen oder Programmabläufe zu implementieren, kommt man an der Programmierung mit entsprechenden Tools nicht vorbei. Grundsätzlich kann dafür jede Programmiersprache und jedes geeignete Tool eingesetzt werden, sofern der Zugriff auf die erforderlichen Treiber möglich ist, was heute fast immer der Fall ist. Für die Erstellung der Bedienoberflächen stehen meist entsprechende Bibliotheksmodule zur Verfügung. Einfache Applikationen werden mitunter auch mit Tabellenkalkulationsprogrammen erstellt.

Einen Mittelweg bieten grafische Programmiertools, die auf die Anforderungen der Messdatenerfassung und -auswertung zugeschnitten sind. Solche Tools gibt es von mehreren Herstellern, die in der Regel aus dem Messtechnik-Umfeld stammen. Sie ermöglichen sowohl die Gestaltung von Bedienoberflächen als auch die effiziente Erstellung von Programmcode auf grafische Weise – daher ihre Bezeichnung. Anstatt den Programmcode auf Textbasis einzugeben, wobei eine strenge Syntax einzuhalten ist, werden Abläufe und Verarbeitungsfunktionen durch grafische Funktionsblöcke auf dem Bildschirm dargestellt und untereinander quasi verdrahtet. Ist für sehr komplexe Teilalgorithmen eine textorientierte Formulierung von Vorteil, erlauben einige dieser Tools auch die Integration von Funktionsblöcken, die intern in einer Textsprache codiert sind. Das folgende Beispiel für ein Tool stammt aus dieser Gruppe.

LabVIEW wurde vor mehreren Jahrzehnten eingeführt und seitdem kontinuierlich erweitert. Das Tool ist in der Messdatenerfassung und -auswertung sowie bei der Automatisierung von Prüfabläufen weit verbreitet. Die Programmieroberfläche von LabVIEW (Bild 2) umfasst stets zwei Fenster: das Front Panel und das Block Diagram.

Im Front Panel wird die Bedienoberfläche erstellt, während im Block Diagram die Funktionsprogrammierung auf grafische Weise erfolgt. Beide Komponenten gehören fest zusammen und werden in derselben Datei gespeichert. Diese trägt die Dateiendung .vi stheht für Virtual Instrument steht, also ein virtuelles Mess- und Automatisierungsinstrument im Computer. Eine solche Datei wird allgemein auch als „VI“ bezeichnet.

Zur besseren Übersicht wird eine Messdatenapplikation häufig in mehrere VIs unterteilt, die sich am besten im sogenannten Projekt-Explorer verwalten lassen. In der Programmieroberfläche werden die Applikation entworfen und getestet. Abschließend kann die fertige Applikation eigenständig auf anderen Rechnern installiert werden. In Verbindung mit einer LabVIEW Runtime Engine lässt sie sich dort ohne die eigentliche Entwicklungsumgebung ausführen.

Nutzdaten identifizieren und in ein geeignetes Format umwandeln

Verfügt man nicht über gerätespezifische Treiber, die sich direkt in die eigene Programmierumgebung einbinden lassen, kommt man um das sogenannte Parsing nicht herum. Darunter versteht man die Auswahl der tatsächlich interessierenden Messdaten aus den Nutzdaten (Payload), die beispielsweise über ein Bussystem vom jeweiligen Endgerät eingelesen werden. Dazu müssen die Messdaten in den Nutzdaten identifiziert und häufig auch aus ihrem ursprünglichen Datenformat in das von der eigenen Programmierumgebung verwendete Format umcodiert werden. Anhand zweier Beispiele wird im Folgenden erläutert, was das in der Praxis bedeutet.

Beispiel 1: IMU-Modul von mCube mit herstellerspezifischem Datenstrom über einen virtuellen seriellen Port: Bei diesem Modul handelt es sich um ein kompaktes Elektronikmodul mit jeweils drei entlang der Gehäuseachsen ausgerichteten Beschleunigungs-, Drehraten- und Magnetfeldsensoren. Zusammen mit entsprechenden schritthaltenden Algorithmen werden solche Module dazu verwendet, Position und Ausrichtung mobiler Systeme im Raum ohne externe technische Infrastruktur zu bestimmen. Sie kommen bei Versuchen, aber auch zur Kurzzeitnavigation zum Einsatz.

Neben einer Bluetooth-Funkschnittstelle verfügt das Modul über eine USB-Schnittstelle. Über diese wird es mit Strom versorgt und gibt kontinuierlich einen Datenstrom mit den Sensormesswerten aus. In den gängigen Betriebssystemen gibt es Treiber, die einen solchen Datenstrom für Programme als sogenannten virtuellen seriellen Port zugänglich machen. Dieser bildet die heute praktisch ausgestorbene frühere serielle RS-232-Schnittstelle nach. Für die rechnerinterne Kommunikation mit der Messdatenapplikation müssen daher die entsprechenden Konfigurationsparameter korrekt eingestellt werden. Beim mCube sind dies beispielsweise: 115.200 Baud (= Bit/s), acht Datenbits, keine Parität, ein Stoppbit und keine Flusssteuerung.

Bild 3 zeigt links den Rohdatenstrom, den die bereits in Bild 2 gezeigte Messdatenapplikation über den virtuellen Port empfängt. Jede Zahl steht dabei für ein Datenbyte; der mögliche Zahlenbereich reicht also von 0 bis 255. Der Hersteller verwendet für unterschiedliche Pakettypen jeweils ein spezifisches Datenformat. Die Pakete werden in einer bestimmten Taktung automatisch über USB vom Modul gesendet. Die Datenstruktur des Pakettyps mit den interessierenden Sensormessdaten ist im rechten Teil von Bild 3 dargestellt. Der Begriff Quaternion bezeichnet eine aus vier Teilzahlen bestehende Zahlenstruktur, die sich aus einem Skalar und einem dreidimensionalen Vektor zusammensetzt. Sie dient dazu, Drehungen und Orientierungen im dreidimensionalen Raum effizient zu beschreiben. Im Modul wird das Quaternion aus den Messwerten der Beschleunigungs- und Drehratensensoren ermittelt.

Beim Parsing muss zunächst der zum interessierenden Pakettyp gehörende Header im kontinuierlich eingehenden Datenstrom identifiziert werden. Anschließend können die folgenden 84 Bytes als Nutzdaten eingelesen werden. In der LabVIEW-Implementierung ist dies im hierfür geschriebenen Unterprogramm „ExtrahierePayload (SubVI).vi“ umgesetzt (Bild 4). Das nachfolgende Unterprogramm „InterpretierePayload (SubVI).vi“ entnimmt daraus jeweils vier aufeinanderfolgende Bytes und codiert sie in das bei LabVIEW verwendete Big-Endian-Format für Gleitkommazahlen in Single-Precision-Auflösung um. Die ganz rechts im Bild dargestellten Platzhaltersymbole stehen für die Anzeigeelemente, die im Front Panel dafür vorgesehen sind. Ausschnitte der entsprechenden Messdatenapplikation waren bereits in Bild 2 zu sehen.

Modbus über TCP: Register auslesen und interpretieren

Beispiel 2: Messmodul der LabJack-T-Serie mit Registern, die per Modbus über TCP/IP ausgelesen werden. Diese in industriellen Applikationen weit verbreiteten Messmodule stellen digitale und analoge Ein- und Ausgänge zur Verfügung, die sich mit vielfältigen modulinternen Zusatzfunktionen konfigurieren lassen. Die Module können außerdem mit der Skriptsprache Lua programmiert werden, die von mehreren Herstellern und Einrichtungen unterstützt wird. Dadurch lassen sie sich als autarke Controller einsetzen. Die Spannungsversorgung erfolgt stets über einen USB-Anschluss.

Je nach Modultyp erfolgt die Kommunikation über USB, LAN oder WLAN. In diesem Beispiel wird über LAN kommuniziert. Dafür unterstützt der Hersteller das in der industriellen Automatisierung weit verbreitete Modbus-Protokoll, das über TCP/IP übertragen wird. Modbus wurde ursprünglich für die einfache Übertragung von Prozessdaten über die früher weit verbreiteten RS-232- und RS-485-Schnittstellen entwickelt. Seit längerer Zeit dominiert jedoch die Übertragung über LAN, bei der Modbus in das Nutzdatenfeld von TCP eingefügt wird.

Modbus ist ein Client/Server-basiertes, byteorientiertes Protokoll (Bild 5). Jeder Kommunikationsvorgang besteht aus einer Client-Anfrage und einer Server-Antwort. In diesem Fall ist der PC der Client und das Messmodul der Server. Modbus über TCP arbeitet auf Port 502. Zur Geräteadressierung wird die IP-Adresse des darunterliegenden IP-Protokolls verwendet. Die Client-Anfrage besteht aus einem Header und den nachfolgenden Nutzdaten. Die meisten Modbus-Register sind 16 Bit lang, bestehen also aus zwei Bytes.

Für größere Datentypen wie UINT32 oder FLOAT32 werden zwei aufeinanderfolgende Register verwendet, die zusammen vier Bytes ergeben. Die Server-Antwort hat eine entsprechende Struktur und enthält denselben Transaction Identifier wie die Client-Anfrage. In der PDU wird zunächst der Function Code der Client-Anfrage wiederholt. Sollen beispielsweise Daten zurückgegeben werden, wie beim Function Code 3, folgen ein Byte Count sowie die angefragten Registerinhalte.

Bild 6 zeigt Ausschnitte des Front Panels und des Block Diagrams eines Demoprogramms zur Kommunikation mit einem LabJack-Messmodul über TCP/IP und das Modbus-Protokoll in LabVIEW. In diesem Fall wurden zusätzlich Open-Source-LabVIEW-VIs für die eigentliche Modbus-Kommunikation installiert. Sie erzeugen beziehungsweise interpretieren die über TCP/IP gesendeten Nutzdaten gemäß der oben beschriebenen Modbus-Telegrammstruktur. Zuvor wurde mit einem Standard-LabVIEW-VI eine TCP/IP-Verbindung zum Messmodul aufgebaut. Dabei kamen dessen IP-Adresse und Port 502 zum Einsatz. Statt der zusätzlichen Modbus-VIs ließe sich das Parsing des Modbus-Telegramms relativ leicht auch selbst programmieren. (heh)

Prof. Dr.-Ing. Jörg Böttcher hat passend zu den Schwerpunkten dieses Beitrags mehrere praxisnahe Fachbücher veröffentlicht. Diese sind in der Reihe „Basiswissen für die intelligente Systemautomatisierung“ (Verlag Books on Demand) und unter www.prof-boettcher.de erschienen.

Open-Source-Alternative zu Matlab/Simulink

Technische Systeme mit Scilab und Xcos simulieren

(ID:50922028)