Remote VI - Deploy und Start mit VI Server

Hallo!

Dies einmal vorweg: Ich habe das Forum durchsucht und habe mir viele und lange und langatmige Beiträge und Lösungsvorschläge bei ni.com zu dem oben genannten Thema (Betreff) durchgelesen. Leider komme ich auf keinen grünen Zweig bei meiner Programmierung der VI Server.

Mein Setup besteht aus einem cFP-2020 mit RealTime 8.5.1, Betriebssystem Pharlab und einem PC mit Windows NT und LabView 8.5.1. Kommunikation erfolgt über TCP.

Mein Ziel ist es ein VI für den Rechner zu schreiben, das ein anderes auf dem Rechner befindliches VI auf den cFP überträgt (Remote VI) und dort startet. Dieses soll später Daten nehmen und an den Rechner übertragen, welcher die Daten auf die Festplatte schreibt. Die Datenkommunikation- und nahme ist kein Problem und funktioniert wunderbar. Allerdings muss man immer seperat beide VIs aus dem Projektbaum öffnen und auf "Start" drücken. Das würde ich gerne umgehen.

Das Problem fängt schon bei der Konfiguration der (oder des ????) VI Server(s) an. Bei welcher von beiden Komponenten (cFP und Rechner) müssen welche Haken in den Optionen gesetzt werden, wo bleiben sie weg? Es ist nicht so, dass ich grundlegend nich verstehe, was die Einträge bedeuten, nur habe ich für (alle möglichen) Kombinationen von mit Verstand oder willkürlich gesetzten Häkchen schon etliche Error 66 (Server blockiert Verbindung), Error 63 (Pufferüberlauf) und gelegentlich auch mal Error 1 ( "deploy" des cFP aus dem Programm heraus nicht möglich) und Error 7 (Datei nicht gefunden, obwohl sie probeweise schon manuell auf dem cFP hinterlegt wurde) an den Kopf geschmissen bekommen. Auf Abruf reproduzierbar waren die Fehler jedoch nicht. Jetzt bin ich frustriert und hoffe das jemand von euch Profi ist.

Ich fänd es super, wenn mir jemand anhand der Nummerierung in den Bildern in der zip Datei im Anhang die einzelnen Einträge einmal vorgeben könnte. Als Maschinenalias (oder -name) vereinbaren wir "cFP2020" und "My Computer". Wenn die IP statt dem Alias gesetzt werden muss, bitte mitangeben!!! Dann weiß ich immerhin schon mal, ob ich mich einfach zu blöd angestellt habe, oder doch was nicht richtig rund läuft.

Lokal (rechnerintern) klappt das Aufrufen und Ausführen von anderen VIs mit den VI Servern wie am Schnürrchen. Nur Netzwerkkommunikation und Labview hat für mich noch nie so hingehauen wie es von NI immer so schön einfach beschrieben wird (mal abgesehen von direkten TCP-Verbindungen, die ich bisher benutze).

Weiter Fragen: Unterstützt der cFP2020 das externe Aufrufen überhaupt, wenn nicht schon ein VI darauf läuft? Braucht man dafür ActiveX? Ist Pharlab mit ActiveX kompatibel? Stimmt ggf. die Konfiguration meines Rechners nicht? Kann ich daran was drehen bzw. rausfinden woran es hakt?

Also ich würd' mich riesig freuen, wenn sich jemand dazu bereit erklärt mir unter die Arme zu greifen.

Liebe Grüße!!!

Mit der direkten VI-Server-Funktionalität wirst du IMHO nicht ans Ziel kommen.

Im Prinzip musst du dasselbe machen wie aus deinem Projekt heraus. Das dürfte eher über die Eigenschaften und Methoden der Klasse "VI Server->Project" gehen.

Im Detail kenne ich mich da aber auch nicht aus.

Gruß, Jens

Hallo!

Vielen Dank für die Antwort! Über die VI Server Funktionen der Klasse "Project" kann ich zwar ein Deploy der Komponenten und der VIs des cFP durchführen (wahrscheinlich auch VIs hinzufügen). Aber das VI starten - wenn gerade kein anderes Programm auf dem cFP läuft - kann ich damit nicht. Was inzwischen aber funktioniert ist, dass ich das VI kontrollieren kann sobald es "in memory" ist, sprich manuell gestartet wurde und ausgeführt wird.

Der Unterschied scheint zu sein, dass allein das Hinterlegen des VIs auf dem cFP, dieses nicht automatisch in den Speicher lädt, also das eigentliche Programm nicht im Register der CPU liegt. Sehe ich das richtig? Wenn es so ist schlussfolgere ich, dass ich dem Betriebssystem (hier Pharlab) den Befehl geben müsste das Programm auszuführen.

