Gast
#7167509
Hallo, kann man beim RS485 auch eine Kollisionserkennung nach CSMA/CD realisieren? Welche Möglichkeiten bestehen noch? Danke!
Gast
#7167512
Friedrich schrieb: > Welche Möglichkeiten bestehen noch? Man liest das zurück, was man gesendet hat. Wenn die beiden Daten nicht übereinstimmen, ist ein Fehler aufgetreten. So macht das CAN.
Da die Ausgänge in beide Richtungen etwa gleich stark sind (kein dominanter Pegel), kann man sich aber auch nicht sicher drauf verlassen, eine Kollision sicher zu erkennen, wenn der Gegner am anderen Ende des Busses hängt.
Bei einer Kollision wird der stärkere Transceiver den schwächeren überstimmen und der schwächere in die thermische Abschaltung gehen. Bei hohen Leitungswiderständen kann es auch passieren, daß beide ihr gesendetes Paket fehlerfrei zurücklesen. Eine zuverlässige Kollisionserkennung ist daher nur in höheren Protokollschichten möglich. Professionelle RS-485 Protokollstacks sind daher oft recht aufwendig.
Gast
#7167592
CSMA/CD sind jedoch beim Profibus & beim Modbus Protokoll möglich oder? Wäre das auch verlässöich/ zu empfehlen? Welche Methoden gäbe es noch?
Nein, CSMA/CD ligt unter der Schicht für die Protokolle. Da Profibus und Modbus RTU auf RS485 basieren, haben auch diese kein CSMA/CD. Dazu brauchst du Treiber wie sie z.B. CAN Verwendet, mit einem dominanten und einen rezessiven Pegel. Modbus RTU verwendet ein Singel-Master System und zusätzlich CRC um eine störungsfreie Kommunikation zu gewärleisten. Profibus hat glaube ich ein Token System.
Gast
#7167822
Friedrich schrieb: > kann man beim RS485 auch eine Kollisionserkennung nach CSMA/CD > realisieren? Nein, nicht wirklich. Master / Slave funzt aber ganz wunderbar bei RS485. Kein Slave sendet ohne das der Master ihn was gefragt hat und kein Slave verlässt das Zeitfenster das er zum Antworten hat. Fehler werden über CRC erkannt. Multimaster führt bei RS485 zu einem Haufen Probleme die man nicht einfach lösen kann. Selbst wenn man erst auf den Bus hört und dann sendet, ist das keine Garantie das das nicht auch zeitgleich ein anderer Teilnehmer macht. Busfehler können nicht in Bitzeit erkannt werden und je nach Leitungslänge, Schleifenwiderstand und Transceiverpower werden die auch garnicht erkannt. Nur die CRC bietet Übertragungssicherheit und bis man die ausgewertet hat ist schon viel Zeit verloren. DANN muss man das Chaos erstmal auflösen bis man neu übertragen kann. Warum immer und immer wieder die gleiche Frage nach RS485 Multimaster kommt kann ich einfach nicht begreifen. Die Sache ist bis zum Erbrechen ausdiskutiert und dafür gibt es Bussysteme die das in Hardware sehr gut machen. Der Witz ist das jeder der sowas fragt meint das Multimaster schneller wäre, aber das stimmt nicht für RS485. Geht eine Multimaster Übertragung fehlerfrei durch, ist die schnell. Wird die zernagelt, warten beide Kontrahenten eine zufällige Zeit ab, senden nochmal, Teilnehmer 3 hat aber mittlerweile Bus Idle erkannt und sendet auch gerade. Nun gibt es schon drei die um den Bus kämpfen un je länger das dauert umso mehr Chaos ist auf dem Bus. Lange Bussegmente mit langer Signallaufzeit und Busauslastung >30-50% kann man sich abschminken. Das dauert eine unbekannte Zeitspanne bis sich der Bus wieder fängt und alle Ihre Telegramme losgeworden sind. Master Slave ist immer gleich schnell langsam, kann bestimmte Slaves priorisieren und verhindert Kollisionen durch das Design. Der RS485 ist ein toller Bus, der mit geringem Aufwand an jedem UART funzt, aber Multimaster ist einfach nicht das wofür der gebaut wurde.
Multimaster geht recht gut mit Token passing. Da braucht es nur für den Fall des Tokenverlusts eine gute Strategie für den Neustart.
Gast
#7167846
Max M. schrieb: > Nein, nicht wirklich. > Master / Slave funzt aber ganz wunderbar bei RS485. > Kein Slave sendet ohne das der Master ihn was gefragt hat und kein Slave > verlässt das Zeitfenster das er zum Antworten hat. > Fehler werden über CRC erkannt. Vielen vielen Dank für diese ausführliche Antwort, auch an allen anderen vielen lieben Dank! Komischerweise findet man in verschiedenen Büchern/Artikeln, verschiedene Informationen zu der Thematik. Das klingt hier für mich aber sehr plausibel.
Dieter W. schrieb: > Multimaster geht recht gut mit Token passing. > Da braucht es nur für den Fall des Tokenverlusts eine gute Strategie für > den Neustart. Ergänzung: Echtzeit - im Sinne von jeder plärrt los wenn er was zu sagen hat - geht damit natürlich nicht. Es darf eben immer nur der Master loslegen, der gerade das Token hat.
Den CAN-Bus hat man schließlich nicht aus langer Weile entwickelt, sondern weil man schwerwiegende Nachteile von RS-485 beseitigen wollte. Es hat schon seinen Charme, wenn der Master die Slaves nicht ständig erneut abfragen muß, sondern per Autosend die Slaves selber neue Meßwerte und Statusänderungen rausplärren können. Das funktioniert bei CAN hervorragend. Selbst eine Busauslastung von 100% ist kein Problem.
Gast
#7168429
Peter D. schrieb: > Das funktioniert bei > CAN hervorragend. > Selbst eine Busauslastung von 100% ist kein Problem. CAN ist aber auch echt ausgefuchst. Kollisionserkennung in Bitzeit, ohne das das dominante Bit des höher priorisierten Teilnehmers dabei zerstört wird. Da dadurch keine Neuübertragungen notwendig werden tritt die race condition nicht auf, die bei anderen Kollisionsbussen ab 50% Auslastung zum Kollaps führt. Dieter W. schrieb: > Es darf eben immer nur der Master loslegen, der gerade das Token hat. Bis dann das Token bei Übertragungsfehler zerstört wird und einer der Master ein neues erzeugen muss. Ein Fass ohne Boden und deterministisches Zeitverhalten geht als erstes über Bord.
Mittlerweile gibt es ARCnet ueber RS485. Arcnet verwendet Tokenpassing, und kann dadurch den Bus maximal belasten. 10MBit mit einem COM20022i, mit einigen Buffern von je 256 bytes, und einem Parallel Interface, DMA, falls gewuenscht. Inkl einem Lowlevelprotocol, welches auch Tokenrecovery, und Rekonfiguration kann. Bei 2.5MBit ist eine Leitungslaenge von 4 miles moeglich Waehrend CAN eher die Billigloesung fuer die Autoindustrie ist. CAN hat als maximale Packetlaenge etwa 6 bytes. Aber man sollte sich schon beantworten, ob man eine Multimaster Loesung moechte.
Kollisionserkennung für arme Leute: Der RS-485-Transceiver und der uC werden aus einem gemeinsamen Spannungsregler mit definierter Strombegrenzung betrieben ;)
Gast
#7170466
Purzel H. schrieb: > CAN hat als maximale Packetlaenge etwa 6 bytes. Da muss ich schon widersprechen. CAN hat bis zu 8 Bytes und CAN FD bis zu 64 Bytes Nutzdaten in einem Frame.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.