CAN, seltsames Fehlerbild, unterschiedliche Pegel

[Andreas K. (altb)]

Moin,

ursprünglich habe ich angefange mich mit dem CAN Bus zu beschäftigen 
wegen U0002 bei ABS, EPS, IPC.

Nachdem die Sternstecker freigelegt wurden habe ich mnich an das Messen 
mit dem DSO gemacht. Anschluß an OBD, von dort geht eine Leitung direkt 
zum ersten Sternstecker, also kein Gateway (z.B. FCM) dazwischen. Minus 
an Signalmasse, ebenfalls am OBD.

Auf dem DSO sind unterschiedliche Pegel für komplette Datenpakete zu 
sehen.
Mal zu hoch (Leitungsinduktivitäten?), mal zu niedrig 
(Leitungskapazitäten und Induktivitäten?).

Ich habe nacheinander, jeweils eine Leitung von den zwei Sternsteckern 
abgezogen (in Summe ca. 25 Leitungen) und immer eine Messung 
durchgeführt.

Das Bild mit den unterschiedliche Pegel blieb.

Frage: Wie Fehlertolerant ist denn der CAN? Ab wieviel Volt DIffernez zu 
1,5 oder 2,5 und 3,5V würde er denn Fehler im Steuergerät hinterlegen?

Ausserdem: Mit dem Peak am Ende eines Datenpakets bestätigen die 
einzelnen Teilnehmer doch den Empfang. Heißt dass, sofern dieser Peak 
sichtbar hat der Teilnehmer das Paket angenommen ("verstanden")?

Anbei ein Bild mit abgezogener CAN- Leitung vom ABS- Modul.

Vielen Dank für Eure Mühe im Voraus

Beste Grüße aus der Stadt mit dem Millionengrab- Wahrzeichen.

Andreas

[Ei der Daus (Gast)]

Du schreibst in Hieroglyphen... Das Photo zeigt Probleme...

[Peter D. (peda)]

Andreas K. schrieb:
> Ab wieviel Volt DIffernez zu
> 1,5 oder 2,5 und 3,5V würde er denn Fehler im Steuergerät hinterlegen?

Dem Steuergerät sind die Pegel vollkommen wumpe. Es hängt nicht am Bus, 
sondern hinter dem CAN-Transceiver (z.B. PCA82C251). Erst wenn an dessen 
RX-Ausgang was nicht stimmt, gibt es Fehler.

[Andreas K. (altb)]

Peter D. schrieb:
> Andreas K. schrieb:
>> Ab wieviel Volt DIffernez zu
>> 1,5 oder 2,5 und 3,5V würde er denn Fehler im Steuergerät hinterlegen?
>
> Dem Steuergerät sind die Pegel vollkommen wumpe. Es hängt nicht am Bus,
> sondern hinter dem CAN-Transceiver (z.B. PCA82C251). Erst wenn an dessen
> RX-Ausgang was nicht stimmt, gibt es Fehler.

Danke für die Antwort. Du hast natürlich recht, das macht der 
Transceiver.
Die Frage war unzureichend beschrieben.

Ich meine:
Ein Modul (TCM, EEC, PCM, usw.) erwartet doch plausible Daten, welche 
eine bestimmte Bedeutung haben.

Z. B.:
Nehmen wir das ABS- Modul welches ein Frame "Flüssigkeitsstand BF- 
Behälter ok" erwarten, sonst würde dies eine Meldung im Cockpit zur 
Anzeige bringen. Die entsprechende rote Warnlampe im IPC (Cockpit) 
aufleuchten lassen.
Stimmen nun auf dem CAN die Pegel für dieses Frames nicht, dann fehlt 
quasi die Meldung "Flüssigkeitsstand BF- Behälter ok" da nicht 
interpretierbar.

Meine erst Frage war also:
Wenn bspw. 3,5V bedeutet "hight" (eins) sein soll, würden bei 3,3V oder 
3,6V noch ein "hight" vom entsprechenden Modul als "hight" verstanden?

Ich arbeite mcih wie gesagt gerade in den Fahrzeug CAN ein...
Sorry, wenn ich das schlecht formuliert habe.

[Andreas K. (altb)]

