Aufgabenstellung
Um den 50kW Generator einer Wasserturbine „stoßfrei“ bei 1000min-1 in das Stromnetz einkoppeln zu können, bedurfte es einer genauen Messung der Drehzahl des Generators. Als Impulsgeber fungierte ein induktiver Näherungssensor am äußeren Rand des Generatorrades. Ein zweiter Sensor an der Turbine diente ebenfalls der Drehzahlerfassung und ermöglichte so, den sich im Riemengetriebe ergebenden Schlupf zu messen und einer Überlastung der Anlage vorzubeugen.
Bei 1000min-1 (entspricht 60ms Periode) ergab sich konstruktiv bedingt eine Impulsbreite von 3ms. Da die Drehzahl jeweils innerhalb einer einzigen Umdrehung erfaßt werden sollte, mußte sonach die Zeit zwischen zwei Impulsen gemessen werden. In der Regel löst man solche Aufgabenstellungen mittels freilaufender Zähler oder Mikrokontroller. Nachdem jedoch bereits 2 kaskadierte Hubos auch andere Aufgaben übernahmen, stellte sich die Frage, ob nicht einer der beiden Hubos die beiden Drehzahlen gleich mitmessen könnte.
Problemfall 1 – Der Linux Scheduler
Zwar bietet der Raspberry Pi eine relativ hoch aufgelöste Zeit jedoch erschwert das preemptive Verhalten des Linux Desktop-Schedulers eine dauerhafte genaue Erfassung (pollen) des Signales. Selbst RT-Threads (also hoch prior laufende Threads) werden nach einem längeren ununterbrochenen Konsum einer gewissen Zeitscheibe preemptet und in der Folge niedriger priore Threads scheduled. Dieses Verhalten ist für Desktop-Scheduler durchaus sinnvoll, um „amoklaufende“ hochpriore Prozesse per Command Shell (z.B. in einer Terminalsession) zu killen. Sched_rt_runtime_us und sched_rt_period_us definieren dabei das zeitliche Verhalten des Schedulers. Eine dauerhafte Abtastung des Sensors schied also aus.
Lösung
Um o.g. Problem zu begegnen, wurde die Abtastung in 2 Phasen auf Basis einer Analogmessung gegliedert.
Phase 1 tastet das Signal alle 2ms ab und stellt somit sicher, daß der Scheduler genügend „Sleep“-Zeit erhält, um nicht in o.g. Problem zu geraten. Erkennt der Algorithmus am Signalwert den schaltenden Sensor, dann fällt er in ein dauerhaftes Polling (Phase 2). Mittels der schnellen AD-Abtastung Get_AI_Channel_Raw() der Hubo C++ Library gelingt eine Abtastung in der Nähe von etwa 160µs. Überschreitet der Signalwert eine gewisse Triggerschwelle, so ist das der Moment der Zeitnahme. Die Zeitspanne zweier auf diese Art ermittelter Triggerpunkte definiert somit die Zeit einer Umdrehung und damit die Drehzahl der Turbine.
Das nachfolgende Bild zeigt drei Impulse und deren Signalverläufe gemessen an den AD-Kanälen des Hubo.
Der Verlauf eines einzelnen Signals ist im folgenden Bild ersichtlich.
Die Umschaltung von Phase 1 der Überwachung mit Schedulerunterbrechungen per „Sleep“ auf Phase 2 (dauerhafte pollende Abtastung) erfolgt dabei bei Unterschreitung von 1500 Digit AD-Signal. Die Rückschaltung (und damit die Zeitnahme) erfolgt bei anschließendem Überschreiten des Wertes von 2000 Digit. Aufgrund der relativ hohen Abtastrate von 160µs in Phase 2 ergibt sich bei 100min-1 eine zu erwartende Genauigkeit von 0,16ms/60ms*100=0,27%, d.h. etwa 3min-1.
Problemfall 2 – Der Linux Scheduler
Zwar erlaubt diese Art der Messung bereits relativ genaue Werte, jedoch ist schon allein durch weitere auf dem Raspberry Pi laufende Software nicht auszuschließen, daß der in Phase 2 laufende (pollende) Thread zuweilen doch unterbrochen wird. Im folgenden Bild erkennt man die ermittelten Periodenzeiten pro Umdrehung dargestellt über der Zeit. Deutlich sind einzelne Ausreißer zu erkennen, die auf ein ungewolltes „Ausplanen“ durch den Scheduler zurückzuführen und unvermeidbar sind.
Nun läßt sich dieser Umstand zwar nicht vermeiden, wohl aber anhand einer verzögerten AD-Abtastung erkennen. Eine derart „verspätete“ Messung muß sonach verworfen werden und bei der nächsten Umdrehung die Zeitmessung erneut gestartet werden.
Problemfall 3 – Der langsam drehende Generator
Zunächst scheint es paradox, daß eine langsame Drehzahlmessung zu größeren Problemen führt, als eine schnelle. Verdeutlicht man sich jedoch, daß sich der Meßwertthread in solch einem Fall ebenfalls länger in Phase 2 (also dem dauerhaften Polling) befindet, so wird klar, wieso dieser Fall ein Problem darstellt. Fällt der Thread nämlich in einen Bereich in dem er o.g. Schedulerparameter (sched_rt_runtime_us und sched_rt_period_us ) verletzt, wird er ausgeplant und die Zeitmessung dieser Umdrehung muß fallengelassen werden. Bei sehr langsamen Umdrehungen ist sogar gar keine Messung mehr möglich, da jede Umdrehung fallengelassen werden muß.
Lösung
Die Lösung dieses Falles ist so simpel wie wirksam. Läuft die Turbine langsam, so wird der Meßwertthread vom Algorithmus nach einer bestimmten Zeit (z.B. 10ms) freiwillig per Sleep ausgeplant. Wacht er nun vor dem Durchschreiten der Triggerschwelle (Übergang von Phase 2 auf Phase 1) wieder auf, so ist alles in Ordnung. Andernfalls wird die Messung verworfen und die Zeitmessung beginnt im nächsten Umlauf beim Übergang von Phase 1 nach Phase2.
Das Projekt
Im folgenden Bild ist der Schaltschrank mit seinen Reglern und Steuerelementen zu erkennen. Rechts oben sind die beiden kaskadierten Hubo‘s zu sehen. Weitere Informationen zum Projekt können in den Threads des Raspberry Pi Forums (Heizung und Turbine, Drehzahlmessung) nachgelesen werden.
Die ungemittelte Genauigkeit eines Umlaufs bei 1000min-1 lag bei etwa 3min-1. Zur Simulation der Turbine während der Implementierung des Drehzahlalgorithmus diente eine drehzahlgeregelte Bohrmaschine mit bewegtem Magnet über einem Hall-Sensor. Die mit diesem Aufbau maximal messbare Drehzahl lag im Bereich von etwa 2000min-1, gemessen auf einem Raspberry Pi 2 B. Die Pulsbreite des Testaufbaus wurde der von Generator und Turbine angeglichen und lag ebenfalls im Bereich von 3ms bei 60ms Periodenzeit (d.h. 5%).
Fazit
Zwar ist eine Drehzahlmessung auf einem Betriebssystem nicht einfach durchzuführen, da der Scheduler ein exaktes Timing erschwert, jedoch läßt es sich mit etwas Software in den Griff bekommen, wenn keine zusätzliche Hardware angeschafft werden soll.
Der Fall der Drehzahlmessung stellt insofern einen „Härtefall“ der Impulsmessung dar, als daß Impulszählung bei gleicher Periodendauer i.d.R. weniger Anforderungen an das zeitgenaue Einlesen eines Impulses stellt, als es bei der Drehzahlmessung der Fall ist. Zur Impulszählung bieten sich beim Hubo vordergründig dessen digitale Eingänge (8..32) an.