Produktebreich

2.1 Allgemeines

Das Datenlogger-Modul ist eine C-Bibliothek für Mikrocontroller-Anwendungen. Die Datenlogger-Modul prüft ob sich die Pegel an digitalen Eingängen geändert haben (Zustandsänderungen) und speichert diese mit einem Zeitstempel in einem Puffer zur Weiterverarbeitung. Die Bedingungen für das Auflösen einer Messung (Triggerbedingungen) sowie die Verarbeitung im Puffer können über die Software vorgegeben werden. Das Datenlogger-Modul ist als C-Bibliothek für Rabbit Microcontroller (unter Verwendung von Dynamic C) und as Standard-C-Bibliothek (mit .h-Files) z.B. für Keil-Compiler o.ä. verfügbar.

2.2 Funktionsweise

In der Hauptprogrammschleife werden vordefinierte Eingänge des Rabbit Mikrocontroller-Moduls eingelesen und die Zustandsänderungen (=Änderung an den Einganspins) in einem FIFO (First In First Out)-Puffer gespeichert. Nach Wunsch wird zu jeder Zustandsänderung auch der Zeitpunkt deren Auftretens gespeichert. Die Funktionsweise ist in Abbildung 2.1 dargestellt. In einer weiteren Puffervarialble wird festgehalten, ob die Daten gültig sind oder ob es zu einem Überlauf des FIFO-Puffers kam.

Abbildung 2.1: Funktionsweise des Datenlogger-Moduls

2.3 Anwendungsbereiche

• Wenn Änderungen an digitalen Eingängen über einen längeren Zeitraum überwacht werden sollen.

• Wenn die Daten in Paketen zwischengespeichert werden müssen (z.B. wenn die gespeicherten Daten paketweise zu einem anderen Rechnersystem übertragen werden wie es z.B. bei einer TCP-IP-Übertragung der Fall ist).

• Wenn sich die Zustände innerhalb kurzer Zeit ändern können (Im Pollingbetrieb hängt die Geschwindigkeit Zyklusfrequenz der Hauptprogrammschleife ab. Im Interrupt-Betrieb von der möglichen Interrupt-Frequenz, die vom Mikrocontroller noch ohne störende Einflüsse auf das restliche Programm eingestellt werden kann).

• Wenn sich die Zustände sehr langsam ändern (z.B. bei mobiler Daten¬erfassung, wenn keine dauernde Netzwerkverbindung besteht, Datenlogger).

2.4 Einstellmöglichkeiten/Parameter

2.4.1 Start der Aufzeichnung

Eine Aufzeichnung kann durch verschiedene Arten ausgelöst werden. Diese sind:

Abbildung 2.2: Bedingungen für den Start der Aufzeichnung

2.4.2 Strategie beim Lesen der Eingänge

Scanvorgang	Beschreibung
Scan all Inputs	Gleichzeitig werden alle 16 digitale Eingangskanäle in einer Programm¬schleife abgefragt.
Scan specific Inputs	Einzelne Eingangskanäle können ein- oder aus¬ge¬schal¬tet (demaskiert) werden.

Abbildung 2.3: Strategien beim Lesen der Eingänge

2.4.3 Wahl der Triggerflanke

Über eine Bibliotheksroutine kann eingestellt werden, ob die Aufzeichnung mit abfallender oder mit steigender Flanke gestartet werden soll.

Triggerflanke	Beschreibung
Trigger on positve Edge	Die Aufzeichnung beginnt wenn eines der Trigger_Bits von logisch 0 auf logisch 1 wechselt.
Trigger on negative Edge	Die Aufzeichnung beginnt wenn eines der Triggerbits von logisch 1 auf logisch 0 abfällt.

Abbildung 2.4: Wählbare Triggerflanken, durch welche die Aufzeichnung gestartet wird

2.4.4 Strategie des Ereignispuffers

Neben dem Erkennen von Pufferüberläufen besteht die Möglichkeit, die Arbeitsweise des FIFO-Puffers einzustellen. Dazu stehen die wie in Abbildung 2.5 dargestellten zwei Strategien zur Verfügung.

Pufferstrategie	Beschreibung
Overwrite Buffer	Bei einem Überlauf des Ereignispuffers werden die Daten überschrieben.
Do not overwrite Buffer	Bei einem Überlauf des Ereignispuffers wartet das Mikrocontroller-Modul solange mit der Aufnahme neuer Ereignisse, bis im Ereignispuffer wieder Platz ist.

Abbildung 2.5: Wählbare Triggerflanken, durch welche die Aufzeichnung gestartet wird

2.4.5 Erkennen von Pufferüberläufen

