DAQ-Anzeige in seperatem VI und Speicherung in TDMS Format

Sehr geehrte Labview Community,

bin noch ein ziemlicher Frischling und arbeite zur Zeit an einer automatischen Steuerung für einen DC Generator. Hierfür habe ich eine Messbox mit digitalen und analogen Input/Output Möglichkeiten. Ein gewisses Grundgerüst des Steuerprogramms steht bereits.
Hier bin ich mir allerdings sehr unsicher, wie ich die Funktionalitäten auf VIs aufteile. Ich möchte ja eine maximale Performance erreichen mit einer maximalen Samplerate von Messwerten, die ich verarbeite.

Zu meiner DAQ gehören 3 Analoge Spannungssignale.

Der Generator wird mit einem analogen Outputsignal angesteuert. Dieses Ausgangssignal wird in abwechselnden VIs durch einen Regelkreis berechnet, in einer globalen Variable gespeichert und an die Messbox gesendet.
In diesem Regelkreis der AVG(Durchschnitts)/RMS(Leistung/Peak(Spitze)-Wert eines analogen Inputsignals eine begrenzende Rolle.

In meiner Anzeige sollen die 3 analogen Inputsignale sowie mein analoges Outputsignal (Steuersignal) in einem Wafeform Chart dargestellt werden.

- Ein Teil der Messwerte muss verrechnet werden (RMS/AVG/Peak-Werte über ein bestimmtes Zeitfenster bestimmen.)
- Meine Messwerte müssen geprüft werden, ob nicht verschiedene Grenzwerte überschritten wurden, woraufhin ein Alarm ausgelöst werden soll und die Maschine erst einmal stillgelegt wird.
- Die Messwerte inkl. AO-Signal sollen im selben Chart im Anzeige-VI FP dargestellt werden.
- Die Messwerte inkl. AO-Signal müssen gespeichert werden.

Das Anzeige-VI FP möchte ich durch global gespeicherte Referenzen auf die FP-Elemente und Propertynodes(Value) lösen.
Das bedeutet aber auch, dass ich im DAQ-VI die DAQ-Daten um mein AO-Signal erweitern muss bevor ich dem Propertynode(Value) diese Daten übergebe.

Wohin mit der RMS/AVG/Peak-Wertgeschichte? Wenn ich diese ins DAQ-VI packe, sorgt das für eine geringere Updaterate, nehme ich an.

• DAQ.vi Kontinuierliche DAQ n Channel mit m Samples/Update; Erweiterung der Waveform-Daten um das AO-Signal; Berechnung der AVG/RMS/Peak-Werte; Speichern aller Werte in globaler Variable
• Anzeige.vi Wafeformchart zur Anzeige der DAQ und des AO-Signals sowie Skalenanzeige der AVG/RMS/Peak-Werte
• Global_Stats.vi Hier wird der jeweils aktuellste Wert aller digitalen und analogen Messwerte gespeichert.
  

Andere Optionen wären Shared Variables für den Datentransfer vom DAQ-VI zum Anzeige-VI...
Soll ich diese Berechnung von AVG/RMS/Peak-Werten über ein bestimmtes Zeitfenster in seperate VIs packen, welche parallel funktionieren und auf die geshareten Wafeform-Daten zugreifen? Hier müsste ich mich erst reinlesen und einiges ausprobieren. Ist das sinnvoll?

Meine Regelkreis-VIs (es sind mehrere) greifen auf eines der AI-Signale zu sowie die AVG/RMS/Peak-Werte und bestimmt das neue AO-Signal. Ist es sinnvoll, wenn dieser Regelkreis nur über globale Variablen auf den Wert des einen AI-Signals sowie die berechneten AVG/RMS/Peak-Werte zugreift? Oder geht das schneller/direkter?

Zeitkritisch ist die eigentliche Steuerung nicht, nur dass der gemessene Peakwert nicht länger als 10ms über einem Grenzwert liegen darf.

Vielen Dank schonmal, morgen wird der Beitrag noch ergänzt.

Grüße
Masse

PS: Anmerkung zu den Kommentaren in den angehängten VIs: mit "SCR" ist das AO-Signal gemeint

PPS: Aktuell programmiere ich mit simulierten Devices in MAX. (AI-Gerät, Spannung)

Anzeige

(17.11.2015 16:52 )m.werle schrieb:  Das Anzeige-VI FP möchte ich durch global gespeicherte Referenzen auf die FP-Elemente und Propertynodes(Value) lösen.

Hiervon möchte ich abraten - siehe auch dein DAQ-VI.

Aus mehreren Gründen:

• Globale Variablen zu verwenden ist auch in Labview die schlechteste aller Möglichkeiten. FGVs sind besser.
• Wenn du Referenzen verwendest, dann nimm strikt-typisierte. Die erkennst du daran, dass letztendlich kein roter Konvertierungspunkt erscheint. Das hat dann nämlich gleich den Vorteil, dass du die Daten am Propertynode nicht per Variant übergeben musst.
• Eine Vermischung von Algorithmus-Operationen und Anzeige-Operationen innerhalb eines VIs halte ich immer für schlecht. Anzeige-Operationen dauern sehr lange, Algorithmus-Operationen gehen meistens sehr schnell.
  

Zitat:Wohin mit der RMS/AVG/Peak-Wertgeschichte? Wenn ich diese ins DAQ-VI packe, sorgt das für eine geringere Updaterate, nehme ich an.

Updaterate von was? Anzeige am Frontpanel?

Ich würde das wie folgt machen:

• Ein VI macht alles das, was mit den zu erfassenden Daten und deren grober Verarbeitung zusammenhängt. Hauptaufgabe wird sein, die erfassten Daten aus dem DAQmx zu lesen. Diese Daten liegen dann paketweise vor. Paketweise kannst du sie jetzt weiter verrechnen. z.B. Größere Pakete erstellen und/oder Mittelwert bilden, Peak feststellen etc. Diese Arbeiten - Lesen, Berechnungen wie AVG und Tests etc. - fallen unter "Algorithmus". Wenn du an dieser Stelle ein Arbeitsraster von 5ms verwendest, kannst du hier gleich, wenn du einen zu langen Peak feststellt, die Maschine abstellen.
• Die Daten, die du anzeigen oder auch speichern willst, stellst du entweder per Melder zur Verfügung oder verschickst sie per Queue.
• Die Anzeige (oder das Speichern) machst du in einem separaten VI. Eine Anzeige muss nicht im Raster von 10ms refreshed werden, auch nicht im Raster von 100ms, 250ms sind genug. Dass bei einer Abtastrate von 5ms und einer Anzeigerate von 250ms öfters in die Queue geschrieben wird als aus ihr gelesen wird, spielt überhaupt keine Rolle. In der Anzeige ließt du einfach die komplette Queue aus und verarbeitest die (durchschnittlich) 50 Datenpakete innerhalb eines Anzeigezyklusses.
  

Vielen Dank schonmal für die ausführliche Rückmeldung!

Strikttypisierte Referencen kriege ich gerade nicht hin. Bin so vorgegangen:

Rechtsklick auf FP-Controls
Advanced -> Customize -> In Toolbar Control auf "Strict Type Def" -> In Toolbar File/Apply Changes -> Save VI
Mache ich nun einen Rechtsklick auf den Control (in den angefügten VIs sind es die beiden Charts im AnzeigeVI) habe ich die Auswahl "Open Type Def" dazugewonnen. Das Customize_Fenster öffnet sich und ich kann lesen, dass die Einstellung "Strict Type Def" gespeichert ist...

Der Rote Punkt bleibt jedoch.


Mh, wie berechne ich denn nun beispielshaft den AVG-Wert über einen bestimmten Zeitraum dt ?
Bei einer Updaterate von 200 Hz (Datenpakete pro Sekunde) und einem dt von 10s müsste ich also 2000 Datenpakete mit jeweils m Samples verrechnen.

Bei einer Updaterate von 200 Hz würde ich diesen AVG Wert alle 5ms neu berechnen, jeweils mit dem neusten Datenpaket und den 1999 davor.

Speicher ich die Daten also in eine Queue und lese hierfür die neusten 2000 Datenpakete aus? Die Anzeige liest dann ebenfalls die Daten mit einer relativ niedrigen Frequenz als großes Bündel aus der Queue und ergänzt das Diagramm?

Ich lese mich gerade erst in Queues ein. Und mach damit gleich erstmal weiter.

---

Nachtrag, weil ich nur 5 VIs hochladen konnte.

(18.11.2015 11:36 )m.werle schrieb:  Strikttypisierte Referencen kriege ich gerade nicht hin.

Muss ich später (am Tag) kucken ...

Zitat:Mh, wie berechne ich denn nun beispielshaft den AVG-Wert über einen bestimmten Zeitraum dt ?
Bei einer Updaterate von 200 Hz (Datenpakete pro Sekunde) und einem dt von 10s müsste ich also 2000 Datenpakete mit jeweils m Samples verrechnen.
Bei einer Updaterate von 200 Hz würde ich diesen AVG Wert alle 5ms neu berechnen, jeweils mit dem neusten Datenpaket und den 1999 davor.

Jawohl, genau so kannst du das machen.

Eine Abtastrate von 200Hz (5ms) ist doch recht langsam. Da könntest du fast mit Einzelwerten arbeiten: 1 Wert aus dem DAQmx lesen, 1 Wert in die Historie für AVG aufnehmen etc. Die Mittelwertbildung könntest du wie folgt machen. Erstelle einen Cluster myAVG, der folgendes enthält: Ein Array "Values" der Länge 2000, einen Integer "Anzahl" und einen Integer "Index". myAVG verwendest du als Ringpuffer. Resettet wird der Ringpuffer, indem alles, Index, Anzahl und Array, auf Null gesetzt wird. Summe über "Values" / "Anzahl" ergibt AVG. Hinzufügen geht so: Values[index]=newValue; index=index+1; if (index>=2000) index=0; Anzahl=Anzahl+1; if (Anzahl>2000) Anzahl = 2000;

Zitat:Speicher ich die Daten also in eine Queue und lese hierfür die neusten 2000 Datenpakete aus? Die Anzeige liest dann ebenfalls die Daten mit einer relativ niedrigen Frequenz als großes Bündel aus der Queue und ergänzt das Diagramm?

In die Queue (bzw. in den Melder) schreibst du nur das, was in einem anderen VI verwendet werden soll. Du kannst hier wieder einen Cluster machen, der z.B. AVG enthält und die gemessenen Daten.

Noch ein Wort zu den gemessenen Daten:
Die "gemessenen Daten" entstehen ja in Folge einer Addition aller einzelnen Auslesungen aus dem DAQmx. Diese Daten ergeben also ein Array (bzw. einen Datenstream). Die Frage ist nun, wer verwaltet diesen Stream. Schließlich muss der resettet und aufaddiert werden. Es gibt zwei Möglichkeiten:

• Entweder wird diese Arbeit vom Sample-VI gemacht. Dann wird das komplette Array per Melder (nicht per Queue) verschickt. Dieses Verfahren geht aber nur, wenn der Stream eine bestimmte Größe nicht überschreitet. Diese Größe kann aber durchaus bei 20MB liegen. Auch sollte die Zeit für einen Zyklus (= Streamgröße) einen bestimmten Wert nicht überschreiten (ca. 3 Minuten).
• Oder diese Arbeit wird vom Anzeige-VI erledigt. Dann werden die einzelnen, gelesenen DAQ-Daten per Queue (nicht per Melder) verschickt. Dieses Verfahren muss man anwenden, wenn die Zyklusdauer groß oder gar "unendlich" ist.
  

Einzeln durch DAQmx ausgelesene Datenpakete zu einem Array (Datenstream) zusammenfassen:

Zitat:Entweder wird diese Arbeit vom Sample-VI gemacht. Dann wird das komplette Array per Melder (nicht per Queue) verschickt.

Mit Sample-VI ist das VI gemeint, das die Daten durch DAQmx ausliest nehme ich an. Also nutze ich Notifier nur, wenn ich einzelne Datenpakete statt einer langen Schlange aus Datenpaketen übermitteln möchte. (Queue hat ja beliebig viele Elemente, beim Notifier wird das eine überschrieben, wenn es vorher noch nicht ausgelesen wurde.) An sicht, macht mein Notifier aber doch das selbe wie eine Queue, oder?

Zitat:Oder diese Arbeit wird vom Anzeige-VI erledigt. Dann werden die einzelnen, gelesenen DAQ-Daten per Queue (nicht per Melder) verschickt. Dieses Verfahren muss man anwenden, wenn die Zyklusdauer groß oder gar "unendlich" ist.

Hier habe ich die Möglichkeit viele Datenpakete vom Sample-VI hintereinander in die Queue einzureihen und in dem Anzeige-VI entsprechend darauf zurück zu greifen. Richtig? Von welcher Zyklusdauer redest du hier?

Ich habe einmal eine Updaterate meiner DAQmx, wie viele Datenpakete mit jeweils so und so vielen Samples ich erhalte. Danach richtet sich die Zyklusdauer der Whileschleife im Sample-VI.
Und ich habe eine wesentlich kleinere Updaterate meiner Anzeige. (Vermutlich ungefähr 4Hz, wie du vorgeschlagen hast.)

Ich gehe jetzt einfach mal davon aus, dass ich das richtig verstanden habe. Ich kann eine Queue benutzen, mein Sample-VI speichert immer wieder Werte in die Queue und mein AnzeigeVI ruft ab und zu diese angehäuften Datenpakete auf einmal ab und erneuert die Anzeige.
_____________________________
FGV

• Ich entwerfe ein FGV welches die Queue mit mehreren Datenpaketen für die Anzeige bereit hält. Diese Datenpakete wurden im Sample-VI um den Analogen Output (mein Steuersignal für den Generator) erweitert.
• Cluster mit folgenden Parametern und Stats: Updaterate des Anzeige-VIs sowie des Sample-VIs, Samplerate (Samples/Update für DAQmx), neuster berechneter AVG/RMS/Peak-Wert, Zeitfenster dt für AVG/RMS/Peak, aktueller Wert des AO-Signals)
  

