Forum: Mikrocontroller und Digitale Elektronik RS485 Fehler ab 3 Teilnehmern


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mich schon ein bisschen durch das Forum hier gelesen aber noch 
keine Antwort gefunden die mein Problem löst. Wobei der Thread schon 
hilfreich war:

Beitrag "RS485 Abschlußwiderstand"

Folgendes Problem:

Wir verwenden eine RS485 Schnittstelle um Sensoren anzusteuern. Im 
Normalfall verwenden wir dazu einen Multiplexer um nacheinander die 
Messdaten von bis zu 48 Sensoren abzufragen. Der Aufbau ist ein wenig 
historisch gewachsen weil die Hardware auch RS232 kann.

Nun wollen wir aber Versuche mit den "neuen" RS485 Sensoren fahren und 
hatten nicht vor dafür eine komplette Schaltung mit Multiplexer zu 
bauen. RS485 kann die Sensoren ja über Adressen ansteuern was den 
Multipexer überflüssig macht. Toll! Zumindest theoretisch.

Nun haben wir das Problem, dass die Sensoren bei mehr als einem 
angeschlossenen Sensor nicht zuverlässig Messdaten liefern.

Jeder Sensor hat seine eigene Adresse und ich kann die Adresse in der 
Regel auch abfragen und bekomme eine Antwort.
Die Kommunikation läuft mit 9600Baud also recht moderat und bis jetzt 
habe ich die Sensoren zu Testzwecken nur einzeln per Hand abgefragt. Es 
sollte also keine Probleme geben weil die Befehle zu schnell kommen. Es 
geht ein Befehl zum Sensor und der schickt mir ein kleines Datenpaket.

Ich habe jetzt die Abschlusswiderstände von den einzelnen Sensoren 
entfernt und nur einen am Ende der Leitung angebracht.

Ein Problem, dass ich mir vorstellen könnte: Es wird geraten zwei 390Ohm 
Widerstände die von A -> +5V und B -> GND gehen zu verbauen. Das habe 
ich aktuell nicht. Die Sensoren laufen mit 24V und die 5V für den 
Transciver werden erst auf der Elektronik erzeugt. Ich könnte die 
Widerstände direkt auf die Sensorelektronik löten aber dann wären sie 
vor jedem einzelnen Transciver. Ich bin nicht sicher ob es das besser 
macht.

Auf der Leitung ist alles toll so lange dort nur ein Sensor 
angeschlossen ist. Mit mehr als einem Sensor ist es recht zufällig ob 
eine Antwort von den Sensoren kommt. Auf dem Oszi sehe ich dann, dass 
der Befehl gesendet wird aber es keine Antwort gibt.
Umso mehr Sensoren ich anschließe umso seltener bekomme ich eine 
Antwort.

Der verwendete Transciver auf der Sensor-Elektronik ist ein MAX3061E. Am 
PC habe ich verschiedene USB RS485 Konverter getestet und alle verhalten 
sich ähnlich.

Die Länge der Leitung beträgt weniger als 2m.

