CAN Loopbackmode mit NI-XNET

(01.02.2016 16:43 )andrepf schrieb:  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.

Funktioniert denn der Empfänger der CAN-Botschaft, also die andere Komponente?

CAN-Botschaften müssen quittiert werden! Dumm ist halt, dass ohne Quittierung die bestehende Botschaft bis zu unendlich oft wiederholt werden kann => Keine neue Botschaft einstellbar.

Loopback geht möglicherweise auch mit einer Schnittstelle: Einfach eine Read- und eine Write-Session auf dem selben Kanal öffnen und ausführen - mit Gegenstelle.

Hallo Zusammen

(01.02.2016 17:50 )jg schrieb:  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.

Meine Minimal-VI's sind die Beispiele von NI zum Thema XNET unter [NI-XNET CAN Sessions]. Z.B. für den Loopback-Modus bei Mikrocontrollern benötige ich keine 2 CAN-Nodes. Der Loopback funktioniert doch so, dass ich eine CAN-Botschaft auf den Bus schiebe und sich jeder CAN-Node diese Nachricht ansieht. Sprich auch der Sender selbst. Je nach Filter wird die Nachricht dann verwertet oder nicht. Da es auf dem uC möglich ist, war mein Versuch das NI-System analog in Betrieb zu nehmen. Wenn du mich jetzt fragst wo dieser zweite CAN-Teilnehmer ist -> der entsteht noch. Darum der Versuch den NI-CAN standalone in Betreib zu nehmen.

(01.02.2016 18:30 )IchSelbst schrieb:  Funktioniert denn der Empfänger der CAN-Botschaft, also die andere Komponente?

CAN-Botschaften müssen quittiert werden! Dumm ist halt, dass ohne Quittierung die bestehende Botschaft bis zu unendlich oft wiederholt werden kann => Keine neue Botschaft einstellbar.

Loopback geht möglicherweise auch mit einer Schnittstelle: Einfach eine Read- und eine Write-Session auf dem selben Kanal öffnen und ausführen - mit Gegenstelle.

Okay, die Quittierung fehlt wenn -> das VI XNET-Write pollert den Bus voll -> irgendwann kommt der Timeout (das ist genau das Verhalten das sich gerade bei mir auf dem Oszi zeigt). Den Versuch mit der Read- und Write-Session auf dem selben Kanal habe ich bereits umgesetzt (siehe VI im Anhang). Aaaber es funktioniert nicht.
Wie funktioniert die Quittierung? Muss ich mich darum selbst kümmern oder übernimmt das XNet VI die Quittierung für mich?

Lange Rede kurzer Sinn: Wenn Ihr mir jetzt sagt das ein Loopback bei dem NI-CAN-Modul 9862 nicht möglich ist, dann ist das eben so ... :/

VG

(03.02.2016 13:23 )andrepf schrieb:  Der Loopback funktioniert doch so, dass ich eine CAN-Botschaft auf den Bus schiebe und sich jeder CAN-Node diese Nachricht ansieht.

Streng genommen nicht. Loopback ist eine system-interne Rückkopplung, die ohne externe Komponenten auskommt. Mir ist nicht bekannt (bzw. gerade nicht in Erinnerung), dass es beim CAN-Bus diesen internen Loopback gibt.

Zitat:Okay, die Quittierung fehlt wenn -> das VI XNET-Write pollert den Bus voll -> irgendwann kommt der Timeout (das ist genau das Verhalten das sich gerade bei mir auf dem Oszi zeigt). Den Versuch mit der Read- und Write-Session auf dem selben Kanal habe ich bereits umgesetzt (siehe VI im Anhang). Aaaber es funktioniert nicht.
Wie funktioniert die Quittierung? Muss ich mich darum selbst kümmern oder übernimmt das XNet VI die Quittierung für mich?

Guckst du Funktionsweise des CAN-Busses.

Eine CAN-Botschaft besteht aus den Bitblöcken "Header-Daten-ACK-EOF". Der Sender sendet aktiv "Header-Daten". "ACK" ist ein Timeslot, während dem der Empfänger bei akzeptiertem Empfang von "Header-Daten" den Bus auf 0 ziehen muss. Nur wenn der Sender diesen Null-Pegel erkennt, hört er auf zu senden. Ansonsten wartet er den "EOF"-Timeslot ab und sendet erneut. Du selbst kannst hier programmatisch nichts machen.

Da ein(1) Controller nicht gleichzeitig senden und empfangen kann (warum auch), quittiert niemand die CAN-Botschaft.