Andreas K. schrieb:
> Ausserdem: Mit dem Peak am Ende eines Datenpakets bestätigen die
> einzelnen Teilnehmer doch den Empfang. Heißt dass, sofern dieser Peak
> sichtbar hat der Teilnehmer das Paket angenommen ("verstanden")?

Das habe ich mir selbst beantworten können.
Am Ende jedes Frames sollten alle Modul mit einem Bestätigungsbit den 
fehlerfreien Empfang des gerade übertragenen Frames bestätigen...

[Soul E. (Gast)]

Andreas K. schrieb:

> Wenn bspw. 3,5V bedeutet "hight" (eins) sein soll, würden bei 3,3V oder
> 3,6V noch ein "hight" vom entsprechenden Modul als "hight" verstanden?

-1,0 V < Udiff < 0,5 V bedeutet High. Bei CAN heisst das "rezessiver 
Pegel"
0,9 V < Udiff < 5,0 V  bedeutet Low.  Bei CAN heisst das "dominanter 
Pegel".

Udiff wird gemessen zwischen CAN_H (+) und CAN_L (-).

[Martin H. (mahi)]

Andreas K. schrieb:
> Stimmen nun auf dem CAN die Pegel für dieses Frames nicht, dann fehlt
> quasi die Meldung "Flüssigkeitsstand BF- Behälter ok" da nicht
> interpretierbar.

Warum sollten die denn nicht stimmen? Und warum nur für einen Frame?

> Meine erst Frage war also:
> Wenn bspw. 3,5V bedeutet "hight" (eins) sein soll, würden bei 3,3V oder
> 3,6V noch ein "hight" vom entsprechenden Modul als "hight" verstanden?

Was soll denn "hight" sein?

> Ich arbeite mcih wie gesagt gerade in den Fahrzeug CAN ein...
> Sorry, wenn ich das schlecht formuliert habe.

Dann fang doch mal an, nachzulesen, was Du misst/messen willst.
CAN ist differentiell, also sollte die Messung auch differentiell sein. 
Single-Ended Messungen sind nur mäßig aussagekräftig.

Zudem sollte, um die Pegel beurteilen zu können, der Bus korrekt 
terminiert sein - "abgezogenes Kabel" klingt irgendwie nicht danach.

[Andrew T. (marsufant)]

Martin H. schrieb:
> Andreas K. schrieb:
>
>> Meine erst Frage war also:
>> Wenn bspw. 3,5V bedeutet "hight" (eins) sein soll, würden bei 3,3V oder
>> 3,6V noch ein "hight" vom entsprechenden Modul als "hight" verstanden?
>
> Was soll denn "hight" sein?

Ein Typo von High.  Das sit aber nun leicht erkennbar.

>
>> Ich arbeite mcih wie gesagt gerade in den Fahrzeug CAN ein...
>> Sorry, wenn ich das schlecht formuliert habe.
>
> Dann fang doch mal an, nachzulesen, was Du misst/messen willst.
> CAN ist differentiell, also sollte die Messung auch differentiell sein.
> Single-Ended Messungen sind nur mäßig aussagekräftig.

Nun, das ist das kleinste Problem. Es geht recht unproblematisch mit dem 
2K anal scope wie es der TO macht.
 Schau hier:
https://www.youtube.com/watch?v=dP8lg9AahD0

>
> Zudem sollte, um die Pegel beurteilen zu können, der Bus korrekt
> terminiert sein - "abgezogenes Kabel" klingt irgendwie nicht danach.

Kommt drauf an wo man Abzieht -- die Chancen, das der 
Terminierungswiderstand dran bleibt ist  ebenfalls hoch. Siehe Link 
oben.

[Andreas K. (altb)]

soul e. schrieb:
>> Wenn bspw. 3,5V bedeutet "hight" (eins) sein soll, würden bei 3,3V oder
>> 3,6V noch ein "hight" vom entsprechenden Modul als "hight" verstanden?
>
> -1,0 V < Udiff < 0,5 V bedeutet High. Bei CAN heisst das "rezessiver
> Pegel"
> 0,9 V < Udiff < 5,0 V  bedeutet Low.  Bei CAN heisst das "dominanter
> Pegel".
>
> Udiff wird gemessen zwischen CAN_H (+) und CAN_L (-).

