Hallo zusammen, ich möchte über einen PC die Teilnehmer eines Bus-Netzerkes einlesen. Das Netzerk selbst arbeitet nach dem Master Slave Verfahren. Der Master ist in meinem Fall der PC und die Slaves eben die Teilnehmer, die alle durch AVR's realisiert werden. Die Slaves arbeiten in verschiedenen Modien wie Sensoren oder Aktoren. Nun stellt sich mir allerdings die Frage wie ich die Sendeberechtigungen beim Abfragen/Einlesen steuern kann. Ansprechen würde ich alle Teilnehmer über die Broadcast Adresse. Dann erwartet der Master ja eine Antwort der Teilnehmer. Nur welcher Slave darf nun dem Matser wann antworten? Hat jemand einen Gedankenanstoß für mich zu dem Thema oder hat schon einmal etwas ähnliches realisiert? Gruß Tobias
:
Verschoben durch Moderator
Fernbus, Stadtbus, CAN-Bus, RS485-Bus?
:
Bearbeitet durch User
Tobias schrieb: > Nun stellt sich mir allerdings die Frage wie ich die Sendeberechtigungen > beim Abfragen/Einlesen steuern kann. Exakt so, wie es in dem uns unbekannten Protokoll des uns unbekannten Busses festgelegt ist.
Tobias schrieb: > Ansprechen würde ich alle Teilnehmer über die Broadcast Adresse. Ethernet netzwerk mit bus-topologie? Das ist veraltet. Die übliche Lösung währe dann auf den teilnehmern ein Programm laufen zu lassen, das per Multicast die anderen Teilnehmer abfragt, bei abfragen antwortet, und alle n sekunden ins netz ruft; das er da ist. So funktioniert u.a. auch ssdp.
Hallo zusammen, habe vergessen den Typ des Netzwerkes mit anzugeben. Es handelt sich um ein RS485 Netzerk mit einem selbst implementierten Protokoll, welches dem Modbus Protokoll ähnelt. Gruß Tobias
Tobias schrieb: > mit einem selbst implementierten > Protokoll, Das ist ja einfach: denk dir was aus! Da RS485 nicht kollisionsfest ist, würde ich eine Form von Zeitscheibenmanagement (heisst time-slice so?) vorschlagen.
Wenn dein Protokoll Modbus ähnelt musst du deine Slaves einzeln ansprechen. Broadcast (Adresse 0) kann nur zum Schreiben verwendet werden und erwartet keine Antwort von den Slaves. Gruß Ulrich
Ulrich K. schrieb: > Wenn dein Protokoll Modbus ähnelt musst du deine Slaves einzeln > ansprechen. Broadcast (Adresse 0) kann nur zum Schreiben verwendet > werden und erwartet keine Antwort von den Slaves. > > Gruß > Ulrich Danke für die Antworten. Ja das habe ich raus gefunden. Ich würde allerdings gerne die Vergabe der Adressen per Software vergeben. Was mitunter ein Grund ist, warum ich das Modbus-Protokoll nicht direkt verwenden möchte. Gruß Tobias
Ich mache es bei RS485 so, dass ich jedem RS485-Slave erstmal per Default die Adresse 99 verpasse. Anschließend hänge ich den ersten Slave erstmal allein an den Bus und vergebe dann per Befehl über RS485 vom Master aus eine neue Adresse, sagen wir 01. Anschließend kann ich den nächsten Slave konfliktfrei an den Bus hängen. Diesen verpasse ich dann die 02. usw. usw. Die Slaves speichern ihre neue Adresse im EEPROM.
Hallo Tobias, ich interpretiere 'Adressen per Software vergeben' mal so, dass du deine Slaves bevor du sie an den Bus hängst konfigurieren willst (wenn sie alle am Bus hängen müssen sie ja schon eine individuelle Adresse haben). Beim Modbus gibt es dazu die Slave Adresse 248. Auf diese Adresse antwortet jeder Slave, sie ist daher für den Punkt zu Punkt Betrieb gedacht (der Slave wird direkt mit dem PC verbunden). Konfigurationswerkzeuge können sich darüber verbinden und die gewünschte Slave Adresse in ein Modbus Register schreiben. (entschuldige meine 'Modbus -Brille') Gruß Ulrich
Hallo zusammen, vielen Dank für die zahlreichen Antworten. Die Ideen finde ich schon mal sehr gut. Ich hatte eine andere Idee, die es ermöglicht, die Teilnehmer direkt am Bus zu ermitteln. Zu Beginn haben alle Slaves keine Adresse sondern hören nur auf eine Broadcast Nachricht. In der Broadcast-Anfrage binde ich die Seriennummer fortlaufend ein und Frage ab ob ein Teilnehmer mit der Seriennummer z.B 0 bis 9999 vorhanden ist. Wenn ein Teilnehmer mit der Seriennummer z.B 5 da ist, Frage ich einige Parameter ab, wie Typ Version usw. Darauf hin kann ich über das gleiche Verfahren die Bus-Adresse konfigurieren. Ich habe allerdings ein Problem damit, dass ich nie ermitteln kann, ob ein Slave mit einer bestimmten Seriennummer einfach nicht am Bus ist oder schlicht weg defekt ist. Was meint ihr zu der Alternative? Gruß Tobias
Tobias schrieb: > Was meint ihr zu der Alternative? Wenn du sowieso eine eindeutige Seriennummer hast, wozu brauchst du dann noch eine zusätzliche Adresse? In dem Fall IST die Seriennummer die Adresse. Siehe zb DS1820. Die machen das genau so. Das was du dann 'Adresse' nennst, ist dann nichts anderes als eine Kurzform der Seriennummer. Sozusagen der Spitzname des Gerätes am Bus. Nur eben, dass du ihm diesen Spitznamen dynamisch zuweist und den lieber verwendest, weil du dann weniger Transfer am Bus hast. Du hast dein eigentliches Problem nicht gelöst :-) Du hast es nur anders benannt. Hast du dir schon mal überlegt, wie lange es dauert, bis du beim Systemstart alle möglichen Seriennummern abgeklappert hast?
:
Bearbeitet durch User
Wenn ein Teilnehmer eine niedrigere Seriennummer hat als die vom Master gesendete meldet er sich mit einem Dominanten Status. Der Master erkennt dann, dass es mindestens einen Klient gab und verfeinert seine Abfrage. Bsp: Master sendet 1 -> niemand meldet sich 2 -> niemand meldet sich 4 -> niemand meldet sich 8 -> Signal auf Bus -> zwischen 4 und 8 befindet sich mindestens 1 Client. +-> 6 -> niemand meldet sich +-> 7 -> Client Meldet sich 16 -> niemand meldet sich ( Nummer 7 meldet sich nicht auf Suchanfragen, weil bereits konfiguriert) 32 -> mindestens einer meldet sich -> zwischen 16 und 32 mindestens ein client +-> 24 mindestens einer meldet sich -> zwischen 16 und 24 mindestens ein client usw..... Damit kannst du auch große (z.B. 128 Bit) Addressräume relativ schnell durchsuchen.
:
Bearbeitet durch User
Dennis R. schrieb: > Der Master erkennt dann, dass es mindestens einen Klient gab und > verfeinert seine Abfrage. hi, Dennis Das was du da beschreibst machen wir hier auch so, nur wir benutzen hier eine zusätzliche Leitung dafür. Die Leitung kann von alles Slaves auf LOW gezogen werden. Damit können die Slaves bestimmte Zustände anzeigen. (Die Zustände können dann abgefragt werden(einzeln oder gesamt)) Wie verhinderst du, das bei dir mehrere Slaves antworten???
Stephan schrieb: > Wie verhinderst du, das bei dir mehrere Slaves antworten??? Das kann man lösen, indem man man die RS485 Transceiver durch CAN Transceiver ersetzt. Nur die Transceiver wohlgemerkt.
:
Bearbeitet durch User
ja ist klar. Aber UNSERE arbeiten hier mir RS485. Da kann ich nicht mal eben den BUS-Treiber tauschen. Sorry.
A. K. schrieb: > Stephan schrieb: >> Wie verhinderst du, das bei dir mehrere Slaves antworten??? > > Das kann man lösen, indem man man die RS485 Transceiver durch CAN > Transceiver ersetzt. Nur die Transceiver wohlgemerkt. Haha. Man kann übriggebliebene Gemüsesuppe raffiniert wieder aufwärmen, wenn man sich ein saftiges Steak dazu brät. Das ganze läßt sich noch weiter verfeinern, wenn man die Gemüsesuppe beim Servieren einfach wegläßt...
Markus F. schrieb: > Man kann übriggebliebene Gemüsesuppe raffiniert wieder aufwärmen, wenn > man sich ein saftiges Steak dazu brät. Das CAN Transceiver und CAN Controller zwei verschiedene Dinge sind, kommt dir nicht in den Sinn? Man kann eine UART mit RS232, RS485 oder CAN Transceivern betreiben. Letzteres erlaubt Arbitration, wie von Dennis beschrieben, unterscheidet sich im Bus aber nur wenig von RS485. Die ursprüngliche Fragestellung ergab nicht zwingend, dass es um eine bereits fast fertige und nicht mehr modifizierbare Lösung handelt.
:
Bearbeitet durch User
Das mehrere slaves gleichzeitig antworten kann man nicht verhindern. Aber man kann die Antwort so gestalten, dass sie vom Master erkannt wird Und es keine Probleme gibt wenn mehrere Clients gleichzeitig antworten In dem jeder client z.b. den Bus auf logisch 1 zieht.
Stephan schrieb: > Die Leitung kann von alles Slaves auf > LOW gezogen werden. So ähnlich haben wir das auch implementiert. Nur, dass diese Leitung als Signalisierung (AT-Signal)verwendet wird. D.h., wenn ein Slave senden will, dann schaut er ob AT belegt ist, wenn ja, dann wartet er 1us multipliziert mit seiner Adresse. Zeigt AT frei an, dann setzt er AT für die vorg. Zeit. Nimmt sie wieder weg und lauscht kurze Zeit, belegt dann die Leitung und tauscht die Daten mit dem Master(den es bei uns hier nicht in diesem Sinne gibt) oder einem anderen Teilnehmer. Die Adressen werden bei uns vor der Inbetriebnahme fest pro Teilnehmer eingestellt. Funktioniert super und ist 100% ohne Kollisionen. Das ist eine Lösung von vielen möglichen.
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.