Probleme mit RS-485 Bus

[beta4881]

Hi!

Erst einmal großes Lob an dieses Forum, das ich schon oft konsultiert habe!

Ich habe folgendes Problem mit einem RS-485-Bus, den ich im Rahmen eines verteilten Roboters (der auf 3 Atmega32 aufbaut) verwende: Sobald ich mehr als 2 Teilnehmer an den Busanschließe, wird die Datenübertragung teilweise fehlerhaft. Entweder werdn Zeichen übertragen, die nach Übertragungsfehlern aussehen, oder die Teilnehmer antworten gar nicht. Das ganze scheint mir nicht immer gleich aufzutreten, manchmal funktioniert die Kommunikation auch, wenn man die Busstecker neu einsteckt oder die Reihenfolge am Bus ändere.

Aufbau wie folgt (gemäß diesem Prinzip):

Bild hier  

(Vollständige Schaltpläne hier!)

Der PC stellt mit der Busumsetzerbox den Master dar, die bis zu 3 "Seiltrommelboxen" die Slaves. Der PC ist alternativ über USB oder per RS-232 (seriell) anschließbar.

Für den RS-485-Bus wurde der Baustein max488 für 4-Draht-Technik verwendet (Datenblatt). Schließt man die Seiltrommelboxen jeweils einzeln an, funktioniert die Kommunikation wunderbar, bei einer zusätzlichen Box nur noch mit Schwierigkeiten, bei einer weiteren gar nicht mehr.

Buskabel: Hier wurde ein herkömmliches Netzwerkkabel (Patch, nicht Crossover) verwendet. Dieses transportiert auf 4 Adern die Datensignale und auf den restlichen 4 Adern die 12V Spannungsversorgung. Jede Mikrocontrollerplatine in den Seiltrommelboxen zieht ca. 100mA. Die Verkabelung erfolgt als Ring, also an jedem Teilnehmer sind 2 Buchsen, wo der Bus durchgeschleift und für die aktuelle Box abgegriffen wird. Die Kabel sind jeweils nur 2-5 m lang.

Abschluss: Verwendet man nur 2 Teilnehmer am Bus, funktioniert die Kommunikation wunderbar auch ohne Abschluss (s. Datenblatt). Bei mehreren Busteilnehmern führt das Hinzufügen des Abschlusses nicht zu einer Verbesserung, stattdessen steigt der Stromverbrauch um 100-200 mA - was ich etwas viel finde.

Kollisionen auf dem Bus werden durch Adressierung und einzelnes Ansprechen der Slaves vermieden!

Irgendwelche Ideen, was der Fehler sein könnte?

Evtl. Ansatzpunkte:

- Signal und Versorgung in einem Kabel. 12V Gleichstrom bei max. 300-500 mA halte ich eigentlich nicht für bedenklich bei Übertragungsraten von 2400 bps bis 9600 bps

- Baustein max488: Lt. Hersteller Maxim gibt es zwei Varianten für etwas verschiedene Temperaturbereiche, die sich jedoch überlappen: Darf man die evtl. nicht gemischt einsetzen?

[shaun]

RS485 definiert einen Zweidrahtbus, wie also hast Du vier Adern angeknotet? Ein Vierdrahtbus mit differernzieller Übertragung wäre RS422, dort hast Du ein Paar für eine, eins für die andere Richtung. Wenn Du bei einem RS422 versuchen würdest, mehr als 2 Knoten anzuschliessen, hast Du zwangsläufig das Problem, das immer mehrere Sender an einem Aderpaar hängen, das wird dann chaotisch und ist so auch nicht vorgesehen.
Ich habe RS485 auf einem Paar eines Netzwerkkabels realisiert, wobei das Steuergerät bereits Abschlusswiderstände enthält, daran werden dann die Knotenmodule mit je zwei parallel geschalteten RJ45-Buchsen aufgereiht und ans Ende kommt ein Stecker, der das RS485-Paar mit 120 Ohm terminiert. Läuft astrein, man muss natürlich aufpassen, dass man ein Protokoll definiert, bei dem sichergestellt wird, dass ein Knoten erst dann sendet, wenn er das auch darf.

[beta4881]

Ich weiß, Wikipedia ist nicht immer korrekt, aber da - und soweit ich mich erinnern kann - auch an anderen Stellen, steht:

"Die EIA-485 Schnittstelle benutzt in der Regel lediglich ein Adernpaar und wird halbduplex betrieben, mit zwei Adernpaaren ist aber auch Vollduplexbetrieb möglich."

http://de.wikipedia.org/wiki/RS485

Allerdings weiß ich nicht, was der Unterschied zwischen rs485 und rs422 ist bzw. habe es nicht verstanden. Hast du da eine gute Übersicht?

--

Das Problem selber war folgendes: max488 hat keine enable Leitungen, mit dem max489 kann das behoben werden.

[pongi]

