Nachricht konnte nicht gesendet werden. Treiberfehler 11 in TransmitCANFrame "XL_ERR_QUEUE_IS_FULL"

Dieses Dokument wurde maschinell aus der englischen Version übersetzt. Bitte berücksichtigen Sie dies. Mehr lesen

Frage:

Welche Bedeutung hat Message could not be sent. Driver error 11 in TransmitCANFrame "XL_ERR_QUEUE_IS_FULL" z.B.

System CAN 1 : Message with ID = 1 could not be sent. Driver error 11 in TransmitCANFrame, "XL_ERR_QUEUE_IS_FULL" 
System 5.581000: CAN 1 : Message with ID = 1 could not be sent. Driver error 11 in TransmitCANFrame

Antwort:

Ein Vector CAN Interface (z.B. VN1630A) verwendet einen First In First Out (FIFO) Puffer für Frames, die gesendet werden sollen. Diese verbleiben im Puffer, bis sie gesendet werden oder die Schnittstelle zurückgesetzt wird (z.B. Messungsstop). Wenn Frames nicht auf dem Bus gesendet werden können, sammeln sich zusätzliche Frames, die von CANoe/CANalyzer an die Schnittstelle gesendet werden, in diesem FIFO-Puffer an. Wenn dieser Puffer überläuft, werden die nachfolgenden Frames verworfen und CANoe/CANalyzer informiert darüber.

Diese Botschaft ist deshalb kein echter Anwendungs- oder Treiberfehler, sondern stellt eine Rückmeldung für den Benutzer der Anwendung dar, dass es ein Problem auf dem physikalischen CAN-Bus geben könnte.

Ein solches Verhalten kann folgende Ursachen haben:

Der Bus ist voll mit hochprioren Botschaften und deshalb kann die CAN-Hardware nicht senden (z.B. Busauslastung bei ca. 100 %)
Sie haben ein Programm, das Botschaften sehr schnell in den Puffer schreibt, so dass die Datenrate des realen Busses überschritten wird (z. B. while-/for-Schleifen).
Es gibt ein physikalisches Problem auf dem Bus und beim Senden treten Error Frames auf, so dass die Karte nicht senden kann.

Was physikalische Probleme auf dem Bus betrifft, so ist die zugrundeliegende Busphysik nicht ganz trivial und die Analyse und Behebung wäre Aufgabe des Benutzers. Als Hilfe finden Sie unterhalb einen Leitfaden (Schritte 1 - 3) zur pragmatischen Lösung der am häufigsten auftretenden Probleme und wo Sie hilfreiche Informationen in CANoe/CANalyzer finden.

Sollten diese Schritte nicht zum Erfolg führen, finden Sie hier einen ausführlichen Anwendungshinweis, der Methoden zur Untersuchung einiger der häufigsten Probleme mit der Physical Layer von CAN beschreibt: Anwendungshinweis AN-ANI-1-115 Common High-Speed Physical Layer Problems

Leitfaden für gute Praktiken zur Behebung der Ursache dieser Botschaft:

Übersicht:

Schritt 1 - Sicherstellen, dass Software und Treiber auf dem neuesten Stand sind
Schritt 2 - Testen der Schnittstelle auf korrekte Funktion
Schritt 3 - Mögliche Abhilfemaßnahmen und Vorschläge für weitere Tests

Schritt 1 - Stellen Sie sicher, dass Software und Treiber auf dem neuesten Stand sind:

Deinstallieren Sie alle Treiber und installieren Sie sie neu, indem Sie den neuesten Aufbau von Vector Driver verwenden.
Aktualisieren Sie auf das neueste Service Pack für Ihre CANoe/CANalyzer Version

Schritt 2 - Testen Sie die Schnittstelle auf korrekte Funktion:

2.1 Schleifentest mit Loop3.exe

Führen Sie einen Loop-Test durch, um die Hardware der Schnittstelle mit unserem Testprogramm loop3.exe zu testen, wie in diesen Artikeln beschrieben

2.2 Schleifentest mit Ihrer Konfiguration

Wenn 2.1 erfolgreich war, können Sie es mit Ihrer CANoe/CANalyzer Konfiguration testen:

Bilden Sie eine Schleife zwischen zwei Hardware-Kanälen (ähnlich 2.1) des Interfaces und senden Sie CAN Frames von einem Kanal zum anderen und umgekehrt. Prüfen Sie das Fenster Trace von CANoe/CANalyzer auf die gesendeten/empfangenen Frames.

