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
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?
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.
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.
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.
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.
