Zwei Queue-Frage an die Experten

@Lucki: Nene - das muss schon so kontinuierlich wie möglich sein, weil ich ja den Verlauf korrelieren möchte. Der Versatz in Punkten wird dann durch die Messfrequenz geteilt und schon kenne ich den Wert in Sekunden. Ob dabei mal 5 oder gar 50 Werte aus dem DAQ kommen sollte nichts ausmachen, weil immer eine konstante Anzahl Werte per Array in den Korrelator geschoben wird.

...Den bösen Fehler hatte ich btw. ungewollt und unbewusst in dem Thread (Suche USB-9213) erzeugt, weil halt die -1 fürs Lesen aller Daten fehlte. Als Ergebnis hat er zwar mit 9 Hz gelesen aber auch immer nur 9 Werte raus geholt und da die Schleife auch ein paar ms frisst haben diese sich letztlich akkumuliert, bis der Puffer überlief


Zum gezeigten VI: Ich habe mir inzwischen selbst eingestanden, dass es sehr unglücklich strukturiert war. Darum sind nun die "nice to know" Quellen in eigene Schleifen gewandert und übernehmen dort auch gleich die Darstellung, so dass 3 Queues weniger nötig sind. Momentan kämpfe ich mit den beiden Datenquellen für die Temperaturverläufe. Deren Synchronität ist zwar im Sekundentakt (gemittelter Verlauf) wichtig aber das könnte man via zweier Q's und getrennter While-Schleifen recht gut abarbeiten. Wo es gerade klemmt ist die Korrelation, die wahlweise eine der beiden Quellen nutzt. Lege ich aber wie bisher beide Q's an einen case und wähle in diesem aus, wer weiter verarbeitet wird, wartet die Schleife trotzdem immer auf beide Werte auch wenn einer davon im Case verpufft. Ich muss die Q's daher irgendwie vorher "umschalten", d.h. die Daten der einen lesen, während die Daten der anderen mit "Queue leeren" zeitgleich vernichtet werden. Schaltet man die andere Quelle auf den Korrelator wird der Spieß einfach umgedreht. So bekäme der Korrelator immer nur einen verlauf und wartet nicht auf den anderen (vorausgesetzt "Q leeren" erwartet keine enthaltenen Werte)

Achja - und der Fehler mit der Keithley-Karte ist inzwischen auch halbwegs klar: 1000 Hz Einstellung entsprechen reell 998,4 Hz Taktung - hahaha, böse Falle. Bisher habe ich es leider noch nicht geschafft wie bei der NI-Box "alle Daten" zu lesen, egal ob es nun 900 oder 1100 sind - er wartet scheinbar immer auf die Anzahl, die als Puffer eingestellt wird. Und setzt man den auf -1 oder 0 meckert er, dass der Wert > 1 sein muss. Mal schauen... nochmal ins sub-VI... Vielleicht ist der Fehler ja ähnlich wie anfangs bei der 9213?!

Viele Grüße,
Dennis

[attachment=61179:SUB_Date...relation.vi]Och menno - LV ist doch echt ein gemeines Programm. Den ganzen Tag habe ich das VI umgeschrieben und mir wirklich Gedanken über den Datenfluss gemacht und nun klemmt es noch mehr. Das ursprüngliche "all in one" VI wo alles in einer einzigen while steckte hat irgendwas zwischen 5 und 25 % CPU gezogen. Dieses hier zieht fast durchgehend 100% und insbesondere die Korrelationsschleife braucht länger als 1000 ms. Interessanterweise braucht sie immer irgendwas um 1000 oder 2000 aber nie z.B. 1500 ms. Wenn man etwas wartet und nicht am Rechner arbeitet rattert sie mit Durchlaufzeiten von 5-10 ms die Queue runter, um dann wieder nachzuhängen. Könnt ihr mir sagen, was ich hier falsch mache? Sind Queues generell Systembremsen? In meinen steckt ja noch nicht mal viel drin - nen paar Arrays zu vielleicht 500 Werten ist doch eigentlich nix...?!

Vorgesehener Ablauf des Programms:

-1,2,3 (s.o.) laufen autark und werden ggf. über lokale Variablen beeinflusst ebenso wie jetzt auch der Thermostat (6)
-4 und 5 laufen in Queues und werden unabhängig voneinander skaliert
-Beide skalierten Verläufe laufen in eine Schleife, die von einem davon die Werte puffert, glättet und ggf. differenziert (warum waren hier eigentlich die ersten 3 differenzierten Werte immer "falsch"?! -> daher der workaround mit Länge +5 und hinten die ersten 5 vom array wieder löschen)
-Das Queue dieser Aufarbeitung läuft in den Kreuzkorrelator

