CAN Loopbackmode mit NI-XNET

Hallo Zusammen,

ich bin gerade bei der Inbetriebnahme meiner NI9862 CAN-Karte. Dazu hab ich die beiden Beispiel "CAN Signal Input Waveform (Session)" und "CAN Signal Output Waveform (Session)" zusammen gefügt. Ziel ist es, das die Karte etwas an sich selber schickt, was ja bei CAN-Bus möglich ist. Mein Software habe ich anbei gehängt. Zuerst schreibe ich auf den CAN-Bus, dann möchte ich diese Daten auslesen. Das bekomme ich nicht zum Laufen. Meine Fragen sind:

• Fehlermeldung: NI-XNET: (Hex 0xBFF6300A) The operation timed out. Solution: specify a timeout long enough to complete the operation, or change the operation in a way that it can get completed in less time (e.g. read less data).: Ich glaub nicht das es am timeout oder der operation liegt, aber woran kann es dann liegen?
• Wo kann ich den Identifier für eine CAN-Frame zur Laufzeit definieren bzw. die einkommende Nachricht filtern in Abhängigkeit des Identifier?
• Wo bekomme ich mit, dass der Transceiver eine neue CAN-Nachricht bekommen hat? Ähnlich wie ein Interrupt auf dem Mikrocontroller. Ich möchte zu einem späteren Zeitpunkt eine CAN-Kommunikation über eine Producer-Consumer-Architektur realisieren. Dazu benötige ich diese Funktion.
  

Vielen Dank schon einmal!

VG

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.

Hallo IchSelbst,

danke für deine ausführliche Antwort. Jedoch glaube ich daran/hoffe ich, dass es mit den XNet-Treibern einfacher gehen muss. Ich bin kein absoluter LabVIEW-Neuling und aber auch keine Vollblutprogrammierer, deswegen ist das wohl der richtige Weg.
Mit meinem Projekt bin ich einen Schritt weiter. Ich gebe eine ID + Payload in das XNET Write.vi. Bis dahin funktioniert alles sehr gut. Jetzt sehe ich mir das Signal auf dem Oszi an und sehe, dass der CAN-Bus mit einer Bitsequenz beschrieben wird (Was schon einmal gut ist). Leider verändert sich das Signal nicht, wenn ich den Payload und die ID ändere. Mache ich etwas grundlegend falsch?

VG

Da ist ja immer noch so einen MAX-Session-Refnum. Ich kann IchSelbst nur zustimmen: Davon verabschieden und mit den dbc-Files zur Definition von Frames/Signalen arbeiten!

Mein Vorschlag: Schau dir zum Einstieg die Beispiele im NI-Example Finder an und fang z.B. mit CAN Frame Output Stream.vi an:
   

Gruß, Jens

(29.01.2016 15:46 )andrepf schrieb:  deswegen ist das wohl der richtige Weg.

Der bessere Weg wäre schon der, es über die PSD-Datei-internen Channel- bzw. Frame-Namen zu machen. Das entspricht dann einer Programmierung auf einer sehr weit oberen Ebene.
Natürlich kannst du auch direkt einen Frame erstellen und den senden. Das finde ich aber nicht so schön, weil ebenen-mäßig viel tiefer. Solltest du allerdings keine PSD/DBC-Datei haben, musst du es wohl so machen.

Zitat:Ich gebe eine ID + Payload in das XNET Write.vi.

Ich kann mich grob daran entsinnen, dass das im Großen und Ganzen richtig sein müsste (früher mit ohne XNet hab ich das glaub ich auch so gemacht, kuck ich nach...)

Zitat:Leider verändert sich das Signal nicht, wenn ich den Payload und die ID ändere.

Was spricht denn der Error-Ausgang des Write-VIs?

Zitat:Mache ich etwas grundlegend falsch?

Grundlegend falsch ist es glaub ich nicht. Ich kuck mal, ob ich noch was mit dem alten Verfahren finde ...

(29.01.2016 15:46 )andrepf schrieb:  wenn ich den Payload und die ID ändere.

Das scheint aber alles ok zu sein. Die Länge des Datenarrays (payload) ist so lang, wie Payload-Length im Konfigurationsdatensatz vorgibt.

Was auch immer gut kommt, ist folgendes: Wenn du schon den MAX bemühst, kannst du doch bestimmt auch probieren, ob du im MAX auch Daten senden kannst. Es gilt: Wenns im MAX nicht geht, wird es auch in LV nicht gehen. Solange es im MAX nicht funktioniert, hast du in der MAX-Task was falsch gemacht.

