Elmconfig und der modifizierte ELM327 mit HS/MS-CAN mit Facelift Modellen

Zitat von BBG-AE185

Was ich nicht ganz verstehe, hast Du die Konfig nach dem 1. auslesen nicht gespeichert?

Das erinnert mich an die Frage vom Arzt, warum man nicht gekommen ist als man noch gesund war. Im echten Leben ist es halt mal so, da machen Menschen Fehler. Manche lernen dabei, andere nicht. Manche haben Glück, andere nicht.

Wichtig ist, finde ich das wir mit unserem Wissen helfen konnten und das der Kollege was gelernt hat. Ich persönlich versuche mich vorab auch immer so gut es geht zu informieren, aber dennoch geht dann auch mal was daneben... und dann hab ich ja EUCH

Zitat von aneurysma

naja zu meinem elm noch habe diesmal beherzigt, den elm eine feste baudrate von 500000 einzustellen, damit diesmal nicht wieder was schief läuft, vielleicht war das auch der Auslöser des fehlerhaften schreibvorganes bzw. lesevorgang, schon vorm backup grüß René

Da wird viel zu viel bumhei drum gemacht. Entscheident ist das Timing auf dem CAN und ein vernünftiger Controller-Chip. Während der Programmierung ist die gesamte restliche Buskommunikation stillgelegt. Das ist ja auch der Grund für die ganzen DTCs, die man nach jeder Programmierung wieder löschen muss. Für die Übertragung des wenige Kilobyte grossen Bootloaders und den anschliessenden 255 Byte CCC Datensatzes wäre auch ein RS232 Trampelpfad mehr als ausreichend.

Das Problem ist nicht die Bandbreite zwischen Adapter und Computer, sondern das Timing der Pakete. Und hier kommt der Treiber ins Spiel, der fast die wichtigste Rolle einnimmt. Hier jetzt alle Aspekte davon zu beleuchten würde zu weit führen. Nur soviel, das man
mit einem VCP fähigen Treiber selten falsch liegt.

Danach kommt gleich der Chipsatz vom Adapter. Nur weil ELM drauf steht, ist noch lange kein ELM drin. Ich glaube die wenigsten hier haben einen Adapter mit original Chipsatz. Bei schlecht gemachten kopien und aufbau der Hardware (kalte Lötstellen, Zinnreste auf der Platine, billigste Chips und Bauteil mit hohen Toletanzen) kommt es halt zu diesen Übertragungsproblemen.

Aber auch der verwende PC, meist ein Laptop tut dasseine. Zwar dürfte für die popelige Fahrzeugkommunikation praktisch alles ab Pentium ausreichen. Wenn aber während der programmierens irgendwelche anderen Programme die CPU für sich beanspruchen, kann es ganz schnell zu eng werden. Von daher ist die Idee von Spike mit einem gut abgestimmten Gesamtpaket zum ausleihen gut gedacht.

Zitat von Go4IT

Im echten Leben ist es halt mal so, da machen Menschen Fehler.

Deshalb ja meine Frage. Der Thread ist ja nun 45 Seiten lang, nicht jeder ließt ihn komplett.
In dem Zusammenhang wäre es interessant zu wissen ob ein Lesevorgang ohne Fehlermeldungen eine valide Konfig sicherstellt. Im Moment verlasse ich mich (wie alle anderen auch) ja darauf das die gespeicherten Konfigs valide sind. Sollte der Lesevorgang nicht abgesichert sein bringt das ja ein zusätzliches Risiko

Zitat von BBG-AE185

In dem Zusammenhang wäre es interessant zu wissen ob ein Lesevorgang ohne Fehlermeldungen eine valide Konfig sicherstellt. Im Moment verlasse ich mich (wie alle anderen auch) ja darauf das die gespeicherten Konfigs valide sind. Sollte der Lesevorgang nicht abgesichert sein bringt das ja ein zusätzliches Risiko

Sehr gute Frage! Es ist ja so:
Gegen Bitfehler bei der Übertragung auf dem CAN-Bus schützt eigentlich das Protokoll selbst. ABER, das ist eine Frage der Umsetzung dieses. Im Falle eines ELM-Adapters, egal ob original oder clone, ist das CAN-Protokoll im Chip über die Software implementiert. Ein ELM327 ist ja im grunde nichts anderes als ein programmierter PIC Mikrokontroller. Der enthält keine spezielle Hardwareunterstützung für CAN, wie es z.B. bei bestimmten Atmega uC's der Fall ist. Sicher hat ELM auch die CRC-Routinen implementiert, ob das aber auch in gänze für die Software der Clones gilt kann nicht sichergestellt werden. Das müsste man testen, durch geziehlt falsche Pakete auf dem Bus und schauen wie der ELM-Adapter reagiert. Diesen Test hat aber dann nur Aussagekraft für den einen getesteten Adapter. Auch einen Rückschluß auf die Serie würde, angesichts der produktionumstände nicht folgern. Hier wäre also die erste, mögliche Fehlerquelle.

