LabVIEWForum.de

Ich wollte mal in die Runde fragen, hat hier jemand Erfahrung mit XNET-Modulen (z.B. LIN-9866 und CAN-9862) auf den cRIOs der Baureihe 906x.

Ich habe hier nämlich gerade ein Riesenproblem damit. Zum Einsatz kommt gerade LabVIEW 2016 mit XNET 16.1. Prinzipiell funktioniert mein Programm, allerdings müssen für eine stabilen Langzeit-Lauf die CAN bzw. LIN-Gegenstellen, mit denen ich kommuniziere, vorhanden und aktiv sein. Ist dies nicht der Fall, dann stürzt irgendwann XNET-Write mit einem Buffer-Overflow ab, was dann die gesamte Scan-Engine auf dem cRIO mit ins Nirvana reißt.

Ich kann das Problem inzwischen forciert und reproduzierbar erzeugen. Im Prinzip langt es, das Bsp "LIN Frame Input Output Same Port.vi" aus dem NI Example Finder aufzurufen und das Timing aus der While Loop zu entfernen (ich weiß, ist nicht die feine englische, aber so tritt der Absturz innerhalb kürzester Zeit ein), danach das VI auf einem cRIO mit LIN-Modul ohne Gegenstelle, nur Spannungsversorgung für den Transceiver, starten und innerhalb von 1 Minute habe ich einen Buffer-Overflow, der sich durch keinerlei weitere Warnungen andeutet. Bevor einer fragt, ich habe auch schon versucht, immer wieder XNET-Flush aufzurufen, ohne Erfolg.

Das extrem Üble ist jetzt: Nach diesem XNET-Absturz habe ich z.B. auch keinen Zugriff mehr auf ebenfalls verbaute DIO-Module per Scan-Engine. Wie schon geschrieben, reißt das die Scan-Engine komplett mit runter. Auch ein Neustart des cRIO hilft nicht wirklich, da ich den XNET-Module zusätzlich die externe Versorgung des Transceivers klauen muss, damit sie wieder funktionieren.

Der NI-Alliance-Partner-Support wurde diesbezüglich von mir vorhin angeschrieben, aber vielleicht hat schon jemand ähnliche Erfahrungen gemacht und weiß eine Lösung...

Vielen Dank im Voraus

Gruß, Jens

EDIT: Viel habe ich hierzu noch nicht auf ni.com gefunden, bisher nur diesen Thread, der haargenau meinem Problem entspricht, weswegen ich mich gleich einmal drangehängt habe.

Hallo Jens,

leider habe ich keine Info zu deinem Problem.
Ich werde mir das aber in meinen Notizen vermerken - und zukünftig weiterhin mit dem"dummen" NI9853 weiterarbeiten. Für LIN kann ich die CAN-LIN-Umsetzer von Peak empfehlen...

Umsteigen auf andere Hardware ist nicht (mehr) möglich.

Eigentlich ist das System, das ich aufgebaut habe, super! Es besteht aus mehreren cRIOs (alle 906x Baureihe, aber unterschiedliche Typen). Auf allen läuft dieselbe Steuer- und Kommunikationssoftware. Zwecks Einsatz der Scan-Engine ist der Software die genaue Hardware-Konfiguration egal. Diese wird bei Start aus einer Konfigurationsdatei eingelesen. Das System kann somit bei Bedarf schnell umkonfiguriert werden. 1 weiteres LIN-Modul an einer anderen Stelle? Kein größeres Problem, einstecken, Konfiguration ändern, neu starten. Es sind an einer Stelle zu wenig Slots für eine Erweiterung? Dann wird ein 4er-Chassis cRIO durch ein 8er-Chassis ersetzt.

Überwacht und zentral gestauert wird das von einer weiteren Software, die auf einem PC läuft.

LIN als Master ist jetzt neu hinzugekommen, und da fällt das Absturz-Problem am ehesten auf. Als Master muss das cRIO die Kommunikation starten, ich muss also auf jeden Fall etwas auf den Bus schreiben, ansonsten gibt es auch keine Antwort. Ganz besonders übel wird es, wenn man die Kommunikation als Signal-In/Signal-Out Session aufbaut. Ich habe bisher keine Möglichkeit gefunden, wie ich dann mitbekomme, wenn die Kommunikation abbricht. Das VI "LIN Communication State" gibt mir hierzu keine sinnvolle Nachricht. Bleibt nur übrig, von eine Signal-Session Abstand zu nehmen und wieder auf eine Frame-Session umzusteigen, dann habe ich wenigstens einen sich ändernden Zeitstempel bei den empfangenen Nachrichten.

Probiert man das übrigens in einem cDAQ-Chassis, dann gibt's keine Probleme!!!

Gruß, Jens

Ich bin ein wenig weitergekommen. Es braucht scheinbar weitere Hardware-Voraussetzungen, damit der beschriebene Absturzfehler auftritt, in diesem Fall ein neben dem CAN oder LIN XNET Modul einen ebenfall installierten DIO 9403 Modul. Ich bin gespannt, ob der NI Support es jetzt nachstellen kann.

Gruß, Jens

Neuigkeiten:
Mein Problem konnte inzwischen vom NI Support nachgestellt werden und ist bei R&D in Austin gelandet. Mal schauen, wann es einen Bugfix gibt.

Voraussetzung ist:
- Verwendung cRIO 906x
- mit XNET-Modul(en)
- mit DIO-Modul 9403 (vielleicht auch andere?)
- Verwendung Scan-Engine zum Zugriff auf DIO- und XNET-Module.

Da nicht klar, ist, ob es bald einen Bugfix gibt, ist die zweite Empfehlung die Verwendung FPGA-Mode zum Zugriff auf das 9403-Modul. Ein erster Test ist vielversprechend, zumindest kann ich den Absturz nicht mehr so schnell erzwingen wie ohne FPGA/Hyprid-Modus. Leider verliere ich dadurch meine Variabilität und muss wohl für jede HW-Konfiguration einen eigenen FPGA-Bitfile erzeugen.

Gruß, Jens

Noch ein letzter Beitrag:

Wie schon geschrieben, Problem konnte nachgestellt werden von NI, aber nur in der Kombination XNET-Modul + 9403 in cRIO 906x, ist also seeeehr ausgefallen.

Ich bin inzwischen auf FPGA/Hybrid-Modus umgestiegen, dh das bzw. die 9403-Module spreche ich per FPGA an. Das funktioniert, keine radikalen Abstürze mehr.

Gruß, Jens