Diskussion:Controller Area Network/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Controller Area Network/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Controller_Area_Network/Archiv/1#Thema_1

Arbitrierung

Eine Frage dazu: es wird geschrieben, dass die 0 gegenüber der 1 dominant ist. D.h. ein Identifier aus Nullen soll die höchste Priorität haben. Der typische NRZ-L Code hat aber für die 0 den 0V-Pegel und für die 1 einen positiven +V-Pegel. Demnach müsste doch die 1 dominant sein, oder täusche ich mich? Weiß jemand genaueres dazu? Danke... Omit 22:25, 25. Mai 2005 (CEST)

Da die TTL-Ausgänge der CAN-Controller nicht direkt verschaltet werden, sondern dafür ein spezieller Physical-Layer mit spezifischen CAN-Transceivern verwendet werden, ist dies irrelevant.--MisterTS 15:25, 3. Jun 2005 (CEST)

Antwort kommt einige Jahre verspätet, hilft aber vielleicht trotzdem: 0 entspricht beim Highspeed-CAN dem 1.5-V-Pegel auf dem CAN_LOW, bzw. 3.5 V auf dem CAN-High, bei 1 entsprechend umgekehrt (weder-noch wären 2.5V). Sobald im Transceiver in irgendeinem der Steuergeräte ein Transistor bei 0 den CAN_Low runterzieht, geht der ganze Bus runter, egal, was die Transistoren in den anderen Geräten machen, deswegen heißt das dominant. Beim Lowspeed sind die Pegel anders, das Prinzip ist aber ähnlich.--KaiBorgeest 23:49, 16. Aug. 2009 (CEST)

Kapazität und deren Einfluss auf die maximale Anzahl der Knoten

MisterTS,

der Grund, warum die Gesamtkapazität eines Netzes die Anzahl der Knoten verringert ist u.A. der folgende: Mit jedem pF verändert sich die Flankensteilheit (sowohl steigende als auch fallende) und daher wird bei zu großer kapazitiver Last das Bussignal irgendwann zu träge, d.h. am Sample-Point liegt kein Pegel gemäss ISO-/SAE-Standard an. Bitte lösche nicht einfach ganze Abschnitte ....

Öhm ja!? Das weiß ich auch. Welchen Abschnitt habe ich den gelöscht? Ich bin mir keiner Schuld bewußt. Ich habe nur einen Abschlußwiderstand in einen Wellenwiderstand zurückversetzt. Also ich hatte den Unterschied im Grundstudium. Außerdem wieso kommt der Beitrag anonym? Die IP kommt jedenfalls aus Hannover. --MisterTS 21:48, 10. Feb 2006 (CET)

Aha, ich habe es gefunden. Ich habe aber keinen ganzen Abschnitt gelöscht. Dies ist aber nicht die Kapazität des Knoten, sondern des CAN-Transceivers. Dann bitte aber auch die Iduktivität mitrechnen und nicht zu vergessen die Signallaufzeit, die sicherlich die größte Einschränkung bildet. Die Kapazität selbst ist relativ gut bestimmt durch den verwendeten CAN-Transceiver. Denn es wird doch sicherlich keiner da große zusätzliche Kondensatoren verbauen. Die Signallaufzeit ist dagegen viel kritischer, insbesondere wenn noch zusätzlich eine galvanische Entkopplung eingesetzt wird. --MisterTS 21:58, 10. Feb 2006 (CET)

Naja, aus Gründen der EMV werden des öfteren Kapazitäten und Zener-Dioden genutzt, welche eine kapazitive Last zur Folge haben, vgl. diverse Application-Notes von Philips.

Auch die Buslänge trägt einen kapazitiven Anteil bei und verzerrt damit das Signal, während es sich im Netzwerk ausbreitet. ramtam 19:34, 20. Aug. 2006 (CET)

Links erweitern / Informationen einarbeiten

Ich habe hier eine Liste mit Links, die zu Seiten mit interessanten Informationen führen.

Soll die Liste der Links erweitert werden oder sollen die Informationen aus den Links verarbeitet werden?

• DeviceNet Offizielle Website
• CANaerospace Offizielle Website
• CAN-Bus Automobil power-line (Englisch)
• CAN Tutorial
• CAN Bus Interface Beschreibung, Pin Out, Signalnamen (Englisch)
• Intrepid Control Systems CAN Bus Tools (Englisch)

ramtam 23:19, 20. Aug. 2006 (CET)

• Die ODVA ist im Text bereits verlinkt. Die ODVA hat mit der Pflege und Weiterentwicklung von CAN wenig zu tun. Daher sollte ein Link reichen (meine bescheidene, gefärbte ;-) Meinung).

