Hallo
Ich bastel gerade an meinem Hausbus.
Grundlage ist rs485. Jeder Teilnehmer kann momentan die "Master" rolle
übernehmen.
Alles im format Absender Emfänger Länge Crc1 Daten crc2.
Z.b Lichtschalter(x) sendet bei betätigung an Lampe(x)
Und zwar ...
Fragt der Ls nach dem Status der Lampe
Diese antwortet mit status
Ls Inventiert den Status und sendet an lampe
Nun habe ich mich aber irgendwo in der Kommunikation Festgedacht
Ich mache das so kompliziert denn mir gehen einige mögliche
Fehlerquellen durch den Kopf.
z.b. Würde der Ls nur ein inventir signal an die Lampe senden, diese das
ausführt aber der Ls das ok nicht bekommt und nochmal sendet ist das
Licht wieder aus.
Ohne ok könnte es passieren das das Signal garnicht erst emfangen wird.
Soweit So gut
Nun möchte ich aber auch von einer zentralen Stelle z.b. vom PC alle
zustände Live ablesen können
Möglichkeit währe
- Alle x Sekunden alle Teilnehmer nach dem zustand fragen.- Könnte aber
den Bus unnötig belasten, Vorallem bei mehreren abfrage stellen.
- Alle Zustände bei Betätigung mitschreiben. - Aber was mit dem crc wem
send ich das ok ?
- Zentrale Steuerung - Möcht ich ungern da ein zentraler punkt zu einem
komplettausfall führen könnte.
Wie macht ihr sowas ? Helft mir doch mal bitte meinen "Hirnknoten" zu
lösen
Ich habe einmal was ueber ein arbiterloses RS485 system gelesen, das mit
timeouts funktionierte. Jeder teilnehmer hatte einen (eindeutigen)
timeout, und begann mit senden, wenn lange genug keine daten
vorbeikamen. Dies erforderte an jedem teilnehmer einen(vielleicht auch
mehrere) timer und die mussten auch jede meldung mitlesen, um den timer
mit dem telegrammende zu synchronisieren. Natuerlich loest das nicht den
aerger den man bekommt wenn stoerungen auf der Leitung sind, oder die
'babbling idiots'(zb durch nichteindeutige timeouts). Da geht mit
rs485 dann nix mehr.
Man sollte so einen Bus zustandsfrei betreiben. Ein command wie
"Invertiere-Zustand" ist eben nicht zustandsfrei. Solange man den bus
interaktiv steuert, ist das nicht so wichtig. Dann drueckt der Benutzer
den Taster eben nochmals. Solange das nicht zu haeufig geschieht, ist
das moeglicherweise akzeptierbar. Besser waere dass sich der Schalter
den Zustand merkt und das Command dann "Anschalten" oder "Abschalten"
bedeutet. Das waere auch vertraeglicher mit einer Automatisierung.
> Ausfallsichere Bus Komunikation rs485
geht so nicht !
jedes Device welches am RS485 hängt, kann diesen BUS verwenden und somit
auch stören und blockieren, auch ein schlecht verlegtes oder
beschädigtes Kabel kann den Bus lahmlegen.
Wenn du eine ausfallsichere Verbindung haben willst, musst du eine
Sternverkabelung mit einem redundanten Busmaster im Stern verwenden,
Dieser BusMaster muss dann gestörte Segmente erkennt und isolieren oder
durch kurzzeitiges abschalten der Versorgungsspannung des Segmentes,
dieses neu starten.
Habe so was mit Erfolg schon mal für ein I2C-Bus gebaut ...
Gruss Ralf
Du kannst auch ein MODBUS-Protokoll benutzen und einen Master als
Repetitor arbeiten lassen. Die Teilnehmer bekommen zudem per broadcast
eine keepalive-Information, die sie daran hindert, sich selber zu
resetten. Dazu muss der Master nur die time slots analysieren und die
Teilnehmer regelmässig anfunken. Die Teilnehmer brauchen dann eine
Schleife, mit der sie einen HW-Timer rücksetzen. Geschieht das nicht
erfolgt ein Reset. Senden darf nur, wer gefragt wird oder im aktuellen
ihm zu geordneten timeslot angefangen hat. Das Synchen geht ebenfalls
vom Master aus.
Die Sache funktioniert mit 60 Teilnehmern bei 1,2MHz über 4 Lanes.
@Dieter
Der "intelligente" Schalter ist - meiner Meinung nach - Overkill. Es
reicht doch, wenn der Schalter an alle Interessenten mitteilt, dass er
(Schalter) ein-/ausgeschaltet wurde, umgeschaltet wurde, (Taster)
gedrückt wurde, gedrückt wurde und gehalten wird oder losgelassen wurde.
Was geht es den Schalter an, welche Funktion mit ihm bedient werden
soll?
Wenn es nur einen Interessenten für die Mitteilung gibt, z.B. die Lampe
oder - besser - eine Zentrale, dann kann sich der Schalter die
Mitteilung auch quittieren lassen. Kommt die Quittung nicht innerhalb
weniger Millisekunden an, dann wird die Mitteilung bis zu ein paar mal
wiederholt. Packt man einen Sequenzzähler in die Mitteilung, kann der
Empfänger daran eine neue Mittteilung von einer Wiederholung
unterscheiden. Gelegentliche Kollisionen führen zu einer kaum merklichen
Verzögerung.
Kollisionen kommen zwar vor, sind aber sehr selten. Wieviele Leute
können vieviele Schalter gleichzeitig bedienen und warum sollten sie das
tun (außer um es mal auszuprobieren)? Das ist ein Hausbus, kein LAN!
Ein "dummer" Schalter, der nicht abgefragt werden kann, kann seinen
RS-485-Transceiver fast die ganze Zeit abschalten und Strom sparen. Da
kann man dann auch die billigen SN75176 einsetzen.
Das Kommunikationsprotokoll sollte ermöglichen:
Mehrere Schalter steuern die gleiche Lampe.
Ein Schalter steuert mehrere Lampen.
Die "Verdrahtung" ändern, ohne Firmware-Updates.
Hallo und Vielen dank für die Denkhilfe
Also eigentlich wollte ich "intelligente" Schalter um eine zentrale
Steuerstelle aufgrung der ausfallwarscheinlichkeit zu vermeiden.
Aber "old-school_offline" hat wohl recht, selbst ein einziger
ausgefallener Schalter könnte den Bus Blokieren. Somit klingt es jetzt
für mich logischer nacheinander alles abzufragen und
keepalive-Information zu senden.
Bleibt jetzt die frage bekomme ich alle Steuerverbindungen in einen
kleinen Avr?
Und wie Sortier ich das "Benutzerfreundlich"
Sternförmig vernetzen fällt aus da
-Die Leitungen schon liegen.
-Die Leitungen dann zu teuer werden
-Ich im Keller (oder wo auch immer) dann ja Hunderte leitungen bedienen
müsste ( Magst du Eventuell mal ein Bild von deinem Master Posten?)
Ansonsten sicher, solange der Master nicht ausfällt :)
Liebe Grüße
Dieter schrieb:> nacheinander alles abzufragen
Willst du Schalter abfragen? Halte ich für keine gute Idee. Damit bei
Schalterbetätigung eine prompte Reaktion der Lampe eintritt, müssten
alle Schalter in - sagen wir mal - 200ms abgefragt werden und die
Abfragen müssen permanent laufen. Folge ist, dass der Bus ausgelastet
ist und alle Controller unnötig aktiv sind.
Rechne mal überschlagsmäßig aus: Baudrate geteilt durch ( Anzahl der
abzufragenden Bus-Teilnehmer mal Länge der Mitteilung mal zwei
(Frage/Antwort) mal Anzahl der Bits pro Zeichen ).
Da sind jetzt noch keine Delays für z.B. Verarbeitungszeiten drin.
Bleibt da noch Luft für weitere Bus-Teilnehmer?
Wenn ein Schalter von sich aus eine Betätigung meldet und sich nach
Quittung wieder schlafen legt, dann gibt das einen Bus, der weitgehend
ruhig ist. Wenn es die Angst erfordert, dann kannst du den Schalter ja
jede Stunde mal ein Lebenszeichen senden lassen.
Meine Angst is schon gross nur weiß ich auch nicht ob das Begründet is.
Ich meine Wie oft stürzt denn ein Avr mit Watchdog wirklich so ab das er
den Bus stört ? Vermutlich eignetlich garnich ?
Wie haben andere das Problem Gelöst?
Es gibt doch sicher schon Hausbus Projekte auf rs 485?
Dieter schrieb:> Wie macht ihr sowas ? Helft mir doch mal bitte meinen "Hirnknoten" zu> lösen
Wie mit dem Deutschen Gesetz: Es ist erlaubt, was per Gesetzt nicht
verboten ist :-)
Damit meine ich das z.B. Lichtschalter vom Controller abgefragt werden,
und wenn Du das Licht "EIN"schaltest so wird sofort das Relais etc.
angezogen.
Per BUS wird dann zeitgleich mitgeteilt das die Lampe nun an ist. Sollte
der Master aber vorher zum Controller den Befehl gegeben haben "AUS" und
"Sperren" so kanst Du den Schalter betätigen wie Du willst, das Licht
bleibt aus (perfekt bei Kinderzimmer wenn dort Abends am Lichtschalter
gespielt wird).
So kommen nur Datebn auf wenn am Schalter hatiert wird oder wenn der
Master dem Schalter einen Befehl gibt.
Dieter schrieb:> Wie haben andere das Problem Gelöst?> Es gibt doch sicher schon Hausbus Projekte auf rs 485?
Massenhaft! Wenn du dich hier im Forum oder sonstwo zum Thema Hausbus
umsiehst, stellst du fest, dass so ziemlich jeder sein eigenes System
aufzieht, weil er bestimmte Vorstellungen verwirklichen will. Es gibt
nur wenige Gemeinschaftsprojekte. Für jede der fertig gewordenen,
funktionierenden Lösungen gibt es gute Gründe, es so und nicht anders zu
machen.
Leider beschreiben zu wenige Projekte die Gründe für ihre
Design-Entscheidungen. Schade, denn gerade dadurch könnte man viele
Fehler bei eigenen Entwurf vermeiden.
Helmut Lenzen schrieb:> Schalter direkt mit Lampe verbinden :=)
Zu einfach, also inakzeptabel! :-)
Ich geh' jetzt erstmal meine Kaffeemaschine booten.