SN65176 RS485-Konkurrenz

Ich übertrage RS485 über:

Mono-Anwendung -> Linux USBTTY-Gerät -> RS485-Adapter mit einem zusätzlichen 100R-Terminator -> ~1m CATV -> SN65176 mit einem zusätzlichen 100R-Terminator -> PIC.

Über das Debugging kann ich sehen, dass die Übertragung von der Anwendung zum PIC erfolgreich ist und die PIC-Übertragung aus der seriellen Schnittstelle ebenfalls in Ordnung ist. Wenn der SN65176 jedoch vom Empfangsmodus in den Antriebsmodus umgeschaltet wird, ist der niedrige Ausgangspegel sehr verrauscht (siehe Oszilloskoperfassung):

Scope-Bild von RS482-Signalen

In dieser Oszilloskopaufnahme ist Kanal 1 (blau) die Datenseite (R/D) des SN65176, und Kanal 2 (gelb) befindet sich am RS485-Anschluss in der Nähe des PCs.

In diesem speziellen Fall stammte das erste Byte vom PC (00001101) und das zweite Byte vom PIC. Es sollte 00011101 sein, wurde aber als 00000100 empfangen.

Hier ist der relevante Mono/C#-Portcode:

        port = new SerialPort(
            portName: portName,
            baudRate: 115200,
            parity: Parity.None,
            dataBits: 8,
            stopBits: StopBits.One)
        {
            Encoding = ASCIIEncoding.ASCII,
            Handshake = Handshake.RequestToSend,
            DtrEnable = false,
            RtsEnable = false,
            WriteTimeout = 1000 // ms
        };
        port.Open();
// ...
        Port.ReadByte()

Der RS232-zu-485-Adapter ist ein XS201A . Es behauptet, eine ausfallsichere Vorspannung zu haben; direkte Messung unterstützt diese Behauptung jedoch nicht. Vielleicht liegt es daran, dass der Bias nur aktiviert wird, wenn das Gerät eingeschaltet ist, aber ich halte das nicht für besonders ausfallsicher. Es enthält keinen Schaltplan und ist eine versiegelte Einheit, daher ist es schwieriger, das Ding zurückzuentwickeln. Wenn ich jedoch an beiden Enden mit einer externen 100-Ohm-Terminierung betrieben werde, sehe ich die folgenden Spannungen:

Va-Vb = 44mV
Va-gnd = 311mV
Vb-gnd = 267mV

Der XS201A behauptet auch, "Automatic Send Data Control" zu verwenden, um von RTS / DTR / TXD mit Strom versorgt zu werden, und um RTS + CTS und DTR + DSR + CT abzukürzen.

Bei getrenntem SN65176 und etwas unterschiedlicher Vorspannung scheint der XS201A ein undokumentiertes 4-Bit-Leitungslaufwerk zu haben, nach dem der Treiber deaktiviert wird:

Laufwerk-Timeout

Dies zeigt zwei aufeinanderfolgende 0x33 vom PC. Es gibt ein Stopp- und ein Startbit, das beide Bytes umgibt, plus das nachfolgende Laufwerks-Timeout.

