Forum: Mikrocontroller und Digitale Elektronik Schnittstellenumschaltung RS485 (automatisch)


von Schorse Kahl (Gast)


Lesenswert?

Hallo
habe da ein kleines Problem wozu es sozusagen professioneller Hilfe 
bedarf.
Mein Atmel ist per RS485-Bus (Halbduplex, 19200Bd.) in meinen SPS 
eingebunden. Den Schnittstellenkonverter kann ich nicht mit dem 
"berühmten" RTS-Signal von Softwareseite (RS232) umschalten - vom 
Prinzip her lässt die angewandte Master-Slave Kommunikation das nicht 
zu.
Der verwendete Adapter (Eigennachbau) funktioniert bei RS232 (ca. 
genormte + /-12V Pegel) wunderbar, auf TTL Pegel umgespeckt hingegen 
schon schlechter. Aber würde gehen.
Nun kommts - baue ich den Adapter isoliert (per Optokoppler) aus 
Einzelteilen auf gehts auch noch mehr als recht zwar aber gerade noch 
brauchbar. Nehme ich hingegen fertig-isolierte Bausteine àlà MAX1490 
denn klemmt die Kiste bei der Umschaltung (1:1 dem mit MAX485 bestückten 
Adaptern nachgebaut).
Egal was probiert es hapert an der Umschaltung - getestet echofreies 
Senden bzw Lesen einzeln gehts, im Wechselsprechverkehr hängts sich auf.

Die Kriterien der Transmitter/Receiverumschaltung der Bausteine sind mir 
aufgrund der letzten Versuche (nahezu) vollständig geläufig - unklar 
hingegen ists warum es mit dem MAX485 "solo" funzt, mit dem selben 
Baustein in der Maxim-fertig-Schaltung vergossen dann aufgibt. Erste 
Überlegung ist das der /(invertierte) Fertigbaustein mit der Umschaltung 
"A und B" umpolt und das nur zu einem definierten Zeitpunkt hinkommt wo 
alle Signale synchron richtig stehen. Dem mehrfach uminvertiert folgte 
jedoch die Umpolung der "A und B" Leitung - es blieb alles gleich nur 
mussten dann "A und B" vertauscht werden damits Sendete/ Empfing.

Zeitglieder eingebaut bringt auch nichts - mit denen funktionierts dann 
schon am einzelnen MAX85 nicht mehr.

Gibts da irgendwo Schaltpläne beziehungsweise IC's welche die 
Richtungserkennung "beherrschen" ?
Vielen Dank
Schorse

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Normal macht die Umschaltung die Software. Beide sind zunächst auf 
Empfang. Der Master sendet an den Slave ein Request Paket, worauf der 
Slave in einer bestimmten Zeit warten muß. Der Slave selbst sendet nur 
auf Anfrage vom Master hin. Der Slave (AVR) könnte somit die Umschaltung 
über Software und einen zusätzlichen Pin bewerkstelligen. Kann die SPS 
selbst für sich umschalten? Wer ist denn jetzt Master und wer Slave?

von Schorse Kahl (Gast)


Lesenswert?

Hallo
der Atmel ist in der Konfiguration qasi "Master" - aber ist vom Prinzip 
her egal. Das Problem liegt das die SPS (S7) keinen "Steuerpin" besitzt 
(am Atmel ginge Softwaretechnisch einen Ausgang mitzuschalten).

Der Adapter muss in zwei Funktionen laufen (als eine Art Weiche). Vom 
Atmel geschaltet von ATMEL zur SPS, und dann alternativ SPS zu SPS. (S7 
zu anderem Fabrikat mit RS232 ). Das funktioniert vollständig nur mit 
automatischer Umschaltung (wie z.Beispiel orginal Simatic Adapter) -

Schorse

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Najaa, dann müßte der ATMEL den Datenverkehr (zur Not über Interruptpin) 
überwachen und "die Weiche" entsprechend umschalten. Über gewisse 
Zeitfenster zwischen den Datenpaketen oder auch einzelnen Bytes kann man 
erreichen, daß nie 2 Transceiver gleichzeitig die Leitung belegen. Wenn 
man steuern kann, daß Slaves nur auf Anfrage antworten und wenn man 
weiß, wer der Master ist, sollte das kein Problem darstellen. Der ATMEL 
lauscht dann die ganze Zeit mit und handelt entsprechend. Prinzipiell 
müßte der ATMEL dann über 2 RS485-Transceiver verfügen, über die er das 
Signal ggf. durchschleifen kann, wenn die beiden SPSse sich unterhalten 
sollen.

von Schorse (Gast)


Lesenswert?

[QUOTE]
Prinzipiell
müßte der ATMEL dann über 2 RS485-Transceiver verfügen, über die er das
Signal ggf. durchschleifen kann, wenn die beiden SPSse sich unterhalten
sollen.
[/QUOTE]
das habe ich im Prinzip so gemacht - der Teil haut hin. Was nicht geht 
ist nur die Rec/Trans-Umschaltung im MAX1490.
Diese Umschaltung - wie sie mit MAX485 funzt - wertet nur das RS232 
(TTL) TxD-Signal aus obwohl der keine Zeichenlänge usw. (mit Parität 
11-BitBytes) berücksichtigt. Frei nach dem Motta wo nicht gesendet wird 
stelle ich auf Empfang.
Sendepause ist dann beim MAX1490 - der schaltet zwar sauber um, kommt 
aber nichts verständliches mehr raus.
Ich würde gerne die fertigen MAX1490 nehmen weil da Isolierung und 
Spannungswandler alles drin sitzt.
Schorse

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Hmmm - kein weiter Einfall...

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

> Diese Umschaltung - wie sie mit MAX485 funzt - wertet nur das
> RS232 (TTL) TxD-Signal aus obwohl der keine Zeichenlänge usw.
> (mit Parität 11-BitBytes) berücksichtigt.
> Frei nach dem Motta wo nicht gesendet wird
> stelle ich auf Empfang.

So wird nur bei Übertragung eines Null-Bits aktiv gesendet, bei einer 
Eins wird bereits der Sender abgeschaltet. Das ist zu schnell.

Abhilfe leistet hier ein (nicht retriggerbares) Monoflop, das nach dem 
Startbit die erforderliche Anzahl von Bitzeiten für ein Datenbyte 
inclusive Parity und Stopbits verzögert.

Damit das funktioniert, muss aber sichergestellt sein, daß nicht 
unmittelbar Start- auf Stopbit des vorhergehenden Bytes folgt - oder 
aber mit zwei Stopbits gesendet und das Monoflop auf ein Stopbit 
ausgerichtet sein, daß das zweite Stopbit also zur "Erholung" des 
Monoflops herangezogen werden kann.

Das muss natürlich sehr genau auf die verwendete Baudrate angepasst 
werden ...

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
Noch kein Account? Hier anmelden.