• ok ramtam 22:47, 21. Aug. 2006 (CET)

• CANaerospace sollte entsprechend bei höheren Protokollen eingearbeitet werden. Leider habe ich mich selbst bisher damit zu wenig befasst, so dass ich nichts beitragen kann.

• vom Autor von CANaerospace selbst könnte man Informationen bekommen: http://www.stockflightsystems.com/ ramtam 22:47, 21. Aug. 2006 (CET)

• Yamar hat einen schlechten physical Layer entwickelt. Schlecht, weil die Grundprinzipien von CAN verrät: Sicherheit ist nicht wirklich vorhanden. Da ist die Powerline-Übertragung, wie sie von Prof. Beikirch (Universität Rostock) entwickelt wurde bei weitem überlegen. Zumindest die Gleichspannungvariante findet Anwendung bei den Schweizer Bahnen (Zug-Bus).

• lässt sich daraus ein kurzer Abriss mit Begründung machen? ramtam 22:47, 21. Aug. 2006 (CET)

• Auch wenn es den Relevanz-Kriterien von WP widerspricht, würde ich für eine Darlegung der Prinzipen von CANRF sein.

• Wireless ist zwar nicht Hauptthema, aber das würde das Bild abrunden. ramtam 22:47, 21. Aug. 2006 (CET)

• Die Seiten von KVaser und Interfacebus bieten keinen Mehrwert, die geboten Informationen die gleichen wie hier im Artikel bzw. wie im CAN-Wiki sind.

• ok ramtam 22:47, 21. Aug. 2006 (CET)

• Fehlen tut ein Link auf die CAN-Mailing-List.

• wenn Du den Link hast, kannst Du ihn dann bitte einfügen? ramtam 22:47, 21. Aug. 2006 (CET)

• Ich füge den Link ein. Aber bitte nicht als Werbung verstehen, auch wenn die Mailinglist zurzeit von Vector Informatik gehostet wird. Sie wurde ursprünglich von Ken Tindell (damals Entwikcklungsleiter bei Volvo, inzwischen betreibt er seine eigene Firma, die nur noch peripher mit CAN zu tun hat) ins Leben gerufen wurde. Nachdem sie immer größer wurde und langem hin und her hatte sich Vector bereiterklärt die Liste zu hosten. --MisterTS 00:27, 22. Aug 2006 (CEST)

--MisterTS 23:55, 20. Aug 2006 (CEST)

Errorframe bei gleicher ID zweier Sender?

Im Abschnitt Arbitrierung, Priorität: Dass ein Errorframe erzeugt wird, sobald zwei Sender mit der gleichen ID senden, ist schlichtweg falsch. Der Errorframe wird erst erzeugt, wenn ein Sender ein rezessives Bit sendet, aber ein dominantes liesst (nach der Arbitrierung). Für den unwahrscheinlichen Fall, dass beide Sender den exakt gleichen Frame senden, fällt die gleiche ID nicht einmal auf. Ich lasse mich gern eines besseren belehren, meine aber Recht zu haben. -- Nautsch 13:38, 5. Jan. 2007 (CET)

Auch was ich bisher gelernt habe entspricht den Aussagen von Nautsch, wenn man ausser acht lässt, dass es sich um ein in der Regel schlechtes Netz-Design handelt, wenn so etwas passiert, wird immer nur dann ein Errorframe erzeugt, wenn die Daten nicht Protokoll konform sind, z.B. fehlende Stuff-Bits, falsche Statusbits oder falscher CRC (oder ein Sender / Empfänger schlicht mit falscher Frequenz läuft). Bei unterschiedlichen IDs gibt der Sender mit niedrigerer Priorität der ID auf (s.o.) korrigiert--NobbiP 10:32, 15. Jan. 2007 (CET). Bei gleicher ID, kann sogar der ganze Frame durchlaufen und als gültig angesehen werden, wenn die Daten auch gleich sind. (Theoretisches Beispiel: aus Versehen 2 gleiche Peripherien, die auf Request die gleiche Nachricht senden, z.B. ewine Systemtemperatur oder Uhrzeit) --NobbiP 13:51, 5. Jan. 2007 (CET)

Ich hab das mal angepasst. -- Nautsch 14:51, 5. Jan. 2007 (CET)

