{"id":608,"date":"2016-08-04T21:24:33","date_gmt":"2016-08-04T19:24:33","guid":{"rendered":"http:\/\/ftl-auerbach.lima-city.de\/Hubo\/?page_id=608"},"modified":"2019-01-12T17:29:03","modified_gmt":"2019-01-12T16:29:03","slug":"drehzahlmessung-einer-wasserturbine","status":"publish","type":"page","link":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/projekte-support\/drehzahlmessung-einer-wasserturbine\/","title":{"rendered":"Drehzahlmessung einer Wasserturbine"},"content":{"rendered":"

Aufgabenstellung<\/strong><\/p>\n

Um den 50kW Generator einer Wasserturbine \u201esto\u00dffrei\u201c bei 1000min-1 in das Stromnetz einkoppeln zu k\u00f6nnen, bedurfte es einer genauen Messung der Drehzahl des Generators. Als Impulsgeber fungierte ein induktiver N\u00e4herungssensor am \u00e4u\u00dferen Rand des Generatorrades. Ein zweiter Sensor an der Turbine diente ebenfalls der Drehzahlerfassung und erm\u00f6glichte so, den sich im Riemengetriebe ergebenden Schlupf zu messen und einer \u00dcberlastung der Anlage vorzubeugen.<\/p>\n

Bei 1000min-1 (entspricht 60ms Periode) ergab sich konstruktiv bedingt eine Impulsbreite von 3ms. Da die Drehzahl jeweils innerhalb einer einzigen Umdrehung erfa\u00dft werden sollte, mu\u00dfte sonach die Zeit zwischen zwei Impulsen gemessen werden. In der Regel l\u00f6st man solche Aufgabenstellungen mittels freilaufender Z\u00e4hler oder Mikrokontroller. Nachdem jedoch bereits 2 kaskadierte Hubos auch andere Aufgaben \u00fcbernahmen, stellte sich die Frage, ob nicht einer der beiden Hubos die beiden Drehzahlen gleich mitmessen k\u00f6nnte.<\/p>\n

 <\/p>\n

Problemfall 1 \u2013 Der Linux Scheduler<\/strong><\/p>\n

Zwar bietet der Raspberry Pi eine relativ hoch aufgel\u00f6ste 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\u00e4ngeren ununterbrochenen Konsum einer gewissen Zeitscheibe preemptet und in der Folge niedriger priore Threads scheduled. Dieses Verhalten ist f\u00fcr Desktop-Scheduler durchaus sinnvoll, um \u201eamoklaufende\u201c 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.<\/p>\n

 <\/p>\n

L\u00f6sung<\/strong><\/p>\n

Um o.g. Problem zu begegnen, wurde die Abtastung in 2 Phasen auf Basis einer Analogmessung gegliedert.
\nPhase 1 tastet das Signal alle 2ms ab und stellt somit sicher, da\u00df der Scheduler gen\u00fcgend \u201eSleep\u201c-Zeit erh\u00e4lt, um nicht in o.g. Problem zu geraten. Erkennt der Algorithmus am Signalwert den schaltenden Sensor, dann f\u00e4llt er in ein dauerhaftes Polling (Phase 2). Mittels der schnellen AD-Abtastung Get_AI_Channel_Raw()<\/a> der Hubo C++ Library gelingt eine Abtastung in der N\u00e4he von etwa 160\u00b5s. \u00dcberschreitet 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.<\/p>\n

Das nachfolgende Bild zeigt drei Impulse und deren Signalverl\u00e4ufe gemessen an den AD-Kan\u00e4len des Hubo.<\/p>\n

\"Generatorsignalverlaeufe\"<\/a><\/p>\n

Der Verlauf eines einzelnen Signals ist im folgenden Bild ersichtlich.<\/p>\n

\"Sensorsignalverlauf\"<\/a><\/p>\n

Die Umschaltung von Phase 1 der \u00dcberwachung mit Schedulerunterbrechungen per \u201eSleep\u201c auf Phase 2 (dauerhafte pollende Abtastung) erfolgt dabei bei Unterschreitung von 1500 Digit AD-Signal. Die R\u00fcckschaltung (und damit die Zeitnahme) erfolgt bei anschlie\u00dfendem \u00dcberschreiten des Wertes von 2000 Digit. Aufgrund der relativ hohen Abtastrate von 160\u00b5s in Phase 2 ergibt sich bei 100min-1 eine zu erwartende Genauigkeit von 0,16ms\/60ms*100=0,27%, d.h. etwa 3min-1.<\/p>\n

 <\/p>\n

Problemfall 2 \u2013 Der Linux Scheduler<\/strong><\/p>\n

Zwar erlaubt diese Art der Messung bereits relativ genaue Werte, jedoch ist schon allein durch weitere auf dem Raspberry Pi laufende Software nicht auszuschlie\u00dfen, da\u00df der in Phase 2 laufende (pollende) Thread zuweilen doch unterbrochen wird. Im folgenden Bild erkennt man die ermittelten Periodenzeiten pro Umdrehung dargestellt \u00fcber der Zeit. Deutlich sind einzelne Ausrei\u00dfer zu erkennen, die auf ein ungewolltes \u201eAusplanen\u201c durch den Scheduler zur\u00fcckzuf\u00fchren und unvermeidbar sind.<\/p>\n

\"Schedulerbedingte_Ausreisser\"<\/a><\/p>\n

Nun l\u00e4\u00dft sich dieser Umstand zwar nicht vermeiden, wohl aber anhand einer verz\u00f6gerten AD-Abtastung erkennen. Eine derart \u201eversp\u00e4tete\u201c Messung mu\u00df sonach verworfen werden und bei der n\u00e4chsten Umdrehung die Zeitmessung erneut gestartet werden.<\/p>\n

 <\/p>\n

Problemfall 3 \u2013 Der langsam drehende Generator<\/strong><\/p>\n

Zun\u00e4chst scheint es paradox, da\u00df eine langsame Drehzahlmessung zu gr\u00f6\u00dferen Problemen f\u00fchrt, als eine schnelle. Verdeutlicht man sich jedoch, da\u00df sich der Me\u00dfwertthread in solch einem Fall ebenfalls l\u00e4nger in Phase 2 (also dem dauerhaften Polling) befindet, so wird klar, wieso dieser Fall ein Problem darstellt. F\u00e4llt der Thread n\u00e4mlich 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\u00df fallengelassen werden. Bei sehr langsamen Umdrehungen ist sogar gar keine Messung mehr m\u00f6glich, da jede Umdrehung fallengelassen werden mu\u00df.<\/p>\n

 <\/p>\n

L\u00f6sung<\/strong><\/p>\n

Die L\u00f6sung dieses Falles ist so simpel wie wirksam. L\u00e4uft die Turbine langsam, so wird der Me\u00dfwertthread vom Algorithmus nach einer bestimmten Zeit (z.B. 10ms) freiwillig per Sleep ausgeplant. Wacht er nun vor dem Durchschreiten der Triggerschwelle (\u00dcbergang von Phase 2 auf Phase 1) wieder auf, so ist alles in Ordnung. Andernfalls wird die Messung verworfen und die Zeitmessung beginnt im n\u00e4chsten Umlauf beim \u00dcbergang von Phase 1 nach Phase2.<\/p>\n

 <\/p>\n

Das Projekt<\/strong><\/p>\n

Im folgenden Bild ist der Schaltschrank mit seinen Reglern und Steuerelementen zu erkennen. Rechts oben sind die beiden kaskadierten Hubo\u2018s zu sehen. Weitere Informationen zum Projekt k\u00f6nnen in den Threads des Raspberry Pi Forums (Heizung und Turbine<\/a>, Drehzahlmessung<\/a>) nachgelesen werden.<\/p>\n

\"Schaltschrank_mit_Beschriftung\"<\/a><\/p>\n

Die ungemittelte Genauigkeit eines Umlaufs bei 1000min-1 lag bei etwa 3min-1. Zur Simulation der Turbine w\u00e4hrend der Implementierung des Drehzahlalgorithmus diente eine drehzahlgeregelte Bohrmaschine mit bewegtem Magnet \u00fcber 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%).<\/p>\n

 <\/p>\n

