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.
Angehängte Dateien:
-
RS485_Aufbau.png
40 KB
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.
Beitrag #6592197 wurde von einem Moderator gelöscht.
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.
Eine dumme Frage, sind alle Teilnehmer hintereinander am BUS, oder hast du die sternförmig angeschlossen? Gruß Anselm
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.
Vielleicht hilft ja auch mal ein Foto vom Aufbau. Was für eine Leitung verwendest du (Geschirmt, Twisted Pair, ) ?
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.
Gefühlt >80% der Beiträge drehen sich um Terminierung und Bias, das ist aber allem Anschein nach gar nicht das Problem.
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.
Was hängen denn für Sensoren am Bus (Datenblätter)? Beschaltung vom Master Transceiver?
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.