+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Module (/Forum-LabVIEW-Module)
+---- Forum: LabVIEW RealTime (/Forum-LabVIEW-RealTime)
+---- Thema: Remote Control von RT-Targets (/Thread-Remote-Control-von-RT-Targets)
Remote Control von RT-Targets - MichaDu - 26.08.2008 10:42
Hallo,
ich möchte einen Stand-Alone RT-Controller programmieren, der nachher autark arbeiten soll, aber bei Bedarf über TCP/IP parametriert werden kann oder auch um Daten auszulesen und anzuzeigen. Soviel ich weiß, gibt es 2 Möglichkeiten:
1. Erstellen eines Host-VIs, das auf dem Remote-Host läuft
2. Steuern des RT-Controllers über einen Standard-Webbrowser
Wenn die Kommunikation ausfällt, muss der RT-Controller aber in jedem Fall weiterlaufen !!
Weiß jemand, welche der beiden Methoden hierfür besser ist?
Remote Control von RT-Targets - thomas.sandrisser - 26.08.2008 18:57
Die Kommunikation generell bei RT applikationen MUSS vom core code getrennt sein.
Bei Remote FrontPanels hast du diesen Effekt automatisch und musst nichts zusaetzlich programmieren.
Bei Verwendung von anderen Technologien (TCP IP, UDP, Shared Variable (je nach Art der Verwendung)) muss der Programmierer Sorge tragen, dass das Programm auch OHNE Client (Host Application) weiter laeuft. Grundsaetzlich basierend auf das richtige handling des Error Clusters und der Timeouts
Remote Control von RT-Targets - RioRio - 30.11.2009 11:43
Hallo,
ich möchte dieses Thema nochmals aufwärmen, weil ich selber unschlüssig bin.
Also stand-alone application auf RT-target, die aber bei Bedarf über TCP parametriert werden kann (bzw. Daten werden angezeigt..).
Ich habe mal kurz zusammengefasst was ich unter den verschiedenen Möglichkeiten verstehe:
Variante Webbroser:
-Verwendung eines Web-Browsers bedeutet: der Webserver muss auf dem RT-Target laufen (also resourcenfressend), Vorteil ist aber, dass ich von jedem beliebigem Rechner aus das remote-panel über einen Browser aufrufen kann
Variante Umgebungsvariable:
Vorteil: einfache Handhabung
Nachteil: es kann zu race conditions kommen; nur von einem bestimmten PC Zugriff auf RT-Target
Variante RT-FIFO mittesl TCP/IP:
aufwändiger, aber "sicherer"..(keine race conditions); nur von einem bestimmten PC Zugriff auf RT-Target
Was meint ihr dazu??
Remote Control von RT-Targets - cb - 30.11.2009 20:18
ich entwickle eigentlich immer eine passende Host-Applikation für das RT-VI. Die Kommunikation realisiere ich über TCP/IP, meistens mit 2 Ports (Hin- und Rückkanal) und einem Protokoll das auf dem Simple TCP-Protokoll aufbaut (siehe Example-Finder).
von den anderen Techniken hab ich schon mal gehört, aber nie benutzt ... füher oder später will ich doch mal was realisieren was ab vom Standard ist und dann hätt ich den Salat. Wenn ich gleich alles selber mach weiß ich wenigstens was ich hab
Remote Control von RT-Targets - dlambert - 01.12.2009 10:55
' schrieb:Variante Umgebungsvariable:
Vorteil: einfache Handhabung
Nachteil: es kann zu race conditions kommen; nur von einem bestimmten PC Zugriff auf RT-Target
Also ich arbeite bislang ausschliesslich mit den SharedVariables und finde die Technik einfach Klasse. Den beschriebenen Nachteil (Zitat) kann ich nicht nachvollziehen. Es ist dem Entwickler überlassen wo im Netzwerk die SVE ( shared variable engine ) platziert wird und welcher Host die vom RT an die SVE gelieferten Daten interpretiert. Ein geteilter Zugriff ist auch kein Problem. Da die SVE etwas ressourcenhungrig ist, lasse ich sie allerdings nie auf dem cRIO laufen. Alle Komponenten sind als Runtimeversion installierbar, so dass keine lizenzrechtlichen Probleme auftauchen.
Hope it helps
Christian
Remote Control von RT-Targets - RioRio - 01.12.2009 14:35
Danke an euch,
mit race conditions bzgl. der shared variablen meinte ich, dass es vorkommen kann, dass auf dem RT-Target die Variable gelesen wird, während gleichzeitig im Host-VI auf dem Host-PC auf diese Variable geschrieben wird.
Die variante von id2x klingt eigentlich am simpelsten UND sichersten.
Ich werd mal sehen was am besten klappt...
Remote Control von RT-Targets - rolfk - 02.12.2009 08:45
Je nachdem wie intelligent Du die TCP/IP Kommunikation machst kann dasselbe auch da passieren. Selber verwende ich im Programm fast ausschliesslich intelligente globale Variablen, und da erübrigt sich das Problem beinahe von selbst.
Dass Du mit der Shared Variable allerdings den Effekt bekommen kannst, dass Du im Target Teil des alten Wertes und Teil des neuen Wertes liest wenn dieser gerade angepasst wird scheint mir eigentlich allenfalls vor Arrays oder Strings überhaupt eine Möglichkeit. Ich bin sicher die Shared Variablen machen sowas wie Transaction Control dass das nicht passieren kann, sofern die Updateoperation nicht in mehrere seperate Schreibzugriffe auf verschiedene Teile eines Arrays ausgeführt wird (was glaub ich bei Shared Variablen nicht mal geht).
Echte Race Conditions sind aber jederzeit möglich sobald man von mehr als einem Ort auf eine bestimmte Resource schreibend (und lesend) zugreift. Da macht das nichts aus ob das eine Shared Variable ist, oder etwas anderes. Mit einer intelligenten globalen Variable hat man dabei noch die besten Chancen um das kontrolliert und sicher zu kapseln.
(Für alle die noch nicht wissen was eine intelligente globale Variable ist: Das ist ein VI mit einer Loop mit uninitialierten Schieberegistern und darin ein Case der mit einem (Enum)Selektor verbunden wird. Jeder Case ist eine Operation auf die Daten in dem oder den Schieberegistern. Was diese Operationen jeweils tun ist ganz der Fantasie des Programmieres überlassen. Das Ziel dabei ist um soviel möglich auf Get und Set Methoden zu verzichten und die jeweiligen Get/Modify/Set Operation als atomare Operation innerhalb eines Cases zu implementieren. Durch das automatische arbitrieren von VI Aufrufen in LabVIEW, wenn dieses von mehreren Stellen angerufen wird, ist jederzeit sichergestellt, das eine solche Operation atomär, und ohne Unterbrechung durch andere Operationen auf die Daten, ausgeführt wird.)