Herkömmliches Netzwerkkabel (UTP) hat keine Schirmung. Jedoch sollte man bei einer RS485 Verbindung eine geschirmte, verdrillte Leitung benutzen. Vielleicht liegst ja daran.
Bei uns im Betrieb haben wir fast 100m RS485 auf solcher weise, es gibt nur gelegentlich Fehlübertragungen.

[beta4881]

Am Kabel wird es nicht liegen: Solange nur eine Box angeschlossen ist, funktioniert es ja (auch bei längeren Leitungslängen).

[bax]

Der Kern des Problems ist ja schon von shaun genannt worden: Mehrere Sender auf der selben Leitung beißen sich, auch wenn sie gerade nichts senden wollen, halten sie ja ein festes Potential auf den Sendeleitungen. Also brauchst Du das Enable, um die Sender, die inaktiv sind, hochohmig zu schalten.

Mir ist noch nicht ganz klar, was du mit ringförmige Verkabelung meinst. Welche RX TX sind wie mit den anderen Teilnehmern verbunden?

Um die Hardware so weiter nutzen zu können, fällt mir nur eins ein: Du könntest den Bus in einzelne Segmente von Teilnehmer zu Teilnehmer aufteilen, dann müssen die Teilnehmer erkennen, ob die kommenden Daten für sie sind, wenn nicht muß der Teilnehmer die Daten weiter zum nächsten schicken. Also ein Token-Ring Protokoll machen.

greetz Rajko

PS: ansonsten ist RS485 extrem störresistent, zumindest bei rel. geringen Datenraten. Wir benutzen für unsere Module in der Gebäudetechnik RS485 mit 9600 baud. Dabei ist es schon öfters vorgekommen, das wir in einem 4-adrigen 'Telefonkabel' 24V Wechselspannung und die RS485 (ohne Masseleitung) bis zu 70 / 80 Meter führen. Das läuft dann immernoch sehr stabil und zuverlässig.

[beta4881]

Ringförmig ist eigentlich der falsche Begriff. shaun hat das eigentlich schon ganz gut beschrieben: Alle Slaves hängen elektrisch gesehen parallel am Bus. Praktisch sieht das nur so aus, dass an jedem Teilnehmer parallelverdrahtete RJ45-Buchsen sind. Über eine Buchse "kommt der Bus", über die zweite Buchse geht der Bus "wieder raus". Zusätzlich wird eben im Inneren der Bus für den Mikrocontroller abgegriffe. Wenn man sich das anschaut, sieht das aus wie ein Ring, ist aber im Sinne von Token Ring keiner.

Anvisierte Lösung: Alle Slaves mit max489 ausstatten. Bei denen kann man die tx Leitungen (die wie oben beschrieben) immer irgend einen Pegel haben, hochohmig schalten (disable). Dann dürfte es gehen.

[pongi]

Wir haben im Betrieb ca. 100 Sensoren die über RS485 verbunden sind, und haben trotzdem keine Probleme. Die Sensoren senden nur dann etwas, wenn sie addressiert werden. Bei uns sieht die Verbindung so aus, dass eine Leitung für RX, eine für TX, und GND von Sensor zu Sensor geführt werden.
Kollision kann ja nur dann auftreten, falls zwei Teilnehmer gleichzeitig senden, wenn man das in der Software ausschliesst, braucht man keine weiteren Massnahmen. Bei uns ist es so gelöst: kein Sensor darf senden, ausser PC. Wenn PC ein ! sendet, warten alle Teilnehmer auf das nächste Byte, was die Adresse ist. 2. B: Adresse 3. B: Befehl. Der Sensor der seine Adresse erkannt hat, kann jetzt den Befehl ausführen, und hat zum sende ein Fenster von 8 Bytes für seine Daten. Er sendet die 8 Bytes (falls die Nutzdaten keine 8B sind, werden noch Paddings hinzugefügt, aber anhand des Befehls ist die Länge der Antwort eindeutig). Damit ist aber die Übertragung nicht abgeschlossen, der PC wartet noch auf ein Abschlusssignal, was ein # ist, erst dann beginnt er mit der nächsten Anfrage. Die Teilnehmer, die nicht adressiert worden sind, hören zu, aber verwerfen die Daten, bis # kommt, und die die Sequenz von neuem anfängt.

[beta4881]

pongi: RS485 ist differentiell ausgeführt auch kann eigentlich nicht aus den Leitungen gnd, tx, rx bestehen. Welche Treiberbausteine benutzt du denn?

Wie sieht es bei allen anderen aus?

[kalledom]

Hallo,
bei mir wird für RS485 der Baustein SN75176 eingesetzt.
Vom µC sind die TTL-Signale Tx und Rx am SN75176 angeschlossen, sowie ein TTL-Signal zum Umschalten von empfangen auf senden, das immer nur so lange aktiv / high ist, wie nach Aufforderung gesendet wird.
Vom Baustein geht über 3 Klemmen ein geschirmtes, verdrilltes Kabel (Telefon-Kabel) mit den Leitungen A und B zu den anderen 'Teilnehmern'.
Tx und Rx gibt es 'außen' nicht mehr als Signal-Namen.