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.
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
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.
> 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
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.
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
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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
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.
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
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.
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
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.
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
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.
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.
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.
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.
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.
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
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!
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
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.
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.
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.
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
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.
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
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.
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?
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.
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
Hallo,
inzwischen konnte das Problem "gelöst" werden. Wobei noch nicht genau
klar ist wo das Problem überhaupt lag. Nachdem wir andere Sensoren (vom
gleichen Typ) verwendet haben funktioniert alles ohne Probleme. Ich
hatte mir die alten Sensoren nochmal angeschaut aber konnte beim
Schaltverhalten der Tranciver spontan nichts auffälliges feststellen.
Ich nehme das jetzt aber mal einfach so hin da es jetzt scheinbar
funktioniert.
Vielen Dank an alle für die vielen hilfreichen Beiträge und all den
Input. Das hat zumindest dazu geführt, dass ich mich wesentlich stärker
mit RS485 beschäftigt habe als beabsichtigt, was vielleicht nicht ganz
schlecht ist :)
Thomas H. schrieb:> was vielleicht nicht ganz schlecht ist
Sicher nicht. Abschlusswiderstände und Bus-Konflikte werden dich noch
eine male an ganz anderen Stellen begegnen.
Na dann drück ich mal die Daumen. So eine "wunderliche" Reparatur
hinterläßt bei mir immer ein flaues Gefühl im Magen. Immerhin könnte man
noch mal gezielt untersuchen, ob der Fehler tatsächlich an bestimmten
Sensoren festzumachen ist. Aber der TO ist natürlich König...
Gruß Rainer
