Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
' schrieb:Ich brauche einen ständigen Datenstrom von der Hardware.
Dieses prinzipielle Vorgehen finde ich richtig.
Zitat:Diesen möchte ich auf eine gewisse Größe puffern
Das soll also folgendes heißen: Die zur Verfügung gestellten Daten sollen z.B. die letzten 1000 Samples sein.
Zitat:und dann in einem Main.vi an andere SubVIs weiterreichen.
Das ist wohl in deinem Falle - 3 unabhängige Datenempfänger - auch sinnvoll.
Zitat:ich muss ihnen die Daten unabhängig von ihren VIs geben können.
Das gehört sich auch so. Und nicht nur, wenn es drei andere Programmierer sind.
Du könntest z.B. ein spezielles SubVI erstellen - von mir immer Klasse gemannt - das über eine Queue gesteuert wird. Dieses SubVI macht alles das, was mit der Task, also den Daten von der Hardware, gemacht werden muss: Create, Konfigurieren, Starten, Lesen, Stoppen, Schließen - etc. (Statemachine: Case-Sequenz in While-Schleife) In dem einen Case Lesen machst du das, was du jetzt auch schon machst: Mittels DaqMX-Read lesen und im Puffer speichern. Diesen Puffer stellst du nun per Melder der Allgemeinheit zur Verfügung.
Dieser Melder nun repräsentiert deinen Datenpuffer. Jeder kann den nun lesen und hat dann den aktuellen Puffer respektive die aktuellen Daten. D.h. du brauchst eigentlich, um für die 3 anderen SubVIs die Daten zur verfügung zu stellen, gar kein eigenes "Main.VI". Alleine schon das Schreiben der Daten in den Melder innerhalb der Klasse bewirkt, dass die Daten für die Allgemeinheit zur Verfügung stehen.
Was du halt brauchst, ist jemand, der die Klasse von außen steuert. Das kannst du mit dem Main.VI machen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Anzeige
19.02.2008, 20:29 (Dieser Beitrag wurde zuletzt bearbeitet: 19.02.2008 20:44 von Kobe.)
Also Queue.
Bevor ich das neu implementiere, kann ich mit einer Queue diese While-Schleife umgehen? Also kann ich irgendwie sagen "wenn etwas darin ist, dann hole es" und nicht "laufe solange und hole etwas bis ich sage stop"?
Und bekomme ich es somit in mein SubVI mit Cases rein, bei denen (wie oben in Komponente_C.vi zu sehen ist) auch Datei lesen dabei ist. Sprich, es mal aktiv, mal inaktiv sein.
//edit
Also ich komme mit einer Queue genau an die gleiche Stelle wie mit den Meldern.
Ich muss mit einer While-Schleife immer wieder abfragen und weiß damit immernoch nicht, wie ich die Daten da kontinuierlich rausbekomme.
Selbst wenn ich diese While-Schleife mit den Melder / Queue-Abfragen in das "Projekt-Main.vi" (eine komplexe GUI) bekomme, müssen dort die Daten aus der While-Schleife pro Iterationsschritt bzw pro x-ten (wenn ein neuer Peak erkannt wurde) Iterationsschritt raus.
PS: Deine Kommentare zu meinen Zitaten sind korrekt.
' schrieb:Also kann ich irgendwie sagen "wenn etwas darin ist, dann hole es"
So nebenbei: Diese Variante gibt es sowohl bei Meldern als auch bei Queues.
Zitat:Also ich komme mit einer Queue genau an die gleiche Stelle wie mit den Meldern.
Solange du dein prinzipielles Vorgehen beibehältst - ist das so.
Zitat:Ich muss mit einer While-Schleife immer wieder abfragen und weiß damit immernoch nicht, wie ich die Daten da kontinuierlich rausbekomme.
Die Daten sind doch bereits heraus. Nämlich im Melder. Und den kannst du überall abfragen.
Zitat:wenn ein neuer Peak erkannt wurde
Heißt das jetzt folgendes: Du musst in dieser deiner While-Schleife die Daten, die du mittels des Melders vom Sample-Vi bekommst, erst noch bearbeiten? Wenn dann z.B. ein Peak erkannt wird, sollen die Daten weitergegeben werden? Dann kommt hier ein weiterer Melder her!
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
19.02.2008, 22:25 (Dieser Beitrag wurde zuletzt bearbeitet: 19.02.2008 22:25 von Kobe.)
' schrieb:Solange du dein prinzipielles Vorgehen beibehältst - ist das so.
Wie soll ich es ändern? Genau da hakt es ja.
Im Prinzip ist es wie in Beitrag #5 (nochmal mit kleinen Änderungen neu hochgeladen): Meine komplette Komponente ist Main.vi und diese arbeitet als SubVI in einem Projekt. Dort werden die Daten kontinuierlich (bzw. sobald ein Peak erkannt wurde, sollte aber gleiche Prinzip wie "kontinuierlich" sein) in einem anderen SubVI verarbeitet. Also muss ich eine Schnittstelle so erstellen, dass in GUI.vi unter Verarbeitung ständig was zu sehen ist. Dort wird im eigentlichen Projekt auch wirklich das Signal noch verarbeitet.
' schrieb:Die Daten sind doch bereits heraus. Nämlich im Melder. Und den kannst du überall abfragen.
Die sind in der While-Schleife verfügbar, aber nicht in dem umgebenden Programm.
' schrieb:Heißt das jetzt folgendes: Du musst in dieser deiner While-Schleife die Daten, die du mittels des Melders vom Sample-Vi bekommst, erst noch bearbeiten? Wenn dann z.B. ein Peak erkannt wird, sollen die Daten weitergegeben werden? Dann kommt hier ein weiterer Melder her!
Damit habe ich mich bisher noch nicht genau beschäftigt, aber es wird evtl. so ablaufen. Solange jedoch mein anderes Problem nicht geklärt ist, brauch ich mich daran nicht zu setzen.
' schrieb:Wie soll ich es ändern? Genau da hakt es ja.
z.B. so wie hier im Anhang.
Zitat:Die sind in der While-Schleife verfügbar, aber nicht in dem umgebenden Programm.
So wie du es bei dir im Anhang hast, sind die Daten im umgebenen Programm vorhanden. Man muss sie nur lesen - so wie hier im Anhang.
Du kannst in MAIN.VI fünf While-Schleifen reinmachen genau so wie die eine jetzt. In allen fünf wird der Melder ausgelesen. Samit sind die Daten sowohl innerhalb als auch außerhalb vorhanden.
Zitat:Damit habe ich mich bisher noch nicht genau beschäftigt, aber es wird evtl. so ablaufen. Solange jedoch mein anderes Problem nicht geklärt ist, brauch ich mich daran nicht zu setzen.
Und wenn dem so ist, kommt ein weiterer Melder her. Du kannst auch jetzt einen weiteren Melder nehmen: Mit dem einen, den es jetzt schon gibt, ließt du die Daten aus Buffer und schreibst sie direkt in den zweiten Melder, den du dann im - jetzt - übergeordnetem Programm ausliest.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
20.02.2008, 01:27 (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2008 01:30 von Kobe.)
Und genau das kann ich nicht machen. Wie gesagt ist die GUI sehr komplex, stell dir anstelle von "Verarbeitung..." ein Blockdiagramm, das nicht auf zwei 1024x768 Bildschirme passt, vor. Abgesehen davon, dass jemand anderes für die GUI verantwortlich ist, müsste ich / er eine While-Schleife um die komplette GUI ziehen, s.d. die Meldungen verfügbar sind. Die Daten, die mein SubVI schickt, werden in einem anderen SubVI gefiltert und ausgewertet und später in der GUI ausgewertet angezeigt. Ich weiß nicht, wie sich das auf die GUI auswirken würde, aber solch einen Eingriff möchte ich nicht vornehmen, da ich dann alles andere als eigenständige SubVI arbeite. Siehe mein Komponente_C.vi, so wie da die Ausgänge sind und auch schon für die Cases außer "Daten von Hardware" arbeiten, so möchte ich sie auch mit gepufferten Daten der Hardware füttern.
Vielleicht muss ich auch komplett anders ran, ich wüsste aber nicht wie.
Ich möchte, dass man Komponente_C.vi per Enum bedient und es dementsprechend Daten liefert.
Idle: genau einmal irgendwas machen
Daten von Roh/Beispieldaten: genau einmal eine Datei einlesen
Daten von Hardware: kontinuierlich bzw jedesmal wenn ein neuer Peak erkannt wurde, es gepuffert nach außen reichen
Falls "genau einmal" und "kontinuierlich" zu Problemen führt, können die "genau einmal" Daten auch kontinuierlich gefeuert werden, es soll nur perfomant bleiben.
' schrieb:stell dir anstelle von "Verarbeitung..." ein Blockdiagramm, das nicht auf zwei 1024x768 Bildschirme passt, vor.
Das ist schon mal ganz schlecht. Siehe diverse Threads, die gerade aktuell sind.
Für ein so großes BD gilt übrigens in besonderem Maße folgendes: Ein Nachteil bei LV ist, dass das Ändern bestehender Sources schwierig bis hin zu unmöglich werden kann (ohne größere Umstrukturierungen).
Zitat:Vielleicht muss ich auch komplett anders ran,
So nebenbei: Das BD in SubVIs auslagern.
Zum Herausführen von Daten aus einer While-Schleife gibt es mehrere Möglichkeiten:
Erstens:
Globale Variablen - nicht zu empfehlen respektive abzuraten. Für Lokale Variablen gilt im übrigen beinahe das selbe.
Zweitens:
Funktionales SubVI. Ein solches SubVI stellt funktional eine Globale Variable dar. Es hat einen Enum-Eingang mit (mindestens) den Werten WriteVar und ReadVar. Intern befindet sich eine While-Schleife mit Schieberegister, das die Daten enthält, sowie eine Case-Sequenz für die Enum-Werte.
Drittens:
Melder. Ein Melder kann als Globale Variable aufgefasst werden. Schreiben und Lesen gehen automatisch mittels entsprechender Elemente. Queues wären in diesem Falle ein Sonderfall von Melder. Wenn du als Daten den kompletten Satz hast, dann nimm Melder. Bei Datenänderung, also jedesmal nue die neuen Daten, dann Queue nehmen.
Viertes:
Möglicherweise würde auch über Benutzerereigniss was machbar sein. Das fällt mir aber gerade erst so ein.
Ich hab dir mal was angehängt, wie ich in meinen Programmen die "Hardwaredaten" "für die Allgemeinheit" zur Verfügung stelle. Das eine ist die Klasse, die für die Task zuständig ist und die Daten sampled und per Melder zur Verfügung stellt. Das andere SubVI dient lediglich zum Erstellen eines Datensatzes, mit dem die Klasse gesteuert wird, und dem Senden dieses Datensatzes per Queue zur Klasse.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
IchSelbst du hast mich auf den Gedanken gebracht, mich als SubVI als kleine GUI aufzurufen. Nach nochmaligen überlegen, sollte genau einmal senden ausreichen, nach einem speziellem Kriterium. Solange ich das nicht gefunden habe, läuft meine while-Schleife und der Nutzer sieht in meiner GUI alle zur Zeit gepufferten Signale. Sobald ich meine Bedingung gefunden habe, beende ich die Schleife und das SubVI wird wieder geschlossen.
