Registerkarte "Callbacks" im Call Library Function Node.

Hallo,
ich habe eine 32-Bit LabView Anwendung (.exe). Ab und zu muss ich diese Anwendung von einem anderen Programm aus steuern, d.h. bestimmte Buttons drücken und bestimmte Controls lesen. Das Gerät ist ein Lineartisch, nur zur Erklärung, ist also alles langsam, im einstelligen Hz Bereich.

Ausserdem arbeite ich in VS2005 in C/C++, mache also laufend DLLs.

Ich habe herausgefunden, dass ich von einer DLL heraus ein UserEvent an LabView senden kann, da ich gerne mit dem Erzeuger-Verbraucher-Pattern arbeite, passt mir das hervorragend. So kann ich also Werte an LabVIEW übergeben. Ich habe den C-SourceFile UserEvent.c und das VI UserEvent Example.vi dazu gefunden.

Das Lesen von Werte scheint komplizierter.
Georg Jaindl von NI teilte mir hierzu mit:
1.) ich solle es mit ActiveX machen
2.) ich solle mir was mit TCP/IP bauen
3.) auf SharedVariables kann man nicht aus einer DLL heraus zugreifen

Das sind die NI Vorschläge.
Ich hatte zuerst die Idee, auf SharedVariables aus meiner C/C++ DLL heraus zuzugreifen. Das geht dann wohl nicht.
ActiveX habe ich noch nicht gemacht - könnt ihr das für eine C/C++-Dll empfehlen ?
TCP/IP geht bestimmt, aber ist ja ne Sonderlösung.

Nun habe ich die Registerkarte "Callbacks" im Call Library Function Node entdeckt, kann ich da nicht LabVIEW dazu bringen, bei Aufruf des VI eine Funktion meiner DLL aufzurufen, und so Daten (aktuelle Position und Geschwindigkeit des Lineartisches) von LV an meine DLL zu übertragen ?

Sorry für die lange Abhandlung.

Werner

Diese Callbacks haben einen misleitenden Namen. Es sind eigentlich Initilisierungs- und Deinitialisierungsfunktionen die LabVIEW mit einer Contextvariable aufruft für jede Instanz einer Call Library Node. Diese Contextvariable kann dann auch als extra Parameter an die eigentlich DLL mitgegeben werden. Die Contextvariable ist einfach ein Pointer, in dem die Initfunktion einen angelegten Speicherbereich zurückgeben kann der instanzspezifische Informationen abspeichert. Dies alles hat vor allem mit Reentranz in LabVIEW zu tun, da eine Call Library Node innerhalb eines reentranten VIs halt eben auch für jede Instanz manchmal eigene lokale Informationen benötigt und deshalb eine DLL globale Variable nicht funktionieren würde. Die eigentliche Funktion erhält diese instanzspezifische Contextvariable und kann dann immer auf die eigene Informationen Bezug nehmen ohne andere Instanzen derselben Call Library Node (CLN) zu beinflussen. Das Ganze wäre auch als extra CLN Parameter implementierbar der innerhalb eines uninitialisierten Schieberegisters im VI abgespeichert wird.

Und grundsätzlich macht es nur Sinn bei besonderen DLL Funktionen die instanzspezifische Daten zwischen mehreren Aufrufen abspeichern müssen und auch dann nur wenn diese Funktion in einem reentranten VI aufgerufen werden kann.

Zu Deinem eigentlichen Problem, das ist leoder nicht ganz trivial. Es hängt sehr davon ab ob Du LabVIEW von einer anderen Applikation (Prozess) ansprechen willst oder nur innerhalb einer DLL die vom LabVIEW Prozess geladen wird. Im ersten Fall wirst Du um Interapplikationskommunikation (IAK) einfach nicht herum kommen. Im zweiten Fall kannst Du einige der Funktionen um Daten in Deiner LabVIEW app zu lesen in eine LabVIEW DLL auslagern und diese am Anfang in der App laden (indem Du eine der Funktionen mittels CLN aufrufst). Danach kannst Du diese DLL von der C DLL aus aufrufen.

Wenn Dein C Code aber innerhalb eines eigenen Prozesses läuft ist dank modernem Multitasking OS und Protected Memory Environment kein Weg der an AIK vorbeiführt. Aber auch dann könntest Du eine DLL in LabVIEW machen die mittels VI Server mit Deiner LabVIEW App kommuniziert. Ist zwar immer noch etwas Arbeit aber Du brauchst nicht ein komplettes TCP/IP Protokoll zu implementieren. Das macht der LabVIEW VI Server schon für Dich.

Danke für die Antwort.
Ich brauchte einige Zeit, da war viel info drinn.