Perfekte Antwort, danke soul e.

Martin H. schrieb:
> Andreas K. schrieb:
>> Stimmen nun auf dem CAN die Pegel für dieses Frames nicht, dann fehlt
>> quasi die Meldung "Flüssigkeitsstand BF- Behälter ok" da nicht
>> interpretierbar.
>
> Warum sollten die denn nicht stimmen? Und warum nur für einen Frame?

Aufgrund von Leitungskapazitäten oder Induktivitäten, 
Überganswiderstände, Wackelkontakt, usw.

Dieser eine Frame dient nur als Beispiel zur Erklärung.
Aber in der Tat kommt bei mir im IPC (Cockpit) die Anzeige "BREAKE" für 
den Bruchteil einer Sekunde. Eine Ursache könnte niedriger Füllstand 
sein.

Martin H. schrieb:
> Dann fang doch mal an, nachzulesen, was Du misst/messen willst.
> CAN ist differentiell, also sollte die Messung auch differentiell sein.
> Single-Ended Messungen sind nur mäßig aussagekräftig.

Mir geht es "noch" nicht um das Messen. Ich gucke mir die Ausgabe des 
DSO an um Unregelmäßigkeiten zu sehen.
Wenn ich z.B. das ABS- Modul auf den SC (Sternstecker) stecke und das 
Bild im DSO ist dann nicht i.O. wird die Ursache dieses Modul/ Leitung 
sein.
Dann kann ich weiteres unternehmen.

Martin H. schrieb:
> Zudem sollte, um die Pegel beurteilen zu können, der Bus korrekt
> terminiert sein - "abgezogenes Kabel" klingt irgendwie nicht danach.

IPC und BCM waren noch an den SCs (es gibt 2. Einen im Fußraum 
Fahrerseite, den anderen auf der Beifahrerseite), deshalb terminiert. 
Sorry! Hatte ich nicht erwähnt

Andrew T. schrieb:
> Nun, das ist das kleinste Problem. Es geht recht unproblematisch mit dem
> 2K anal scope wie es der TO macht.
>  Schau hier:
> Youtube-Video "CAN-Bus Fehlerbilder - 500 kBaud Bus"

Vielen  Dank für den Link Andrew T.
Ich kenne alle 3 CAN-Bus Videos von Michael bereits.
Aber bei erneutem schauen ist mit aufgefallen, dass das linke Bild 
(l-IPC-BCM-connected) i.O. ist.
Allerdings ist mein Fehlerbild (IPC-BCM-DCM-connected) "natürlich" nicht 
dabei, ich muss immer was spezielles haben.

[Soul E. (Gast)]

Andreas K. schrieb:

> Aber bei erneutem schauen ist mit aufgefallen, dass das linke Bild
> (l-IPC-BCM-connected) i.O. ist.

Beider Bilder sind (vom Pegel her) i.O. Beim rechten Bild 
(IPC-BCM-DCM-connected.jpg) fehlt irgendwo eine Masseverbindung, da 
springt der Common Mode (d.h. die Spannung von CAN_H = CAN_L gegen 
Masse) ziemlich stark hin und her. Ist aber für die Funktion unkritisch, 
da nur die Differenz zwischen CAN_H und CAN_L ausgewertet wird.

[Andreas K. (altb)]

soul e. schrieb:
> Andreas K. schrieb:
>
>> Aber bei erneutem schauen ist mit aufgefallen, dass das linke Bild
>> (l-IPC-BCM-connected) i.O. ist.
>
> Beider Bilder sind (vom Pegel her) i.O. Beim rechten Bild
> (IPC-BCM-DCM-connected.jpg) fehlt irgendwo eine Masseverbindung, da
> springt der Common Mode (d.h. die Spannung von CAN_H = CAN_L gegen
> Masse) ziemlich stark hin und her. Ist aber für die Funktion unkritisch,
> da nur die Differenz zwischen CAN_H und CAN_L ausgewertet wird.

Vielen Dank soul e.
Deine Darstellung hilft mir enorm weiter!

[Martin H. (mahi)]

