Hi, wenn ich mit RS485 Multimaster nutzen will kann ich doch keinen normalen MAX485 nehmen, oder? Soweit ich das verstanden habe steigen die normalen Treiber aus, wenn zwei versuchen, gleichzeitig zu senden. Muss man einen Treiber mit Fault Protect nehmen?
>Hi, wenn ich mit RS485 Multimaster nutzen will kann ich doch keinen >normalen MAX485 nehmen, oder? Doch. Eigentlich sind doch alle RS485-Netzwerke Mulimaster. Es kommt dabei auf die Software an und das Datenverkehrsaufkommen an. >Soweit ich das verstanden habe steigen die normalen Treiber aus, wenn zwei >versuchen, gleichzeitig zu senden. Was meinst du mit "aussteigen"? Wenn ein Treiber eine logische "1" sendet und ein anderer eine logische "0", dann kommt es zu einem Kurzschluss auf dem Bus. CAN-Transceiver erkennen sowas.
STK500-Besitzer schrieb: > Doch. Eigentlich sind doch alle RS485-Netzwerke Mulimaster. Eigentlich nicht, RS485 ist in seiner Grundform Single Master STK500-Besitzer schrieb: > Was meinst du mit "aussteigen"? > Wenn ein Treiber eine logische "1" sendet und ein anderer eine logische > "0", dann kommt es zu einem Kurzschluss auf dem Bus. Eben. Soweit ich weiß schalten normale Treiberbausteine dann ab. Es gibt aber welche mit Fault Protect > > CAN-Transceiver erkennen sowas. CAN funktioniert etwas anders. Bei CAN gibt es nur Sink Treiber und einen PullUp Widerstand. Da gibt es keinen Kurzschluss. RS485 hat Push/Pull Treiber. Bitte korrigiert mich, wenn ich falsch liege. Aber soweit ich weiß müsste das stimmen.
Jens Schwarzhans schrieb: > Eigentlich nicht, RS485 ist in seiner Grundform Single Master Sie sind durchaus Multi-Master tauglich. Wenn konfliktfrei. Für Bus-Arbitrierung per Konflikt/Kollision sind sie nicht vorgesehen. CAN-Trensceiver sind es.
Ein RS485-Driver kann normal bis 32 Receiver treiben (also den eigenen Receiver im Transceiver + 31 andere). Es gibt aber auch Bausteine mit erweiterte Spezif. (z.B. von Maxim) mit max 128 Receivern. Bei CAN-Transc. kann (wie oben erwähnt) immer einer ein dominantes 0-Bit auf die Leitung legen, ähnlich einer einfache OpenColector-Struktur. Das ist auch das Prinzip, weshalb CAN die bitweise Arbitrierung machen kann. (Jeder Driver sendet seine dominate 0-Pegel jedes Adr-Bits) und derjenige Driver "gewinnt", bei dem das MSB 0 ist (bzw die meisten oberen Bits 0 sind) ) Somit könnte man auch gut ein eigenes Netzwerk sich bauen, mit CAN-Transceivern anstatt mit RS485-Transceivern.
A. K. schrieb: > Für > Bus-Arbitrierung per Konflikt/Kollision sind sie nicht vorgesehen. Es gibt z.B. den MAX3430 mit Fault-Protected. Da steht explizit dabei "Multimaster RS-485 Networks" Ich habe sogar ein Projekt gefunden, das ein Protokoll dafür implementiert http://ulan.sourceforge.net/index.php?page=1
Jens Schwarzhans schrieb: > Es gibt z.B. den MAX3430 mit Fault-Protected. Da steht explizit dabei > "Multimaster RS-485 Networks" Soweit nichts Neues. RS485-Transceiver sind m.W. alle irgendwie gegen Kollisionen abgesichert, und sei es thermisch. Der Knackpunkt bei Transceivern für Multimaster mit Kollision als Quasi-Normalzustand ist, ob die Beteiligten die Kollision auch sicher erkennen können, und zwar alle in gleicher Weise. Ich kann mir zwar spezielle RS485-Transceiver oder Zusatzbeschaltungen vorstellen, die eine Kollision sicher erkennen und signalisieren, aber die üblichen Transceiver allein tun dies nicht, auch nicht dieser MAXe. Je nach Leitungslänge/dicke können Streithähne an entfernten Enden der Leitung zu unterschiedlichem Ergebnis kommen. Daher meine obige Aussage, die für diesen MAXe ebenso zutrifft wie für den ollen SN75176: Multimaster geht, aber Kollisionen als Arbitrationsmechanismus sind problematisch. Es gibt jedoch Verfahren wie Token Passing, bei denen Kollisionen nur als eher seltener Nebeneffekt bei Tokenverlust auftreten, allerdings ist das in der Praxis recht komplex. Auch das im verlinkten Projekt verwendete Verfahren betont die Notwendigkeit, Kollisionen möglichst zu vermeiden.
Zur Illustration: Der Kurzschluss/Kollisionsstrom dieses MAXe liegt bei bis zu 250mA und die Schwellspannung in der Grössenordnung von 100mV. Ein Leitungswiderstand von einigen Zehntel Ohm kann also im Konfliktfall bereits dazu führen, dass beide Seiten sich als Gewinner sehen und keine Kollision erkennen.
Mir ist klar, dass die Treiber eine Kollision nicht erkennen können. Das muss die Software machen. Aber ein MAX485 oder LTC485 hat meines Wissens kein "normales" Fault Protect. Im Fall eines Kurzschlusses bei einer Kollision schalten diese Treiber afaik komplett ab. Es geht also nicht darum, dass die Treiber eine Kollision erkennen sondern nur darum, dass die Treiber eine Kollision verkraften ohne abzuschalten. Das Erkennen muss ausschließlich die Software machen.
>Das Erkennen muss ausschließlich die Software machen.
Aber das gibt extreme Probleme (bzw ist das Erkennen fast unmöglich), da
der Spannungspegel auf der Leitung dann nicht genau definiert ist. Bzw
müsste über viele Bits hinweg jeder Sender seine eigens gesendeten Bits
vergleichen... und das während der langen Zeit der Kurzschlüsse... das
ist nicht praktikabel
Nein, das Erkennen ist nicht allzu schwierig. Der CRC ist kaputt. Nochmals.
Für neue Projekte würde ich im Moment ausschliesslich CAN verwenden. Die ganzen Klimmzüge, die bei RS485 nötig sind, kann man sich getrost schenken. Braucht niemand.
>Nein, das Erkennen ist nicht allzu schwierig. Der CRC ist kaputt.
Dann sind während dieser ganzen ProtokollZeit Kurzschlüsse auf dem Bus
!!! U.U. mit sehr grossen Strömen.
Auch könnte es sein dass verschiedene Receiver verschiedene Werte lesen,
so dass im Extremfall (wenn rel. kurzes Protokoll) sogar ein Receiver
kein Fehler feststellt, und andere Receiver doch einen Fehler
feststellen.
H.joachim Seifert schrieb: > Für neue Projekte würde ich im Moment ausschliesslich CAN verwenden. > Die ganzen Klimmzüge, die bei RS485 nötig sind, kann man sich getrost > schenken. Braucht niemand. Hm. Gibt es CAN eigentlich potentialfrei?
CAN ist leider Muell. Die Packetlaenge ist nur 6 Byte, was fuer Automobildaten passend sein mag, aber fuer viele Anwendungen eher mager ist. Da RS485 Treiber einen Innenwiderstand haben, ist ein Kurzschlussstrom nicht allzu gross. Ein Kurzschluss ist immer moeglich und muss daher tolerierbar sein.
Hm. Ich habe CAN bislang immer erfolgreich umgangen. Echt nur 6 Byte? Das ist wirklich dürftig. Also, geht das? 100V Potentialdifferenz zwischen zwei Geräten?
>CAN ist leider Muell. Die Packetlaenge ist nur 6 Byte, was fuer >Automobildaten passend sein mag, aber fuer viele Anwendungen eher mager >ist. Man muss ja nicht das ganze Protokoll und die damit verbundenen Controller verwenden, sondern kann sich die Sache selber bauen. Beim CAN-Transceivern wird nicht zwischen Senden und Empfangen umgeschaltet wie beim RS485-Transceivern. Da muss man dann "nur" das gesendete Byte mit dem empfangenen vergleichen und entsprechend reagieren: Bei Gleichheit kann man weiter senden, bei Ungleichheit war jemand anders auch auf dem Bus unterwegs...
Abdul K. schrieb: > Hm. Ich habe CAN bislang immer erfolgreich umgangen. Echt nur 6 Byte? > Das ist wirklich dürftig. Es sind nicht 6 sondern 8 Bytes. Plus einer 29-Bit Adresse in der sich ggf. auch noch etwas Daten unterbingen lassen (z.B. Zeile/Spalte bei LCD-Daten) wenn man die Adressstruktur selber definiert. CAN ist ein Steuerbus, kein Interface für Massenspeicher. Was mich nicht daran gehindert hat, den Inhalt eines 512KB Protokollspeichers darüber zu übertragen.
Abdul K. schrieb: > Also, geht das? 100V Potentialdifferenz zwischen zwei Geräten? Indem man den Transceiver vom Controller potentialtrennt. Nicht anders als bei RS485, nur eine Leitung weniger (kein driver enable nötig).
Hey noch Was schrieb: > Da RS485 Treiber einen Innenwiderstand haben, ist ein Kurzschlussstrom > nicht allzu gross. Die Hersteller der Transceiver scheinen sich dabei auf einen Maximalwert von 250mA geeinigt zu haben.
Man kann auch die höheren Layer von typischer RS485 Vernetzung nutzen, d.h. UART, und dies mit CAN Transceivern kombinieren. Damit sind Kollisionen sauber definiert und man erspart sich das etwas fieselige Timing von driver enable und inter packet gap. Wer unbedingt RS485-Multimaster fahren will, der sollte diese Variante ebenfalls betrachten.
Die Idee, einen CAN Transceiver statt RS485 zu verwenden ist schon keine schlechte Idee, hat aber einen Haken. Man hat sein eigenes Format kreiert und kann keine anderen Geräte verwenden, die RS485 Transceiver haben
Klar. Wenn man feste Vorgaben darüber hat, mit welchen Fertiggeräten sich das kombinieren lassen muss, dann erübrigt sich jede Diskussion über physikalische Übertragungstechnik, Betriebsart und Protokolle, denn dann definieren diese Geräte die Technik und der Rest vom Netz muss sich dran halten.
Wenn man von der dominanten-0-Bit-Detections-Möglichkeit (u.a. bei CAN Transceivern) profitieren will, schafft man aber keine so hohe Übertragungsraten, weil jedes Bit so lange geschaltet sein muss, dass es überall auf der Leitung ansteht. (Deswegen ist CAN auch rel. langsam)
Ich ziehe RS485 halt CAN vor, weil dafür keine speziellen Controller nötig sind. Jeder Mikrocontroller, der 9 Bits verarbeiten kann, ist in der Lage das zu nutzen. Wenn er jetzt noch einen IRQ bei gesetztem neunten Bit auslöst hat man schon die halbe Miete. Für eigene Projekte in einem geschlossenen Umfeld würde ich vielleicht sogar CAN Transceiver einsetzten, aber es gibt auch das eine oder andere Modul, das ich gerne verwenden würde.
>Ich ziehe RS485 halt CAN vor, weil dafür keine speziellen Controller >nötig sind. Für CAN-Transc. -wie auch f. RS485Transc.- sind keine speziellen Controller nötig
MCUA schrieb: > Für CAN-Transc. -wie auch f. RS485Transc.- sind keine speziellen > Controller nötig Jain. Für mich ist CAN das Gesamtpaket, also Transceiver, Controller, Protokoll. Einen CAN Transceiver als RS485 Verschnitt zu missbrauchen ist nicht Brot und nicht Fleisch. Man werkelt da nur in seiner eigenen Welt. Wenn CAN, dann das volle Programm
>Für CAN-Transc. -wie auch f. RS485Transc.- sind keine speziellen >Controller nötig Was ich auch die ganze Zeit vermitteln möchte...
>Einen CAN Transceiver als RS485 Verschnitt zu missbrauchen ist nicht >Brot und nicht Fleisch. Man werkelt da nur in seiner eigenen Welt. Wenn >CAN, dann das volle Programm Blödsinn! >Jain. Für mich ist CAN das Gesamtpaket, also Transceiver, Controller, >Protokoll. Falsche Einstellung.
STK500-Besitzer schrieb: > Falsche Einstellung. Ich möchte mal Wikipedia zitieren > CAN ist als ISO 11898 international standardisiert und definiert die Layer 1 (physikalische Schicht) und 2 (Datensicherungsschicht) im ISO/OSI-Referenzmodell. Meine Einstellung interessiert in der realen Welt da draußen keinen. Wenn ich einen CAN Transceiver direkt an einen UART klebe und mein eigenes Protokoll stricke bringt mir das außerhalb meiner vier Wände nicht viel. Es funktioniert, keine Frage. Aber funktionieren allein reicht nicht immer
Achso, willst du vielleicht darauf hinaus, das CAN Protokoll in Software zu emulieren?
>Meine Einstellung interessiert in der realen Welt da draußen keinen. >Wenn ich einen CAN Transceiver direkt an einen UART klebe und mein >eigenes Protokoll stricke bringt mir das außerhalb meiner vier Wände >nicht viel. Auf der RS485 benutzt du also ein standardisiertes Protokoll? Wenn ich mir das Protocol2000 von Kramer (im Bereich der Video-Kreuzschienen relativ verbreitet) ansehe, dann ist es mit 4 Bytes sehr beschränkt. Für die Anwendung reicht es alle Mal. Viel Erfolg!
Das es für RS485 kein Standard Protokoll gibt weißt du so gut wie ich. Aber das kann man ja selbst anpassen. Wenn man einen CAN Controller nimmt und irgendwelche CAN Devices anschließen will hat man eben seinen Standard, auf dem alles Basiert Aber wenn du einen CAN Transceiver einfach an einen UART klemmst hast du gar nichts. Willst du CAN Geräte anschließen musst du das komplette CAN Protokoll selbst stricken und wenn du RS485 Geräte anschließen willst kommst du auch nicht weit
Was willst Du? Auf der einen Seite, vorhandene 'normale' Geräte mit RS485 Schnittstellen ansteuern und auf der anderen Seite ein spezielles, kollisionsfestes Interface verwenden? Das paßt doch nicht zusammen! >Wenn ich einen CAN Transceiver direkt an einen UART klebe und mein >eigenes Protokoll stricke bringt mir das außerhalb meiner vier Wände >nicht viel. Das bringt immerhin soviel, dass Deine eigenen Geräte funktioniern.
Tropenhitze schrieb: > Auf der einen Seite, vorhandene 'normale' Geräte mit RS485 > Schnittstellen ansteuern und auf der anderen Seite ein spezielles, > kollisionsfestes Interface verwenden? Das paßt doch nicht zusammen! Wieso ein spezielles? Ich will lediglich einen RS485 Transceiver verwenden, der Multimasterkommunikation erlaubt. Ich kann aber immer noch Geräte anschließen, die normale Treiber verwenden. Die senden ja nur, wenn sie aufgefordert wurden.
Ich versteh dich immer noch nicht. JEDER RS485-Transceiver ermöglicht Multimaster. Es gibt aber zur selben Zeit nur einen einzigen Sender auf der Leitung. Welcher das wann ist, musst du irgendwie selbst per Software ausklamüsern. Und dafür gibts verschiedene Ansätze.
H.joachim Seifert schrieb: > JEDER RS485-Transceiver ermöglicht Multimaster Nur, wenn sichergestellt ist, dass keine zwei Master gleichzeitig senden. Sobald das passiert bekommt man mit normalen Transceivern ein Problem. Deshalb gibt es ja z.B. den MAX3430. Dort steht auch explizit > Multimaster RS-485 Networks
Also um das mal zusammenzufassen. Entweder man hat normale Transceiver und stellt per Software/Protokoll sicher, dass immer nur einer sendet. Dh alle Teilnehmer handeln vorher aus, wer als nächstes senden darf. Oder man verwendet Fault Protected Transceiver und kann eine Software-Kollisionserkennung nutzen. Also einfach Daten senden und auf ein ACK des Empfängers warten. Folgt das nicht kam es zu einer Kollision. Letzteres dürfte effizienter sein, weil vor jeder Arbitrierung kein zusätzlicher Overhead nötig ist.
Jens Schwarzhans schrieb: > Also um das mal zusammenzufassen. Entweder man hat normale Transceiver > und stellt per Software/Protokoll sicher, dass immer nur einer sendet. > Dh alle Teilnehmer handeln vorher aus, wer als nächstes senden darf. Was irgendwelche Synchronität voraussetzt und das ist das Problem. Sobald das Netzwerk relativ groß wird, 'sehen' sich die Transceiver nicht mehr 'rechtzeitig', und daher... > > Oder man verwendet Fault Protected Transceiver und kann eine > Software-Kollisionserkennung nutzen. Also einfach Daten senden und auf > ein ACK des Empfängers warten. Folgt das nicht kam es zu einer > Kollision. > > Letzteres dürfte effizienter sein, weil vor jeder Arbitrierung kein > zusätzlicher Overhead nötig ist. ... ist dies effizienter! Diese Erkennung brauch man eh. Einfacher CRC reicht völlig.
A. K. schrieb: > Abdul K. schrieb: > >> Also, geht das? 100V Potentialdifferenz zwischen zwei Geräten? > > Indem man den Transceiver vom Controller potentialtrennt. Nicht anders > als bei RS485, nur eine Leitung weniger (kein driver enable nötig). Ich meinte eigentlich eine Trennung per Übertrager und gleichspannungsfreien Code, also FM bzw. Manchester. Geht das bei CAN? Ich vermute es geht nicht.
>Deshalb gibt es ja z.B. den MAX3430.
Hast Du denn auch Repeater mit diesem MORITZ?
Diese müßten das 'böse' Spiel ja auch mitmachen.
Da mit 128 Devices an einem Bus mehr als ausreichen und ich auch keine 10km überbrücken will sehe ich noch keine Notwendigkeit für einen Repeater Und ich bin mir sicher, dass es etwas entsprechendes gibt.
Repeater auf einem bidirektionalen Bus ist schwierig.
(wurde zwar schon von anderen erläutert) >> Für CAN-Transc. -wie auch f. RS485Transc.- sind keine speziellen >> Controller nötig >Jain. Für mich ist CAN das Gesamtpaket, also Transceiver, Controller, >Protokoll. >Einen CAN Transceiver als RS485 Verschnitt zu missbrauchen ist nicht >Brot und nicht Fleisch. Man werkelt da nur in seiner eigenen Welt. Wenn >CAN, dann das volle Programm tschuldigung, aber "Jain" ist Humbug. Als Entwickler weisst du doch (oder nicht ?), dass es auf eine binäre Frage nur "JA" oder "NEIN" gibt. Also was soll das Gerede? ENTWEDER der Transceiver kanns ODER er kanns nicht. Fertig. Seit wann muss ein IC (oder Transceiver) Brot oder Fleisch sein ? Dann musst du ins Lebensmittelgeschäft gehen ! Ein CAN Transceiver ist genau so ein Transceiver wie ein RS485 Transceiver oder ein XXXX-Transceiver. Der hat (genau wie andere auch) genau spezif. Eigenschaften. Und wenn die passen, dann kann den nehmen. Deswegen gibts den ja. --------- Aber wenn du ein COMPLETT FERTIGES (Feld)Bussystem kaufen oder nachbauen willst, musst du dich sowiso an DIESE Spezif. halten , und dann ist deine ganze Fragerei nach einem Treiber o.ä. sowiso hinfällig.
>Repeater auf einem bidirektionalen Bus ist schwierig.
Eigentlich nicht:
forums.futura-sciences.com/.../42449d1206434081-reemmeteur-rs485-bidirec
tionnel-repeteur-rs485.pdf
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.