Zeitverzögerte Aktion

Also, ich habe folgendes Problem:
ich möchte ein Stream starten um Sensordaten aufzunehmen und 3sekunden später eine Spannungsänderung vornehmen.
Das Problem, ist dass wenn ich eine einfache verzögerung nehme, er den stream auch erst nach 3 sekunden startet. Wie kann ich es hinbekommen, dass die aufnahme startet, und nach 3sekunden erst, die 2te aktion folgt? dabei soll er natürlich nicht die aufnahme beenden. Daher habe ich es auch mit einer Flat Sequence nicht hinbekommen.
Anbei noch das Programm und ein screen, worum es geht, das prog. ist recht groß
   

  Kopie_von_Strem1.vi (Größe: 217,54 KB / Downloads: 260)

Da sich von den echten Profis keiner rantraut, versuch ich mal mein Glück:

Eine echte parallelität zu erzeugen gelingt dir ja nur wenn du tatsächlich zwei Processoren hast. In dem Fall müsste man sich mit Parallelprogrammierung unter LabVIEW auseinandersetzen.

Ansonsten könntest du mal versuchen mit Hilfe einer Queue eine Pseudoparalellität zu erzeugen.

Wie es genau funktioniert kann ich dir leider auch nicht sagen, bin ein absoluter LV-Anfänger, aber ich kann ja mal versuchen mein Gedankenkonstrukt zu beschreiben:

Bei Programmstart startest du einen Timer und den Datenstream

Du legst eine Queue an in der du zwei Tasks hast.
1. Daten vom Stream bekommen
2. Spannung erhöhen (aber nur wenn der Timer größer als 3 Sekunden ist)

Dann arbeitest du die Queue ab. In der Bearbeitung schiebst du wieder neue Aufgaben in die Queue (wieder Daten erfassen und Spannung erhöhen). Wenn die gesamte Sache beendet werden soll, schreibst du einfach nichts mehr in die Queue rein.

Für die Umsetzung in LabVIEW bin ich wie gesagt zu blöde, aber evtl hilft dir das ja auch so schon weiter.

ich brauch keine exakte verzögerung... es reicht also, wenn die spannung sich etwa bei 3 sek. ändert.
muss halt nur die aufzeichnung beginnen, bevor sich die spannung ändert.
aber ich werd es mal versuchen mit dem queue.

' schrieb:Du legst eine Queue an in der du zwei Tasks hast.

Wenn gleich ich weiten Teilen des TSchAC'schen Postings zustimmen kann, so will ich doch folgendes anmerken.

Queues haben keine Tasks. Queues können zwei Tasks verbinden.

Wenn ich so überlege, würden ich hier möglicherweise eine Task verwenden: Die Task samplt Daten und zählt Zeit hoch. Wenn die Zeit um ist, wird die Spannung ausgegeben. Diese eine Task wird vom MainVI mittels einer Queue gesteuert.

Beachte folgendes: Das Auslesen eines DaqMX-Read und die Verarbeitung dieser Daten erfolgt z.B. im 50ms-Raster. Das dauert ca. 2ms (). In der restlichen Zeit kann also ebendiese überprüft und ggf. die Spannung angepasst werden.

@IchSelbst:

Vielen Dank für die Richtigstellung, ich kenne Queues nur aus der theoretischen Informatik. Da ist es einfach eine Liste von Aufgaben (von mir fälschlicherweise als TASK bezeichnet) die abgearbeitet werden müssen. Dabei wird nach dem FIFO (First In, First Out) verfahren gearbeitet, sprich die Aufgabe die als erstes in die Queue geschrieben wurde, wird als erstes abgearbeitet.

Dass es unter LabVIEW ein eigenes Element TASK gibt war mir nicht bekannt (wen wunderts, bei meinen umfangreichen Kenntnissen ;-)). Aber habe ja auch gesagt, dass mein Post nur mein Gedankenkonstruk beschreibt und freu mich natürlich, dass es doch eigermaßen anwendbar ist.

Ich werde morgen mal versuchen soetwas in LabVIEW umzusetzen, wenn ichs schaff werd ich dann auch mal ein VI posten. Lernen an konkreten Aufgaben is doch immer noch das Beste und mit der Foren-Unterstützung mach ich sogar Fortschritte.

' schrieb:Da ist es einfach eine Liste von Aufgaben ...

Genau.

Zitat:Dass es unter LabVIEW ein eigenes Element TASK gibt war mir nicht bekannt

Mit Task habe ich hier weniger ein spezielles Element als vielmehr ein "informationstechnisches Konstrukt" gemeint. Wie eine Task realisiert wird (oft durch eine While-Schleife) ist für das allgemeine Verständnis nicht notwendig.

Dann sind wir uns ja einig und hoffen, dass Silverhawk geholfen wurde,..

Hum, neuer Tag neue Überlegungen!

Was spricht gegen einen Ansatz ohne Queue?
Habe mal ein kleines Beispiel erstellt. Als Datenquelle habe ich hier einen Sinus-Simulanten genommen, der könnte dann durch den gewünschten Datenstream ersetzt werden.

Programmablauf:

- aktuelle Zeit festhalten
- Signaldarstellung beginnen
wenn zuvor festgehaltene Zeit länger als 3000 ms her ist, Amplitude um 110 erhöhen, ansonsten um 0

Hier das dazugehörige VI:


  AmplitudeErh_hen.vi (Größe: 52,17 KB / Downloads: 236)

' schrieb:Was spricht gegen einen Ansatz ohne Queue?

Das VI - ich bezeichne es mal als Klasse - , welches sampled, wartet und Spannungen ausgibt, kommt selbstverständlich für sich gesehen ohne Queue aus. Im Prinzip kann man das so machen, wie du gepostet hast. Diese Klasse aber soll ja von außerhalb gesteuert werden. Außerdem läuft diese Klasse als eigenständige Task außerhalb jedweden Datenflusses. Und dafür brauchst du eben Queues und/oder Melder.

Das nächste wäre dann, dass eine solche Klasse intern eine Statemachine hat. Ohne Statemachine keine anständige Steuerung. Wenn es dich oder gar Silverhawk interessiert, kannst du mal hier reinschauen. Da hab ich eine solche Klasse gepostet. Mit einer solchen Klasse wäre das Sampled, Warten, Ausgeben etc. möglich.

' schrieb:Was spricht gegen einen Ansatz ohne Queue?

Überhaupt nichts.
Es ist übrigens so, daß, wenn die Datenaufnahme einmal angestoßen ist, die Messkarte autark arbeitet und ihre Daten über DMA in einen Puffer schiebt. CPU-Belastungen entstehen nur durch das gelegentliche Abholen der Daten und deren Verarbeitung.
Hier mal ein VI, das verzögert einen Gong anstößt, und ich erklär mal wies funktioniert:
Datenaufnahme Einstellung: Rate 1kHz kontinuierlich, 100Samples: Der DAQ Assistent blockiert immer so lange, bis wieder 100 Daten im Puffer sind, dann werden sie ausgegeben. Er wirkt wie Timer von 100ms.
Verstrichene Zeit: Es wurden 3s eingestellt. Das VI wird also alle 100 ms abgefragt, ob die Zeit verstrichen ist. Wenn ja, setzt sich das VI von selbt außer Gefecht, der Case ist dann immer true, und es sitzt im false Case. Die einmalige LH-Flanke des Siganals verstrichene Zeit löst den Gong aus - oder in Deinem Fall eben etwas anderes.

   

  Verzoegert.vi (Größe: 118,48 KB / Downloads: 238)