Ich habe Probleme mit der Kommunikation an einem RS485 Bus. Der Aufbau besteht aus zwei Komponenten, welche grundsätzlich funktionieren. TC Komponente A (Komponente-A_ADM3072EARZ.JPG): 485-TC ADM3072EARZ (3.3V) Fixer Abschlusswiderstand 120 Ohm /RE und DE werden gleichzeitig von RTS angesteuert, per Default auf Empfang (RTS=0). TC Komponente B (Komponente-B_ADM4852ACPZ.JPG): 485-TC ADM4852ACPZ (5V) Abschlusswiderstand 120 Ohm per Jumper einschaltbar /RE und DE werden gleichzeitig durch retriggerbares Monoflop angesteuert, per Default auf Empfang. (Triggerung durch TX-Signal mit Impulsdauer tw = 330 us) Kommunikationskanal: ca. 50 cm Twisted Pair Kabel ohne Schirm Nun zu meinem eigentlichen Problem: Wenn der Abschlusswiderstand an Komponente B aktiviert ist, hat die Kommunikation Probleme. Sobald der Widerstand entfernt ist, funktioniert die Kommunikation. Gemäss Empfehlung sollen beide Enden mit 120 Ohm abgeschlossen werden, damit die Impedanz angepasst ist. Durch Messen mit dem KO habe ich festgestellt, dass nach dem Umschalten von Senden auf Empfangen am TC von Komponente A ein nicht gewollter Impuls entsteht. Siehe Bild RS485_mit-Abschlusswid.png CH1 gelb RS485 mit diffential probe CH2 grün RO Komponente A CH3 blau DI Komponente A CH4 rot /RE, DE Komponente A Meine Begründung: RTS wechselt den Kanal von Senden auf Empfangen (/RE, DE low), nachdem das letzte Byte gesendet wurde. Zu dieser Zeit ist der Buspegel noch auf high, bevor die RS485-Seite hochimpedant wird und gegen 0V fällt. Womöglich interpretiert der TC diesen Pegel bereits als Empfangssignal und setzt RO nach der Laufzeitverzögerung auf low. Sobald ich den Abschlusswiderstand entferne, ist die Flankensteilheit deutlich geringer. Siehe Bild RS485_ohne-Abschlusswid.png. Das Signal auf dem Bus wird als high erkannt und es entsteht kein ungewollter Impuls. Da die Ansteuerung von /RE und DE durch RTS empfohlen wird, gehe ich davon aus, dass ich nicht der einzige bin mit dem erwähnten Problem. Wird dies hauptsächlich in der SW gefiltert oder gibt es hierfür eine elegante Hardware Lösung?
Angehängte Dateien:
-
Komponente-A_ADM3072EARZ.PNG
12 KB -
Komponente-B_ADM4852ACPZ.PNG
22 KB -
RS485_mit-Abschlusswid.png
9,6 KB -
RS485_ohne-Abschlusswid.png
9,4 KB
Versuch mal auf einer Seite die RS485 so vorzuspannen, dass definierte Pegel an den Eingängen liegen. https://www.mikrocontroller.net/articles/RS-485 Die 390Ohm sind mir etwas zu niedrig. Ich nehme immer 750.
Die beiden TC besitzen True fail-safe, welche meiner Meinung nach keine zusätzlichen Bias-Widerstände benötigen. Auszug Datenblatt ADM3072: "The receiver inputs have a true fail-safe feature, which eliminates the need for external bias resistors and ensures a logic high output level when the inputs are open or shorted." Auszug Datenblatt ADM4852: "The receiver inputs have a true fail-safe feature, which ensures a logic high output level when the inputs are open or shorted. This guarantees that the receiver outputs are in a known state before communication begins and when communication ends."
Die Frage ist wie dieses integrierte fail-save Handling implementiert ist. Gerade auch im Umschaltmoment. Ich würde die 10s opfern und mal probehalber die 2 Widerstände anlöten. Wenn es hilft kannst du dich immer noch entscheiden ob du das Problem damit löst oder per Software.
Ich bin z.B. dazu übergegangen den Empfänger immer an zu lassen. Damit liest man zwar seine eigenen gesendeten Daten selbst mit ein, hat aber den Vorteil Kurzschlüsse oder Kollisionen frühzeitig erkennen zu können.
Michael schrieb: > which ensures > a logic high output level when the inputs are open or shorted Die sind aber mit dem Bus verbunden und sind weder open noch shorted. Das funktioniert ja vielleicht wenn man den Stecker zieht. Georg
Lange her, wenn ich mich richtig erinnere, habe ich das damals so gemacht, wie ein Kollege schon geschrieben hat. Empfänger immer an. Sender war so geschaltet, das ich mit dem TX die Sender Freigabe geschaltet habe, (Inverter nötig), und das Ausgangssignal wurde festverdrahtet. Zu dem haben ich immer einen Pull-Up und einen Pulldown pro Segment installiert. Bei den Werten bin ich mir aber nicht mehr sicher.
@temp: Ich habe die Bias-Widerstände bestückt, jedoch keine Verbesserung festgestellt. @Georg: Durch die Beschaltung an /RE und DE = low wird die Impedanz am TC hochohmig. Durch den integrierten fail-safe mode gehe ich davon aus, dass es keinen offenen Pegel gibt. Die Pegel am RS485-Bus sind i.O, Upp ca. 5V. Ansonsten könnte die UART-Seite die Daten nicht korrekt interpretieren. Im Bild "RS485_mit-Abschlusswid.png" ist die abfallende Flanke wie erwartet relativ steil (100 ns/Div). Der TC interpretiert nach dem Umschalten auf Empfangen den Buspegel, welcher ca. 100 ns später auf 0V ist. Ideal wäre, wenn der Bus vorgängig hochimpedant wird (DI=low) und kurz später die Daten am Bus interpretiert werden (/RE = low). Leider habe ich nur eine RTS-Leitung zur Verfügung zum ansteuern der beiden Steuereingänge.
Michael schrieb: > Ideal wäre, wenn der Bus vorgängig hochimpedant wird (DI=low) und > kurz später die Daten am Bus interpretiert werden (/RE = low) Ist wohl so. Michael schrieb: > Leider > habe ich nur eine RTS-Leitung zur Verfügung zum ansteuern der beiden > Steuereingänge. Monoflop? Ev. kann man ja auch den UART Receiver verzögert enablen. Georg
Das Problem besteht ewt. Darin das beim disable vom RX/TX der Port hochohmig wird. Bei AVRs wird der Port wieder freigeben. Wenn der Pullup nicht aktiviert ist hängt alles in der Luft.
Angehängte Dateien:
Für mich ist das Verhalten immer noch unerklärlich, da dies eine Standardkonfiguration ist und bestimmt mehrere davon betroffen sein müssten. Womöglich wird der sehr kurze Impuls von anderen uC nicht erkannt und führt daher auch nicht zu fehlerhaften Datenpakete. Ich habe den /RE Eingang mittels RC-Glied (tau = 1 us) verzögert. Eleganter wäre natürlich ein zusätzlicher Schmitt-Trigger nach dem RC-Glied. Ich gehe jedoch davon aus, dass der Eingang vom TC einen solchen integriert hat. Möglicherweise verfolgen wir einen redundanten Lösungsansatz (HW und SW). Besten Dank für die Diskussion.
Michael schrieb: > Für mich ist das Verhalten immer noch unerklärlich, da dies eine > Standardkonfiguration ist und bestimmt mehrere davon betroffen sein > müssten. Womöglich wird der sehr kurze Impuls von anderen uC nicht > erkannt und führt daher auch nicht zu fehlerhaften Datenpakete. Es betrifft ja nur die Seite die gerade gesendet hat und jetzt lesen soll. Auf der RS485 Seite ist alles clean. Entweder man lässt den Empfänger an und liest die gesendeten Daten mit, dann gibt es dein Problem nicht. Oder man sendet, schaltet um, wartet ein paar Takte, löscht den eventuellen Müll im RX Buffer und akzeptiert erst danach die einlaufenden Daten. Dann kannst du dir das RC-Glied auch sparen. Jedes Gerät welches über RS485 Requests detektiert wartet ohnehin eine gewisse Zeit bevor es die Antwort sendet. Auf jeden Fall länger als dein kurzer Impuls dauert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.