Nachdem ich dann heute Mittag mit dem LabVIEW-Support telefoniert habe und mit einem Hinweis auf die Spring 2014er Version verwiesen words, dass der DAQ-Assistent fehlerhaft ist in der 2011 Version, habe ich auf der Arbeit nun auf die neue Version geupdatet.
Passenderweise konnte ich dann gleich das Advanced Signal Processing Toolkit mit installieren, um die TSA Autocorrelations-VI zu testen. Diese scheint auch direkt plausible Werte mit auszugeben.
Nachher werde ich zuhause noch weiter an der Segmentierung der Auswertung arbeiten.
Danke erneut für eure geduldige und tatkräftige Unterstützung!
Hallo Adaephon,
Zitat:dass der DAQ-Assistent fehlerhaft ist in der 2011 Version
Sowas fällt nur auf, wenn man ihn benutzt. Die meisten "fortgeschrittenen" LabVIEWer verzichten darauf…
Zitat:habe ich auf der Arbeit nun auf die neue Version geupdatet
Dann solltest du auch daran denken, dein Profil hier anzupassen!
Ich habe es gleich im Profil geändert, danke für die Erinnerung GerdW.
Wegen dem sequenziellen Histogramm habe ich etwas im Internet gesucht und eine VI gefunden, die recht ähnlich dem ist, was ich mir vorstelle.
[
attachment=49228]
Bei dieser VI wird eine PtByPt VI genutzt um eine Queue zu erzeugen welche Blocke erzeugt, die dann dem Histogramm zugeführt werden.
Leider kann ich nicht die bestehende Queue mit dem fortlaufendem Signal über die integrierten Daten an diese Queue anschließen, damit die neue Queue aus 1 sekündlichen Stücken besteht. Gibt es eine solche Queue-VI auch für 1D Werte?
Hallo Adaephon,
du hast vielleicht die LV2013SP1, aber bestimmt noch nicht die LV2014. Die kommt erst Anfang August in die Läden!
Tipp: LabVIEW->Hilfemenü->"Über LabVIEW"…
Kann dein VI gerade nicht anschauen, bin hier mit LV2011 unterwegs.
Zum PtByPt-VI: Das dient dazu, eine Queue zu
simulieren und dabei mit Einzelwerten ("Point by Point") zu arbeiten…
Guten Morgen GerdW,
oh, ich habe mich von dem Aufdruck der DVDs verleiten lassen, dort stand Spring 2014 drauf, aber unter "About Labview" steht 2013 SP 1
Ich habe es geändert.
Von der Running_Histogramm.VI habe ich mal eine Datei für vorherige Versionen erstellt,
ich hoffe das klappt:
[
attachment=49229]
Aber in der ist eher nur exemplarisch eine Idee enthalten, wie so etwas laufen könnte.
Die Einspeisung der Queue mit den Messwerten macht Probleme.
Hallo Adaephon,
was erhoffst du dir von dieser PtByPt-Queue?
Hast du dir mal angeschaut, wie die intern aufgebaut ist? Das gleiche hattest du doch schon selbst programmiert: Schieberegister zum Sammeln von Daten…
Ja,
die Idee dahinter hatte ich schon einmal selbst erstellt,
aber ich hatte gehofft das über diese Art sekündliche Pulse erzeugt werden könnten mit den relevanten Daten.
Aber ich glaube so geht das auch nicht.
Irgendwie muss ich mir eine Schleife erzeugen, welche abhängig von dem Max-Value einzelne Arrays erstellt die die Daten einer Sekunde Messung enthalten.
Meine Idee dafür ist, dass ich einen weiteren Consumer der Queue aufmache, darin eine for-Schleife baue, die jede Sekunde eine neue Iteration macht und in dieser Sekunde die Daten der Queue abgreift und für eine bestimmte Anzahl bins je das Histogramm ausrechnet.
[
attachment=49230]
[
attachment=49231]
Leider scheint auch das nicht zu funktionieren, die for-Schleife reagiert gar nicht auf die Loop-Condition und der Rest leider auch nicht.
Edit:
Aber mir fällt auch gerade auf, dass so meine Idee auch nicht wirklich umgesetzt werden kann. Ich möchte ein fortlaufendes Histogramm welches alle x-ms einen Balken mit den Counts innerhalb dieses Intervalls ausspuckt. Über die obere Idee würde alle Sekunde ein stehendes Histogramm erzeugt werden, wenn es denn laufen würde.
Hallo Adaephon,
Zitat:die for-Schleife reagiert gar nicht auf die Loop-Condition und der Rest leider auch nicht.
Ich habe mal auf den Aufräumknopf gedrückt und dann noch einen Kommentar ins BD geschrieben:
[
attachment=49232]
Zweiter Fehler: Daten an zwei verschiedenen Stellen aus nur einer Queue herauszunehmen endet so gut wie immer im Chaos. Du weißt nie (sicher), welche Daten von welchem Consumer nun gerade gelesen werden…
Sinnbild: eine Queue ist wie ein Förderband, an einem Ende werden Pakete aufs Band gelegt, die am anderen Ende wieder herunterfallen. Du kannst zwischendrin zwar Pakete vom Band nehmen, dann kommt der Arbeiter am Bandende aber durcheinander…
Oh,
ich dachte man kann an zwei Stellen die gleichen Werte einer Queue abgreifen.
Also müsste ich das fortlaufende Histogramm mit in die erste und dann einzige Consumer Loop aufnehmen. Damit es zu keinen Konflikten des Datenflusses kommt.