Wie erkenne ich die Fehlerursachen für ERR_BUSLIGHT?

[andreastg]

Wir setzen einen PCAN-USB für eine Maschinensteuerung ein. Ich beobachte jetzt in einem System mit einem Mehrkern-Prozessor systematisch einen ERR_BUSLIGHT, wenn aus mehreren Threads Zugriffe auf den PCAN-USB geschehen.
Eigentlich sollten die Threads synchronisiert sein.
Über den PCAN-View konnte ich keine Fehler erkennen.
Gibt es eine Möglichkeit, die Fehlerursachen abzufragen?

[PEAK-Support]

Hallo, bitte bringen Sie als erstes Ihre Treiber auf den aktuellen Stand (mind. Version 3.8.2). Die aktuelle Version finden Sie immer hier.

Der "Fehler" ERR_BUSLIGHT ist aber eigentlich ein Zeichen das auf der Hardwareseite etwas nicht stimmt. Es bedeutet das der interne Errorcounter ein gewissen Level überschritten hat (siehe auch hier)
Überprüfen Sie ob die Verkabelung OK ist (gedrilltes Kabl, keine langen Stichleitungen und beide Enden terminiert mit 120 Ohm), prüfen Sie ob alle CAN Knoten gleiche Baudrateneinstellungen haben (Sample Point etc. beachten)
Schalten Sie bei dem, parallel zu Ihrer Applikation laufendem, PCAN-View (auch hier bitte die neuste Version verwenden) das Aufzeichnen der Fehlermeldungen und Errorcounter im Tracer ein und überprüfen Sie welche Fehler genau auftreten.
Starten Sie erst Ihre Applikation. Dann erst den PCAN-View mit der bereits verwendeten Hardware verbinden.

PCAN-View Logger Settings

PCAN-View.JPG (35.04 KiB) Viewed 13982 times

[andreastg]

Danke für die schnelle Antwort!
Ich habe nochmals alles geprüft:
- die USB-Treiber auf der Steuerungsseite und für PCAN-View sind Version 3.8.2.10146
- beide Enden sind mit 120 Ohm terminiert.
- Verkabelung erfolgt mit CAT5e-Kabeln. CAN-L und CAN-H sind verdrillt
- PCANView zeigt keine Fehler
Die Kommunikation ist über lange Zeit OK, bis ich eine Referenzfahrt für zwei Servoregler starte. Während dieser Fahrt erhalte ich dann (wiederholbar) zuerst einen BUSLIGHT-, dann einen BUSOFF-Fehler. Danach sendet aber auch der Servoregler (Schneider Lexium32) ein PDO mit falschen Werten Ich werde mal dort weiterforschen.
Warum bekomme ich auf der Steuerungsseite einen Fehler, sehe aber im Viewer, dass der Fehlerzähler auf 0 steht?

[PEAK-Support]

Sie schreiben:

Während dieser Fahrt erhalte ich dann (wiederholbar) zuerst einen BUSLIGHT-, dann einen BUSOFF-Fehler. Danach sendet aber auch der Servoregler (Schneider Lexium32) ein PDO mit falschen Werten Ich werde mal dort weiterforschen.

Bedeutet das, dass wenn Sie in Ihrer Applikation CAN Nachrichten Empfangen haben Sie den TPCANMessageType auf "Status PCAN_MESSAGE_STATUS" abfragen und entsprechend auswerten? (siehe auch Doku von PCAN-Basic API)

