Beiträge von freakmaster

Zitat von M57_Tourer

Wäre beim alten M57 ganz klar der Nockenwellensensor

Sollte der dann nicht im FS auftauchen?
Ich hatte den im FS, als die Steuerkette gerissen ist...
Laut Doku vom BMW geht der Motor deswegen nicht aus, würde sich aber nicht mehr starten lassen.

Versucht er denn zu zünden oder tut sich gaaaaar nix?
Wenn ers versucht sollte es sich anders anhören ("angestrengter") bzw. Rauch ausm Auspuff kommen.
Wenn er sich "unangestrengt" anhört, wird kein Sprit eingespritzt => Kann die Synchronisation zwischen "Wegfahrsperre" (CAS) und Motorsteuergerät (DDE) sein.

Auf alle Fälle jemanden mit den entsprechenden Tools den Fehlerspeicher auslesen lassen!
Bitte keine generischen Programme verwenden, sondern originale! Da sieht man einfach mehr Daten...

Überbrücken kannst du am
Massepin => Fahrtrichtung links, am Dom. Schaut aus wie eine Sechskantschraube mit Kuhle oben und verlängertem Zylinder nach unten
Plus-Anschluss => Fahrtrichtung links, rote Kappe mit großem + Zeichen

Puh...
Hast du die genaue Bezeichnung von dem Typenschild der Lader?

btw: in deinem Profil gibst du einen 520d an, im ersten Post einen 530xd - fährst du mehrere oder ists ein Tippfehler?

Also, mein Bauchgefühl sagt irgendwie: falscher Lader.

Ich hatte mittlerweile 6 Lader (orig & Austausch) vom M57N2 in der Hand und alle haben so ausgeschaut wie der obere...
Hast du geschaut, von welchem Hersteller der neue ist?

Sorry für die späte Rückmeldung. War erst auf Geschäftsreise und dann mit Sabine beschäftigt...

Zitat von Paladin

Frage 1: Wieviele Menüpunkte und Informationen kann/soll man später abrufen?
Frage 2: Ist das Display "nur" druckempfänglich, oder kann man auf dem Display auch wischen wie auf einem Handy?

Zu Frage 1:
Schwer zu sagen...
Kommt immer darauf an, was einen interessiert.
Vorteil: Wenn mal die Grundlagen geschaffen sind, kann das theoretisch jedermann selbst mit dem Nextion Editor selbst erweitern (Der Controller ist da aufwändiger).
Daher würde ich einen "weiter" bzw. "zurück" Button ("<" oder ">") vorsehen, um die entsprechenden Seiten durchschalten zu können.

Zu Frage 2:
Das Display ist leider nur Druckempfindlich (Resistiv). Wischen ginge nur vernünftig mit einem Kapazitiven Display.

Steuerung über den Controller (ZBE) wäre theoretisch schon möglich aber um eine parallele Wirkung auf das Navi + Display zu verhindern, müsste man einen dual-CAN-Controller einsetzen und zwischen Fahrzeug und ZBE einschleifen. Zusätzlich stellt sich dann die Frage, wie man zwischen Display und Navi umschaltet...
Alles in allem meiner Meinung nach nicht "smooth" machbar.

Zitat von Paladin

Was genau meinst Du mit Befehlsset?

Das Display ist bis zu einem gewissen Maß "intelligent".
Man kann ihm mit einer gewissen Anzahl an definierten Befehlen sagen, was es machen soll: instruction-set

Was z.B. geht ist: "Zeichne einen Strich vom Koordinate xy bis Koordinate xy in der Farbe z".
Der Vorteil daran: Ich muss mich nicht um die Berechnung der Koordinaten zwischen den beiden Punkten kümmern und dem Display sagen, dass es da auch noch Farbige Punkte setzen soll
=> Spart Rechenleistung und ich kann mich weiterhin um den CAN kümmern.

