Verbindungsprobleme cRIO

Hallo LabVIEW-Experten,

ich habe mir ein Programm zusammen gestellt das eigentlich soweit ganz gut läuft. Leider kommt es bei längeren Anwendungen über mehrere Stunden/Tage teilweise zu Verbindungsproblemen. Meist gibt LabVIEW den Error Code -63043 aus (siehe Fehlermeldung im Anhang). Leider werde ich aus den möglichen Ursachen nicht recht schlau: In dem Zeitraum, in der das Programm läuft, wird soweit ich weiß nichts am Netzwerk verändert und der Prozessor ist eigentlich auch nicht wirklich ausgelastet. Das mit dem Timeout habe ich noch nicht ausprobiert, denn ich will nicht in einer Systemdatei (nirio.ini) nicht herumspielen und dabei nicht genau wissen was ich dabei mache... außerdem müßte erst mein Admin mir den Zugriff auf die Datei freischalten Vielleicht kann jemand aus Erfahrung sprechen ob die Timeout Anpassung überhaubt etwas bringt. Was könnte ich gegen die Fehlermeldungen und das Abstürzen von meinem VI sonst noch tun?
Außerdem ist mir aufgefallen das meine cRIO nach einer der längeren Anwendungen im NI-Max auf "Nicht verbunden" war. Liegt das an dem Hacken den ich in NI-Max bei "Bei IP-Fehlern anhalten" aktiviert habe? Was hält dann noch an? Schalte nämlich über meine cRIO über einen Schütz (bei stromlos auf öffen) eine Heizung, nicht das die auf Dauer läuft...

Habe mal unten meine gesamtes Projekt mit eine paar Infos zu meinem System in einer zip-Datei angehängt.

Vielen Dank im Vorraus schon für die Antworten!

Gruß Twobobbels

Hallo Twobobbels,

du greifst doch nicht etwa von deinem Windows-Host aus direkt auf den FPGA deines cRIO9074 zu?
Sowas sollte man nicht machen…

Jedes Beispiel-Projekt, das mit LabVIEW mitgeliefert wird, zeigt folgendes:
- Es gibt ein FPGA-VI, dass auf die im cRIO verbaute Hardware zugreift
- Es gibt ein RT-VI, welches auf dem cRIO läuft. Dieses kommuniziert mit dem FPGA-VI über die bekannten Methoden.
- Es gibt ein Windows-/PC-Host-VI, welches ein UI darstellen kann. Dieses kommuniziert über Netzwerk-Schnittstellen mit dem RT-VI.

Dummerweise hast du den mittleren Punkt weggelassen - und darfst dich deshalb nicht wundern, dass Netzwerkprobleme zu Fehlverhalten führen!
Einfache Lösung: Das oben genannte Projekt-Schema einhalten!
Einfache Lösung 2: Im FPGA einen Watchdog programmieren, der das System in einen sicheren Zustand schaltet, wenn sich der Windows-Host nicht (mehr) meldet!

Zum Windows-VI:
- Viel zu viele lokale Variablen!
- Es fehlt eine vernünftige Programmstruktur!
- Ein VI, welches mit der STOP-Funktion beendet wird, ist (IMHO) grundsätzlich "schlecht". Entweder beendet man ein Executable mit EXIT (nach dem Runterfahren aller wichtigen Prozesse) - oder das Programm beendet alle Schleifen regulär über irgendwelche Stop-Bedingungen: wozu also ein hartes "STOP", bevor irgendwelche Schleifen korrekt beendet wurden?
- Wozu eine Event-Struktur mit einem TimeOut von 10ms, wenn im TimeOut NICHTS passiert?
- LabVIEW bringt ein VI zum Umrechnen von Pt100-R nach Temperatur mit, sowas muss man nicht selbst programmieren…
- Es gibt "+1" und "-1"-Funktionen…
- Es gibt Funktionen zum Berechnen von Polynomen. Deine Methode mit diversen "X^Y"-Aufrufen und CoercionDots ist hochgradig Rube-Goldberg:
   
- Wenn du beim Formatieren von Zahlen ein Komma (statt des schönen Punktes) als Dezimaltrennzeichen haben willst, musst du nur den passenden Formatcode verwenden…

Hallo Gerd,

danke für die konstruktive Kritik! Werde sicher ein mein VI dementsprechend optimieren. Zur Sache mit dem Projekt-Schema mit Windows-VI, RT-VI und FPGA-VI: Habe am Anfang das jetzige Windows-VI auf der cRIO laufen lassen, leider haben da die Eventcases nicht funktioniert. Deshalb nur das Windows-VI. Hoffe es läuft dann runder mit cRIO zwischendrin.
Hättest du mir vll noch ein Projekt mit dem 3-Ebenen-Schema? Ich kenne nur die Getting-Started-Beispiele mit FPGA-VI und RT-VI auf cRIO, ein Beispiel mit drei Ebenen kenne ich leider nicht.

Lösung 2 entfällt, ich will ja trotzdem ein Programm das nicht abstürzt und meine Aufzeichnung weiter laufen lässt