Andrew T. schrieb:
>> Dann fang doch mal an, nachzulesen, was Du misst/messen willst.
>> CAN ist differentiell, also sollte die Messung auch differentiell sein.
>> Single-Ended Messungen sind nur mäßig aussagekräftig.
>
> Nun, das ist das kleinste Problem. Es geht recht unproblematisch mit dem
> 2K anal scope wie es der TO macht.

Ja, es geht mit einem 2-Kanal-Scope, wenn man sich die Differenz der 
beiden Kanäle anzeigen lässt, was so ziemlich jedes Oszi kann.
Bei CAN-H und CAN-L gegen Masse sieht nur, ob der Bus im erlaubten 
Spannungsbereich der Transceiver bleibt und fertig.

Andrew T. schrieb:
> Kommt drauf an wo man Abzieht -- die Chancen, das der
> Terminierungswiderstand dran bleibt ist  ebenfalls hoch. Siehe Link
> oben.

Irgendein Youtube-Video ist bestimmt die verlässtlichste 
Informationsquelle, die es nur gibt ;)
Ja, wenn man nur eine ECU absteckt, ist ziemlich sicher, dass der Bus 
noch an anderer Stelle terminiert ist, da es üblicherweise (je nach 
Topologie) mehrere Teminierungs-Netzwerke am Bus gibt. Aber ob die 
Messung dann noch aussagekräftig ist, steht auf einem anderen Blatt.


An den TO: Die absoluten Pegel sagen wirklich sehr wenig aus - egal was 
andere hier oder auf Youtube behaupten. Solange die nicht irgendwo bei 
+/-12V sind, interessiert die ECU nur die Differenz der beiden 
Leitungen.
Lass Dein Oszi die Differenz der beiden Kanäle bilden und dann schau Dir 
mal ein paar Bits an, ob die "sauber" sind (wovon ich ausgehe). Ich 
bezweifle, dass Dein Problem wirklich auf der untersten Bus-Ebene zu 
suchen ist. Wenn der Bus wirklich physikalisch gestört wäre, würden 
höchstwahrscheinlich mehrere Lämpchen im Cockpit angehen.

Sporadische Fehler sind extrem schwer mit dem Oszi zu sehen - auf was 
soll man denn triggern, wenn man nicht weiß, wie die Störung aussieht. 
Da hilft nur loggen und auf "höherer Ebene" auswerten.

An Deiner Stelle würde ich erstmal den/die Fehlerspeicher auslesen 
(lassen). Wenn ein "Lämpchen" angeht (auch nur Kurz), dann ist auch ein 
Eintrag im Fehlerspeicher gelandet. Und der bleibt eine ganze Weile da 
drin, auch wenn das Lämpchen wieder aus geht. Da sieht man dann 
üblicherweise auch, warum das Lämpchen angegangen ist.

[Andreas K. (altb)]

Vielen Dank für deine Antwort Andrew T.

Martin H. schrieb:
> Irgendein Youtube-Video ist bestimmt die verlässtlichste
> Informationsquelle, die es nur gibt ;)
> Ja, wenn man nur eine ECU absteckt, ist ziemlich sicher, dass der Bus
> noch an anderer Stelle terminiert ist, da es üblicherweise (je nach
> Topologie) mehrere Teminierungs-Netzwerke am Bus gibt. Aber ob die
> Messung dann noch aussagekräftig ist, steht auf einem anderen Blatt.

Naja, ich habe zwar ein verläßliches CAN Wiring Diagram mit allen 
Modulen aber darauf ist nicht zu erkennen wo terminiert ist.
Ich kann nur sagen, dass wenn BMC und IPC vom Sternstecker ab sind der 
CAN tot ist.
Und soweit ich das nun mit Eurer Hilfe sagen kann sind die bisher 
gesichteten Frames ja i.O.

Martin H. schrieb:
> Lass Dein Oszi die Differenz der beiden Kanäle bilden und dann schau Dir
> mal ein paar Bits an, ob die "sauber" sind (wovon ich ausgehe). Ich
> bezweifle, dass Dein Problem wirklich auf der untersten Bus-Ebene zu
> suchen ist. Wenn der Bus wirklich physikalisch gestört wäre, würden
> höchstwahrscheinlich mehrere Lämpchen im Cockpit angehen.

Da kommen mir nun auch Zweifel. Ich musste eben ertmal fesstellen, dass 
nicht die Leitungen/ Steckverbindungen zu einem Modul das Problem sein 
könnte, da am Motorkabelbaum "herumgedoktort" wurde.
Es kommen allerdings mehrere Lämpchen im Cockpit.


Martin H. schrieb:
> Sporadische Fehler sind extrem schwer mit dem Oszi zu sehen - auf was
> soll man denn triggern, wenn man nicht weiß, wie die Störung aussieht.
> Da hilft nur loggen und auf "höherer Ebene" auswerten.

Was meinst Du genau mit "höherer Ebene"?
Durch Eure Erklärungen sind mir da noch eine paar Maßnahmen eingefallen.
Eine, auch wenn ich nicht viel davon erwarte wäre bei der Fahrt zum 
Zeitpunkt einer Meldung im IPC mal zu sehen wie die Frames da aussehen.

Martin H. schrieb:
> An Deiner Stelle würde ich erstmal den/die Fehlerspeicher auslesen
> (lassen). Wenn ein "Lämpchen" angeht (auch nur Kurz), dann ist auch ein
> Eintrag im Fehlerspeicher gelandet. Und der bleibt eine ganze Weile da
> drin, auch wenn das Lämpchen wieder aus geht. Da sieht man dann
> üblicherweise auch, warum das Lämpchen angegangen ist.

Leider sind die DTC unauffällig. Dafür kann es verschieden Gründe geben, 
z. Bsp.:
- Es wird unter bestimmten Umständen was im Fehlerspeicher abgelegt, 
bspw. mehrere Fahrzyklen hitereinander mit gleichem Fehler. Trifft bei 
mir allerdings zu.
- Möglicherweise stehen die Fehler nicht lange genug an. Dagen spricht, 
dass im Cockpit etwas angezeigt wird.
- Oder es sind keine Fehler. Z.B. die "BREAKE" Warnlampe die mit dabei 
ist, welches u.a. bedeutet das der Bremsflüssigkeitsstand zu niedrig 
ist.

BTW: Das IPC ist neu, d.h. ein vom OEM- Zulieferer remanufactured...

[Autsch (Gast)]

Möglicherweise kein Problem im Can, sondern ein Masseproblem im Cockpit?
Vielleicht auch nur der Anzeigeprozessor für das Cockpit?

[Martin H. (mahi)]

Andreas K. schrieb:
> Was meinst Du genau mit "höherer Ebene"?

Damit meine ich, nicht einzelne Bits/Pegel mit dem Oszi anzuschauen, 
sondern zumindest auf CAN-Frameebene (CAN Prüfsumme, DLC-, 
Stuff-Errors,...) oder noch weiter oben (Applikations-CRCs, 
Botschaftszähler) Untersuchungen anzustellen. Das erfordert allerdings 
die entsprechenden Tools und Informationen über Frameinhalte etc.

Autsch schrieb:
> Möglicherweise kein Problem im Can, sondern ein Masseproblem im Cockpit?
Wenn die Masse lange genug "weg" ist, dass etwas passiert (Neustart des 
µC) sollte sich das aber deutlicher zeigen (Lampentest, etc.).
Wenn die Masse nur kurz wackelt, ist die Frage auf was sich das 
auswirken könnte. Störungen in der Kommunikation sollten zuerst im 
Fehlerspeicher auftauchen, bevor Lämpchen angehen...

> Vielleicht auch nur der Anzeigeprozessor für das Cockpit?
Wenn da ein Serienfehler drin ist, sollte man den aber in den Weiten des 
Internets finden. "Bitkipper" sollten normalerweise über Prüfsummen 
abgesichert sein. Wenn da was nicht stimmt, kommt das Steuergerät (in 
dem Fall das Cockpit) nicht mehr aus dem Bootloader und man sieht 
garnichts.

Das das Problem nicht beim CAN liegt, meine ich auch. Ich tippe auf 
einen Sensor, der Müll liefert.

Welche Warnlampen außer "BRAKE" kommen denn eigentlich noch?
"BRAKE" in gelb oder rot?

Beispiel Raddrehzahlsensor verschmutzt oder kaputt: ESP greift ein ohne 
echten Grund, ESP meldet Fehler, Fehlermeldung ABS, Fehlermeldung 
Bremsen, Reifendrucküberwachung meckert... alles sporadisch und jede 
erdenkliche Kombination davon.

