Hallo Ist es irgendwie möglich einen RS-485-Bus "plug&play"-fähig zu bekommen. Ich meine ohne das ich alle Adressen der angeschlossenen Sensoren und Aktoren vorher im Speicher aufliste. Ich hatte mir gedacht, daß ich den einzelnen Sensoren und Aktoren Adressen (Nummern) gebe (EEPROM des Controllers), die dann vom Master erkannt werden sollen.
Hallo! Ich arbeite zur Zeit auch an so etwas ähnlichem. Ich sehe aber momentan eher ein Problem darin, dass wenn der Bus "Plug and Play" fähig ist, er ja in bestimmten Zeitintervallen nach neuen Teilnehmern suchen müsste. Momentan ist das so gedacht, dass der Master an alle Adressen, von denen er meint dass dort kein Teilnehmer ist, ein bestimmtes Paket sendet, und falls zwischenzeitlich dort ein Teilnehmer angeschlossen wurde, dieser antwortet. Allerdings bremst das meiner Meinung nach den Bus aus, da in bestimmten Intervallen gesucht werden müsste und währenddessen kein anderer Teilnehmer senden darf. Außerdem muss man ein kleines Timeout einbauen, um den Teilnehmern Zeit zum antworten zu lassen. Um diese unnötige Belastung des Bus zu vermeiden, sucht mein Master nur nach neuen Teilnehmern, wenn man einen Taster drückt. So muss ich ihm zwar selber sagen dass er suchen soll, aber ich denke, dass das besser ist als den Bus unnötig zu belasten. Mit den Adressen im EEPROM das hab ich mir auch schon überlegt. Ich werde es wahrscheinlich so machen, dass jeder Teilnehmer zu beginn seine Adresse aus dem EEPROM liest. Man muss halt dann darauf achten keine Adresse 2 Mal zu vergeben. mfg Michael
Hallo Michael, warum willst du dieses Scannen weglassen, die Busperformance wird darunter kaum leiden. Außerdem brauchst du bei einem 485-Bus ja sowieso einen Master der die Buszugriffe regelt, oder hast du eine bessere Lösung um Kollisionen zu vermeiden ? Ich sehe das Problem eher in der Verkabelung, kommt der neue Teilnehmer in die Busmitte, wird der Bus beim Einschleifen kurzzeitig in zwei unabhängige Segmente geteilt (denen dann auch noch jeweils ein Abschlußwiderstand fehlt). Kommt der neue Teilnehmer ans Ende gibts die Trennung zwischen Abschluß und Bus. grüsse leo9
Meine Überlegung war folgende: Wenn der Master immer nach einer Sekunde sucht. und in meinem Bus max 15 Teilnehmer sein können, und er jedem teilnehmer einen Timeout von 20ms lässt, dann hab ich alle 1 sec eine Unterbrechung von 0,3 sec, also fast ein viertel der Zeit. Außerdem ist es in meinem Fall nicht so dass man normalerweise während des Betriebs Teilnehmer anschließt, sondern das ganze ist eher ein nettes Feature, man könnte auch das ganze Gerät abschalten und danach wieder an, dann werden neue Teilnehmer auch erkannt... mfg Michael
Warum muss sich der Master darum kümmern? Eine Kollisionsprüfung kann man recht einfach dadurch realsieren, dass man das was man sendet selbst empfängt (Transceiver konstant als Listener), und dann überprüft. So kann ein neu hinzugekommener Teilnehmer auch den Bus überwachen und sich bei nächster Gelegenheit beim Master anmelden, also quasi ein Temporärer Master. @Leo: Warum sollte der Bus bei einem neuen Teilnehmer aufgetrennt werden? Normalerweise wird der Bus ja nicht durch ein Gerät durchgeschliffen. Es wäre halt ein Problem der mechanischen Umsetzung. Die Terminierungswiderstände braucht man eigentlich nur bei sehr hohen Geschwindigkeiten und langen Kabeln... Jetzt würde mich noch interessieren, wie häufig es zu einem Gerätewechsel kommt und wie der Master feststellt, dass ein Gerät senden will. Wenn man die Slaves sowieso triggern muss, kann man das auch für alle Geräte der Reihe nach, weil es doch sonst zu endlosen Kollisionen käme. Wenn schon dynamisch, dann von Anfang an: Erst nur der Master, der vergebens auf Antworten wartet. Sobald ein Gerät vorhanden ist, würde sich dieses ja auch auf die Anfrage mit der entsprechende Adresse melden. Eine Art Hardware-Adressierung ist ja sowieso notwendig, damit der Master die Daten zuordnen kann. Oder handelt es sich bei den anderen Geräten nur um Anzeigen? Dann würde sich auch die RS422 eignen. Die hat für jede Richtung ein eigenes Aderpärchen. Gruß Rahul
@Rahul: "recht einfach dadurch realsieren, dass man das was man sendet selbst empfängt " ... darin liegt das Problem vieler RS485-Designs, die Bustreiber sind relativ niederohmig (meist auch kurzschlußfest) und die Pegelerkennung lautet meist A>B bzw Rx+>Rx-. Wenn nun zwei Treiber gegeneinander arbeiten reichen bereits die Übergangswiderstände der Stecker damit jeder Teilnehmer auf seiner Busseite seine gesendeten Daten liest und von der Kollision nichts mitbekommt. Wenn man auf R2-485 Ebene ein Multimaster Konzept realisieren will, kommt man um ein Protokoll mit ACK resp. NACK nicht herum. Die RS485 ist von den elektrischen Eigenschaften nicht für Kollisionen bzw. deren Erkennung konzipiert. grüsse leo9
"Eine Kollisionsprüfung kann man recht einfach dadurch realsieren, dass man das was man sendet selbst empfängt (Transceiver konstant als Listener), und dann überprüft. So kann ein neu hinzugekommener Teilnehmer auch den Bus überwachen und sich bei nächster Gelegenheit beim Master anmelden, also quasi ein Temporärer Master." @ Rahul: So wie du das beschreibst sehe ich aber noch ein Problem. Mal angenommen ein Teilnehmer überwacht den Bus und erkennt eine Pause. Wenn er da sofort etwas sendet um sich beim Master einzubuchen, dann kann es aber doch sein, dass gleichzeitig ein anderer Teilnehmer zu senden anfängt und somit wieder nur Datenmüll rauskommt.
Hallo Leute, habe da mel eine Frage die da gur hineinpassen würde. Arbeite gerade an einem dezentralen RS485 Bus. Hat jemand irgendwo ein ein fertiges Busprotokoll im Netz gefunden (in Basic). Wie CSMA/CD funktioniert ist mir klar es geht mir mehr um die Programmierung. THX Mario
Hallo, da möchte ich auch gern nochmal eine Frage einwerfen: Was passiert denn eigentlich, wenn ich keine lange Busleitung nehme, sondern Sternförmig vom Master weggehe? Wo ist da dann der elektrische Unterschied? Wenns denn hier reinpasst, würd ich mich über eine Erklärung freuen... Dirk
@Michael, "Meine Überlegung war folgende: Wenn der Master immer nach einer Sekunde sucht. und in meinem Bus max 15 Teilnehmer sein können, und er jedem teilnehmer einen Timeout von 20ms lässt, dann hab ich alle 1 sec eine Unterbrechung von 0,3 sec, also fast ein viertel der Zeit." Warum ? Zwingt Dich denn jemand, immer alle 15 sofort hintereinander zu suchen ? Sobalder der Master eine Pause hat, sucht er irgendeinen und in der nächsten Pause den nächsten usw. Aber ich weiß schon, warum ich lieber CAN nehme. Beim Devicenet Protokoll z.B. schreit jeder neue Slave sein DuplicateMacID raus und fertig. Und da der CAN ja kollisionsvermeidend ist, gelingt es jedem, der was senden will, dies auch zu tun. Peter
@Peter: Der CAN ist nicht kollisionsvermeidend, er ist lediglich im Stande Kollisionen auf Bit-Ebene zu erkennen und der rezessive Teilnehmer zieht sich vom Bus zurück. Das bedeutet eine Kollision kann auftreten, es wird aber das dominante Datenpaket nicht gestört und es müssen nur die rezessiven Daten nocheinmal geschickt werden. grüsse leo9
CSMA/CA = Carrier-Sense Multiple Access with Collision Avoidance
^^^^^^^^^ ^^^^^^^^^
||||||||| |||||||||
Peter
@Peter: Die Wahrscheinlichkeit dass zwei Teilnehmer zum gleichen Zeitpunkt auf den Bus wollen ist durch das Zugriffsverfahren zwar deutlich geringer als in CSMA/CD-Netzen, verhindert werden Kollisionen dadurch aber nicht. Der Vorteil von CAN liegt halt einfach darin dass auch bei Auftreten einer Kollision ein Datenpaket am Bus "überlebt". Im Gegensatz dazu wird z.B. bei RS-485 die Übertragung unwiderruflich gestört und beide Stationen müssen nochmals mit der Sendung beginnen. Einigen wir uns einfach darauf dass eine "nicht destruktive Kollision" eben "keine echte Kollision" ist, dann stimmt deine Vermeidung und meine Erkennung. grüsse leo9
Ist eine Kollision nicht per Definition das Zerstören der vorliegenden Informationen? Und genau das kann (auch definitionsgemäß) bei CAN nicht vorkommen. http://www.lfs-tipps.de/sections.php?op=printpage&artid=30 (Abschnitt: "Was ist eine Kollision?") beschreibt was eine Kollision auf elektr. Ebene ist. Ich halte das für aussagekräftig und auf logische Ebene übertragbar. (Bestätige damit im Prinzip leo9s letzten Absatz). ----, (QuadDash).
Hallo ich hatte in den letzten Tagen keine Zeit zu antworten. Danke erstmal für die Antworten. Ich habe mich entschieden den Bus anders aufzubauen. Ich werde einfach alle Adressen die ich vergeben habe und vergeben werde im Master speichern und dann den Bus im Master/Slave Modus arbeiten. Also die zyklische Abfrage der Slaves. Das ist einfacher. Die Anzahl der Slaves wird ja bis maximal 30/32 begrenzt sein. Da reicht eigentlich der EEPROM locker aus. Nun meine Frage: Gibt es da vielleicht schon "Protokoll-Gerüste"? Damit ich nicht erst was erfinden muß, was schon da ist. ;-)
Schau mal ob dir das weiterhilft: http://www.elektronik-projekt.de/include.php?path=content/articles.php&contentid=16&PHPKITSID=edd784f04007bcaafa2db67e76f27418 Dort ist unter anderem ein Protokoll beschrieben. Das funktioniert allerdings nur, wenn alle Teilnehmer ihr UART auf 9Bit schalten können. Das geht z.B. mit den AVRs mfg Michael
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.