Was nicht geht ist der Befehl: "Zeichne einen 20 px breiten, geschwungenen Pfeil mit einem Farbverlauf von grün nach lila von links unten nach rechts oben".
Hier müsste ich die einzelnen Pixel selbst berechnen, was zwar möglich aber einfach scheixxe ist
Lösung => Ein jpg mit dem Pfeil vorbereiten und das dann als Bild anzeigen lassen.

Das müsste man z.B. auch mit den Buttons machen, wenn die die Farbe von weiß auf orange ändern sollen!

@MarcelA

Zitat von MarcelA

Nochmal Fragen zu den Datenpaketen.
0AA ist die Can ID , Dann sollte doch die länge kommen oder (#) ? oder steht # für 8
Woher weiß man als nächstes für was z.b BB C3 2C FE oder CC oder 14 steht,
und könnte mir dann jemand die rechnung der Hex zeigen.

zu der Frage wegen der Länge hatte ich hier schon was geschrieben:

Zitat von Freakmaster

Wer die Daten unten mit dem Beispiel vom Hemi vergleicht, wird feststellen, dass in dem Trace keine Angabe zur Länge des Datenblocks enthalten sind.
Das ist im Falle des Traces auch irrelevant, da die Datei Zeilenweise eingelesen wird und damit das Ende der Zeile (LF / LineFeed) das Ende des Datenblocks markiert.

Die Daten aus dem Trace kann man einfach manuell aufsplitten.
Zeile im Trace:
0AA#EABD099EB80A9483<LF>
=>
0AA # EA BD 09 9E B8 0A 94 83
=>
ID: 0AA
# <= Trennzeichen // ab hier kommen Daten
EA BD 09 9E B8 0A 94 83 => immer 2 Zahlen/Buchstaben ergeben einen "Block" bzw. ein Byte
<LF> => Zeilenende und damit auch Datenblockende

Zum Umrechnen nutze ich immer entsprechende Rechner. Z.B. den hier: klick
Was meinst du denn damit?

Zitat von MarcelA

Das ist ja nur aus der ASCII Tabelle richtig

Die ASCII Tabelle ist eine Tabelle, welche einen "Zahlenwert" zu einem Buchstaben umwandelt und hat mit dem Beispiel nichts zu tun.
Fassen wir nochmal kurz zusammen:

Es gibt (mindestens) drei Möglichkeiten, "Daten" über den Bus zu transportieren.
- Binär => z.B. Türstatus
- als Zahlenwerte => 0AA - Beispiel mit dem Gaspedal hier ausm Thread
- als Zeichenwerte => 0x380

Da wir ja erstmal nicht wissen, um welche Daten es sich auf dem Bus handelt, müssen wir uns das System immer genau anschauen und herumtesten.
Je nach verwendetem Tool werden nebeneinander HEX sowie DEZ-Daten angezeigt, womit sich die Fgst-Nr. z.B. recht einfach finden lässt, sofern sie nicht irgendwie verschlüsselt wurde.

@Ivy_E60:
Auf auf, wieder ran an den Speck!
Ich bin leider die Woche auf Geschäftsreise und kann von hier aus nicht auf dein Excel zugreifen aber ich glaube, ich kenne es und habe auch daraus schon ordentlich gelernt!
Wenn du lust hast, schnapp dir mal die DBC und schau drüber.
Hattest du schonmal mit den cantools gearbeitet? Das .h und .c-Files mit denen erstellen klappt bisher leider auf meinem Linux nicht...

@Paladin:
Die Icons sind schonmal cool!
Hättest du einen geschickteren Vorschlag für die Anzeigen? Ich bin grafisch wie gesagt ne 0-Nummer, also lass dich darauf nicht festlegen!
Das einzige, was uns einschränkt ist das Befehlsset des Displays, was sich aber unter Umständen wieder mit Images aushebeln lässt...

Ohne Dynamic Drive sollten ~1,5-2L rein passen.
Mit DD sind es knapp 3 bzw. wenn alles wirklich leer war, etwas mehr - sofern ich nich noch richtig erinnere.

Das Anpassen der Skalen ist nicht schwer - da ist das Auslöten vom EEPROM aufwändiger.
Dafür gibt es mittlerweile eine Software, welche ziemlich einfach zu benutzen ist. Such mal nach "perfekt toolbox".
Alternativ kannst du das ganze mit HEX-Werten selber ausrechnen aber das willst du nicht

Zitat von saft6luck

BTW mit welchem Tool erstellst du die CAN DB? Mein Tool kann sie nicht lesen: syntax error in line 115

Sorry, war tatsächlich einer drin...
Ist mit SavvyCan erstellt. Der Hundling lässt einen speichern aber das File dann nicht mehr laden...
War ein Fragezeichen drin, das wohl nicht zulässig ist.

Bei dem Display ist links oben x0,y0
Rechts unten dann x400,y240

Mittelposition war natürlich falsch, sorry. Da gehört jeweils die Hälfte der Control-Höhe/-Breite dazu gerechnet, welche bei 80x80 liegt
Die Mittelpunkte sollten damit auf: x80,y108 und x320,y108 liegen (Zahlen "begradigt").

Die Farbe der Zeiger kann man problemlos im Betrieb anpassen.
Ist nur ein bisschen Code notwendig.

@Paladin: Langsam tippen ist nach "zwei mal so einen Text ausm Kopf raus tippen" zu viel verlangt

Displaygröße sind 400*240 Pixel.
Die beiden Gauges sind derzeit mit dem Generator hier Unter Nutzung der folgenden Daten erstellt (Spoiler -> Codeblock). Mittelpositionen der Gauges im Bild sind x=41,y=68 und x=278,y=68

Die Icons der Buttons haben derzeit eine Größe von 30x30 (Tanken), 40x40 (< >) oder 50x50 (Settings & Home) Pixel wobei nur die Pfeile einen Rahmen außen rum bekommen haben.
Skalieren lassen sie sich ja im Normalfall ganz gut.
Format der Bilder geht JPG und PNG out of the box - der Rest wird hald umkonvertiert.
Hintergrund immer #000, Hauptfarbe im Regelfall #fff - bei der kleinen Tempanzeige die BMW-M-Farben:

rgba(69,153,254,.70)

rgba(3, 30, 73)
rgba(238,4,5,.70)

Ansonsten sei deiner Kreativität keine Grenze gesetzt

<!doctype html>
<html>
	<head>
		<title>Gauges as Components</title>
		<script src="gauge.min.js"></script>
	</head>
	// https://canvas-gauges.com/documentation/user-guide/using-as-component
	<body>
		<!-- Injecting radial gauge -->
		<canvas data-type="radial-gauge"
				data-width="100"
				data-height="100"
				data-units="Nm"
				data-title="false"
				data-borders="false"
				data-value="0"
				data-min-value="0"
				data-max-value="600"
				data-major-ticks="0,100,200,300,400,500,600"
				data-minor-ticks="4"
				data-stroke-ticks="true"
				data-highlights='[
					{ "from": 0, "to": 600, "color": "rgba(213,72,57,.70)" }
				]'
				data-color-plate="#000"
				data-color-major-ticks="#222"
				data-color-minor-ticks="#222"
				data-color-title="#fff"
				data-color-units="#fff"
				data-color-numbers="#fff"
				data-value-box="true"
				data-font-value="Led"
				data-font-numbers-size="30"
				data-font-units-size="30"
				// needle 
				data-needle="false"
		></canvas>
		<canvas data-type="radial-gauge"
				data-width="100"
				data-height="100"
				data-units="kW"
				data-title="false"
				data-borders="false"
				data-value="0"
				data-min-value="0"
				data-max-value="200"
				data-major-ticks="0,50,100,150,200"
				data-minor-ticks="5"
				data-stroke-ticks="true"
				data-highlights='[
					{ "from": 0, "to": 200, "color": "rgba(213,72,57,.70)" }
				]'
				data-color-plate="#000"
				data-color-major-ticks="#222"
				data-color-minor-ticks="#222"
				data-color-title="#fff"
				data-color-units="#fff"
				data-color-numbers="#fff"
				data-value-box="true"
				data-font-value="Led"
				data-font-numbers-size="30"
				data-font-units-size="30"
				// needle 
				data-needle="false"
		></canvas>
	</body>