[Andreas K. (altb)]

Martin H. schrieb:
> Andreas K. schrieb:
>> Was meinst Du genau mit "höherer Ebene"?
>
> Damit meine ich, nicht einzelne Bits/Pegel mit dem Oszi anzuschauen,
> sondern zumindest auf CAN-Frameebene (CAN Prüfsumme, DLC-,
> Stuff-Errors,...) oder noch weiter oben (Applikations-CRCs,
> Botschaftszähler) Untersuchungen anzustellen. Das erfordert allerdings
> die entsprechenden Tools und Informationen über Frameinhalte etc.

Axo, ok. Ne, keine Chance.
1. Dazu fehlt mir das Know- How (noch).
2. Habe nur ein billig- Hantek DSO ohne Bus-Decoding.

Martin H. schrieb:
> Autsch schrieb:
>> Möglicherweise kein Problem im Can, sondern ein Masseproblem im Cockpit?
> Wenn die Masse lange genug "weg" ist, dass etwas passiert (Neustart des
> µC) sollte sich das aber deutlicher zeigen (Lampentest, etc.).
> Wenn die Masse nur kurz wackelt, ist die Frage auf was sich das
> auswirken könnte. Störungen in der Kommunikation sollten zuerst im
> Fehlerspeicher auftauchen, bevor Lämpchen angehen...

Danke Autsch!
Martin H. Ich habe noch ein "Service Shifter" Problem welches ich 
aktuell noch separat betrachte. Meist war ein Kabelproblem im Bereich 
Cockpit oder CAT die Ursache. Daher werde ich das IPC mal ausbauen und 
die Kabelbäume ansehen.

Martin H. schrieb:
> Autsch schrieb:
>> Vielleicht auch nur der Anzeigeprozessor für das Cockpit?
> Wenn da ein Serienfehler drin ist, sollte man den aber in den Weiten des
> Internets finden. "Bitkipper" sollten normalerweise über Prüfsummen
> abgesichert sein. Wenn da was nicht stimmt, kommt das Steuergerät (in
> dem Fall das Cockpit) nicht mehr aus dem Bootloader und man sieht
> garnichts.

Schwer zu sagen, allerdings ist das IPC neu (remanufactured) von Mopar, 
also Originalersatzteil. Deswegen würde ich das an letzte Stelle der 
Fehlersuche setzen.

Martin H. schrieb:
> Das das Problem nicht beim CAN liegt, meine ich auch. Ich tippe auf
> einen Sensor, der Müll liefert.

Ich eigentlich auch. Aber mir ist eingefallen das es bei der 
Durchführung eines Security Recalls bei dem 4 Module geflasht werden 
Probleme gab. Hierzu musste PCM, TCM, RFH und IPC nacheinander upgedatet 
werden. Zum Schluß dann das Update für das IPC dauert 2 Stunden und ist 
immer abgebrochen, bis PCM, TCM und RFH vom CAN getrennt wurden. Die 
drei Module sahen im DSO aber i.O. aus. Da mein Mutiplexer Probleme beim 
Verbindungsaufbau hat, werde ich die 3 Module mal vom CAN abnehmen und 
dann gucken ob der Mutiplexer sich sofort verbinden kann. Der ist 
scheinbar nicht so Fehlertolerant wie das vom Vertragshändler.

Martin H. schrieb:
> Welche Warnlampen außer "BRAKE" kommen denn eigentlich noch?
> "BRAKE" in gelb oder rot?

Ich habe momentan nur 2 Bilder, da ich ein Video drehen und dies dann in 
slomotion ansehen muß.
Bei dem einen ist BREAK (rot) und das ESP (orange), beim 2ten 
Lenkradsymbol (orange) zu sehen.
Interessant: Das Lenkradsymbol bedeute eine malfunction vom EPS 
(Electric Power Steering), welches im DSO vom Aussehen her einen Frame 
wie das DCO (Drive Train Control Modul) liefert (im obigen Bild, 
IPC-BCM-DCM-connected.jpg). Wie soul e. schrieb, eventuell ein 
Masseproblem welches ich mir noch ansehen werde.

