Guten Tag, in einem Projekt möchte ich die Vibrationen eines Motors und die dazugehörige Drehzahl miteinander darstellen. Die Vibrationen werden mittels eines Beschleunigungssensors aufgenommen und die Drehzahlen erhalte ich von einem Encoder (Rechtecksignal, 32 Impulse pro Umdrehung). Diese beiden Signale habe ich mit einem Oszilloskop aufgenommen und als csv-Datei abgespeichert. Dabei erhalte ich von dem Encoder ein Rechtecksignal. Die unterschiedlichen Periodendauern des Rechtecksignals stehen dabei für die jeweilige Drehzahl. Diese wollte ich nun in Matlab darstellen. Leider weiß ich nicht wie ich aus dem Rechtecksignal die Drehzahlwerte erzeuge, hat jemand eine Idee? Ich hoffe die Frage passt in das Forum. Grüße
Encodersignalspannungswert diskretisieren ( z.b. Spannung > 1/2 * Encoderpegel = 1 , Spannung <= 1/2 * Encoderpegel = 0). Da du vermutlich eine feste Samplingrate hattest um das CSV aufzunehmen, kannst du jetzt einfach die Anzahl der Samples zählen, die von einer 1 über eine 0 zu einer 1 des Encodersignals benötigt werden und die Anzahl dann mit der Abtastrate multiplizieren. Dann dieses Produkt (=Zeit) * 32 (wegen 32 Impulse pro Umdrehung). Und davon den Kehrwert.
Danke für den Tipp. Das Diskretisieren habe ich nun mal ausprobiert, allerdings wird wohl die ganze Auswertung nicht klappen, da der Pegel scheinbar in der Messung eingebrochen ist. Das erste Bild 1 zeigt das geplottete Signal in Matlab ohne Bearbeitung, das Bild zwei nach der Diskretisierung. Die Drehzahl wurde im Versuch linear erhöht, die Grafiken widersprechen dieser Durchführung. Bild 3 zeigt ebenfalls das abweichende Signal im oberen Bereich, allerdings entsprach das Signal beim Reinzoomen (unterer Bereich) einem Rechtecksignal. Nun bin ich überfragt was das zu bedeuten hat, die Umsetzung des Vorschlags erschien mir zielführend.
Bild 1 sieht mir auch nicht annähernd nach einem Encodersignal aus. Ich hab mir deine CSV gar nicht geplottet, sondern bin davon ausgegangen, dass es sich um ein Rechtecksignal handelt. Bist du sicher, dass das Bild 1 nicht vielleicht dein Beschleunigungssensorsignal ist?
Timo N. schrieb: > Bild 1 sieht mir auch nicht annähernd nach einem Encodersignal aus Nein. Aber wie auch immer, der TO sollte zuerst mal überschlägig berechnen, was da rauskommen soll - bei 1000 U/min z.B. sind das mehr als 500 Hz, d.h. eine Periode dauert 2 ms, und das soll z.B. mit 10 bit aufgelöst werden. Dann muss die Samplingrate kürzer als 2 µsec sein- kann das Matlab? Ich glaube nicht. Je nach zu erwartender Drehzahl muss man statt Periodendauermessung eine Frequenzmessung verwenden, also die Anzahl Impulse / Zeiteinheit erfassen - mit einem Zähler und einer Zeitbasis. Georg
Der Beschleunigungssensor hat einen anderen Verlauf. Die Daten des Beschleunigungssensors sind in Bild drei gelb und die des Encoders grün. Das Signal wird ja im gezoomten Zustand in Bild 3 richtig dargestellt nur in den Messwerten irgendwie nicht. Ist somit die Samplingrate vom Oszilloskop zu gering gewesen, wobei es ja im gezoomten Zustand stimmt? Die Drehzahl steigt bis auf 4000 1/min.
Rechts steht "Freq: 1.04 kHz", ist das die Encoder-Frequenz? Geteilt durch 32 heisst dann 32,5 Umdrehungen pro Sekunde oder 1950 pro Minute.
georg schrieb: > Dann muss die Samplingrate kürzer als 2 µsec sein- kann das Matlab? Ich > glaube nicht. Warum soll Matlab das nicht Können?
Maik H. schrieb: > Das Signal wird ja im gezoomten Zustand in Bild 3 richtig dargestellt > nur in den Messwerten irgendwie nicht. > Ist somit die Samplingrate vom Oszilloskop zu gering gewesen, wobei es > ja im gezoomten Zustand stimmt? Auf den ersten Blick sehen die oberen Messungen tasächlich nach zu geringer Abtastrate aus. Aber wie du richtig schreibst, würde dann im Zoom nicht das echte Rechteck sichtbar werden. Deswegen könnte ich mir vorstellen, dass dein Oszi zwar grundsätzlich schnell genug abtastet, bei der Übersichtsdarstellung (über viele Sekunden) und beim Datenexport dann aber die Datenmenge reduziert/die Daten irgendwie "zusammenfasst", so dass das Rechteck nicht mehr korrekt dargestellt wird. Zähle nach, wie viele Messwerte in deinem csv enthalten sind und welche tatsächliche Abtastrate sich dadurch für deine Messung ergibt. Du musst pro Periode des Encodersignals mehrere Abtastpunkte haben, damit sich das ganze halbwegs auswerten lässt.
ok, ich hab dein csv jetzt erst geöffnet. Man braucht nicht nachzuzählen, weil die Abtastzeitpunkte ja direkt als Zahl angegeben sind. Du hast in den exportierten Daten (und dementsprechend wohl auch in der Übersichtsdarstellung auf dem Oszi) Messwerte im Abstand von 2,5ms - also viel zu langsam für die Auswertung des Dekodersignals. Dass das Oszi die Zoom-Darstellung trotzdem richtig hinkriegt deutet darauf hin, dass es nur die reduzierte Übersichtsdarstellung mit 400S/s exportiert hat. Denkbar wäre noch, dass es den Zoom-Bereich wirklich mit einer anderern Abtastrate gemessen als den Übersichtsbereich (quasi zwei unterschiedliche Zeitbasen verwendet). Wenn sich der Zoom ohne neue Messung verschieben lässt, fällt diese Möglichkeit aber weg. Dann musst du das Oszi nur noch dazu bringen, wirklich alle Messwerte mit der hohen Abtastrate zu exportieren.
Vielen Dank für die Ideen. Es liegt tatsächlich an der Speicherung der Messwerte. Bei der Speicherung als CSV-Datei ist die Anzahl der Messpunkte begrenzt. Dadurch wird sozusagen die Abtastrate reduziert und das originale Signal kann nicht mehr rekonstruiert werden. Abhilfe schafft wohl die Speicherung als Binärdatei. Für die Auswertung in Matlab muss allerdings diese wieder mit einem Zusatztool übersetzt werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.