gelegentliche Datenfehler auf RS485

Also ist dein Bus überhaupt nicht terminiert? Mit 120ohm wird es 
schlecht? Dann Terminierung mal auch auf 5v u gnd legen. Fail safe halt.

Hi

Wie es aussieht, sendest Du laufend den kompletten Display-Inhalt?
Würde die zu übertragenden Daten auf ein Minimum reduzieren und eine 
Prüfsumme mitschicken.
Dann musst Du aber auch 'nachhören', ob die Daten korrekt empfangen 
wurden um Diese ggf. neu zu verschicken.

Die Sequenzen, wo nur noch Müll auf dem Display erscheint, sieht schon 
nach Daten-Gulasch aus, ein verschobener Pointer hört sich da für mich 
schlüssig an.

Die kleineren Fehler werden Übertragungsfehler sein - aber schon bei 10 
Metern?

MfG

Andreas F. schrieb:
> Die Übertragung erfolgt durch fertig gekaufte Cat5-Patchkabel, auf den
> .. Die GesamtBusLänge ist deutlich kürzer als 10 Meter

Dann nimm doch mal ein kurzes Kabel zum Test
und achte auch auf die richtigen Paare.

Wenn du half duplex machst, dann musst du failsafe terminieren, oder
irgendwie anders sicherstellen, dass die Pegel nicht wandern.

Andreas F. schrieb:
> Die Daten- Leitungen sind mit TVS-Dioden ausgestattet.

Ist evtl. die Kapazität der TVS-Dioden zu hoch?

Gruß Anja

Wow. Mit so viel Resonanz (und so schnell) hatte ich nicht gerechnet.
Habe morgen Frühdienst und muss mich vorbereiten (Schlaf).
Ich finde aber sicher eine Gelegenheit mir das Obige in Ruhe 
durchzulesen und noch am Vormittag entsprechend zu antworten.
Danke schonmal :) N8 (AFK)

U. M. schrieb:
> Problem könnte sein, wenn die Leitungen nicht vorgespannt sind.
> -> Leitung A mit ca. 470R ... 1k gegen +Ub
> -> Leitung B mit ca. 470R ... 1k gegen gnd

sollte es sein ;)

So. Bin auf der Arbeit und habe somit Zeit, mich dieser Sache hier zu 
widmen. Blöderweise kann ich wiederum hier keine Versuche durchführen :)

Ich danke Euch für die wertvollen Anregungen und Richtungsweiser. Ich 
versuche mal, auf alles einzugehen. Hierbei werde ich mich auch gleich 
als Noob outen.
Dies ist mein erstes Projekt dieser Art. Ich kämpfe nun schon seit einem 
Jahr damit (in der Freizeit). Vorher wusste ich von serieller 
Kommunikation nur soviel, daß ich sie immer mit paralleler K. 
verwechselt habe.

Um so wertvoller ist mir dieses Forum, in welchem ich auch sehr viel 
"nur" lese.

Jim M. schrieb:
> Warten die Slaves auf den Master?
Im Prinzip ja. Hatte auch schon so eine Idee. Ich müsste - zumindest zu 
Debug-Zwecken - mal an geeigneter Stelle ein delay() im ms-Bereich 
einfügen. So weit bin ich aber noch nicht, der Code sollte eigentlich(!) 
auch so funktionieren.
Die Sache ist die, das System stammt nicht von mir, ich bastele nur das 
"Frontend" aus vorgegebenen Code-Schnipseln zusammen. An den 
Bibliotheken herumzupfuschen, sehe ich nicht als meine Aufgabe. Ganz 
davon abgesehen, daß ich dafür auch zu blöd wäre :)

Jim M. schrieb:
> Ansonsten müsstest Du folgendes:
>
>> läuft irgendwelcher Mist über die Leitung.
>
> mal mit einem Oszi einfangen.
Das Problem ist, ich habe nur so eine (etwas ältere) Conrad-Krücke mit 
5MHz. Mein Versuch, den Bus abzuhören, ist daran gescheitert, daß ich 
kein auswertbares Signal angezeigt bekommen habe.
Ich habe aber einen Logic-Analyser benutzt. Der zeigte mir im Vergleich 
von A und B (die meines Wissens genau(!) spiegelverkehrt sein müssen) 
gelegentliche - scheinbar spontane - Pegelsprünge auf nur einem Kanal. 
Deren Ursprung ließ sich hierbei natürlich nicht ermitteln.

Hauke Haien schrieb:
> Also ist dein Bus überhaupt nicht terminiert? Mit 120ohm wird es
> schlecht? Dann Terminierung mal auch auf 5v u gnd legen. Fail safe halt.