Aufgaben des FGVs
[list]
[*] Queue Initialisieren
[*] Queue Referenz ausgeben
[*] Cluster einlesen
[*] Cluster ausgeben

Ist es sinnvoll die Funktionen des FGVs "Cluster ausgeben" und "Queue Ref ausgeben" zu einer Output-Funktion zu bündeln?

Aufbau des Sample-VIs
Außerhalb der Whileschleife
1.) Meine Queue in meinem FGV initialisieren,
2.) Parameter aus dem Cluster aus dem FGV auslesen und den DAQmx-Task starten.
3.) Mit den ausgelesenen Parametern auch die Cluster myAVG, myRMS und myPeak initialisieren

Innerhalb der Whileschleife
mit meiner Updaterate_DAQ Datenpakete über das DAQmx von meinem Gerät auslesen. Aus diesem Datenstream lese ich die notwendigen Werte für die RMS/AVG/Peak-Werte aus, außerdem den aktuellen AO-Signal-Wert. Die berechneten RMS/AVG/Peak-Werte werden vom FGV wieder eingelesen und der ausgelesene AO-Signal-Wert wird an den Datenstream aus meinem DAQmx angehängt und anschließend in die Queue gespeichert.

Die berechneten AVG/Peak/RMS-Werte werden in einer Eventstructure bei einem Valuechange mit ihrem Grenzwert verglichen, um zu testen, ob ein Alarm ausgelsöt werden muss und die Maschine gestoppt.