• Ist im Feld TPCANMsg.MSGTYPE das Bit PCAN_MESSAGE_STATUS gesetzt, ist die gelesene CAN-Botschaft keine Daten-Botschaft, sondern eine Statusmeldung. CAN-ID und Längencode einer solchen Statusmeldung dürfen nicht ausgewertet werden (sie enthalten undefinierte Werte). Die eigentliche Information über den Fehler lassen sich aus den ersten 4 Datenbytes der Nachricht herauslesen, wobei sich das MSB in Datenbyte 0 befindet, und das LSB in Datenbyte 3.
  
  Beispiele:
  
  Data0 Data1 Data2 Data3 Fehler Fehlercode Beschreibung
  00h 00h 00h 02h PCAN_ERROR_OVERRUN 0002h CAN-Controller wurde zu spät gelesen.
  00h 00h 00h 04h PCAN_ERROR_BUSLIGHT 0004h Busfehler: Fehlerzähler erreichte 'Light'-Limit.
  00h 00h 00h 08h PCAN_ERROR_BUSHEAVY 0008h Busfehler: Fehlerzähler erreichte 'Heavy'-Limit.
  00h 00h 00h 10h PCAN_ERROR_BUSOFF 0010h Busfehler: CAN_Controller ging 'Bus-Off'.

Wenn der PCAN-View am selben Netz (Hardware) hängt, so empfangen beide Applikationen (PCAN-View und Ihre) die gleichen Nachrichten. Somit müsste auch der PCAN-View diese Fehler anzeigen...
Ein Busoff wäre auch das ENde der Kommunikation - danach ist bindend ein CAN Controller Reset nötig.

Schalten Sie in Ihrer Applikation bitte mal über CAN_SetValue(..) testweise das Feature BUSSOFF_AUTORESET ein:

• PCAN_BUSOFF_AUTORESET
  
  Zugriff:
  
  Beschreibung: Dieser Parameter veranlasst den PCAN-Treiber zum automatischen Reset des CAN-Controllers, sobald ein Bus-Off-Zustand festgestellt wird. Da während dieses Zustands keine Kommunikation auf dem Bus stattfindet, kann bereits auf Treiberebene mit einem Reset reagiert werden, um die Anwendung nicht mit Behandlungsroutinen zu überfrachten.
  
  Wertebereich: Der Parameter kann nur 2 Werte annehmen: PCAN_PARAMETER_OFF, PCAN_PARAMETER_ON. Andere Werte sind ungültig und werden ignoriert.
  
  Standardwert: Ausgeschaltet (PCAN_PARAMETER_OFF).
  
  PCAN-Gerät: Alle PCAN Geräte (außer PCAN_NONEBUS Kanal).
  

[andreastg]

Ich benutze eine modifizierte Version von PCANLight. Read() und Write() geben einen Fehlercode zurück:
enum CANResult
{
ERR_OK = 0x0000,
ERR_XMTFULL = 0x0001, // Send buffer of the Controller ist full
ERR_OVERRUN = 0x0002, // CAN-Controller was read to late
ERR_BUSLIGHT = 0x0004, // Bus error: an Error count reached the limit
ERR_BUSHEAVY = 0x0008, // Bus error: an Error count reached the limit
ERR_BUSOFF = 0x0010, // Bus error: CAN_Controller went to 'Bus-Off'
ERR_QRCVEMPTY = 0x0020, // RcvQueue is empty
ERR_QOVERRUN = 0x0040, // RcvQueue was read to late
ERR_QXMTFULL = 0x0080, // Send queue is full
ERR_REGTEST = 0x0100, // RegisterTest of the 82C200/SJA1000 failed
ERR_NOVXD = 0x0200, // Problem with Localization of the VxD

ERRMASK_ILLHANDLE = 0x1C00, // Mask for all Handle errors
ERR_HWINUSE = 0x0400, // Hardware is occupied by a net
ERR_NETINUSE = 0x0800, // The Net is attached to a Client
ERR_ILLHW = 0x1400, // Invalid Hardware handle
ERR_ILLNET = 0x1800, // Invalid Net handle
ERR_ILLCLIENT = 0x1C00, // Invalid Client handle
ERR_RESOURCE = 0x2000, // Not generatably Resource (FIFO, Client, Timeout)
ERR_PARMTYP = 0x4000, // Parameter not permitted
ERR_PARMVAL = 0x8000, // Invalid Parameter value
ERR_ANYBUSERR = ERR_BUSLIGHT | ERR_BUSHEAVY | ERR_BUSOFF, // All others error status <> 0 please ask by PEAK ......intern Driver errors.....
ERR_NO_DLL = 0xFFFFFFFF// A Dll could not be loaded or a function was not found into the Dll
};
Diesen Code werte ich aus. Ist er nicht ERR_OK oder (beim Lesen) ERR_QRCVEMPTY, so gebe ich den Fehler aus.