</html>

Zitat von alias10

Sehr interessantes Thema, aber ich verstehe den Sinn dahinter nicht. Was habt ihr vor mit den Daten?

Z.B. das hier
Datendisplay_Main.JPG
Datendisplay_Sport.JPG

Datendisplay ähnlich dem vom saft6luck

Die Technologie (=CAN) dahinter, um die Daten vom Fahrzeug zu bekommen ist die gleiche, jedoch nutze ich z.B. einen anderen Controller (ESP32).

Paladin: Wenn dir mal langweilig ist - Die Anzeigen im Sportmodus finde ich persönlich nicht so pralle, bin aber in der Bildbearbeitung bzw. Erstellung nicht bewandert genug, um selber welche zu basteln...
Icons für Öltemperatur, Wassertemp und Gaspedal bräuchte ich auch noch ;D

marcel: Welche Hardware zum Sniffen gebraucht wird schreibe ich gerne die Tage zusammen.
Ich würde aber gerne vorher noch das Problem der Verbindungsabbrüche im WLAN-Modus beheben - das macht das Arbeiten doch recht unangenehm...

Nicht alle Datenpakete beinhalten jedoch eine Dezimalzahl.
Informationen können auch "bitweise" übertragen werden.

Hier am Beispiel der Datenpakete mit der ID 2FC => Status der Türen:
2FC#81 00 00 FF FF FF FF
2FC#81 55 05 FF FF FF FF