Gegen Datenfehler der CCC "schützt" (naja...) die Prüfsumme derselben. Da sie eine einfache Additionssumme ist, natürlich nicht gegen vertauschte Bytes oder zufällig wertgleiche Fehler. Hierzu müsste eine ECHT Prüfsumme (z.B. MD5) enthalten sein. Hier müsste man abklären, ob ELMConfig diese Prüfsumme beim einlesen kontrolliert. Um jetzt erstmal die Simulation eines BCM-Lesevorganges zu ersparen habe ich folgende Annahme gemacht: Das Laden einer CCC aus einer Datei verwendet die gleiche Überprüfungs- und Verarbeitungsfunktion wie das laden aus dem BCM/IPC. Dann habe ich eine intakte CCC kopiert und darin das Checksum-Byte durch einen beliebigen Wert geändert. Das erwartete Verhalten beim laden wäre also eine Fehlermeldung. Zu meiner Überraschung kam keine. Die CCC wurde geladen als wenn nichts wär. Durch erneutes abspeichern und Vergleich konnte ich erkennen, das die richtige Checksumme wieder eingesetzt wurde. Damit wäre für mich zumindest bewiesen, das ELMConfig die Prüfsumme beim lesen einer CCC nicht berücksichtigt. Für mich ein klarer Bug. Wenigstens ein Hinweis wäre angebracht das möglicherweise eine defekte CCC geladen wurde und ob man diese, zu Reparaturzwecken dennoch bearbeiten möchte.

Was folgern wir daraus? Es ist grundsätzlich möglich völligen Quatsch als CCC zu lesen. Schlimmer noch, beim abspeichern eines vermeintlich konsistenten Backups wird die Checksumme für diesen Quatsch auch noch korrekt berechnet. Dadurch ist es möglich die CCC seines Fahrzeugs zu killen, obwohl man alles richtig gemacht hat!

Was lernen wir daraus? Zum konsistenten auslesen sollte man über einen CAN-Adapter verfügen, welcher das CAN-Protokoll hundertprozentig implementiert. Hier würde ich ausschließlich einem Hardware-Controller vertrauen, z.B. einem Atmega-Chip mit integriertem Controller, oder einen per SPI angebundenen wie z.B. dem MCP2515. Damit sind Übertragunsfehler ausgeschlossen.
Desweiteren würde ich die CCC nicht direkt im ELMConfig laden, sondern mit einer eigenen Software die mir auch die Prüfsumme korrekt verifiziert. Erst dann würde ich diesen Daten vorbehaltlos vertrauen.

Das habe ich auch.

Wollte jetzt mal das erste Mal mit Forscan den Fehlerspeicher auslesen, damit ich weiß, welcher Parkpieper hinüber ist. Aber ich krieg das ums Verrecken nicht verbunden.

Hab extra nochmal ein sauberes Windows 7 neu installiert und dann die CH340-Treiber installiert, da mein ELM diesen Wandler hat. Hab aber immer ein gelbes Ausrufezeichen im Gerätemanager mit der Meckermeldung, dass der Treiber nicht signiert ist. Wenn ich dann Forscan starte und auf 9600 oder 38400 Baud und Com3 stelle, wie es der Anschluß auch vorgibt, dann bekomme ich trotzdem keine Verbindung.

Hab auch Spikes Helpertool ausprobiert, das läuft auch fehlerfrei durch, aber trotzdem keine Verbindung.

Hat jemand einen Plan, was ich da falsch mache?
Muß der ELM am Auto angeschlossen sein, damit er ihn erkennt? Wobei ich auch das schon versucht habe, klappt aber trotzdem nicht.

OK, ich hak mal direkt nach, denn ich habe es hinbekommen. Dachte, ich tu mir einen Gefallen und nehm Windows 7, aber nix ging. Bin dann mal an mein Hauptnotebook /Thinkpad T520) mit Windows 10 und zack, ohne Jonglieren einfach die Treiber installiert, die Windows vorgeschlagen hat und sofort Verbindung bekommen:

Und jetzt weiß ich, wer der Übeltäter ist:

===PAM DTC B1B40:96-27===
Code: B1B40 - Sensor vorne links außen.