Stimmt. Nicht terminiert. Es heißt im Allgemeinen, daß das bei meinen 
Buslängen nicht erforderlich sei. Maxim behauptet auch im Datenblatt, 
daß der MAX487 Failsafe "eingebaut" hat.
Und ich habe 100 Ohm getestet. 120 Ohm will ich noch versuchen, sobald 
die Widerstände da sind. (Ich lebe hier in der Provinz - Erfurt - und es 
gibt hier keinen gescheiten lokalen Dealer mehr. Muss alles online 
einkaufen).
Die Datenleitungen "vorspannen" habe ich als Einziges noch nicht 
versucht.
Mal sehen, ob ich das elegant auf meine PCBs bekomme. Will nicht extra 
neue anfertigen für einen Versuch.

Rufus Τ. F. schrieb:
> Welche Baudrate verwendest Du?
Da bin ich mir nicht sicher. Ich habe nicht viel Ahnung von der Materie. 
Der Master wird per USB seriell mit 250000 angeschlossen. Per socat wird 
ein UDP-Stream "erzeugt" und an den Master geschickt (siehe Code).
Mehr verstehe ich davon nicht :( Wieviel effektive Baudrate das dann 
ergibt, weiß ich nicht. Ich habe mal versucht, das irgendwie zu 
errechnen... Habe es dann nach 10 Seiten "Internet" lesen aufgegeben.

1

REM Specify the number of the COM port your Arduino is connected to:

2

set COMPORT=5

3

4

set /A TTYNUM=%COMPORT%-1

5

mode COM%COMPORT% BAUD=250000 PARITY=N DATA=8 STOP=1 TO=off DTR=on

6

socat\socat -v UDP4-RECV:5010,ip-add-membership=239.255.50.10:127.0.0.1,reuseaddr!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM%

7

8

pause

> Wirds besser, wenn Du die Baudrate drosselst?
Um die Baudrate zu drosseln, müsste ich in die Library rein. Die wird 
dort vorgegeben.
> Was für eine Taktquelle verwenden Deine µCs?
Wenn ich das richtig verstehe, sind das wohl die 16 MHz des AVR. Oder?

oszi40 schrieb:
> Dann nimm doch mal ein kurzes Kabel zum Test
Habe ich auch schon versucht. Verschiedenste Kabel und -Längen. Manchmal 
hatte ich den Eindruck, daß die Störungen abnehmen, wenn ich mehrere 
Slaves in der Kette anschließe.
Ich schrieb auch: "deutlich unter 10m". Meistens habe ich bloß einen 
halben oder 2 Meter angeschlossen. Das Ganze läuft i.Moment noch auf dem 
Tisch.

Johann Klammer schrieb:
> Wenn du half duplex machst, dann musst du failsafe terminieren,

Das werde ich auf alle Fälle als Nächstes versuchen.

Anja schrieb:
> Ist evtl. die Kapazität der TVS-Dioden zu hoch?

Dazu kann ich mich nicht sachkundig äußern. Wieviel F sind "zu hoch"?
Ich benutze für die Datenleitungen die SM712 (angeblich speziell für 
RS485 geeignet), für die 12V-Leitung nehme ich (auf jedem Node) jeweils 
eine SMBJ12A.

U. M. schrieb:
>> ... jedoch häufen sich mehr und mehr Anzeigefehler (falsche
>> Zeichen).
> Und du bist sicher, dass dies durch das Interface bedingt ist und nicht
> durch Macken im Display selbst?
Das ist ausgeschlossen. Obwohl ich das nie in Erwägung gezogen hatte, 
habe ich schon verschiedene Displays ausprobiert. Die sind unschuldig :)

Es ist eindeutig der RS485-Bus. Ich hatte einen Versuch laufen, in 
welchem ich den LCD-"Treiber" AVR (UNO) direkt per USB betrieben habe: 
Keine Fehler!
> -> Timings der Richtungsumschaltung  RE/DE ist nicht korrekt
> z.B. weil es zu spät aktiviert wird (also nicht vor dem Startbit)
>
> -> Busteilnehmer Antworten zu schnell, während der voherige noch den Bus
> mit RE/DE = High blockiert.
>
> -> Baudraten (Bitzeiten) passen nicht gut zusammen (Mit Oszi
> korrigieren).
Klingt alles sehr einleuchtend.
Diese Punkte müsste ich aber mit dem Entwickler der Software 
diskutieren. Ich will erst mal meine(!) Fehler ausschließen, bevor ich 
den Mann belästige. Der hat mit seinem Studium genug um die Ohren. Das 
System befindet sich noch in der Beta-Phase und ich darf da (aufgrund 
meiner möglichen Schlamperei) nichts aufmischen.