Bei unterschiedlicher Adresse (Arbitration Field) wird durch den dominanten Zustand "LOW" bei CAN der Sender mit höherer ID aufgeben (nicht wie oben beschrieben mit niedrigerer ID. Das Arbitrierungsfeld besteht aus dem Identifier und dem Remote-Bit. Über den Identifier (je nach CAN-Specification Version 2.0A mit elf, bei Version 2.0B mit zusätzlichen 18 Identifier-Bits) wird eine Nachricht gekennzeichnet und deren Priorität festgelegt. Das Anforderungsbit (Remote Transmission Request Bit, RTR) unterscheidet zwischen Daten- und Anforderungstelegramm. Da es sinnvoll ist, einem Datentelegramm gegenüber einer gleichzeitigen Anforderung derselben Nachricht den Vorzug zu geben, wird das RTR-Bit einer Anforderung rezessiv gesendet. --Thomas Kuschel 16:32, 10. Jan. 2007 (CET)

Das ist ja alles richtig, aber was (bis auf den Dreher mit den IDs von NobbiP) möchtest du damit sagen? Die Funktionsweise der Arbitrierung ist uns doch klar!? Nautsch 09:30, 15. Jan. 2007 (CET)

sicherheitsgerichtete Daten?

Ich habe das schon mehrfach auf Hochglanzseiten gelesen. Aber ich weis nicht was das ist. Wer kann mir helfen?--Kölscher Pitter 22:35, 17. Aug. 2007 (CEST)

Hi, vergleiche dazu vielleicht Sicherheitsanforderungsstufe, Grüßle NobbiP 23:10, 17. Aug. 2007 (CEST)

Danke NoppiP. Aber in dem Artikel Sicherheitsanforderungsstufe wird wieder einmal Sicherheit und Zuverlässigkeit in unzulässiger Weise verknüpft. Beides sind völlig unabhängige Begriffe. Was "sicherheitsgerichtete Daten" damit zu tun habenm bleibt mir verborgen.--Kölscher Pitter 08:36, 18. Aug. 2007 (CEST)

Topolgie

Da wird was geschrieben von ringförmiger Topologie - NEIN, das gibt's bei CAN nicht. Wenn das auf logischer Ebene geschieht, hat das nicht mehr viel mit der Bus-Topologie zu tun. Das kann man dann eher als Redundanz-Frage behandeln. Ich bin dafür, das wieder rauszunehmen, da es falsch und sehr verwirrend ist. JuergenKlueser 10:29, 6. Sep. 2007 (CEST)

Also ich habe das nicht geschrieben und ich habe auch noch keinen Ring-CAN gesehen. Das sagt aber gar nichts. Im Automotive-Bereich scheint es schlechthin alles zu geben, vor allem auch jenseits der eigentlichen Standards. Wenn es also doch einen Autohersteller geben sollte, der einen Ring-CAN einbaut, würde mich das nicht mehr wundern. --PeterFrankfurt 00:05, 7. Sep. 2007 (CEST)

Wir sind im Automobilbereich tätig und einen CAN-Ring gibt es dort nicht. Um es vielleicht klarer auszudrücken: Man kann ja durchaus Ring-Strukturen aufbauen, das ist dann aber eine logische Ebene über CAN und hat mit CAN nichts zu tun. Im Extrembeispiel mache man einen Ring mit 2 Steuergeräten - jedes hat dann 2 CAN-Controller. Das ist dann das gleiche, wie 2 CAN redundant. Die Applikationsschicht ist dann verantwortlich, Datenkonsistenz etc. zu gewährleisten. Jeder einzelne CAN-Controller "weiss" von der Sache aber gar nichts. JuergenKlueser 10:57, 13. Sep. 2007 (CEST)

Ich war auch im Automobilbereich tätig und hatte vor allem die nützliche Erfahrung, es dabei mit verschiedenen Herstellern zu tun gehabt zu haben. Und da war eines der Aha-Erlebnisse, wie stark doch die Implementierungen der Hersteller voneinander abweichen. Seitdem halte ich eben nichts mehr für unmöglich. Beim langsamen Info-CAN, der auch schon mal eindrahtig läuft, sind die elektrischen Verhältnisse so unkritisch, dass der auch einen Ring vertragen würde. --PeterFrankfurt 14:06, 13. Sep. 2007 (CEST)

Hallo Peter, Du hast schon Recht. Es wird vieles gemacht. Wenn hier aber CAN beschrieben wird, sollten nicht die abstrusesten Dinge da stehen, die dem Neueinsteiger vermitteln, dass sie normal seien. Bin nach wie vor der Meinung, die Ringtopologie gehört raus. (Siehe meine Anmerkung zu logischer Ebene). Ich selbst werde es nicht rauslöschen, sonst macht's nur sonst jemand wieder rückgängig. Viele Grüße aus Stuttgart JuergenKlueser 09:01, 6. Feb. 2008 (CET)

Also ich rühr da jetzt lieber auch nicht dran. --PeterFrankfurt 22:24, 6. Feb. 2008 (CET)

Ich habe jetzt gerade den Ring gelöscht. Beim CAN gibt es den nicht. Die im Artikel erwähnte Ringstruktur im Infotainment gibt es zwar, aber mit dem optischen MOST-Bus und nicht mit dem CAN. P.S. Stern sollte nach reiner Lehre auch nicht sein, ist aber gängige Praxis, um nicht zigmal den Kabelbaum anzapfen zu müssen. Solange die Stichleitungen kurz sind gegenüber der Wellenlänge funktioniert der auch ohne Probleme.--KaiBorgeest 00:01, 17. Aug. 2009 (CEST)

Testen eines CAN Netzwerk

Aua, das sieht ja schlimm aus. Erstens extremes Denglisch und zweitens offensichtlich eine Wort-für-Wort-Übersetzung eines englischen Werbetextes (von Agilent?). Neben diesen qualitativen Aspekten: Muss man da evtl. eine URV fürchten? --PeterFrankfurt 01:04, 15. Mär. 2008 (CET)

Sehe ich genauso JuergenKlueser 09:29, 20. Mär. 2008 (CET)

Außerdem ist die Frage was dieser Abschnitt hier zu suchen hat. Selbst wenn man ihn sprachlich verbessern würde, hat er wenig mit CAN zu tun. Denn inhaltlich trifft dies alles auch auf LIN, FlexRay und jedes andere Kommunikationssystem zu. Überall müsste man entsprechende Tests durchführen. Die einen machen es und die anderen nicht. --MisterTS 09:24, 13. Mai 2008 (CEST)

CSMA/CA oder /CR?

CA heißt Kollisionsvermeidung, CR Kollisionsauflösung. Die Begriffe werden nicht immer sauber getrennt. Beim CAN können während der Arbitrierung mehrere Knoten gleichzeitig senden, der mit der höchsten Prio bleibt im Rennen (CR). Damit werden kritische Kollisionen verhindert, im weitesten Sinne wäre der Ausdruck CA also auch tolerierbar. CR ist aber treffender, deswegen habe ich die Änderung von CR nach CA im Artikel wieder zurückgesetzt, statt sie zu sichten.--KaiBorgeest 23:27, 17. Sep. 2009 (CEST)

Laut verschiedenen Quellen wird bei CAN allerdings CSMA/CA eingesetzt. Siehe z.b. Vector: http://www.vector-elearning.com/index.php?&wbt_ls_seite_id=451402&root=376493&seite=vl_einfuehrungcan_de. In der englischen Wikipedia wird CSMA/BA (Bitweise Arbitrierung) genannt. Ich finde das sehr inkonsistent und verwirrend. -- 193.196.7.169 09:24, 26. Nov. 2009 (CET)

Die ISO11898-1/2 referenzieren CSMA, aber ohne jeden Zusatz. Die Referenzierung von CA in fast allen Veröffentlichungen (auch in unseren eigenen) ist eher als historisch zu sehen. Habe mit einem der damaligen Entwickler von CAN gesprochen. Er sagt auch, dass CSMA/CR korrekt ist. Wichtig ist, dass CR wie von Prof. Borgeest geschrieben für Collision Resolution steht und nicht für Collision Recovery, da keine destruktiven Kollisionen stattfinden. Gruß --JuergenKlueser 11:33, 27. Nov. 2009 (CET)

CRC

Hi,

kann einer mit den CRC für ein bestimmtes Bitmuster einer CAN-Nachricht einmal herleiten ? Wie prinzipiel ein CRC berechnet wird ist mir klar, aber irgendwie haut dies bei einer CAN-msg nicht hin. (BCH-Code mit entsprechendem Generatorpolynom).

ps: Die Berechnung der CRC's hier in Wikipedia ist klar, siehe Zyklische Redundanzprüfung. gruss dm (nicht signierter Beitrag von 141.51.111.15 (Diskussion | Beiträge) 16:48, 28. Jul. 2004 (CEST))

Also CAN nutzt ja einen CRC-16 Code, der das Arbitration-, Control- und Data-Field einbezieht. Wenn Du das genaue Generatorpolynom hast, dann musst Du doch nur eine Polynomdivision durchführen und erhältst dann das CRC Feld!? Omit 12:58, 26. Mai 2005 (CEST)

CAN nutzt einen CRC-15 Code ($G(x)=x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1$). Das zu prüfende Datenwort besteht aus Arbitration-, Control-, Data-Field plus 15 Nullen! --87.163.242.18 17:48, 23. Mär. 2007 (CET)

Was soll denn das bedeuten?

Ein Teilnehmer kann Empfänger und Sender von Nachrichten beliebig vieler Identifier sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben (damit die Arbitrierung funktioniert).

Da stimmt doch was nicht oder bin ich doof? (nicht signierter Beitrag von 84.191.120.57 (Diskussion | Beiträge) 16:00, 3. Jul. 2005 (CEST))

Ich denke das soll folgendes bedeuten: Ein Motorsteuergerät (Teilnehmer) kann z.B. auf ID768, ID233 und auf ID531 senden. Im Netzverbund muss dann aber das Motorsteuergerät das einzige Steuergerät sein, das auf ID768, ID233 und ID531 sendet, kein anderes Steuergerät darf auf einer dieser IDs senden. Somit ist der Satz oben korrekt, den das Steuergerät sendet in unserem Beispiel auf drei IDs, jede ID ist aber im Netzwerk genau einem Sender (wenn auch in unserem Beispiel dem gleichen) zugeordnet.

--Timo Engelmann 09:13, 4. Aug 2005 (CEST)

Liegt daran dass die Arbitrierung im ID-Feld geschieht, ein späteres "Überschreiben" eines gesendeten Bits würde der Sender mit einem Errorframe quittieren (natürlich passiert das dann nur in dem Fall wenn beide Steuergeräte dieselbe ID im selben Moment abschicken würden) (nicht signierter Beitrag von 80.134.41.225 (Diskussion | Beiträge) 20:19, 19. Jan. 2006 (CET))

Soweit ich das beurteilen kann bedeutet es, dass eine Nachricht mit einem Identifier nur einmal existieren darf um dem Gesetz der Arbitrierung zu folgen. Soll heißen, ein Steuergerät sendet eine Nachricht die nur einmal existiert aber von jedem Steuergerät das diese Nachricht auch empfangen soll gelesen werden kann.

Ein Steuergerät sendet allerdings NICHT einem speziellen anderem Steuergerät eine Nachricht, sondern "legt" die Nachricht auf den BUS. Die Steuergeräte, die die Nachricht empfangen sollen holen sie sich -unter Beachtung der Arbitrierung- dann.

Gruß D.B. (nicht signierter Beitrag von 84.150.170.225 (Diskussion | Beiträge) 15:25, 21. Mär. 2008 (CET))

Kommunikationsmatrix

Mir fehlt in dem Artikel die Erklärung der Kommunikationsmatrix, auch K-Matrix oder CAN-Matrix. Über diese wird spezifiziert, welcher Busteilnehmer welche Nachrichten sendet und welche Nachrichten er empfängt. (nicht signierter Beitrag von 193.174.9.65 (Diskussion | Beiträge) 15:36, 31. Mär. 2006 (CEST))

Was hat die Kommunikationsmatrix mit CAN zu tun? Wenn ich es richtig verstehe, ist die Kommunikationsmatrix nur ein Hilfmittel bei der Systemintegration, um Fehler in den Kommunikationsbeziehungen zwischen den Teilnehmern zu finden. Dies hat primär nichts mit CAN gemein. Dies muß bei jedem Broad-/Multicast-Netzwerk gemacht werden, z. B. auch bei Ethernet. --MisterTS 15:08, 27. Apr 2006 (CEST)

Nein, die K-Matrix hat primär nichts mit Fehlersuche zu tun. Beim CAN werden sämtliche Nachrichten die über den Bus verschickt werden bereits während der Systemintegration spezifiziert. Hier steht welches Steuergerät welche Nachricht verschickt und welche es empfängt (empfangen = nicht verwerfen, da alle Busteilnehmer mithören) und welches Bit in welcher Nachricht was bedeutet.

Beim Ethernet z.B. ist es unmöglich alle Nachrichten im Voraus festzulegen, dazu gibt es dann das OSI-Modell... (nicht signierter Beitrag von 193.174.9.65 (Diskussion | Beiträge) 16:38, 5. Mai 2006 (CEST))

Das könnte man aber auch für Ethernet festlegen, wenn man propritäre Protokolle basierend auf Ethernet verwendet. Außerdem was hat dies mit dem OSI-Modell zu tun? Das OSI-Modell gilt auch für CAN. Außerdem wie ist es bei CANopen, DeviceNet, SDS oder J1939? Sind bei diesen höheren CAN-basierenden Protokollen auch schon alle Nachrichten während der Systemintegration spezifiziert? Bei J1939 könnte man sagen: Jaein. Bei CANopen auf alle Fälle: Nein.

Daher: die K-Matrix ist etwas Automotive spezifisches, welche so gesehen für jedes propritäres Protokoll existieren kann, aber nicht muß. Dabei ist es sogar unerheblich, ob es CAN, Flexray oder irgendetwas anderes wie z. B. Ethernet ist. Daher meine Meinung: Sie hat nichts mit CAN zu tun und sollte daher hier nicht erklärt werden. Andererseits könnte man von hier aus darauf verweisen im Zusammenhang mit den höheren CAN-basierenden Protokollen. --MisterTS 22:13, 6. Mai 2006 (CEST)

Nachtrag: Provokativ könnte ich sogar behaupten, daß die K-Matrix ein Hilfsmittel ist, die man für jedes Kommunikationssystem benötigt. Selbst bei jedem Master/Slave-basierenden System kann man eine K-Matrix aufstellen. Auch wenn es etwas sinnfrei ist, da jede Nachricht genau einen Sender und genau einen Empfänger besitzt. Dagegen bei jedem Broadcast- oder Multicast-Netzwerk macht es sehr wohl Sinn eine solche K-Matrix aufzustellen, unabhängig von CAN. Andererseits nach Deiner Definition benötigt jedes Kommunikationssytem, welches ein ordentliches Netzwerkmanagement besitzt keine K-Matrix. (nicht signierter Beitrag von MisterTS (Diskussion | Beiträge) 22:27, 6. Mai 2006 (CEST))

Logo auf der Seite

Hallo, was hat das CiA Logo auf der Wiki Seite von CAN verloren? Die CiA ist eine von vielen Institutionen die höhere Software Layer für das CAN Protokol in einem "Verein" unterstützen. Warum steht dann nicht auch das ODVA Logo, oder SSD, oder CAN Kingdom oder TTCAN (OK hier ist die phys. Anbindung noch etwas anders). Die Gesammtmenge verkaufter CAN Chips ist in der Automobilbranche wohl um ein vielfaches höher als in der Automatisierungstechnik. CAN kommt eben aus dem mobilem Bereich und ein Logo aus der Industriewelt als "das Logo für CAN" auf der Seite oben rechts darzustellen ist meiner Meinung nach falsch.Im Bereich industrielle Kommunikation OK, aber nicht "global" als CAN Logo--UweWilhelm 09:27, 9. Nov. 2011 (CET)

Hi, das denke ich auch. Zu einem anderen Abschnitt im Artikel passt es auch nicht wirklich. Deswegen rausgenommen.--Phry (Disk) 10:59, 9. Nov. 2011 (CET)

Dieser Abschnitt kann archiviert werden. --Phry (Disk) 08:27, 16. Nov. 2011 (CET)

Übertragungsrate

Hallo! Wie wird denn die Übertragungsrate im CAN-Bus definiert? In Kbit/s oder in Baud? Ich hab schon in mehreren Quellen nachgelesen, aber einmal so, einmal so... Weis jemand genaueres?

Gruß Markus (nicht signierter Beitrag von 84.153.38.27 (Diskussion | Beiträge) 18:55, 11. Jul. 2005 (CEST))

Ich habe da mal einen kleinen Tip für Dich. Schaue einmal bei Wikipedia nach wie ein Baud definiert ist ;-) . Bei CAN gilt die Eigenschaft, daß in einem Übertragungsschritt ein Symbol übertragen wird. Damit kann man baud und bps wieder gleichsetzen. Allerdings verwenden viele baud auch falsch (habe ich bis vorkurzem auch).