Weitere Fehlersymptome:
- Interner Bauteilfehler

Status:
- DTC vorhanden zum Zeitpunkt der Anfrage
- Fehlfunktions Indikator Lampe ist AUS für diesen DTC

Modul: Einparkhilfe

Und das hat dir ELMConfig nicht gesagt? Kann ich kaum glauben.
Ja, grundsätzlich ist ForScan das deutlich fortschrittlichere Programm, aber aus meinen PAM-Experimenten weiß ich, das diese Fehler dort ganz genauso angezeigt werden. Wichtig ist halt und da bin ich auch erst viel später drauf gekommen, das man den DTC-Code im Fenster per Doppelklick öffnet. Dann erhält man zusätzliche Informationen.

Dafür hättest Du noch nichtmal ELM gebraucht;-) Der Code "B1B40" steht auch so in den offiziellen Code-Tabellen, z.b. bei mir im Wiki DTC Fehlercodes B... im Bereich der DTC-Fehler.
Die "96" ist die Fehlerursache und laut Liste wirklich so allgemein ein "Component internal failure".
Die letzte Ziffer erklärt niemand, weil es Ford- und Modulspezifisch ist. Hier weiss u.U. ein IDS mehr. Ich kenne hier bei den PAM-Sensoren nur den "2C".

Kannst den ja einfach mal tauschen und schauen ob der Fehler wandert. Zu 99% sind die Sensoren heile und die Stecker/Kabel haben einen Hau. Die Sensoren sind nämlich nahezu unverwüstlich. Falls es doch der Sensor ist, oder Du den tauschst, darf ich Dich um den vermeintlich defekten bitten? Ich würde nämlich gern mal einen aufmachen

P.S.: Das mit dem Treiberproblem kenne ich sonst nur umgekehrt. Windows 10 ist da viel strikter was die Signierung, also das gültige Entwicklerzertifikat eines Treibers angeht.

Mit ELMConfig hab ich es gar nicht versucht, das bekam ja auf dem alten NB auch keine Verbindung. Forscan war schneller installiert, da ich da keine Runtimes und nix brauche. Mit ELM rumprogrammieren, da hab ich irgendwie so ganz alleine schon etwas Bammel vor, da ich mir nix zerschießen will.

Ich mach den linken äußeren PDC-Sensor mal raus, habe auch noch zwei da liegen aus der Zeit, als ich meine Stoßstange kaputt hatte, damit teste ich es mal. Was mich nur wundert, ist dass der Dauerpiepton von hinten kommt, obwohl laut DTC der vordere Sensor defekt ist. Na, mal sehen, das schaue ich mir morgen mal an, sofern es nicht regnet. Da muß ja der Nebelscheinwerfer raus für.

Naja, bei Windows 10 gab es nix zu signieren, da er ja seinen eigenen Treiber genommen hat und ich keinen externen installieren musste. Da habe ich dann scheinbar das Glück gehabt, dass Spike mir damals den ELM mit dem CH340 geschickt hat, denn dessen Treiber kennt Windows 10 augenscheinlich.

Klar, wenn sich ein Sensor als defekt herausstellt, kannste den gerne schlachten.

Zitat von Go4IT

Falls es doch der Sensor ist, oder Du den tauschst, darf ich Dich um den vermeintlich defekten bitten? Ich würde nämlich gern mal einen aufmachen

Off Topic.

Da du ja Jäger und Sammler bist , könnte ich dir ein paar Lenkradtasten anbieten, sind halt hinten die Schraubenlöcher ausgebrochen, hat wohl ein Grobmotoriker versucht ohne die Schrauben zu lösen vom Lenkrad zu bekommen.
( Ich war es nicht, bevor es hier losgeht modo )die kannst du gerne haben.

Wolltest doch meine ich die Widerstandswerte aufnehmen, wenn ich mich recht entsinne.

Zitat von digdog

Da du ja Jäger und Sammler bist , könnte ich dir ein paar Lenkradtasten anbieten... Wolltest doch meine ich die Widerstandswerte aufnehmen, wenn ich mich recht entsinne.

Coole Sache! Die nehm ich gerne. Genau, wollte die zerlegen, Bilder machen, Artikel schreiben, ausmessen, mit rumspielen und so. Goldrichtig für meine Zwecke! Ich danke Dir!!!
Schick mir über mein Profil eine EMail mit nem PayPal-Konto, dann schick ich Dir nen kleinen Obulus für Versand, Verpackung und Mühe.

Zitat von ArthurDaley

