Hi,
gibt es eine Möglichkeit, dass Daten nur angelegt werden, wenn die Daten auch wirklich angefragt werden?
Ich habe eine DAQ-Schleife (welche Daten von einem C-DAQ kontinuierlich abfragt mit hohen Abtastraten als auch schnell (kleine Samples-Rate).
Die Daten werden mittels Stream-Funktion in eine TDMS Schleife geschrieben. (Funktioniert super
)
In der Hauptschleife sollen lediglich Digitale Daten von der DAQ Schleife hin und wieder abgefragt werden (Digitale Daten werden nicht in TDMS geschrieben!). Daher möchte ich es ungern mittels "Stream" machen, weil dann dort ja ständig die Daten vom C-DAQ angelegt werden, obwohl sie gar nicht gebraucht werden....
Ich suche quasi ein "Stream auf Anfrage"
Welche Möglichkeiten gäbe es?
Hallo LV-New,
Zitat:Daher möchte ich es ungern mittels "Stream" machen, weil dann dort ja ständig die Daten vom C-DAQ angelegt werden, obwohl sie gar nicht gebraucht werden....
Ich suche quasi ein "Stream auf Anfrage"
Also keinen Stream, sondern ein Tag (beide ChannelWires)?
Oder statt einer Queue einen Notifier?
Oder gar eine globale/lokale Variable, obwohl die anderen Alternativen sinnvoller sind?
Hi Gerd_W,
wenn ich es richtig sehe/verstehe scheint es mit Tag nicht zu gehen.
Denn wenn ich eine Sonde auf Kanal schreiben lege laufen da dennoch Daten rein, obwohl Sie nicht angefordert werden. (Siehe angehangenes Beispiel).
Faktisch sollte er erst die Daten in den Kanal schreiben legen wenn Sie auch angefordert werden....
(Plan ist wie gesagt der DAQ-Schleife keine "Arbeit zu bereiten" wenn sowieso keine Daten benötig werden.)
Es ginge natürlich, dass die eine Schleife einen Befehl zur DAQ-Schleife gibt, "jetzt brauche ich Daten" und man dann ein Stream anlegt und die Daten dann wieder in die andere Schleife nach oben gibt. Aber schön ist das ja auch nicht :-)
An globale Variable hatte ich auch zunächst gedacht, allerdings soll man dies ja vermeiden, soweit habe ich es schon gelernt :-)
Und zum anderen schreibt DAQ ja dann dennoch ständig rein und die andere Schleife ließt lediglich irgendwann mal draus....
Irgendwie beschleicht mich das leise Gefühl, dass das was ich vorhabe gar nicht geht.....
Analogie zur Arbeitswelt wäre faktisch:
DAQ=Arbeiter
andere Schleife=Chef
Arbeiter macht wie immer vorbildlich seine Aufgaben
irgendwann kommt der Chef und fragt an was man zuletzt gearbeitet hat und man gibt sofort eine Antwort.
So wie ich "Tag" aktuell verstehe wäre es so als würde der Arbeiter sich alles auf einen Zettel notieren. Den letzen Wert durchstreichen und einen aktuellen Wert notieren und dann einfach den "aktuellen Wert" immer vorlesen.
Richtig?
Hallo LV-New,
Zitat:irgendwann kommt der Chef und fragt an was man zuletzt gearbeitet hat und man gibt sofort eine Antwort.
So wie ich "Tag" aktuell verstehe wäre es so als würde der Arbeiter sich alles auf einen Zettel notieren. Den letzen Wert durchstreichen und einen aktuellen Wert notieren und dann einfach den "aktuellen Wert" immer vorlesen.
Was ist so schlimm daran, dass der Arbeiter immer laut ruft, woran er gerade arbeitet und der Chef das nur dann hört, wenn er in Hörweite ist?
Ein Tag/Notifier merkt sich halt immer nur den letzten (geschriebenen) Wert: danach hattest du doch gefragt, oder?
"Was ist so schlimm daran, dass der Arbeiter immer laut ruft, woran er gerade arbeitet und der Chef das nur dann hört, wenn er in Hörweite ist?"
Die anderen Kollegen werden gestört und es sieht danach aus als hätte ich nichts anderes zu tun als rumzuschreihen :-).
Wie gesagt das was ich haben möchte scheint gar nicht zu gehen. Anstatt ständig sich den letzten Wert aufzuschreiben, war die Idee dass er den aktuellen Wert weitergibt, sobald der "Chef" (die andere Schleife) danach gefragt hat
(28.07.2020 13:41 )LV-New schrieb: [ -> ]Es ginge natürlich, dass die eine Schleife einen Befehl zur DAQ-Schleife gibt, "jetzt brauche ich Daten" und man dann ein Stream anlegt und die Daten dann wieder in die andere Schleife nach oben gibt. Aber schön ist das ja auch nicht :-)
Was ist daran nicht schön? Das neu anlegen?
Dann vielleicht die Alternative: Leg eine Queue an...da wird nichts reingeschrieben, bis der Chef ruft, z.B. über ein Flag oder einen Notifier...Dann legt der Arbeiter einen (oder mehrere) Werte rein...und schon hat sie der Chef auf dem Tisch. Wenn er neue Werte will, muss er halt noch mal rufen!
Wenn kein Stream übergeben werden soll, dann musst Du den Stream mit Abbruch verwenden.
Ich habe es in Deinen VI eingebaut. bei False wird alles verworfen, bei True übertragen.
Gruß
Freddy
Hi, danke für euren vielen Anmerkungen!
Habe es mir heute mal im Detail angeschaut und war erschrocken, das meine Theorie so falsch, in der Praxis war....
Bin ja davon ausgegangen, dass LabVIEW/mein PC doch ganz schön arbeiten müsste wenn ich relativ viele Daten per Stream übergebe.
Aber selbst nach dem ich nun 100 Signale dem "Chef" auf den Tisch lege (per Anforderung) und gleichzeitig noch 1000 Signale per Stream weitergebe an eine andere Stelle (TDMS) habe ich max. 1ms Abweichung zwischen der Kommunikation "Arbeiter (DAQ) und "Chef". - Siehe Anhang!
Oder habe ich da was übersehen?
Danke nochmal für Eure Hilfe!
Hallo LV-New,
Zitat:Aber selbst nach dem ich nun 100 Signale dem "Chef" auf den Tisch lege (per Anforderung) und gleichzeitig noch 1000 Signale per Stream weitergebe an eine andere Stelle (TDMS) habe ich max. 1ms Abweichung zwischen der Kommunikation "Arbeiter (DAQ) und "Chef". - Siehe Anhang!
Bei einem Tag hast du aber keine Historie und damit auch wenig Speicherbedarf - also wenig Aufwand.
Deshalb mein Vorschlag, einfach ständig diesen Tag/Notifier parat zu halten…
Zitat:Bin ja davon ausgegangen, dass LabVIEW/mein PC doch ganz schön arbeiten müsste wenn ich relativ viele Daten per Stream übergebe.
Das solltest du bedenken, wenn du mit einer Queue/Stream arbeitest und der Consumer nicht mit dem Abarbeiten hinterherkommt: das kann dann böse "out of memory"-Fehler geben…
Zitat:Bin ja davon ausgegangen, dass LabVIEW/mein PC doch ganz schön arbeiten müsste wenn ich relativ viele Daten per Stream übergebe.
Das solltest du bedenken, wenn du mit einer Queue/Stream arbeitest und der Consumer nicht mit dem Abarbeiten hinterherkommt: das kann dann böse "out of memory"-Fehler geben…
Aus genau dem Grund hatte ich ursprünglich meine Frage gestellt
Warum ist der TAG nach deiner Ansicht besser geeignet als der Verlustbehafte Stream? Bei beiden habe ich doch keine Historie und damit weniger Speicherbedarf?!