Ich hätte eine Frage zu einer Schaltung. Prinzipiell geht es darum die Steuerleitungen eines RS485-Treibers mit dessen Signalleitung zu treiben. RS485-Bus für mehrere Teilnehmer http://www.kriwanek.de/arduino/projekt-energiemessung/rs485-bus/285-rs485-bus-fuer-mehrere-teilnehmer.html Folgendes ist mir bisher klar. Da der Ruhepegel von TXD High ist, sind die Enable Leitungen in Ruhe auf Low und der Max485 ist im Receive Modus. Wird nun eine logische 0 übertragen, wechselt TXD von High nach Low und Enable von Low nach High. Hierdurch wird laut dem Datenblatt der Transmitter aktiv und es wird auf der RS485-Leitung eine logische 0 übertragen (A-B) < 200mV. Mir stellt sich nun folgende Frage: Wenn eine logische 1 übertragen wird, wechselt TXD auf High und Enable auf Low. Laut Datenblatt geht der Transmitter nun in den hochohmigen Zustand und der Receiver wird aktiv. Warum liegt an der RS485-Leitung nun eine logische 1 (A-B) > 200mV an? Bin gespannt auf die Antworten ;)
Gast
#4207876
Hallo! Der 485-Bus (A-B) muß nicht nur terminiert, sondern auch mit den Pegeln für eine "1" vorgespannt werden.
Noch was: /RE (Pin 2) sollte fest auf GND gelegt werden. Nur so kann der sendende Controller die eigene Nachricht mitlesen, und Kollisionen am Bus überhaupt erkennen. DI (Pin 4) kann ebenfalls fest auf GND liegen, und das invertierte TxD-Signal nur an DE (Pin 3). So vermeidet man Spikes auf dem Bus.
Gast
#4207892
Genau. Dann - und nur dann - funktioniert dieses "Arme-Leute-RS485". Aber eigentlich ist es Pfusch.
Gast
#4207896
Route 6. schrieb: > DI (Pin 4) kann ebenfalls fest auf GND liegen, und das invertierte > TxD-Signal nur an DE (Pin 3). So vermeidet man Spikes auf dem Bus. Lol ...
Gast
#4207913
Route 6. schrieb: > Noch was: > /RE (Pin 2) sollte fest auf GND gelegt werden. Nur so kann der sendende > Controller die eigene Nachricht mitlesen, und Kollisionen am Bus > überhaupt erkennen. Vorsicht! Die Kollisionserkennung funktioniert nicht unbedingt! Jeder Treiber treibt ja an seinem Knoten den Bus. Treiben 2 Knoten den Bus an unterschiedlichen voneinander entfernten Punkten (vllt. auch noch unterschiedlich stark), entsteht ein Spannungsgefälle so dass es dazu kommen kann, das ein Knoden denkt er habe richtig gesendet, da er es an seinem Punkt scheinbar richtig gemessen hat aber an einem Anderen Punkt des Buses sah der Pegel durch den dort Treibenden Knoten ganz anders aus sodass die Kollision nicht erkannt wurde. Deshalb die Kollisionserkennung besser im Protokoll implementieren und möglichst von vornherein vermeiden. Im Anhang ein Screenshot, wie es an einem Punkt aussehen kann, wenn mehrere Knoten den Bus treiben (Hier wurde weiter entfernt von beiden Knoten gemessen wobei der eine Knoten weiter entfernt quasi hinter dem anderen ist).
Angehängte Dateien:
-
DS1Z_QuickPrint14.png
(57 KB)
Kollisionserkennung sollte man im Protokoll vermeiden. Ein Multimasterprotokoll ist etwas sehr Schwieriges, das man sich nicht antun sollte. Zum Einen sollten alle Knoten mithoeren und so erkennen, wann Zeit fuer sie ist. Das kann man mit SenderIDs machen, die jeweils hochgezaehlt werden. Jeder darf senden bis er nichts meht zu sagen hat und sendet dann ein "Macht-weiter". Und wenn ein Knoten nichts zu sagen hat, sendet er ein "Macht-weiter". Das geht bis die Folge abbricht. Dann darf zb der niedrigste Knoten neu beginnen. Welcher ist der Niedrigste ? Koennt ja sein, dass der grad abgehaengt wurde. Wie kommt ein neuer Knoten auf den bus ? Wie kommt er zu einer SenderID ? usw. Das Ganze sollte dann auch debugbar sein. Ich empfehl ein Master-slave protokoll. Einer sagt, was passieren soll.
Ich schrieb: > Vorsicht! Die Kollisionserkennung funktioniert nicht unbedingt! Jeder > Treiber treibt ja an seinem Knoten den Bus. Treiben 2 Knoten den Bus an > unterschiedlichen voneinander entfernten Punkten (vllt. auch noch > unterschiedlich stark), entsteht ein Spannungsgefälle so dass es dazu > kommen kann, das ein Knoden denkt er habe richtig gesendet, da er es an > seinem Punkt scheinbar richtig gemessen hat aber an einem Anderen Punkt > des Buses sah der Pegel durch den dort Treibenden Knoten ganz anders aus > sodass die Kollision nicht erkannt wurde. Du hast es nicht verstanden, worum es in diesem Beitrag geht. Für einen Standard-RS485-Bus liegst Du richtig, hier aber falsch. Hier soll das Zugriffsprinzip des CAN dem RS485-Tranceiver aufgestülpt werden. Man könnte auch gleich einen CAN Transceiver verwenden, wenn man alle Busknoten selbst macht, und nicht fertige RS485-Geräte integrieren muß. Das Ganze funktioniert in der Praxis auch. Die Firma PhyTec hat das mit Erfolg mit ihrem µNET-Netzwerk in den 90gern verkauft, als CAN noch fast unbezahlbar war.
Vielen Dank erst mal für die vielen Antworten. Das Protokoll läuft folgendermaßen: Es gibt einen Master der mehrere Slaves anspricht. Nur wenn ein Slave angesprochen wird antwortet dieser. Er sendet nie von selbst. Hierdurch sollte es keine Kollisionen auf dem Bus geben. Nun weiter zur Schaltung: Das heißt, um einen Ruhepegel von (A-B) > 200 mV zu erzeugen füge ich einen Pull-Up von Leitung A auf VCC und einen Pull-Down von Leitung B auf GND ein? Hätte jetzt als Pull-Up und Pull-Down einen 330 Ohm genommen. Dann liegen im Ruhefall an A 1,9V und an B 1,4V an => 500mV Differenzsignal. Wären dann ca 14mW Verlustleistung im Ruhefall. Ist das soweit in Ordnung?
Angehängte Dateien:
-
rs485.png
(48 KB)
In diesem Artikel sind die Varianten der Failsafe-Terminierung bzw. des Failsafe-Biasing ganz gut beschrieben: http://www.ti.com/lit/an/slyt514/slyt514.pdf
Thomas H. schrieb: > Das heißt, um einen Ruhepegel von (A-B) > 200 mV zu erzeugen füge ich > einen Pull-Up von Leitung A auf VCC und einen Pull-Down von Leitung B > auf GND ein? Überlege mal, warum in der Doku zum MAX4xx genau diese Widerstände fehlen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.