Was ich aber auch interessant finde an Euren Antworten, daß niemand auf 
mein Breakout des Kabels eingegangen ist. Scheint wohl egal zu sein, wie 
ich Signal und Versorgung auf die 4 Adernpaare verteile?
Das Einzige, was ich hierzu gelesen habe, ist, daß das Signal auf 1 und 
2 (orange/orange-weiß) sein sollte, da diese am wenigsten übersprechen.

Nach der Lektüre dieses Thread liegen 3 Möglichkeiten oben:
- Failsafe für sicheren Pegel
- Timing der Halbduplex-Umschaltung

Jim M. schrieb:
> Falls Du die Zeilen regelmäßig neu schreibst: Stack Overflow auf dem
> Master µC wäre auch eine Möglichkeit.
Das habe ich eben noch gefunden.
Es werden immer ganze Zeilen neu geschrieben, aber nur, wenn sich ein 
Wert geändert hat.
Stack-Overflow??? Habe ich nur eine bildliche Vorstellung, was das sein 
könnte. Man müsste wohl einen Puffer(?) vergrößern oder schneller (oder 
mit besserem Timing) leeren.
Das müsste ich dann(!) mit dem Entwickler diskutieren.

Wenn ich alle möglichen Hardware-Kalamitäten (ich liebe: Kasperfallen) 
ausgeschlossen habe, lade ich ihn mglwse hierher ein (wenn er es nicht 
sowieso schon liest?) :)

Habe ich noch was vergessen? Fragt mich einfach.
Nochmal: Danke :)

Wie sieht es an der RO-Leitung (Empfänger-Ausgang) der RS-485-Treiber 
aus?
Worst case: während des Sendens ist der Pin hochohmig, so daß der UART 
sich irgendwelche Pegel zusammenphantasiert und Blödsinn empfängt. Die 
Software verläßt sich darauf, daß alle empfangenen Daten von einem 
anderen Busteilnehmer kommen, und versucht ihr bestes, dem Blödsinn 
gerecht zu werden...
Gegenmaßnahmen:
 - UART-Empfänger während des Sendens ausschalten
 - ignorieren, was während des Sendens empfangen wurde
 - Pullup an RxD

Aber zuerst würde ich Öletronikas Punkte prüfen: Leitungen vorgespannt? 
Timing bei der Übergabe geklärt? (wie schnell nach Ende des Stopbits 
schaltet der Master den Sender aus? Wie schnell antwortet der Slave? 
Dazwischen sollte genug Zeit für Baudratentoleranz liegen)

Und schließlich: verwendet das Protokoll eine gute Prüfsumme? Wenn ja 
(und wenn die beim Empfang auch beachtet wird), muß der Datenmüll durch 
einen Softwarefehler (Puffer-Überlauf, verbogener Pointer...) innerhalb 
eines der beteiligten Geräte entstehen.

1. Hier sind noch sehr gute Tips zu RS485:
http://www.ti.com/lit/an/snla049b/snla049b.pdf
2. Sind die GNDs von den Busteilnehmern sicher miteinander verbunden?

Werner

Hi

>Die Leitungen A und B sind ja differentielle Signale. Meist wird keine
>Masse dazu herausgezogen.

Ten Ways to Bulletproof RS-485 Interfaces (AppNote 1057)

sagt dazu

A typical mistake is to connect two
nodes with only two wires. If you do this, the system may radiate
high levels of EMI, because the common-mode return
current finds its way back to the source, regardless of where
the loop takes it. An intentional ground provides a
low-impedance path in a known location, thus reducing
emissions.

MfG Spess

Die bestellten Widerstände wurden heute geliefert. Kam noch nicht zur 
Testinstallation.
Die oben genannten Dokumente habe ich gelesen und - zum wesentlichen 
Teil - auch verstanden :)
Werde ganz sicher hier beschreiben, wie der Krimi weiter geht :)
Bis dann.

Ich hatte einen Nachmittag frei und die Gelegenheit genutzt, ein 
komplettes Master-PCB neu herzustellen (das nachträgliche Drauf-Gebastel 
auf einer SMD-Platine bringt es nicht wirklich).

Nun habe ich Failsafe 2x 750 Ohm und als Terminator zwischen A und B 130 
Ohm gesetzt. (Zum Glück passt das Rechenbeispiel in den o.g. Papieren zu 
meinem Fall). Am anderen Ende bleiben 120 Ohm als Terminierung.
Als Differenz zwischen A und B habe ich jetzt (in Ruhe und mit dem 
Multimeter gemessen) 400 mV (falls ich mich richtig erinnere, bin auf 
der Arbeit).

Der Bus funktioniert einwandfrei, jedenfalls die Slaves, die nur die 
Änderung von Schalterpositionen zu senden und die Helligkeit einer LED 
mittels empfangener Werte zu steuern haben. Aber die gingen auch vorher 
schon.