Wenn die Anzahl der gespeicherten Ereignisse die Grösse des Puffers überschreitet kommt es zu einem Überlauf des Ereignispuffers. Dies kann z.B. vorkommen wenn innerhalb kurzer Zeit sehr viele Ereignisse generiert werden und der Ereignispuffer nicht ausgelesen oder zu langsam ausgelesen wird. Das Datenlogger-Modul ist deshalb so ausgelegt, dass Überläufe erkannt und dokumentiert werden. Dies wird über ein zusätzliches Flag (Info-Feld) erreicht. Durch Abrage des Info-Flags ist im Nachhinein feststellbar, an welchen Stellen ein Überlauf im Ereignispuffer stattgefunden hat. Jede aufgezeichnete Zurstands¬änderung enhält ein Info-Feld. Die Werte im Info-Feld haben die wie in Abbildung 2.5 aufgezeigte Bedeutung. Das Info-Flag wird in den zwei höchstwertigen Bits, in der auch die aktuelle Zeit in Millisekunden gespeichert wird, abgelegt.

Abbildung 2.6: Bedeutung der Wert im Info-Feld des Ereignis-Puffers

2.4.6 Polling vs. Interrupt-Modus

Nachfolgend werden mögliche Betriebsarten für die Abtastung von Signalen erläutert und kurz auf die Vor- und Nachteile der einzelnen Möglichkeiten eingegangen.

2.4.6.1 Polling-Betrieb

Im Polling-Betrieb (Hauptprogrammschleife) werden die Eingänge mit dem Durchlauf der Hauptprogramm¬schleife zyklisch überprüft. Mit dieser Variante wird beim Einsatz des Datenlogger-Moduls gearbeitet.

Vorteile

Nachteile

Sehre gute Systemstabilität keine Probleme mit gleichzeitigem Schreiben und Lesen des Ereignis-Puffers einfach zu implementieren unabhängig von der Hardware und daher sehr leicht auf andere Mikrocontroller portierbar

durch laufendes Abfragen der Eingänge wird der Prozessor immer belastet. Im Polling-Betrieb (zyklische Abtastung durch Timer-Interrupt) Die Abtastung erfolgt in diesem Fall zyklisch nach einer vordefinierten Frequenz (z.B. 50ms) über einen Timer-Interrupt. In diesem Fall muss sichergestellt werden, dass der Ereignispuffer nicht gleichzeitig gelesen und beschrieben wird (thread safety). Vorteile Abtastfrequenz ist exakt definiert Speichern der Uhrzeit nicht unbedingt erforderlich, wenn die Abtastrate bekannt ist (=> es steht mehr Speicher für die Anwendung zur Verfügung) hardwarespezifische Programmierung notwendig Ereignispuffer muss Thread-sicher sein um Probleme bei gleichzeitigem Schreiben und Lesen zu vermeiden durch laufendes Abfragen der Eingänge wird der Prozessor immer belastet.

Abbildung 2.7: Vor- und Nachteile des Polling-Betriebes

2.4.6.2 Interrupt-Betrieb

Im Interrupt-Betrieb werden die Logik-Routinen nur bei Auftreten einer Änderung aufgerufen. Der Interrupt-Betrieb ist aus Gründen der Systemstabilität u.a. Problematik des gleichzeitiges Lesens und Schreibens des FIFO-Puffers, Unter¬brechung weiterer Systemroutinen, die mit Interrupts arbeiten können (z.B.serielle Schnittstellen) aktuell nicht vorgesehen. Dazu kommt, dass bei kurz aufeinander folgenden Ereignissen sehr viele Interrupts erzeugt werden. Dies kann zur Instabilität des Systems führen.

Vorteile	Nachteile
das System wird nur dann belastet, wenn sich an den Eingängen der Zustand ändert (sehr Ressourcenschonend).	hardwarespezifische Programmierung notwendig Ereignispuffer muss Thread-sicher sein um Probleme bei gleichzeitigem Schreiben und Lesen zu vermeiden sein

2.4.7 Weiteres

• Alle genannten Betriebsarten können über die Ferne modulspezifisch festgelegt werden.

• Der FIFO-Speicher kann gleichzeitig beschrieben und gelesen werden.

• Das Datenlogger-Modul lässt sich sehr einfach in das Application Framework für MicrocontrollerApplication Framework für Microcontroller integrieren (ist aber nicht zwingend notwendig).

2.5 Beschränkungen

2.5.1 Abtastfrequenz

Die Abtastfrequenz hängt wesentlich von der restlichen Applikation ab. Unter Einsatz des Application Frameworks für Mikrocontroller wurde z.B. bei einer Anwendung, deren Hauptaufgabe im Wesentlichen darin besteht die Zustandsänderungen aufzunehmen und diese über ein TCP-IP-Netzwerk zu übertragen, ein durchschnittliche Abtastfrequenzen von f-Abtast > 1 KHz erreicht.

2.5.2 Grösse des Puffers