Schauen wir uns die beiden markierten Bytes an (denkt an die Umstellung aufgrund der LSB Codierung).

HEX 0000 = DEZ 0 = BIT 00000000 00000000
HEX 0555 = DEZ 1365 = BIT 00000101 01010101

Fahrertüre = erstes Bit (von rechts nach links!)
Beifahrertüre = drittes Bit
Türe hinten links = fünftes Bit
Türe hinten rechts = siebtes Bit
Motorhaube (unbestätigt) = neuntes Bit
Kofferraum = elftes Bit

Wobei das Bit 0 bedeutet, dass die Türe geschlossen ist.
Wurde sie geöffnet, geht das entsprechende Bit auf 1.
Die beiden Beispiele zeigen also die "Extreme" - alle Türen auf und alle Türen zu.

Wäre z.B. nur die Fahrertüre offen, wäre das Datenpaket folgendermaßen:
2FC#81 01 00 FF FF FF FF

Wäre zusätzlich noch der Kofferraum offen:
2FC#81 01 02 FF FF FF FF

Servus Hemi,

danke dir für die Ausführungen!!
War mir fast alles bekannt aber du hast es definitiv besser auf den Punkt gebracht, als ich

Mit "Die Große Frage ist z.B.: Wer genau übergibt die Daten woher an wen?" war in diesem speziellen Falle die Frage vom Marcel bezüglich RX/TX gemeint.
Dass beim CAN mit "Fire&forgett" gearbeitet wird, hatte ich ja schon beschrieben.

Bei der Kette habe ich den Controller außer acht gelassen, da der von mir verwendete ESP32 bereits einen CAN-Controller eingebaut hat. My fault

Mir ist in der Arbeit leider die Zeit ausgegangen, daher konnte ich die vorbereiteten Beispiele nicht mehr abschicken und muss sie neu schreiben -.-
Ich bleibe mal beim Beispiel mit der ID 0x0AA und überspringe die Zerlegung der Daten vom CAN-Controller in die drei aufgeführten Bestandteile, da das wie gesagt der Treiber von Thomas Barth für mich erledigt...

