cRIO startet selbstständig neu - Debugging

Liebe LabVIEW-Entwickler,

bei einem cRIO-System welches höchste Verfügbarkeit haben muss (Datenlogger und permanente Datenbereitstellung) habe ich das äußerst unerwünschte Verhalten festgestellt, dass dieses regelmäßig selbstständig neustartet.
Die Häufigkeit der Neustarts schwankt zwischen ca. 5 und 15 mal täglich. Die ausgeführte LabVIEW-Anwendung ist nicht in der Lage einen Systemneustart auszulösen.
Da die Linux-System-Logfiles bei jedem Neustart gelöscht werden, finde ich aktuell keinen Ansatz zum Debuggen.

Meine Fragen:
1. Wie kann ich konfigurieren, dass die Logfiles permanent gesichert bleiben?
2. Hat jemand eine Idee bezogen auf mögliche Ursachen des oben beschriebenen Verhaltens?
3. Hat jemand einen Tipp, wie ich diesen Fehler am besten debuggen kann (Software-Tool von NI?, Linux-Tools? > ich leider kein Linux-Experte )?


WEITERE INFOS:
Programmiermodus: Real-Time CPU (seit cRIO-Generation 904x)
CPU-Last (nur RT-Applikation): unter 30%
Memory-Ausnutzung: ca. 40%
Firmware cRIO-9041: 5.6.0f0f
Betriebssystem: NI Linux Real-Time x64 4.9.47 -rt37-6.0.0f1


Vielen Dank und Gruß aus Berlin
RoK

Hallo RoK,
könnte es sein, dass Du einen Watchdog eingebaut hast und die Software es nicht immer schaft in zurück zu setzen?

WDT Thema bei NI, könnte was für Dein Thema sein.

Gruß
Freddy

Hallo Freddy,

ich nutze für die Datenerfassung den seit ca. einem Jahr bei der cRIO 904x-Serie verfügbaren Real-Time CPU Modus in Kombination mit dem nun auch auf dem Real-Time System verfügbaren DAQmx-Treiber.
Inwiefern da 'intern' ein Watchdog implementiert ist, weiß ich leider nicht. Ich selbst habe zudem keinen Watchdog eingebaut.

