Events auf dem RT-Controller

Hallo,

habe eine RT-Applikation, die auf einem cRIO läuft, in der ich Benutzereingaben (Buttons etc.) mit einer Eventstruktur bearbeiten möchte. Die Events werden aber nicht registriert, wenn ich Eingaben über das "Mirror-Frontpanel" oder einen Webbrowser mache. Liegt es daran, dass die Eingabegeräte nicht direkt an das Realtime-Gerät angeschlossen sind? Wenn ich die Eingaben mit einer ganz normalen Polling-Schleife mache, funktioniert es!

es gibt keine events unter RT weil es kein FrontPanel gibt. Es gibt nur user generated events.

Wennst mit einer event structure arbeitest nehme ich an, dass property nodes auch nicht weit sind:
Property nodes unter RT funktionieren nur so lange, bis das FP removed wird (ist bei einer EXE z.b. standard)

' schrieb:Wennst mit einer event structure arbeitest nehme ich an, dass property nodes auch nicht weit sind:

Danke für die Antwort!

Wundere mich auch schon, warum NI dann diese Funktionen bei einem RT-Projekt nicht aus der Funktionsliste eliminiert? Das machen die doch auch bei dem FPGA-Modul...

' schrieb:Wennst mit einer event structure arbeitest nehme ich an, dass property nodes auch nicht weit sind:
Property nodes unter RT funktionieren nur so lange, bis das FP removed wird (ist bei einer EXE z.b. standard)

A propos property node ;-)
Ich habe tatsächlich einen aus einem Tab-Container verwendet (wie die Porperty page aus MS-MFC), um die Tabs (Pages) von einem anderen Control aus zu steuern. Das funktioniert sowohl über das "Mirror-Frontpanel" als auch über den Webbrowser. Was muss ich denn hierbei beachten? Oder besser: was darf ich hier nicht verwenden, um spätere Fehler zu vermeiden? Ich will das Target nur am Anfang parametrieren...

' schrieb:Aber a propos property node ;-)
Ich habe tatsächlich einen aus einem Tab-Container verwendet (wie die Porperty page aus MS-MFC), um die Tabs (Pages) von einem anderen Control aus zu steuern. Das funktioniert sowohl über das "Mirror-Frontpanel" als auch über den Webbrowser. Was muss ich denn hierbei beachten? Oder besser: was darf ich hier nicht verwenden, um spätere Fehler zu vermeiden?

wenn du den eingebauten Web-Server ist das wiederum ein "Sonderfall", da hast du ja wieder ein "Frontpanel".

Gedacht ist das Ganze "eigentlich" so:
im RT-Teil deiner verteilten Anwendung finden keine Frontpanel Interaktionen mit dem User statt. Wenn du den RT-Teil fertig programmiert hast, kompiliert und als Startup auf den RT-Controler abgelegt hast, startet dieser einfach und führt dein VI aus. Dann hast du kein Frontpanel mehr, das ist einfach nicht da. Für die Benutzer-Interaktion schreibst du ein eigenständige Windows Applikation, die den RT-Teil - durch welche Mechanismen auch immer - steuert. Den RT-Controler hast du mehr oder weniger in eine Black-Box "verwandelt" bzw. in ein Messgerät, dass genau deinen Anforderungen entspricht. Ausser Einschalten, Ausschalten und ggf. ein Reset wird da nicht mehr interagiert ...

Das Frontpanel hast du bei den RT-VIs eigentlich nur, wenn du beim Entwickeln bist. Sobald du die Entwicklungs-Umgebung verläßt gibts die nicht mehr. Wenn du's mir nicht glaubst: schließ einfach mal einen Monitor an den RT-Controler an

Zitat:Welcome to LabVIEW RT 8.5.1 *blink blink blink*

Was gibt es zu beachten:
- verzichte einfach auf alles was mit Frontpanel zu tun hat
=> keine locals, keine property nodes

bei mir sieht z.B. das Haupt-RT-VI so aus:
   

