RS485-Bus für mehrere Teilnehmer

[Thomas H. (Firma: Student) (haube)]

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 ;)

[Der Ami (Gast)]

Hallo!
Der 485-Bus (A-B) muß nicht nur terminiert, sondern auch mit den Pegeln 
für eine "1" vorgespannt werden.

[Route_66 H. (route_66)]

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.

[zeitler (Gast)]

Genau. Dann - und nur dann - funktioniert dieses "Arme-Leute-RS485". 
Aber eigentlich ist es Pfusch.

[Peter (Gast)]

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 ...

[Ich (Gast)]

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).

[Pandur S. (jetztnicht)]

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.

[Route_66 H. (route_66)]

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.

[Thomas H. (Firma: Student) (haube)]

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?

[Torsten C. (torsten_c)]

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

[Ralf G. (ralg)]

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.