Delay für kontinuierliche Datenerfassung zwingend?
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!
Delay für kontinuierliche Datenerfassung zwingend?
Hallo werte Profis,
in meiner "Tapete" erfasse ich mit 10kHz kontinuierlich 4 AI Kanäle. Verwende ich in der While-Schleife in der die Datenerfassung erfolgt kein Delay (Warten) oder aber setze ich den Delay-Wert zu niedrig an, knallen die analogen Signale unter die Decke bzw. bewegen sich "Bang-bang"-mäßig in einem Vielfachen der möglichen Range mit sehr hoher Frequenz zwischen zwei Extremen. Siehe beigefügtes Bild. Nur in den Zeitabschnitten wo der grüne Signalverlauf kurvig ist, ist alles ok.
Nun zu meinen Fragen:
1) Wieso ist das so? Was passiert da genau?
2) Wie kann ich dem entgegenwirken? Genauer, wie kann ich die Daterfassung so konfigurieren, dass sie möglichst wenig Zeit benötigt und ich so, die erforderliche Delay-Time möglichst gering wählen kann. Ziel ist eine möglichst hohe Datenpunkt-Erfassungsrate, wobei ein Datenpunkt aus Mindestens 100 besser 200 Samples gemittelt sein muss (Reduzierung des Rauschens).
3) Es scheint, dass die Zeit für die Erfsssung variiert. Das beschriebene "Bang-bang" Verhalten tritt in seiner unregelmäßigen Frequenz umso häufiger auf, je mehr ich die Delaytime reduziere. Man kann sozusagen von einer gewissen Wahrscheinlichkeit sprechen. Je niedriger die Zeit, desto höher die Wahrscheinlichkeit, das die Signalverläufe diese riesigen Ausreißer zeigen. Die Anlage ist für Langzeitversuche (mehrere Wochen) konzipiert. Der Programmcode ist derzeit so ausgelegt, dass sich die Steuerung abschaltet, wenn gewisse Werte (der erfassten Analogsignale) überschritten werden. Der Versuch muss dann von vorne gestartet werden, was natürlich dsann sehr ärgerlich ist. Ich würde daher die Wahrscheinlichkeit mit der dieses Verhalten auftritt gerne auf "Null" reduzieren. Sprich, ist es möglich, sicher zu stellen, dass für die Erfassung immer genügend Zeit ist. (Z.B. über eine dynamische Delaytime oder so was?)
Ich hoffe man kann verstehen wo es derzeit hakt. Für alle Ansätze und Erklärungen die ein Laie (Ich) im Stande ist zu verstehen, jetzt schon mal vielen DANK!
RE: Delay für kontinuierliche Datenerfassung zwingend?
Auch ohne VI, so viel schon mal vorweg: In der While-Schleife erfolgt (in der Regel) keine Datenerfassuung, die erfolgt in der Messkarte. In der While-Schleife werden nur die Daten aus dem Puffer abgeholt, und eine Wartefunktion hat da nichts zu suchen. Die kann höchstens dazu führen, dass der Puffer überläuft.
RE: Delay für kontinuierliche Datenerfassung zwingend?
Ich schließe mich den Meinungen meiner Vorredner jg und Lucki an und füge hinzu: Meiner Meinung nach haben die Spikes weder etwas mit Delays (ob vorhanden oder nicht vorhanden ist egal) noch mit dem Datensampeln als solchem zu tun. Ich vermute einen Fehler beim Weiterverarbeiten der einzelnen Datenpakete ...
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
RE: Delay für kontinuierliche Datenerfassung zwingend?
Guten Morgen,
ersteinmal vielen Dank für Eure Rückmeldungen! Zur Erklärung, weshalb ich das Programm dieses Mal nicht hochgeladen habe:
Ich habe das Programm in der Vergangenheit bereits mehrere Male hochgeladen und jedes Mal empörte Antworten über den Zustand erhalten und das man mir mit einer solchen Tapete leider nicht weiter helfen werde. Da mir nicht klar ist, wie/ob ich lediglich Teile des Programms hochladen kann (die dann aber trotzdem lauffähig sind habe ich nun den Versuch gestartet das Problem nur zu beschreiben. Dies scheint aber auch nicht richtig gewesen zu sein.
Ich habe beruflich die Aufgabe, ein bestehendes Programm nach den Wünschen der Bediener zu modifizieren. Der Programmierer ist nicht mehr zu erreichen und eine Dokumentation existiert nicht. Ich bin noch ziemlicher LV-Neuling und dennoch festen Willens, das Programm nach und nach zu verstehen, es in eine neue LV-Konforme Struktur zu bringen und dann - nach und nach - die Wünsche der Bediener umzusetzen.
Sehr gerne würde ich das Programm, mit all seinen SubVIs ersteinmal vernünftig strukturieren, die Anzahl der lokalen Variablen reduzieren, ungenutze Teile entfernen etc. etc. Leider ist mir bis jetzt jedoch bei jedem Versuch dies umzusetzen der Code um die Ohren geflogen. Für Hilfe / Ideen zu diesem generellen Problem wäre ich sehr sehr dankbar!
Nun noch einmal zur akuten Fragestellung:
Zunächst einmal das LV-Projekt in der Anlage. Start über die Datei DSDL4.vi.
@Ich selbst:
Es ist ganz eindeutig (wenn auch indirekt), dass die Wartezeit innerhalb der Whileschleife Einfluss auf die Auftrittswahrscheinlichkeit der Spikes hat. Dies lässt sich anhand des Schiebereglers für die Wartezeit (links im GUI) eindeutig zeigen.
@Lucki:
Mir geht es um den DAQmx - lesen Block. M.E. muss dieser Block für eine kontinuierliche Datenerfassung in eine Whileschleife. Lasse ich die Delay-Funktion weg, habe ich nur noch Spikes.
Wäre super, wenn ihr mir trotz des Tapetencharakters weiter helfen könntet.
Gruß & danke vorab,
Philipp
09.07.2018, 09:41 (Dieser Beitrag wurde zuletzt bearbeitet: 09.07.2018 09:43 von GerdW.)
RE: Delay für kontinuierliche Datenerfassung zwingend?
Hallo Philipp,
lass das Delay weg und gib dafür beim DAQmxRead eine zu lesende Anzahl von Samples vor!
Damit stellst du dann einfach und viel genauer deine Schleifeniterationszeit ein…
Beispiel: Du hast 10kS/s vorgeben und liest 1000 Samples, dann muss DAQmxRead maximal 0.1s warten, bis die Daten geliefert werden.
Tipp: 0.1s ist ein durchaus üblicher Wert, wenn man Daten von DAQmx abfragt. 10 Updates pro Sekunde sind ein guter Kompromiss zwischen Datenmenge und GUI-Updaterate für "nichtextreme" Sampleraten…
Zitat:Für Hilfe / Ideen zu diesem generellen Problem wäre ich sehr sehr dankbar!
Versuche für den Anfang dieses ständige Konvertieren der Daten von DBL(-Array) zu DDT und zurück zu DBL(-Array) zu vermeiden.
Ersetzt SplitSignal durch IndexArray…
Organisiere dein Projekt etwas besser: alle subVIs in (virtuelle) Unterordner, nur das MainVI "DSDL" sichtbar im Hauptzweig…
RE: Delay für kontinuierliche Datenerfassung zwingend?
(09.07.2018 09:31 )Philipp841 schrieb: empörte Antworten über den Zustand erhalten
Sowas muss dich völlig kalt lassen …
Zitat:das man mir mit einer solchen Tapete leider nicht weiter helfen werde.
Sagen wird mal so: Es gibt nicht viele, die sich in ihrer Freizeit die Zeit nehmen Tapeten zu kontrollieren ...
Zitat:Es ist ganz eindeutig (wenn auch indirekt), dass die Wartezeit innerhalb der Whileschleife Einfluss auf die Auftrittswahrscheinlichkeit der Spikes hat.
Das mag ja alles sein - aber: Mit der Wartezeit wird im schlimmsten Falle ein Fehler ausgebügelt. Naja, der Fehler muss nicht zwangsweise ein "Fehler" sein, es kann auch eine "Inkonsistenz" oder einfach nur "schlechte Programmierung" sein.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
RE: Delay für kontinuierliche Datenerfassung zwingend?
(09.07.2018 09:31 )Philipp841 schrieb: Wäre super, wenn ihr mir trotz des Tapetencharakters weiter helfen könntet.
Probier mal die Sequenzierung gemäß Bild: RaceCondition mit allen Variablen.
Najn, da hast du ja eine große Aufgabe vor dir. Ich rate aber trotzdem, diese Aufgabe komplett durchzuziehen. Auch wenn der Chef meint, dass sind unnötige Kosten - die Pflege dieser Tapete verbraucht viel, viel mehr Kosten.
Ich würde mal mit einer FGV für alle Pfade anfangen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
12.07.2018, 09:40 (Dieser Beitrag wurde zuletzt bearbeitet: 12.07.2018 10:03 von Philipp841.)
RE: Delay für kontinuierliche Datenerfassung zwingend?
(09.07.2018 09:41 )GerdW schrieb: Organisiere dein Projekt etwas besser: alle subVIs in (virtuelle) Unterordner, nur das MainVI "DSDL" sichtbar im Hauptzweig…
HY Gerd,
dies habe ich nun schon öfter gehört und würde ich nun gerne angehen. Könntest du mir ein/zwei drei Fragen dazu beantworten:
1) Worin liegt der Vorteil dieser Organisation?
2) Wie ist bei der Erstellung solcher Ordner bzw. dem Hinzufügen von VIs zu Ordnern vozugehen (Drag & Drop)? Gibt es Fehlerquellen?
3) Gibt es eine Möglichkeit mir anzeigen zu lassen, welches SubVI
- an welcher Stelle aufgerufen wird (bzw. auszumachen, wenn es garnicht mehr benötigt wird)
- wie oft aufgerufen wird
- welche lokalen/globalen Variablen verwendet.
4) Worin liegen die Unterschiede zwischen virtuellen Ordnern und den Autofüll-Ordnern?
RE: Delay für kontinuierliche Datenerfassung zwingend?
Hallo Phil,
Zitat:1) Worin liegt der Vorteil dieser Organisation?
Auch Leute, die deinen Code nciht kennen, finden schnell die relevanten VIs…
Zitat:2) Wie ist bei der Erstellung solcher Ordner bzw. dem Hinzufügen von VIs zu Ordnern vozugehen (Drag & Drop)? Gibt es Fehlerquellen?
Am besten direkt im Projekt arbeiten…
Die schlimmste Fehlerquelle ist es, wenn man Dateien außerhalb des LabVIEW-Projektes verschiebt (d.h. nicht mit LabVIEW, sondern dem WinExplorer) - dann meckert das Projekt hinterher über fehlende Dateien…
Zitat:3) Gibt es eine Möglichkeit mir anzeigen zu lassen, welches SubVI
- an welcher Stelle aufgerufen wird (bzw. auszumachen, wenn es garnicht mehr benötigt wird)
Rechtsklick auf das VI im Projekt -> Aufrufer anzeigen
Zitat:- wie oft aufgerufen wird
HauptVI öffnen, dann das entsprechende subVI öffnen. Dann Rechtsklick auf subVI-Icon -> alle Instanzen suchen
Zitat:- welche lokalen/globalen Variablen verwendet.
VI öffnen, Hierarchie anzeigen lassen inkl. der globalen Variablen. (Lokale Variablen siehst du im Blockdiagramm, welches du ja aufgeräumt erstellt hast! )
Zitat:4) Worin liegen die Unterschiede zwischen virtuellen Ordnern und den Autofüll-Ordnern?
- Ein "Autofill"-Ordner ist ein realer Ordner auf deiner Festplatte und das Projekt gleicht jedesmal dessen Inhalt mit der Anzeige im Projekt ab.
- Ein "virtueller" Ordner existiert nur als "Ordnungshilfe" im Projekt, die darin angezeigten Dateien können irgendwo (!) auf deiner Festplatte liegen.