der Stop Button und die LEDs sind auch nur zum debuggen, damit ich das Programm auf dem RT-Controler laufen lassen kann und es ggf. stoppen kann ohne, dass ich mich mit dem Client verbinden muss. Vor dem Release kommt das auch alles noch weg

Anzeige

Danke für die ausführliche Antwort!

Ich möchte mein RT-Target (übrigens ein cRIO) später als Prozessregler laufen lassen, der nur über TCP/IP von einer SPS aus gesteuert werden kann und auch Prozessdaten mit ihr austauscht.

Falls aber doch mal zwischendurch eine Änderung der Regelparameter vorgenommen werden muss, wollte ich die Möglichkeit offen lassen, einen Laptop oder PC anzuschließen und die Parameter komfortabel über einen Webbrowser ändern zu können. Dafür muss ich doch noch ein Frontpanel im RT-VI haben, oder? Die geänderten Reglerwerte speichere ich in einer Konfigurationsdatei ab, damit sie beim Neustart automatisch geladen werden.

' schrieb:- verzichte einfach auf alles was mit Frontpanel zu tun hat
=> keine locals, keine property nodes

So restriktiv ists dann auch wieder net :-)
Locals darfst verwenden weil die eine Speicherkopie sind und asynchron zum FP laufen
Invokes hingegen funktionieren unter RT auch nur eingeschraenkt (verstaendlich)

' schrieb:So restriktiv ists dann auch wieder net :-)
Locals darfst verwenden weil die eine Speicherkopie sind und asynchron zum FP laufen

naja, aber wirklich brauchen tut man se oooch nich ...

' schrieb:Falls aber doch mal zwischendurch eine Änderung der Regelparameter vorgenommen werden muss, wollte ich die Möglichkeit offen lassen, einen Laptop oder PC anzuschließen und die Parameter komfortabel über einen Webbrowser ändern zu können. Dafür muss ich doch noch ein Frontpanel im RT-VI haben, oder? Die geänderten Reglerwerte speichere ich in einer Konfigurationsdatei ab, damit sie beim Neustart automatisch geladen werden.

naja, ich mach das so:
ich speichere Konfigurations-Einstellungen in einer binären Datei auf dem cRIO. Diese Datei wird beim Start des RT-VIs gelesen und verarbeitet. Wenn man's nun einfach haben will könnte man mit dem FTP Client auf das cRIO zugreifen und diese Datei ersetzen und das RT-VI neu starten. Allerdings bin ich ja nu CLA und da macht man's natürlich kompliziert:

Die Verbindung zwischen cRIO und PC läuft über TCP und 2 Ports. Einer als "Hin-Kanal", der andere als "Rück Kanal". Für den Hin- und den Rück-Kanal gibt es jeweils ein eigenes Protokoll, das im groben aus einem Header (was kommen jetzt für Daten) und den Daten selbst besteht. Wenn ich nun irgendwelche Parameter des RT-VIs ändern will, schickt der PC Client eine Anforderung an den RT-Server "hey, schick ma die aktuelle Konfiguration". Die dafür zuständige State-Machine auf dem Server bekommt diese Anforderung und sendet die aktuelle Konfiguration per TCP an den Client.

Im Client kommt diese Nachricht an und anhand des Headers kann identifiziert werden, dass das jetzt die Konfigurations Daten sind. Daraufhin wird ein Dialog geöffnet, auf dem die entsprechenden Controls sind, die natürlich (ja, und da benutz ich z.B. locals ...) mit den "richtigen" Werten aus den Konfigurations-Daten "vor-ausgefüllt" sind. Der User kann nun diese Daten im Dialog ändern. Drückt er OK werden die Konfigurations-Daten wieder an den Server geschickt, im Header steht dann z.B. "konfiguration ändern". Die State-Machine im Server erhält den Befehl und überschreibt die vorhandenen Daten mit denen aus der TCP Nachricht und überschreibt die bestehende Konfig-Datei mit den neuen Daten ...