MisterTS 20:20, 25. Aug 2005 (CEST)

Hallo, bei der Übertragunsrate und Leitungslänge des CAN-Bus spielt die Lichtgeschwindigkeit (Ausbreitungsgeschwindigkeit) keine Rolle! Eher spielen Kapazitäten und Induktivitäten eine entscheidende Rolle und wirken bei zunehmender Leitungslänge und Übertragungsrate flankenglättend!

Hermi1081 13:26, 3. Sep 2012 (CEST)

synchrones oder asynchrones Übertragungsverfahren

Hallo!

Meiner Meinung nach ist CAN kein asynchrones Übertragungsverfahren sondern ein synchrones. Für asynchrone Übertragungen ist das Datentelegramm viel zu lang. Wenn der Empfänger nur einmal am Anfang (Startbit) synchronisieren würde, würden sich Fehler bis zum Schluss aufsummieren und der Empfänger würde ein falsches Bit detektieren. Bei CAN ist der Takt in das Telegramm "moduliert". Siehe Leitungskodierung!

Viel Spaß noch!

Andreas (nicht signierter Beitrag von 84.180.234.145 (Diskussion | Beiträge) 19:33, 19. Jul. 2005 (CEST))

Ja und nein. CAN ist wie Ethernet und RS232 ein asynchrones Verfahren. Es gibt kein klassisches Taktsignal, sei es durch eine getrennte Leitung oder durch ein kontinuierliches Signal auf dem Übertragungsmedium. Auf der anderen Seite ist es während der Übertragung synchron, denn das Bitstuffing garantiert eine Synchronisierung.