Martin H. schrieb:
> Beispiel Raddrehzahlsensor verschmutzt oder kaputt: ESP greift ein ohne
> echten Grund, ESP meldet Fehler, Fehlermeldung ABS, Fehlermeldung
> Bremsen, Reifendrucküberwachung meckert... alles sporadisch und jede
> erdenkliche Kombination davon.

Ganz heiß Martin H., TPMS (Reifendruck) meckert auch manchmal, ESP und 
BREAKE (ABS). Den Sensor VA rechts habe ich getauscht, denn sah optisch 
anders aus als der Linke. Kabelbaum vom Sensor bis zum Motorkabelbaum 
optisch geprüft.

Die Prüfung der Frames habe ich bisher nur mit "Zündung an" 
durchgeführt.
Das mache ich noch mit laufendem Motor, bzw. beim Fahren!

Um die Storry komplett zu machen:
Der Wagen hatte einen Unfall vorn rechts und wurde instand gesetzt. Ist 
ca. 10000KM ohne Probleme gefahren. Dann kam erst "Service Shifter" (nun 
immer häufiger als im Winter) und das kurzzeitige aufblinken o.g. 
Symbole im Cockpit (IPC) bevor der o.g. Security Recall durchgeführt 
wurde.
Entsprechend habe ich vorn rechts mal alle Kabelbäume aufgemacht und 
Lötverbindungen getrennt, kalt verpresst und mit hochleitendem Lötzinn 
zusätzlich verlötet. Sowie für entdrillte CAN Leitungen die Pins aus dem 
Stecker gelöst und die Leitungen korrekt verdrillt.

Da Du Dich zu meiner Freude so für das Thema interessierst Martin
Das habe ich mir noch vorgenommen:
- Reifendruck Modul Stecker prüfen, zum Test abklemmen
- Module unter dem Fahrersitz Stecker prüfen
- PCM->TCM->RFH CAN von SC trennen -> DSO an OBD, Frames prüfen
- PCM->TCM->RFH CAN von SC trennen -> Mutiplexer an OBD
- OBD Versorgungsspannung mit DSO prüfen bei laufendem Motor
- BCM WH prüfen, Masse und 12V messen
- DCM + EPS Masseverbindung prüfen
- DCM + EPS CAN low mit DSO gegen PCM CAN low prüfen
- EPS (under right front of motor) Kabel messen, Stecker prüfen 
(+)dkblue/wht 1, (-)yel 2, SC C11
- EPS, mit Mutiplexer Signale von torque sensor und steering position 
sensor prüfen
- DCM (under driver seat) Masse und 12V messen, CAN messen, Stecker 
prüfen (+)wht 1, (-)dkgrn 2, SC C12
- DCM Test, Transfer Case Switch (via CAN -> DCM)  in verschiedene Modi 
stellen und IPC Bestätigung beobachten
- DCM + EPS am SC trennen, Mutiplexer an OBD, Verbnindungsaufbau?
- DCM + EPS am SC trennen, wenn möglich fahren
- DCM Sicherung (F94, F77 powers the DCM) prüfen
- DSO an OBD -> fahren bis Meldung in EVIC kommt dann Frames im DSO 
prüfen

Erledigt wurde:
- Leitungen zum Getriebe Leitung/ Stecker prüfen
- Radsensoren Stecker VA rechts prüfen  - neuer Sensor eingebaut
- Durchgang rechts Radkasten nach Innenraum prüfen/ abdichten
- Module unter dem Beifahrersitz Stecker prüfen
- Einzelne Teilnehmer abklemmen und Bus beobachten (SC)
- Zuleitung Lichtmaschine, Batterie
- Motormasse prüfen
- Kabelbaum vom PCM am Motor befestigt (Verlegung)? Ist am Motor und 
Karosserie befestigt
- PCM öffnen - neues PCM eingebaut
- Shifter öffnen, Stecker prüfen - Sichtprüfung WH bis Mittelkonsole, 
Messung (loop) 0,4Ohm
- Alle Leitungen von SCs -> einzeln aufstecken -> DSO prüfen (ohne IPC + 
BCM kein Signal)

[Martin H. (mahi)]

Andreas K. schrieb:
> Habe nur ein billig- Hantek DSO ohne Bus-Decoding.