Hier ein paar Pakete aus einem Trace im Format vom candump aus den CAN-Tools, die ich mitgeschnitten habe, um die 0x0AA zu bestätigen.
Wer die Daten unten mit dem Beispiel vom Hemi vergleicht, wird feststellen, dass in dem Trace keine Angabe zur Länge des Datenblocks enthalten sind.
Das ist im Falle des Traces auch irrelevant, da die Datei Zeilenweise eingelesen wird und damit das Ende der Zeile (LF / LineFeed) das Ende des Datenblocks markiert.

Timestamp Interface <CanID>#<Daten>
(1580407425.319989) can0 0AA#F493FF00A80A8083
(1580407425.419913) can0 0AA#EABD099EB80A9483
(1580407425.519990) can0 0AA#39B828FE640FB486 <= das schauen wir uns mal an

(1580407425.619937) can0 0AA#BBC32CFECC14B48C

39 B8 28 FE 64 0F B4 86
unbekannt
Drehzahl
Drehmoment
Gaspedal

Bei der Gaspedalstellung ist es aus meiner Sicht relativ einfach, da kein Offset und kein Faktor notwendig (ACHTUNG: Wer mit den Infos vom Trevor Cook vergleicht, wird einen Unterschied merken. => Wer findets? ).

Hex 00 = Dez 0 = Standgas

HEX 9E = Dez 158 = ~62% Gas

Hex FE = Dez 254 = Vollgas

Die Drehzahl konnte hier aus meiner Sicht ebenfalls bestätigt werden.
Grundsätzlich können wir davon ausgehen, dass sich die Information der Drehzahl in zwei Byte verstecken muss.
Warum?
Ein Byte = acht Bit = Werte von 0 bis 256
zwei Byte = sechzehn Bit = Werte von 0 bis 65.535
Unsere Drehzahl geht beim Diesel bis ~4500 (gerade Zahl, um es einfacher zu machen), bedeutet also, dass wir die Zahl nicht ohne Offset und Faktor in ein Byte (max 256) rein quetschen können.

Wie vom Hemi ausgeführt, gibt es zwei Arten, die Daten zu codieren. Alle Daten, die ich bisher bei meinem e61 bestätigen konnte, waren LSB codiert.
Bedeutet also, dass wir die Werte der zwei Byte "64" und "0F" erst einmal "zusammenhängen" müssen - und zwar erst das im Array befindliche "höhere" Byte[5] und dann das "niedrigere" Byte[4] => "0F64"

Umgerechnet in einen Dezimalwert wären das dann 3940 - würde erstmal plausibel klingen (bedenkt das Vollgas) AAAABER schauen wir uns eines der kurz darauf folgenden Datenpakete an (DA D3 30 FE 88 3F B4 B0), wäre - noch immer bei Vollgas - der Wert 3F88 umgerechnet: 16264

16 k Umdrehungen? Bei einem Diesel? Niemals ;D
Hier muss also mindestens ein Faktor ins Spiel kommen...
Zum Glück sind Entwickler nicht immer Sadisten (Sorry Hemi Ich gehe mal davon aus, dass du einer bist - und zwar einer, der die Ausnahmen der Regel bestätigt ) und rechnen nicht oft mit krummen Zahlen.
Also tasten wir uns mal langsam ran:

16264 / 2 = 8132 (immer noch zu hoch)
16264 / 3 = 5421,33 (neeeeeee, passt nicht)
16264 / 4 = 4066 => BINGO Das passt doch recht gut

Gegencheck auf unser Paket bei Standgas: A8 0A => 0AA8 => 2728 / 4 => 682 => Passt.
Wenden wir den Faktor also auf die 3940 aus unserem Beispielpaket an, kommt eine Drehzahl von 985 U/Min heraus.

Schauen wir jetzt auf die Zeitstempel, so lässt sich relativ einfach die Zeit herausrechnen, wie lange es gedauert hat, um von Standgasdrehzahl auf Vollgasdrehzahl (bei stehendem Fahrzeug) zu kommen:
(1580407426.620043) can0 0AA#E00D31FE543FB4B0