...Und eigentlich nur letzterer macht Zicken. Wie gesagt habe ich Schon Werte deutlich unter 20 gesehen (was auch normal sein sollte) und sonst nur Werte zwischen 1850 und 2150 und ab und zu mal 900-1100. Das spricht doch irgendwie dafür, dass die Schleife nen Timing bekommt aber mehr als die Queue hängt doch nicht dran. Und solange diese Werte hat sollte die Korrelation doch schnell durchlaufen (was sie ja auch ab und zu mal tut...)?!

Diesmal etwas mehr Anhang - vielleicht steckt der Fehler ja im sub-VI?? Ist aber rel. unwahrscheinlich, da die "all in one" Version fast identische sub-VIs genutzt hat.

(Kompatibel gespeichert aus 2010)


PS: Die KPCI dauert mal +10, mal -10 - Sie ist nicht die Ursache, wie man an der leeren Queue sieht.

PPS: Kurzer Trockentest: Simulierter Verlauf mit 10.000 Werten läuft etwa 4-5 Mal pro sek durch den Korrelator incl. Gererierung des Verlaufes, Puffer und co. Hier sind es i.d.R. nur 270 oder ~1500 Werte...

' schrieb:Stimmt natürlich, nur: Kartenpuffer << RAM (Queue).

Es kann durchaus sein, daß ich mich mit der Meinung, daß die DAQmx-Datenerfssung in der Regel eine Producer-Consumer-Struktur überflüssig macht, weil es selbst schon eine ist, zu weit aus dem Fenster gelehnt habe. Ich habe das noch nie von anderer Seite so gehört, deshalb erwarte ich Widerspruch und freue noch über jede Diskussion.

Zu Deinem Einwand: Es ist richtig, was Du sagst, nur läuft der Einwand ins Leere. Der Kartenpuffer ist zwar tatsächlich klein. Aber der ist doch nicht identisch mit dem DAQmx- Empfangspuffer, der sich per Konfiguration fast beliebig groß machen läßt und der sich im RAM des PC befindet. Die Datenübertragung zwischen zwischen Karte und diesem Puffer erfolgt über DMA.

(Nebenbemerkung: Es scheint hier einen Unterschied zu geben zwischen den klassischen Treibern für ältere Karten und DAQmx. Bei den älteren Treibern konnte man über Eigenschaftsknoten festlegen, ob nur der Kartenpuffer, nur der PC-RAM-Puffer oder beides verwendet werden soll. Bei DAQmx habe ich solche Einstellungen bisher nicht gefunden, bin aber froh darüber. Ich gehe davon aus, daß das Zusammenspiel zwischen den beiden Pufferbereichen von LV jetzt so intelligent gemanaged wird, dass sich der Programmierer darüber keine Gedanken zu machen braucht.)

Gruß Ludwig

Okay - Fehler gefunden: Es war die Erkennung des ersten Maximalwertes in der Korrelationsfunktion. Anbei ein Screenshot des Teils, der zuerst das Gesamtmaximum ermittelt, dann den ersten Wert über 0,5*diesem ermittelt und ab dort den ersten, der wieder darunter geht. Ausgewertet wurde dann nur der Bereich von 0 bis hier und schon hatte ich das erste Maximum. Funktioniert, frisst aber scheinbar reichlich CPU-Leistung. Habt ihr eine elegantere Lösung?!

Vielen Dank und Gruß,
Dennis

' schrieb:Zu Deinem Einwand: Es ist richtig, was Du sagst, nur läuft der Einwand ins Leere. Der Kartenpuffer ist zwar tatsächlich klein. Aber der ist doch nicht identisch mit dem DAQmx- Empfangspuffer, der sich per Konfiguration fast beliebig groß machen läßt und der sich im RAM des PC befindet. Die Datenübertragung zwischen zwischen Karte und diesem Puffer erfolgt über DMA.

Was mir "ein Sicherheitsgefühl verleiht" ist: Produce-Schleife beinhalten nur das DAQ-Rd und das füllen der Queue - da kann relative wenig schiefgehen/ ins Stocken geraten. In der Consumer-Loop ist dann ein ganzer Haufen an Code - Darstellung/Verarbeitung/TDMS-Write/etc... Wenn's denn stockt, dann da. Und dann wird weder Kartenpuffer noch DAQmx-Empfangspuffer beansprucht und sone Queue kann viel schlucken ... DAQ-Read wird nicht ausgebremst.

Keine Ahnung ob diese Vorgehensweise nur eine sehr sehr theoretische Fehlerquelle ausmertzt, geschweige denn überhaupt irgendwas ausmertzt...

