Diskussion:Controller Area Network/Archiv/1

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Arbitrierung 

message: 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)
replies: text:  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)
thread_title:  Kapazität und deren Einfluss auf die maximale Anzahl der Knoten 

message: 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)
replies: text: 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)
replies: text: Ich hab das mal angepasst. -- Nautsch 14:51, 5. Jan. 2007 (CET)

text: 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)
thread_title:  Errorframe bei gleicher ID zweier Sender? 

message: 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)
replies: text: Hi, vergleiche dazu vielleicht Sicherheitsanforderungsstufe, Grüßle NobbiP 23:10, 17. Aug. 2007 (CEST)
thread_title:  sicherheitsgerichtete Daten? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: Also ich rühr da jetzt lieber auch nicht dran. --PeterFrankfurt 22:24, 6. Feb. 2008 (CET)
replies: text: 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)
thread_title:  Topolgie 

message: 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)
replies: text: Sehe ich genauso JuergenKlueser 09:29, 20. Mär. 2008 (CET)
replies: text:  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)
thread_title:  Testen eines CAN Netzwerk 

message: 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)
replies: text: 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)
thread_title:  CSMA/CA oder /CR? 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  CRC 

message: 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)
replies: text: 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)
thread_title:  Logo auf der Seite 

message: 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)
replies: text: 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)
thread_title:  CANBasic-Werbung 

message: 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)
replies: text: erledigt --Rainald62 (Diskussion) 01:12, 16. Apr. 2016 (CEST)
replies: text:  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)
replies: text:  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)
thread_title:  datenrate!!!!