Ich glaube, hier im Forum mal wsa von einem Open-Source CAN-Bus Tool 
gelesen zu haben. Ich weiß aber nicht, welche Hardware Du dafür 
bräuchtest. Vielleicht wäre das eine Möglichkeit...

[Andreas K. (altb)]

Martin H. schrieb:
> Andreas K. schrieb:
>> Habe nur ein billig- Hantek DSO ohne Bus-Decoding.
>
> Ich glaube, hier im Forum mal wsa von einem Open-Source CAN-Bus Tool
> gelesen zu haben. Ich weiß aber nicht, welche Hardware Du dafür
> bräuchtest. Vielleicht wäre das eine Möglichkeit...

Sowas wie CanKing, Busmaster, usw. Gibt es einige, aber man braucht eben 
ein Interface, welches ich "noch" nicht habe.

Ich dachte da an ein DSO mit CAN Decoder.
Denn ich habe ein paar Frames mit ca. 1,6V Udiff und einen kaputten 
Frame (siehe service_shifter_2_0diff.jpg) bei der Fahrt gefunden.
Dann würde ich mit DSO an OBD wieder fahren, die Adresse des defekten 
Frames notieren.
Im Stand mit allen Leitungen vom Star connector abziehen und eins nach 
dem anderen verbinden und wieder trennen, bis der Frame mit 
entsprechender Adresse erscheint. Dann kenne ich de n Teilnehmer und 
kann weiter prüfen.

Wenn ich ein CANUSB Interface mit entsprechender Software benutzen 
würde, dann sollte mir diese den defekten Frame ganz sicher auch melden?
Wenn ja, dann wäre es eine Alternative, da könnte ich wie mit DSO 
genauso verfahren.

Das Zweite was mir auffiel, die Masseverbindung der beiden SCs hat zur 
Karosseriemasse 90, bzw. 80 Ohm. Laut wiring diagamm soll dies aber zu 
unterschiedlichen Massepunkten (SCs_left_right.jpg) direkt auf die 
Karosserie gehen. Hmnnn...

Aber diese Woche noch kommt ein neues Shifter Modul was ich vor der 
Sichtung des defekten Frames bereits  bestellt hatte.
Vieleicht ist es ja zufälligerweise genau das. Ich denke das wird 
einbaufertig (geflushed) geliefert. Da keine Recalls durchgeführt wurden 
bei denen das Shifter Modul upgedated wurde sollte der Software- Stand 
passen.

[Andreas K. (altb)]

So, DSO mit CAN Decoder besorgt und gemessen.

Masse DSO an Signalmasse des OBD- Steckers, CAN high und low ebenfalls 
dort.

Alle Stecker vom star connector abgezogen bis auf IPC (Instrument Panel 
Control) und BCM (Body Control Module) sonst bewegt sich nix auf dem 
Bus.
Alle Frame Adressen in Excel notiert.
Jetzt PCM (Powertrain Control Module) aufgesteckt und die dazu 
gekommenen Frames notiert. PCM wieder ab und ESM (Electronik Shifter 
Module) aufgesteckt. Wieder die hinzu gekommenen Frames notiert, usw.

Es stellte sich heraus, dass fast allen Modulen kaputte Frames 
zuzuordnen war. Ledigtlich 2 Module waren i.O. oder auch nur Zufall?!
Dabei waren die o.g. auch BCM und IPC Module. Die beiden lassen sich 
aufgrund der unterschiedlichen Amplitude auseinander halten.
Auf dem Bild IPC-BCM.jpg kann man den "defekten" Frame (links) gut 
erkennen
Das erklärt die verschiedeste Fehler welche im IPC angezeigt werden und 
das Getriebe sporadisch runter schaltet weil vom ABS, ESL, usw. Modul 
nix valides kommt.

Die Kabelbäume im Motorraum wurden von irgend jemanden mal 
instandgesetzt. Entsprechend hatte ich die CAN- Leitungen durchgemessen, 
aber nun zur Sicherheit wurden beide Kabelbäume trotzdem getauscht.
Ohne Befund, wäre ja auch zu schön gewesen.

Nächste Woche kommt das BCM dran, welches als Gateway fungiert.
Dann sehen wir weiter...