Bei mir schleicht sich das Gefühl ein, dass die neue Real-Time DAQmx Funktionalität hier eine Rolle spielt, ggfs. hardwarenah nicht sauber oder performant angebunden ist, sodass die Auslastungsverteilung durch den Scheduler systemseitig durcheinander kommt. Möglicherweise steht dies auch im Zusammenhang mit meinem zweiten Problem (https://www.labviewforum.de/Thread-start...ausfuehren ).

>>> Gibt es eine Möglichkeit die den reboot auslösende Komponente (Linux-Anwendung/Prozess oder LabVIEW-Routine) zu identifizieren?

Leider sind auf der NI LinuxRT Systemdistribution die Analysetools im Funktionsumfang recht stark reduziert verfügbar ('nur' Busybox als Toolbox für die Dienstprogramme verfügbar).

Danke für die flinke Antwort ...
Gruß
RoK

Hallo RoK,
ich vermute, dass Du den WDT in Deinem Programm aktivierst.
Hier ein Link, bei dem wird erklärt wie man einen WDT erzeugt.
https://forums.ni.com/t5/Example-Program...-p/3506386

Könnte sein Du hast ungewollt den WDT aktiviert.

Gruß
Freddy

Hallo Freddy,

vielen Dank für die schnelle Rückmeldung.

Zumindest nutze ich keines der RT-Watchdog-VIs. Linux-seitig läuft allerdings ein Watchdog-Dienst, welcher aber keine Komponenten der RT-Applikation überwacht.

Wenn der Watchdog in den Timeout läuft würde dieser m.E. den reboot-Befehl (shutdown -r) für das crio auslösen … ?
In diesem Fall müssten in den System-Log-Files einige Statuseintrage für das Beenden von Prozessen eingetragen werden. Allerdings kommt dort nichts an. Es sieht aus, als würde der Reset-Knopf gedrückt werden oder die Spannung wegbrechen. Diese beiden Szenarien können aber ausgeschlossen werden.

Leider bin ich nach wie vor ratlos. Kann es auf ausgeführten Code in der RT-Applikation zurückgeführt werden, wenn CPU-ast und Memory deutlich im 'grünen Bereich' bleiben?

LG RoK

Suchst Du an der richtigen Stelle? Eventuelle Crash logs werden an einer anderen Stelle geschrieben dann bei einem normalen Linux System. NI setzt diesen Path auf /var/local/natinst/log

Dort werde allerlei Dateien geschrieben oder erweitert wenn ein Crash passiert. Bei Default wird ein truncated coredump generiert der für weitere Fehlersuche selbst für NI recht nutzlos ist, aber Du kannst in /etc/init.d/lvrt-wrapper unter dem anderen ulimit Kommande eine Zeile

Code:

ulimit -c unlimited

einfügen und dann wird der gesamte benützte Speicher gedumpt, was dann natürlich ein ziemlich grosses File verursachen kann. Ein allfälliger truncated coredump solltest Du dann auch gleich löschen. Mit dem vollen coredump kann NI Support dann etwas machen.

Wenn dann ein crash mit coredum geschehen ist kannst Du das File archivieren und einen Supportrequest bei NI öffnen.

Code:

tar -cf myCoreDump.tar core_dump.\!usr\!local\!natinst\!labview\!lvrt

Falls wirklich nichts auf einen crash-reset hinweist müsstest Du doch einmal die Speisung untersuchen. Die NI RT Systeme können relativ kritisch auf Brownouts reagieren, das sind kurze Spannungsdips auf der Speiseleitung die selbst wenn sie nur wenige Millisekunden unter den Minimumwert sinken gleich einen vollen Hardwarereset ausführen. Der Umstand dass Deine Systeme mehmals täglich selbständig resetten würde eigentlich darauf weisen. Bei einem crash-reset merkt sich das System dass es gecrasht hat und beim folgenden crash wird die RT Applikation normalerweise nicht mehr gestartet, aber das kann man glaube ich in ni-rt.ini mit einem eigenen Token anpassen.

Anzeige

Hallo Rolf,

vielen Dank für die nützlichen Informationen zum truncated coredump!
Ich werde versuchen damit noch einige weitere Erkenntnisse zu gewinnen.

Zitat:... müsstest Du doch einmal die Speisung untersuchen. Die NI RT Systeme können relativ kritisch auf Brownouts reagieren ...

Das Netzteil schließe ich mittlerweile aus, da die Neustarts bei deaktivierter RT-Applikation nicht auftreten, auch wenn CPU mit der stress-Funktion starkt belastet wird.

Der Effekt des willkürlichen Neustartens tritt tatsächlich nur dann auf, wenn die RT-Applikation ausgeführt wird. Nun habe ich Teile des Programmcodes entfernt ( im Wesentlichen: [1] einige Berechnungsfunktionen der Sound & Vibration Suite, [2] MathScript-Knoten, der ein kleines Matlab-Skript ausführt) und das System führt keine Reboots mehr durch. Ich vermute nun eine ungewollte Interaktion des DAQmx-Treibers der neuen cRIO-Generation "CPU-Real Time Modus" mit verwendeten High-Level VIs / dem erstellten Code. Ist das vorstellbar? Es müssten dabei vermutlich Speicherbereiche korrumpiert werden, sodass das NI LinuxRT "die Reißleine zieht", dann würde ich aber auch Logs vom Kernel erwarten ... ? Kannst du das bestätigen oder gibt es bessere Erklärungsansätze?

Viele Grüße
RoK

Hallo Forumsleser,

ich möchte das Thema, wenn auch etwas verspätet, mit einem kurzen Fazit abschließen:

Nach einem Update auf die seit kurzem verfügbare Firmware 5.6.5f0 trat der Fehler auf einem Testsystem zunächst nicht mehr auf und tritt nun allgemein nicht mehr regelmäßig auf.

Bei einigen Versionen der Applikation rebootete das cRIO selbsständig, bei anderen nicht, obwohl lediglich zusätzlicher Code ergänzt wurde (z.B. Berechnungsfunktionen). Ein rekompilieren des identischen Programmcodes schafft dann aber Abhilfe und es ist möglich eine stabil ausführbare Applikation zu erstellen.

Leider konnte auch mit Involvierung des NI-supports kein Verständnis drüber gewonnen werden, warum dieses Verhalten sporadisch auftritt.

Grüße aus Berlin,
RoK

Vielen Dank für die Rückmeldung!