Für mich sieht das nach Streit aus. Sind Sie sicher, dass der Sender auf der PC-Seite deaktiviert ist, bevor der PIC mit der Übertragung beginnt? Wie wird das Senderfreigabesignal des PCs gesteuert? Haben Sie sich sowohl die + als auch die - Seite des Busses angesehen und zeigen beide das Problem?
Ich bin ziemlich zuversichtlich, dass die Z-Zustände der PIC-Seite korrekt implementiert sind, aber nicht so zuversichtlich über die PC-Seite. Es ist ein USB-zu-UART-Adapter und dann ein UART-zu-RS485-Adapter. Ich werde meinen Code posten.
Es sieht aus wie eine Baudrate von etwa 125k, aber ich sehe das Stoppbit von der Übertragung des PCs nicht. Es sieht so aus, als würde der PIC übertragen, bevor der PC fertig ist. Aus Ihrem Code geht hervor, dass die Sendeaktivierung des PCs von RTS gesteuert wird, aber ich verstehe, dass es zu einer Latenz kommen kann, bevor RTS abfällt, insbesondere über USB.
Eine Sache, die helfen könnte: Normalerweise lege ich Vorspannungswiderstände auf den Bus, so dass ein Bus mit drei Zuständen eine Spannung von etwa 300 Millivolt unter der Mittellinie hat (etwa 2,2 V bei einem 5-V-Bus). Auf diese Weise ist es auf einem Oszilloskop ersichtlich, wenn der Bus nicht gefahren wird. Anscheinend wird Ihr Bus immer gefahren, weshalb ich vermute, dass sich die beiden Sender überschneiden.
@Reinderien - Ich stimme Mark (+1) zu, bei diesen Wellenformen ist Ihr Problem ein Streit. Es gibt verschiedene RS-485-Adapter, die zu der von Ihnen geschriebenen Beschreibung passen, aber sie funktionieren nicht alle auf die gleiche Weise, z. B. behaupten einige, die RS-485-Seite "auto-enable" zu haben. Diese benötigen Zeit, nachdem sie die Übertragung beendet haben, um den Betrieb des RS-485-Busses zu beenden. Ich schlage vor, sich nur auf die PC-Übertragung zu konzentrieren (tx 1 Byte, dann 5 Sekunden Pause, Wiederholung) und den Bus während dieser Pausen zu überwachen. Ich vermute, Sie werden feststellen, dass der RS-485-Bus bis zu einer zusätzlichen Zeichenzeit länger als das übertragene Byte selbst aktiv angesteuert wird.
Sam macht einen guten Punkt: Einige RS-232-> RS-485 warten, bis der Sender im Leerlauf ist, bevor sie den Treiber deaktivieren. Es dauert einige Zeit, bis der Leerlauf erkannt wird. Welchen RS-485-Adapter verwendest du? (@SamGibson)
Der Konverter, den ich verwende, ist dieser. usconverters.com/rs232-rs485-converter-xs201a
@Mark das voreingenommene Netzwerk ist eine gute Idee, aber in der Praxis schwierig. Es ist ein differenzielles Paar, das eine bestimmte Abschlussimpedanz erfordert, und daher wäre die Vorspannungstopologie nicht nur ein einzelner Abschlusswiderstand.
Vielleicht die Thevenin-Voreingenommenheit, die in goo.gl/images/yY5BjW gezeigt wird
Ein Beispiel dafür, wie ich kündige, sehen Sie sich Abbildung 10 auf der letzten Seite dieses Dokuments an: usconverters.com/downloads/support/10waysrs485.pdf
@Reinderien - Mark hat schon viele gute Ratschläge gegeben. Ich füge nur meine 0,02 US-Dollar hinzu: "Das Vorspannungsnetzwerk ist [...] in der Praxis schwierig. Es ist ein Differenzpaar, das eine bestimmte Abschlussimpedanz erfordert [...]", imho für vorübergehende Testzwecke, ist Ihnen egal über die Kündigung so viel. Sie müssen nur die +/- Leitungen vorspannen, damit Sie auf dem Oszilloskop sehen können, wann sie aktiv vom PC angesteuert werden, oder nur die Vorspannung von den Widerständen. Führen Sie dann den von mir vorgeschlagenen Nur-PC-Test durch, um zu sehen, wie schnell der PC aufhört, aktiv den Bus zu fahren, um den Fokus auf die PC-Hardware zu bestätigen.
Wenn Sie sich Ihren Link zum RS232-RS485-Konverter ansehen, fallen zwei Punkte auf (obwohl kein Schema zur weiteren Analyse angegeben ist). Sie sagen, dass es "ausfallsichere Vorspannungswiderstände" hat, die sich auf die Entscheidungen über die Vorspannung auswirken und es im Bereich offensichtlich machen können. Noch wichtiger ist, dass sie meinen Verdacht bestätigen - es hat "Automatic Send Data Control" - Bingo! Das Datenblatt zeigt, dass das RTS-Signal nicht zur Richtungssteuerung verwendet wird, sondern nur für parasitäre Stromversorgung vom RS232-Port. Bitte fügen Sie eine Verzögerung von 1 s nach Tx vom PC hinzu, bevor der PIC versucht, Tx zu senden, wiederholen Sie Ihren ursprünglichen Test und melden Sie sich zurück.
@Mark, dieser "10-Punkte"-Artikel ist wirklich großartig. Im Gegenzug bezieht es sich speziell auf AN-847 über differentielle Vorspannung, die ich gerade lese.
@Reinderien - Danke für die Testergebnisse in Ihren letzten Updates. Das bestätigt den unbeabsichtigten Streit im Bus. Ich habe eine Antwort verfasst, um meine Ansichten zusammenzufassen und mit einem anderen EE.SE-Thema verknüpft, das sehr relevant ist. Kudos an Mark für seine früheren Kommentare :-)
Meine neuen RS485-Probleme sind hier: electronic.stackexchange.com/questions/246097/…

