Der CAN-Bus im Volvo
Um Kabelbäume unter anderem in Fahrzeugen zu vereinfachen entwickelte Bosch im Jahre 1983 das Controller Area Network. Seit dem Jahr 2000 findet dieses System in vielen Fahrzeugen Anwendung (bei Volvo ab V70II S80 S60 XC70 XC90).
Grundprinzip ist, dass der gesamte Datenaustausch auf zwei Leitungen stattfindet. Diese werden um Reflexionen an beiden Enden zu vermeiden jeweils mit einem 120 Ohm Widerstand terminiert. Die Signalübertragung erfolgt differenziell mit einer Spannungsdifferenz von 2V zwischen CAN-H und CAN-L. Da im KFZ die Datenleitung vielen Störfeldern ausgesetzt ist werden beide Kabel miteinander verdrillt ,damit beide Leitungen den Störungen gleichermaßen ausgesetzt sind und eine Spannungsdifferenz von 2V erhalten bleibt.
Link zur Grafik
Bei einem dominanten Zustand (logisch 0) liegen beide Leitung auf einer Spannung von 2,5 volt. Im rezessiven Zustand (logisch 1) wird die Spannung der Leitung CAN-H(igh) um 1V auf 3,5V angehoben und die Spannung auf der Leitung CAN-L(ow) um 1V auf 1,5V abgesenkt.
Link zur Grafik
Alle im Netzwerk befindlichen Geräte können auf dieser Leitung mithören und abwechselnd senden. Damit sichergestellt wird, dass immer nur ein einzelnes Gerät sendet ist das Übertragungsverfahren streng definiert. Eine Darstellung aller Mechanismen würden den Inhalt des Forums jedoch sprengen, somit ist es an dieser Stelle sinnvoll die wesentlichen Spezifikationen zu erläutern.
Ein Gerät muss immer auf eine Lücke warten, bis es anfangen darf, Daten in das Netzwerk zu senden. Gleichzeitig muss das sendende Gerät im Netzwerk mithören und vergleichen ob jeder einzelne Spannungszustand erfolgreich in das Netzwerk übertragen wird. Da bei einer 1 der Pegel als hoch und einer 0 der Pegel als tief definiert ist, kommt es dazu, dass wenn zwei Geräte gleichzeitig senden, das Gerät mit dem dominanten Bit das Netzwerk auf Null zieht und somit den rezessiven Zustand überschreibt. Weil jedes Gerät die zu sendende Meldung mit dem Zustand des Netzwerkes vergleicht, stellt das Gerät, welches zum eigentlichen Zeitpunkt eine 1 gesendet hat einen Fehler fest und stoppt die eigene Sendung. Infolgedessen haben Meldungen mit einer vorausgehenden 0 eine höhere Priorität als Meldungen mit einer vorausgehenden 1.
Zur Identifikation besteht jede gesendete Meldung aus einer ID und einem Datensatz.
Zum Beispiel die Meldung welche vom Lenkradmodul gesendet wird, um den Zustand des Blinker- und Wischerhebels wiederzugeben:
ID: 0111300A Daten: C0 00 00 27 80 8E 00 C0
Da Volvo den erweiterten J1939-CAN-Frame nutzt besteht die ID aus 4 Bytes “01 11 30 0A” welche einerseits die Priorität der Meldung festlegen und andererseits der Identifikation dienen. Jede ID in einem Netzwerk darf nur einmal vergeben sein. Die ID hat den Nutzen für andere Geräte, dass diese dadurch selektieren können, welche Informationen für sie wichtig sein können. Das Radio beispielsweise achtet auf IDs, welche vom CEM kommen und die Geschwindigkeit und Beleuchtungseinstellung enthalten, wie auch auf IDs welche vom Lenkradmodul kommen und eine Änderung der Lenkradtasten enthalten.
Ein Gerät darf auch über mehrere IDs verfügen, da es auch verschiedene Informationen versenden kann.
Die ID bei Volvo wird gefolgt von einem 8 Byte Datensatz “C0 00 00 27 80 8E 00 C0” in diesem sind die Informationen enthalten, welche das Gerät dem Netzwerk mitteilt.
In Beispiel des Lenkradmoduls codiert die 5te Stelle (Byte 4) für:
5te Stelle:
80: Nichts gedrückt
84: Blinkhebel in rechter Stellung
88: Blinkhebel in linker Stellung
C0: Resettaste am Blinkhebel wird betätigt (Boardcomputerversion)
A0: Read Taste am Blinkhebel wird betätigt
Die 6te Stelle "8E" gibt an, dass der Wischerhebel in 0 Stellung ist.
Die Gesamte Meldung wird etwa alle 15ms in das Datennetzwerk gesendet (nach Priorität häufiger oder seltener), damit jegliche Geräte über den Zustand Bescheid wissen und entsprechend reagieren können. Erhält das CCM die Meldung 84 aktiviert es das Relais für den Blinker der rechten Seite.
Link zum Datendiagramm
Im Datendiagramm ist zu erkennen, dass die gesamte Meldung (als Frame bezeichnet) aus mehr als der ID und dem Datensatz besteht. Es sind noch einige Zusätze nötig, damit eine Meldung erfolgreich übertragen werden kann, diese sind aber bei alleiniger Betrachtung der Meldungen hier nicht von Bedeutung und werden in der realen Anwendung von Controllern automatisch errechnet und durchgeführt.
Kommt es trotz aller Mechanismen dazu, dass ein Fehler auftritt, weil beispielsweise eine ID doppelt im Netzwerk auftritt, unterbricht das Gerät mit gleicher ID die Sendung sofortig und versucht zu einem weiteren Zeitpunkt seine Meldung in das Netzwerk zu senden. Kommt es weiterhin hintereinander zum selbigen Fehler, klinkt sich das Gerät für eine vergleichsweise längere Zeit (ca. 10s) aus dem Netzwerk aus und versucht den Datentransfer erneut. Dies kann jedoch gravierend sein, wenn beispielsweise für etwa 10s der Blinker nicht mehr funktioniert.
Im Volvo gibt es zwei verschiedene CAN-Netzwerke:
Link zur Grafik
Das Motor High-Speed CAN mit einer Datenrate von 250kb/s und das Comfort-Low-Speed-CAN mit einer Datenrate von 125kb/s. Beide Netzwerke laufen voneinander unabhängig, das CEM ist das einzige Gerät welches in Kontakt mit beiden Netzwerken steht und somit Daten zwischen diesen austauschen kann wie beispielsweise die Drehzahl.
Volvo hat die Codierung jeglicher Daten in jedem Baujahr geändert, was zur Folge hat, das sich Geräte aus unterschiedlichen Baujahren nicht über den CAN-Bus unterhalten können, das sie ihre Meldungen nicht mehr verstehen.
Dazu ein Beispiel für die Datenwörter, welche unter anderem für die Tasten des Lenkrades zuständig sind:
Fahrzeug aus 2001
ID: 00200066 Daten: C0 00 00 01 1F 40 40 7F
Fahrzeug aus 2002:
ID: 0261300A Daten: 80 00 00 27 80 C2 00 CF
Beide Meldungen erfüllen genau die gleiche Funktion, können aber nicht von Geräten aus anderen Baujahren interpretiert werden.
Durch diese Zusammenhänge lassen sich nicht nur Funktionen im Fahrzeug ergründen sondern auch Erweiterungen wie die eines CAN-Extenders aufbauen. Durch ein einfaches Senden einer Meldung in dieses Netzwerk lässt sich somit etwa eine Coming-Home Funktion mit zusätzlich aktivierten Nebelscheinwerfen realisieren oder es können Tastendrücke oder Fahrzeugdaten jeglicher Art erfasst werden.
Beste Antwort im Thema
Um Kabelbäume unter anderem in Fahrzeugen zu vereinfachen entwickelte Bosch im Jahre 1983 das Controller Area Network. Seit dem Jahr 2000 findet dieses System in vielen Fahrzeugen Anwendung (bei Volvo ab V70II S80 S60 XC70 XC90).
Grundprinzip ist, dass der gesamte Datenaustausch auf zwei Leitungen stattfindet. Diese werden um Reflexionen an beiden Enden zu vermeiden jeweils mit einem 120 Ohm Widerstand terminiert. Die Signalübertragung erfolgt differenziell mit einer Spannungsdifferenz von 2V zwischen CAN-H und CAN-L. Da im KFZ die Datenleitung vielen Störfeldern ausgesetzt ist werden beide Kabel miteinander verdrillt ,damit beide Leitungen den Störungen gleichermaßen ausgesetzt sind und eine Spannungsdifferenz von 2V erhalten bleibt.
Link zur Grafik
Bei einem dominanten Zustand (logisch 0) liegen beide Leitung auf einer Spannung von 2,5 volt. Im rezessiven Zustand (logisch 1) wird die Spannung der Leitung CAN-H(igh) um 1V auf 3,5V angehoben und die Spannung auf der Leitung CAN-L(ow) um 1V auf 1,5V abgesenkt.
Link zur Grafik
Alle im Netzwerk befindlichen Geräte können auf dieser Leitung mithören und abwechselnd senden. Damit sichergestellt wird, dass immer nur ein einzelnes Gerät sendet ist das Übertragungsverfahren streng definiert. Eine Darstellung aller Mechanismen würden den Inhalt des Forums jedoch sprengen, somit ist es an dieser Stelle sinnvoll die wesentlichen Spezifikationen zu erläutern.
Ein Gerät muss immer auf eine Lücke warten, bis es anfangen darf, Daten in das Netzwerk zu senden. Gleichzeitig muss das sendende Gerät im Netzwerk mithören und vergleichen ob jeder einzelne Spannungszustand erfolgreich in das Netzwerk übertragen wird. Da bei einer 1 der Pegel als hoch und einer 0 der Pegel als tief definiert ist, kommt es dazu, dass wenn zwei Geräte gleichzeitig senden, das Gerät mit dem dominanten Bit das Netzwerk auf Null zieht und somit den rezessiven Zustand überschreibt. Weil jedes Gerät die zu sendende Meldung mit dem Zustand des Netzwerkes vergleicht, stellt das Gerät, welches zum eigentlichen Zeitpunkt eine 1 gesendet hat einen Fehler fest und stoppt die eigene Sendung. Infolgedessen haben Meldungen mit einer vorausgehenden 0 eine höhere Priorität als Meldungen mit einer vorausgehenden 1.
Zur Identifikation besteht jede gesendete Meldung aus einer ID und einem Datensatz.
Zum Beispiel die Meldung welche vom Lenkradmodul gesendet wird, um den Zustand des Blinker- und Wischerhebels wiederzugeben:
ID: 0111300A Daten: C0 00 00 27 80 8E 00 C0
Da Volvo den erweiterten J1939-CAN-Frame nutzt besteht die ID aus 4 Bytes “01 11 30 0A” welche einerseits die Priorität der Meldung festlegen und andererseits der Identifikation dienen. Jede ID in einem Netzwerk darf nur einmal vergeben sein. Die ID hat den Nutzen für andere Geräte, dass diese dadurch selektieren können, welche Informationen für sie wichtig sein können. Das Radio beispielsweise achtet auf IDs, welche vom CEM kommen und die Geschwindigkeit und Beleuchtungseinstellung enthalten, wie auch auf IDs welche vom Lenkradmodul kommen und eine Änderung der Lenkradtasten enthalten.
Ein Gerät darf auch über mehrere IDs verfügen, da es auch verschiedene Informationen versenden kann.
Die ID bei Volvo wird gefolgt von einem 8 Byte Datensatz “C0 00 00 27 80 8E 00 C0” in diesem sind die Informationen enthalten, welche das Gerät dem Netzwerk mitteilt.
In Beispiel des Lenkradmoduls codiert die 5te Stelle (Byte 4) für:
5te Stelle:
80: Nichts gedrückt
84: Blinkhebel in rechter Stellung
88: Blinkhebel in linker Stellung
C0: Resettaste am Blinkhebel wird betätigt (Boardcomputerversion)
A0: Read Taste am Blinkhebel wird betätigt
Die 6te Stelle "8E" gibt an, dass der Wischerhebel in 0 Stellung ist.
Die Gesamte Meldung wird etwa alle 15ms in das Datennetzwerk gesendet (nach Priorität häufiger oder seltener), damit jegliche Geräte über den Zustand Bescheid wissen und entsprechend reagieren können. Erhält das CCM die Meldung 84 aktiviert es das Relais für den Blinker der rechten Seite.
Link zum Datendiagramm
Im Datendiagramm ist zu erkennen, dass die gesamte Meldung (als Frame bezeichnet) aus mehr als der ID und dem Datensatz besteht. Es sind noch einige Zusätze nötig, damit eine Meldung erfolgreich übertragen werden kann, diese sind aber bei alleiniger Betrachtung der Meldungen hier nicht von Bedeutung und werden in der realen Anwendung von Controllern automatisch errechnet und durchgeführt.
Kommt es trotz aller Mechanismen dazu, dass ein Fehler auftritt, weil beispielsweise eine ID doppelt im Netzwerk auftritt, unterbricht das Gerät mit gleicher ID die Sendung sofortig und versucht zu einem weiteren Zeitpunkt seine Meldung in das Netzwerk zu senden. Kommt es weiterhin hintereinander zum selbigen Fehler, klinkt sich das Gerät für eine vergleichsweise längere Zeit (ca. 10s) aus dem Netzwerk aus und versucht den Datentransfer erneut. Dies kann jedoch gravierend sein, wenn beispielsweise für etwa 10s der Blinker nicht mehr funktioniert.
Im Volvo gibt es zwei verschiedene CAN-Netzwerke:
Link zur Grafik
Das Motor High-Speed CAN mit einer Datenrate von 250kb/s und das Comfort-Low-Speed-CAN mit einer Datenrate von 125kb/s. Beide Netzwerke laufen voneinander unabhängig, das CEM ist das einzige Gerät welches in Kontakt mit beiden Netzwerken steht und somit Daten zwischen diesen austauschen kann wie beispielsweise die Drehzahl.
Volvo hat die Codierung jeglicher Daten in jedem Baujahr geändert, was zur Folge hat, das sich Geräte aus unterschiedlichen Baujahren nicht über den CAN-Bus unterhalten können, das sie ihre Meldungen nicht mehr verstehen.
Dazu ein Beispiel für die Datenwörter, welche unter anderem für die Tasten des Lenkrades zuständig sind:
Fahrzeug aus 2001
ID: 00200066 Daten: C0 00 00 01 1F 40 40 7F
Fahrzeug aus 2002:
ID: 0261300A Daten: 80 00 00 27 80 C2 00 CF
Beide Meldungen erfüllen genau die gleiche Funktion, können aber nicht von Geräten aus anderen Baujahren interpretiert werden.
Durch diese Zusammenhänge lassen sich nicht nur Funktionen im Fahrzeug ergründen sondern auch Erweiterungen wie die eines CAN-Extenders aufbauen. Durch ein einfaches Senden einer Meldung in dieses Netzwerk lässt sich somit etwa eine Coming-Home Funktion mit zusätzlich aktivierten Nebelscheinwerfen realisieren oder es können Tastendrücke oder Fahrzeugdaten jeglicher Art erfasst werden.
277 Antworten
Die Library findet folgendermaßen Anwendung:
Code:
#include <Canbus.h> //Über Include werden die benötigten Librarys
#include <defaults.h> //in das Projekt verlinkt
#include <global.h>
#include <mcp2515.h>
#include <mcp2515_defs.h>
void setup() // Setup dieser Vorgang erfolgt einmal nach dem Start
{
Serial.begin(115200);
//Hiermit wird der CAN-Controller auf 125 kBit initialisiert
if(Canbus.init(CANSPEED_125))
Serial.println("CAN Init ok"😉;
else
Serial.println("Can't init CAN"😉;
delay(1000);
}
void loop() //Dies ist die eigentlich Programmschleife
{ //Alle Befehle hier werden dauerhaft durchlaufen
tCAN message; //Verknüpft die Variablen mit der CAN-Library
//Steht einmalig zu Beginn der Schleife
if (mcp2515_get_message(&message)) { //Prüft neue Meldung
//Wenn eine Meldung empfangen wurde, wird der Code in dieser Schleife durchgeführt
}
}
In diesem Beispiel wird überprüft, ob die die gelbe Taste auf der Fernbedienung betätigt wurde.
Beim 2001er V70 sieht die ID folgendermaßen aus:
ID: 00A1102A Datensatz: 80 30 00 10 04 00 00 00
Bei Betätigung ändert sich die 6te Stelle von 00 in 35
Falls dies passiert, aktiviert das Fahrzeug die Nebelscheinwerfer für etwa 10 Sekunden durch das Senden folgender Nachrichten:
ID: 000FFFFE Datensatz 8F 40 B1 1A 21 01 00 40
15ms Pause
ID: 000FFFFE Datensatz 4E 00 00 00 40 00 00 00
3900ms Pause
ID: 000FFFFE Datensatz D8 00 00 00 00 00 00 00
Die Aktivierung der Nebelscheinwerfer besteht aus zwei Meldungen, welche in einem Abstand von 15ms gesendet werden müssen, ansonsten reagiert das CEM nicht auf diese.
Die Aktivierung läuft jedoch nach etwa 4 Sekunden aus, und wird um weitere 4 Sekunden durch eine Alive-Message (verlängert alle Diagnoseaktivierungen) verlängert
Code:
#include <Canbus.h>
#include <defaults.h>
#include <global.h>
#include <mcp2515.h>
#include <mcp2515_defs.h>
void setup()
{
Serial.begin(115200);
//Initialise MCP2515 CAN controller at the specified speed
if(Canbus.init(CANSPEED_125))
Serial.println("CAN Init ok"😉;
else
Serial.println("Can't init CAN"😉;
delay(1000);
}
void loop()
{
tCAN message;
if (mcp2515_get_message(&message)) {
if (message.id == 0x111300A) { //Überprüft auf ID 0111300A
Serial.println("ID trifft zu"😉;
if (message.data[5] == 53){ //Überprüft 6te Stelle Zählweise von 0 an
//Die 35 HEX ist in Dez eine 53 und wurde umgerechnet
Serial.println("Licht wird eingeschaltet"😉; //Meldung im Serial Monitor
//Wenn diese Meldung stimmte wird die erste Meldung gesendet
message.id = 0xFFFFE;
message.header.rtr = 0;
message.header.length = 8;
message.data[0] = 0x8F;
message.data[1] = 0x40;
message.data[2] = 0xB1;
message.data[3] = 0x1A;
message.data[4] = 0x21;
message.data[5] = 0x01;
message.data[6] = 0x00;
message.data[7] = 0x40;
mcp2515_bit_modify(CANCTRL, (1{REQOP2)|(1{REQOP1)|(1{REQOP0), 0);
mcp2515_send_message_J1939(&message); //Diese Befehle senden
delay(15); //15ms Pause
message.id = 0xFFFFE; //2te Meldung
message.header.rtr = 0;
message.header.length = 8;
message.data[0] = 0x4E;
message.data[1] = 0x00;
message.data[2] = 0x00;
message.data[3] = 0x00;
message.data[4] = 0x40;
message.data[5] = 0x00;
message.data[6] = 0x00;
message.data[7] = 0x00;
mcp2515_bit_modify(CANCTRL, (1{REQOP2)|(1{REQOP1)|(1{REQOP0), 0);
mcp2515_send_message_J1939(&message); //Senden
delay(3900); //3900ms Pause
message.id = 0xFFFFE; //Alive Message
message.header.rtr = 0;
message.header.length = 8;
message.data[0] = 0xD8;
message.data[1] = 0x00;
message.data[2] = 0x00;
message.data[3] = 0x00;
message.data[4] = 0x00;
message.data[5] = 0x00;
message.data[6] = 0x00;
message.data[7] = 0x00;
mcp2515_bit_modify(CANCTRL, (1{REQOP2)|(1{REQOP1)|(1{REQOP0), 0);
mcp2515_send_message_J1939(&message); //Senden
}
}
}
}
Der Code ist nicht ideal, die lange Pause von fast 4 Sekunden blockiert den Controller die gesamte Zeit. Die gelbe Taste wird nur im Stand betätigt, wenn gleichzeitig keine anderen Funktionen benötigt werden ist dies so aber durchführbar.
Ich vergleich die Datensätze im in dezimaler Form, da ich die Schreibweise bevorzuge
if (message.data[5] == 53) und der Wert eh nur einmal umgerechnet werden muss.
Am schnellsten geht dies mit einer Tabelle oder einem Umrechner wie diesem .
Ein hexadezimaler vergleich würde so aussehen:
if (message.data[5]&0x35), für den Prozessor sollte dies egal sein.
Ja Dankeschön... jetzt ist die Basis da...alles weitere muss man wohl mit kreativität und Geduld rausbekommen....ich habe gerade versucht die datensätze zuzuordnen...Bis auf die Fensterheber habe ich auch alle gefunden...muss icch bei denen etwas besonderes beachten? Zündung etc. ?? Oder sind die einfach nur schwer zu finden ?
Habe dies selbst nur als Wochenendprojekt betrieben und auch nicht alle Meldungen, je mehr man aus dem Traffic versteht, desto besser. Es können aus Vida aber nicht nur Aktivierungen gesendet werden, sondern auch Diagnoseanfragen, dazu fallen aber immer zusätzliche Meldungen an, desshalb bevorzuge ich es so viel wie möglich aus dem Traffic zu lesen.
Je nach Zündschlüsselposition gibt es aber auch mehr oder weniger Meldungen im Bus.
Die Schlüsselposition erhält man damit durch Senden von:
ID: 000FFFFE Datensatz: CD 40 A6 1A 04 01 00 00
Darauf gibt es einmalig folgende Meldung zurück:
ID: 00800003 Datensatz: CD 40 E6 1A 04 1E 00 00
Die 6te Stelle steh dann für:
1D Position Radio
1E Position Zündung
1C Position aus
18 Kein Schlüssel im Schloss
Die Batteriespannung gibt es durch das Senden von:
ID: 000FFFFE Datensatz: CD 40 A6 1A 02 01 00 00
Darauf kommt einmalig zurück:
ID: 00800003 Datensatz: CD 40 E6 1A 02 60 00 00
Die 6te Stelle in Dezimal durch 8 geteilt ergibt anschließend die Batteriespannung in Volt.
Ähnliche Themen
Das Empfangen mit der Library gestaltet sich sehr übersichtlich, anders sieht dies mit dem Senden aus, hier ist es sehr unübersichtlich und platzraubend.
Um alles stark zu komprimieren und zu vereinfachen, habe ich das Senden in eine Funktion unten im Skript gepackt, welche sich wesentlich schneller aufrufen lässt.
Das Skript mit selbiger Funktion sieht anschließend so aus:
Code:
#include <Canbus.h>
#include <defaults.h>
#include <global.h>
#include <mcp2515.h>
#include <mcp2515_defs.h>
void setup()
{
Serial.begin(115200);
//Initialise MCP2515 CAN controller at the specified speed
if(Canbus.init(CANSPEED_125))
Serial.println("CAN Init ok"😉;
else
Serial.println("Can't init CAN"😉;
delay(1000);
}
void loop()
{
tCAN message;
if (mcp2515_get_message(&message)) {
if (message.id == 0x111300A) {
Serial.println("ID trifft zu"😉;
if (message.data[5] == 53){
Serial.println("Licht wird eingeschaltet"😉;
cantx(0xFFFFE, 0x8F, 0x40, 0xB1, 0x1A, 0x21, 0x01, 0x00, 0x40);
delay(15);
cantx(0xFFFFE, 0x4E, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00);
delay(3900);
cantx(0xFFFFE, 0xD8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
}
}
}
}
//Beginn Funktion Senden
uint8_t cantx(long id, int c0, int c1, int c2, int c3, int c4, int c5, int c6, int c7)////Senden
{
mcp2515_bit_modify(CANCTRL, (1{REQOP2)|(1{REQOP1)|(1{REQOP0), 0); //Bit modify
uint8_t status = mcp2515_read_status(SPI_READ_STATUS);
uint8_t address;
uint8_t t;
uint8_t TXBnSIDH=0;
uint8_t TXBnSIDL=0;
uint8_t TXBnEID8=0;
uint8_t TXBnEID0=0;
if (bit_is_clear(status, 2)) {
address = 0x00;
}
else if (bit_is_clear(status, 4)) {
address = 0x02;
}
else if (bit_is_clear(status, 6)) {
address = 0x04;
}
else {
// all buffers are used => could not send message
return 0;
}
RESET(MCP2515_CS);
spi_putc(SPI_WRITE_TX | address);
TXBnSIDH = (id) } 21; // 8 MSB of Identifier A
TXBnSIDL = (id) } 18;
TXBnSIDL = (TXBnSIDL { 5) | 0x08 ; // 3 LSB of Identifier A. Enable Extended identifier (bit 3)
if (GETBIT((id),17)==1) SETBIT(TXBnSIDL,1); // bit 17 of Identifier B
if (GETBIT((id),16)==1) SETBIT(TXBnSIDL,0); // bit 16 of Identifier B
TXBnEID8 = (id)}8; // bits 8-15 of Identifier B
TXBnEID0 = (id); // bits 0-7 of Identifier B
spi_putc(TXBnSIDH);
spi_putc(TXBnSIDL);
spi_putc(TXBnEID8);
spi_putc(TXBnEID0);
uint8_t length = 8 & 0x0f;
if (0) { //if (message->header.rtr) {
// a rtr-frame has a length, but contains no data
spi_putc((1{RTR) | length);
}
else {
// set message length
spi_putc(length);
// data
spi_putc(c0);
spi_putc(c1);
spi_putc(c2);
spi_putc(c3);
spi_putc(c4);
spi_putc(c5);
spi_putc(c6);
spi_putc(c7);
}
SET(MCP2515_CS);
// send message
RESET(MCP2515_CS);
address = (address == 0) ? 1 : address;
spi_putc(SPI_RTS | address);
SET(MCP2515_CS);
return address;
}////////////////////////////////Ende Funktion Senden
Danke fuer den Code, allerdings zeigt mein Compiler einige Fehler an.....Habe bereits angefangen den Komfort-Blinker zu programmieren. Mein groesseres Problem wird die Komfortöffnung der Fenster. Denn wenn kein Schlüssel steckt können die Fenster nicht runter gefahren werden.....da Bedarf es Kreativität....
Habe das gerade nochmal überprüft, also die Fehler werden durchs Forum erzeugt und treten beispielsweise immer auf bei:
Code:
mcp2515_bit_modify(CANCTRL, (1<<REQOP2)|(1<<REQOP1)|(1<<REQOP0), 0); //Bit modify
auf.
Dabei wird aus << ein { erzeugt und bei >> ein } erzeugt, dies sollte den Fehler darstellen. Suche noch eine andere Art wie der Quellcode am besten hier verlinkt werden kann.
Habe die Zeichen jetzt teilweise in Unicode geschrieben, hoffe das bleibt jetzt auch so:
Code:
#include <Canbus.h>
#include <defaults.h>
#include <global.h>
#include <mcp2515.h>
#include <mcp2515_defs.h>
void setup()
{
Serial.begin(115200);
//Initialise MCP2515 CAN controller at the specified speed
if(Canbus.init(CANSPEED_125))
Serial.println("CAN Init ok"😉;
else
Serial.println("Can't init CAN"😉;
delay(1000);
}
void loop()
{
tCAN message;
if (mcp2515_get_message(&message)) {
if (message.id == 0x111300A) {
Serial.println("ID trifft zu"😉;
if (message.data[5] == 53){
Serial.println("Licht wird eingeschaltet"😉;
cantx(0xFFFFE, 0x8F, 0x40, 0xB1, 0x1A, 0x21, 0x01, 0x00, 0x40);
delay(15);
cantx(0xFFFFE, 0x4E, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00);
delay(3900);
cantx(0xFFFFE, 0xD8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
}
}
}
}
///////////////////////////////////////////////////////////////////////////////Senden
uint8_t cantx(long id, int c0, int c1, int c2, int c3, int c4, int c5, int c6, int c7)
{
//Serial.println(message->id,HEX);
mcp2515_bit_modify(CANCTRL, (1<<REQOP2)|(1<<REQOP1)|(1<<REQOP0), 0); //Bit modify
uint8_t status = mcp2515_read_status(SPI_READ_STATUS);
uint8_t address;
uint8_t t;
uint8_t TXBnSIDH=0;
uint8_t TXBnSIDL=0;
uint8_t TXBnEID8=0;
uint8_t TXBnEID0=0;
if (bit_is_clear(status, 2)) {
address = 0x00;
}
else if (bit_is_clear(status, 4)) {
address = 0x02;
}
else if (bit_is_clear(status, 6)) {
address = 0x04;
}
else {
// all buffers are used => could not send message
return 0;
}
RESET(MCP2515_CS);
spi_putc(SPI_WRITE_TX | address);
TXBnSIDH = (id) >> 21; // 8 MSB of Identifier A
TXBnSIDL = (id) >> 18;
TXBnSIDL = (TXBnSIDL << 5) | 0x08 ; // 3 LSB of Identifier A. Enable Extended identifier (bit 3)
if (GETBIT((id),17)==1) SETBIT(TXBnSIDL,1); // bit 17 of Identifier B
if (GETBIT((id),16)==1) SETBIT(TXBnSIDL,0); // bit 16 of Identifier B
TXBnEID8 = (id)>>8; // bits 8-15 of Identifier B
TXBnEID0 = (id); // bits 0-7 of Identifier B
spi_putc(TXBnSIDH);
spi_putc(TXBnSIDL);
spi_putc(TXBnEID8);
spi_putc(TXBnEID0);
uint8_t length = 8 & 0x0f;
if (0) {
spi_putc((1<<RTR) | length);
}
else {
// set message length
spi_putc(length);
spi_putc(c0);
spi_putc(c1);
spi_putc(c2);
spi_putc(c3);
spi_putc(c4);
spi_putc(c5);
spi_putc(c6);
spi_putc(c7);
}
SET(MCP2515_CS);
RESET(MCP2515_CS);
address = (address == 0) ? 1 : address;
spi_putc(SPI_RTS | address);
SET(MCP2515_CS);
return address;
}/////////////////////////////////////////////Ende Senden
Hört sich auf jeden Fall schonmal gut an, werde gleich mal schauen, ob sich die Fenster mit den Diagnosecodes bewegen lassen, falls der Sommer kommt könnte das ganz praktisch sein...
Auf jeden Fall...es wäre auch noch einmal interessant, wie du die Diagnosecodes rausbekommst...denke ja mal mit Vida....aber wie genau das funktioniert würde moch schon interessieren...
Also die Sache mit Vadis ist eigentlich die bequemste um an Informationen zu gelangen, nur leider fällt dadurch immer zusätzlicher Traffic an, da der Wagen die Informationen nicht ohne Aufforderung sendet, desshalb sollte man einigermaßen sparsam mit Diagnoseanfragen sein, welche man dem Wagen gleichzeitig stellt.
Ich denke es macht wenig Sinn etwa alle 2 Sekunden die Batteriespannung abzufragen nur damit man einen aktuellen Wert erhält, welcher sich wahrscheinlich eh kaum ändert. Besser ist es wenn man rausgefunden hat an welcher Stelle das Fahrzeug die Information über die Batteriespannung selber ständig sendet.
Aber wenn VADIS als Maßstab genommen wird, dies erlaubt die Abfrage von gleichzeitig 12 Parametern in Echtzeit. Denke das man diesen Wert auch nicht unbedingt überschreiten sollte.
So jetzt aber zur Vorgehensweise, VADIS wird gleichzeit mit dem Logger an das Auto angeschlossen, dann lässt man einmal die Fahrzeugkommunikation mit Fehlercodes etc. erfolgen, danach kommt erstmal Ruhe in den BUS. Vadis zeigt nun ständig in einem kleinen Fenster die Schlüsselposition und die Batteriespannung an. Dazu werden die bereits bekannten Meldungen gesendet.
Schlüsselposition:
ID: 000FFFFE Datensatz: CD 40 A6 1A 04 01 00 00
Antwort:
ID: 00800003 Datensatz: CD 40 E6 1A 04 1E 00 00
Batteriespannung:
ID: 000FFFFE Datensatz: CD 40 A6 1A 02 01 00 00
Antwort
ID: 00800003 Datensatz: CD 40 E6 1A 02 60 00 00
Dazu kommt noch die bereits erwähnte Alive-Message für den Diagnosemodus alle 4 Sekunden
ID: 000FFFFE Datensatz: D8 00 00 00 00 00 00 00
Auffällig dabei ist das die Diagnosemeldung immer die ID 000FFFFE hat.
Die ID für die Antwort erfolgt ebenfalls immer nach dem Schema 008... und taucht pro Anfrage immer nur einmal auf, lässt sich also bereits durch die Häufigkeit erkennen.
Dadurch ist es leicht einen Filter in CanHacker zu setzen um nur die Diagnosemeldungen zu erhalten, dazu wird für Start ID und End ID 0 eingetragen und für discrete IDs 000FFFFE, dazu noch den Haken bein Enable Range Filter. Nach eigener Erfahrung ist es am besten dann CanHacker einmal neu zu starten, da es sonst oft nicht richtig funktioniert, gleiches gilt wenn man den Filter wieder entfernt hat
In VADIS gibt es die Möglichkeit jede Menge weitere Werte abzufragen etwa Innenraumtemperatur, Relaisstellung von Lampen etc., immer wenn ein Wert abgefragt wird taucht im Traffic folglich immer eine weitere Meldung mit der ID 000FFFFE auf, auf welche es auch nach ähnlichem Schema eine Antwort gibt.
Genauso lassen sich auch zur Diagnose viele Dinge aktivieren.
Die Meldungen sind aber nicht immer einteilig, es kommt auch vor, wie etwa bei den Scheinwerfern, dass Aktivierungen aus zwei Meldungen bestehen, welche in einem bestimmten zeitlichen Abstand gesendet werden müssen.
Sollen Aktivierungen selbst gesendet werden muss VIDA wieder geschlossen werden, ansonsten überschreibt es die Aktivierungen und es passiert nichts.
Um zusammenhängende Meldungen zu senden nimmt man am besten das Play im Tracer, da die Meldungen dann auch im gleichen zeitlichen Abstand gesendet werden. Um zweiteilige Meldungen zu testen empfiehlt es sich diese in eine Trace-Datei mit dem Texteditor zu Schreiben und dann mit CanHacker zu öffen.
Dazu nimmt man vorher Traffic mit CanHacker auf speichert diesen mit Save Trace und schaut sich diese Datei mit dem Editor an. Das Format sollte selbsterkärend sein. Es können alle vorhandenen Meldungen in dieser Datei gelöscht werden und die eigenen Werte im gewünschten Zeitabstand eingetragen werden.
Über Load Trace kann die datei wieder geöffnet werden und die Meldungen lassen sich abspielen.
Wenn zusätzlich unten in das Transmit Fenster noch die Alive Message alle 4000ms mit Send All gesendet wird bleiben die Aktivierungen auch dauerhaft aktiv und erlöschen nicht bereits nach 4 Sekunden.
Es gibt zur Diagnose des UEM und des CEM jeweils die Aktivierung "Erweiterte X-Versorgung" diese versorgt zusammenhängende Bauteile nach Aktivierung trotz abgezogenem Schlüssel weiterhin mit Strom. Wird diese in Zusammenhang mit der Alive-Message gesendet sollten sich selbst im abgeschlossenen Fahrzeug ohne Schlüssel im Schloss die Fensterheber betätigen lassen...
Hast du das Vadis-System bei E-Bay aus China bestellt?
Ich möchte hier noch einmal darstellen, dass für dieses Projekt keineswegs VADIS benötigt wird, denn die Diagnosemeldungen sollten eigentlich in jedem Fahrzeug funktionieren und bis auf einige wenige (Scheinwerfer und Blinker) werden in der Regel keine Diagnosemeldungen gebraucht.
Natürlich kann man damit viel anstellen, es ist aber auch die Frage welche Funktionen man überhaupt umsetzten will. Wenn man sich beispielsweise den Extender anguckt, weis ich nicht ob man beispielsweise unbedingt den Tacho-Swipe etc. wirklich benötigt.
Darüberhinaus lässt sich dank sardine auch der Arduino als Volvo Diagnosegerät für den Innraum-Bus mit der Volvo Software nutzen.
Ich habe mir schon vor langer Zeit ein bestimmtes Diagnosegerät angeschafft, da es sich beim Unterhalt von 3 Volvos in der Familie und vieler selbst durchgeführter Reperaturen enorm lohnt.
Wenn man dann eh schon drüber verfügt lässt es sich aber auch gut für diesen Zweck nutzen.
So genau möchte ich mich da jetzt nicht unbedingt zu äußern, da das Tool ja zumindest vom Bestellvorgang her in einer Grauzone liegt. Ich gehe nicht davon aus, das man bei dem Lesegerät das Originalgerät des Herstellers erwirbt. Aber laut Onlinerecherche: "Sowohl Erwerb als auch Besitz gefälschter Produkte zu privaten Zwecken ist nicht strafbar".
Desshalb habe ich gehört, dass das Gerät von
http://www.diagtools.de/wholesale/volvo-vida-dice-diagnostic-tool.html
schon innerhalb einer Woche da war, aber noch 20 Euro beim DHL Boten für die Zoll Gebühr fällig wurden.
Alternativ könnte man bei Ali-express reinschauen, dort gibt es noch günstigere Versionen allerdings sollte man immer auf den Versand achten, wenn es nicht DHL (normalerweise unter 10 Tage) ist, kann es sein das man bis zu 3 Wochen warten muss.
Der Link geht nicht. Hier ist z.B. ein Link zu einem Shop, die das Gerät verkaufen: http://www.motor-talk.de/.../...ahrung-mit-vida-dice-t4436756.html?.... Da habe ich meines auch her. Die Lieferung an sich hat sogar nur 2 Tage gedauert, Dienstag abgeschickt und am Donnerstag war es schon da.