RS-485, Kommunikationsproblem mit dem LTC2850

[Ludo S. (ludo916)]

Hallo Zusammen,

ich versuche mit dem LTC2850 eine RS-485 Kommunikation mit einem Sensor 
zu erstellen. Mit meiner Software bekommen ich eine Fehlermeldung und 
keine Ergebnisse. Wenn ich aber den Sensor mit einem USB <-> RS-485 
Modul anschließe bekomme ich die richtige Werte (Ergebnisse) vom Sensor. 
Dieses Modul habe ich am Eingang A & B vom LTC2850 angeschlossen.

Ich habe noch mal meinen LTC2850 - Baustein verbunden und die serielle 
Kommunikation mit einem Logic-Analyser mitgehört. Mir ist aufgefallen, 
dass ich auf der RX-Leitung direkt das bekomme, was gerade über TX sende 
und erst ca. 0.34s später kommt die richtige Antwort.

hat zufällig jemand eine Idee warum, sich der Sensor so verhält? 
Manchmal bekomme ich nicht das, was ich sende, sondern irgendeine 
Information. Ich habe ich verschieden Anschlussmöglichkeiten der beiden 
Pins (*RE & DE) ausprobiert und bekomme immer das gleiche Verhalten.

VG

[Schorsch X. (bastelschorsch)]

RS-485 ist eine halbduplex Kommunikation, d.h. der Empfänger (wenn 
aktiv) hört das mit, was der Sender sendet. Entweder per Software die 
eigenen Daten wegfiltern, oder beim Senden den Empfänger deaktivieren 
z.B. über den RE Eingang.

[Ludo S. (ludo916)]

Schorsch X. schrieb:
> RS-485 ist eine halbduplex Kommunikation, d.h. der Empfänger (wenn
> aktiv) hört das mit, was der Sender sendet. Entweder per Software die
> eigenen Daten wegfiltern, oder beim Senden den Empfänger deaktivieren
> z.B. über den RE Eingang.

Hallo,
Dank für deine schnelle Rückmeldung.

Vielleicht habe ich es nicht richtig verstanden. Ich sende die Abfrage 
vom PC über UART an den LTC2850 und der soll über RS485 die Daten vom 
Sensor holen und mir zurückgeben.
Aber ich höre meine Anfrage im gleichen Moment über die UART (RX) und 
kurz danach die richtige Antwort vom LTC2850.
Da ich ein Bild der verschiedene Schaltzustände (gelbe Markierung), die 
ich ausprobiert habe.

VG

[Rufus Τ. F. (rufus)]

Ludo S. schrieb:
> Aber ich höre meine Anfrage im gleichen Moment über die UART (RX)

Das ist logisch; Du hast die "*RE"-Leitung des RS485-Transceivers auf 
Masse gelegt, damit kommt an dessen "RO"-Ausgang alles 'raus, was auf 
dem RS485-Bus geschieht.

Möchtest Du das nicht, musst Du die Leitung während des Sendens 
deaktivieren, was am einfachsten geht, wenn Du *RE mit DE verbindest.

Bist Du Dir sicher, daß Deine Monoflop-Steuerung das zur Baudrate 
passende Timing produziert?

Bessere UARTs als die PC-Standard-UART enthalten Hardwareunterstützung 
für die Ansteuerung von RS485-Transceivern, auch etliche 
USB-Seriell-Bridges können das, so daß derartige Monoflop-Frickeleien 
nicht nötig sind.

Soll der Aufbau wirklich an einem PC betrieben werden, oder ist das nur 
ein Testbetrieb?

[Achim S. (Gast)]

Ludo S. schrieb:
> Da ich ein Bild der verschiedene Schaltzustände (gelbe Markierung), die
> ich ausprobiert habe.

Schorsch hat es ja eigentlich schon beschrieben. Wenn du die eigenen 
Nachrichten nicht mithören willst, dann musst diese "Schaltzustände" 
zwischen Senden umd Empfangen umstellen.

- wenn du sendest musst du DE=RE=1 stellen (und R= per Pullup auf 
Ruhepegel halten). Dann ist dein Baustein in Senderichtung aktiv, in 
Empfangsrichtung ignoriert er aber, was er grade selbst auf die 
Leitungen treibt.
- wenn du nicht sendest musst du DE=RE=0 stellen. Dann ist dein Baustein 
in Senderichtung inaktiv, und du kannst Nachrichten von anderen 
Bausteinen empfangen.