Mit ELMConfig hab ich es gar nicht versucht, das bekam ja auf dem alten NB auch keine Verbindung. Forscan war schneller installiert, da ich da keine Runtimes und nix brauche. Mit ELM rumprogrammieren, da hab ich irgendwie so ganz alleine schon etwas Bammel vor, da ich mir nix zerschießen will.

Naja... so schlimm ist es schon nicht. Zumindest wenn man die erste Grundregel der IT beachtet: "Save early, save often", also immer schön mit Backup.

Zitat von ArthurDaley

Ich mach den linken äußeren PDC-Sensor mal raus, habe auch noch zwei da liegen aus der Zeit, als ich meine Stoßstange kaputt hatte, damit teste ich es mal. Was mich nur wundert, ist dass der Dauerpiepton von hinten kommt, obwohl laut DTC der vordere Sensor defekt ist. Na, mal sehen, das schaue ich mir morgen mal an, sofern es nicht regnet. Da muß ja der Nebelscheinwerfer raus für.

Ich habe das noch nie gemacht. Hinten ist es wohl von der Zugänglichkeit deutlich einfacher.
Wär nett wenn Du danach berichtest wie man die wechselt!
Der Dauerpiepton müsste begleitet werden von 6 Blinksignalen im PDC-Schalter. Das ist der normale, allgemeine Hinweis des PAMs an den Fahrer "ACHTUNG, ich bin kabott!"
Der Ton kommt entweder aus dem hinteren oder dem vorderen Lautsprecher wenn der hintere kaputt ist. Ist also ganz normal.

Zitat von ArthurDaley

Naja, bei Windows 10 gab es nix zu signieren, da er ja seinen eigenen Treiber genommen hat und ich keinen externen installieren musste. Da habe ich dann scheinbar das Glück gehabt, dass Spike mir damals den ELM mit dem CH340 geschickt hat, denn dessen Treiber kennt Windows 10 augenscheinlich.

CH340 ist nicht in Windows enthalten, in keinem. Ist China-Gammelware
Die hatten aber, ähnlich wie beim original FTDI-Treiber auch mal Probleme wegen geänderter USB-PIDs.
Egal, hauptsache es klappt jetzt bei Dir. Das ELMConfig kannste Dir dann vielleicht mal auf dem anderen Laptop installierten.

Zitat von ArthurDaley

Klar, wenn sich ein Sensor als defekt herausstellt, kannste den gerne schlachten.

Juchu, heut ist mein Glückstag, erst Du dann DigDog
Gleiches Angebot gilt natürlich für Dich, wobei so ein Sensor sicher in einem Briefumschlag platz hat...

Zitat von Go4IT

dann schick ich Dir nen kleinen Obulus für Versand, Verpackung und Mühe.

Schick mir einfach deine Adresse per PN, Versand kann ich mir noch Leisten, fahr schliesslich einen 2,5 er vain

Wir müssen dich ein wenig unterstützen, ich warte ja noch auf den Fluxkompensator aus der Bastelecke
das wir Henry Ford mal besuchen können.

Zitat von digdog

Wir müssen dich ein wenig unterstützen, ich warte ja noch auf den Fluxkompensator aus der Bastelecke das wir Henry Ford mal besuchen können.

Da bin ich dran. Aber Du weißt das Zeitreisen extrem gefährlich sind. Ein kleiner Fehler und schwub, werden aus allen unseren schönen Mondis plötzlich... Fiats... oder Dacias... oder noch schlimmer... BMWs oder Schummel-VWs

Der Ton kommt entweder aus dem hinteren oder dem vorderen Lautsprecher wenn der hintere kaputt ist. Ist also ganz normal.
Da muss ich auch nochmal nachhaken: Es ist also normal, dass es hinten piept, wenn vorne der Sensor defekt ist? Weil das ist die Situation laut DTC.

Ich will auch nix dafür, wenn ein Sensor sich als defekt herausstellt, dann kriegste den auch für lau.

O-Ton ETIS

"Der Lautsprecher der hinteren Einparkhilfe wird zur
akustischen Anzeige verschiedenen Fehlerarten in der vorderen und
hinteren Einparkhilfe verwendet. Wenn der Lautsprecher der hinteren
Einparkhilfe defekt ist, wird der vordere Lautsprecher der Einparkhilfe
zur akustischen Anzeige der Fehlerarten verwendet. "

Na, da lag ich doch mit meinem selbsterarbeitetem Wissen garnicht so schlecht
P.S.: Ich fürchte es wird langsam Off-Topic. PAM-Themen diskutieren wir bessern im dafür vorgesehenen Thread weiter, sonst gibts Hause vom Marc...

Danke Euch, das passt ja.