Noch eine Frage zum Hacken "Bei IP-Fehlern anhalten". Was passiert da genau?

Gruß Twobobbels

(16.12.2015 20:32 )Twobobbels schrieb:  Noch eine Frage zum Hacken "Bei IP-Fehlern anhalten". Was passiert da genau?

Die Option wird bei VxWorks cRIOs (und dazu zählt dein 9074) bei Systemstart ausgewertet. Wenn du z.B. dein cRIO auf DHCP gestellt hast, und das cRIO beim Start keinen DHCP Server findet, dann wird das System an dieser Stelle angehalten. Dumm, wenn man eigentlich ein Stand-Alone-System hat (ok, das hast du leider nicht umgesetzt..., wozu überhaupt das cRIO???), und nur wegen eines Neustarts läuft dann das System nicht. Und ein VxWorks cRIO holt sich eine DHCP-IP leider nur beim Systemstart, danach nicht mehr.
Ohne gesetzten Haken startet das cRIO normal, aber dann mit einer Link-Local IP.

Deshalb fährt man unter VxWorks am besten, wenn man dem Teil eine feste IP-Adresse verpasst.

Ob das Ganze auch bei deinem Aufbau (Windows -> Direkt Zugriff auf FPGA per TCP-IP) Probleme macht oder einen Einfluß hat, keine Ahnung, so was habe ich
noch nie umgesetzt.

Gruß, Jens

Hallo Twobobbels,

Zitat:Habe am Anfang das jetzige Windows-VI auf der cRIO laufen lassen, leider haben da die Eventcases nicht funktioniert.

Wie sollen UI-Events auf einem Gerät funktionieren, das keinen Bildschirmanschluss hat und damit überhaupt kein UI darstellen kann?

Zitat:Deshalb nur das Windows-VI. Hoffe es läuft dann runder mit cRIO zwischendrin.

Die Hoffnung stirbt zuletzt…
Das es nicht "rund" läuft, weißt du ja jetzt!

Zitat:Hättest du mir vll noch ein Projekt mit dem 3-Ebenen-Schema? Ich kenne nur die Getting-Started-Beispiele mit FPGA-VI und RT-VI auf cRIO, ein Beispiel mit drei Ebenen kenne ich leider nicht.

1. Du startest LabVIEW
2. Du drückst im GettingStartedWindow auf "Projekt erstellen".
3. Du wählst "Beispielprojekte -> CompactRIO"
4. In der Liste rechts wählst du gleich den ersten Punkt "LabVIEW FPGA Control on CompactRIO"…
Es wird ein Projekt erstellt, dass alle 3 oben genannten Targets ("Ebenen") enthält…
War das so schwer?

Die anderen Beispiel-Projekte kann man sich natürlich auch anschauen!

Hallo zusammen,

ich habe jetzt die Projektstruktur mit 3 Ebenen umgesetzt, die Steuerung auf dem RT-VI und die Benutzerschnittsstelle auf dem Host-VI, Kommunikation mit Netzwerkvariabeln. Geholfen hat es aber nicht, bei einem ersten Probelauf hat das Programm nach ca 48 h mit derselben Fehlermeldung (im ersten Beitrag hinterlegt) gestoppt. Im NI MAX war darauf die Verbindung komplett weg, musste das cRIO mit dem Reset-Knopf am Gerät neu starten um die Verbindung wiederherstellen. Habe jetzt den Hacken "Bei IP-Fehlern anhalten" wieder entfernt...

Habe jetzt mal die RPCTimeout und RPCSessionTimeout in der Windows nirio.ini erhöht, wie in der Fehlerbeschreibung in Beitrag 1 gefordert (vgl. http://digital.ni.com/public.nsf/allkb/B...3D006BEA8F). Außerdem wurde der Switch und Netzwerkkabel gewechselt. Was könnte ich sonst noch machen? Hat jemand noch eine Idee?

Gruß Twobobbels

Verstehe ich nicht so recht (ohne Einblick in deinen Sourcecode).

Du hast jetzt 3 Ebenen (Host, RT, FPGA). Wieso kann der von dir beschriebene Fehler auftreten, wenn du jetzt "brav" den FPGA nur noch vom RT aus aufrufst?

Gruß, Jens

(14.01.2016 22:26 )jg schrieb:  Verstehe ich nicht so recht (ohne Einblick in deinen Sourcecode).

Du hast jetzt 3 Ebenen (Host, RT, FPGA). Wieso kann der von dir beschriebene Fehler auftreten, wenn du jetzt "brav" den FPGA nur noch vom RT aus aufrufst?

Gruß, Jens

Hallo Jens,

darin liegt ja mein Problem, ich versteh es auch nicht . Daten vom FPGA bekommt inzwischen nur das RT-VI, das Host-VI bezieht seine Daten wiederum vom RT-VI über Netzwerkvariabeln.

Mal schauen, im Moment läuft noch ja noch die Messung mit neuer Hardware, vll lag es ja an dem... MEssung läuft inzwischen seit 44 h ohne Fehlermeldung.

Gruß Twobobbels