Servus, ich probiere grad ein wenig rum und habe mir einen Diagnose Tester mit einem ELM 327 und einem User Interface gebastelt/ programmiert. Nun zu meiner Frage ich kann egal was ich mache das UDS-Protokoll nicht anwenden, aber wieso? Die OBD 2 Funktionen wie 07 für Fehlerspeicher auslesen oder 0105 für Kühlmitteltemperatur funktionieren einwandfrei, allerdings egal was ich gemäß UDS-Protokoll verwende z.B. 1902 für Fehlerspeicher abfragen nichts funktioniert. Kann der ELM 327 das UDS-Protokoll einfach nicht verwenden oder ist dies ein Eingabe Fehler? Danke für jede Hilfe!
Christian schrieb: > Eingabe Fehler? Kannst du feststellen, ob dein ELM327 ein Klon ist? Und dann probiere mal den RDID 22 F1 86 "Read Active Diagnostic Session". Kommt eine Response? Christian schrieb: > allerdings egal was ich gemäß UDS-Protokoll verwende z.B. 1902 für > Fehlerspeicher abfragen nichts funktioniert. Kommen Negative Response Codes (NRC)? Wenn ja, welche? (Die haben immer das Format 7F xx xx) Für die UDS Fehlerspeicher-Services 19 und 14 muss man in die OEM extended Session gehen. Das geht mit Session Service 10. In dem Fall mal 10 03 voraus schicken. Außerdem muss der Client ohne Kommunikation den TesterPresent Service 3E bedienen, um den Session-Timeout zurückzusetzen und somit die Session offen zu halten. (Also schön 3E 00 rein ballern.) Viel Erfolg! mfg mf PS Christian schrieb: > Die OBD 2 Funktionen wie 07 für Fehlerspeicher auslesen oder 0105 für > Kühlmitteltemperatur Das sind OBD "modes", also alles unter Hex 10, somit nix UDS. Daher meine Vermutung dass es ein Klon ist, der nur OBD weitergibt aber nicht UDS...
:
Bearbeitet durch User
Danke für deine Antwort! Achim M. schrieb > Kannst du feststellen, ob dein ELM327 ein Klon ist? Einen Klon würde ich ausschließen, diesen hab ich von Sparkfun erworben. https://www.sparkfun.com/products/9555 > Und dann probiere mal den RDID 22 F1 86 > "Read Active Diagnostic Session". > Kommt eine Response? Die Eingabe werde ich morgen gleich mal ausprobieren! > Kommen Negative Response Codes (NRC)? > Wenn ja, welche? > (Die haben immer das Format 7F xx xx) Egal was ich bisher eingegeben habe es kam bis jetzt keine Rückmeldung > Für die UDS Fehlerspeicher-Services 19 und 14 muss man in die OEM > extended Session gehen. Das geht mit Session Service 10. In dem Fall mal > 10 03 voraus schicken. Also 10 03 und im Anschluss z.B. 19 02 richtig? So habe ich es nämlich noch nicht probiert. > Außerdem muss der Client ohne Kommunikation den TesterPresent Service 3E > bedienen, um den Session-Timeout zurückzusetzen und somit die Session > offen zu halten. (Also schön 3E 00 rein ballern.) Das heißt im Beispiel 19 -> erst 10 03 dann 3E 00 und dann 19 02 richtig? Ein originaler ELM 327 ist sicher mit UDS kompatibel oder? Ist ja im Endeffekt nur ein Frage Antwort Spiel.
Christian schrieb: > Das heißt im Beispiel 19 -> erst 10 03 dann 3E 00 und dann 19 02 > richtig? Erst 10 03, dann 19 02. Und wenn man nix senden will oder deine UI auf Eingaben wartet, 3E 00 alle halbe Sekunde oder so. Sonst müsste vor jedem 19er ein 10er gesendet werden. Ist kompliziert, aber die ISO14229 lesen ist auch kein Spaß... Keine NRCs machen mich aber schon stutzig. Christian schrieb: > Ein originaler ELM 327 ist sicher mit UDS kompatibel oder? Ist ja im > Endeffekt nur ein Frage Antwort Spiel. https://www.elmelectronics.com/products/ics/obd/ Ich sehe kein ISO14229 also kein UDS. I don't know... KWP2000 geht - damit z.B. alle UDS RDIDs die in Single-Frame-Responses passen. Ich kann mir vorstellen, dass jegliche Requests als AT implementiert sein müssen. Umständlich. Wäre an sich schön wenn der einen "transparent mode" hätte... mfg mf
:
Bearbeitet durch User
Achim M. schrieb: > Erst 10 03, dann 19 02. Und wenn man nix senden will oder deine UI auf > Eingaben wartet, 3E 00 alle halbe Sekunde oder so. Sonst müsste vor > jedem 19er ein 10er gesendet werden. Ist kompliziert, aber die ISO14229 > lesen ist auch kein Spaß... Ich habe die ganzen Eingabecodes probiert, leider keinerlei Rückmeldung. Ich gehe davon aus, dass der Mikrocontroller die Eingabe einfach nicht versteht.(nicht kompatibel ist) > Ich sehe kein ISO14229 also kein UDS. Wüsstest du einen Mikrocontroller der dieses Protokoll ab kann? oder werden solche Probleme softwareseitig gelöst und die Hardware ist "egal"? Ich hab jetzt auch nochmal weitere Eingaben probiert wie 24 F190 für VIN-Abfrage, aber auch hier nichts ... Danke vielmals :)
Der ELM327 hat meines Wissens nur beim Empfang ISO-TP Unterstützung.
Beim Senden muss man sich selber darum kümmern, bei Messages mit weniger
als 8 Byte also die Länge davor schreiben ("03 22 F1 86" anstelle "22 F1
86").
Bei 8 Byte und länger kommt noch die Fragmentierung dazu.
:
Bearbeitet durch User
Dieter S. schrieb: > Der ELM327 hat meines Wissens nur beim Empfang ISO-TP Unterstützung. Gut zu wissen. Danke! Christian schrieb: > 24 F190 für VIN-Abfrage, Das ist auch ein 22er. Ganz sicher. Nach neuesten Erkenntnissen also 03 22 F1 86 ReadActiveDiagSession 03 22 F1 90 ReadVIN Wundert mich aber, dass man den ISO-TP Vorspann (Länge) bei den OBD-Modes nicht angeben muss. mfg mf
Da ich die ELM327 Adapter normalerweise nicht verwende habe ich es schnell mal ausprobiert: Das AT-Kommando AT CAF0 bzw. CAF1 entscheidet ob man das Längenbyte bei ISO-TP mit angeben muss (bei CAF0).
Christian schrieb: > Servus, > > ich probiere grad ein wenig rum und habe mir einen Diagnose Tester mit > einem ELM 327 und einem User Interface gebastelt/ programmiert. Nun zu > meiner Frage ich kann egal was ich mache das UDS-Protokoll nicht > anwenden, aber wieso? > Die OBD 2 Funktionen wie 07 für Fehlerspeicher auslesen oder 0105 für > Kühlmitteltemperatur funktionieren einwandfrei, allerdings egal was ich > gemäß UDS-Protokoll verwende z.B. 1902 für Fehlerspeicher abfragen > nichts funktioniert. Kann der ELM 327 das UDS-Protokoll einfach nicht > verwenden oder ist dies ein Eingabe Fehler? > > Danke für jede Hilfe! hast Du daran gedacht dass Du im Normalfall andere CAN Identifier für UDS Kommunikation mit den ECUs nutzen musst?
Dieter S. schrieb: > Der ELM327 hat meines Wissens nur beim Empfang ISO-TP > Unterstützung. > > Beim Senden muss man sich selber darum kümmern, bei Messages mit weniger > als 8 Byte also die Länge davor schreiben ("03 22 F1 86" anstelle "22 F1 > 86"). > > Bei 8 Byte und länger kommt noch die Fragmentierung dazu. Danke für deine Idee, allerdings auch hier kein Erfolg mit der Eingabe 03 22 F1 86. Weder eine Reaktion noch ein Errorcode. Dieter S. schrieb: > Da ich die ELM327 Adapter normalerweise nicht verwende habe ich es > schnell mal ausprobiert: Das AT-Kommando AT CAF0 bzw. CAF1 entscheidet > ob man das Längenbyte bei ISO-TP mit angeben muss (bei CAF0). Wie kann man rausfinden welches Kommando man hat? Chris R. schrieb: > Christian schrieb: >> Servus, >> >> ich probiere grad ein wenig rum und habe mir einen Diagnose Tester mit >> einem ELM 327 und einem User Interface gebastelt/ programmiert. Nun zu >> meiner Frage ich kann egal was ich mache das UDS-Protokoll nicht >> anwenden, aber wieso? >> Die OBD 2 Funktionen wie 07 für Fehlerspeicher auslesen oder 0105 für >> Kühlmitteltemperatur funktionieren einwandfrei, allerdings egal was ich >> gemäß UDS-Protokoll verwende z.B. 1902 für Fehlerspeicher abfragen >> nichts funktioniert. Kann der ELM 327 das UDS-Protokoll einfach nicht >> verwenden oder ist dies ein Eingabe Fehler? >> >> Danke für jede Hilfe! > > hast Du daran gedacht dass Du im Normalfall andere CAN Identifier für > UDS Kommunikation mit den ECUs nutzen musst? Verstehe nicht ganz was du meinst, spielt es eine Rolle bei der Eingabe? Möchte ja z.B. nur den Fehlerspeicher aller Stg. auslesen. Die sollte ja z.B. mit 10 03 19 02 möglich sein.
Ich habe ja auch noch mal kräftig recherchiert und hab mir mal das Datenblatt von dem ELM 327 ganz genau durchgelesen. Hier wird in keinerlei Hinsicht über UDS gesprochen. https://www.elmelectronics.com/ic/elm327/ Im Gegensatz zum ELM 329 hier wird im Datenblatt sehr wohl von den UDS-Befehlen gesprochen, noch dazu darüber, dass der Controller periodische Befehle sendet was der ELM 327 nicht kann. Das periodische Senden ist doch wichtig um die Diagnosesitzung aufrecht zu erhalten oder liege ich hier ganz falsch? Danke wirklich für jede Hilfe bin schon am verzweifeln. ^^
Achim M. schrieb: > Das sind OBD "modes", also alles unter Hex 10, somit nix UDS. Daher > meine Vermutung dass es ein Klon ist, der nur OBD weitergibt aber nicht > UDS... Servus Achim, ich hab mir hierzu nochmal Gedanken über meine Hardware gemacht, ich dachte ich habe einen ELM 327. Ich habe mir nämlich bei SparkFun dieses Teil gekauft und vermeintlich gedacht es ist ein ELM 327. https://www.sparkfun.com/products/9555 Es ist gar keiner, kann das Problem daran liegen?
>> hast Du daran gedacht dass Du im Normalfall andere CAN Identifier für >> UDS Kommunikation mit den ECUs nutzen musst? > > Verstehe nicht ganz was du meinst, spielt es eine Rolle bei der Eingabe? > Möchte ja z.B. nur den Fehlerspeicher aller Stg. auslesen. Die sollte ja > z.B. mit 10 03 19 02 möglich sein. Bei OBD sind die Identifier die auf dem CAN zur Kommunikation verwendet werden fix, d.h. du kannst auf der 0x7DF - das ist der funktionale Request für OBD - alle OBD Master auffordern auf ihren eigenen OBD Identifiern ihre Fehlerspeicher zurückzuschicken. Bei UDS wird ein anderer Identifier die auf dem CAN zur Kommunikation verwendet, gerne z.B. der 0x700 für den funktionalen Request. Die Steuergeräte antworten dann auch wieder auf ihren (UDS) Identifiern. Ob ein Steuergerät überhaupt auf einen SID 19 auf dem funktionalen Request reagiert oder nicht ist bei UDS herstellerabhängig. Es kann auch gut sein dass man das Steuergerät mit seinem eigenen Request Identifier direkt anfragen muss damit ein SID 19 überhaupt geht. Wenn Du auf dem 0x7FD UDS statt OBD SID schickst passiert gar nichts weil die Steuergeräte bei funktionaler Anfrage keine negative Response schicken und die SID-Bereiche zwischen UDS und OBD unterschiedlich sind.
:
Bearbeitet durch User
Christian schrieb: > > Im Gegensatz zum ELM 329 hier wird im Datenblatt sehr wohl von den > UDS-Befehlen gesprochen, noch dazu darüber, dass der Controller > periodische Befehle sendet was der ELM 327 nicht kann. Das periodische > Senden ist doch wichtig um die Diagnosesitzung aufrecht zu erhalten oder > liege ich hier ganz falsch? Was der ELM327 kann ist die Unterstützung von ISO-TP, darauf baut UDS auf. Beim Senden von kurzen Messages (kürzer als 8 Byte) ist ISO-TP aber im Prinzip nur das zusätzliche Längenbyte am Anfang. Zu der Diagnosesitzung und periodisches Senden: Eine Antwort auf UDS "Tester Present" sollte man immer bekommen, auch das Auslesen des Fehlerspeicher geht normalerweise. Allerdings muss man die richtige CAN-ID schicken, die zum gewünschten Steuergerät gehört, das man ansprechen will. Und es muss natürlich auch sichergestellt sein dass die Antwort auch angezeigt wird (der ELM327 zeigt ja je nach EInstellung nur bestimmte empfangene CAN-IDs an).
Christian schrieb: > Ich habe ja auch noch mal kräftig recherchiert und hab mir mal das > Datenblatt von dem ELM 327 ganz genau durchgelesen. Hier wird in > keinerlei Hinsicht über UDS gesprochen. > https://www.elmelectronics.com/ic/elm327/ > > Im Gegensatz zum ELM 329 hier wird im Datenblatt sehr wohl von den > UDS-Befehlen gesprochen, noch dazu darüber, dass der Controller > periodische Befehle sendet was der ELM 327 nicht kann. Das periodische > Senden ist doch wichtig um die Diagnosesitzung aufrecht zu erhalten oder > liege ich hier ganz falsch? > > Danke wirklich für jede Hilfe bin schon am verzweifeln. ^^ AT SH ist Dein Freund. Für UDS musst Du dem ELM327 schon sagen was er genau senden soll und die Antwort dann selber parsen.
Dieter S. schrieb: > Zu der Diagnosesitzung und periodisches Senden: Eine Antwort auf UDS > "Tester Present" sollte man immer bekommen, Was soll bitte auf Testerpresent bei UDS als Antwort kommen? Heute haben fast alle OEM suppress positive response als Standard vorgegeben wenn eine Tester Present kommt, egal ob es explizit angefordert wird oder nicht.
Fangen wir mal am anderen Ende an: Was ist denn dein Gegenpart? Kann das Teil UDS?
Chris R. schrieb: > > Wenn Du auf dem 0x7FD UDS statt OBD SID schickst passiert gar nichts > weil die Steuergeräte bei funktionaler Anfrage keine negative Response > schicken und die SID-Bereiche zwischen UDS und OBD unterschiedlich sind. Wie kann ich den zwischen UDS und OBD switchen? 0x7FD muss doch anhand der SID immer OBD 2 Protkoll sein und ab 10 UDS oder? Krubkj L. schrieb: > Fangen wir mal am anderen Ende an: Was ist denn dein Gegenpart? > Kann das > Teil UDS? Danke für deine Teilnahme ^^ wenn du die Hardware meinst ist es dieses https://www.sparkfun.com/products/9555 oder die Anwendung? Die habe ich weitestgehend selbst programmiert.
Christian schrieb: >> Wenn Du auf dem 0x7FD UDS statt OBD SID schickst passiert gar nichts >> weil die Steuergeräte bei funktionaler Anfrage keine negative Response >> schicken und die SID-Bereiche zwischen UDS und OBD unterschiedlich sind. > > Wie kann ich den zwischen UDS und OBD switchen? 0x7FD muss doch anhand > der SID immer OBD 2 Protkoll sein und ab 10 UDS oder? nein eben nicht. Das Spiel funktiniert anders rum bei den meisten OEM, es gibt Identifier-Pärchen für Kommunikation nach OBD und andere für die Kommunikation mit UDS um beide Welten sauber zu trennen. UDS ist ja nicht einfach ein erweitertes OBD sondern eine komplett eigene Welt. Um da Probleme zu vermeiden trennt man gerne von vorneherein die verwendeten CAN IDs für beide Protokolle. 0x7FD ist immer OBD weil das im OBD2 Standard gesetzlich so gefordert ist, genauso die jeweiligen SID für OBD. Die UDS SID haben mit den OBD SID auch nichts zu tun ausser dass die Idee hinter den beiden Protokollen ähnlich ist und man schlauerweise keine SID doppelt definiert hat. Wenn Du auf der 0x7FD eine Ox (03) 22 F1 89 anfragst merkt der oder die OBD Master dass Du per OBD versuchst einen SID 22 anzufragen. SID 22 ist aber bei OBD nicht existiert. Nachdem funktional adressiert wurde ignoriert es das dann einfach. Wenn du physikalisch auf dem jeweiligen OBD request Identifier der ECU anfragst würde eine negative response auf dem jeweiligen OBD Response Identifier kommen. wenn du auf der 0x700 eine Ox (03) 22 F1 89 anfragst merkt das Steuergerät dass Du per UDS versuchst einen SID 22 anzufragen. SID 22 ist die SW Version und entsprechend antwortet das Steuergerät dann auch. Nachdem die 0x700 der funktionale Request ist antworten hier alle ECU mit ihrer jeweiligen SW Version nacheinander darauf, jeweils auf dem zum jeweiligen Steuergerät gehörendem UDS Response Identifier.
Chris R. schrieb: > Wenn Du auf der 0x7FD eine Ox (03) 22 F1 89 anfragst merkt der oder die > OBD Master dass Du per OBD versuchst einen SID 22 anzufragen. SID 22 ist > aber bei OBD nicht existiert. Nachdem funktional adressiert wurde > ignoriert es das dann einfach. Wenn du physikalisch auf dem jeweiligen > OBD request Identifier der ECU anfragst würde eine negative response auf > dem jeweiligen OBD Response Identifier kommen. > > wenn du auf der 0x700 eine Ox (03) 22 F1 89 anfragst merkt das > Steuergerät dass Du per UDS versuchst einen SID 22 anzufragen. SID 22 > ist die SW Version und entsprechend antwortet das Steuergerät dann auch. > Nachdem die 0x700 der funktionale Request ist antworten hier alle ECU > mit ihrer jeweiligen SW Version nacheinander darauf, jeweils auf dem zum > jeweiligen Steuergerät gehörendem UDS Response Identifier. Okay das Thema is echt komplizierter als ich dachte. Was meinst du mit wenn du auf 0x700 anfragst? Meinst du wenn man erst 0x7FD anfrägt dann Ox (03) 22 F1 89 -> 7FD 03 22 F1 89 ist es OBD und wenn du 0x700 Ox (03) 22 F1 89 -> 700 03 22 F1 89 anfrägst ist es UDS?
Versuch es Dir so vorzustellen, OBD2 und UDS sind komplett getrennte Welten und komplett getrennte Protokolle die fast nichts miteinander zu tun haben ausser dass man mit beiden irgendwas mit Diagnose machen kann. Beide verwenden auch getrennte Kommunikationskanäle, d.h. wenn man auf CAN unterwegs ist verschiedene Identifier auf dem Bus. OBD2 sind paar Sachen die gesetzlich definiert und einheitlich sind um z.B. beim TÜV einheitlich auslesen zu können. UDS ist viel mächtiger und für die hersteller spezifische Diagnose.
Christian schrieb: > Okay das Thema is echt komplizierter als ich dachte. Was meinst du mit > wenn du auf 0x700 anfragst? 0x700 bzw. 0x7FD sind die CAN Identifier auf denen die Anfrage geschickt wird.
Chris R. schrieb: > Christian schrieb: >> Okay das Thema is echt komplizierter als ich dachte. Was meinst du mit >> wenn du auf 0x700 anfragst? > > 0x700 bzw. 0x7FD sind die CAN Identifier auf denen die Anfrage geschickt > wird. Ich verstehe voll und ganz was du meinst, prinzipiell ist mir der Unterschied zwischen UDS und OBD klar. 0x700 könnte z.B. das Gateway sein richitg? Was mir nicht einleuchtet, wie können Bosch, VCDS und wie sie nicht alle heißen überhaupt einen Tester entwickeln z.B. ganz simple den Fehlerspeicher aller Stg. auslesen, wenn UDS bei jedem Hersteller anders wäre. Es gibt doch mit Sicherheit eine zentrale "Eingabe" die das Gateway anspricht und mir alle Fehlercodes sendet, mehr will ich doch gar nicht. :/
Christian schrieb: > Was mir nicht einleuchtet, wie können Bosch, VCDS und wie sie nicht alle > heißen überhaupt einen Tester entwickeln z.B. ganz simple den > Fehlerspeicher aller Stg. auslesen, wenn UDS bei jedem Hersteller anders > wäre. Es gibt doch mit Sicherheit eine zentrale "Eingabe" die das > Gateway anspricht und mir alle Fehlercodes sendet, mehr will ich doch > gar nicht. :/ Naja es gibt verschiedene Wege, Kostenpflichtiger Erwerb der erforderlichen Daten, Reverse Engineering und Industriespionage. In den USA sind die Hersteller sogar zum Beispiel verpflichtet die Daten rauszurücken, vieles bekommst du dann als Mitglied des ETI hier, du kannst ja spaßeshalber mal die Liste der Member anschauen: https://www.etools.org/ Daimler hat in seinen ETI Bereich sogar komplette ODX Pakete, andere Hersteller haben tonnenweise Dokumentation, wovon oft auch nur ein Bruchteil wirklich implementiert ist. Bei anderen Fahrzeugherstellern muss man die Daten direkt anfragen und kaufen. Oft wird auch die Kommunikation nachgebaut, man schaut was der OEM Tester macht und versucht zu verstehen wie die Daten interpretiert werden. Oder es wird versucht die Datenbanken von vorhandenen Testern zu extrahieren und zu konvertieren. Wenn man nicht nur einen Tester für den freien Markt entwickelt, sondern auch für einen OEM hat man natürlich auch den Vorteil, das man detaillierte Informationen über die Steuergeräte hat, welche sich häufig auch bei anderen Steuergeräten des gleichen Zulieferers anwenden lassen. Ich glaube das ist auch der große Vorteil von Bosch, die bauen Steuergeräte, entwickeln einige OEM Tester und haben ihre eigenen Tester für den freien Markt. Das einzige was wirklich standardisiert ist bei UDS sind die SIDs, wenn du zum Beispiel zu VW schaust, verwenden die sogar noch ein eigenes Transportprotokoll statt ISO-TP. Wenn ich mich richtig erinnere gibt es im VW TP keine festen CAN Identifier für die einzelnen ECUs, sondern die werden bei der Kommunikation mit dem Gateway ausgehandelt. VCDS hatte früher viele Datensätze von Nutzern bekommen und wenn ich mir die neuen Datensätze anschaue, vermute ich, dass das gekaufte ODX Daten sind.
Es ist relativ einfach an die nötigen Daten zu kommen. Für fast alle Fahrzeugmodelle findet man die Diagnosesoftware des Herstellers (z.B. ODIS bei VW, ISTA bei BMW oder XENTRY bei Mercedes). Damit kann man ausprobieren was bei der Diagnose passiert. Wobei ich bei Bosch davon ausgehen würde dass sie mit den Herstellern zusammenarbeiten und die nötigen Daten für ihre Werkstatttester direkt bekommen.
Christian schrieb: > Danke für deine Teilnahme ^^ wenn du die Hardware meinst ist es dieses > https://www.sparkfun.com/products/9555 oder die Anwendung? Die habe ich > weitestgehend selbst programmiert. Ich meine dein Auto oder ECU. Was ist das? Christian schrieb: > Was mir nicht einleuchtet, wie können Bosch, VCDS und wie sie nicht alle > heißen überhaupt einen Tester entwickeln Indem sie die Hersteller der ECUs sind (Bosch und Co.). Also genau wissen, wie das Protokoll aussieht. Die Leute bei VAG-COM testen einfach alles durch. Nennt sich reverse enginering. Es gibt auch Bücher zum Thema. Vielleicht solltest du damit anfangen? Denn wie es aussieht, kennst du nicht einmal den Unterschied zwischen OEM OBD und OBD II. Der ist aber entscheidend. OBD II und UDS sind normiert. Also kann das jeder nachlesen, der bereit ist, Geld oder Zeit in die Hand zu nehmen.
Christian schrieb: > Ich verstehe voll und ganz was du meinst, prinzipiell ist mir der > Unterschied zwischen UDS und OBD klar. > > 0x700 könnte z.B. das Gateway sein richitg? > > Was mir nicht einleuchtet, wie können Bosch, VCDS und wie sie nicht alle > heißen überhaupt einen Tester entwickeln z.B. ganz simple den > Fehlerspeicher aller Stg. auslesen, wenn UDS bei jedem Hersteller anders > wäre. Es gibt doch mit Sicherheit eine zentrale "Eingabe" die das > Gateway anspricht und mir alle Fehlercodes sendet, mehr will ich doch > gar nicht. :/ Ne, 0x700 ist funktionaler Request. Bei ODB2 und UDS gibt es zwei Arten anzufragen, funktional und physikalisch. funktional heißt dass man einmal ins Auto reinfragt wer denn so alles überhaupt da ist und dann die Antworten einsammelt, dazu ist der 0x700 bei UDS da. Beispiel (IDs frei gewählt): Anfrage ID 0x700 Bytes 03 22 F1 89 --> hallo, gebt mir mal alle eure SW Versionen Gateway antwortet dann auf ID 0x4711 mit SW 1234 Motor antwortet dann auf ID 0x0815mit SW 5678 ... Wenn ich das Gateway direkt fragen will dann geht das nicht über die 0x700 sondern über die ID 0x4710 Bytes 03 22 F1 89, es würde dann auch auf der 0x4711 mit SW 1234 antworten. 0x4710 und 0x4711 wären in dem Beispiel das physikalische Request-Response ID Pärchen fürs Gateway. OBD2 analog mit anderen IDs und SID, da ist der 0x7FD der funktionale Request für alle. Die Hersteller müssen ihre Diagnosebeschreibungen freien Werkstätten etc. zur Verfügung stellen (nicht kostenlos!), da bekommen auch die Anbieter von universellen Testern ihre ganzen Daten her.
> Das einzige was wirklich standardisiert ist bei UDS sind die SIDs, wenn > du zum Beispiel zu VW schaust, verwenden die sogar noch ein eigenes > Transportprotokoll statt ISO-TP. Wenn ich mich richtig erinnere gibt es > im VW TP keine festen CAN Identifier für die einzelnen ECUs, sondern die > werden bei der Kommunikation mit dem Gateway ausgehandelt. VW verwendet schon lange normales ISO-TP auf CAN, davor war es TP2. Was du meinst geht Richtung DoIP auf Ethernet, das ist dann aber eh eine komplett andere Baustelle.
Chris R. schrieb: > VW verwendet schon lange normales ISO-TP auf CAN, davor war es TP2. > Was du meinst geht Richtung DoIP auf Ethernet, das ist dann aber eh eine > komplett andere Baustelle. War schon auf TP2.0 bezogen, aber ich habe ehrlicherweise keine VW Diagnoseprojekte gemacht, überwiegend asiatische Hersteller. Daher bin ich mir beim TP2.0 nicht sicher ob ich das so richtig in Erinnerung habe mit dem aushandeln der CAN Identifier. Ist aber schon Jahre her, da war DoIP gerade so in den Startlöchern und für unsere Belange nicht relevant, auch wenn wir schon Entwicklungen in dieser Richtung angestellt haben.
Marc X. schrieb: >> VW verwendet schon lange normales ISO-TP auf CAN, davor war es TP2. >> Was du meinst geht Richtung DoIP auf Ethernet, das ist dann aber eh eine >> komplett andere Baustelle. > > War schon auf TP2.0 bezogen, aber ich habe ehrlicherweise keine VW > Diagnoseprojekte gemacht, überwiegend asiatische Hersteller. Daher bin > ich mir beim TP2.0 nicht sicher ob ich das so richtig in Erinnerung habe > mit dem aushandeln der CAN Identifier. aushandeln trifft es bei TP2.0 nicht ganz, es gibt nen Identifier Switch basierend auf einem Stardwert und der Diagnose-Adresse der jeweiligen ECU. Warum das so gemacht wurde wollte mir aber der Autor der TP2.0 Spec vor zwei Jahren bei nem Bierchen auch nicht genauer erklären - oder er hatte nach 20 Jahren vergessen was er sich damals gedacht hatte.
:
Bearbeitet durch User
Hast Du denn a) eine ordentliche Verbindung zum CAN Bus? Richtige Polung HI/LO b) die richtige CAN Baudrate am ELM eingestellt? c) die richtige CAN ID Länge (std 11 Bit oder ext)? d) auf dem Oszi nachgelesen ob da was am Bus passiert? e) Informationen über den CAN Bus und die daran angeschlossenen Geräte (IDs)? f) geprüft ob zwischen Deinem ELM (OBD-Buchse?) und den Busteilnehmern ein Gateway hängt und diese ggf. Dinge filtert oder besondere "Freischaltsequenzen" erfordert? Eine Übersicht der UDS CAN IDs wäre hilfreich, wie z.b.hier https://mk4-wiki.denkdose.de/artikel/can-bus/mk4_can-bus_modules
> Wenn ich das Gateway direkt fragen will dann geht das nicht über die > 0x700 sondern über die ID 0x4710 Bytes 03 22 F1 89, es würde dann auch > auf der 0x4711 mit SW 1234 antworten. > 0x4710 und 0x4711 wären in dem Beispiel das physikalische > Request-Response ID Pärchen fürs Gateway. > > OBD2 analog mit anderen IDs und SID, da ist der 0x7FD der funktionale > Request für alle. > > Die Hersteller müssen ihre Diagnosebeschreibungen freien Werkstätten > etc. zur Verfügung stellen (nicht kostenlos!), da bekommen auch die > Anbieter von universellen Testern ihre ganzen Daten her. Danke dir jetzt hab ich es verstanden! :D Krubkj L. schrieb: > Christian schrieb: > >> Danke für deine Teilnahme ^^ wenn du die Hardware meinst ist es dieses >> https://www.sparkfun.com/products/9555 oder die Anwendung? Die habe ich >> weitestgehend selbst programmiert. > > Ich meine dein Auto oder ECU. Was ist das? Es ist ein Golf 7 BJ 2019, ich arbeite bei VW also mit ODIS rum testen wäre auch kein Problem.
Olli Z. schrieb: > Hast Du denn > a) eine ordentliche Verbindung zum CAN Bus? Richtige Polung HI/LO > b) die richtige CAN Baudrate am ELM eingestellt? > c) die richtige CAN ID Länge (std 11 Bit oder ext)? > d) auf dem Oszi nachgelesen ob da was am Bus passiert? > e) Informationen über den CAN Bus und die daran angeschlossenen Geräte > (IDs)? > f) geprüft ob zwischen Deinem ELM (OBD-Buchse?) und den Busteilnehmern > ein Gateway hängt und diese ggf. Dinge filtert oder besondere > "Freischaltsequenzen" erfordert? > > Eine Übersicht der UDS CAN IDs wäre hilfreich, wie z.b.hier > https://mk4-wiki.denkdose.de/artikel/can-bus/mk4_can-bus_modules a -> ist richtig b -> muss ich nochmal prüfen,aber ich denke wenn OBD Modes gehen muss es ja c -> 11 Bit d -> mach ich in der Arbeit e -> ne leider nicht wirklich hätte gehofft, dass es eine Gesamtabfrage zum Fehlerspeicher abfragen gibt. (mehr will ich auch nicht) f -> Es hängt definitiv ein Gateway dazwischen, ob er dies Filter weiß ich leider nicht Hab mir jetzt eine Lektüre gekaut wo es nochmal gut erklärt wird ich hoffe ich kann mein Grundwissen über UDS dann ein bisschen erweitern.
Christian schrieb: > > Es ist ein Golf 7 BJ 2019, ich arbeite bei VW also mit ODIS rum testen > wäre auch kein Problem. Dann kannst Du ja einfach eine Diagnosesitzung mit ODIS mitschneiden und Dir ansehen was passiert. Das Mitschneiden der CAN-Bus Kommunikation geht vermutlich auch mit dem ELM327, man muss ihn halt so initialisieren dass er alle CAN Messages ausgibt und nichts wegfiltert.
Christian schrieb: > Ich habe mir nämlich bei SparkFun dieses Teil gekauft und vermeintlich > gedacht es ist ein ELM 327. https://www.sparkfun.com/products/9555 > Es ist gar keiner, kann das Problem daran liegen? ...... STN1110 is an OBD to UART interpreter that can be used to convert messages between any of the OBD-II protocols currently in use, and UART. It is fully compatible with the de facto industry standard ELM327 command set. ...... Die sagen "fully compatible", reden aber andererseits nur über OBD-II. Schwer zu sagen, ob UDS-Requests einfach ignoriert und in /dev/null versenkt werden... Wenn du die Möglichkeit hast, das Ding an ein mindestens DK2-Gerät direkt anzuhängen, müsste es klarer sein, als über den Diagnose-Gateway im Fahrzeug. mfg mf
:
Bearbeitet durch User
Zu dem STN1110: Der ist im Vergleich zum ELM327 die bessere Wahl. Es gibt zusätzliche Kommandos und auch Firmware Updates. Bezüglich UDS ist er kompatibel zum ELM327 und kann dazu verwendet werden per UDS mit einem Steuergerät zu kommunizieren, man muss dazu halt zuerst die zum Steuergerät passenden CAN IDs für Senden und Empfangen einstellen. Für das Mitschneiden der Kommunikation auf dem CAN Bus eignet er sich ebenfalls. Man muss dazu das passende Protokoll einstellen (CAN Bus Geschwindigkeit), mit "AT CAF0" die Protokollbehandlung abstellen und mit "AT H1" die Anzeige der CAN IDs einschalten. Gegebenenfalls auch noch mit "STCMM1" CAN ACKs beim Mitschneiden einschalten. Und dann startet man mit "STMA" das Mitschneiden. Damit keine Daten verloren gehen sollte die UART Baudrate möglichst groß sein. Doku und Firmware Updates gibt es bei ScanTool.net.
> Es ist ein Golf 7 BJ 2019, ich arbeite bei VW also mit ODIS rum testen > wäre auch kein Problem. Stell aber auf Diagnose per CAN/CAN FD um, sonst nimmt ODIS DoIP und da sind ein paar Sachen anders.
Also wenn Du (TO) dich schon mit dem Thema UDS beschäftigst (was ich im übrigen auch gerade tue) und einließt, wie wäre es denn wenn Du dir den ganzen Overhead und die Interpretationen einer halbfertigen Lösung wie einem ELM/STN sparst und alles erstmal rein auf CAN-Frame Basis erledigst? Ich nutze für solche Dinge sehr gern einen STM32 basierenden CAN/USB Wandler. Ich habe eine Selbstbau-Variante, inzwischen gibt es sowas aber wie Sand am Meer zu kaufen für kleines Geld, teils sogar mit 2 CAN-Bussen was für manche Anwendungen wirklich interessant werden kann (z.B. Filter). Diese senden einfach einen CAN-Frame auf den Bus, oder leiten die empfangenen Frames seriell abrufbar in den PC. Die besseren verwenden einen internen Sende/Empfangsbuffer der größer ist als die ggf. von einem Stand-Alone-Controller wie SJA1000 o.ä. Mit dieser Schnittstelle hast Du dann die volle Wahl zwischen: Ich programmiere alles selbst per serial-IO und ich nutze tools wie z.B. slcan unter Linux. Zum analysieren und debuggen nutze ich da gern das Windows-Tool CANHacker. Natürlich, da muss man jeden Frame selbst steuern, also ISO-TP per Software. Aber zum lernen eh das Beste und in der Umsetzung jetzt auch nicht sooo tragisch wie man glauben mag. Da gibt es auch einen großen Pool fertiger Lösungen auf Github. Weiterhin erlaubt praktisch jede Programmiersprache, selbst Skriptsprachen, den Zugriff auf eine virtuelle, serielle Schnittstelle (COM-Port). Ich habe da div. Erfahrungen mit PHP, Python gesammelt und bin aktuell bei C++. Es gibt aber auch einfache Skript-tools (z.B. https://sourceforge.net/projects/scriptcommunicator/) mit denen man einfache Hilfsmittel bauen kann, für Projekte ideal.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.