Hallo, ich plane gerade, mir ein RS485-Bus aufzubauen. Zuerst wollte ich CAN nutzen, bin dann aber doch auf RS485 umgestiegen, da mir die Datenrate bei zu langer Leitungslänge zu gering war (wird am Ende etwa insgesamt 1km Cat5-Kabel sein (mit allen Abzweigungen), und 250kbit/s hätte ich schon gerne). Die Bandbreite brauch ich halt, da ich teilweise auch Audio-Daten übertrage. Außerdem erschien es mir doch einfacher für die doch stark ausgelasteten Controller der Slaves, ein simples UART-Protokoll zu handhaben anstelle von CAN. Zudem scheint es ja bei CAN keine Möglichkeit zu geben, bei insg. 1km Leitungslänge Datenraten von 250kbit/s zu erreichen, auch habe ich keine wirklichen Hubs für CAN gefunden, wie sie für RS485 existieren :/ Ich habe also vor, meinen RS485-Bus ähnlich DMX aufzubauen, d.h. ein Segment hat max. 300m, dann kommt ein Repeater, max 32. Slaves pro Segment, etc. Das Protokoll ist recht simpel, es besteht aus 4 Byte, das erste Byte enthält die Adresse und die 3 anderen Bytes enthalten Daten. Theo. muss ein Slave nur schauen, ob seine Adresse übereinstimmt, falls nein die nächsten 3 Bytes ignorieren und dann nochmal nachschauen. Es gibt im Bus einen Master, der über einen extra RS485-Kanal seine Daten an die Slaves sendet. Auf diesem Kanal sendet auch NUR der Master, von daher dürfte es hier zu keiner Kollision kommen. Zugleich hab ich noch einen Rückkanal, der dazu dient, Daten von den Slaves zum Master zu senden, falls der Master Daten anfordert. Und dies ist mein Problem. Normalerweise dürfte ja nichts schief gehen, aber es könnte ja, aus irgendwelchen Gründen, plötzlich ein Slave auf die Idee kommen, Daten zu senden (oder sendet seine Daten zeitlich verzögert, sodass ein andere Slave bereits sendet) und es kommt zu einer Kollision. Wie kann ich dies nun verhindern bzw. erkennen. Wie ich bisher in Erfahrung bringen konnte, geht dies mit RS485-Treiber nicht, da hier eine Kollision ein Kurzschluss ist. Also müsste ich für eine Kollision-Erkennung CAN-Treiber verwenden, richtig? Am besten würde ich es jedoch finden, wenn ich irgendwie erkennen könnte, ob Daten bereits auf dem Rückkanal gesendet werden. Jedoch weiß ich nicht, wie. Wenn ich CAN-Treiber nutzen würde, könnte ich ja einfach Rx auf den RX-Pin des Atmegas legen, aber dummerweise ist der schon mit dem RS485-Kanal vom Master beleget. Von daher wollte ich mal Fragen, ob es eine Möglichkeit gibt, mithilfe eines "normalen" Pin eines Atmegas festzustellen, ob auf dem Bus gerade gesendet wird. Dann könnte der Slave ja einfach warten, bis niemand mehr sendet. Hoffe, ihr könnt mir etwas weiterhelfen, oder mit evtl. doch wieder CAN schmackhaft machen, aber wie gesagt, Grundbedingung wäre, dass günstige HUBs verfügbar sind, sodass ich Segmente à 300m zu insgesamt etwa 1km Leitung zusammenschließen kann und trotzdem Datenraten von etwa 250kbit/s erreiche. So, viel Text, mal hoffen, dass es nicht abschreckt ;) Viele Grüße Julian
Julian W. schrieb: > Am besten würde ich es jedoch finden, wenn ich irgendwie erkennen > könnte, ob Daten bereits auf dem Rückkanal gesendet werden. Jedoch weiß > ich nicht, wie. Hallo Julian, das verhindert Kollisionen nicht: hört ein Client auf zu senden, dann können 2 oder mehr andere Clients auf die Idee kommen, ihrerseits Daten zu senden. Wie man das einschränkt, ist bei Ethernet beschrieben (das ist CS - Carrier Sense - in CSMA-CD), aber damit werden Kollisionen nur seltener, nicht unmöglich. Deswegen ist trotzdem "Collision Detect" erforderlich (das CD ins CSMA-CD). Ein deterministisch geregelter Zugriff ist nur möglich, wenn ein Token kreist oder in einer Master-Slave-Umgebung der Master bestimmt, wer wann senden darf. Also zurück auf Los. Gruss Reinhard
Hallo Julian, in einer ähnlichen Situation - aber ohne zwei Kanäle - haben wir uns entschlossen, CAN-Treiber, aber kein CAN-Protokoll zu verwenden. Die Treiber sind kollisionsfest, der zurückgelesene Wert ist eindeutig definiert - die Kollision ist sauber erkennbar. Wir lesen das Echo zurück und senden das nächste Byte erst und nur, wenn das Echo des letzten angekommen ist. Also Byte-weise CD, wenn Du so willst. Es gibt also Kollisionen, aber sie werden behandelt. Das geht natürlich zu Lasten des Durchsatzes, weil immer wieder gewartet und gelegentlich abgebrochen wird. Das Gegenkonzept ist der Token, der das Senden sauber regelt. Wenn Du das richtig implementierst, kann es kaum zu Kollisionen kommen. Selbst wenn ein Client verzögert reagiert, liefert er ja erst zum Schluss den Token zurück - vorher darf keiner senden. Auch eine Master-Slave-Organisation würde zu diesem Effekt führen, Reinhard hat da völlig Recht. In beiden Fällen musst Du aber andere Probleme lösen, das Recovery eines verlorenen Tokens oder ein ausgefallener Master. Gruß Jens
Wenn man schon 2 separate differentielle Busse verwendet, dann kann man vielleicht auch so frech sein, echtes CAN für Steuerung und Arbitrierung und echtes RS485 für hohen Datendurchsatz zu kombinieren ;-).
Mist, geht also auch nicht. Eine Idee, die ich noch hatte, war einfach eine zusätzliche Leitung zu verlegen. Wenn ein Slave sendet, zieht er diese auf High und nachher auf Low. Dummerweise müsste ich dafür nun eine zusätzliche Leitung ziehen und zudem weiß ich nicht, ob da nach 300m auch noch sicher High anliegt, also auch alles sehr "wackelig". Das mit dem Token hab ich mir auch schon überlegt, aber das Problem mit dem verloren Token hasst du ja schon angesprochen. Der ausgefallene Master müsste ich nicht behandeln, dass wäre nämlich der SuperGAU und damit würde eh erst mal alles still stehen ;) Also da würde ich ja fast wieder auf CAN zurückkommen, aber dafür müsste ich zwingend Segmente mit jeweils 300m so miteinander verbinden, sodass ich die 250kbit/s erreiche (wobei, da muss ich ja noch jede Menge Overhead durch Can abziehen...). Und der einzige IC, der "gerade mal" 2 CAN-Segmente miteinander verbinden kann, kostet fast 13€ bei farnell, was mir etwas teuer ist :/ ON SEMICONDUCTOR - AMIS42770ICAW1RG http://de.farnell.com/on-semiconductor/amis42770icaw1rg/ic-can-txrx-1mbps-1-1-5-25v-soic/dp/1641442?Ntt=AMIS42770 Oder was denkt ihr, ist es mit einem Atmega und mehreren CAN-Controllern möglich, 250kbit/s "durchzureichen", wobei dann auch Probleme mit Kollisionen auftreten könnten, ich puffern muss, ....
A. K. schrieb: > Wenn man schon 2 separate differentielle Busse verwendet, dann kann man > vielleicht auch so frech sein, echtes CAN für Steuerung und Arbitrierung > und echtes RS485 für hohen Datendurchsatz zu kombinieren ;-). Das wäre noch eine Lösung, bei etwa 1km hätte ich bei CAN immerhin noch 50kbti/s, die könnten reichen...
Julian W. schrieb: > ich plane gerade, mir ein RS485-Bus aufzubauen. Warum? > Zuerst wollte ich CAN > nutzen, bin dann aber doch auf RS485 umgestiegen, da mir die Datenrate > bei zu langer Leitungslänge zu gering war Bei CAN ist die Kollisionserkennung so gebaut das sich lange Leitungslängen und hohe Datenraten faktisch ausschließen > (wird am Ende etwa insgesamt > 1km Cat5-Kabel sein (mit allen Abzweigungen), und du hast auch an den Wellenwiderstand die Leitungsreflektionen an Abschlusswiderstände und Interferenzen gedacht? > und 250kbit/s hätte ich > schon gerne). Die Bandbreite brauch ich halt, da ich teilweise auch > Audio-Daten übertrage. Warum nimmst du dann nicht Ethernet? > Außerdem erschien es mir doch einfacher für die doch stark ausgelasteten > Controller der Slaves, ein simples UART-Protokoll zu handhaben anstelle > von CAN. Wenn die Slaves so stark ausgelastet sind wie sollen Sie auch noch die doch eher ineffizeinte ungesicherte RS485 Übertragung managen? > Zudem scheint es ja bei CAN keine Möglichkeit zu geben, bei > insg. 1km Leitungslänge Datenraten von 250kbit/s zu erreichen, s.o. > auch habe > ich keine wirklichen Hubs für CAN gefunden, Du brauchst auch eine Bridge. > wie sie für RS485 existieren Wobei die Frage wie die bei diesem Tempo mit der Adressierung umgehen was für Spezies ist. Das ist sicher alles nicht falsch, nur hast du keinerlei Sicherungsschicht wenn Störungen auftreten (was bei dieser Leitungslänge sicher nicht ungewöhnlich wäre). Einfacher ist es sicher die Daten asynchron auf die Reise zu schicken, nur was auf der anderen Seite bei dem Tempo ankommt hängt von den Umständen ab auf die deine Bitpäckche nunterwegs reffen.
Jens Martin schrieb: >> ich plane gerade, mir ein RS485-Bus aufzubauen. > > Warum? Ist quasi mein "Pilot-Projekt" zur Hausautomatisierung Jens Martin schrieb: >> Außerdem erschien es mir doch einfacher für die doch stark ausgelasteten >> Controller der Slaves, ein simples UART-Protokoll zu handhaben anstelle >> von CAN. > Wenn die Slaves so stark ausgelastet sind wie sollen Sie auch noch die > doch eher ineffizeinte ungesicherte RS485 Übertragung managen? Nunja, 99% der Nodes werden wohl "im Leerlauf" sein, nur der eine, der gerade mit den Audio-Daten "beschossen" wird, hat halt doch etwas zu arbeiten. Jens Martin schrieb: >> (wird am Ende etwa insgesamt >> 1km Cat5-Kabel sein (mit allen Abzweigungen), > > und du hast auch an den Wellenwiderstand die Leitungsreflektionen > an Abschlusswiderstände und Interferenzen gedacht? Daher teile ich das ganze in Segmente der Länge 300m ein. Alle 300m wird dann, wie bei DMX, ein Repeater/Booster sein, der das Signal "auffrischt". Jens Martin schrieb: >> Zuerst wollte ich CAN >> nutzen, bin dann aber doch auf RS485 umgestiegen, da mir die Datenrate >> bei zu langer Leitungslänge zu gering war > > Bei CAN ist die Kollisionserkennung so gebaut das sich lange > Leitungslängen und hohe Datenraten faktisch ausschließen Daher wollte ich den CAN ja in 300m Segmente aufteilen, und dieses Segmente miteinander verbinden. Somit wäre jeder Bus nur 300m lang und doch wäre jeder Node erreichbar. Dadurch würde wohl die Latenz etwas hochgehen, aber das wäre nicht so tragisch, ob das Licht jetzt 10ms nachdem ich den Schalter gedrückt habe, angeht oder nicht. > Das ist sicher alles nicht falsch, nur hast du keinerlei > Sicherungsschicht wenn Störungen auftreten (was bei dieser Leitungslänge > sicher nicht ungewöhnlich wäre). Daher wollte ich ja zuerst CAN einsetzten, da hier ja die Übertragung gesichert ist, nur mit der Leitungslänge gibt es da ja dummerweise Probleme. Jens Martin schrieb: >> und 250kbit/s hätte ich >> schon gerne). Die Bandbreite brauch ich halt, da ich teilweise auch >> Audio-Daten übertrage. > > Warum nimmst du dann nicht Ethernet? Zum ersten mal ist das nicht ganz so günstig in Sachen Preis und Stromverbrauch, zum anderen wollte ich AVR Atmegas nutzen und da einen TCP/IP-Stack zu implantieren, ist erstens nicht ganz einfach und bestimmt nicht sehr ressourcensparend. Wenn ich es schaffe würde, z.B. 3 CAN-Segmente mit je 300m zusammenzuschalten, also alle Nachrichten durchgereicht werden, dürfte ich doch trotzdem die 250kbit/s schaffen. Klar, wenn eine Message durch alle 3 "CAN-Busse" gehen muss, bis sie ankommt, dürfte die Latenz etwas hoch gehen, aber das dürften doch noch im ms Bereich liegen. Die Frage ist halt nur, wie Verbinde ich 2 CAN-Busse miteinander.
Julian W. schrieb: > Zum ersten mal ist das nicht ganz so günstig in Sachen Preis und > Stromverbrauch, zum anderen wollte ich AVR Atmegas nutzen und da einen > TCP/IP-Stack zu implantieren, ist erstens nicht ganz einfach und > bestimmt nicht sehr ressourcensparend. Auf Ethernet muss nicht zwingend IP gefahren werden. Und wenn der Switch STP kann gibts auch ein wenig Redundanz. Such dir dann aber bitte eine Ethernet-Protokoll-ID die keiner nutzt.
Dieter schrieb: > Julian W. schrieb: >> Zum ersten mal ist das nicht ganz so günstig in Sachen Preis und >> Stromverbrauch, zum anderen wollte ich AVR Atmegas nutzen und da einen >> TCP/IP-Stack zu implantieren, ist erstens nicht ganz einfach und >> bestimmt nicht sehr ressourcensparend. > > Auf Ethernet muss nicht zwingend IP gefahren werden. Und wenn der Switch > STP kann gibts auch ein wenig Redundanz. Such dir dann aber bitte eine > Ethernet-Protokoll-ID die keiner nutzt. Gut, aber ich bräuchte ja immer noch pro Node einen Port am Switch, und auch der Stromverbrauch von Ethernet ist nicht ganz unerheblich...
Julian W. schrieb: > Wenn ich es schaffe würde, z.B. 3 CAN-Segmente mit je 300m > zusammenzuschalten, also alle Nachrichten durchgereicht werden, dürfte > ich doch trotzdem die 250kbit/s schaffen. Nur hast du dann auch ein paar investitionen, musst die Bridges powern und die Telegramme auch queuen. > Klar, wenn eine Message durch alle 3 "CAN-Busse" gehen muss, bis sie > ankommt, dürfte die Latenz etwas hoch gehen, Wenn du mit 250kb/s die Bridge vollballerst und auf der anderen Seite gequasselt wird musst du erstmal das ganze in einem Fifo zwischenspeichern. Den dann mit 250kbs gleichzeitig zu füllen und zu leeren ist nun wahrlich keine Haustechnik mehr Das ist aber bei TCP/IP Stacks und Struktur mit drin > aber das dürften doch noch > im ms Bereich liegen. Die Frage ist halt nur, wie Verbinde ich 2 > CAN-Busse miteinander. Eine Bridge ist laut http://de.wikipedia.org/wiki/OSI-Modell genau als das Teil das definiert das zwei segmentierte aber sonst gleichartige Busse miteinander verbindert. Ob diese schöne Theorie aber in der Praxis günstiger wird als das Massenkonsumerprodukt Ethernet wage ich zu bezweifeln?
Gut, angenommen, ich würde Ethernet benutzten, wie würde das da aussehen. Leider habe ich noch nie was mit Ethernet gemacht. Einzig den ENC28J60 hab ich schon mal in dem Zusammenhang gehört. Könntest du mir kurz erklären, wie so ein Netzwerk grob aussehen würde? Verkablung wäre dann wohl Stern, also immer zum Switch hin. Die Möglichkeit eines Stranges dürfte wohl nicht bestehen. Und wie sieht das mit der Ansteuerung aus, wenn ich nicht TCP/IP nutze, wie identifiziere ich die Nodes? Über die MAC?
Julian W. schrieb: > Könntest du mir kurz erklären, wie so ein Netzwerk grob aussehen würde? Julian, das Netz ist voll mit dem Zeugs, ich glauib das bekommst do ohne Hilfe hin. Julian W. schrieb: > Verkablung wäre dann wohl Stern, also immer zum Switch hin. Die > Möglichkeit eines Stranges dürfte wohl nicht bestehen Nun, wenn du CAT5 6 7 legst ist das doch eh egal.
Nunja, was ich aber immer im Netz finde (auch auf Bezug auf AVRs) sind TCP (IPv4 und IPv6) bzw. UDP-Stacks. Das ist ja scheinbar nicht dass, was ich haben will. Außerdem wäre es für mich dann noch interessant, ob ich in dieses Netz noch meinen Windows-Rechner klemmen könnte oder würde das Probleme geben, z.B. mit Boradcast-Paketen? Einzig auf Wikipedia hab ich was gefunden: http://de.wikipedia.org/wiki/Ethernet Das würde dann z.B. heißen, ich würde als EtherType z.B. einfach 0xAAAA nehmen und schon könnte ich einfach mithilfe der MAC-Adresse Daten versenden? Und mit dem Kabel ist es nicht ganz egal, da pro Strang etwa 10 Nodes sein werden. Aber trotzdem bräuchte ich ja nur 1x 300m, wenn ich das ganze linear verlegen würde. Wenn ich nun von jedem Node ein Kabel zum Switch legen muss, sind das am Ende 10 Kabel unterschiedlicher Länge, was im Endeffekt jedoch erheblich mehr sein dürfte, da schon alleine das Kabel des letzten Nodes 300m sein muss.
Julian W. schrieb: > Nunja, was ich aber immer im Netz finde (auch auf Bezug auf AVRs) sind > TCP (IPv4 und IPv6) bzw. UDP-Stacks. Das ist ja scheinbar nicht dass, > was ich haben will. Das ist auch alles andere als trivial, aber warum nicht die long dsitance mit der entsprechenden Technologie überbrücken und von dort seriell die Devices einbinden? > Außerdem wäre es für mich dann noch interessant, ob ich in dieses Netz > noch meinen Windows-Rechner klemmen könnte oder würde das Probleme > geben, z.B. mit Boradcast-Paketen? Wenn das ganze sauber aufgebaut ist macht es keinen Unterschied. Hier schwirrt alles mögliche im Netz rum PCs Server ComServer embedded devices usw. usf > > Einzig auf Wikipedia hab ich was gefunden: > http://de.wikipedia.org/wiki/Ethernet > > Das würde dann z.B. heißen, ich würde als EtherType z.B. einfach 0xAAAA > nehmen und schon könnte ich einfach mithilfe der MAC-Adresse Daten > versenden? Nimm ein Ethernet Modul wo alles drin ist, (gibt es komplett in der Buchse) wenn du das ganze selbst aufbauen willst erfindest du das Rad zum 10. mal. Nr. 1-9 haben auch ein paar Jährchen gebraucht. > > Und mit dem Kabel ist es nicht ganz egal, da pro Strang etwa 10 Nodes > sein werden. Aber trotzdem bräuchte ich ja nur 1x 300m, wenn ich das > ganze linear verlegen würde. Dann mach doch Multitechnologie, 2 paare 100mBit (mehr braucht Ethernet da nicht ist auch genormt wo die liegen ) paar 3 RS485 Paar 4 CAN. Dann kannst du per Pinbelegung entscheiden ob da nun ein Ring Stern oder sonstige Gewölle angeklemmt wird. > Wenn ich nun von jedem Node ein Kabel zum Switch legen muss, sind das am > Ende 10 Kabel unterschiedlicher Länge, was im Endeffekt jedoch erheblich > mehr sein dürfte, da schon alleine das Kabel des letzten Nodes 300m sein > muss. Eine FO (Fiberoptik) Strecke bringt da schon einiges. Auch in Hinblick auf Masse Shield Ableitströme und das ganze andere feine Zeugs was man als Anfänger (manchmal schmerzhaft) erlernt
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.