Vom Zeitstempel schneiden wir mal den identischen Teil weg (158040742...). Dann bleibt übrig:
Zeitstempel bei Standgas: 5.319989
Zeitstempel bei knapp Vollgasdrehzahl: 6.620043

6.620043 - 5.319989 = 1,300054 Sekunden
Wie kommt jetzt so eine glatte Sekundenanzahl zustande? Denkt an den Zeitintervall, in dem die Pakete teilweise geschickt werden...
In diesem Falle 100 ms = 0,1 Sekunden

Zitat von MarcelA

Wenn ich jetzt ein Bmw spezielles Interface habe ist da doch bestimmt der selbe can Reciver wie im datendisplay von Saft6luck drin und wandelt die Daten vom Can H und L aus übergibt sie der Tdx Rdx.

Jein ;D

Hier kommen wir schön langsam zum OSI-Modell...

Transceiver-ICs gibt es natürlich von verschiedenen Herstellern mit unterschiedlichen Spezifikationen. Manche können z.B. die höheren BUS-Geschwindigkeiten nicht, andere brauchen dafür aber mehr Coding (Software) etc.
Alle unterstützen sie jedoch die gleiche "elektrische" Spezifikation (Layer 1). Sonst würden sie einfach geschmeidig in Rauch aufgehen ;D

Das "übergeben" an Tx / Rx stellst du dir aktuell noch etwas zu leicht vor.
Die Große Frage ist z.B.: Wer genau übergibt die Daten woher an wen?
Tx/Rx sind nur Bezeichnungen für Sende-/Empfangsleitungen ohne jegliche Spezifikation, welches Protokoll genutzt wird.
USB hat z.B. diese Leitungen, RS232 jedoch auch! Ein CAN-Transceiver hat die beiden aber ebenfalls...
Alle drei Protokolle haben aber ganz unterschiedliche Spezifikationen, "was wie wann" über welche der beiden Leitungen zu senden ist.

CAN-Transceiver <=> Microcontroller (z.B. Arduino) nutzt "TxD"/"RxD", um miteinander zu kommunizieren. z.B. PDF Seite 5
Nur ist das kein RS232 Protokoll

Wenn ich die Daten dann erst einmal im Microcontroller habe, kann ich sie dann entsprechend weiter Verarbeiten (z.B. Anzeige der Daten auf einem Display) oder weiterschicken (Speichern auf einer SD-Karte, per RS232 Protokoll an den PC oder ein serielles Display, per Wlan an eine PC uvm.)

Mit dem Treiber, den ich auf meinem Arduino benutze, bekomme ich effektiv die drei notwendigen Daten zur Weiterverarbeitung.
Hier mal ein Beispiel, wie die Daten eines CAN-"Telegramms" ausschauen:

ID: 0AA
Länge: 8
Daten: C6 DA F3 00 00 00 84 C8

In diesem Datenpaket verstecken sich nach meinem aktuellen Wissensstand drei Informationen.
1. Drehzahl
2. Drehmoment
3. Gaspedalstellung

Die Drehzahl lässt sich dann z.B. mit folgender Methode auslesen:

int FrameHandlerClass::getEngineRPM(byte* buff)
{
	return (((buff[5] << 8) + buff[4]) / 4);
}

Soweit mal zu der Ausführung - mehr gibts später...

Zitat von MarcelA

Ich meine kann man nicht direkt die Signale am K Can ablesen oder Pt Can?
So ein interface ist doch eigentlich schon so das es die Daten verständlich macht für die Pc Schnittstelle.

Nicht böse nehmen, aber ich glaube da müssen wir etwas weiter bei den basics anfangen - ist glaube ich für alle gut

1. die beiden von mir verwendeten Interfaces lesen direkt die Daten vom K-Can aus.
Wenn ich sie an den PT-CAN hängen würde, wäre das auch durchaus möglich - sind nur unterschiedliche Geschwindigkeiten unter Verwendung der gleichen Protokolle.

