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
Du schreibst in Hieroglyphen... Das Photo zeigt Probleme...
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.
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. 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...
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 (-).
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.
:
Bearbeitet durch User
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.
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.
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.
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!
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.
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...
:
Bearbeitet durch User
Möglicherweise kein Problem im Can, sondern ein Masseproblem im Cockpit? Vielleicht auch nur der Anzeigeprozessor für das Cockpit?
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.
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)
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...
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.
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.