Hallo, ich habe nach einer Möglichkeit gesucht, irgendwie an die Drehzahlen von möglichst beliebigen Autos zu kommen... Jetzt habe ich für das Arduino Board (Arduino.cc) ein CAN-Shield gefunden: http://www.skpang.co.uk/catalog/product_info.php?cPath=140_142&products_id=706 Kennst sich wer mit CAN aus? Sind Drehzahlwerte bekannt? Wäre das also für einen Laien möglich, so an die Drehzahldaten zu kommen? Thx
Das Problem ist das jeder Hersteller die Werte in eigenen IDs vergibt, da sie tun und lassen können was sie wollen. Es geht sogar soweit das der 3er für die Drehzahl eine andere ÍD hat als der 5er. Die M-Modelle haben wieder eine eigene ID...
Hanz Hoyer schrieb: >Kennst sich wer mit CAN aus? Sind Drehzahlwerte >bekannt? Wäre das also für einen Laien möglich, >so an die Drehzahldaten zu kommen? Es gab hier im Forum gelegentlich mal Themen zu CAN und Auto. Z.B. Autoradio am CAN-Bus, wo jemand was manipulieren wollte. Da müßtest du die Forensuche mal mit Suchbegriffen bemühen. Aber, warum sollte das nicht gehen? Mit einem passiven CAN-Bus-Knoten, der also nur mit hört, kann man nicht besonders viel falsch machen. Man muß nur heraus finden, wo sich die entsprechenden Leitungen im Auto befinden, bzw. leicht zugänglich sind. Und wenn es dann geklappt hat, darfst du dir aus dem ganzen Datensalat die entsprechenden Messages heraus suchen. Zu den Dateninhalten müßte man sicher jemanden aus der Entwicklung der Steuergeräte fragen. Ob die da wohl einfach was rausrücken?
okay, der CAN-Bus besteht aus zwei drähten (Can-High und CAN-Low) die kann man recht einfach abgreigen... Der nächste Schritt wäre, wie ich dann nun mit meinem Arduino die entsprechenden Messages aus dem Can Auslese...
Hanz Hoyer schrieb: >okay, der CAN-Bus besteht aus zwei drähten (Can-High und CAN-Low) >die kann man recht einfach abgreigen... Das kann auch mal ein Lichtwellenleiter sein, anstatt Draht. >Der nächste Schritt wäre, wie ich dann nun mit meinem Arduino >die entsprechenden Messages aus dem Can Auslese... Genau. Du brauchst da mal eine CAN-Software auf dem Board, die mit dem CAN-Controller kommuniziert. Und etwas Datenspeicher zum Erfassen der Daten. Ich selbst arbeitete für eine CAN-Entwicklung mal mit einem CAN-Bus-Analyser zum Busmitschnitt, der bequem vom PC aus bedienbar war, und die Daten dort zusammen mit einem Zeitstempel in einer Tabelle sichtbar machte.
Hanz Hoyer schrieb: > okay, der CAN-Bus besteht aus zwei drähten (Can-High und CAN-Low) die > kann man recht einfach abgreigen... Zumindest wenn du weißt, an welchen CAN du musst. Drehzahl beim A5 bekommst du nur über den Motor-CAN.
Baim A5 ist die Drehzahl auf allen CAN-Bussen zu finden. Der Komfort braucht es für die Ambiente-Regelung im Radio. Die Diagnose sowieso. Die Kombianzeige würde ohne auch nur Quatsch anzeigen. Und so weiter. Genau genommen gibt es sogar mehrere Drehzahlsignale. Bei Audi ist es sogar so, dass eine Nachricht die auf mehreren Bussen zu finden ist auf allen die gleiche ID und den gleichen Aufbau hat. Gruß, TManiac
Meine Unterlagen und Tests sagen da etwas anderes, aber egal. Tut nichts zur Sache.
Um in möglichst vielen unterschiedlichen Autos die Drehzahl zu messen würde ich dir die OBD2 Schnittstelle empfehlen. Gibt da eine Menge an fertigen Module für unter 50€, z.B. dieses hier: http://www.obd-shop.com/danila/product_details.php?id=357&lang=de Kann man soweit ich das sehe bequem über UART ansprechen. Natürlich kannst Du auch den CAN direkt anzapfen, allerdings bräuchtest du dann ersteinmal Infos zu Message ID, Signalposition und -skalierung. Alles Daten die sicherlich nicht ohne weiteres zu Beschaffen sind. Kannst ja mal bei Audi anrufen und fragen ob sie dir ihre K-Matrix zuschicken können :-)) > Das kann auch mal ein Lichtwellenleiter sein, anstatt Draht. Rein aus Interesse, da ich zum ersten mal hiervon höre: In welchem Auto kommt ein optischer CAN zum Einsatz?
peterguy schrieb: >In welchem Auto kommt ein optischer CAN zum Einsatz? Sowas hab ich vor gut 10 Jahren schon mal auf einem Werbeplakat eines Automotive-Herstellers gesehen, wobei ein aufgeschnittenes Auto und die darin befindlichen Teile zu sehen waren. OK, du hast sicher Recht, da wird wohl aus Kostengründen drauf verzichtet.
Aha, funktioniert die OBD2 Schnittstelle genausoschnell (echtzeit) wie der Can-Bus? Kann man da einfach die aktuelle Drehzahl auslesen? UART ist doch ein anderer Begriff für serielle Schnittstelle oder?
Hanz Hoyer schrieb: >UART ist doch ein anderer Begriff für serielle Schnittstelle >oder? Er meint vielleicht einen CAN-zu-UART-Adapter für den PC.
Mit Lichtleiter kenn ich nur MOST. OBD2 geht über CAN, ich versteh die Frage daher nicht :D
Ich bezioehe mich auf dies hier: Um in möglichst vielen unterschiedlichen Autos die Drehzahl zu messen würde ich dir die OBD2 Schnittstelle empfehlen. Gibt da eine Menge an fertigen Module für unter 50€, z.B. dieses hier: http://www.obd-shop.com/danila/product_details.php... Kann man soweit ich das sehe bequem über UART ansprechen. Also ODB läuft auch über den CAN BUS?
Der Can ist auf dem OBD abgreifbar! Warscheinlich meint er das. Aber nicht jedes Auto unterstützt CAN, obwohl es OBD hat.
Lichtwellenleiter (MOST) werden heute hauptsächlich für die Infortaiment-Systeme in den Premium Marken verbaut. Musik/Navi/TV ect. Fahrzeuge haben mehrere CAN Systeme. zum Beispiel: CAN Antrieb für Motor/Getriebe... CAN Komfort für Klima/Türen... CAN Infotaiment für Soundsteuerung/Navi/TV... Teilweise separat noch für Airbag, ABS, ESP also für Sicherheitssysteme. Ist aber von Marke zu Marke und sogar je nach Modell unterschiedlich. Einige Signale werden natürlich in jedem CAN-Bus vorkommen, wie zum Beispiel Drehzahl, Bordspannung, Geschwindigkeit. Das ganze entschlüssseln wird vermutlich nicht einfach werden, da wirst du beim OBD Stecker am meisten erfolg haben. Da dieser CAN-BUS bei allen Herstellern seit 2001 (bei Benziner) und 2003 (bei Diesel) einheitlich sein müssen. Neue Abgasvorschriften haben das ganze genormt damit die z.b. die Polizei/Fremdgaragen mit Ihren Testgeräten den Fehlerspeicher abfragen kann. Irgendwo sollten demzufolge genauere Angaben zu diesem CAN-Bus vorhanden sein, evtl. ein Hersteller anfragen.
Hier die verwendeten Normen, was genau was vorschreibt weis ich jetzt auch nicht. Aber die dazu passenden Unterlagen wirst schon finden, und dir vermutlich wieterhelfen. * ISO 8092-2:2000 - Road vehicles - Connections for on-board electrical wiring harnesses - Part 2: Definitions, test methods and general performance requirements * ISO 9141 - Road vehicles - Diagnostic systems - Requirements for interchange of digital information, erschienen 1989 * ISO 9141-2 - CARB requirements for interchange of digital information, 1994 und Ergänzung von 1996 * ISO 9141-3 - Road vehicles - Verfication of the communication between vehicle and OBDII scan tool * ISO 11519-2 - Road vehicles - Low speed serial data communication - Low speed controller area network (CAN), 1994 * ISO 11519-3 - Road vehicles - Low speed serial data communication - Vehicle area network (VAN), 1994 * ISO 11898 - Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication, 1993 * ISO/DIS 11898-1 - Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical signalling (Revision of ISO 11519-2:1994, ISO 11898:1993/Amd 1:1995) * ISO/DIS 11898-2 - Road vehicles - Controller area network (CAN) - Part 2: High-speed medium access unit (Revision of ISO 11519-2:1994, ISO 11898:1993/Amd 1:1995) * ISO/DIS 14229 - Road Vehicles-Diagnostic System-Diagnostic Services Specification * ISO/DIS 14230-1 - Road Vehicles-Diagnostic System-Keyword Protocol 2000, Physical Layer * ISO/DIS 14230-2 - Road Vehicles-Diagnostic System-Keyword Protocol 2000, Data Link Layer * ISO/DIS 14230-3 - Road Vehicles-Diagnostic System-Keyword Protocol 2000, Application Layer * ISO/DIS 14230-4 - Road Vehicles-Diagnostic System-Keyword Protocol 2000, Requirements for emission-related systems * ISO/DIS 15031-1 - Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics, Part 1: General information, 2001 * ISO/DIS 15031-3.2 - Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics, Part 3: Diagnostic connector and related electrical circuits, specification and use, 2002 * ISO/DIS 15031-4.2 - Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics, Part 4: External test equipment, 2002 * ISO/DIS 15031-5.2 - Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics, Part 5: Diagnostic services, 2000 * ISO/DIS 15031-6.2 - Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics, Part 6: Trouble code definitions, 2000 * ISO/DIS 15031-7 - Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics, Part 7: Data link security, 2001 * ISO/TR 15497:2000 - Road vehicles - Development guidelines for vehicle based software * ISO/DIS 15764 - Road vehicles - Extended data link security * ISO/DIS 15765-1 - Road vehicles - Diagnostics on Controller Area Network (CAN) - Part 1: General information * ISO/DIS 15765-2 - Road vehicles - Diagnostics on Controller Area Network (CAN) - Part 2: Network layer services * ISO/DIS 15765-3 - Road vehicles - Diagnostics on Controller Area Network (CAN) - Part 3: Application layer services * ISO/DIS 15765-4 - Road vehicles - Diagnostics on Controller Area Network (CAN) - Part 4: Requirements for emissions-related systems * ISO/DIS 16845.2 - Road vehicles - Controller area network (CAN) - Conformance test plan * SAE J1850 - Class B Data Communications Network Interface, 2001 * SAE J1930 - Electrical/Electronic Systems Diagnostic Terms, Definitions, Abbreviations and Acronyms, entspricht ISO/TR 15031-2, April 2002 * SAE J1939 - Recommended Practise for Control and Communications Network (Class C) on Truck and Bus Applications * SAE J1939/01 - Recommended Practise for Control and Communications Network on Truck and Bus Applications * SAE J1939/11 - Physical Layer, 250k bits/sec, Shielded Twisted Pair * SAE J1939/21 - Data Link Layer * SAE J1939/31 - Network Layer * SAE J1939/71 - Vehicle Application Layer, Jan. 2008 * SAE J1939/73 - Application Layer - Diagnostics * SAE J1939/81 - Network Management Protocol * SAE J1962 - Diagnostic Connector, entspricht ISO/DIS 15031-3, Dez. 2001 * SAE J1978 - OBD II Scan Tool, entspricht ISO/DIS 15031-4, Dez. 2001 * SAE J1979 - Diagnostic Test Modes, entspricht ISO/DIS 15031-5, April 2002 * SAE J2012 - Diagnostic Trouble Code Definitions, entspricht ISO/DIS 15031-6, Dez. 2007 * SAE J2190 - Enhanced Diagnostic Test Modes * SAE J2178 - Class B data communication network messages * SAE J2818 - Keyword Protocol 1281, Jan. 2008
> Kann man da einfach die aktuelle Drehzahl auslesen? UART ist doch ein > anderer Begriff für serielle Schnittstelle oder? Ja und ja. Das Modul hat eine serielle Schnittstelle, die du direkt an deinen Arduino anschließen kannst. Zum Thema OBD2: Hier muss nicht unbedingt CAN anliegen, es kann genausogut K-Line oder PWM sein. Ist aber eigentlich nicht relevant, da das OBD Modul alle Protokolle automatisch handelt. Dein Arduino muss das Modul nur über die serielle Schnittstelle ansprechen um eine Verbindung aufzubauen und z.B. die Drehzahl abzufragen. Ist sicherlich die allereinfachste Möglichkeit an das Drehzahlsignal zu kommen. Was möchtest du eigentlich mit dem Drehzahlsignal machen? Wenn du dir einen Drehzahlmesser bauen möchtest könntest du auch wie hier vorgeschlagen: http://www.digitaler-drehzahlmesser.de/ das Analoge Signal anzapfen.
Hallo, vielen Dank für diese tolle antwort... Die anderen Antworten waren ebenfalls gut, nur diese Antwort bringt mich wirklich wieder auf den Weg... Ich benötige die Drehzahlwerte, um mir eine digitale Drehzahlanzeige zu bauen... Ich bin wirklich ein Anfänger... kann zwar einiges mit meinem Arduino bereits realisieren, aber das ist doch alles sehr komplex... Naja, aber dass ist der richtige Weg... Also OBD 2... Sind die Drehzahlwerte denn bei OBD 2 einheitlich codiert? Also funktioniert das dann bei vielen Autos, oder muss man das jedesmal neu anpassen? Danke!!
... Polizei/Fremdgaragen ... Warum die Polizei? Fremdgarage - ist das die von meinen Nachbarn und wie kann eine Garage den CAN-Bus abfragen?
@Martin Die Gesetzgebung schreibt vor das alle OBD2 Fahrzeuge die selben Pinbelegungen, Steckergrösse, CAN-BUS Protokolle verwendet. Sogar wo sich der Stecker befindet ist vorgeschrieben. nämlich Fahrerfussraum. Sorry ist Fremdgarage ein Schweizerdeutscher Ausdruck? Damit wenigstens die überprüfung der Abgasrelevanten Systeme von jeder Werkstatt (also einen VW Werkstatt an einem BMW) durchgeführt werden kann und somit überhaubt eine Abgwaswartung zulässig ist (Abgaswerte werden seit OBD2 nicht mehr gemessen). Da jede Marke eigene Diagnosesysteme verwendet und diese vorher nicht zueinander kompatiebel waren hat man sich für diese OBD2 schnittstelle entschieden. Es existieren zirka 8000 Fehlercodes die bei allen gleich sind, da über OBD2 auch die Lambdawerte, Geschwindigkeit oder Drehzahl ausgelesen werden kann, nehme ich an (Ich weiss es aber nicht zu 100Prozent) das auch die Werte für Drehzahl bei allen gleich sind. Was durchaus logisch scheint. Jetzt kommen wir zur Polizei. Im Kombiinstrument leuchtet bei einem Abgasrelevanten Fehler die sogenante MIL (Malfunction Indicator Light) auf. Die soll den Fahrer dazu auffordern in die nächste Werkstatt zu fahren. Er ist sogar dazu verpflichtet. Falls er einfach weiter fährt und die Herren von der Polizei es bei der nächsten kontrolle genau nehmen. Können Sie anhand ihres Testgerätes feststellen seit wann der Fehler gespeichert ist und dir eine Busse geben weil du die Umwelt verschmutzt.
Danke für die Antwort... Das klingt doch super!! Also: Um an Drehzahldaten zu kommen, eignet sich jetzt wohl am besten OBD2, sofern es sich um ein neueres Fahrzeug handelt... Nun noch eine Frage: Kann man an der OD2 Schnittstelle die Drehzahldaten in ECHTZEIT abgreifen? Oder ist da eine gewisse LAtenz drauf?
Echtzeit, brauchst das Signal ja für Diagnosezwecke am Tester. Also ich kenns von meinem Gerät, reagiert blitzschnell und auf 1 umdrehung genau. Noch nebenbei, auch mit all den Infos die du jetzt hast. Ein Drehzahlsignal zu bekommen wäre über die Zündspulen trotzdem um welten einfacher.... Würde auch bei allen Benziner, alter egal, problemlos funktionieren.
Danke für den Hinweis... das habe ich nun auch wieder überlegt... allerdings wäre da ja die Sache mit dem Kabel... Wenn ich einen festeingebauten Drehzahlmesser im Fahrzeug einbauen möchte, dann muss ich ja ein Kabel durch die Spritzwand ziehen.. aber vielleicht sollte ich erstmal mit der Zündspulen versuchen :)
> Nun noch eine Frage: Kann man an der OD2 Schnittstelle die Drehzahldaten > in ECHTZEIT abgreifen? Oder ist da eine gewisse LAtenz drauf? Sicherlich ist da eine gewisse Latenz drauf. Alledings liegt die im Bereich von Millisekunden (würde schätzen unter 100ms) und dürfte in etwa der Latenz entsprechen, die auch der DZM im Kombiinstrument aufweist. Für dein Vorhaben ists auf jeden Fall ausreichend schnell. > Sind die Drehzahlwerte denn bei OBD 2 einheitlich codiert? Also > funktioniert das dann bei vielen Autos, oder muss man das jedesmal neu > anpassen? Die Kodierung ist normiert, sprich sie ist in allen Autos gleich. Zumindest in allen Autos die sich an die Spezifikation halten ;-) Ein Vorteil der noch für OBD sprechen würde: Am Stecker liegen 12V an, d.h. Versorgung deines DZMs ginge über das selbe Kabel Rein aus Interesse, da ich im Moment an etwas ähnlichem Bastle, was nimmst Du als Gehäuse, bzw wie verbaust du dein Gerät?
Also ein Kabel durch die Spritzwand ziehen ist kein sinderliches Problem. Es Hat ja bereits öffnungen für die original Kaberstränge, musst nur noch den weg dazu freibauen. Eine weitere Möglichkeit an die Drehzahl zu kommen: Restwelligeit der batteriepannung.
Danke für den Spritzwand-Tipp!! RESTWELLIGKEIT: Das wäre sicherlich die eleganteste Lösung.... Weil das ja am universalsten ist... (Vorausgesetzt man kennt die Übersetzung, aber das ist ja sicherlich einfacher zu erfragen als CAN, etc.) Die Restwelligkeit kommt zustande, weil die Wechselspannung nicht 100%ig gleichgerichtet ist oder? Ich habe gehört, dass auch dies bei neueren Fahrzeugen immer besser gleichgerichtet wird, aber es soll immernoch funktionieren... So könnte man ja einfach über den Zigarettenanzünder gehen... Nur: Wie muss das Signal aufbereitet werden, um mit einem Mikrokontroller die Restwelligkeit auszulesen? Oder würde das auch ohne MikroKontroller gehen, nur mit ein paar ICs? Gruß hans
Die Restwelligkeit auszuwerten ist aus mehreren Gründen nicht sehr genau. Der Schlupf des Antriebsriemen für den Generator ist lastabhängig. Das Übersetzungsverhältnis ist unbekannt. Nicht nur der Generator, sondern auch andere Geräte erzeugen Spannungsrippel auf dem Bordnetz. Welligkeit des Generators mit Welligkeit, die von Lasten hervorgerufen werden, zu unterscheiden, ist sicher nicht ganz einfach. Grüße, Peter
Thomas Obermayer schrieb: > Also ein Kabel durch die Spritzwand ziehen ist kein sinderliches > Problem. Dachte ich auch mal. Aber je nach Auto kann das verdammt aufwendig werden. Ich habe in meinen Golf 5 eine extern mit 220V versorgte Standheizung eingebaut, die im Winter den Motor vorheizen und für enteiste Scheiben sorgen soll. Die Sachen, von denen ich dachte, sie könnten schwierig sein, wie das Anbringen des Heizelements am Motor, waren dann am Ende das einfachste, während das Verlegen der Steuerleitung für das Bedienteil vom Motorraum in den Innenraum das größte Problem dargestellt hat. Selbst die Leute von der VW-Werkstatt waren erstmal ratlos. > Es Hat ja bereits öffnungen für die original Kaberstränge, > musst nur noch den weg dazu freibauen. Leider sind die heute so angebracht, daß man da nicht einfach ein eigenes Kabel mit durchstecken kann, ohne irgendwelche Verklebungen auseinanderzureißen. Ein eigenes Loch bohren geht auch nicht, ohne vorher das ganze Amaturenbrett oder den Motor zu entfernen.
@ Hanz Hoyer Ja genau die Restwelligkeit kommt von der nicht 100% gleichgerichteten Bordspannung. Und ja, bei neueren Fahrzeugen klappt das nicht überall. Das heisst den Zigarettenanzünder kannst vergessen. Hab ich auch mal probieret bei einem neuen Audi A6, am Zigarettenanzünder war da nix mit Restwelligkeit... Batterie selbst ging aber. @Peter Diener Naja, ich hab da so ein kleines gerät um schnellstmöglich die Drehzahl von jedem beliebigem Fahrzeug abzuzweigen. Brauch das beruflich. Ausser Zylinderzahl muss ich da gar nix eingeben um an die Drehzahl zu kommen, brauch kein übersetzungsverhältniss. Wie genau das jetzt ist kann ich dir nicht mal sagen, da es für meine Zwecke vollkommen reicht. Hab aber nie krasse abweichungen festgestellt, selbst unter last nicht. @Rolf Magnus Also ich kenn diese VW Werkstatt nicht, aber durch meine doch schon paar jahre Erfahrung an Zusatzeinbauten und Umbauten an und im Fahrzeug kann ich schon sagen das es so ziemlich bei jedem Fahrzeug angemessen zu realisieren ist. Es Existieren diverse "Löcher" in der Spritzwand, abgesehen von Kabel hast du ganz sicher noch das Bremspedal, evtl. noch die Kupplung. Ausserdem kommt von irgendwoher die Frischluft ins Auto. Das Armaturenbrett musste ich noch nie ausbauen oder verbauen um Kabel hindurch zu bekommen. Fussraum Fahrer hast fast immer irgendwo Platz für ein Kabel. Klar mit bohren kann es schwierig werden mangeld Platz. Meisten nem ich aber immernoch Kabelführungen, mit einem Draht hindurch, kabel daran befestigen, und durchziehen.
@ Rolf Magnus exakt das gleiche Problem hatte ich bei meinem A6 mit der elektrischen Standheizung. Nirgendwo ein Loch zum Durchführen des Kabels. Torsten
Hallo, der Weg über die OBD-Schnittstelle ist zwar sehr universell, aber nicht ganz trivial. Hier liegt ein höheres Protokoll, was auf CAN, PWM oder K-Line aufbaut. K-Line ist eine 10400Bit/s UART, also auf nem AT90CAN neben CAN problemlos mit drauf(Da gibt es eine Arduino-Portierung für).Bei deinem Shield sollte es eher auf einen Arduino-Mega gesteckt sein, sonst fehlt die die zeite RS232. PWM nutzen eh nur noch ne handvoll Amerikaner. Hier sollte CAN mittlerweile auch etabliert sein. Trotz Norm kann man darauf möglicherweise verzichten oder man baut einen Timer um. Das sieht ähnlich aus, wie Infrarot-Codes lesen. Im Wesentlichen ist der Ablauf: Der Adapter schickt ein Signal an mit einer funktionalen ID ins Fahrzeug. Alle Steuergeräte, die die Anfrage verstanden haben antworten gleichzeitig darauf mit Ihrer physischen ID. Negative Responsen auf funktionale Anfragen sollen normalerweise am OBD-Interface unterdrückt werden. Normalerweise trägt deine Anforderung die Daten 01(request current powertrain diagnostic data) und 0C(engine rpm) Die Antwort ist dann 41(pos. response auf 01) und 2 Byte mit einer Auflösung von 0,25rpm/Bit. Beginnt die Antwort mit 78 oder bleibt sie aus, dann kennt das SG dieses Datum nicht. Funktionale ID zum senden durch den Adapter ist 7DF. Danach antwortet das Motor-SG mit 7E8 und das Getriebe-SG mit 7E9. Je nachdem, wer von beiden die Drehzahl kennt, wird danach nicht mehr mit allen SG gesprochen, sondern nur noch mit dem jeweiligen SG mit seiner physischen Adresse. Physisch erreichst du das Motor-SG auf 7E0 und das Getriebe auf 7E1. Achja, alle genannten Zahlen sind HEX. Ansonsten haben viele Instrumenten-SG oder Motor-SG noch einen zusätzlichen Frequenz-Ausgang um Drehzahlmesser anzusteuern. Manchmal muss der nur aktiviert werden. Sowas geht mit einem einfachen Diagnoseadapter und ner zum Fahrzeug passenden Anleitung aus dem Netz. Für die Fahrzeughersteller ist der Pin nämlich günstiger als ein zusätzlicher CAN-Empfänger. Ich wünsch Dir gutes Gelingen
Mir ist gerade aufgefallen, das in der Protokollschicht noch ein Byte fehlt: normalerweise ist das erste Byte das Protokollbyte. Die höchsten 4 Bit sind 0-für SingleFrame, 1-für FirstFrame(einer geteilten Botschaft), 2-für ConsecutiveFrame(weitere Teile einer geteilten Botschaft) und 3 für FlowControl. die niederen 4 Bit des ersten Byte enthalten bei 0 die Anzahl der folgenden Nutzdaten-Bytes Bei 3 enthalten die niedrigen 4 Bit den Steuerbefehl der Flußsteuerung Bei 2 steckt in den niederen 4 Byte ein Zähler, der mit jeder fortlaufenden Botschaft eins hochgezählt wird und von 0xF zu 0x0 überlaufen darf. Bei 1 steckt in dem niederen 4 Bit und in dem folgenden Byte die Gesamt-Anzahl der Nutzdaten-Bytes( Hier limitiert allerdings UDS auf 1012)
VIelen Dank für die tollen Tipps... Das ist ja genial. Allerdings bezweifel ich, dass ich das alleine hinbekomme. Ich habe zwar erste Grundkenntnisse, aber das mit einem Arduino Board (Atmege 328) umzusetzen, erscheint mir nich trivial... Viele Grüße aus hamburg, hans
Das ist nicht so schwer, vorallem, wenn es eine Bibliothek zu dem CAN-Shield gibt. In der Setup stellst Du den Bustakt auf 500kBit. Dann stellst Du den Empfangsfilter auf 7EF hex, so dass alles zwischen 7E0 und 7EF empfangen werden kann. Und als letztes prüfst/löschst Du die Fehlerregister. Dann bereitest Du dir 2 Sendefunktionen vor. In einer lädst Du 02 01 0c xx xx xx xx xx und die Adresse 7DF in den Sendepuffer.( ggf. kannst Du die Länge der Botschaft(DLC) auf 3 stellen. Sonst füll den Rest einfach mit irgendwas auf) In der zweiten lädst Du 02 01 0c xxxxx und als Adresse eine Variable sowie einen Empfangsfilter mit der Variable um 8 erhöht. Im Hauptprogramm rufst Du die erste Funktion und bleibst in einer Schleife, bis der CAN-Shield Empfang meldet oder 100 ms um sind.(Geht natürlich sehr viel komfortabler über Interrupts...) Wenn ein Empfang gekommen ist, dann Merke Dir die Adresse und schau in das 2.Byte. steht da eine 41(das erste Byte sollte 03 sein), dann prüfe das 3. und 4.Byte auf FF. Steht da nicht FF verlass die Schleife, erniedrige die gemerkte Adresse um 8 und rufe die zweite Funktion auf. Wenn keine 41 in dem 2. Byte steht, dann schau nochmal in den Puffer, ob inzwischen eine weitere Botschaft eingetroffen ist, bzw. warte weiter in der Schleife auf die nächste Botschaft. Wenn die Schleife nach 100 ms aus ist und es ist kein Empfang eingetroffen, dann initialisiere Dein CAN-Shield neu und fang wieder mit der ersten Botschaft an. Am einfachsten geht das, indem die setup-funktion wieder aufgerufen wird. Hier kann natürlich vorher noch eine komfortable Prüfung der CAN-Fehlerregister durchgeführt werden. Nach dem rufen der zweiten Funktion bleib am besten in einer ähnlichen Schleife, wie die erste Schleife war. Das heißt, Du sendest(Funktion 2), wartest, bis Du entweder durch einen Interrupt gerufen wirdst oder pollst bis Du Empfang hast, prüfst das 2.Byte auf 41 und verarbeitest das 3. und 4.Byte. Stehen da FF FF, dann gib auf Deiner Anzeige einen Fehlerwert aus. Danach solltest Du noch ein wenig in der Schleife bleiben, bis mindestens 100ms um sind und starte Deine zweite Schleife neu.Das machst Du auch, wenn kein Empfang kam. Ggf. können hier auch wieder die Fehlerregister geprüft werden. ===================================================== Du baust die Verbindung auf, testest, von wem die gewünschten Daten kommen. Dann stellst Du den Empfang auf den Sender um, der als erstes die gewünschten Daten liefert und forderst den danach alle 100ms auf, neue Daten zu liefern. Die Botschaften sind niederprior. Deshalb kann es immer mal vorkommen, das eine Botschaft nicht übertragen werden konnte in der Zeit der zweiten Schleife. Prinzipiell kannst Du den Abfrage-Takt bis etwas unter 10 ms treiben. Jedoch erzeugst Du dann sehr viel Buslast, so das die Botschaftsausfälle häufiger werden oder Deine Anfragen nicht mehr absetzen kannst. Zudem wird die Diagnosekommunikation von außen unbemerkt über einige Steuergeräte geroutet(Diagnosegateway/Kombiinstrument). Daher kann es gut sein, das diese hohe Abfragerate zu einem Fehlereintrag und einer Fehlerreaktion in einem dieser Steuergeräte führt. Daher solltest Du nicht unter 100 ms gehen.
@Rainer: Großartig, danke! Genau was ich gesucht habe und hat exakt so funktioniert wie du es beschrieben hast. Gruß Jan
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.