Antworten (1)

Um die Diskussion zusammenzufassen und auf Ihre Testergebnisse zu antworten:

Es scheint, dass der XS201A ein undokumentiertes 4-Bit-Zeilenlaufwerk hat, nach dem der Treiber deaktiviert wird

Einverstanden, dieses Verhalten passt zu dem, was ich zuvor bei einigen Konvertern gesehen habe, und danke, dass Sie den Test durchgeführt haben.

Es ist wahrscheinlich eher eine relativ feste Zeit , während der die Leitung nach der Übertragung durch diesen RS232-RS485-Konverter aktiv angesteuert wird, als eine konstante Anzahl von Bitzeiten unabhängig von der Bitrate. Sie könnten die Bitrate erheblich ändern und erneut testen, um zu bestätigen, dass die "leitungsgesteuerte Zeit nach dem Senden" immer noch ähnlich wie die aktuellen ~ 35 us bleibt. Möglicherweise stellen Sie auch fest, dass diese "leitungsgesteuerte Zeit nach dem Senden" je nach gesendetem Datenbyte variiert. Daher schlage ich weitere Tests mit unterschiedlichen Bytes vor, um dies zu überprüfen.

Dies war ein weiteres aktuelles Thema hier auf EE.SE (Wie funktioniert dieses RS485-Modul?) , wo ein Teilschema die Art der Schaltung zeigt, die verwendet werden kann, um das "automatische" Umschalten zwischen Senden und Empfangen auf RS-485 bereitzustellen. Diese schalten jedoch nicht sofort um, wenn eine Übertragung beendet ist, was zu dem Verhalten führt, das Sie beobachtet haben.

Aus meiner Sicht sind einige Optionen:

  • Fügen Sie gegebenenfalls Verzögerungen in Ihrem Code hinzu, um das Verhalten dieses Konverters zu berücksichtigen (aber Sie müssen zuerst testen und versuchen, die maximale "leitungsgesteuerte Zeit nach dem Senden" zu finden), oder ;
  • Verwenden Sie einen anderen RS232-RS485-Konverter, der die RTS-Leitung verwendet, um tatsächlich zwischen Tx und Rx umzuschalten. Sie müssen jedoch überprüfen, ob sich das RTS-Signal zum richtigen Zeitpunkt und nicht zu früh ändert (was das Senden unterbrechen könnte). Eine kleine "Durchlaufzeit" kann dennoch erforderlich sein, insbesondere wenn der Abstand (dh die Kabelkapazität) zwischen den Geräten groß ist.

Möglicherweise möchten Sie nach Begriffen wie „RS-485-Turnaround-Verzögerung“ oder „RS-485-Auto-Turnaround“ suchen, um weitere Informationen und Erfahrungen beim Zeitmultiplexen mehrerer Sender auf Halbduplex-RS-485-Bussen zu erhalten.

Ich hatte bereits begonnen, die Verzögerung zu codieren, bevor Sie es vorgeschlagen haben, und tatsächlich hat das den Streit gelöst, der wie Rauschen aussah. Die eingehenden und ausgehenden Signale sehen jetzt recht sauber aus... Leider sind die eingehenden Daten aus irgendeinem Grund immer noch völlig falsch. Dafür starte ich eine neue Frage.
SN65176 RS485-Konkurrenz
AntwortenHierDatenschutz-Bestimmungen1y, 0v