Dann finde ich aber auch 2 Schelifen toll, da man schließlich fast nur noch mit (mind.) DualCores zu tun hat.


Gruß dimitri

Dem stimme ich zu. In meinem Projekt stecken die beiden kontinuierlichen Erfassungen jetzt fast alleine in den Erzeugerschleifen, da selbst ein Graph ggf. mal nen paar ms
fressen kann und - sofern er hinter der Erfassung kommt - diese paar ms dann als Versatz akkumuliert. Insofern bin ich wirklich froh über eure Hilfe mit den Queues, da diese die durchgängige Erfassung erst wirklich möglich macht.

Zitat:Dann finde ich aber auch 2 Schelifen toll, da man schließlich fast nur noch mit (mind.) DualCores zu tun hat.

Außer wir armen Studenten - meiner ist nen P4@2600/2GB und damit liege ich noch rund 50% über dem, was die anderen bei uns als Messrechner einsetzen. Nur einer geht drüber - die verwenden einen i5@2800/8GB, weil sie Bilder einer Hochgeschwindigkeitskamera auswerten und einen Laser danach positionieren. Damit haben sie ihren Core2duo/4GB regelmäßig in die Knie gezwungen...
Wobei: Nach dem, was ich jetzt hier gelernt habe werde ich sie mal auf Queues ansprechen. Evtl. ist das Design ja linear und sie nutzen tatsächlich nur einen Kern...?!?!?


Aber doch nochmal die Frage in eigener Sache betreffend die letzte in meinem VI zu verarbeitende Queue: Wie vorher pendelt die Dauer der Schleife immer so um den Wert des Taktes, d.h. mal 900, mal 1000 aber nie 100, 200... auch wenn die Queue voll gelaufen ist. Dann plötzlich steht dort ein paar Mal 10...7...5... und ein paar - aber nicht alle - Elemente werden abgearbeitet und dann springt sie wieder in den 1000er takt. Habt ihr da eine Erklärung für? Eigentlich sollte diese Schleife doch nur einen Takt haben, wenn die Queue keine Elemente mehr hat und ansonsten "so schnell wie möglich" laufen?!?

Viele Grüße,
Dennis

Anzeige

@Dimitri
Die hast ja wieder Recht, wenn Du schreibst, daß eine Queue zwischen Datenerzeugung und -empfang die Unterbrechung der Datenerzeugung wirksam verhindert, wenn bei Datenempfang und -verarbeitung mal etwas ins Stocken gerät.

Nur ist eben "Queue" nur ein anderer Ausdruck für "FIFO-Puffer", und der DAQmx-Datenpuffer ist genau so einer, und zwar mit ähnlichen Leitungsmerkmalen wie der FIFO-Puffer der sich "Queue" nennt (z.B Puffergröße bereffend) (Es stehen lediglich für diesen Puffer nicht so viele Funktionen zur Verfügung wie bei den Queues - schließlich ist der Puffer ja nur für die einfache Zwischenspeicherung von DAQmx- Daten bestimmt).

Alle was Du an der Queue lobst trifft also auch auf den QAQmx-FIFO-Datenpuffer zu.
Und außerdem: Die Meßkarten besorgen die Datenerfassung mit eigenem Prozessor (und/oder FPGA) autark, und der Datentransport zum Puffer im PC-RAM geschieht per DMA, also ohne nennenswerte Mitwirkung der Main-CPU. Es handelt es sich also hier schon um eine Erzeuger-Verbraucher-Struktur mit getrennten Prozessoren, ohne daß man zwei Kerne der Main-CPU dafür verschwendet. Genialer und einfacher geht es nicht. Bei einer "Doppel-FIFO-Pufferung" mit zusätzlicher Queue und insgesamt drei Prozessor(-kernen) kann ich nur noch Resourccen- und Performance-Verschwendung konstatieren.

Gruß Ludwig

@Cruza..
Entschuldige bitte die Diskusion über Deinen Kopf hinweg mit Dimitri. Die vielen VIs haben mich im Moment etwas abgeschreckt, es ist recht aufwändig sich das alles anzusehen.

Ok, überzeugt. Aber arbeitet der Protagonist überhaupt mit DAQmx? Haben ja nicht alle Treiber son Puffer, oder?

BTW::offtopic2:ich schreibe heute eine MATLAB/LabVIEW-Klausur



@Cruza: ich hoffe auch mein Abschweifen vom Thema stört dich nicht zu sehr.

' schrieb:BTW::offtopic2:ich schreibe heute eine MATLAB/LabVIEW-Klausur

Das schaffst Du doch, viel Spaß dabei. Die Fragen werden doch wohl nicht so schwer sein wie diese hier und auch die Zeitbegrenzung nicht so arg.