Zum Senden von Frames kann z.B. die vorhandene RBS verwendet werden, die mit einem zusätzlichen CAN Netzwerk verlängert werden kann. Oder es können Frames über CAPL, Interaktiver Generator o.ä. gesendet werden.
Wenn dieser Test erfolgreich ist, funktioniert die Vector Hard- und Software wie erwartet. In diesem Fall finden Sie unten unter Schritt 3 mögliche Abhilfemaßnahmen und Vorschläge.

Sollte das nicht funktionieren, prüfen Sie bitte die folgenden Pflichtpunkte.

2.2.1 Terminierung

Stellen Sie je nach CAN-Spezifikation sicher, dass der Bus korrekt terminiert ist (z.B. ist für CAN High-Speed ein 120 Ω Widerstand zwischen CAN_H(igh) und CAN_L(ow) an beiden Enden des CAN-Busses vorgeschrieben).

2.2.2 Pin-Belegung

Prüfen Sie, ob die richtige Pin-Belegung der Schnittstelle verwendet wird. Die verwendeten Pins für CAN_H(igh) und CAN_L(ow) des konfigurierten Kanals können Sie in der Vector Hardware Configuration für den konfigurierten Applikationskanal unter D-SUB9 Pin Assignment einsehen.

2.2.3 Einstellungen von Baudrate und Abtastpunkt

Prüfen Sie, ob beide Kanäle mit den exakt gleichen Einstellungen für Datenrate und Abtastzeitpunkt konfiguriert sind, z.B. die Einstellungen in CANoe/CANalyzer Hardware | Network Hardware | Network Hardware Configuration | Setup.

Wichtig: Die spezifischen Einstellungen für Baudrate und Sample Point sind abhängig von dem von Ihnen verwendeten Netzwerk und den Einstellungen, die von den CAN Controllern in den realen Steuergeräten Ihres Netzwerks verwendet werden. Diese Informationen sollten der Spezifikation Ihres Netzwerks entnommen werden. Bitte haben Sie Verständnis dafür, dass dieses Wissen nicht von Vector zur Verfügung gestellt werden kann.

2.2.3.1 CAN-Baudrate und Abtastpunkt

Die Einstellungen für baud rate, bus timing register 0, und bus timing register 1 müssen für beide Kanäle übereinstimmen.

2.2.3.2 CAN FD Baudrate

Die Baudrate für Arbitration phase und Data phase muss für beide Kanäle gleich sein (z.B. Arbitrierungsphase 500 kBaud, Datenphase 1000 kBaud für beide Kanäle CAN 1 und CAN 2)

2.2.3.3 CAN FD Abtastpunkt

Für beide Kanäle muss exakt der gleiche Abtastpunkt konfiguriert sein. Das bedeutet, dass nicht nur der grobe Sample Point -Prozentsatz gleich sein muss, sondern auch die spezifischen Einstellungen für BTL, TSEG1, TSEG2, Prescaler und Sync Jump Width. Sie erreichen diese Einstellungen über die Schaltfläche […] rechts neben dem Eingabefeld für den Prozentsatz.
Can : Die Messstellen können unterschiedliche Einstellungen für Arbitration phase und Data phase haben !

(Hinweis: Bedeutung der Messstellenkonfiguration in einem CAN FD Netzwerk)

Schritt 3 - Mögliche Abhilfemaßnahmen und Vorschläge für weitere Tests

Nach einem erfolgreichen Test Ihrer Vector Hard- und Software in Schritt 2 müssen Sie Ihren spezifischen Aufbau, den physikalischen Bus, das Netzwerk, die Steuergeräte, etc. analysieren. Bitte haben Sie Verständnis dafür, dass Vector im Rahmen des regulären Supports keine Analyse für Probleme liefern kann, die eine eingehende Analyse der tatsächlichen Bus-Physik unter Verwendung eines Oszilloskops etc. erfordern würden.

Dennoch finden Sie unterhalb viele mögliche Ursachen für physikalische Bus-Fehler, Abhilfemaßnahmen und Vorschläge für weitere Tests.

3.1 Allgemeine Informationen

3.1.1 Fenster Trace

Im Fenster Trace finden Sie Informationen über die Art des Error Frames (z.B. Not ACKnowledge error):

3.1.2 CAN-Statistik

Unter CAN Statistics finden Sie Informationen über die TX- und Rx-Fehleranzahl sowie den aktuellen Chip-Status:

Hinweis: Wenn deaktiviert, kann die CAN Statistics im CANoe/CANalyzer aktiviert werden. Options | Measurement | Performance | Statistics | Calculate bus statistics

3.1.3 Fenster Write

Das Fenster Write kann zusätzliche Informationen über den aktuellen Status zwischen CANoe/CANalyzer und dem Vector Interface enthalten. Z.B. können Frames nicht gesendet werden und werden verworfen.

