RS485 crossover Netzwerk

[Dirk H. (hodi)]

Guten Abend,

ich habe eine spezielle Frage zu einem RS485 halb duplex Netzwerk mit 
mehreren Teilnehmern.

Im Anhang findet Ihr ein Bild mit einem (quasi) Schema zur 
Fragenstellung.

Diese besteht aus mehreren RS485 halb duplex Treiberbausteinen.
Der Typ MAX1487 soll hier nur als Beispiel fungieren und nur eine 
untergeordnete Rolle in Beziehung auf Anzahl ,Busbelastung
bzw. Leitungslänge darstellen.

Wichtig ist, das alle Teilnehmer mit Failsafe Terminierung ausgestattet 
sind und an den jeweiligen Bus-Enden die entsprechende Terminierung 
aktiv ist.

Wichtig!!!

Die Verbindung der Teilnehmer ist nicht 1:1 über das gesamte Netzwerk.
Das heisst, A+B können zwischendurch wahllos gekreuzt sein.


Meine Frage nun dazu:

Welchen Zustand nimmt der Ausgang RO am jeweiligen RS485 Treiber ein, 
wenn
sich alle Treiberausgänge im inaktivem Zustand (IDLE) befinden.
Bedeutet, jeder empfängt, jedoch keiner sendet.

Hat da jemand praktische Erfahrungen damit?

Ich bin Euch schon jetzt für Eure Antworten dankbar.

Gruß

Dirk

[Veit D. (devil-elec)]

Hallo,

RO benötigt einen Pullup. Damit sollte die Frage beantwortet sein.  :-)

[Dirk H. (hodi)]

Veit D. schrieb:
> Hallo,
>
> RO benötigt einen Pullup. Damit sollte die Frage beantwortet sein.  :-)

Es geht darum, dass die Teilnehmer im Netzwerk vom Anwender wahllos 
gekreut werden können und welchen Ausgangszustand hierbei RO trotz 
Pullup an der jeweiligen Node einnimmt.

[Rufus Τ. F. (rufus)]

Dirk H. schrieb:
> Es geht darum, dass die Teilnehmer im Netzwerk vom Anwender wahllos
> gekreut werden können

Das ist kaputt. Was soll das bringen?

[U. M. (oeletronika)]

Hallo,
> Dirk H. schrieb:
> Meine Frage nun dazu:
> Welchen Zustand nimmt der Ausgang RO am jeweiligen RS485 Treiber ein,
> wenn sich alle Treiberausgänge im inaktivem Zustand (IDLE) befinden.
> Bedeutet, jeder empfängt, jedoch keiner sendet.
Dann hat der BUS auf den Leitungen keine definierte Differenzspannung, 
die von den Treibern selbst kommt.
Die Terminierungwiderstände werden in dem Fall die Leitung A und B auf 
Udiff=0V ziehen.

Schau dir für den jeweiligen RS485-Treiber an, welche Spannungswerte 
diese haben. Für den MAX1487 werden Werte zw. -0,2V...0,2V angegeben.
-> Receiver Differential Threshold Voltage
https://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf
Der Pegel an RO kann also nicht vorherbestimmt werden.

Da die Hysterese nur ca. 70mV ist (Receiver Input Hysteresis), kann es 
auch schon bei Störbeeinflussungen von paar 10mV zu Pegeländerungen an 
RO kommen.

> Hat da jemand praktische Erfahrungen damit?
Um einen def. Zustand auf dem BUS im Ruhezustand zu erreichen, kann man 
die A/B-Leitungen etwas vorspannen, z.B. mit 390...470 Ohm gegen +Ub und 
gnd (siehe Anhang: R51 und R52)
Beachte, dass diese Widerstände mit in die Terminierung eingehen.

Wenn möglich, solltest du auch auf bandbreitenbgrenzte Treiber nutzen. 
Die sind bezüglich Reflexionen, Terminierung und Kabelqualität viel 
gutmütiger.

Wenn du einen def. Ruhepegel hast, kannst du letzlich auch leichter 
Auswerten, wie herum die Leitungen A/B gerade angeklemmt sind. Mußt ja 
das Signal nur zusätzlich negiert bewerten.

Gruß Öletronika

[Strubi (Gast)]

Dirk H. schrieb:
> Hat da jemand praktische Erfahrungen damit?

Ja. Willst du die Verpolung detektieren -> Spannungsmessung.
Google: "fehlersuche in rs485-netzwerken", von Saia-Burgess hat sich da 
mal einer etwas Mühe gemacht.
Willst du aber eine verpolungstolerante RS485-Lösung, muss ich die 
schlechteste Firmware aller Zeiten zitieren: "No such fun".

[Abdul K. (ehydra)]

Um es kurz zu machen: RO wird einmal z.B. 0 ausgeben und bei den 
Busteilnehmern mit gekreuzten Differentialleitungen eben den inversen 
Wert, im Beispiel also 1.
Dein Leitungscode muß das berücksichtigen. Differentielle Kodierung wäre 
dafür eine Möglichkeit. Asymmetrische Blockcodes die andere.

[Dirk H. (hodi)]

Danke für die Antworten.

Mir geht es hier weniger um die nichtinverse/inverse Kodierung bzw. 
Auswertung auf der Sekundärseite, sprich RO Ausgang zum Comtroller.
Das stellt hierbei software- als auch protokolltechnisch eine 
untergeordnete Rolle dar.

Es geht vielmehr um die physikalische Beeinflussung auf der (primär) 
Treiberseite untereinander mit der Anzahl X an Failsafe Terminierungen 
und ihren Wechselwirkungen untereinander (wenn man das so bezeichnen 
darf).

[Abdul K. (ehydra)]

Es gibt keine. Es wird einfach funktionieren. Apple hat das beim 
LocalTalk-Bus genau so gemacht. Nur eben mit RS422-Transceivern, was 
aber keinen Unterschied macht. Das Handbuch zum LocalTalk kann man frei 
runterladen.