Gleichzeitig senden und empfangen geht nicht, weil die Sende- und 
Empfangsrichtung über die identischen Leitungen läuft (deshalb 
halbduplex).

[Ludo S. (ludo916)]

Rufus Τ. F. schrieb:

>
> Möchtest Du das nicht, musst Du die Leitung während des Sendens
> deaktivieren, was am einfachsten geht, wenn Du *RE mit DE verbindest.

Das stimmt. Ich habe nachher beim Test die *RE-Leitung von der Masse 
getrennt und mit DE verbunden. Leider bekam ich immer das gleiche raus.

Rufus Τ. F. schrieb:
> Bist Du Dir sicher, daß Deine Monoflop-Steuerung das zur Baudrate
> passende Timing produziert?

Da bin ich noch nicht ganz sicher.

Rufus Τ. F. schrieb:
> Bessere UARTs als die PC-Standard-UART enthalten Hardwareunterstützung
> für die Ansteuerung von RS485-Transceivern, auch etliche
> USB-Seriell-Bridges können das, so daß derartige Monoflop-Frickeleien
> nicht nötig sind.

Das wäre bei meiner Hardware super. Die UART meines Controllers 
unterstützt diese leider nicht. Deswegen brauche ich diesen Monoflop, 
vielleichet gibt es auch eine andere Möglichkeit?

Rufus Τ. F. schrieb:
> Soll der Aufbau wirklich an einem PC betrieben werden, oder ist das nur
> ein Testbetrieb?

Ja. und alle USB-port vom implementierten HUB sind schon belegt.

[Ludo S. (ludo916)]

Achim S. schrieb:
> (und R= per Pullup auf
> Ruhepegel halten)

meinst die damit die RO-Leitung? Da habe ich gestern auch mal mit einem 
10k Pullup ausprobiert. Es war leider nicht besser.

Ich habe auch mit RE=*RE = 0 und DE=*RE=1 versucht. Es kam zwar was 
zurück aber mit Error Bit usw. leider habe kein Bild mehr davon.

[Ludo S. (ludo916)]

Ludo S. schrieb:
> Ich habe auch mit RE=*RE = 0 und DE=*RE=1 versucht. Es kam zwar was
> zurück aber mit Error Bit usw. leider habe kein Bild mehr davon.

siehe Foto !

[Achim S. (Gast)]

Ludo S. schrieb:
> Ich habe auch mit RE=*RE = 0 und DE=*RE=1 versucht.

Und das hast nach dem Senden im richtigen Zeitpunkt vom einen aufs 
andere umgeschaltet?

Ludo S. schrieb:
> siehe Foto !

Du hast bei deinem Bildausschnitt die Signalnamen abgeschnitten. Wähle 
bitte den Ausschnitt so, dass man eindeutig erkennen, welches Signal 
jeweils gezeigt ist.

[Rufus Τ. F. (rufus)]

Ludo S. schrieb:
> Die UART meines Controllers unterstützt diese leider nicht. Deswegen
> brauche ich diesen Monoflop, vielleichet gibt es auch eine andere
> Möglichkeit?

Natürlich, Dein Controller kann das auch in Software machen. Welcher ist 
es denn?

>> Soll der Aufbau wirklich an einem PC betrieben werden, oder ist das nur
>> ein Testbetrieb?
>
> Ja. und alle USB-port vom implementierten HUB sind schon belegt.

Du widersprichst Dir. Controller oder PC?

Im übrigen: Sieh mal nach, wofür das Wort "Implementieren" steht.

[Ludo S. (ludo916)]

Rufus Τ. F. schrieb:
> Du widersprichst Dir. Controller oder PC?
>
> Im übrigen: Sieh mal nach, wofür das Wort "Implementieren" steht.

Sorry. Das System wird nicht an einem PC angeschlossen. Das ist ein 
kleines Auswertesystem, wo ein iMX6-Prozessor (in Form eines Computer on 
Modul) drauf kommt.Ich verwende deshalb die UART <-> RS485 (LTC2850) 
-Schnittstelle um die Kommunikation mit einem RS485-unterstützen Sensor 
zu erstellen.

Rufus Τ. F. schrieb:
> Dein Controller kann das auch in Software machen.

Signal filtern??