Die verschiedenen möglichen CAN Error Frames finden Sie in der CAN-Spezifikation erklärt. Zusätzlich finden Sie diese und die Bedienung von CAN-Fehlern auch in unserem kostenlosen Vector e-learning erklärt: Einführung in CAN | Lernmodul CAN

3.2 Beispiele

3.2.1 Nicht ACKnowledge Fehler Frames im Fenster Trace

Die CAN-Spezifikation verlangt mindestens zwei teilnehmende Knoten in einem CAN-Netzwerk. Wenn kein anderer Knoten einen von der Schnittstelle gesendeten CAN Frame ACKnowledgt (d.h. das ACK Bit auf dominanten Pegel setzt), sendet die Schnittstelle einen CAN Error Frame, vergößert in der Regel ihre TX Error Count um eins und versucht stattdessen, den Frame nach einer kurzen Wartezeit erneut zu senden. Dies ist eine normale CAN-Fehler-Bedienung und wird erwartet.

Unten sehen Sie, wie ein solches Verhalten in CANoe/CAnalyzer beobachtet werden kann:

a) Das Fenster Trace zeigt Not ACKnowledge CAN Error Frames

Hinweis: Die dominant/recessive error flag zeigt den Chipstatus (aktiv/passiv) des CAN Chips der Schnittstelle an.

b) In der CAN-Statistik ist die Chip State Passive und die Transmit Error Count (TEC) ist 128

c) Im Fenster Write kann CANoe den Fehler anzeigen:
System <time>: CAN <channelnumber> : Message with ID = <ID> could not be sent. Driver error 11 in TransmitCANFrame

Lösung:
Stellen Sie sicher, dass mindestens ein anderer teilnehmender Knoten die vom Vector Interface gesendeten CAN Frames quittiert (d.h. das ACK-Bit setzt).

Mögliche Ursachen:

Ungesichertes reales Steuergerät
Fehlende oder unvollständige Terminierung
Keine/fehlerhafte physikalische CAN-Verbindung
Reales Steuergerät quittiert aus anderen Gründen nicht ACK (prüfen Sie in Ihren Spezifikationen, welche Bedingung erfüllt sein muss, damit Ihr Steuergerät einen Frame quittiert)

Mögliche Abhilfemaßnahmen:

Steuergerät einschalten
Physikalische CAN-Bus-Terminierung prüfen (z.B. ist für CAN High-Speed ein 120 Ω Widerstand zwischen CAN_H und CAN_L an beiden Enden des CAN-Bus vorgeschrieben)
Physikalischen CAN-Bus auf korrekte Verbindung der Linien CAN_H(igh) und CAN_L(ow) prüfen
Einen zweiten verfügbaren Kanal des Vector-Interface verwenden, um als zweiter teilnehmender Knoten im Netzwerk zu fungieren, wenn kein echtes Steuergerät verfügbar ist

3.2.2 Bitfehler und Füllbitfehler im Fenster Trace

Diese Error Frames werden üblicherweise verursacht, wenn es ein Problem mit der eigentlichen physikalischen CAN-Bus Kommunikation gibt.

a) Im Fenster Trace werden Stuff Error Frames und/oder Bit Error Frames angezeigt

b) In der CAN-Statistik ist Chip State Passive und Transmit Error Count (TEC) ist 128 im Falle von Stuff-Fehlern. Im Falle von Bit Error Frames kann der TEC über 128 bis 255 vergößert werden. Dies führt zu einem Bus Off Zustand des CAN Controllers des Vector Interfaces. Im Zustand Bus Off empfängt und sendet das Vector Interface keine CAN Frames auf dem spezifischen CAN Kanal, es sei denn, es wird zurückgesetzt oder CANoe/CANalyzer wird neu gestartet. Daher werden im Fenster Trace keine neuen Frames angezeigt.
(Hinweis: Der Kanal des Interfaces kann auch während der Messung über die CAPL-Funktionen reset()/resetEx() zurückgesetzt werden)

c) Im Fenster Write kann CANoe/CANalyzer den Fehler anzeigen:
System <time>: CAN <channelnumber> : Message with ID = <ID> could not be sent. Driver error 11 in TransmitCANFrame

Lösung:
Um diese Kommunikationsfehler, die auf den physikalischen Linien des Busses auftreten, richtig zu analysieren, wäre ein Oszilloskop (z.B. Picoscope) in Verbindung mit der entsprechenden Software (z.B. CANoe Option Scope) erforderlich.

Oft können diese Fehler jedoch pragmatisch behoben werden, wenn die folgenden Anforderungen eingehalten werden - falls nicht, prüfen Sie bitte den Anwendungshinweis AN-ANI-1-115 Common High-Speed Physical Layer Problems für weitere Informationen: