' schrieb:is jetz schon sehr OT, nimmt aber bezug zu den Posts darüber:

ich glaub nicht, dass se sinnvoll ist bei einem VISA Read auf einen seriellen Port eine unbegrenzte Wartezeit anzugeben, aus folgendem Grund: wenn nun keine Daten mehr reinkommen wartet das VISA Read VI unendlich lange, und das ist bestimmt länger als man das Programm drumherum laufen lassen möchte=> man kann eigentlich nur noch mit "Exit LabVIEW" einen Abrruch erzwingen und das ist nicht besonders sauber ...

Wenn ich über VISA kommuniziere hab ich eigentlich immer so Schleifendurchlaufzeiten von 100 ms, nicht länger

' schrieb:Hallo zusammen,
eg ich habe mir die library auch heruntergeladen und probeweise getestet und finde sie auf den ersten Blick
sehr interessant.
Ich werde mich bestimmt damit näher beschäftigen wenn ich Zeit und Ruhe (genau hier ist mein Problem) habe.
Es ist in meinen Augen eine tolle Sache wenn solche Ideen hier eingestellt und diskutiert werden.
Nun kann ich noch nicht viel beitragen, jedoch habe ich das "Get Notifier Status" Modul vermisst,
da ich diese Funktion auch häufig nutze.

Gruß
Ralf

PS: OSD/FGV benutze ich ebenfalls immer häufiger und kann deine Argumentation nicht nachvollziehen (Provokation?)

' schrieb:Nun, die Idee wäre, dass ein VISA Close die Resource abschliesst und das VISA Read mit unendlichem Timeout abgebrochen wird und mit einem entsprechenden Fehler zurückkehrt. Ein bischen dasselbe wie mit Queues, Notifiern etc.

Bei Queues und Co funktioniert das auch aber bei VISA leider nicht. Aber, wenn man in NI Spy nachschaut, sieht man das LabVIEW normalerweise viReadAsync(...) aufruft auch wenn VISA Read scheinbar synchron arbeitet. Der Grund ist einfach wenn man sich mit dem VISA API ein bischen abgegeben hat. Beim Gebrauch vom synchronen viRead(...) kann nur ein viRead(...) gleichzeitig aktiv sein (ob das jetzt per Applikation gilt oder System global weiss ich nicht mal sicher). Damit wären komplizierte Applikationen mit Ansprechen von mehreren Instrumenten gleichzeitig kaum zu machen. Mit viReadAsync(...) kann LabVIEW das umgehen, indem es das synchrone Warten halt selber macht und regelmässig mit viWaitOnEvent(..., VI_EVENT_ON_COMPLETION, ...) selber checken ob die angeforderten Daten schon eingetroffen sind.

Und um eine asynchrone viRead/WriteAsync(...) Operation abzubrechen kann man halt eben viTerminate(..., VI_NULL) auf die entsprechende Resource aufrufen. Das VI-NULL am Ende sagt VISA dass alle asynchronen Operationen für die entsprechende VISA Resource abgebrochen werden sollen. Beim nächsten Aufruf von viWaitOnEvent(...) durch LabVIEW sieht es dass die asynchrone Operation abgebrochen wurde und sollte mit einem entsprechenden Fehler das VISA Read beenden.

Eigentlich ist es ein Bug in LabVIEW. VISA Close sollte sicherheitshalber auch noch ein entsprechendes viTerminate(...) ausführen, allenfalls mit einem Boolean Parameter am VISA Close auschaltbar. Default sollte aber beim Abschliessen einer VISA Resource auch alle möglicherweise noch anstehenden asynchronenen Operationen automatisch auch abgebrochen werden.

Ich muss dabei erwähnen dass diese Analyse nicht 100% ist. Es könnte sein dass das Problem noch durch etwas anderes verursacht wird, und mein VI von zwei Posts höher noch nicht die Lösung ist, aber es ist meiner Meinung nach eine Unterlassung von LabVIEW um eventuelle VISA Read Operationen nicht zu beenden wenn eine VISA Resource anderswo im Programm explizit abgeschlossen wurde, und ziemlich sicher sogar wenn das implizit passiert (auto refnum cleanup).

Rolf Kalbermatter

' schrieb:Hi, ich mache gerade eine neue Version der Tasking Library. Nun wollte ich wissen, wozu du das VI Get Notifier Status nutzt?

In der neuen Version wird CmdNumber+VariantData Cluster zum Übertragen von Datenpaketen benutzt. Ansonsten bleibt es gleich. Gibt es sonstige Wünsche zum Verbessern der Library?

Gruß, eg