INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

cRIO startet selbstständig neu - Debugging



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

09.10.2018, 19:14
Beitrag #1

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
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 Blush)?


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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
10.10.2018, 08:20
Beitrag #2

Freddy Offline
LVF-Freak
****


Beiträge: 574
Registriert seit: Aug 2008

2017, NXG 2.0 BETA
1996
DE

76275
Deutschland
RE: cRIO startet selbstständig neu - Debugging
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

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
10.10.2018, 10:13 (Dieser Beitrag wurde zuletzt bearbeitet: 10.10.2018 11:47 von jg.)
Beitrag #3

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
RE: cRIO startet selbstständig neu - Debugging
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
10.10.2018, 11:21
Beitrag #4

Freddy Offline
LVF-Freak
****


Beiträge: 574
Registriert seit: Aug 2008

2017, NXG 2.0 BETA
1996
DE

76275
Deutschland
RE: cRIO startet selbstständig neu - Debugging
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

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
10.10.2018, 17:30
Beitrag #5

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
RE: cRIO startet selbstständig neu - Debugging
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
17.10.2018, 09:53 (Dieser Beitrag wurde zuletzt bearbeitet: 22.11.2018 14:24 von rolfk.)
Beitrag #6

rolfk Offline
LVF-Guru
*****


Beiträge: 2.278
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
RE: cRIO startet selbstständig neu - Debugging
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.

Rolf Kalbermatter
Test & Measurements Solutions
http://www.tm-solutions.eu
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
26.10.2018, 14:13
Beitrag #7

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
RE: cRIO startet selbstständig neu - Debugging
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Gehe zu: