Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
06.11.2007, 23:03 (Dieser Beitrag wurde zuletzt bearbeitet: 06.11.2007 23:04 von imbe3m112.)
ich bin neu hier und hoffe, dass Ihr mir eventuell helfen könnt. Ich möchte an einen kleinen Druckluftmotor die Drehzahl abmessen. Dazu nehme ich von einem Opel einen Drehzahlmesser mit 16 Impulsen. Bei LabVIEW 8.2.1 habe ich jetzt ein Programm geschrieben, welches auch funktioniert. Jedoch stukkt der Drehzahlmesser gewaltig. Es gibt keine sauberen Übergänge, wie die Drehzahlmesser aus dem Auto. Was kann ich verändern? Oder ist was falsch?
Prinzipiell: Ich steige zwar nicht 100%ig durch, was du mit diesen ganzen Operationen machst, aber ein Drehzahlmesser gibt doch ein digitales Signal mit einer bestimmten (von der Drehzahl abhängigen) Frequenz aus. Zumindest fühle ich mich durch dein VI bestätigt.
Ein Counter ist für die Frequenzmessung wesentlich besser geeignet, als eine softwareseitige Überwachung eines digitalen Eingangs...
Ja, wenn ich wüßte was "stukken" ist...
Aber was ich auf jeden Fall verbessern würde: Die Mittelwertbildung durch eine gleitende Mittelwertbildung zu ersetzen.
Jetzt ist es so: Impulszählung erfolg über 2 sec (diese Zeit ist notwendig) . In diesem Intervall erfolgt bei Dir auch das Updating der Anzeige.
Besser: Updating viel öfter, z.B. alle 100ms, wobei bei jedem Updating die Zählergebnisse der vorangegangenen 2 sec verwendet werden.
"Stukken" beduetet, dass der Drehzahlmesser springt. Er springt z.B. von 100 auf 200 ohne das der Zeiger sich bewegt.
Momentan, wie Lucki schon beschrieben hat, nimmt der Drehzahlmesser den aktuellen Wert, der alle 2sec. ansteht.
Wie bekomme ich hin, wie du schreibst, dass er einen Mittelwert nimmt? Sollte dann der Drehzahlmesser vernünftig laufen?
Ja, er sollte dann vernünftig laufen. Dein Problem ist, dass er momentan 2s lang einen Wert ermittelt und ihn dann auf den Indikator knallt. Damit springt der im 2s-Takt. Wenn du diesen z.B. alle 100ms updatest, wird das "stucken" wesentlich kleiner. Und bitte nimm demnächst mal springen/ ruckeln/ stocken/ ... Es gibt hundert Synonyme dafür, wieso also grade den Dialekt bevorzugen?
Schaue mal in die Palette Signal Processing -> Waveform Measurements. Dort hast du eine ganze Reihe von Mittelwert-VIs. Man kann den natürlich auch schnell selber zusammenbasteln...
Ja ich kann ja das Mittelwert-VI "Mean" nehmen. Jedoch wo schließ ich das an. Ich weiß nicht was Array ist. An anderen Stellen, wo ich denke lässt es sich nicht anschließen.
Dafür solltest du deine aktuellen Messwerte nicht immer wieder überschreiben, sondern immer schön an ein Array anhängen. Sonst wird es ja auch für das VI schwierig, einen Mittelwert zu berechnen - aus einem Wert... Allerdings solltest du die Arraygröße beschränken auf z.B. 100 Werte. Wenn der 101. ankommt, fliegt der 1. aus dem Array raus.
Keine Ahnung, ob es auch ein VI gibt, dass sich die alten Werte automatisch merkt, aber so sollte es auf jeden Fall gehen.
' schrieb:Ja ich kann ja das Mittelwert-VI "Mean" nehmen. Jedoch wo schließ ich das an. Ich weiß nicht was Array ist. An anderen Stellen, wo ich denke lässt es sich nicht anschließen.
Für gleitende Mittelwertbildung ist in LV bestens vorgesorgt. Hab mal ein VI gemacht. Die 2 Schleifen mit Melder (seihe VI) sind nur so eine Spielerei, das läßt sich auch alles in eine einzige Schleife packen.
Es wäre natürlich besser, wenn man die Taktung (500Hz) hardwaremäßig erzeugen würde, und noch besser, wenn man, wie oben schon gesagt, die ganze Flankenzählung (hier über 100ms) überhaupt nicht mit DI, sondern mit dem jeder Messkarte eingebauten Zähler machen würde. Ich habe es aber jetzt mal so gelassen wie Du es hattest. Du kannst damit bis ca. 900U/min messen
' schrieb:Für gleitende Mittelwertbildung ist in LV bestens vorgesorgt. Hab mal ein VI gemacht. Die 2 Schleifen mit Melder (seihe VI) sind nur so eine Spielerei, das läßt sich auch alles in eine einzige Schleife packen.
Es wäre natürlich besser, wenn man die Taktung (500Hz) hardwaremäßig erzeugen würde, und noch besser, wenn man, wie oben schon gesagt, die ganze Flankenzählung (hier über 100ms) überhaupt nicht mit DI, sondern mit dem jeder Messkarte eingebauten Zähler machen würde. Ich habe es aber jetzt mal so gelassen wie Du es hattest. Du kannst damit bis ca. 900U/min messen
WOW das sieht super aus. Aber so weit waren wir in der Schule mit LabVIEW noch nicht. Von daher konnte ich das nicht wissen. Am Montag probier ich das direkt mal mit dem Sensor aus. Ich habe dne zur Zeit nicht hier.
DANKE schonmal! Jetzt muss ich nur noch dahinter steigen, was du da alles rein getan hast
Ich schreibe am Montag nochmal wie das mit dem Sensor geklappt hat.
' schrieb:Für gleitende Mittelwertbildung ist in LV bestens vorgesorgt. Hab mal ein VI gemacht. Die 2 Schleifen mit Melder (seihe VI) sind nur so eine Spielerei, das läßt sich auch alles in eine einzige Schleife packen.
Es wäre natürlich besser, wenn man die Taktung (500Hz) hardwaremäßig erzeugen würde, und noch besser, wenn man, wie oben schon gesagt, die ganze Flankenzählung (hier über 100ms) überhaupt nicht mit DI, sondern mit dem jeder Messkarte eingebauten Zähler machen würde. Ich habe es aber jetzt mal so gelassen wie Du es hattest. Du kannst damit bis ca. 900U/min messen
Nicht schlecht. Die FIR-Filter waren mir bisher zu undurchsichtig - zuviele gleich klingende VIs;)Aber wie ich sehe, lohnt es sich, mal einen Blick drauf zu werfen...