Je nach verfügbarem RAM-Speicher des eingesetzten Mikrocontroller-Moduls können mehrere Ereignisse aufgezeichnet werden (z.B. bei einem RCM3200-Mikrokontroller-Modul bis zu 1024 Ereignisse). Zur Speicherung eines Ereignsisses werden (6 Byte für Datum/Uhrzeit und Pufferflags sowie 2 Bytes für die 16 gemessenen digitalen Eingangskanäle). Die Daten können anschliessend z.B. in Paketen binär über eine Netzwerkverbindung einem weiteren System zur Verfügung gestellt werden. Möglich wäre auch eine Aufzeichnung im Flash-Speicher (z.B. bei Mikrocontroller-Modulen mit SD-Speicherkarten).

2.5.3 Programmspeicherbedarf

Der Programmspeicherbedarf beim Einbinden des Datenlogger-Moduls beträgt < 1Kb.

2.5.3 Zeitstempel

In den bei Dynamic C™ mitgelieferten Bibliotheken wird eine Variable SEC_TIMER mitgeführt, welche jede neue Sekunde um 1 inkrementiert wird. Die Zählung beginnt dabei ab dem 1.1.1980 00:00:00 Uhr. Ebenso ist der Zugriff auf eine Variable MS_TIMER möglich. Diese Variable wird jede neue Millisekunde um 1 inkrementiert und läuft ca. nach 47 Tagen über (unsigned long-Wert). Dazu kommt, dass die Variable bei jedem Neustart neu initialisiert wird. Sie ist daher für die Erfassung der Zeit in ms nicht gut geeignet. Falls in ihrer Anwendung Zustandsänderungen mit einer Auflösung im ms-Bereich aufgezeichnet werden sollen, dann besteht eine Möglichkeit darin, die mit Dynamic C™ mitgelieferte Bibliothek vdriver.lib zu erweitern. Eine kurze Beschreibung der notwendigen Erweiterungen (ca. 10 Programmzeilen) findet man in den mitgelieferten Beispielen. Bislang ergaben sich keine störenden Einflüsse auf andere Bibliotheken.

2.6 Beispielanwendung

2.6.1 Einfacher Logik-Analysator

An einem Mikrocontroller-Modul sollen 16 digitale Eingänge überwacht werden. Die Daten werden von einem PC-System laufend abgefragt und paketweise über eine Ethernet-Verbindung an ein PC-System übertragen. Am PC-System wird der Signal¬verlauf in Form eines Logikdiagramms ausgewertet und grafisch dargestellt.

2.6.2 Aufzeichnung des Temperaturverlaufes über längere Zeit

An je 8 digitalen Eingängen werden zwei Analog-Digital-Umsetzer angeschlossen an denen ein Temperatursensor und ein Drucksensor zur Messung des Luftdruckes angeschlossen sind. Der Temperaturverlauf und der Druckverlauf eines Tages wird in 5-Minuten-Abständen aufgenommen und im Ereignispuffer gespeichert. Nach einer Woche werden die gespeicherten Daten von einem PC-System ausgelesen und ausgewertet.

2.6.3 Einfache Wärmemengenmessung einer Solaranlage

Über die Zeit von einem Jahr möchte man die ausgebeutete Energiemenge aus den Sonnenkollektoren einer installierten Solaranlage ermitteln. Von der Solaranlage sind die Temperatur des Vorlaufes sowie des Rücklaufes des Heizkreises bekannt. Ebenso kennt man die mittlere Durchflussgeschwindigkeit der Pumpe und die Einsachaltzeiten der Pumpe. Als Kühlmittel wird zu zwei Drittel Wasser und zu einem Drittel das Kühlzusatzmittel R32 verwendet. Dessen spezifische Wärmekapazität beträt 18J/Kg/K.
Die Energieausbeute errechnet sich demnach aus:
Q = m_punkt * cw(T) * ?T [J] (Joule) m_punkt Massendurchsatz [Kg/s]]
Und die mittlere Leistung der Anlage:
Pmittel = ?Q/?t [J/s ] = [W] (Watt)

2.7 Was erhalten sie mit dem Kauf des Datenlogger-Moduls?

Mit dem Kauf des Datenlogger-Moduls erhalten sie:

• den Source-Code des Datenlogger-Moduls für ihre eigenen Anwendungen,

• eine Beschreibung der Funktionsweise der wesentlichen Routinen und des grundlegenden Konzeptes sowie

• drei kleine Beispielanwendungen in denen die wesentlichen Funktionen und ihre Anwendung demonstriert werden.

2.8 Preis

2.9 Versand

Der Versand erfolgt als downloadbares Archiv im zip-Format. Es entfallen deshalb keine Versandkosten. Alternativ können sie auch eine CD anfordern (zusätzlich Euro 5.- innerhalb von Österreich, Versand ins Ausland nach Aufwand).