2. Thema Protokolle:
Die "Elektrische Kommunikation" passiert immer über ein definiertes "Protokoll".
Das ist im Prinzip nichts anderes als eine Definition, welches Signal (HIGH vs. LOW // z.B. 12V vs. 0V) in welcher Zeit und welcher Abfolge welche Bedeutung hat.
Auf Basis dieser Protokolle werden Daten ausgetauscht.
Beim K-/PT-/F-/...CAN passiert das ganze mit einer Art Telegramm.
Das Telegramm ist grundsätzlich aus folgenden Elementen aufgebaut (Extended-Frames und den Control-Overhead wie CRC etc. lassen wir mal außer acht!):

- ID: dreistellige Identifikationsnummer des Telegrammes.
- Länge: Information, wie lange das Datenpaket ist. (0-8 Bit)
- Datenpaket: Hier sind 0 bis 8 "Paketfelder" zulässig, wobei ich eine Information in einem oder mehreren Feldern verpacken darf.

Steuergeräte senden grundsätzlich einfach immer ihre "Standard"-Daten auf den BUS, welche von den Entwicklern als "dauerhaft wichtig" empfunden wurden.
Bei kritischen Daten (z.B. Drehzahl, "Gaspedalstellung", Crashsensordaten etc.) passiert das in definierten Zeitintervallen (z.B. 200ms, 2s etc.)
Bei weniger kritischen Daten aufgrund eines Ereignisses (z.B. Knopf für die Innenbeleuchtung wurde gedrückt).

Andere Daten wie z.B. der Ladedruck werden nicht automatisch auf den BUS gelegt, weil sie von anderen Steuergeräten normalerweise nicht benötigt werden!
Den Ladedruck braucht im e6x z.B. nur das Motorsteuergerät, welches den Sensor selbst auswertet - also warum dann wertvolle und begrenzte Bandbreite auf dem Bus belegen und die Daten senden, wenn eh keiner zuhört?

Hier kommen wir dann zum Thema Diagnose/-schnittstelle.
Gewisse Daten können per Diagnosesoftware bei den Steuergeräten "angefragt" werden, welche dann als Antwort die gewünschten Daten auf den BUS legen.
Hierbei kommen dann im Normalfall mehrere, unterschiedliche Protokolle zum Einsatz.

Gehen wir z.B. von einem Interface einer freien Werkstatt (!! NICHT BMW !!) aus, das per WLAN mit dem PC Verbunden ist.

1. PC <=> Interface // Protokoll, das genutzt wird, um Daten auszutauschen: TCP

Das Interface übersetzt jetzt die per TCP erhaltenen Daten und es geht weiter:
2. Interface <=> OBD Diagnoseschnittstelle // Protokoll: unterschiedlich.

Warum "unterschiedlich"?
Weil jeder Hersteller sein eigenes Süppchen bezüglich der Diagnoseschnittstellen kocht und zudem noch vom Gesetzgeber gezwungen wurde, gewisse Standards zu unterstützen.
Heißt also, dass das Interface und das Steuergerät, an dem die Diagnoseschnittstelle angeschlossen ist, sich unterhalten und dann auf ein Protokoll einigen.

3. "OBD-Steuergerät" <=> "Ziel-Steuergerät" // Protokoll: CAN

Hinten raus läuft die Kommunikation also dann effektiv wieder über den CAN.
Natürlich könnte man jetzt auf der Netzwerkschnittstelle am PC mitsniffen und die Daten auswerten, wobei hier jedoch wieder properitäre Protokolle auf Basis von TCP verwendet werden, welche man erst analysieren müsste aber warum?
Wir sniffen ja bereits auf dem CAN mit, welcher ja doch relativ einfach gestrickt ist...

Um beim Beispiel von oben zu bleiben:
Wenn wir also den Ladedruck haben wollen, müssen wir "nur" auf dem CAN mitsniffen, über die Diagnosetools den Ladedruck anfordern und schauen, welche Telegramme auf dem BUS hin und her gesendet werden.
Das ist der Teil, den ich selbst leider noch nicht durchgeführt habe. Der steht jedoch auf meinem Plan, sobald mal etwas Zeit da ist...

Ich hoffe, die Erklärung ist halbwegs verständlich und löst so manchen Denkknoten

ps. Wenn Profis mitlesen: Bessere sowie ausführlichere Erklärungen als meine sind erwünscht - ich lern gern dazu!
pps. Die OSI-Schichten hab ich auch mal gemütlich ignoriert ;D

Servus Marcel,

was meinst du denn genau?
Meinst du die CAN-BUS-Daten vom K-CAN über den OBD Stecker?

Zitat von Dr Death

Früher war es bei BMW üblich, dass nur ein "Ersatztacho" verbaut werden konnte der entweder den gleichen oder höheren Kilometerstand hatte ansonsten hat das Kombi gemeckert und der Manipulationspunkt ging an. Was passiert jetzt wohl wenn man sein Kombiinstrument ausbaut, meinetwegen 20tkm. mit dem neuen Digitalen rumfährt und dann sein altes originales wieder einbaut?

Knapp daneben aber trotzdem fast vorbei

1. Manipulationspunkt: Der kommt nur, wenn die VIN aus dem Kombi nicht zur VIN vom Fahrzeug passt. Abgeglichen wird mindestens mit dem CAS soweit ich herausfinden konnte. Ob andere STGs beteiligt sind, weiß ich nicht.

2. Km-Stand: Es wird bei Einbau eines anderen Kombiinstrumentes zwischen "Fahrzeug" und "Kombi" abgeglichen. Der jeweils höhere Km-Stand wird bei dem jeweiligen Partner abgespeichert.
Hat das Kombi weniger und wird ins Fahrzeug eingebaut, wird der Km-Stand vom Fahrzeug im Kombi gespeichert - !!EGAL, OB DIE VIN KORREKT IST!! Also nicht mit dem Kombi von nem Kumpel quertauschen
Hat das Fahrzeug weniger und das Kombi mit dem höheren Km-Stand wird eingebaut, speichern alle STG den höheren Wert ab. Ich weiß derzeit nur von CAS und den Schlüsseln.

Der Kilometerstand im Kombi wird in einem EEProm gespeichert. Je nach Baujahr wird eines der folgenden (oder kompatiblen) EEProms verwendet:
M35080
M35080-3
M35080-6
M35080VP
M35080V6
080D0WQ

Möchte man also ein anderes Kombi aus einem anderen Fahrzeug einbauen, muss man so oder so die VIN im EEProm ändern, sofern man den Manipulationspunkt los werden möchte.
In diesem Zuge setzt man den Km-Stand also einfach gleich mit auf 0 und die Sache ist erledigt. Damit lässt sich das Kombiinstrument dann problemlos mit den üblichen Tools codieren.
Wer das mal brauchen sollte, einfach melden. Kann ich gern erledigen... Wird z.B. auch beim Umbau auf einen M5-Tacho benötigt.

Wenn man das hier angesprochene Display für xx Km eingebaut hatte, einfach das originale Kombi wieder einbauen.
Der höhere Km-Stand wird automatisch im Kombi gespeichert und gut ists.

Zitat von Paladin

Es braucht niemand ein zusätzliches BMW-Emblem auf dem Monitor, wenn man sich schon in einem befindet.

Ach komm. Manchmal braucht man hald noch ne zusätzliche Erinnerung
Ich darf da nicht meckern, da ich was ähnliches in meinem Display drin habe... (Bilder gerade nicht möglich weil @Work...)
Jedoch hat das eine Funktion.

Hier mal noch der aktuelle Stand der Datenbank (massiv erweitert): BMW_E6x_30_01_2020_11_31.zip