Achim S. schrieb:
> Du hast bei deinem Bildausschnitt die Signalnamen abgeschnitten. Wähle
> bitte den Ausschnitt so, dass man eindeutig erkennen, welches Signal
> jeweils gezeigt ist.

Auf dem Bild:
Signal 1 --> Tx-Leitung
Signal 2 --> Rx-Leitung
Signal 3 --> RS485-A
Signal 4 --> RS485-B


Achim S. schrieb:
> Und das hast nach dem Senden im richtigen Zeitpunkt vom einen aufs
> andere umgeschaltet?

Das könnte eventuell ein Timing Problem vom SN74AHC123AD seien. Ich 
verstehe leider immer noch nicht warum dieses Signal eintrifft wenn DE 
(aktiv) = *RE(inaktiv) = 1. Die Umschaltung erfolgt sobald nichts mehr 
auf Tx gesendet wird und da kommt schon was zurück, obwohl Rx nichts 
machen muss.

[Rufus Τ. F. (rufus)]

Ludo S. schrieb:
>> Dein Controller kann das auch in Software machen.
>
> Signal filtern??

Nein. Die Routine, die die UART beschreibt, aktiviert vor dem Senden die 
Steuerleitung und deaktiviert sie, wenn die UART signalisiert, daß das 
letzte Bit das Sendeschieberegister verlassen hat.

Es gibt UARTs, die dann einen Interrupt auslösen können, es gibt UARTs, 
die dafür ein abfragbares Bit im Statusregister haben (wie z.B. die im 
PC-Bereich ubiquitäre 8250/16450 etc.).

Wenn es diese Information nicht gibt, wird vor dem Senden eines 
Telegrammes ein Timer mit einem von Baudrate und Telegrammlänge 
abhängigen Wert aufgezogen, in dessen Interrupthandler dann die 
Steuerleitung wieder deaktiviert wird.

Mit dem Problem haben sich für Deinen Controller aber auch schon andere 
Leute auseinandergesetzt, z.B. hier:
https://community.nxp.com/thread/310625

[Achim S. (Gast)]

Ludo S. schrieb:
> Auf dem Bild:
> Signal 1 --> Tx-Leitung
> Signal 2 --> Rx-Leitung
> Signal 3 --> RS485-A
> Signal 4 --> RS485-B

Ok, danke. Wie wäre es, wenn du direkt DE und RE messen würdest? Dann 
wüsste man, ob deren Timing stimmt.

Ludo S. schrieb:
> Ich
> verstehe leider immer noch nicht warum dieses Signal eintrifft wenn DE
> (aktiv) = *RE(inaktiv) = 1. Die Umschaltung erfolgt sobald nichts mehr
> auf Tx gesendet wird und da kommt schon was zurück, obwohl Rx nichts
> machen muss.

Wenn der Receiver disabled ist und die RO Leitung überhaupt nicht 
definiert wird (also kein ausreichender Pullup), dann kann sie 
"irgendwas" anzeigen. Z.B. mitkoppeln, wenn irgendeine benachbarte 
Leitung schaltet. Oder beliebig um die Umschaltschwelle herum wackeln.

Eine Oszilloskopmessung (anstelle der Logikanalysatormessung) würde 
Klarheit schaffen, ob auf RO definierte Logiksignale unterwegs sind oder 
ob man da nur das Zufallsergebnis einer undefinierten Logikleitung 
sieht.

[Ludo S. (ludo916)]

Achim S. schrieb:
> Wenn der Receiver disabled ist und die RO Leitung überhaupt nicht
> definiert wird (also kein ausreichender Pullup), dann kann sie
> "irgendwas" anzeigen. Z.B. mitkoppeln, wenn irgendeine benachbarte
> Leitung schaltet. Oder beliebig um die Umschaltschwelle herum wackeln.

Hallo Zusammen,

erstmal vielen Dank für eure hilfreiche Antworten. Timing war richtig 
aber der Pullup widerstand auf der Ro-Leitung war nicht ausreichend 
genug. Den habe ich angepasst und bekomme nun ein sauberes Signal 
zurück.

Rufus Τ. F. schrieb:
> Mit dem Problem haben sich für Deinen Controller aber auch schon andere
> Leute auseinandergesetzt, z.B. hier:
> https://community.nxp.com/thread/310625

Danke für den Link. Die Seite hatte ich mal irgendwann mal kurz 
geöffnet.


noch mal besten Dank an alle.

VG