Wie gesagt, wenn ich das ganze mit einem Sensor betreibe funktioniert 
alles wunderbar. Ich habe von RS485 nicht so viel Ahnung und bin 
irgendwie am Ende meines Wissens angekommen :(

Wir wollen auch keine riesigen Mengen an Sensoren anschließen. 10 würden 
schon reichen. Aktuell läuft es aber selbst ab 2 Sensoren schon 
unzuverlässig.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Schalte nur ein Device dran.

Schaue dir das RX-Signal am Chip und am uC (Empfang) an.

Wenn Du nun 10 weiter Teilnehmer an den bus hängst, sollte es sich nicht 
ändern. Fall doch, Ursache suchen. Falls nicht, SW

von Hmmm (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thomas schrieb:
> Ich habe jetzt die Abschlusswiderstände von den einzelnen Sensoren
> entfernt und nur einen am Ende der Leitung angebracht.

Beide Enden müssen terminiert werden.

Thomas schrieb:
> Ein Problem, dass ich mir vorstellen könnte: Es wird geraten zwei 390Ohm
> Widerstände die von A -> +5V und B -> GND gehen zu verbauen.

Die Bias-Widerstände sind dafür da, dass dann, wenn gerade kein 
Busteilnehmer sendet, ein sauberer Ruhepegel vorhanden ist.

Thomas schrieb:
> Auf der Leitung ist alles toll so lange dort nur ein Sensor
> angeschlossen ist. Mit mehr als einem Sensor ist es recht zufällig ob
> eine Antwort von den Sensoren kommt. Auf dem Oszi sehe ich dann, dass
> der Befehl gesendet wird aber es keine Antwort gibt.

Am besten guckst Du mal mit einem Logic Analyzer zu, was auf Pin 1 bis 4 
des Transceivers passiert. Dann siehst Du, was der Slave hört, was er 
antwortet und wann er Treiber und Empfänger ein- und ausschaltet.

von Sascha W. (sascha-w)


Bewertung
2 lesenswert
nicht lesenswert
> Thomas schrieb im Beitrag #6591491
>> Ein Problem, dass ich mir vorstellen könnte: Es wird geraten zwei 390Ohm
>> Widerstände die von A -> +5V und B -> GND gehen zu verbauen.
>
> Die Bias-Widerstände sind dafür da, dass dann, wenn gerade kein
> Busteilnehmer sendet, ein sauberer Ruhepegel vorhanden ist.
und die gehören wenn dann genau 1x an den Bus, i.d.R. an den Master - 
der ist ja immer da.

Sascha

von Thomas H. (thomasthepommes)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Thomas schrieb:
>> Ich habe jetzt die Abschlusswiderstände von den einzelnen Sensoren
>> entfernt und nur einen am Ende der Leitung angebracht.
>
> Beide Enden müssen terminiert werden.

Also, ja es sind beide Enden mit Widerständen versehen. Normal ist der 
Abschlusswiderstand direkt auf der Elektronik. Ich wollte damit nur 
sagen, dass ich nicht an jedem Transciver den R habe sondern nur einen 
(bzw. zwei) für die ganze Leitung verwende :)

> Thomas schrieb:
>> Auf der Leitung ist alles toll so lange dort nur ein Sensor
>> angeschlossen ist. Mit mehr als einem Sensor ist es recht zufällig ob
>> eine Antwort von den Sensoren kommt. Auf dem Oszi sehe ich dann, dass
>> der Befehl gesendet wird aber es keine Antwort gibt.
>
> Am besten guckst Du mal mit einem Logic Analyzer zu, was auf Pin 1 bis 4
> des Transceivers passiert. Dann siehst Du, was der Slave hört, was er
> antwortet und wann er Treiber und Empfänger ein- und ausschaltet.

Muss ich mal schauen ob ich einen auftreiben kann.

von Dietrich L. (dietrichl)


Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Also, ja es sind beide Enden mit Widerständen versehen. Normal ist der
> Abschlusswiderstand direkt auf der Elektronik. Ich wollte damit nur
> sagen, dass ich nicht an jedem Transciver den R habe sondern nur einen
> (bzw. zwei) für die ganze Leitung verwende :)

Dann zeichne mal auf, wie deine Widerstände wirklich verbaut sind.

Du brauchst 4 Widerstände: an einem Ende den Abschlusswiderstand mit 
Bias-Netzwerk und am anderen Ende nur den Abschlusswiderstand.
Siehe auch https://de.wikipedia.org/wiki/EIA-485#Technik

von Nick M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ist das Zweidraht oder Vierdraht RS485? Sind die Sensoren auch wirklich 
still, wenn sie nichts zu sagen haben oder ziehen die den Bus auf 
"ihren" Pegel?

Da gehört schon bisschen Protokoll dazu das du dir aber überlegen musst.

von Veit D. (devil-elec)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

wie kommt ihr auf 4 Widerstände? Wenn es 6 an der Zahl sind.

Je 3 am Anfang und Ende des Busses. Ich verwende je 2x 1k und 1x 130 Ohm 
je Busseite.