[PEAK-Support]

Verwenden SIe bitte unseren Original Code! Für "modifizierten" Code können wir keinen Support geben -woher sollen wir wissen was Sie geändert haben und ob dort nicht der Fehler ist?. Die Read Funktion muss auch immer und zwingend den MsgType abfragen!!! Wenn dieser vom Typ "PCAN_MESSAGE_STATUS" sollten die Fehlercodes behandelt werden.

[andreastg]

Die Modifikationen sollten nicht das Problem sein, die Erweiterungen waren zur Hardwarekompatibilität notwendig und werden in unserem Fall nicht verwendet. Die Erweiterungen sind auch schon lange im Einsatz und mein Problem tritt erst bei einem ATOM D525 auf. Darum vermutete ich die Fehlerursachen in einer fehlerhaften Synchronsation mehrerer Threads in meiner Software.
Ich habe gesehen, dass CANResult dem Byte TPCANMsg::Data[3] entspricht und, falls CANResult ungleich ERR_OK ist, TPCANMsg::ID den Wert 0x80 enthält (das entsricht MSGTYPE_STATUS im enum MsgTypes aus PCANLight.h).
Aber ein Update unserer Software auf PCANBasic erscheint mir auf alle Fälle sinnvoll, auch wenn ich nicht glaube, dass ich damit mein Problem lösen werde.

[PEAK-Support]

Der Treiber, also der eigentliche CAN Sender/Empfänger, ist bei allen unseren API´s ja der gleiche (pcan_xxx.sys). Die DLL´s geben ja nur API Functionen über IOControlls an den Gerätetreiber weiter. Deshalb kann ich mir auch nicht vorstellen das nach der Umstellung auf die PCAN-Basic API das Problem gelöst sein wird (wobei der Schritt sinnvoll ist, alleine schon wegen der neuen Features, und der Einfachheit auf andere CAN Kanäle und Hardwaretypen umzuschalten).

Unverständlich für mich ist aber, dass der PCAN-View, auf dem gleichen PC, der mit dem gleichen CAN Treiber kommuniziert, die Error Frames nicht sieht - das würde ja bedeuten das der Gerätetreiber den verschiedenen CAN Clients unterschiedliche Nachrichten in die einzelnen Queues sendet - was ausgeschlossenist. Eventuell greifen mehrere Threads auf gleiche Variablen/Strukturen/Objecte zu, und Ihrer Errorframes sind nur Ghost Nachrichten durch auslesen veralteter Werte.

[andreastg]

Obwohl ich den Fehler nur in ganz bestimmten, wiederholbaren Situationen beobachten konnte, ist er verschwinden, nachdem ich die Baudrate auf 500kHz reduziert habe. Das scheint damit doch ein Hardwareproblem zu sein (trotz Terminierungen, CAT5e etc).

[PEAK-Support]

Haben SIe mal Ihre Buslänge berechnet? Beachten Sie das jede galvanische Entkopplung (also zum Bsp. die Verwendung eines PCAN-USB ISO oder eine galv. entkoppelten Karte) eine Verlängerung der physikalischen CAN Leitung darstellt. Auch sind T-Abzweigungen bei hohen Baudraten so kurz wie möglich zu halten. CAT5 Kabel ist auch kein CAN Kabel. Hier wird immer am falschen Punkt gespart - man sollte entsprechende CAN Kabel verwenden (z.B. von LAPP, oder Northwire) die der Spezifikation entsprechen. Gerade wenn man die 1MBit fährt.