Ist es überhaupt möglich die Cluster myAVG, etc. dynamisch bei Aufruf des Sample-VIs zu erstellen, entsprechend der eingestellten Sampleanzahl/Updaterate/Größe des Zeitfensters. Ein ein dimensionales Array mit N Elementen zu initialisieren geht ja. Aber wenn ich verschiedene Daten zu einem Cluster zusammenfüge (Bundle), dann brauche ich doch ein Prototyp Cluster, dass bereits die richtige Form hat... mh.

Anmerkungen zu meinem Analogen Outputsignal
Das AO-Signal wird in einem Regelkreis (RK) berechnet. Es gibt verschiedene VIs mit unterschiedlichen RK, je nach Betriebszustand des Generators. Der RK entnimmt aus dem FGV die neusten Messwerte und berechnet das neue Analoge Ausgangssignal, speichert dieses im FGV ab und sendet es per DAQmx an meine Maschine.

Speicherung der Messwerte
Dies kann ich einfach im Anzeige-VI erledigen, da die Zykluszeit hier entsprechend hoch ist, und ich hier sowieso sämtliche Messdaten aus der Queue auslese, um diese anzuzeigen. Richtig?

(18.11.2015 14:51 )m.werle schrieb:  Mit Sample-VI ist das VI gemeint, das die Daten durch DAQmx ausliest nehme ich an.

Ja.

Zitat:Also nutze ich Notifier nur, wenn ich einzelne Datenpakete statt einer langen Schlange aus Datenpaketen übermitteln möchte. (Queue hat ja beliebig viele Elemente, beim Notifier wird das eine überschrieben, wenn es vorher noch nicht ausgelesen wurde.)

Es wird auch dann überschrieben, wenn es ausgelesen wurde. Ein Melder ist wie eine globale Variable: Es ist kein "Herauslesen", sondern ein "Lesen".

Zitat:An sicht, macht mein Notifier aber doch das selbe wie eine Queue, oder?

Ich stelle mir den Melder immer als Queue mit nur einem möglichen Eintrag vor. Daten aus einer Queue werden "herausgelesen", Daten im Melder nur "gelesen".

Zitat:Hier habe ich die Möglichkeit viele Datenpakete vom Sample-VI hintereinander in die Queue einzureihen und in dem Anzeige-VI entsprechend darauf zurück zu greifen. Richtig?

Ja.

Zitat:Von welcher Zyklusdauer redest du hier?

Viele meiner Programm sind "Dauerlaufprogramme". Da wird ein Prüfling ständig mit der selben Betätigung beaufschlagt. Eine Betätigung (was immer das auch ist) dauert z.B. 30 Sekunden. Von diesen Betätigungen werden dann z.B. 2 Mio gemacht. Die Zyklusdauer ist dann 30 Sekunden. Zu Beginn eines Zyklusses werden diverse Daten im Sample-VI resettet (z.B. Länge Array). Am Ende des Zyklusses wird das Array aus dem Melder gelesen ...

Zitat:Ich habe einmal eine Updaterate meiner DAQmx, wie viele Datenpakete mit jeweils so und so vielen Samples ich erhalte. Danach richtet sich die Zyklusdauer der Whileschleife im Sample-VI.

Eigentlich gefällt mir das nicht. Uneigentlich kannst du das aber auch so machen.
Ich selbst bevorzuge eine konstante, also Abtastraten-unabhängige Schleifendauer, z.B. 50ms. Innerhalb dieser Zeit werden sich einige Samples ansammeln. Wie viele es sind, ist dem Algorithmus eigentlich egal - dafür ist er ja ein Anzahl-unabhängiger Algorithmus geworden.

Zitat:Ich gehe jetzt einfach mal davon aus, dass ich das richtig verstanden habe.

Davon geht ich aus.

Zitat:Ich entwerfe ein FGV ...

Ja - das kannst du so mal probieren.

Zitat:Ist es sinnvoll die Funktionen des FGVs "Cluster ausgeben" und "Queue Ref ausgeben" zu einer Output-Funktion zu bündeln?

Für Ausgaben brauchst du keine explizite Funktion. Alles das, was die FGV ausgibt, kann sie in "Klar-Daten" (also nicht als Variant) ausgeben. Ausgaben stehen immer, also bei jeder Funktion, am Ausgang an. Entweder pro Datum ein Ausgang oder alle Daten gesammelt in einem Cluster und ein Ausgang. Würdest du nur ein Ausgang haben für alle Datentypen, müsstest du extern den Variant-Ausgang typisieren. Das ist aufwändig.

Zitat:Aufbau des Sample-VIs

Alles Ja.

Zitat:Die berechneten AVG/Peak/RMS-Werte werden in einer Eventstructure bei einem Valuechange mit ihrem Grenzwert verglichen, um zu testen, ob ein Alarm ausgelsöt werden muss und die Maschine gestoppt.

Wie, was, wo: Eventstruktur? Im Sample-VI befindet sich keine Eventstruktur!
Ansonsten klingt das an sich ja richtig - naja, ist es ja auch. Aber:
Woher weis die Eventstructur, dass ein ValueChange eingetreten ist? Den ValueChange würde ich im Sample-VI feststellen und dann, z.B. mit einer Melder oder einer Queue oder im Sample-VI selbst speziell zu dem Zeitpunkt, an dem der Notfall eingetreten ist, reagieren.

Zitat:Ist es überhaupt möglich die Cluster myAVG, etc. dynamisch bei Aufruf des Sample-VIs zu erstellen,

Das Erstellen eines Cluster, also eines Types, zur Laufzeit ist normalerweise überhaupt nicht notwendig. Was man braucht, weis man zur Programmierzeit. Was aber notwendig ist, ist das initialisieren der Instanzen des Typs.

Zitat:Das AO-Signal wird in einem Regelkreis (RK) berechnet. Es gibt verschiedene VIs mit unterschiedlichen RK, je nach Betriebszustand des Generators. Der RK entnimmt aus dem FGV die neusten Messwerte und berechnet das neue Analoge Ausgangssignal, speichert dieses im FGV ab und sendet es per DAQmx an meine Maschine.

Sehe ich jetzt kein Problem ...

Zitat:Speicherung der Messwerte
Dies kann ich einfach im Anzeige-VI erledigen, da die Zykluszeit hier entsprechend hoch ist, und ich hier sowieso sämtliche Messdaten aus der Queue auslese, um diese anzuzeigen. Richtig?

Ja.

(18.11.2015 11:36 )m.werle schrieb:  Strikttypisierte Referencen kriege ich gerade nicht hin. Bin so vorgegangen:

Probiers mal so:

• Öffne das VI mit den globalen Variablen.
• Öffne das VI Anzeige_Test.
• Kopiere die Referenz "Messwerte" (oder auch "Messwerte inkl. SCR") aus Anzeige_Test per Drag&Drop nach Test_Global.
• In Test_Global gibt es jetzt eine neue globale Variable namens "SVDiagr Referenz".
• Kopiere den Namen der Variablen "Ref Measure_Chart_ink_SCR" mit Ctrl-C, lösche die Variable "Ref Measure_Chart_ink_SCR", benenne die Variable "SVDiagr Referenz" mittels Ctrl-V in "Ref Measure_Chart_ink_SCR" um.
  

Jetzt sollte in Anzeige_Test der rote Punkt bei "Ref Measure_Chart_ink_SCR" verschwunden sein. Am Propertynode in DAQ_unfertig titt jetzt ein Fehler auf, weil der Eingang Wert jetzt ein Waveform ist und kein Variant mehr.

Funktioniert so bei LV2014, bei LV2010 wird es wohl auch so sein.

Nachtrag:
Da ist jetzt zwar keine Typdefinition herausgekommen, aber dafür gibt es jetzt typ-identische Variablen.

Okay, dankeschön!
Die Typidentischen Referenzen funktionieren nach der Methode, die du genannt hast. (Roter Punkt ist weg und Value ist nicht mehr Variable)

(18.11.2015 17:02 )IchSelbst schrieb:  

Zitat:Von welcher Zyklusdauer redest du hier?

Viele meiner Programm sind "Dauerlaufprogramme". Da wird ein Prüfling ständig mit der selben Betätigung beaufschlagt. Eine Betätigung (was immer das auch ist) dauert z.B. 30 Sekunden. Von diesen Betätigungen werden dann z.B. 2 Mio gemacht. Die Zyklusdauer ist dann 30 Sekunden. Zu Beginn eines Zyklusses werden diverse Daten im Sample-VI resettet (z.B. Länge Array). Am Ende des Zyklusses wird das Array aus dem Melder gelesen ...

Zitat:Ich habe einmal eine Updaterate meiner DAQmx, wie viele Datenpakete mit jeweils so und so vielen Samples ich erhalte. Danach richtet sich die Zyklusdauer der Whileschleife im Sample-VI.

Eigentlich gefällt mir das nicht. Uneigentlich kannst du das aber auch so machen.
Ich selbst bevorzuge eine konstante, also Abtastraten-unabhängige Schleifendauer, z.B. 50ms. Innerhalb dieser Zeit werden sich einige Samples ansammeln. Wie viele es sind, ist dem Algorithmus eigentlich egal - dafür ist er ja ein Anzahl-unabhängiger Algorith

Mhhh...

Ich soll sozusagen eine recht lange Zyklusdauer entwerfen, in welcher mein Sample-VI in regelmäßigen Abständen diverse Daten resettet werden.

Läuft das dann folgendermaßen ab?
Ich hab eine äußere Whileschleife mit dieser fixen relativ langen Zyklusdauer in welcher die Initialisierung verschiedener Daten vorgenommen wird und eine innere Whileschleife in welcher die Samples entnommen werden sowie die Zeit seit dem letzten mal Resetten gemessen wird. Ein Reset ist dann das Beenden der inneren Schleife um somit diverse Daten zu Reinitialisieren.

Mein TestAnzeige-VI flusht in regelmäßigen Abständen (Anzeigezyklusdauer) die Queue in welcher die (im Sample-VI um zwei weitere Signale erweiterten) Messwerte gespeichert sind. Die Queue Referenz sowie diverse Parameter habe ich in einer FGV gespeichert.

Im TestAnzeige-VI lassen sich die Zykluszeit der Anzeige sowie die Updaterate und die Samplerate (Samples/Update) für das Sample-VI erstellen. Bei Start des TestAnzeige-VI öffnet das Sample-VI.

Das Sample-VI im aktuellen Zustand hat zwei Indicator, einmal für die Anzahl der Iterationen der Whileschleife und einmal für die Zeit (in ms) zwischen zwei Iterationen. Diese variiert sehr stark und hängt sehr davon ab, wie viele Samples/Update ich erfasse. Woran liegt das? Ich blick da noch nicht ganz durch. Meine eingestellte Updaterate wird ja gar nicht eingehalten... mh.

Zitat:

Zitat:Die berechneten AVG/Peak/RMS-Werte werden in einer Eventstructure bei einem Valuechange mit ihrem Grenzwert verglichen, um zu testen, ob ein Alarm ausgelsöt werden muss und die Maschine gestoppt.

Wie, was, wo: Eventstruktur? Im Sample-VI befindet sich keine Eventstruktur!
Ansonsten klingt das an sich ja richtig - naja, ist es ja auch. Aber:
Woher weis die Eventstructur, dass ein ValueChange eingetreten ist? Den ValueChange würde ich im Sample-VI feststellen und dann, z.B. mit einer Melder oder einer Queue oder im Sample-VI selbst speziell zu dem Zeitpunkt, an dem der Notfall eingetreten ist, reagieren.

Genau, die Evenstructure wollte ich ins Sample-VI packen. Die Reaktion erfolgt direkt in dieser Eventstructure. Ist allerdings noch nicht programmiert. Hier kommen auch noch weitere Prüfalgorithmen hinein. Mein SampleVI soll nicht nur 3 AI-Signale sondern auch 8 Digitale DI-Signale erfassen. Für ein paar dieser Daten wird es auch verschiedene Prüfalgorithmen geben.

Die Prüfalgorithmen mag ich möglichst schnell nach der Datenerfassung abwickeln. Das Anzeige-VI hat eine zu lange Zyklusdauer, deshalb dachte ich wäre es sinnvoll alle Prüfalgorithmen direkt ins Sample-VI zu packen.

---

Nachtrag:

Weiß nicht genau, ob Test-Global.vi noch nötig ist, wollt alles wichtige ins FGV packen, bin noch nicht ganz fertig. Und inwiefern diese Typedefinitionen (Control_blabla.vi) nötig sind.

Bin mal weitermachen.

(23.11.2015 10:38 )m.werle schrieb:  Ich soll sozusagen eine recht lange Zyklusdauer entwerfen, in welcher mein Sample-VI in regelmäßigen Abständen diverse Daten resettet werden.

Das sollst du machen für den Fall, dass deine Applikation derart ist, dass ein Zyklus oft hintereinander gemacht wird. Voraussetzung wäre aber, dass der Zyklus einen dreiteiligen Aufbau hat: Prüfling steht in Grundstellung, Prüfling wird beaufschlagt, Prüfling geht wieder nach Grundstellung.
Wenn du aber einen Ablauf hast, der z.B. einen Motor (theoretisch) unendlich lang drehen lassen soll, dann ist dieses Verfahren an sich ungeeignet. Das Ungeeignete besteht darin, dass bei einem zyklischen Algorithmus die Daten nur einmal, nämlich an Anfang resettet werden und die eigentliche Betätigung, also das Sammeln von Daten, eine überschaubare Zeit dauert und damit einen überschaubaren Speicherbereich belegt. Bei unendlich lang musst du zwar auch am Anfang die Daten resetten - allerdings kannst du für die Dauer von unendlich keinen Speicherbereich zur Verfügung stellen.

Zitat:Läuft das dann folgendermaßen ab?
Ich hab eine äußere Whileschleife mit dieser fixen relativ langen Zyklusdauer in welcher die Initialisierung verschiedener Daten vorgenommen wird und eine innere Whileschleife in welcher die Samples entnommen werden sowie die Zeit seit dem letzten mal Resetten gemessen wird. Ein Reset ist dann das Beenden der inneren Schleife um somit diverse Daten zu Reinitialisieren.

Im Prinzip ja. Weis ich denn überhaupt schon, ob du eher eine "zyklischen Beaufschlagung" deines Prüflings hast oder ob du eine unendlich lange Beaufschlagung machen willst?

Zitat:Mein TestAnzeige-VI flusht in regelmäßigen Abständen (Anzeigezyklusdauer) die Queue in welcher die (im Sample-VI um zwei weitere Signale erweiterten) Messwerte gespeichert sind. Die Queue Referenz sowie diverse Parameter habe ich in einer FGV gespeichert.
Im TestAnzeige-VI lassen sich die Zykluszeit der Anzeige sowie die Updaterate und die Samplerate (Samples/Update) für das Sample-VI erstellen. Bei Start des TestAnzeige-VI öffnet das Sample-VI.

Prinzipiell kannst du das so machen.

Zitat:Das Sample-VI im aktuellen Zustand hat zwei Indicator, einmal für die Anzahl der Iterationen der Whileschleife und einmal für die Zeit (in ms) zwischen zwei Iterationen. Diese variiert sehr stark und hängt sehr davon ab, wie viele Samples/Update ich erfasse. Woran liegt das? Ich blick da noch nicht ganz durch. Meine eingestellte Updaterate wird ja gar nicht eingehalten

Auch ich wäre der Meinung, dass alles konstant sein müsste. Waran das liegt, muss ich erst ankucken.
Unschön ist, dass du zwei Parameter hast, die das selbe bewirken (so hab ich das zumindest verstanden): "Zeit zwischen zwei Iterationen" und "Samples/Update". Ichhabe noch in Erinnerung, dass die immer eine feste Anzahl ("Samples/Update) Maus dem DAQmx herausliest. Ich würde immer herauslesen, was vorhanden ist. Spätestens dann muss die Zyklusdauer der inneren Whileschleife konstant sein.

Zitat:Genau, die Evenstructure wollte ich ins Sample-VI packen.

Hab ich selbst noch nie gemacht, würde ich wohl auch nie tun ...

Zitat:Die Prüfalgorithmen mag ich möglichst schnell nach der Datenerfassung abwickeln. Das Anzeige-VI hat eine zu lange Zyklusdauer, deshalb dachte ich wäre es sinnvoll alle Prüfalgorithmen direkt ins Sample-VI zu packen.

Genauso mache ich das auch.


Neben dem zugegebenermaßen sehr wichtigen Prinzip "THINK DATAFLOW" kannst du ohne weiteres aber auch modular und objekt-orientiert denken. Für deinen Fall würde ich folgendes überlegen:
Ich nehme ein VI ("Sample-VI"), das selbstständig, also ohne jedwede Einbindung in einen Datenfluss, im Hintergrund läuft. Gesteuert wird das VI durch eine Steuer-Queue. Dieses VI ist dann ein selbstständiges Modul (also ein Objekt). Was dieses Modul machen soll, bekommt es über die Queue gesagt: Daten initialisieren, in den Dauerlauf-Case gehen und die geforderte Arbeit machen, in den Standby-Case gehen und lediglich aktuelle Messwerte erfassten usw. Im übrigen haben "Hintergrund-VIs" keine aktives Frontpanel. Grundaufbau des Moduls: Eine Whileschleife mit Schieberegistern, in der sich eine per Enumerator gesteuerte Case-Struktur sowie eine in Reihe geschaltete Abfrage der Steuerqueue befindet.
Gesteuert wird dieses Hintergrund-VI durch ein VI, das bereits die User-Schnittstelle enthalten kann: Also ein Frontpanel mit Eingabe- und Anzeigeelementen. Wichtig in diesem VI ist eine eigenständige Whileschleife, die z.B. die Daten aus dem Sample-VI liest und das Sample-VI steuert.

(23.11.2015 12:11 )IchSelbst schrieb:  

(23.11.2015 10:38 )m.werle schrieb:  Ich soll sozusagen eine recht lange Zyklusdauer entwerfen, in welcher mein Sample-VI in regelmäßigen Abständen diverse Daten resettet werden.

Das sollst du machen für den Fall, dass deine Applikation derart ist, dass ein Zyklus oft hintereinander gemacht wird. Voraussetzung wäre aber, dass der Zyklus einen dreiteiligen Aufbau hat: Prüfling steht in Grundstellung, Prüfling wird beaufschlagt, Prüfling geht wieder nach Grundstellung.
Wenn du aber einen Ablauf hast, der z.B. einen Motor (theoretisch) unendlich lang drehen lassen soll, dann ist dieses Verfahren an sich ungeeignet. Das Ungeeignete besteht darin, dass bei einem zyklischen Algorithmus die Daten nur einmal, nämlich an Anfang resettet werden und die eigentliche Betätigung, also das Sammeln von Daten, eine überschaubare Zeit dauert und damit einen überschaubaren Speicherbereich belegt. Bei unendlich lang musst du zwar auch am Anfang die Daten resetten - allerdings kannst du für die Dauer von unendlich keinen Speicherbereich zur Verfügung stellen.

Gesteuert wird ein DC Generator mit variabler Ausgangsspannung durch Veränderung des Phasenanschnittswinkel zweier Thyristoren.
Die von mir zu programmierende Steuerung soll ermöglichen die Ausgangsspannung durch Ansteuern der Thyristoren (AO-Signal) zu regeln.
Im Betrieb wird eine Ausgangsspannung für einen bestimmten Zeitraum konstant gehalten oder die Ausgangsspannung wird rampenförmig auf ein anderes Spannungslevel gefahren. (Oder auch mal Umgepolt)

Im Dauerbetrieb wird der Generator nie laufen, aber die Prüfungen für die er eingesetzt wird sind sehr unterschiedlich lange. Manche auch tage- oder wochenlang. Zwischendurch wird er aber normalerweise nie in den Ausgangszustand zurück versetzt.

Es werden sich aber keine unendlichen Datenmengen anhäufen. Die Historylänge des Wafeformchart im Anzeige-VI ist begrenzt. Die Queue über welche die Messwerte ans Anzeige-VI übermittelt werden wird immer wieder geflusht. Und für den Datalog-Modus ist geplant eine Speicherrate einzustellen, wie viele der gesammelten Samples denn gespeichert werden müssen. (Die Menge an Messsamples die erfasst werden ist möglichst groß, damit die Prüfalgorithmen möglichst schnell testen können, ob alles im Lot ist. Die hohe Auflösung ist für den User bei der späteren Betrachtung des Spannungsverlaufs eventuell unnötig genau.)

-> Unzyklische, unendlich lange Beaufschlagung

Zitat:

Zitat:Das Sample-VI im aktuellen Zustand hat zwei Indicator, einmal für die Anzahl der Iterationen der Whileschleife und einmal für die Zeit (in ms) zwischen zwei Iterationen. Diese variiert sehr stark und hängt sehr davon ab, wie viele Samples/Update ich erfasse. Woran liegt das? Ich blick da noch nicht ganz durch. Meine eingestellte Updaterate wird ja gar nicht eingehalten

Auch ich wäre der Meinung, dass alles konstant sein müsste. Waran das liegt, muss ich erst ankucken.
Unschön ist, dass du zwei Parameter hast, die das selbe bewirken (so hab ich das zumindest verstanden): "Zeit zwischen zwei Iterationen" und "Samples/Update". Ichhabe noch in Erinnerung, dass die immer eine feste Anzahl ("Samples/Update) Maus dem DAQmx herausliest. Ich würde immer herauslesen, was vorhanden ist. Spätestens dann muss die Zyklusdauer der inneren Whileschleife konstant sein.

Äh, stop. Das eine ist nur ein Indicator, kein Parameter um etwas einzustellen. Das war nur, damit ich beim Debuggen direkt die Zeitdauer zwischen zwei Iterationen ablesen kann, um zu Überprüfen, ob diese mit meiner eingestellten Updaterate übereinstimmt.
Die Whileschleife hat übrigens auch keinen Timer, ich glaube das Timing wird lediglich von dem DAQmx-Read-VI bestimmt.

Hier mal kurz etwas Grundsätzliches zu den DAQmx-VIs und MAX (Measurement and Automation Exporer):
In MAX habe ich ein simuliertes AI-Erfassungsgerät konfiguriert. Dort gebe ich an, wie schnell das simulierte DAQ-Gerät Datenerfasst und in seinen Buffer speichert.
Im Blockpanel meines Sample-VIs bestimme ich über die Eingänge des DAQmx-Read-VIs wie schnell (Updaterate) und wie viel Samples/Update (Samplerate) ich auslese. Richtig?

Aufgrund des unzyklischen Betriebes, habe ich weiterhin nur eine Whileschleife im SampleVI und keine innere+äußere.

Zitat:

Zitat:Genau, die Evenstructure wollte ich ins Sample-VI packen.

Hab ich selbst noch nie gemacht, würde ich wohl auch nie tun ...

Zitat:Die Prüfalgorithmen mag ich möglichst schnell nach der Datenerfassung abwickeln. Das Anzeige-VI hat eine zu lange Zyklusdauer, deshalb dachte ich wäre es sinnvoll alle Prüfalgorithmen direkt ins Sample-VI zu packen.

Genauso mache ich das auch.

Du würdest die Prüfalgorithmen ebenfalls ins Sample-VI packen, aber die Eventstructur, in welcher ich die Reaktion auf einen anschlagenden Prüfalgorithmus hineinschreiben möchte, in ein anderes VI auslagern? (z.B. über Melder oder Queue die Info: Alarm XY ausgelöst)

Zitat:Neben dem zugegebenermaßen sehr wichtigen Prinzip "THINK DATAFLOW" kannst du ohne weiteres aber auch modular und objekt-orientiert denken. Für deinen Fall würde ich folgendes überlegen:
Ich nehme ein VI ("Sample-VI"), das selbstständig, also ohne jedwede Einbindung in einen Datenfluss, im Hintergrund läuft. Gesteuert wird das VI durch eine Steuer-Queue. Dieses VI ist dann ein selbstständiges Modul (also ein Objekt). Was dieses Modul machen soll, bekommt es über die Queue gesagt: Daten initialisieren, in den Dauerlauf-Case gehen und die geforderte Arbeit machen, in den Standby-Case gehen und lediglich aktuelle Messwerte erfassten usw. Im übrigen haben "Hintergrund-VIs" keine aktives Frontpanel. Grundaufbau des Moduls: Eine Whileschleife mit Schieberegistern, in der sich eine per Enumerator gesteuerte Case-Struktur sowie eine in Reihe geschaltete Abfrage der Steuerqueue befindet.
Gesteuert wird dieses Hintergrund-VI durch ein VI, das bereits die User-Schnittstelle enthalten kann: Also ein Frontpanel mit Eingabe- und Anzeigeelementen. Wichtig in diesem VI ist eine eigenständige Whileschleife, die z.B. die Daten aus dem Sample-VI liest und das Sample-VI steuert.

Mein Sample-VI soll nur einmal eingestellt werden (Updaterate + Samplerate). Dann soll die Datenerfassung einfach konstant im Hintergrund laufen.

Die Parameter zum Initialisieren des Sample-VI sind alle in der FGV gespeichert. Stellt der User während der Programmlaufzeit im Menü die Einstellungen um, so muss er das Sample-VI Neustarten, damit diese wirksam werden.