MisterTS 20:26, 25. Aug 2005 (CEST)

Ich bin grade auch über das adjektiv asynchron im Text gestolpert. Ich bin der Meinung, dass CAN auf Frame-Ebene betrachtet ein asynchrones Verfahren ist, aber auf Bit-Ebene betrachtet ein Synchrones Verfahren ist, da nur so die Dinge wie Arbitrierung oder Retransmission sicher gestellt werden können. Daher werde ich das adjektiv asynchron jetzt aus dem ersten Satz entfernen. --Hendiadyon (Diskussion) (10:49, 9. Aug. 2013 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

CANBasic-Werbung

Hi, am 16.Mai 2013 hat der Benutzer Erniotti mehrere Erweiterungen mit Bildern, die von canbasic stammen in den Artikel eingefügt. Meines Erachtens machen die meisten davon den Artikel nicht verständlicher, sondern sind eher Werbung für Produkte der Firma Ingendi (www.canbasic.com), deren Geschäftsführer den gleichen Namen wie der Benutzer Erniotti hat... Was tun? --82.166.137.197 16:04, 20. Jun. 2013 (CEST)

Bin der gleichen Meinung. Das Bild mit dem Auto bringt nicht viel. Die Screenshots sind OK, so lange nichts besseres eingefügt werden kann. Der Link zum Youtube Video, na ja ganz Lustig und für Einsteiger vielleicht ganz gut. --87.189.81.103 17:20, 11. Aug. 2013 (CEST) (Sorry, war wohl nicht angemeldet --Plupp (Diskussion) 18:05, 11. Aug. 2013 (CEST) )

Omatauglichkeit ???

Liebe Leute, wenn morgen irgendwas streikt und ich mich in die Programmierung das CAN-Bus einlesen muss, dann spare ich vermutlich viel Geld, weil dieses ein hervorragender Fachbuchartikel ist. Die immer eingeforderte Omatauglichkeit kann ansonsten aber auch nicht stärker und vorsätzlicher mit Füßen treten als hier geschehen!

Könnte mal bitte erstmal jemand definieren, was ein CAN-Bus faktisch (!!) im Fahrzeug genau ist und wo er faktisch (!!) relevant ist? Soweit wie bei der digitalen Modellbaueisenbahn, wo fast nichts mehr eine eigene Stromversorgung mit eigenen Kabeln hat, sind wir im PKW-Bereich noch lange nicht. Das hat mit "Spaßvogel" weiter oben ja schon jemand deutlich erwähnt. Die absolute Überzahl aller Verbraucher ist in vielen Fahrzeugen ja wohl noch ganz klassisch geschaltet. Also: Batterie/LiMa > Sicherung > Schalter > Verbraucher > Fahrzeugmasse, alles via Kupferleitung. Zumindest, solange wir von einem Mittelklassewagen mit durchschnittlicher Ausstattung und nicht von einer Luxuskarosse reden.

Welche Elemente in einem Fahrzeug sind´s denn nun, die idealtypisch oder mehrheitlich, die über CAN-Bus gesteuert. Also nach dem Motto: Batterie/LiMa > Sicherung > Dauerplus an Verbraucher / zzgl. Signal über CAN-Bus?

Nachtrag: Leute!!! Das glaubt man ja nicht! Gerade nochmal alles durchgelesen, was wurde bereits 2005, also vor fast 10 Jahren, sehr sachlich und konstruktiv angemerkt. Seitem Hundert von Edits. Nur diesem basalen und unverzichtbaren Punkt hat sich noch keiner angenommen. Unglaublich! Um was geht´s manchen Autoren hier eigentlich? Darum, altruistisch einen helfenden, allgemeinverständlichen Artikel für die Allgemeinheit zu verfassen? Oder darum,einerseits anonym und unerkannt, andererseits aber öffentlich und potentiell kritiserbar mit abgedrehtem Fachwissen zu glänzen und sich zu freuen, wenn es von anderen Fachleuten nicht zerissen wird? --82.82.87.48 09:16, 27. Apr. 2014 (CEST)

Dein Anliegen in allen Ehren, aber ... Ein CAN-Bus ist nix für den Hobbyisten, die sollte man eher abschrecken, als ihnen aus Versehen irgendwelche Bastelanleitungen zu geben. Wenn Du wissen willst, wo er genau verwendet wird, muss man erstmal die Schweizer Antwort geben: Das ist von Hersteller zu Hersteller und von Modell zu Modell höchst verschieden. Ich selbst fahre einen Kleinwagen, da spielt sich nicht arg viel ab. Aber schon beim VW Golf läuft nichts mehr ohne CAN, das fängt bei so Kleinigkeiten wie dem Motorhauben- und Heckklappensensor an, Sensoren für Türen, Tankinhalt an, und das ist nur der langsame "Komfort-CAN". Auf dem schnellen "Motor-CAN" laufen dann vor allem die Daten des Motorsteuergeräts, Einspritzpumpe und Co, auf dem Weg kommen beispielsweise die Drehzahlwerte zur Anzeige vorne ins Cockpit. --PeterFrankfurt (Diskussion) 03:14, 28. Apr. 2014 (CEST)

Wie bitte? Lies dir bitte mal beliebige betreffende WP-Richtlinien durch, wie ein Artikel geschrieben werden müsste, wenn man es denn machen würde. Falscher kann man es nicht machen als einen Artikel so zu schreiben, dass etwas gewissermaßen als "Blackbox" angesehen wird und nur die internen Geheimnisse der Blackbock gelüftet werden, Sinn und Einsatz der Blackbox aber quasi nicht a-n-s-a-t-z-w-e-i-s-e genannt werden. Wenn es eben nur etwas ungenau abgegrenzt werden kann, was ein CAN-Bus von PKW zu PKW regel, dann kann und muss man auch das eben genau so schreiben.

vgl.: "Was Wikipedia nicht ist:", dort: "Wikipedia ist keine Sammlung von Anleitungen und Ratgebern. Es ist nicht Aufgabe der Wikipedia, zu erklären, wie man eine Redewendung, ein Gerät oder eine Software verwendet... Mit der Erstellung von Lehrbüchern und anderen Sachbüchern beschäftigt sich das Schwesterprojekt Wikibooks "

vgl. ebenso: "Grundprinzipien: "Wikipedia ist ein gemeinschaftliches Projekt mit dem Ziel, eine Enzyklopädie von bestmöglicher Qualität zu schaffen." Gemeinschaflich! Wenn hier mehrere Leute (seit Jahren!) sagen, da fehlt was Wichtiges, dann zählt das auch. Dann zählt kein Wächteramt der Autoren.

vgl: "Artikel", dort "Inhalt und Form": Ein Artikel muss inhaltlich sein Thema definieren. Der Autor darf nicht voraussetzen, dass der Leser schon wissen wird, was der Gegenstand ist – die Definition zu liefern, ist die erste Aufgabe einer Enzyklopädie.

--82.82.87.48 06:08, 28. Apr. 2014 (CEST)

Geh mal davon aus, dass im Artikel nicht mal ansatzweise steht, wie man den CAN programmiert (bzgl. Deines ersten Satzes...). Der Artikel beschreibt schlicht und einfach ein heute übliches Bussystem. Du hast sicher recht, dass man etwas mehr über die Verwendung schreiben könnte. Aber wo ist das Problem? Mach's doch! --JuergenKlueser (Diskussion) 08:28, 28. Apr. 2014 (CEST)

"...wie man den CAN programmiert (bzgl. Deines ersten Satzes..." war auch durchaus nicht ganz ernst&wörtlich gemeint, sondern sollte Ist- und Sollzustand deutlich erklären. Ich habe es aufgegeben, in Wikipedia etwas selbst zu schreiben, dazu glucken die Erstautoren viel zu oft viel zu dicht auf ihren Artikeln. Eine durchaus gute und verständliche Beschreibung gibt es im WWW aber bei KFZ-Tech, dort unter CAN-Bus, die man leicht umgearbeitet (um nicht zu kopieren) sicherlich übernehmen könnte --88.70.3.68 07:15, 3. Mai 2014 (CEST)

datenrate!!!!

Ich finde nirgends eine Angabe über die Datenraten bei Can oder über den Takt! Wie erkennt der Endteilnehmer, wie lange ein bit ist? 80.146.181.123 14:34, 15. Apr. 2016 (CEST)

erledigt --Rainald62 (Diskussion) 01:12, 16. Apr. 2016 (CEST)

Ich muss das nochmal aufmachen. Unter der Überschrift "Maximale Übertragungsrate und Leitungslänge" findet man zwar Beispiele zur Datenrate in Kombination zur Leitungslänge, aber keine konkrete Spezifikation. Gibt es diese? Wenn ja, wäre die Taktfrequenz und die Mindest- bzw. Maximaldatenrate anzugeben. -- Dr. Schorsch*? 09:45, 18. Dez. 2019 (CET)

Mea culpa, da stand wirklich schon was. Ich habe es aber etwas (wie ich finde) lesbarer gestaltet, damit auch ich die Information finden kann. :-) Ich habe von der EN-Wiki noch einen Hinweis auf CAN FD eingebaut. -- Dr. Schorsch*? 09:59, 18. Dez. 2019 (CET)