Heyho!
Ich verzweifle allmälich und hoffe, ihr könnt mir den Tipp geben welcher Schalter hier noch umgelegt werden muss. Kurz Aufgabe und Problem:
Es sollen mit einem USB-9213 kontinuierlich Werte abgetastet werden und zwar im high-res Modus mit der max. Frequenz von 9 Hz (auf 2 Kanälen). Wie das kontinuierlich geht ist so weit klar, bloß dauert der Aufruf des Sub-VI aus dem Haupt-VI halt XX ms, weshalb der Puffer sich langsam immer mehr füllt und die Abtastung hinterher läuft. Entsprechend wird der Zeitversatz der Werte immer größer, bis irgendwann der Puffer überläuft und es einen Fehler gibt.
Mein Anliegen/Wunsch: Ich möchte, dass das Gerät mit 9 Hz abtastet aber ich immer "alle" Werte bekomme, wenn ich das sub-VI anstosse. So ist es egal, ob man es alle 0.5 / 1 oder 2 sek aufruft, weil dann entsprechend die verfügbaren 4,9 oder 18 Werte geliefert würden. Ähnliches habe ich versucht, mit der Erhöhung von "Anzahl samples" im sub-VI zu erreichen, allerdings wartet es dann tatsächlich, bis die auch anstehen. Leider hat auch eine "-1" im DAQ Lesen (was ja eigentlich "alle" bedeutet) nicht geholfen
Vielen Dank und Grüsse,
Dennis
LV2010
Der Property-Node "ReadAllAvailSamp" ist zu überflüssig (falsch). Der bringt nur was bei "finiter" und nicht bei kontinuierlicher Datenerfassung. Wie Du schon geschrieben hast, sollten bei -1 alle Daten im Puffer erfasst werden. Was kriegst Du denn für eine Fehlermeldung, wenn Du -1 anschließst?
Gruß Markus
Heyho!
Hehe - der Hinweis mit dem Property-Node kam eben auch als erstes von anderer Seite. Verzeiht dem Noob bitte den Fauxpas. Ich dachte, der Node braucht nur die "ID" des Task und hat die Weiterleitung als Option. Dass er nur in Reihe eingefügt Wirkung zeigt wusste ich nicht.
Betreffend die -1 : Genau das hat mich so verwirrt - bei "Anzahl Samples" gab es mit -1 eine Fehlermeldung, ich solle bitte etwas >0 eintragen und im DAQ-read später steht als default besagte -1. Dass vom vorderen Case aber nach hinten zun read durchgeleitet wird ist mir bis eben nicht aufgefallen. Ohne dieses wire zu entfernen kann man die -1 also gar nicht nutzen. Und kaum getan klappt's auch endlich mit der zeitgleichen Auswertung der Messdaten und der Puffer bleibt leer
Es gab übrigens noch einen erhobenen Zeigefinger, dass man so etwas eigentlich mit Queues macht und das Problem dann im Zweifel gar nicht in Erscheinung getreten wäre. Die ganzen Programme jetzt darauf umzustellen übersteigt aber meine Fähigkeiten, denn mehr als ein paar Werte lesen, korrelieren und regeln soll das Programm nicht. Und ob dann später in den Rohdaten die Werte mal 1 oder halt 1.1 sek auseinander liegen ist egal, da eh interpoliert wird.
Vielen Dank für die Hilfe. Ich hoffe, der Thread hilft auch dem nächsten Suchenden, der in die "-1 -Falle" beim kontinuierlichen Lesen tappt
Viele Grüße,
Dennis
Wäre nett, wenn Du das funktionierende VI noch hochladen könntest. Aber trotzdem schon mal Danke für die Rückmeldung. Welche Verbindung hast Du weggemacht?
Gruß Markus
Aber klar doch, gern
. Hast recht - so nützt es dem nächsten Suchenden viel mehr. Aus dem Grund ist das angehängte VI jetzt auch in LV8.6 gespeichert...
Auslöser war die Verbindung von "Anzahl Samples" zu DAQ-lesen, wie im angehängten Bild markiert. Diese wird btw. automatisch berücksichtigt, wenn man das Express-VI mit "in DAQmx umwandeln" umwandelt. Macht man es jedoch wie wir es gelernt haben mit "Frontpanel anzeigen" bleibt die Verbindung bestehen, auch wenn man im kontinuierlichen Modus arbeitet. Fieserweise läuft der Draht dann hinter dem case zwischen der Timing-Konfiguration und dem Auslesen entlang, weshalb er dem Anfänger wie mir nicht auffällt. Sobald man das VI wie im angehängten Bild automatisch aufräumen lässt, springt die Verbindung auch ins Auge. Diese muss wie gesagt für kontinuierliches Lesen entfernt werden, da die Timing-Konfiguration einen Wert >0 erwartet, man für "alles lesen" aber hinten eine -1 anhängen muss. Trägt man diese händisch auf dem Frontpanel ein, gibt das DAQ-Timing entsprechend eine Fehlermeldung. Belässt man den Wert hingegen auf >0, wird auch das DAQ-read damit gefüttert und liest eben nur die entsprechende Anzahl Werte, wodurch der Zeitverzug pro Durchlauf immer größer wird und irgendwann den Puffer überlaufen lässt.
Viele Grüße,
Dennis
PS: Upps - mein Fauxpas mit dem property-node ist ja immer noch drin. Den bitte einfach übersehen...
Habe mir nur das erste VI angesehen, und da sehe ich gleich etwas, worauf ich hinweisen möchte:
Im VI "Sample Takt" wird bei kontinuierlicher Erfassung der Eingang "Sample-Zahl" in der Bedeutung umfunktioniert - siehe Hilfe. Der Eingangsname müßte dann richtig heißen "Puffergröße" - aber den Namen in Abhängigkeit der Beschaltung eines anderen Eingangs zu ändern, das hat NI noch nicht geschafft. Man fährt eigentlich immer gut, wenn man den Eingang bei kontinuierlicher Erfassung nicht beschaltet.
Bei unbeschaltetem Eingang "Byte Anzahl" (=-1) am VI Daqmx Lesen passiert dieses: Wenn Pufferinhalt >0, wird die momentan im Puffer vorhandene Anzahl ohne Wartezeit gelesen. Bei Pufferinhalt =0 wird hingegen gewartet, bis ein Wert im Puffer ist.
Jepp, so hatte ich es auch verstanden bzw. von Anfang an gewünscht.
Das mit der Puffergröße stimmt, allerdings kam von NI die Aussage dass es wohl wurscht wäre was man dort anschließt weil er sie wohl eh selbst setzt. Irgendwo hatte ich gelesen je nach Frequenz so im Bereich 5-10 fach der Samplingfrequenz. Ob das jetzt wirklich stimmt oder er nur meinte es wäre wurscht OB man dort einen Wert anlegt, weil er es ohne diesen halt selbst berechnet weiß ich nicht. Könnte man wohl einfach testen, allerdings rennt die Zeit und das Programm sollte seit Monaten stehen...
Viele Grüße,
Dennis