Hallo Leute! Ich habe versucht einen RS232<->RS485 Konverter zu entwerfen. Ich bitte mal darum die Schaltung im Anhang zu prüfen und mir zu sagen, ob das so richtig ist oder ob ich irgendwo einen Fehler mache. Vielen Dank für die Mühe, sascha
Angehängte Dateien:
-
Unbenannt-1.gif
9,8 KB
Sind C8 und C9 richtig herum? (Hab das Datenblatt gerade nicht zur Hand). Dem Richtungssteuerpin des MAX485 könntest du noch einen Pull-down Widerstand spendieren.
jo... C8 und C9 stimmen so. Da Stecken dann die -12V bzw. +12V drin. Welchen Zweck würde der Pull-Down erfüllen?
>Welchen Zweck würde der Pull-Down erfüllen? Der MAX485 würde nicht ungewollt ins Netz senden. Bietet sich dann an, wenn der steuernde Portpin auch hochohmig werden kann. (Ist nur ein Vorschlag)
>Bietet sich dann an, wenn der steuernde Portpin auch hochohmig werden >kann. Aber kann er doch nicht, oder? Also der Ausgang vom Max232 ist doch immer H oder L. Oder nicht?
Pin 2 und 3 vom Max 485 gehören gebrückt. Masse weg. SG Josef
@Josef Danke... das leuchtet natürlich ein. Darum ist einer auch invertiert.
>Pin 2 und 3 vom Max 485 gehören gebrückt. Masse weg.
Jein.
Wenn man die Daten empfangen will, die man sendet/gesendet hat, dann
kann man den RE-Pin (oder war es der andere?) auch konstant grounden.
Naja... das will ich ja net unbedingt. Das hätte ich dann in der Software "weggeschmissen".
Ist interessant, wenn man auch Kollisionen auch erkennen kann. Dafür ist der MAX485 aber zu niederohmig.
Die Software dazu ist interessanter. Ich habe festgestellt, daß unter Windows die Richtungssteuerung sehr träge ist. Wenn der PC ein Datenpaket sendet und der andere Teilnehmer (z.B. eine uC-Schaltung) sehr kurz danach seinerseits antwortet, hat der PC evt. noch nicht auf Empfang geschaltet. Da muß man sein Augenmerk drauf richten. Besser geht das mit einem USB-RS232-Chip mit Richtungssteuer-Ausgang (z.B. FTDI). Oder man macht die Richtungssteuerung in Hardware mit einer Art Monoflop, mit einem Timeout von etwas mehr als einer Zeichenlänge (dann muß man aber je nach Baudrate das Monoflop umschalten).
Danke für den Tip, aber da der Hersteller der Slaves auch einen solchen (teuren) RS232<->RS485 Wandler anbietet ist davon auszugehen, dass die Slaves sich ein wenig Zeit lassen, bis sie antworten.
@ günter.... das ist doch unsinn.... träge richtungssteuerung unter windows ??? dietmar
@dietmar: Nun, man muß natürlich die Programmierumgebung bzw. verwendete Sprache dazu betrachten. Ich verwende Delphi 5 (Object Pascal) und die Serial-Komponente CPORT von Dejan Crnila. Bei einem Programm-Projekt wollte ich RS485-Betrieb realisieren und habe es relativ primitiv so programmiert, daß ich RTS aktivierte, dann den String sendete und danach RTS wieder inaktivierte. Was ich zunächst nicht bedachte, war, daß Windows solche übergebenen Daten ja mehrfach puffert und sie irgendwann an den Hardware-Treiber weitergibt, der die Zeichen dann rausbringt. Wie dazu aber das Setzen/Löschen von RTS korreliert, kann man u.U. schlecht abschätzen; jedenfalls war das Ergebnis, das ich erzielte, dermaßen schlecht, daß ich mir abgeschminkt habe, mit solch einfachen Mitteln einen RS485-Betrieb zu programmieren. Mit Turbo-Async mag's besser gehen, das habe ich nicht getestet. Ich habe mir dann ein RS232-RS485-Interface mit Timeout-Monoflop selbstgebaut, damit funktioniert es perfekt, aber die Senderaktivierung wird damit ja in Hardware (und unabhängig von Windows) durchgeführt; das Programm weiß garnicht, daß RS485 stattfindet. Kleiner Nachteil meines Interfaces: ich muß die Baudrate dort einstellen. Praktisch alle käuflichen Interfaces sind so aufgebaut, wie Sascha es gemacht hat, und die geben zwar damit an, sie seien baudratenunabhängig, aber sie haben halt alle den Nachteil, daß die RS485-Funktion davon abhängig ist, daß der UART bzw. das dahinter hängende Programm die Richtungssteuerung richtig bewerkstelligt. Man sollte somit (ggf. mittels Oszilloskop) mal danach schauen, wann vor dem Beginn des Datenpakets der Bus belegt wird, und wie schnell nach dem Ende des Datenpakets er wieder frei wird, sodaß andere Teilnehmer gleich danach senden können. Da kann man Überraschungen erleben ...
@Günter R. >es relativ primitiv so programmiert, daß ich RTS aktivierte, dann den >String sendete und danach RTS wieder inaktivierte. Was ich zunächst >nicht bedachte, war, daß Windows solche übergebenen Daten ja mehrfach >puffert und sie irgendwann an den Hardware-Treiber weitergibt, der die >Zeichen dann rausbringt. Wie dazu aber das Setzen/Löschen von RTS >korreliert, kann man u.U. schlecht abschätzen; jedenfalls war das Nun, dazu braucht man halt nen Kernel Driver. Nicht ganz trivial. Ich hab das vor längerer Zeit auch einfach per Hardware gelöst (AVR als Busmaster). MFG Falk
@ Günter Deine Sache mit dem Timeout-Monoflop interessiert mich sehr, da ich ein ähnliches Problem lösen will. Dabei geht es allerdings nicht um RS485, sondern um eine etwas spezielle Halbduplex-Kommunikation (proprietär; tut hier nichts zur Sache), wo ich ebenfalls mit RTS die Übertragungsrichtung setze. Der Sender muss vor dem Senden des ersten Bytes aktiviert werden und muss es bleiben, bis das letzte Byte gesendet wurde (dies ist übrigens ohnehin etwas knifflig, da der UART einem nicht mitteilt, wann ein Byte wirklich bis zum letzten Stopbit gesendet worden ist). Die Beobachtung, dass unter Windows das Setzen von Handshake-Leitungen nicht zuverlässig mit dem Timing des Datenstroms synchronisiert ist, habe ich auch machen müssen. So will ich etwas realisieren, das unabhängig vom RTS funktioniert, wobei in meinem Fall die Baudrate fix ist. Jedenfalls, da ich das RTS sicher VOR dem ersten Byte setzen muss, und auch die Elektronik nicht in die Zukunft sehen kann, ist mein Lösungsansatz wie folgt: Einen PIC in die Sendeleitung schalten, wenn der ein Byte empfängt, das Byte puffern, Sender einschalten, Byte senden, und natürlich in der Zwischenzeit weitere Bytes empfangen. Am Schluss nach einem Timeout in der Länge eines Bytes den Sender wieder ausschalten. Wenn es Dir nichts ausmacht, würdest Du Deine Monoflop-Lösung posten? Vielen Dank Severino
Das Problem das Günther beschreibt, ist genau mit diesem Pull-Down widerstand zu lösen da der Max485 sehr träge umschaltet sofern man den Driver-Enable nicht über einen Widerstand runter auf Masse zieht. Schaltpläne für solche Wandler gibts auf meiner HP: http://www.rs485-hausbus.de.vu Gruss Jochen_str
@jochen_str >Das Problem das Günther beschreibt, ist genau mit diesem Pull-Down >widerstand zu lösen da der Max485 sehr träge umschaltet sofern man den >Driver-Enable nicht über einen Widerstand runter auf Masse zieht. Das wage ich zu bezweifeln. Der MAX schaltet schon sehr schnell (ein paar dutzend Nanosekunden) um, man muss aber schon den Steuereingang (Driver enable) auch mit einem Logikausgang schalten, und nicht in der Luft hängen lassen. Ausserdem sprach Günther doch wohl eher von Softwareproblemen (schlecht definiertes Timing bei Zugriff von Userprogrammen auf RS232 Port). MfG Falk
Also wenn ich euch und eure teils kontroversen Meinungen richtig verstehe, dann sollte meine Schaltung prinzipiell funktionieren. Wenn beim Schnittstellen-Zugriff über die Windows API Timing-Probleme auftauchene, dann muss ich mir eben doch die "Last" eines Kernel-Mode-Treibers aufladen.
Also ich verwende für eine Pc seitige Steuerung auch das RTS-Signal, welches ich über Visual Basic (welches nicht direkt auf die Kernal zugreift, sondern ein Basic-Modul das übernimmt) die Zwei Steuereingänge des MAX485 sind zusammengeschaltet und laufen auf den MAX232 der das RTS signal umsetzt, von +-12v auf 5 bzw 0 v und dann braucht man denoch einen R der mir den DE auf masse zieht weil er sonst nicht gescheit umschaltet. Wenn man einen Avr zum schalten nimmt ist das genauso. Mit dem Widerstand schaltet der sofort um. Mir ist noch nie die "Antwort" eines Busteilnehmers entgangen der antwortet nach wenigen ms. gruss Jochen Rs485-hausbus.de.vu
@Sascha >Also wenn ich euch und eure teils kontroversen Meinungen richtig >verstehe, dann sollte meine Schaltung prinzipiell funktionieren. Wenn Ja. >beim Schnittstellen-Zugriff über die Windows API Timing-Probleme >auftauchene, dann muss ich mir eben doch die "Last" eines >Kernel-Mode-Treibers aufladen. Ja. @Jochen S. >signal umsetzt, von +-12v auf 5 bzw 0 v und dann braucht man denoch >einen R der mir den DE auf masse zieht weil er sonst nicht gescheit >umschaltet. Wenn man einen Avr zum schalten nimmt ist das genauso. Du sprichst in Rätseln. Wozu soll ich an DE nochmal nen Pull-down dranmachen, wenn DE und RE verbunden sind und von einem ordentlichen Digitalausgang (vom MAX232) gesteuert werden? >Mir ist noch nie die "Antwort" eines Busteilnehmers entgangen der >antwortet nach wenigen ms. Das sind ja auch Ewigkeiten. Auf nem AVR bzw. mittels Kernal Driver kann man wenige Microsekunden nachdem das letzte Byte gesendet wurde den Treiber abschalten. MFG Falk
@ Falk: Um ehrlich zu sein am Anfang habe ich mir das auch gedacht, musste dann aber feststellen es ging nicht. Dann habe ich rumexperimentiert und habe zur Kontrolle eine LED zwischen DE und GND geschaltet und siehe da schon lief die Musik, da der DE über die LED auf Masse ging: LED weg Problem wieder da. Ich dachte auch immer das mir der MAX232 eine saubere Null liefern würde aber habe das Gefühl er lässt den Ausgang einfach in der Luft hängen.
@Jochen S. >Masse ging: LED weg Problem wieder da. Ich dachte auch immer das mir der >MAX232 eine saubere Null liefern würde aber habe das Gefühl er lässt den >Ausgang einfach in der Luft hängen. Welcher Ausgang? MAX defekt? Die Ausgänge vom TTL MAX232 sind keine Open Drain (und gerader der müsste ein sauberes LOW liefern). Ich tippe auf defekten IC oder Verdrahtung. MfG Falk
@Falk: Das sehe ich genauso. Der MAX232 hat Push-Pull-Ausgang, der zu jedem Logikpegel sauber und schnell durchschaltet. @Severino: Klar kann ich meine Monoflop-Lösung hier posten, nur nicht sofort, da ich die Schaltung nur als Schmierzettel-Handskizze habe (und sie davon auf ein Veroboard verdrahtet habe), die ist z.Zt. nicht reprofähig. Ich werde sie mit Tippex etwas verschönern und dann scannen und stelle sie dann hier rein. Aber die Schaltung ist sehr einfach: nach üblicher Manier sind ein MAX232 und ein MAX487CPA miteinander verbunden (Pin 11 des MAX232 mit Pin 1 des MAX487, dazu ein Pullup von 10k, sowie Pin 12 des MAX232 mit Pin 4 des MAX487), RE und DE verbunden = Pins 2 und 3, nur eben diese nicht an RTS gelegt, sondern mit dem Ausgang eines Monoflops CD4528 verbunden (Q-Ausgang, Pin 10). Der A-Eingang (Pin 12) liegt an GND, der B-Eingang (Pin 11) ist mit dem Receive-Ausgang des MAX232 (Pin 12) verbunden. Das ist schon der ganze Witz. Die kleine Schwierigkeit liegt in der Timeout-Zeit des Monoflops; hier habe ich ein 4-poliges Mäuseklavier (für 4 einstellbare Baudraten 9600, 38400, 57600 und 115200 bps) zum Umschalten; dieses schaltet RC-Kombinationen an den CD4528; der Widerstand ist immer ein Fest-R mit 3.3k und ein Poti mit 10k in Serie und wechselnde Kondensatoren (also insgesamt 4 * 3.3k und 4 * 10k-Poti und 4 Kondensatoren): 9600 bps: C = 470 nF Timeout 1,56 ms Bit-Zeit 104,16 us 38400 bps: C = 150 nF Timeout 390 us Bit-Zeit 26,05 us 57600 bps: C = 100 nF Timeout 260 us Bit-Zeit 17,37 us 115200 bps: C = 33 nF Timeout 130 us Bit-Zeit 8,68 us Beim Protokoll 8-E-1 hat ein Zeichen 11 Bits, ich habe mich für eine Timeoutzeit von 15 Bitzeiten entschieden (könnte man noch etwas kleiner machen, aber: Temperaturdrift u.ä. beachten, besser ein wenig Toleranz lassen). Den Poti-Abgleich für jede Baudrate macht man mit dem Oszilloskop; den Mono mit einer Rechteck niedriger Frequenz triggern und die Eigenzeit auf die genannten Timeouts einstellen. So müßte es gelingen. Schaltung folgt irgendwann (aber nach der Beschreibung kannst Du's ja eigentlich aufbauen). Günter
Das ist doch eine verfeinerte Version aus einer alten elektor, da war das genauso, ich konnte mir nur nie vorstellen, dass das läuft hatte immer Angst das erste bit geht verloren, da der MAx485 oder welcher auch immer erst auf senden schaltet wenn das erste bit kommt. Muss hier im Protokoll was geändert werden so erst eine bit schicken zum umschalten dann eigentliche Nachricht oder klappt das so??
@ Günter Vielen Dank für die Beschreibung. Alles klar, Du brauchst für mich kein Schema zu posten. Ich schaue jetzt mal, ob sich das für meine Zwecke verwenden lässt. Nochmals besten Dank Severino
@Jochen: Das klappt schon; der Treiber wird ja innerhalb von Nanosekunden eingeschaltet, da fängt das Startbit ja gerade erst an; am Protokoll muß man nichts ändern. Interessant, daß es dies im Elektor gab; ich habe den Elektor, habe mir die o.g. Schaltung aber selbst zusammengezimmert; sie ist ja auch relativ trivial, da braucht's nicht viel.
@Severino: Hab' meine Handskizze jetzt doch mal gescannt; sieht gekritzelt aus (ist sie ja auch), aber ich denke, man erkennt, wie die Schaltung aufgebaut ist.
Angehängte Dateien:
-
oszi.png
2,5 KB
Zwar ist der Thread schon etwas betagt, aber ich hoffe, das macht nichts. Ich habe den monoflop-basierten RS232-RS485 Wandler laut Schaltung von Günter R. (in diesem Diskussionsfaden zu finden) nachgebaut. Mein Timing-Kondensator ist jedoch 1000 nF (Tantal), da ich primär niedrige Baudraten benötige. Das Problem sieht man im Anhang: Ähnlich wie schon von Jochen S. befürchtet, geht mir bereits bei 2400 Baud ungefähr das halbe Startbit verloren. An 9600 ist da gar nicht mehr zu denken. (gelb: RS232-TX nach Pegelwandler am DI Pin des MAX485, grün: RE/DE-Signal) Ist eine solche Verzögerung beim Triggern des Monoflop (MC14528BCP) normal? Oder sind die 1uF-Kondensatoren schuld?
@Sebastian E. (der_andere_sebastian) >Das Problem sieht man im Anhang: Ähnlich wie schon von Jochen S. >befürchtet, geht mir bereits bei 2400 Baud ungefähr das halbe Startbit >verloren. >An 9600 ist da gar nicht mehr zu denken. Da ist was faul. >Ist eine solche Verzögerung beim Triggern des Monoflop (MC14528BCP) >normal? Oder sind die 1uF-Kondensatoren schuld? Wahrscheinlich. Mach mal lieber 10 nF (NANO) und dafür den Widerstnad um den Faktor 100 grösser. MFG Falk
Danke für den Tip. Die Richtung stimmt, schon mit 47nF ist das Problem praktisch gelöst. Leider sind mir eben nacheinander schon vier SP232 kaputt gegangen, aber ich glaube nicht, daß der Kondenastor daran schuld ist. Vermute eher Latch-Up beim Einschalten oder so etwas.
Angehängte Dateien:
-
oszi.png
4 KB
Nachtrag: Alles ok, das angehängte Bild zeigt nun das Signal bei 2400 Baud, Verzögerungszeit des MF nach Augenmaß abgeglichen. Da die Flanken am Anfang der Signale jetzt praktisch zusammenfallen, sollte auch ein Betrieb bei höheren Baudraten möglich sein. Offensichtlich war der Tantalkondensator zu hochohmig, oder 1uF eben einfach zu viel. Nebenbei gesagt habe ich jetzt einen MAX202 eingesetzt. Der scheint unempfindlicher zu sein. Vielen Dank nochmal für die schnelle Hilfe.
Sebastian E. wrote: > Das Problem sieht man im Anhang: Ähnlich wie schon von Jochen S. > befürchtet, geht mir bereits bei 2400 Baud ungefähr das halbe Startbit > verloren. > An 9600 ist da gar nicht mehr zu denken. Hast Du beachtet, daß meine Schaltung baudraten-abhängig ist und man für jede Baudrate einen genau abgestimmten Kondensator und die Trimmereinstellung benötigt? Deswegen gibt es ja den DIP-Schalter, mit dem man 4 verschiedene Baudraten auswählen kann. Diese Schaltung funktioniert bestens, ist aber unkomfortabel, weil man ggf. die Baudrate umstellen muß; läßt sich aber nicht (!) vermeiden. Eine bessere Lösung für PC-Anwendungen ist ein USB/RS485-Wandler mit einem FT232RL; dieser hat einen RS485-TxE-Ausgang, mit dem der Treiber gesteuert werden kann. Aber an diesem Chip wird die Baudrate letztlich (über den UART) auch eingestellt. Meine Schaltung brauchte ich als Nachsetzer für ein Nicht-PC-Gerät, bei dem keine Eingriffe möglich waren.
@Günter R. (galileo14) >jede Baudrate einen genau abgestimmten Kondensator und die >Trimmereinstellung benötigt? Schon klar, es geht aber um die Verzögerung des Monoflopausgangs, NICHT die Pulsbreite. Und mehr als 100us sind da viel zu viel. MFg Falk P.S. Das mit dem Trimmer ist überflüssig. Es reicht praktisch, wenn die Pulszeit vom Monoflop ca. 15 Bitzeiten lang ist +/- 20%. Mit 1% Metallfilmwiderständen und 10% Folien/Keramik-kondensatoren schaft man das problemlos. Beitrag "Re: RS-485 erweitern"
Ja, klar. Deswegen habe ich auch dieses Konzept übernommen, jedoch nur mit einem Jumper zum Umstecken und 2 R/C-Kombinationen. Ich brauche bestenfalls 1200 und 2400 Baud. Ich wußte ja gar nicht, daß der FT232RL einen passenden Steuerausgang hat. Und der muß nicht extra per Software gesteuert werden? Das wäre langfristig eine Lösung für mich, da ich auf dem PC eine fertige MODBUS-Master-Software benutze, die die RTS-Leitung nicht steuert. Danke übrigens für die Schaltung! Um auch etwas beizutragen, würde ich auf Wunsch die Eagle-Dateien dazu einstellen. Allerdings braucht mein Layout vier Drahtbrücken.
@ Sebastian E. (der_andere_sebastian) >Ich wußte ja gar nicht, daß der FT232RL einen passenden Steuerausgang >hat. Hat er, sogar standardmässig aktiviert. > Und der muß nicht extra per Software gesteuert werden? Nein. >Danke übrigens für die Schaltung! Um auch etwas beizutragen, würde ich >auf Wunsch die Eagle-Dateien dazu einstellen. Tu das. > Allerdings braucht mein Layout vier Drahtbrücken. Werden wir verschmerrzen können ;-) MFG Falk
Bitteschön. Die vier Leitungen im Top-Layer können natürlich als Drahtbrücken ausgeführt werden. Bohrerdurchmesser 0,6 für normale Bauteile empfohlen, 0,8 für Jumper und 0,95 für die Wago-Federkraftklemme. Sicherlich kann man das Layout noch wesentlich verbessern. Aber für eine kleine Testschaltung reicht es.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.