Analogmessung auf einem Kanal im Hintergrund

' schrieb:Ich muss aber trotzdem an der "deutschen" Benennung der Anschlüsse rumnörgeln:

Da bist du nicht der erste und wirst auch nicht der letzte sein. Ich bin ja der Meinung, so manche Sachen gehören einfach nicht übersetzt. Und von denen gibt es in LabVIEW viele.

Zitat:aber man muss meiner Meinung nach bei LabVIEW schon viele Konzepte kennen, und alle kombinieren.

Das siehst du richtig.
Deswegen tun sich Anfänger, die von den Verkäufern hören "ach, geht alles mit Klick, Klick", plötzlich extrem schwer, wenn's ans Eingemachte geht.

Zitat:(sehe ich als C-Programmierer wie einen Interrupt an)

Genau so sollten die Events auch funktionieren. Die Frage ist nur, ob LabVIEW respektive seine Entwickler das so wollen (und können). Ich hätte auch gerne, dass manche Sachen so mit "asynchronen Interrupts" gehen würden. Aber ist halt nicht.

Zitat:Events hingegen ( vorausgesetzt gut in LV implementiert, was ich aber stark annehme) verbrauchen nur dann CPU-Zeit, wenn Sie auftreten.

Zu Events gemäß einer Event-Sequenz musst man auch noch folgendes beachten: Auch eine Event-Seqeunz ist immer in einen Datenfluss eingebunden. Außerdem, was viel schlimmer ist: Ein VI hat zwei "Main-Threads": einen "BD-Thraed" und einen "FP-Thread" (UI-Thread). Wenn also bei einem VI das FP aktiviert ist, geht auch ein Teil der Rechenzeit an den UI-Thread - und ob der sich durch einen Event beenden lässt, bezweifle ich. Es wäre also besser, den DAQmx-Event in einem parallelen SubVI ohne FP zu betreiben.

Mal zwei gute Aspekte zu LabVIEW: Multitasking ohne Ende, ohne das der Anwender davon was merkt oder sich darum kümmern müsste. Außerdem wird das System von Version zu Version besser. Und da fällt bestimmt auch das Handlen von Events drunter. Events können nämlich auch in einer Datenflusssteuerung manche Sachen erheblich vereinfachen.

Zitat:Würde man das selber machen müssen, dann, ja dann: wären meine Events viel besser.

Klar. Ich hab das mit Delphi und der DAQ-Library nicht anders gemacht.


Wenn du erkannt, verstanden und akzeptiert hast, dass LabVIEW ein Datenfluss-orientiertes System ist und das ganze prinzipiell alleine mit einem in einen Datenfluss eingebundenen DAQmx-Read geht - dann darfst du auch alles in Events machen - sollen die LabVIEW-Spezis in Austin doch sagen was sie wollen.

Anzeige

' schrieb:Ich mach das so.

Könnte ich das Beispiel von dir, auch dazu bringen, per Button zu starten, und dann eine Sekunde lang zu messen und sich dann wieder zu idle wechseln. Ich tu mich schwer, diese Ablaufzeit in die State-machine zu integrieren...

Aus dem Init Frame schickst du den Timer-Wert (ms) (Timing Palette) in ein Schieberegister. Im Record Frame vergleichst du diesen Timer-Wert aus dem SR mit dem aktuellen Wert. In einer zusätzlichen Case-Struktur im Record Frame kannst du dann per lokaler Variable den Record-Button wieder auf false setzen, wenn (Timer_Wert_aktuell - Timer_Wert_Schieberegister) > 1000 ist. Allerdings hängt so die Auflösung dieser Sekunde von deiner Iterationszeit ab.

Edit: Wie gesagt unterliegen deine Sekunden auf diese Weise (wahrscheinlich) einer gewissen Varianz. Deswegen ist mir da eine andere Methode eingefallen.

Die genaue Länge deiner Signalblöcke ist ja bekannt. Du wählst einfach eine geeignete Blockgröße, die du pro Iteration abspeicherst, und zählst die Iterationen seit dem Init-Frame. Fertig. Ab z.B. der 10., 100., oder 1000. Iteration (seit dem Init-Frame) setzt du den Recordbutton via lokaler Variable auf false.


Gruß dimitri

Hallo und danke an alle,
ich danke ich habe alle euren guten Vorschläge verarbeitet, und das Programmgerüst macht alles was ich brauche. Das Blockdiagramm ist aber für meine Begriffe etwas groß geworden, darf ich mal um euren Rat
  Labview_Document.pdf (Größe: 176,71 KB / Downloads: 288)
bitten, ob das so noch durchgeht, oder um Vorschläge, wie ich es eleganter und schöner machen kann...

Ich sag mir immer: Wenn ich einen abgeschlossenen Block am Bildschirm komplett sehe, soll's mir recht sein. Ich komm damit zurecht. Jede deiner While-Schleifen stellt so einen abgeschlossenen Block dar. Und auch die beiden Strukturen rechts und links der While-Schleifen.

Irgendwo hat aber auch diese meine Einstellung eine Grenze. Die Frage ist halt, ob bei fünfzig oder fünf While-Schleifen. Hast du denn mal versucht, die While-Schleifen in SubVIs auszulagern? Zumindest mit der für's Datenspeichern sollte das gar kein Problem sein.

' schrieb:Hast du denn mal versucht, die While-Schleifen in SubVIs auszulagern? Zumindest mit der für's Datenspeichern sollte das gar kein Problem sein.

