Hallo Liebe Leute Ich hätte eine Frage zum CAN-Bus :-) Ich habe ein unbekanntes Gerät, dass mir auf dem CAN-Bus , auf ein paar Adressen, ein paar Daten ausgibt. Also Übertragung funktioniert... Jetzt möchte ich aber den ganzen Adressberreich des CAN-Buses durchcannen, ob es noch andere Adressen im Gerät gibt, auf das das Gerät vielleicht anspricht.. (eventuell sollte auch eine Boot-Option im Gerät vorhanden sein ?!) Derzeit lausche ich mit dem CAN-USB-Modem von PEAK und dem PcanView (Ein paar andere Modem hätte ich auch noch...) Habe mir auch schon mal das Programm CanEsay runtergeladen (30Tage Testversion)aber noch nix damit gemacht... Gibt es vielleicht eine Möglichkeit, alles Adressen des CAN-Bus zu scannen? Meine Idee wäre eventuell das ACK Bit auszuwerten..?! Da müsste eigentlich ein Wert zurückkommen, wenn ich eine richtige Adresse anspreche ? Also nacheinander jede Adresse Senden und schauen ob ein ACk kommt .. grübel... Mir ist aber noch nicht ganz klar, mit welchem Programme das ginge.. Hat jemand daszu eine Idee ? Erfahrung ? Oder gibt es schon Programme, die das können ? DANKE l.G. Robert
Quark. Das Ack kommt bei JEDER formal richtigen CAN-Botschaft. Wenn es "verborgene" Funktionen gibt, kommst du so nicht dran, da es ganz schnell gegen unendlich gehende Möglichkeiten gibt. Mal ganz auf die Schnelle ausgedachte, primitivste Möglichkeit, Zusatzfunktionen "freizuschalten" ID 0x566 DL 7 0x23 0xFE 0x00 0x44 0xAC 0x3E 0x7d Nur wenn das exakt so kommt funktioniert irgendwas anderes. Kann man beliebig weiter ausbauen. Du hast nur 3 Möglichkeiten: -mithorchen, wenn ein "offizielles" Gerät irgendsowas veranstaltet -die Original-Source "beschaffen" -und drittens (schwer bis unmöglich) an die Maschinensoftware heranzukommen und rückwärts übersetzen Kurz: vergiss es.
H.Joachim S. schrieb: > Du hast nur 3 Möglichkeiten: > -mithorchen, wenn ein "offizielles" Gerät irgendsowas veranstaltet > -die Original-Source "beschaffen" > -und drittens (schwer bis unmöglich) an die Maschinensoftware > heranzukommen und rückwärts übersetzen Wenn man erkennt, dass da noch CANopen oder ein anderen Protokoll "gesprochen" wird, hätte man einen Anhaltspunkt und ein paar bekannte Adressen.
Robert schrieb: > Ich habe ein unbekanntes Gerät, dass mir auf dem CAN-Bus , auf ein paar > Adressen, ein paar Daten ausgibt. Robert schrieb: > ob es noch andere Adressen im Gerät gibt, auf das das Gerät vielleicht > anspricht.. ahaaa...Du hast also ein unbekanntest Gerät und willst wissen auf was der so anspricht??? :-) Lass mich raten..Das unbekannte Teil ist von Audi/VW bzw von Maserati, richtig?
Danke für die schnellen Antworten :-) @ Bülent C ne.. ist kein Auto, ist ein handliches Gerät.. CanOpen wird höchstwarscheinlich nicht eingesetzt.. (da schon älter) @H.Joachim S. mmhh.. Grundsatzfrage: Wenn ich ein Gerät habe, dass für eine bestimmte Adresse konfiguriert ist (z.B. 0x100) und ich spreche das dann an mit 0x100 an, müsste doch ein Ack kommen ?! Muss ich dann auch die richten Nutz-Daten übertragen oder bekomme ich schon ein ACK, wenn die Adresse stimmt ? (kenne das so von I2C) Kann man das ACK irgendwo sehen, oder wird das nur intern in den Schichtmodellen verarbeitet ? l.G. Robert
Hi, die CAN Adressen sind nicht für Geräte sondern für die Nachrichten. 0x100 ist z.B. die Kühlwassertemperatur, wenn die gesendet wird ist dem Sender egal ob die für einen oder mehrere ist. Wenn die Nachricht empfangen wird dann gibt es ein ACK. Das ACK gibt es für den Empfang einer Nachricht, ob die Daten relevant sind oder nicht ist egal. Gruß JackFrost
Das Ack dient dem Sender zu erkennen ob er korrekt am Bus angeschlossen ist. Es wird von jedem Teilnehmer erzeugt wenn der Frame korrekt ist. Ob ein Empfänger auf eine bestimme ID ( das sind Objekt-Identifier keine Adressen) + Datenlänge + korrekte Daten reagiert muss von Außen nicht sichtbar sein. Bevor du dich an die Lebensaufgabe machst alles auszuprobieren, investiere noch etwas in CAN Grundlagen. Schon im kurzen Wikipedia Artikel steht viel mehr als du jetzt weist.
Robert schrieb: > Derzeit lausche ich mit dem CAN-USB-Modem von PEAK und dem PcanView Auf der Treiber-CD von PEAK sind Programmierbeispiele in C++, C# und VB mit denen man einfach eine eigene kleine Anwendung zusammenbasteln kann. (Microsoft Visual Studio Express gibts kostenlos zum Download). Robert schrieb: > Wenn ich ein Gerät habe, dass für eine bestimmte Adresse konfiguriert > ist > (z.B. 0x100) und ich spreche das dann an mit 0x100 an, müsste doch ein > Ack kommen ? Wie schon gesagt: Das ACK kommt immer, egal ob die anderen CAN-Teilnehmer deine Botschaft nun verarbeiten oder einfach ignorieren.
Hallo @Volle22 Ich habe mich schon ein bisschen eingelesen.. und verschiedene Seiten zum Thema konsumiert aber alles ist eben nocht nicht klar... Nochmal konkret gefragt: Wenn jetzt ein Gerät am CAN-Bus angeschlossen ist (nur eines) und das sendet z.B. Daten mit Adresse 0x110, 0x120, 0x130 (sind frei erfunden) Diese empfange ich z.B. mit dem CAN-Modem con PEAK Jetzt könnte doch das Gerät so programmiert sein, dass es z.B. einen Steuerbefehl auf 0x100 empfangen kann. Wenn ich jetzt auf 0x101 irgendwelche Daten sende (als Test) dürfte ja kein ACK kommen und wenn ich auf 0x100 etwas sende, müsste ein ACK kommen Stimmt das soweit ? Kann ich das ACK irgendwie auswerten ?
Nein, das stimmt nicht.
es ist egal welche CAN ID du dem Gerät sendest, es wird immer ein ACK
von ihm kommen. Ob das Gerät diese Nachricht auswertet oder nicht ist
über den CAN-Bus nicht zu ermitteln.
ACK gibt nur an, ob die physikalische Übertragung funktioniert hat
(sprich richtige stuff bits, korrekter CRC). Was das Gerät nun mit der
Nachricht logisch anstellt ist nicht direkt auf dem CAN-Bus zu sehen.
Der Weg über ACK ist eine Sackgasse. Tut mir leid ist leider technisch
so :(
Viele Grüße
Gast
Hi, um die Sache mit dem ACK/NAK etwas besser zu verstehen: Es handelt sich dabei um eine Schutzfunktion des Bus und nicht um ein "ich habe die Daten angenommen". Schutzfunktion in dem Sinne: Beim CAN wird viel Wert auf Datenintegrität gelegt, da eine Nachricht mehrere Steuergeräte betreffen kann und es wichtig ist, im gesamten System konsistente Daten zu haben. Deswegen ist es auch so, dass wenn von einem einzigen Teilnehmer ein NAK kommt, die Nachricht für alle Teilnehmer verworfen wird. Der Sender wird dadurch gezwungen, diese ungültig gewordene Nachricht erneut zu senden. Dadurch wird, wie beschrieben, vermieden, dass verschiedene Steuergeräte mit unterschiedlichen Daten arbeiten. Wer jetzt sagt: "Das ist aber Kacke, wenn ein Steuergerät nun alles mit NAK bestätigt, dann geht gar nix mehr" - ja, allerdings: er geht damit auch in einen sicheren Zustand: Lieber etwas funktioniert nicht als falsch. Zudem gibt es einen weiteren Schutzmechanismus: Empfängt ein Steuergerät n Nachrichten falsch, geht es zunächst in den Listen-Modus. Wenn es der "Rogue"-Teilnehmer war, wird die Störung damit automatisch aufgehoben. Kommen dagegen weitere geNAKten-Nachrichten rein, klemmt sich der Teilnehmer komplett vom Bus ab. CAN ist in vielerlei Hinsicht einzigartig. Man muss sich allerdings mit ihm auseinandersetzen, um seine Eigenheiten und Vorzüge zu lernen und zu schätzen ;-)
> ... ist ein handliches Gerät ...
Tolle Information.
Frage: Warum plenkst du so viel?
@Chris R Danke für die Gute Info :-) @ Harald mmmhhh.. ist doch nur eine Umschreibung wenn mann es nicht genau angeben will.. Ich verstehe deine Neugier ;-), aber das Gerät tut nix zur Sache ;-) Auch plenk ist mir nicht wichtig.... Die Information zählt ;-) Danke Chris R. :-) l.G. Robert
Robert schrieb: > @ Harald > > mmmhhh.. ist doch nur eine Umschreibung wenn mann es nicht genau angeben > will.. Immer diese heimlich tuerei....Ist das Teil für 'ne Mondlandung gut oder warum diese heimlichtuerei?? So bekommst Du sicherlich keine Infos..
Die Beschreibung von ACK/NAK ist aber nicht korrekt. ACK ist dominant, dementsprechend reicht das ACK eines einzigen Knotens aus, um dem Sender zu bestätigen: alles korrekt gelaufen. NAK heißt entsprechend: rezessives Pegel im slot, keiner hat was korrektes empfangen. Aktiv NAK kann logischerweise keiner senden.
H.Joachim S. schrieb: > Die Beschreibung von ACK/NAK ist aber nicht korrekt. ACK ist Ja, da hast du natürlich recht. Habe es komplett aus dem Kopf geschrieben ohne nochmal nachzuschauen. Ich zitiere einfach mal aus der Wikipedia (deren Artikel zum CAN i. A. Recht gut ist, an der Stelle aber nicht ganz exakt):
1 | Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-Frames zu quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots und überschreibt somit den rezessiven Pegel des Senders. Im Falle einer negativen Quittung (rezessiver Pegel) muss der fehlererkennende Knoten nach dem ACK-Delimiter ein Error-Flag auflegen, damit erstens der Sender vom Übertragungsfehler in Kenntnis gesetzt wird und zweitens um netzweite Datenkonsistenz sicherzustellen. Wird der rezessive Pegel von einem Empfänger durch einen dominanten überschrieben, kann der Absender jedoch nicht davon ausgehen, dass das Telegramm von allen anderen Empfängern erhalten wurde. |
...und weil ich zu schnell auf veröffentlichen geklickt habe (sorry for spamming): Ein NAK ist im ACK-Feld zwar rezessiv (wir somit also "verdeckt"), das zweite ACK-Bit ist allerdings per default rezessiv. Wenn dieses nun dominant wird, gilt die Nachricht als ungültig. Das ist entweder das (wenn ich mich richtig erinnere) erwähnte Error-Flag, oder was eigentlich noch viel cleverer ist: ist der Bus (physisch) zu lang bzw. die Bitrate für die gegebene Länge zu groß, läuft das erste (dominate) ACK-Bit in das zweite (rezessive) Bit hinein und schwupps, wird die Nachricht ungültig. Allerdings muss ich sagen, dass ich in der Praxis nur sehr selten bis in die unteren LSI-Layer vom CAN schaue. Zum Debugging reicht in meinem Fall der RX/TX-Error count (der auch anderweitig beeinflusst wird) - wenn nicht sogar die Anzeige "OK"/"BUS OFF". Wenn man nix grob falsch macht, ist das Zeug sehr robust.
Chris R. schrieb: > CAN ist in vielerlei Hinsicht einzigartig. Man muss sich allerdings mit > ihm auseinandersetzen, um seine Eigenheiten und Vorzüge zu lernen und zu > schätzen ;-) so einzigartig ist der CAN nicht EIB/KNX hat sehr viel von ihm übernommen. Ähnliche Aufgabenstellung, nur im Haus und nicht im Auto.
Chris R (ohne Login) schrieb: > Ich zitiere einfach mal aus der Wikipedia (deren Artikel zum CAN i. A. > Recht gut ist, Die IS0 11898 sollte i. A. "recht gut" sein? http://www.google.com/search?q=iso+11898+pdf pfffff....
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.