Fazit<\/strong><\/p>\n

Zwar ist eine Drehzahlmessung auf einem Betriebssystem nicht einfach durchzuf\u00fchren, da der Scheduler ein exaktes Timing erschwert, jedoch l\u00e4\u00dft es sich mit etwas Software in den Griff bekommen, wenn keine zus\u00e4tzliche Hardware angeschafft werden soll.<\/p>\n

Der Fall der Drehzahlmessung stellt insofern einen \u201eH\u00e4rtefall\u201c der Impulsmessung dar, als da\u00df Impulsz\u00e4hlung 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\u00e4hlung bieten sich beim Hubo vordergr\u00fcndig dessen digitale Eing\u00e4nge (8..32) an.<\/p>\n","protected":false},"excerpt":{"rendered":"

Aufgabenstellung Um den 50kW Generator einer Wasserturbine \u201esto\u00dffrei\u201c bei 1000min-1 in das Stromnetz einkoppeln zu k\u00f6nnen, bedurfte es einer genauen Messung der Drehzahl des Generators. Als Impulsgeber fungierte ein induktiver N\u00e4herungssensor am \u00e4u\u00dferen Rand des Generatorrades. Ein zweiter Sensor an der Turbine diente ebenfalls der Drehzahlerfassung und erm\u00f6glichte so, den\u2026<\/p>\n

Continue reading<\/span><\/i><\/a> <\/p>\n","protected":false},"author":1,"featured_media":0,"parent":577,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/pages\/608"}],"collection":[{"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/comments?post=608"}],"version-history":[{"count":21,"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/pages\/608\/revisions"}],"predecessor-version":[{"id":1394,"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/pages\/608\/revisions\/1394"}],"up":[{"embeddable":true,"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/pages\/577"}],"wp:attachment":[{"href":"https:\/\/ftl-auerbach.lima-city.de\/Hubo\/wp-json\/wp\/v2\/media?parent=608"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}