Ja, hab ich versucht, aber bin da nicht weitergekommen, weil ich zig lokale variablen verwende, und die tun es (oder lieg ich da falsch?) nur in dem VI, wo auch das Frontpanel ist. Beispielsweise bei der Datenspeicherung verriegle ich den Button zum Anzeigen der TDMS-Datei bis die Datendatei geschlossen ist, usw.

Ein SUB-VI, in das 30 Kabel reinlaufen, ist auch nicht wirklich schöner anzusehen.

Es ist nur so, ich hab ein relativ kleines Frontpanel
  Labview_Document.pdf (Größe: 57,02 KB / Downloads: 260)
, aber dazu halt ein schon recht großes Blockdiagramm.

Von Bierdeckel kann also gar keine Rede mehr sein.

Ich habe 2 Bildschirme, aber für das Blockdiagramm bräuchte ich alleine 2 Bildschirme übereinander. Natürlich kann ichs noch was zusammenschieben, aber wenn ichs dann erweitere, fehlt mir vermutlich wieder Platz...

Von der Struktur her bin ich total zufrieden, es ist wunderbar modular erweiterbar durch Erzeuger-Verbraucher und State-Maschines und läuft total performant (wegen der Queues und Events).

Ich wollte hier nur mal die Rückmeldung hören: Ja, so machen wirs auch, oder: NEIN, das geht viel besser.

Anzeige

' schrieb:weil ich zig lokale variablen verwende

Achja. (<= mal was neues).

Zitat:und die tun es (oder lieg ich da falsch?) nur in dem VI, wo auch das Frontpanel ist.

Ja, du liegst nicht falsch.

Zitat:Beispielsweise bei der Datenspeicherung verriegle ich den Button zum Anzeigen der TDMS-Datei bis die Datendatei geschlossen ist, usw.

Das Problem, was ganz allgemein auftritt, ist, dass parallele Abläufen ggf. synchronisiert werden müssen. In einem VI kann man das sehr leicht und einfach mit Lokalen Variablen machen. VI-übergreifend ist das jetzt nicht mehr so einfach. - Naja, eigenlich doch: Dafür gibt es die Synchronisations-Palette (in deinem Falle: Semaphoren?).
Eine weitere Möglichkeit, ohne den Algorithmus ändern zu müssen, wären Referenzen. Du übergibst also eine Referenz auf TDMS-View in das SubVI und kannst dann im SubVI per Referenz auf TDMS-View zugreifen. (Sowas z.B. mach ich.)

Zitat:Ein SUB-VI, in das 30 Kabel reinlaufen, ist auch nicht wirklich schöner anzusehen.

Auch hier hast du wieder recht: Pack die 30 Elemente in einen Cluster (den es nur im BD gibt: bundlen ohne Name) und gib den an das SubVI. Oder leg die 30 Elemente in einen Cluster am FP und übergib diesen Cluster.

Zitat:Es ist nur so, ich hab ein relativ kleines Frontpanel, aber dazu halt ein schon recht großes Blockdiagramm.

Ja, auch hier muss ich dir wieder Recht geben: Finde ich auch.

Zitat:aber wenn ichs dann erweitere, fehlt mir vermutlich wieder Platz...

Zitat:Ja, so machen wirs auch, oder: NEIN, das geht viel besser.

Eigenlich hab ich nie so viele parallele Schleifen. Eigenlich immer drei Stück: Eine mit einer Event-Struktur. Eine, in der nur Anzeigeelemente zyklisch refresht werden (z.B. aus Meldern). Und eine, in der die Statemachine für die Steuerung läuft. Dieser Aufbau ist applikationsunabhängig. Alles, was applikationsbedingt keinen direkten Zugang zum Frontpanel hat/braucht, ist in einem ggf. parallelen SubVI ausgelagert. Das würde jetzt bedeutet: Kleines FP - kleines BD.

' schrieb:Beispiel:

Je länger die auslesende Schleife wartet, desto mehr muss sie aus der Queue lesen.

[attachment=53118:BD.png]

Gruß SeBa

Nochmal danke für dein Beispiel, funktioniert wunderbar. Ein Detail tuts sogar besser als erwartet, ich versteh nur nicht ganz warum es so "gut" funktioniert, und zwar: Die untere while-Schleife holt ja alle Daten aus der Queue und zeigt diese auch absolut korrekt an. Was aber, wenn die Queue leer ist und gar keine Daten drinn sind ? Es ist tatsächlich so, das dann auch nichts passiert, was völlig super ist, ich frage mich nur warum ? Ich hätte eher vermutet, man müsste in einem True/false auswerten, ob Daten drinn sind. Selbst wenn die for-Schleife hinter dem , Queue leeren VI fehlt und das warte_n_ms-vi , funktioniert das ganze immer noch wunderbar. Ich nehme an, wenn man einen leeren Signalverlauf einfach in ein Signalverlaufsdiagramm reinlaufen lassen kann, und es passiert dann einfach nichts, oder was ist die Erklärung, die eben kein Error-Case für eine leere Queue nötig ist ?

Die Queue wartet solange bis Daten anliegen. Das kann ein Wert sein oder Mehrere, jenachdem wie schnell du die Queue ausliest.

Du musst die Dequeue-Schleife aber nicht timen. Lässt du nur das Queue-Leeren VI ohne ein Wait arbeiten, wird die Schleife angehalten bis entweder Daten anliegen oder der Timeout überschritten wird.

Wenn du dir mal die Schleifencounter anschaust, wirst du es sehen.

Gruß SeBa