Auf meinem Display kommt nun garnichts mehr an. Ich vermute aber, das 
liegt nicht am neuen Master, ich habe sehr wahrscheinlich irgendwas 
anderes vermasselt. Jedenfalls wird der AVR etwas warm. Da muss ich 
nochmal bei.

Nosnibor schrieb:
> Gegenmaßnahmen:
>  - UART-Empfänger während des Sendens ausschalten
>  - ignorieren, was während des Sendens empfangen wurde
Das wird doch m.E. durch das Verbinden von RO und DI gewährleistet (?) 
Außerdem hat der fragliche AVR nichts zu senden. TX hängt in "der Luft".
>  - Pullup an RxD
Welcher ist das? Mein Verständnis sagt mir, daß es sich um den RX0 am 
AVR handelt. Ein Pullup hier ändert auch nichts.

Ich bin jetzt kurz davor, die Hardware als Problemquelle auszuschließen.
Nach einem weiteren Durchlauf - diesmal mit funktionierendem Display - 
kommt die Erkenntnis, daß sich NICHTS geändert hat.

Alle Slaves arbeiten wie erwartet, nur der, an dem das Display hängt, 
macht Zicken (spontan auftretende falsche Zeichen).

Werde wohl doch den Entwickler des Protokolls kontaktieren. (es sei 
denn, hier hat noch jemand eine zündende Idee.

Zur Belohnung habe ich mal ein Foto von meinem neuen Masterboard (ein 
Shield für den "Arduino MEGA 2560 R3". Zu sehen sind die drei MAX487 mit 
Failsafe-Widerständen, die drei Pull-Downs für die TXenable und die drei 
RJ45-Buchsen.

Jetzt will ich aber hören: "Das haste fein gemacht". :)

Hi

Andreas F. schrieb:
> Jetzt will ich aber hören: "Das haste fein gemacht". :)

Schaut doch nett aus :)

Hast Du von der Display-Platine noch einen Ersatz da und Diesen 
versuchshalber benutzt, oder Beide gleichzeitig?
Klar können vereinzelt Bytes verstümmelt ankommen, das muß man per 
Prüfsumme ect.pp. rausfiltern und die Übertragung neu anstoßen.
Wenn der Slave nicht selber 'oha, Fehler' senden darf, muß der Master 
abfragen, ob die Übertragung korrekt war, worauf der Slave dann ja 
antworten darf.
Oder ähnlich den Time-Slots beim 1-wire, daß jeder Slave, Der Probleme 
mit dem Paket hatte, den Fehler anzeigen kann, vll. wäre das Paket ja 
für Ihn gewesen und mit anderer Empfänger-ID könnte die Prüfsumme ja 
vll. passen.

MfG

posti schrieb:
> Hast Du von der Display-Platine noch einen Ersatz da und Diesen
> versuchshalber benutzt, oder Beide gleichzeitig?
Das ist eine SUPER Idee :)
Muss nur erst noch ein display-kompatibles Slaveboard bauen. Das ist 
kein Problem, muss nur die Zeit finden (dauert inkl. Bohren und Löten 
einen entspannten Tag). LCDs habe ich auch noch liegen.
Dann könnte ich sehen, ob auf beiden der gleiche Schrott läuft und wäre 
der Quelle einen Schritt näher. Danke.
> Klar können vereinzelt Bytes verstümmelt ankommen, das muß man per
> Prüfsumme ect.pp. rausfiltern und die Übertragung neu anstoßen.
> Wenn der Slave nicht selber 'oha, Fehler' senden darf, muß der Master
> abfragen, ob die Übertragung korrekt war, worauf der Slave dann ja
> antworten darf.
Meines Wissens gibt es (noch) keine Prüfsumme. Das Projekt ist noch in 
der Beta-Phase und ich bin einer der Minen-Hunde (Ian: Nicht böse sein. 
Mache ich sehr gerne.)
> Oder ähnlich den Time-Slots beim 1-wire, daß jeder Slave, Der Probleme
> mit dem Paket hatte, den Fehler anzeigen kann, vll. wäre das Paket ja
> für Ihn gewesen und mit anderer Empfänger-ID könnte die Prüfsumme ja
> vll. passen.
Das Problem ist, daß ich (aus welchem Grund auch immer) dem Slave durch 
Abtrennen des TX das Senden verbieten muss. Sonst bleibt das LCD dunkel.
Woran das liegt, habe ich auch noch nicht herausgefunden. Eventuell gibt 
es da Stress zwischen den "RS485"- und Adafruit-Bibliotheken (von deren 
Inneren ich NULL Ahnung habe).
Das liegt aber nahe... Wieso bin ich da nicht schon eher drauf gekommen, 
die Probleme begannen ja mit dem Display. Kann aber auch sein, daß die 
Probleme dadurch erst sichtbar wurden.