von Hmmm (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Veit D. schrieb:
> wie kommt ihr auf 4 Widerstände? Wenn es 6 an der Zahl sind.
>
> Je 3 am Anfang und Ende des Busses. Ich verwende je 2x 1k und 1x 130 Ohm
> je Busseite.

Es gibt keine Notwendigkeit, die Bias-Widerstände auf die Busenden 
aufzuteilen.

Nützlich kann das natürlich sein, wenn Du ein separates 
"Terminierungs-Modul" einsetzt, wovon an jedes Ende eines drangehängt 
wird.

von Nick M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hmmm schrieb:
> Es gibt keine Notwendigkeit, die Bias-Widerstände auf die Busenden
> aufzuteilen.

Ist auch rein vom systematischen her ... hmmm ... eher wirr. Das Bias 
gehört in / an den Master, egal wo der am Bus sitzt.

von Thomas H. (thomasthepommes)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Dietrich L. schrieb:

> Dann zeichne mal auf, wie deine Widerstände wirklich verbaut sind.
>
> Du brauchst 4 Widerstände: an einem Ende den Abschlusswiderstand mit
> Bias-Netzwerk und am anderen Ende nur den Abschlusswiderstand.
> Siehe auch https://de.wikipedia.org/wiki/EIA-485#Technik

Also das wäre der grundsätzliche Aufbau.

Wie gesagt, mit den BIAS Widerständen bin ich mir etwas unsicher da wir 
keine 5V Leitung verwenden sondern 24V zur Versorgung der Sensoren. Ich 
stehe da ein bisschen auf dem Schlauch ob und wie ich hier die 
Widerstände (rot) anbringe damit das im Einklang steht mit den 5V die 
dann am Transciver auf der Sensorelektronik ankommen :(

Zu ein paar anderen Fragen:

Ein Adern-Paar, Halbduplex Betrieb.

Die Sensoren senden in der Regel nichts wenn sie nicht angesprochen 
werden. Auf dem Oszi sehe ich auch nur genau dann eine Bewegung wenn ich 
einen Befehl sende.

Wie gesagt, manchmal bekomme ich Messwerte wenn ich den Sensor anspreche 
und wenn ich das tue dann auch immer vom richtigen Sensor.

Wenn wir die Sensoren im Einzelbetrieb über den Multiplexer verwenden 
dann laufen sie über 24h und liefern zuverlässig Messwerte.

Aber ich schaue mir heute nochmal die Software an. Vielleicht gibt es ja 
auch dort noch ein Problem.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Auf dem Oszi sehe ich dann, dass der Befehl gesendet wird aber es
> keine Antwort gibt.

Und wie unterscheiden sich die Signale, zwischen einem oder mehreren 
Sensoren am Bus?
Bau mal Widerstände in die Busleitung ein, damit du sehen kannst, wer 
den Pegel irgendwo hin zieht.

Hmmm schrieb:
> Am besten guckst Du mal mit einem Logic Analyzer zu, was auf Pin 1 bis 4
> des Transceivers passiert.

Ein LA hilft erst, wenn die Pegel sauber sind oder die Schwellen beim LA 
identisch mit dem Transceiver sind.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Aber ich schaue mir heute nochmal die Software an. Vielleicht gibt es ja
> auch dort noch ein Problem.

Oft sieht man den Fehler, dass nach dem Senden der Transceiver zu früh 
wieder auf Empfangsrichtung umgestellt wird, nämlich bevor das letzte 
Bit physikalisch über den Bus ging. Welches Flag im µC verwendest Du für 
die Entscheidung der Umschaltung?

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Thomas schrieb:
> Nun haben wir das Problem, dass die Sensoren bei mehr als einem
> angeschlossenen Sensor nicht zuverlässig Messdaten liefern.
> Ein Problem, dass ich mir vorstellen könnte

Nicht "vorstellen", sondern messen ist hier angesagt.

> Auf dem Oszi sehe ich dann, dass der
> Befehl gesendet wird aber es keine Antwort gibt.

Zeigt uns doch auch mal, was du da siehst. Flankensteilheit, Pegel, 
Rauschen, Reflexionen wären hier als erstes von Interesse.

: Bearbeitet durch User
Beitrag #6592197 wurde vom Autor gelöscht.
von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> dass nach dem Senden der Transceiver zu früh
> wieder auf Empfangsrichtung umgestellt wird

Man sollte auch auf dem Oszi sehen können, ob die Master-Message sauber 
rausgesendet wird, auf Vermutungen ist man da nicht angewiesen.

Georg

von Dietrich L. (dietrichl)


Bewertung
1 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Wie gesagt, mit den BIAS Widerständen bin ich mir etwas unsicher da wir
> keine 5V Leitung verwenden sondern 24V zur Versorgung der Sensoren.

Ein Widerstand zur (+)-Seite solltest du in jedem Fall haben, denn ohne 
Bias kann eine kurze Störung in den Sendepausen den Enpfänger umschalten 
und du erkennst das nächste Start-Bit nicht mehr.
Bei 24V könnte man im Prinzip den oberen Widerstand entsprechend 
hochohmiger machen. So schön finde ich das aber nicht, denn damit kannst 
du dir Störungen auf den +24V einkoppeln.
Um den Ist-Zustand bezüglich Bias festzustellen: Wenn keine sendet 
(weder Master noch Sensor), dann muss zwischen A und B eine kleine 
Spannungsdifferenz vorhanden sein. Und wie der Sensor beschaltet ist 
lässt sich auch durch messen feststellen.
Insgesamt dürfen nicht mehr als 2 Abschlusswiderstände vorhanden sein, 
sonst wird der Pegel zwischen A und B zu klein. Diese sind am Besten an 
den Enden der Leitung angebracht, um Reflektionen klein zu halten. Bei 
9600Bd ist das allerdings nicht so kritisch, das hängt aber auch von der 
Leitungslänge ab.

von Edi R. (edi_r)


Bewertung
1 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Die Sensoren senden in der Regel nichts wenn sie nicht angesprochen
> werden.

Nichts senden reicht hier nicht. Ein Sensor, der gerade nicht senden 
soll, muss auch seinen RS485-Treiber hochohmig schalten, sonst belastet 
er die Signalleitungen.

von Wolfgang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Dietrich L. schrieb:
> Bei 24V könnte man im Prinzip den oberen Widerstand entsprechend
> hochohmiger machen. So schön finde ich das aber nicht, denn damit kannst
> du dir Störungen auf den +24V einkoppeln.

Das lässt sich mit einem Tiefpass verhindern. Einfach den Widerstand in 
zwei Hälften Teilen und am Abgriff mit einem Kondensator gegen Gnd 
beruhigen.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Hmmm schrieb:
>
>> Am besten guckst Du mal mit einem Logic Analyzer zu, was auf Pin 1 bis 4
>> des Transceivers passiert.
>
> Ein LA hilft erst, wenn die Pegel sauber sind oder die Schwellen beim LA
> identisch mit dem Transceiver sind.

Ich sagte Pin 1 bis 4, das ist nicht die RS485-Seite.

Da sind die Pegel sauber, mit einer Ausnahme: Wenn der Receiver 
abgeschaltet wird, ist der Ausgang davon (zumindest bei den meisten 
Transceivern) hochohmig.

von Anselm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eine dumme Frage, sind alle Teilnehmer hintereinander am BUS, oder hast 
du die sternförmig angeschlossen?

Gruß
Anselm

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
Da es offensichtlich schon in Minimalkofiguration nicht funktioniert, 
empfehle ich eine simple Testsoftware. Das "schwere" Messen mit LA und 
schlimmer ist meist nicht nötig, zumal hier keine Raketengeschwindigkeit 
über den Bus läuft. Es sollte also der einfachste Ablauf getestet 
werden. Master sendet Slave-Adresse und bekommt Antwort. Dass hier bei 
Halb-Duplex die Treiber entsprechend angesteuert werden müssen, sollte 
klar sein. Wenn das gelungen ist, sollte die Erweiterung auf mehr Slaves 
kein Problem sein...Terminierung wie schon vorgeschlagen, egal ob 24V 
oder 5V über die Leitung läuft.
Gruß Rainer

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn ihr mich fragt, dienen die 24V und Masse wohl nur zur Versorgung 
der Sensoren. Hier würde ich auch keine Terminierungswiderstände 
anklemmen. Du wirst wohl oder übel an zwei Sensoren (oder Master + einen 
Sensor) alle notwendigen Widerstände auflöten müssen und diese an beide 
Enden des Busses klemmen müssen. Außer du guckst ins Datenblatt deiner 
Sensormodule welche maximale Busspannung erlaubt ist. Gewöhnlich nur bis 
12V.

von Timo N. (tnn85)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hilft ja auch mal ein Foto vom Aufbau.

Was für eine Leitung verwendest du  (Geschirmt, Twisted Pair, ) ?

von Nick M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Edi R. schrieb:
> Nichts senden reicht hier nicht. Ein Sensor, der gerade nicht senden
> soll, muss auch seinen RS485-Treiber hochohmig schalten, sonst belastet
> er die Signalleitungen.

Nachdem jetzt klar ist, dass es Zweidraht ist, würde ich auch sagen, 
dass man das als nächstes kontrolliert. Denn mit dem Multiplexer und 
RS232 war das nicht nötig.

von Dieter W. (dds5)


Bewertung
0 lesenswert
nicht lesenswert
Sind die Sensoren Kaufteile oder Eigenentwicklungen?

Bei ungünstiger Auslegung der Empfangsroutine kann es vorkommen, dass 
der Empfänger noch durch die mitgehörte Antwort eines anderen Sensors 
"verstopft" ist und erst eine "Erholzeit" braucht.

von Wolfgang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hmmm schrieb:
> Ich sagte Pin 1 bis 4, das ist nicht die RS485-Seite.

Ich kann lesen, meinte aber nicht die Pegel auf der Logikseite vom 
Treiber, sondern die auf dem RS485-Bus. Denke mal über den Sinn der von 
dir vorgeschlagenen Messung nach. .

Wenn alles mit rechten Dingen zu geht, wird dabei raus kommen, dass 
irgendein Logikpegel nicht passt. Wenn es anders wäre, würde die 
Übertragung funktionieren. Die Messung auf der Logikseite des MAX3061 
bringt einen da also kaum einen Schritt weiter.

Das Problem entsteht durch das Zusammenschalten auf der RS485-Seite. Und 
ob sich dort irgendwelche Ausgänge behaken oder jemand zur falschen Zeit 
den Bus runter zieht, erkennt man an komischen Pegeln. Mit zusätzlichen 
Widerständen sieht man auf dem Oszi sogar sofort, wer der Bösewicht ist.

Alles andere ist Stochern im Nebel.

von TomA (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hallo Thomas.

Entspann dich mal, denke in Ruhe selbst nach und lasse dich nicht 
schwindelig quatschen. Die RS485 ist eine Schnittstelle die bis zu 
10MBaud Datenrate und 1,2km Kabellänge kann, aber nicht Beides 
gleichzeitig. Bei 10MBit sind max. 100m Kabellänge praktikabel.

Mit deinen 2m Kabel und 9600Baud Übertragungsgeschwindigkeit kannst du 
eine nassgepisste Paketschnur zur Übertragung verwenden und mit 
Hasenkötteln terminieren. Vergiss die Verkabelung, die funktioniert, wie 
du im Punkt zu Punkt Betrieb (nur zwei Geräte) siehst (der funktioniert 
ja ordentlich!). Das Einzige was du an der Verkabelung überprüfen 
solltest ist die Polarität der Signale (D+ auf D+ auf D+ ... / D- auf D- 
auf D- ...). RS485 funktioniert oft auch bei falscher Polarität, aber 
nicht stabil.

Wie Wolfgang schon schrieb, konzentriere dich auf das Wesentliche - und 
das ist hier ganz sicher nicht das Kabel und dessen Terminierung.

Ich denke du hast ein Problem mit der Adressierung (evtl. 
Doppeladressierung) oder einer falsch eingestellten Betriebsart. Schau 
in die Beschreibungen der beteiligten Geräte, ob du irgendwelche Jumper 
oder Softwareschalter umstellen musst.

Gruss Tom

von Rainer V. (a_zip)


Bewertung
1 lesenswert
nicht lesenswert
Sorry, ich hatte überlesen, dass es mit 2 Teilnehmern funzt. Ja dann 
bleiben wirklich nur Verdrahtungsfehler und vermutlich Software! Und die 
Terminierungen gegen Vcc und Gnd müssen natürlich an 5V und Gnd und 
nicht an diese 24V!
Bin gespannt...Gruß Rainer

von Wolfgang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Rainer V. schrieb:
> Und die Terminierungen gegen Vcc und Gnd müssen natürlich an 5V und Gnd und
> nicht an diese 24V!

Was heißt "natürlich"?
Schon die Terminierung des Bus durch die Terminierung selbst sorgt 
dafür, dass die 24V nicht am Bus auftauchen - nennt sich 
Spannungsteiler. Und mit dem Kondensator im aufgeteilten Pull-Up 
erreicht man Impedanzsymmetrie bzgl. der Pegel.

von Rainer V. (a_zip)


Bewertung
1 lesenswert
nicht lesenswert
Für mich natürlich, weil der Baustein ja an 5V angeschlossen wird. Was 
will ich da gegen die 24V terminieren? Wenn du aus 24V eine 
Versorgungsspannung für deine Schaltung gewinnst, ok, danach 
interessiert aber nur noch diese Spannung...
Gruß Rainer

von Wolfgang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Rainer V. schrieb:
> Für mich natürlich, weil der Baustein ja an 5V angeschlossen wird. Was
> will ich da gegen die 24V terminieren?

Auf der Seite der Sensoren stehen eben keine 5V zur Verfügung, wenn man 
nicht an der Elektronik rumlöten möchte/kann/darf und trotzdem möchte 
man dort den Bus vielleicht vernünftig terminieren.

Thomas schrieb:
> Die Sensoren laufen mit 24V und die 5V für den
> Transciver werden erst auf der Elektronik erzeugt.

von Rainer V. (a_zip)


Bewertung
1 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Auf der Seite der Sensoren stehen eben keine 5V zur Verfügung

Leider verstehe ich dich nicht. Will aber jetzt auch keinen 
Nebenschauplatz aufmachen. Auf der Sensorseite muß ja ein RS485-Baustein 
sein und der arbeitet nicht mit diesen 24V. Wie der gesteuert wird ist 
ja erst mal egal, aber das Netz zwischen den RS-Bausteinen arbeitet 
sicher mit deren eigener Versorgungsspannung, während die 24V für die 
Sensorik selbst ist...so einfach...und daher terminiere ich gegen diese 
Spannung.
Gruß Rainer

von Nick M. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Auf der Seite der Sensoren stehen eben keine 5V zur Verfügung, wenn man
> nicht an der Elektronik rumlöten möchte/kann/darf und trotzdem möchte
> man dort den Bus vielleicht vernünftig terminieren.

Terminieren ist was Anderes als Bias. Den Bias sollte der Master machen. 
Terminierung hängt an den Enden der Leitung, dazu muss nicht zwangsweise 
am Leitungsende ein Sensor hängen. Kann aber.
Die 24 V am Sensor sind dafür komplett uninteressant.

Irgendwie scheinst du immer mehr durcheinander zu kommen.

von Dieter W. (dds5)


Bewertung
0 lesenswert
nicht lesenswert
Gefühlt >80% der Beiträge drehen sich um Terminierung und Bias, das ist 
aber allem Anschein nach gar nicht das Problem.

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Ich habe von RS485 nicht so viel Ahnung und bin
> irgendwie am Ende meines Wissens angekommen

Aber ihr habt das alles doch bisher in RS232 schon laufen. Und nun mußt 
du die RS485 halt richtig verschalten. Es sind am Anfang doch schon 
einige Tips gekommen. Hast du das mal versucht? Ich kann mir gerade 
wieder nicht vorstellen, dass die Kommunikation mit 2 Teilnehmern 
zuverlässig läuft und schon der dritte das ganze zum Kollaps bringt.
Gruß Rainer

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Hmmm schrieb:
>> Ich sagte Pin 1 bis 4, das ist nicht die RS485-Seite.
>
> Ich kann lesen, meinte aber nicht die Pegel auf der Logikseite vom
> Treiber, sondern die auf dem RS485-Bus. Denke mal über den Sinn der von
> dir vorgeschlagenen Messung nach. .

Der TO sieht mit dem Oszi den Request auf dem Bus, bloss keine Replies. 
Krumme Pegel anstelle der Replies hätte er hoffentlich erwähnt.

Der aus meiner Sicht nächste Schritt wäre jetzt, sich anzugucken, was in 
den Slaves aus dem Receiver rauskommt und ob und wie sie darauf 
reagieren. Mit einem 8-Channel-LA könnte man bequem das komplette 
Verhalten von zwei Slaves beobachten.

Aber das ist natürlich nur einer der möglichen Ansätze.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Dieter W. schrieb:
> Gefühlt >80% der Beiträge drehen sich um Terminierung und Bias, das ist
> aber allem Anschein nach gar nicht das Problem.

Woher willst du das wissen?

Ein Blick auf das Oszilloskop würde mehr als 100 Worte bringen, aber 
dieses Bild behält er für sich.

Der verarscht uns doch!

Solange der TO sich weigert, die Bilder vom Aufbau und dem Oszilloskop 
zu zeigen, ist er es nicht würdig, von uns Hilfe zu bekommen. Wer nehmen 
will, muss auch etwas geben.

: Bearbeitet durch User
von Achim S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Krumme Pegel anstelle der Replies hätte er hoffentlich erwähnt.

Wenn er sie wahrgenommen und richtig interpretiert hätte, dann hätte er 
sie wohl erwähnt. Andererseits hätte er sich dann wahrcheinlich den 
ganzen Thread gespart und selbst die Lösung seines Problems gefunden.

Aber vielleicht hat er die Pegel im Fehlerfall noch gar nicht überprüft. 
(Sondern nur folgendes angeschaut, ohne es genauer zu analysieren:

Thomas H. schrieb:
> Auf dem Oszi sehe ich auch nur genau dann eine Bewegung wenn ich
> einen Befehl sende.

In jedem Fall ist es mehr als naheliegend, die Ergebnisse der 
Oszimessungen mal hier zu zeigen. Und zwar idealerweise im Vergleich 
einer Messung, bei der die Daten richtig ankamen zu einer zweiten 
Messung, bei der die Daten falsch interpretiert wurden.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Der TO sieht mit dem Oszi den Request auf dem Bus, bloss keine Replies.
> Krumme Pegel anstelle der Replies hätte er hoffentlich erwähnt.

Der TO hat zwar ein oszi, vermutlich aber keine Ahnung, wie er die 
analogen Signale interpretieren soll.

Thomas H. schrieb:
> Auf dem Oszi sehe ich auch nur genau dann eine Bewegung wenn ich einen
> Befehl sende.

Schon die erste Antwort war, schau mit dem oszi auf die Signale. 
Stattdessen will er lieber an Widerständen drehen, einen LA besorgen 
oder SW checken.

Solange der TO die Signale weder lesen noch teilen kann, ist der Rest 
Vodoo.

Sonst hat der fragende einfach keins. Hier hat er vielleicht Hemmungen, 
weil es ein 10€ Teil ist. Doch das reicht völlig aus.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
A. S. schrieb:
> Hier hat er vielleicht Hemmungen,
> weil es ein 10€ Teil ist. Doch das reicht völlig aus.

Ich sage auch immer dass so ein "Spielzeug" DSO-138 oder DSO-150 immer 
noch sehr viel besser ist, als gar keins.

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
Auch wenn der TO vielleicht aufgegeben hat...ich denke jetzt, dass er 
das Problem hat, dass der zweite Slave wahrscheinlich in der Antwort des 
ersten seine Adresse irgendwann erkennt und nun seinerseits antwortet. 
Diese Möglichkeiten muß man per Software ausschließen. Also muß man ein 
Protokoll vereinbaren, das für alle Beteiligten gilt. Da der TO bisher 
seine Sensoren per Multiplexer umgeschaltet/angesprochen hat, hatte er 
dieses Problem dort natürlich nicht! Unter der Voraussetzung, dass die 
Verbindung wirklich mit 2 Partnern klappt, braucht man sich auch um 
Hardware erst mal nicht zu kümmern.
Gruß Rainer

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Man könnte den Bus zur probe mal mit 3 Teilnehmern belasten aber den 
dritten im Reset-Zustand halten, damit er nicht dazwischen funkt.

Oder mal was ganz abgefahrenes tun: Ein Oszillogramm vorzeigen!

von Georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wenn der TO sonst nichts auf die Reihe kriegt kann er sich ja immer noch 
einen Multiplexer bauen aus RS485-Transceivern, von denen immer nur 
einer zu einem Slave durchgeschaltet wird. Das ist ja nicht mehr Aufwand 
als bisher mit RS232C, und anscheinend haben die das ja schon 
hingekriegt.

Georg

von Nick M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Georg schrieb:
> Das ist ja nicht mehr Aufwand
> als bisher mit RS232C, und anscheinend haben die das ja schon
> hingekriegt.

Da hätte er doch viel schlauer das RS232 auch auf einem Bus laufen 
lassen können, ohne MPX.
Aber wer in der Software spart, muss halt in die Hardware mehr Geld 
stecken.

von uwe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was hängen denn für Sensoren am Bus (Datenblätter)?
Beschaltung vom Master Transceiver?

von uwe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Muss mich TomA anschließen(Hihi):
->Mit deinen 2m Kabel und 9600Baud Übertragungsgeschwindigkeit kannst du
->eine nassgepisste Paketschnur zur Übertragung verwenden und mit
->Hasenkötteln terminieren.

von Hans-jürgen H. (hjherbert) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Schau dir MODBUS an.

Das läuft zuverlässig.

- Jeder Slave hat eine  Nummer.
- Jedes Telegramm, egal ob Reizung oder Antwort, beginnt mit der 
Slave-Nummer.
- Nur der gefragte Slave sendet seine Antwort.
- Jedes Telegramm ist durch eine 15-Bit-CRC geschützt.
- Timeout ist 35 Bit-Zeiten.

Siehe https://simplymodbus.ca/

Problematisch sind die RS232/RS485-Umsetzer, die nicht durch RTS 
gesteuert werden. Die ziehen nicht aktiv auf Ruhepegel.

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
Na, ich glaube, dass verselbstständigt sich hier jetzt 
wieder...vielleicht hatte der TO ja auch nur einen läppischen Fehler 
gemacht und schämt sich jetzt :-)
Gruß Rainer

von Thomas H. (thomasthepommes)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin erst Ende der Woche wieder in der Firma daher kann ich im Moment 
keine Bilder machen :(

Der Aufbau ist aktuell so einfach wie möglich um alle denkbaren 
Fehlerquellen auszuschließen. Ich habe eine Lochrasterplatine auf der 
die 4 Leitungen angebracht sind. Auf die Leitungen sind eine Hand voll 
Stecker gelötet und am Ende der Leitung ein 120R zwischen A und B. Alles 
hintereinander, keine Sternschaltung.

Von den Steckern gehen ca. 30-40cm lange, geschirmte Kabel zu den 
einzelnen Sensoren. Kein Twisted Pair. Keine externe Quelle in der Nähe 
die groß stören könnte.

Vom RS485 Stick gehen zwei kurze Kabel (<5cm) an die Lochrasterplatine. 
Zusätzlich die 24V von einem kleinen Netzteil.

Das ist kein aktueller Versuchsaufbau. Später soll das mal noch etwas 
komplizierter verbaut werden. Aber wenn es selbst in der 
Grundkonfiguration nicht funktioniert brauche ich noch nicht 
weiterdenken.

Ich werde mich die Woche nochmal mit der Software beschäftigen.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Vom RS485 Stick gehen zwei kurze Kabel (<5cm) an die Lochrasterplatine.
> Zusätzlich die 24V von einem kleinen Netzteil.

Kein GND?

Georg

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Der Aufbau ist aktuell so einfach wie möglich um alle denkbaren
> Fehlerquellen auszuschließen. Ich habe eine Lochrasterplatine auf der
> die 4 Leitungen angebracht sind. Auf die Leitungen sind eine Hand voll
> Stecker gelötet und am Ende der Leitung ein 120R zwischen A und B. Alles
> hintereinander, keine Sternschaltung.
>
> Von den Steckern gehen ca. 30-40cm lange, geschirmte Kabel zu den
> einzelnen Sensoren. Kein Twisted Pair. Keine externe Quelle in der Nähe
> die groß stören könnte.

Du widersprichst dir da selbst. Wenn du den "Bus" auf einer Platine hast 
und davon dann zu jedem Teilnehmer erst noch 30cm Kabel führst, dann ist 
das IMNSHO ganz klar eine Sternverdrahtung und kein normaler Bus.

von Nick M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ralf D. schrieb:
> dann ist
> das IMNSHO ganz klar eine Sternverdrahtung und kein normaler Bus.

Sollte bei 9600 Bd echt egal sein. Aber dennoch nicht richtig.
Wurde im Treiberbaustein auch die slew rate auf low konfiguriert?

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nick M. schrieb:
> Wurde im Treiberbaustein auch die slew rate auf low konfiguriert?

Der MAX3061E gehört nicht zu den (wenigen) Transceivern, bei denen man 
das könnte, sondern ist immer slew-rate limited.

Aber beim Testaufbau mit 9600bps und ein paar cm Buslänge ist das völlig 
egal, da kannst Du auch einen alten SN75176 ohne jegliche Terminierung 
verwenden, und es wird immer noch funktionieren.

Meine Vermutung ist, dass es ein Softwareproblem ist. Adressierung der 
einzelnen Geräte vermurkst, so dass keines oder alle gleichzeitig 
antworten, zu schnelle Antworten / zu langsame TX/RX-Umschaltung, 
irgendsowas.

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Meine Vermutung ist, dass es ein Softwareproblem ist. Adressierung der
> einzelnen Geräte vermurkst, so dass keines oder alle gleichzeitig
> antworten, zu schnelle Antworten / zu langsame TX/RX-Umschaltung,
> irgendsowas.

Ja, das hat sich ja schon herauskristalliert. Da er bisher seine 
Sensoren über Multiplexer angesprochen hat, also hardwaremäßig 
verschaltet hat, hatte er natürlich kein Problem mit Kommunikation 
"untereinander". Nun müssen die Teilnehmer aber wissen, was auf ihrem 
Bus passiert und das muß jeder Kontroller in Software haben! Vielleicht 
beginnen wir noch mal mit der einfachsten Topologie, also 1 Master ein 
Slave plus einweiterer Slave mit Terminierung am Master und am 
End-Slave. Die ominöse Terminierung zur Versorgung sollte erst mal 
wegbleiben. Das verwirrt nur. Der TO hat nun also die Aufgabe, die 
Slaves so zu programmieren, dass sich das gewünschte "Frage-Antwort" 
ergibt. Man schaut sich dazu vielleicht mal einfache Busprotokolle an, 
kann sich aber auch selbst was ausdenken! Viel Spass...
Rainer

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.