Des Weiteren würde es bedeuten, dass das VI als ausführbare (bereits kompilierte) Datei hinterlegt werden muss?! Dies wirft aber eine grundsätzliche Frage auf, auf die ich bisher keine Antwort gefunden habe:
Kann der cFP/Pharlab tatsächlich "VIs auführen" oder kompiliert mein Rechner den Code für die ihm bekannte Hardware des cFPs und sendet dem cFP dann die executable?

Das wäre schade, denn dann könnten Anwender mit geringen LabView Kenntnissen das VI für die Datennahme nicht einfach verändern und das Programm auf dem Rechner starten, sondern müssten es immer erst eimal kompilieren, bevor die Änderungen wirksam werden...

Hat jemand eine alternative Idee zu VI-Servern, mit der es möglich wäre mit einem Programm auf meinem Rechner ein Programm auf dem cFP zu starten, ohne es vorher manuell zu kompilieren und manuell auf den cFP zu packen?

Viele Grüße!!!

Ganz schön viele Fragen...

(04.02.2013 16:26 )KeineFrageGuteFrage schrieb:  Vielen Dank für die Antwort! Über die VI Server Funktionen der Klasse "Project" kann ich zwar ein Deploy der Komponenten und der VIs des cFP durchführen (wahrscheinlich auch VIs hinzufügen). Aber das VI starten - wenn gerade kein anderes Programm auf dem cFP läuft - kann ich damit nicht. Was inzwischen aber funktioniert ist, dass ich das VI kontrollieren kann sobald es "in memory" ist, sprich manuell gestartet wurde und ausgeführt wird.

Ja, Deploy bringt die VIs nur ins RAM des Real-Time-Systems.

(04.02.2013 16:26 )KeineFrageGuteFrage schrieb:  Der Unterschied scheint zu sein, dass allein das Hinterlegen des VIs auf dem cFP, dieses nicht automatisch in den Speicher lädt, also das eigentliche Programm nicht im Register der CPU liegt. Sehe ich das richtig? Wenn es so ist schlussfolgere ich, dass ich dem Betriebssystem (hier Pharlab) den Befehl geben müsste das Programm auszuführen.

Ja genau, kannst du vergleichen mit einer Exe, wenn die auf der HDD liegt, dann "kennt" das Betriebssystem sie, aber deshalb muss sie ja noch nicht ausgeführt werden.

(04.02.2013 16:26 )KeineFrageGuteFrage schrieb:  Des Weiteren würde es bedeuten, dass das VI als ausführbare (bereits kompilierte) Datei hinterlegt werden muss?! Dies wirft aber eine grundsätzliche Frage auf, auf die ich bisher keine Antwort gefunden habe:
Kann der cFP/Pharlab tatsächlich "VIs auführen" oder kompiliert mein Rechner den Code für die ihm bekannte Hardware des cFPs und sendet dem cFP dann die executable?

Jetzt wird's etwas kompliziert mit dem Erklären.
Ein VI enthält immer auch kompilierten Code, und den auch Zielsystem-spezifisch. Daher kommt die Wartezeit beim Öffnen, wenn du z.B. ein VI, was du unter dem Zielsystem "Mein Computer" erstellt hast, dann unter dem Zielsystem "RT-Target" öffnest. Somit ist es dann auch klar, wieso du ein neues VI erst einmal speichern musst, bevor du es auf dem RT-Target ausführen kannst.
Und da auf dem RT-Target schon eine LabVIEW-Runtime-Umgebung installiert ist und läuft, kann das Target auch direkt VIs ausführen.
Bei einer rtexe ist es übrigens nicht viel anders, denn im Prinzip ist das nur ein Container-Datenformat, das alle VIs enthält, die deine Applikation benötigt - natürlich entsprechend optimiert (also mglw. FP & BD entfernt, automatisches Errorhandling deaktiviert usw.).

Folgendes habe ich übrigens gerade eben unter und einem sbRIO-Target (und somit VxWorks) probiert, es funktioniert:
   

Ob das für die ein gangbarer Weg ist, kann ich nicht einschätzen.
Das Ganze ist sehr speziell, da du auch "Leute mit wenig LV-Kenntnissen" erwähnst - und das dann wieder im Zusammenhang mit einem RT-System.

Gruß, Jens

Hallo Jens!

Vielen Dank für deine aufschlussreichen Antworten! Das waren genau die Infos, die ich haben wollte!!! Und dann klappt das mit dem VI, wie du es abgebildet hast auch noch astrein! Ich bin selig. Wunderbar. Vielen Dank!

Einzige Anmerkung für spätere Leser: Leider gibt es in LV 8.5.1 den PropertyNode "Active Project" noch nicht. Aber das lässt sich umgehen, indem man einen PropertyNode erstellt, als Klasse "Project" auswählt, sich den Array "Project.Projects[]" ausgeben lässt und in einem For-Loop nach dem Project sucht, das das aktive VI enthält (siehe Anhang).

Ich arbeite das erste Mal mit VIServern und bin von der Fülle der Funktionen erschlagen. Und das muss nicht unbedingt schlecht sein.

Liebe Grüße!!!