Anzeige

(28.01.2016 13:54 )andrepf schrieb:  Wo kann ich den Identifier für eine CAN-Frame zur Laufzeit definieren

"Zur Laufzeit definieren" würde bedeuten, die Task selbst zu erstellen. Auf Frame-Basis so wie du hab ich das nicht mit CAN gemacht, sondern mit LIN. Als Basis für mein eigenes "Create-Tasks-VI" habe ich die Mustervorlage aus der XNET-Palette verwendet.
Zuerst muss ja die Task erzeugt werden. Beim Createn der Task werden diverse Parameter konfiguriert, z.B. auch Payload-Length pro Identifier. Später dann, beim Schreiben von Daten, gilt der Identifier als Index! Du kannst mal versuchen, die Task, die du im MAX erzeugt hast, in LV in ein VI zu verwandeln. Dann siehst du, was alles gemacht werden muss, um eine Task zu erstellen.

Zitat:bzw. die einkommende Nachricht filtern in Abhängigkeit des Identifier?

Bestimmt geht das, aber ich weis es nicht: Bisher bin ich immer davon ausgegangen, dass ich den Identifier kenne und somit eine Identifier-spezifische Read-Task habe. Sollte der XNet-Read selbst nicht identifier-unabhängig funktionieren, muss du wahrscheinlich eine Ebene tiefer gehen.

Zitat:Wo bekomme ich mit, dass der Transceiver eine neue CAN-Nachricht bekommen hat?

Vermutlich tatsächlich nicht. Ließ mal in der Hilfe: "If the session mode is Frame Input Single-Point, you must leave timeout unwired (0.0). Because this mode reads the most recent value of each frame, timeout does not apply." Das interpretiere ich so: Es wird immer der letzte empfangene Datensatz gelesen.

Hallo Jens,

(29.01.2016 16:01 )jg schrieb:  Mein Vorschlag: Schau dir zum Einstieg die Beispiele im NI-Example Finder an und fang z.B. mit CAN Frame Output Stream.vi an:

vielen Dank für den Hinweis. Das sind die Beispiele mit denen ich den CAN-Bus in Betrieb nehmen will. Wenn ich über den NI-XNET-Bus-Monitor Daten sende, sehe ich an meinem Oszi das sich der Identifier und die Übertragungsrate wie gewünscht unter dem Reiter [Transmit] verändert. Ich sehe jedoch nie etwas bei den Reitern [Monitor] - [Graph]. Nebenbei bekomme ich auch noch die Fehlermeldung: "Timeout Fehler bi der Übertragung. ..." (siehe Screenshot). Mein Aufbau ist simpel: NI9862 -> CAN/LIN-Power-Cable von NI -> CAN Breakoutbox. Dort habe ich die 120 Ohm Terminierung eingestellt und nehme auch das CANH und CANL Signal für das Oszi ab. Mir gehen die Ideen aus, woran ich noch drehen könnte.

Wenn die original Beispiele auf dem CAN laufen lassen, dann sehe ich keine Veränderung im Datenframe, obwohl der Identifier für die verschiedenen Datenframes unterschiedlich ist (z.B. CANEventFrame1 ID = x42 und CANEventFrame2 ID = x43). Ist das bei euch auch so?


Hallo IchSelbst

Im MAX Daten senden bekomme ich nicht hin. Oder meinst du den NI-XNET-Bus-Monitor?
Der Error-Ausgang ist leer ("No Error"). Wie gesagt, mir gehen die Ideen aus



VG

Ich bin jetzt einen Schritt weiter. Und zwar übernimmt mir das XNet meine Eingaben für Identifier und den Payload, aaaber nur wenn ich das VI stoppe und wieder neu auf run gehe.
Alle Änderungen zur Laufzeit des VI werden nicht auf den CAN-Bus gespielt. Das Verhalten ist bei meinem VI sowie den NI-Beispielen identisch. Jemand eine Idee?

VG

Solange wir dein VI inkl. Einstellungen nicht kennen, NEIN.

Und um nochmal zum Ausgangspunkt des Threads inkl. Titel zurück zu kommen: Für ein echten Loop-Backmodus brauchst du 2 CAN Ports. Bisher lese ich immer nur was von einem CAN-Modul, welches du verwendest.

Gruß, Jens