Hallo Leute,
ich bekomme immer zweimal hintereinander den "Error1" wenn ich eine Messung durchgeführt habe, nach Programmstop.
Abtastrate 20kHz bei 20 samples per channel.
Die Signaldaten über waveform werden in eine Queue geschrieben, welche diesen Fehler ausgibt.
Genauer gesagt:
"Error1 occured at Enqueue Element in *.vi
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a charracter not allowed by the OS such as ? or @.
=============================================================================================
NI-488: Command requires GPIB Controller to be Contoller-In-Charge"
leider kann ich kein *.vi oder ähnliches hochladen, da vor Ort der Datentransfer bzw. Internetzugang total beschränkt ist. Entschuldigt dafür.
Danke im voraus für eure Hilfe!
Ist der Aufbau immer noch so wie im Parallel-Thread?
http://www.labviewforum.de/attachment.php?aid=52852
(offtopic: Hier konntest du ein Bild posten).
Falls ja, du hast dir eine Race-Condition programmiert, du kannst nicht vorhersagen, in welcher Reihenfolge deine Loops beendet werden. Wenn die untere Loop zuerst beendet ist und danach die Queue zerstört wird, dann erhältst du an der Stelle "Enqueue Element" genau den von dir beschrieben Fehler 1.
vgl. folgendes Minimal-Bsp:
[
attachment=52889]
Gruß, Jens
(20.04.2015 16:07 )jg schrieb: [ -> ]Ist der Aufbau immer noch so wie im Parallel-Thread?
Er ist ähnlich. Nur dass ich nach dem Scale Baustein die Daten als Waveform belasse und danach die Daten als Waveform (statt DBL wie im Bild vom Parallel-Thread) in die Queue schreibe.
Zitat:(offtopic: Hier konntest du ein Bild posten).
Sorry, wie gesagt - Datentransfer schwierig hier.
Zitat:Falls ja, du hast dir eine Race-Condition programmiert, du kannst nicht vorhersagen, in welcher Reihenfolge deine Loops beendet werden.
Oh das ist interessant, also wäre es besser den Inhalt der unteren Schleife mit in die obere zu packen?
(20.04.2015 16:17 )Agenth schrieb: [ -> ]Zitat:Falls ja, du hast dir eine Race-Condition programmiert, du kannst nicht vorhersagen, in welcher Reihenfolge deine Loops beendet werden.
Oh das ist interessant, also wäre es besser den Inhalt der unteren Schleife mit in die obere zu packen?
Auf gar keinen Fall besser! Du willst ja gerade Datenerfassung und -verarbeitung trennen, ansonsten brauchst du erst gar nicht mit Queues zu beginnen.
Du musst dafür sorgen, dass "Release Queue" erst dann aufgerufen wird, wenn
beide Schleifen beendet sind, z.B. über ein "Error Bundle".
Oder du könntest "Error 1" als "Unschönheit" des Programm-Aufbaus programmatisch ignorieren, nach dem Motto: Wenn die Verarbeitungsschleife schon beendet ist, dann brauche ich keine Werte mehr an sie senden.
Gruß, Jens
(20.04.2015 17:00 )jg schrieb: [ -> ]Du musst dafür sorgen, dass "Release Queue" erst dann aufgerufen wird, wenn beide Schleifen beendet sind, z.B. über ein "Error Bundle".
Oder du könntest "Error 1" als "Unschönheit" des Programm-Aufbaus programmatisch ignorieren, nach dem Motto: Wenn die Verarbeitungsschleife schon beendet ist, dann brauche ich keine Werte mehr an sie senden.
Danke das war eine gute Erklärung! Werde ich mal versuchen und berichten
Anmerkung: In dem von Jens zitiertem Bild ist aber keine Race-Condition enthalten, im Gegenteil: Die falsche Reihenfolge, die zum Fehler führen muss, ist fest einprogrammiert. Dafür sorgt der Fehlerstrang.
Danke Jens, das hat geklappt!