Ich möchte um ein paar Geräte im Haus zu Steuren ein Bussystem
einsetzen. Im vom prinzip her sowie EIB, nur etwas schneller, und da EIB
als private Bastellei recht teuer ist, möchte ich das eben mit RS485 im
halbduplex aufbauen.
Jetzt mache ich mir gerade Gedanken über die Kollisionserkennung.
Sowas wie dieses CSMA/CD bei CAN und I2C ist bei RS485 ja nicht so ohne
weiteres Anwendbar?
Was für verfahren werden bei einem RS485 Bus der Multimasterfähig sein
soll denn so eingesetzt, bzw welche möglichekiten gibt es da?
Es geht ja speziell um den Fall, wenn 2 Master gleichzeitig anfangen
wollen zu senden.
Alles andere könnte man ja auch schon über das Protokoll mit absichern.
--
Gruß
Arne
Hmm, why not? Ein Sender haut einfach sein Datenpaket raus, liest selber mit
und vergleicht. Wenn das unterschiedlich ist -> BOING.
Ist aber nur so ne Idde.
Ausserdem, muss es denn wirklich Multimaster sein? Und wenn doch, dann
vielleicht mit nem Token?
--
MfG
Falk
Moment, habe ich jetzt etwas Flasch verstanden?
Das geht doch vom Prinzip her nicht, die Ausgangstreiber schalten doch
gegen + und -, nichts mit pullup, wie i2c. Bei CAN weiss ich jetzt nicht
genau, aber man nimmt doch dort aus diesem Grunde keine RS485 Treiber
oder? Wenn ich nun an einem Ende meiner 1200m langen Leitung einen
Master habe, der gleichzeitig mit dem Master an dem gegenüberliegenden
Ende der Leitung anfängt zu senden, dann bringt mir das Auslesen nichts,
den ich werde vermutlich das Richtige auslesen.
> Ist aber nur so ne Idde.
> Ausserdem, muss es denn wirklich Multimaster sein?
Hm, das ist flexibler, ich stelle mir wirklich so ein System auch zum
schalten das Lichtes usw. vor, jeder Taster kann dann autark - dezentral
agieren. Man kann dann im Keller das Licht für den Dachboden schalten.
Ok, man würde mich dann sicherlich schief anschauen wenn ich erkläre,
warum ein Softwareupdate notwendig ist, wenn das Licht im Wohnzimmer
nicht mehr geht, oder warum Strg+Alt+Enf bei flakerndem Licht hilft,
aber ...
> vielleicht mit nem Token?
Token?
hörte ich schon mal,
google....
Hm, ein Ringbus in dem Ständig etwas umherläuft?
"Der Plumssack geht rum", trifft es in etwa, wenn ich das jetzt
richtig verstnaden habe.
Wer den Token hat darf senden Ok,
das setzt voraus, das ich mein Netz so organisiere, das die Hardware die
Adressen von selbst bedingt, also doppelte Steckverbindungen an den
Geräten. So ein token kann ja verloren gehen, fällt eines der Geräte
aus, gibt es keinen Token mehr, es müsste ein Überwachungsmechanissmus
her, also eine art Zentrale. Gefällt mir nicht so sehr der Gedanke, ich
werde mal genauer drüber nachdenken.
--
Gruß
Arne
> So ein token kann ja verloren gehen, fällt eines der Geräte
> aus, gibt es keinen Token mehr, es müsste ein Überwachungsmechanissmus
> her, also eine art Zentrale. Gefällt mir nicht so sehr der Gedanke, ich
> werde mal genauer drüber nachdenken.
Schau Dir das alte Arcnet an. Das funktioniert mit Token ohne Zentrale an
einem Bus.
Siegfried
--
http://www.schmidt.ath.cx
Ich habe ein ähnliches Projekt in Arbeit.
RS485 ist super - einfach und schnell und preiswert.
Eib ist Sauteuer und komplex, aber ein Standard.
Ich lebe aber ganz gut mit dem Gefühl des Eigenbau.
Meine Prozess-Knoten sind Amtel's mit 8 Eingänge und 8 SSR.
Zu deiner Frage zu den Kollisionen habe ich folgendes implementiert:
1) Es gibt ein Tackt-Master der alle Clients rundum abfragt.
2) Jeder Client kann dann eine Msg. an den Master oder an alle senden.
Das Minimum ist eine Quitierung der Masterabfrage.
3) Der Master überprüft die Quittung und fordert im Fehlerfall den
selben
Client nochmals auf zum resend.
Vorteil meiner Lösung:
Es gibt keine Kollisionen.
Der Master hat eine übersicht über den Status der Clients.
Nachteil:
Mit steigender Clientzahl wird die Durchsatzrate pro Client kleiner.
Ist bei mir aber kein Problem, da ich mit 128 kBit fahre un nicht mehr
als 30 Cleints habe. Damit ist die Verzögerung eines Schalters der ein
Licht aufdrehen soll noch unmerklich.
Übrigens: Über den gleichen Chip fahre ich ich das gesamte Protokoll
und dimme
gleichzeitig 8 Triacs (SSR).
LG RT
Siegfried Schmidt <s-sc...@netcologne.de> wrote in message news:<6j152a...@shiva.my-fqdn.de>...