CAN Loopbackmode mit NI-XNET

Hallo andrepf

Du fängst ja mit komplizierten Sachen an. Naja, da weist du wenigstens, was auf dich zukommt.

Mit Loopback hab ich noch nichts gemacht. Ich hab immer gleich einen Prüfling verwendet.

Ich will mal beschreiben, wie ich immer vorgehe.

Das ganze Gedöns mit dem Definieren der Tasks im MAX mach ich sowieso nie (auch für analoge etc. Karten nicht). Es gibt eine PSD(?)-Datei, die die CAN-Schnittstelle des Prüflings beschreibt. Diese Datei enthält alle wichtigen Informationen, die der XNET benötigt: Frame- und Channel-Beschreibungen. Diese PSD-Datei liefert der Kunde, dem der Prüfling gehört. Diese PSD-Datei erleichtert die Arbeit erheblich.

Zuerst erstelle ich mir zwei CAN-Sessions: Eine zum Lesen und eine zum Schreiben. Alleine das Erstellen dieser Sessions ist allerdings schon etwas aufwändiger. Die XNet-Schnittstelle wird per Knoten (ähnlich ActiveX) gehandhabt. Es müsste da Beispiele geben, wie das genau geht.

Mein Anwender (bzw. der Inbetriebnehmer des Programmes) muss am Frontpanel (FP) aus einer Liste alle die Channels wählen, die per Bus gelesen bzw. geschrieben werden sollen. Die Vorgabeliste wird ersteht durch Auslesen des entsprechenden XNet-Knotens. Damit sind mir nämlich die genauen Namen der Kanäle bekannt. Mit den Namen der gewählten Channels wird nun eine Session (Rd oder Wr) erstellt. Das geschieht ähnlich wie beim successiven Erstellen eine AIn-Task. Es gibt spezielle Knoten. Ganz am Schluss muss noch einmalig(!) die Baudrate eingestellt werden. Damit sind die beiden Sessions definiert und können verwendet werden.

Jetzt gibt es zwei unabhängige, parallele Schleifen: eine, die permanent schreibt und eine, die permanent ließt. Bei mir sind sie deswegen permanent, weil der Prüfling, das so verlangt. Weil es unabhängige Schleifen sind, müssen sie per Queue gesteuert werden.

Zur Lese-Task:
Wie auch bei AIn-Tasks wird ein 2D-Array (Array of Array of Samples) gelesen. Die Samples haben die Reihenfolge, wie oben beim Definieren der Session angegeben (wie auch sonst). Eine Sache finde ich allerdings unschön: Ein Array of Samples ist immer der letzte vom Bus gelesene Datensatz - d.h.: Bricht die Übertragung am CAN-Bus ab, so wird permanent der letzte gültige Datensatz ausgegeben. Eine Meldung, dass keine Daten mehr ankommen, habe ich bisher nicht finden können.

Zur Schreib-Task:
Hier muss ich ein 2D-Array (Array of Array of Values) vorgeben. Die erste Dimension hat die Reihenfolge wie beim Erstellen der Session angegeben. Die zweite Dimension ist z.B. eine Betätigungskurve. Die Ausgabeschleife muss genau in der Geschwindigkeit laufen, wie der Prüfling die Daten haben will (z.B. alle 10ms ein Datensatz).

Diese beiden Tasks laufen asynchron, können aber selbstverständlich einen synchronisierten Start haben (das aber fällt dann nicht mehr unter die XNet-Problematik). Die Vorgänge "Lesen" und "Schreiben" befinden sich (selbstverständlich) innerhalb einer Enumerator-gesteuerten Case-Struktur, die dem Methoden/Property/Eigenschaften-System eines Objektes entspricht. Die Case-Strukturen und Queue- bzw. Melder-Managemente beider(!) Tasks befinden sich in einem(1) VI, das unabhängig, also nicht sequenziert, im Hintergrund läuft.