Ich möchte in der Tat LabVIEW von einer anderen Applikation (Prozess) mit steuern.

Meine Idee hierzu war es, eine DLL zu machen, die halt sowohl von Labview, also auch von der anderen Applikation aufgerufen wird, und so eine bidierktionale Kommunikation zwischen beiden Prozessen ermöglicht.

Ich wollte dazu entweder benannte Datenabschnitte (http://msdn.microsoft.com/de-debrary/h90...0%29.aspx) oder Named Shared Memory (http://msdn.microsoft.com/en-usbrary/aa3...5%29.aspx) einsetzen.

Meinst du mit Interapplikationskommunikation (IAK) Active-X ? Darf ich deine persönliche Meinung zur Verwendung von ActiveX erfahren ? Fndest du das gut, um einer anderen Anwendung Zugriff auf ein Labview-Programm zu geben ?

Ich kenne viele deiner Postings, danke dafür, ich habe schon oft davon profitiert.

Die andere Idee, die ganze Labview Anwendung als DLL zu kompilieren kann ich noch nicht richtig beurteilen. Kann dann in dieser Labview-DLL auch das ganze Erzeuger-Verbraucher-Pattern drinn sein, und die GUI, und ich kann dann einige funktionen exportieren, die dann meine andere Anwendung aufruft ? Geht das so ?

Warum kann man eigentlich auf SharedVariables nicht aus einer C-DLL heraus zugreifen, das wäre doch elegant ?

Werner

Also Datenaustausch alleine durch sharen einer DLL zwischen zwei Applikationen geht halt nicht aber das hast Du ja scheinbar schon erkannt da Du spezifisch die Verwendung von Shared Memory oder benannten Datenabschnitten erwähnst.

IAK ist jegliche Form von Kommunikation die Daten zwischen zwei Prozessen austauschen kann. Das können Pipes sein, shared Memory, Netzwerkkommunikation oder auch ganz trivial Austausch von Daten mittels Datenbeständen (Files).

Active X selber ist nicht wirklich IAK obwohl man bei Verwendung von Acitve X auch RPC (Remote Procedure Calls) verwenden kann was dann schon IAK wäre. Active X ist in meinen Augen aber ein superschwerer Dynosaurier der zum Teil auf Technologien basiert die noch aus alten Windows 3.x OLE Zeiten stammen. Es funktioniert (meist) ist aber eine durchaus filigrane Konstruktion die das Gewicht des Superdynos nur mit viel Glück und regelmässigen Gebeten einigermassen tragen kann.

Die Idee mit der LabVIEW DLL war nicht unbedingt um die ganze Applikation als DLL zu machen. Anstelle davon dachte ich eine DLL zu machen die von Deinem Prozess geladen werden kann und die eigentliche Kommunikation mittlels VI Server Calls realisiert. VI Server macht Verbindung durch TCP/IP (wenn man bei der Open Applikation Reference eine explicite remote Adresse angibt und die LabVIEW Applikation selber kann als VI Server enabled werden. Das macht man in der LabVIEW Umgebung durch Einstellung in the Optionen und wenn man diese Werte die dadurch im LabVIEW.INI File geschrieben werden in die eigene MyAPP.INI übernimmt, dann kann die LabVIEW app ebenfalls als VI Server funktionieren.

' schrieb:Also Datenaustausch alleine durch sharen einer DLL zwischen zwei Applikationen geht halt nicht aber das hast Du ja scheinbar schon erkannt da Du spezifisch die Verwendung von Shared Memory oder benannten Datenabschnitten erwähnst.

Ja, ich wollte elegant durchblicken lassen, dass ich das erkannt habe

' schrieb:Active X selber ist nicht wirklich IAK obwohl man bei Verwendung von Acitve X auch RPC (Remote Procedure Calls) verwenden kann was dann schon IAK wäre. Active X ist in meinen Augen aber ein superschwerer Dynosaurier der zum Teil auf Technologien basiert die noch aus alten Windows 3.x OLE Zeiten stammen. Es funktioniert (meist) ist aber eine durchaus filigrane Konstruktion die das Gewicht des Superdynos nur mit viel Glück und regelmässigen Gebeten einigermassen tragen kann.

Danke für deine Einschätzung, daher liebe ich deine Postings so

' schrieb:Die Idee mit der LabVIEW DLL war nicht unbedingt um die ganze Applikation als DLL zu machen. Anstelle davon dachte ich eine DLL zu machen die von Deinem Prozess geladen werden kann und die eigentliche Kommunikation mittlels VI Server Calls realisiert.

VI Server Calls muss ich mir ansehen, danke für den Hinweis.
Momentan verfolge ich auch noch die Idee Webservices...

Werner