LabVIEWForum.de

Hallo zusammen

Ich habe eine kundenspezifische .NET-DLL, die mir per Event Daten zukommen lässt - es klappt (von LabVIEW aus gesehen) alles gut.

Zu meiner vollen Zufriedenheit fehlt aber folgende Sache:

Die Entwicklungsumgebung ist aktiv. Das Anwenderprogramm wird gestartet und die Verbindung zur .NET-DLL hergestellt. Dann werden diverse Male Daten ausgetauscht. Zuletzt wird das Anwenderprogramm beendet. Auch die .NET-Schnittstelle wird beendet. Und zwar in folgender Reihenfolge, sequenziert durch den Error-Cluster:
* Schließen des Konstruktors, der beim Erstellen des Event-Callbacks (Ereignis-Registrierung) verwendet wird.
* Aufheben der Ereignis-Registrierung.
* Schließen der VI-Referenz des VIs, das der Ereignis-Registrierungs-Knoten erzeugt hat.

Keines dieser drei Elemente erzeugt einen Fehler.

Aber:
Das Callback-VI ist noch aktiv. Was zur Folge hat, dass SubVIs und Typdefinitionen, die sich im Callback-VI befinden, in der IDE auch bei nicht laufendem Anwenderprogramm nicht änderbar sind. Ich muss immer das ganze Projekt schließen und neu öffnen. Erst dann kann ich die verwendeten SubVIs ändern. Daraus schließe ich, dass das Callback-VI noch "läuft" (wie auch immer) - obwohl ich die Referenzen (im Übrigen nach Vorlage) doch fehlerfrei beendet habe.

Ich will, wenn das Anwenderprogramm nicht mehr läuft, auch die SubVIs, die sich im Callback-VI befinden, ändern können.

Was mach ich falsch? Warum gehen diese SubVIs nicht ändern?

Die Reihenfolge des Schließens der Referenzen ist offensichtlich irrelevant. Muss ich das Callback-VI explizit "beenden" - wenn ja wie: Ich hab nichts gefunden, das funktioniert. Das Callback-VI geht auch in der IDE nicht beenden: Der rote Abbruch-Button ist ausgegraut.

Hallo DuSelbst,

Gegenfrage: Wieso läuft das Callback-VI noch?

Ich habe bisher nicht viel DotNET-Callbacks programmiert. Aber wenn, dann waren das immer VIs, die einfach die Daten vom Callback in eine Queue geschoben haben und sofort wieder beendet wurden.
Machst du das nicht so?

(19.06.2016 19:34 )GerdW schrieb: [ -> ]Gegenfrage: Wieso läuft das Callback-VI noch?

Das weis ich nicht.
Ich gehe davon aus, dass das VI noch läuft. Eben weil alle SubVIs und Typdefinitionen, die in der Hierarchie das Callback-VIs liegen, nicht änderbar sind - ebenso wie bei "normalen" SubVIs auch.

Zitat:VIs, die einfach die Daten vom Callback in eine Queue geschoben haben und sofort wieder beendet wurden. Machst du das nicht so?

Doch, genau so mach ich das auch (und so soll es auch sein). Hinweis: Das Callback-VI wird beendet, weil der komplette Code abgearbeitet wurde. Ich gehe davon aus, dass das ausreicht.

Eigentlich werden die Daten lediglich per Queue verschickt. Allerdings wird vorher noch der Index der Ereignisreferenz berechnet (es laufen mehrere ablaufinvariante VIs). Hierzu ist eine FGV erforderlich - die nicht mehr änderbar ist.

Die tatsächliche Laufzeit des Callback-VIs ist bestimmt minimal. "Laufen" wird das Programm bestimmt nur ganz kurz. Die Frage ist: gehört der Bereitschaftszustand, der notwendig ist, um den Event entgegenzunehmen, zur "Laufzeit" des Programmes oder nicht.

Kann es sein, dass dieser "Bereitschaftszustand" irgendwie mit VB-.Net zusammenhängt?

Vielleicht noch folgender Hinweis:
Es wird zwar nur eine DLL verwendet. Ich muss aber drei "Connects" machen, die jeweils eine TCP/IP-Schnittstelle bedienen, deren (zwischenverarbeitete) Response-Daten ich als Event erhalte. Demzufolge hab ich auch drei Callback-VIs, die aber als Instanz eines(1) VIs generiert werden.

(19.06.2016 19:34 )GerdW schrieb: [ -> ]Hallo DuSelbst,

Gegenfrage: Wieso läuft das Callback-VI noch?

Ich habe bisher nicht viel DotNET-Callbacks programmiert. Aber wenn, dann waren das immer VIs, die einfach die Daten vom Callback in eine Queue geschoben haben und sofort wieder beendet wurden.
Machst du das nicht so?

Um das Callback VI innerhalb von .Net ausführbar zu machen wird es in einen seperate Context (Application Instance) geladen und das hat zur Folge dass das VI reserviert ist und auch aus anderen Contexts nicht mehr modifizierbar ist. Mir ist nicht ganz genau bekannt ob und wie sich so ein VI wieder unreservieren lässt und bis jetzt hat es mich zuwenig gestört, dass ich da wirklich weiter gesucht habe.
Wenn Du je mit Actor Programmierung beginnen solltest wirst Du Dich da auch mit solchen Dingen ärgern und da ist kein .Net im Spiel.

Korrektur: Hier gibt es einen Workaround: http://www.ni.com/product-documentation/...y_Category

(20.06.2016 11:33 )rolfk schrieb: [ -> ]Um das Callback VI innerhalb von .Net ausführbar zu machen wird es in einen seperate Context (Application Instance) geladen und das hat zur Folge dass das VI reserviert ist und auch aus anderen Contexts nicht mehr modifizierbar ist. Mir ist nicht ganz genau bekannt ob und wie sich so ein VI wieder unreservieren lässt und bis jetzt hat es mich zuwenig gestört, dass ich da wirklich weiter gesucht habe.
Wenn Du je mit Actor Programmierung beginnen solltest wirst Du Dich da auch mit solchen Dingen ärgern und da ist kein .Net im Spiel.

Korrektur: Hier gibt es einen Workaround: http://www.ni.com/product-documentation/...y_Category

Hervorragend.

Danke schön, rolfk.

DANKE!

Ich habe den halben Tag nach der richtigen Beschreibung gesucht
und unter Deinem Link endlich gefunden.

Gruß
Nominas