MoSteuS - Brainstorming

  • Zitat

    Die Bussysteme sollten deshalb getrennt sein, damit wenn eine Einheit dauerhaft iergendwelche daten über den HBUS sendet (z.B: Ausgangsänderungen bei Lauflichtern) nicht das Gesamtsystem blockiert ist, bzw mehrere dieser Lauflichteiheiten vorhanden sein können und
    untereinander über den externen Bus vernetzt sind und sich so z.B. synchronisieren können. (wenn man natürlich nur ein externes Bedienpult
    anschließt und der HBUS nicht dauerhaft ausgelastet ist, würde es auch mit einem Bussystem funktionieren, jedoch gibt es einige Gründe dies
    trotzdem nicht zu realisieren)

    Ich gehe davon aus, dass der Controller, wenn es sich um einen AVR handelt, bis zum Anschlag ausgelastet ist, wenn er Daten mit 2,5MHz über den HBUS schaufelt.
    Da sehe ich wenig Restpower, um noch einen zweiten Bus mit hoher Geschwindigkeit zu bedienen.
    Insofern dürfte es wurscht sein, ob man die Busse trennt oder alle Daten über einen einzigen Bus peitscht.


    Im Gegenteil: Die Software wird viel einfacher, wenn sie nur einen Bus bedienen muss.


    Wenn zwei Subsysteme ("Moduleinheiten") zum Einsatz kommen, also zwei getrennte HBUSse, die an sich autark z.B. irgendwelche Lauflichter ansteuern und sich lediglich per RS485 untereinander synchronisieren, dann können diese Synchronisationsdaten doch im Datenstrom vom ersten HBUS enthalten sein!?!?


    Den Flaschenhals sehe ich halt beim AVR.
    Wenn dessen UART, wie Pesi schon richtig feststellte, halt bei 2,5MHz seine Obergrenze hat, dann legt das halt die Obergrenze für den Datenstrom auf dem HBUS fest. Und damit ist der Controller praktisch ausgelastet, diese Datenmengen bereit zu stellen.
    Wo mehr benötigt wird, muss man die Aufgaben halt in autarke Subsysteme aufteilen, die sich lediglich untereinander synchronisieren.
    Und dafür werden nur so wenige Daten benötigt, dass man das problemlos im Traffic unterbringen kann.
    Lasse mich natürlich gerne korrigieren, falls Du gerade klügere Konzepte im Kopf hast, die ich nur noch nicht erfasse.


    Zitat

    Interessant ist, dass mein Bus-Connector-Modul dir zu teuer und zu aufwendig ist, du jedoch in jedes Modul einen HBUS-Dekoder einbauen willst.

    Bei "Bus-Connector-Modul" denke ich halt an ein eigenständiges Hutschienengehäuse, das ebenfalls wieder Motherboard und einen HBUS-Decoder beinhaltet ...
    Wenn Du aber mehr an eine im Modul befindliche Leiterplatte denkst, dann bin ich mit Dir.
    Im Hutschienenmodul sitzt halt immer die Grundplatine (ich nenne sie "Motherboard"), welche immer:
    a) Die Schnittstellenverbinder zur Außenwelt bereit stellt. Also steckbare Klemmleisten und so.
    b) Den aufgesteckten HBUS-Decoder enthält.
    c) Den Verbinder zum HBUS enthält (zweireihige Pfostenleiste, von unten bestückt).


    Darüber hinaus, können diverse Erweiterungsplatinen auf das Motherboard gesteckt werden, sofern dieses dafür ausgelegt ist.


    Grundlegender Aufbau:
    Das Motherboard enthält also die von unten bestückte, zweireihige Pfostenleiste, die in den HBUS-Verbinder eingesteckt wird, in dem Moment wo man das Hutschienenmodul auf die Schiene steckt.
    Neben dieser zweireihigen Pfostenleiste sitzt auf dem Motherboard ein Steckplatz, in den der HBUS-Decoder eingesteckt wird.
    Die Signale vom HBUS-Verbinder gehen also über den zweireihigen Pfostenverbinder auf dem Motherboard direkt zum Steckplatz des HBUS-Decoders.
    Dessen Ausgangssignale wiederum gehen über den selben Steckplatz wieder zum Motherboard, wo die Signale dann die Steuerleitungen der jeweiligen ICs auf dem Motherboard bedienen.


    Darüber hinaus können durchaus weitere, gesteckte Erweiterungskarten zum Einsatz kommen, wie z.B. ein Bus-Connector-"Modul".
    Aber das Wort "Modul" lassen wir in dem Zusammenhang lieber.
    Um Begriffsverwirrungen zu vermeiden, bezeichne ich die Platinen innerhalb eines Hutschienenmoduls nicht ebenfalls als "Modul".
    Wenn also der Begriff "Modul" fällt, sollte damit immer ein Hutschienenmodul gemeint sein, welches durchaus mehrere Platinen beinhalten kann, die dann aber halt "Erweiterungskarten" genannt werden sollten.
    Ich bin bei der Planung zuvor selbst dauernd durcheinandergekommen, mit den Hutschienen-Modulen, welche wiederum "Module beinhalten".


    Meine Sprachregelung also: Interne Karten heißen "Erweiterungen" oder "Erweiterungskarten".
    Bin offen für andere Vorschläge, aber eine Sprachkonvention muss her.


    Zitat

    Des weiteren würde ich wenn dierekt den Bus-Connector in den jeweiligen Hauptcontroller des HBUSes integrieren.

    Das würde ich im Normalfall ebenfalls tun, schon allein weil der Controller dann direkt darauf zugreifen kann und der Datenstrom nicht unnötigerweise über den HBUS geführt werden muss.


    Zitat

    (eventuell bei 3 Leitungen eine nur für den Steuerungspfad reservieren, damit bei einem Fehler (Kurzschluss/Überlast) nicht die gesammte einheit nicht mehr erreichbar ist.

    Das ist eine gute Idee. Wirft aber die Frage nach der Absicherung auf.
    Wenn alles aus einem einzigen Netzteil gespeist wird, müsste gewährleistet sein, dass im Falle eines Kurzschlusses an externer Peripherie nur die Lastsicherung durchbrät, die Spannungsversorgung der Module aber weiterhin gewährleistet ist.


    Man könnte den HBUS-Decodern, die ja die Spannungsregler für 5V und 3,3V enthalten, eingangsseitig je eine eigene Polyfuse spendieren.
    Aber die Sicherung für den Laststrom müsste entweder ganz außerhalb sitzen, oder man müsste ein eigenes Modul konstruieren, in welches der dicke Saft eingespeist wird und das praktisch nur 'ne Sicherung enthält und mehrere Ausgangsklemmen, von denen man abgehen kann, zu den Modulen, die eine eigene Klemme für die Einspeisung haben, sowie zu den Einspeisesteckern an beiden Enden des HBUSes.


    Zitat

    Die entscheidung zwischen Interrupt und Polling ist so eine Sache und ich würde mich da garnicht so dierekt festlegen. Würde beides vorsehen/integrieren (bedeutet 1-2 Leitungen für Interruptauswertung reservieren)

    Das ist ein wirklich schwieriges Thema, aber ich würde die ultimativ zeitkritischen Interrupt-Signale dann eher direkt dem Controller-Modul zuführen.
    Alle "normalen" Interrupts, die auch etwas Aufschub verdauen können, dann halt per Protokoll im RS485-Datenstrom untergebracht.


    Bei den externen Hausautomations-Teilnehmern geht das sowieso nicht anders.
    Da steht keine gesonderte Interrupt-Leitung zur Verfügung. Und eine Betätigung eines Lichttasters kann auch wie beschrieben per Zeitfenster gepollt werden.


    Wenn das so ausgelegt wird, dass die Reaktionszeit schnell genug ist, z.B 0,1s, merkt der Anwender davon nichts.


    Gut, wir gehen davon aus, dass der HBUS erstens der Hochgeschwindigkeits-Bus ist und in seiner Länge sowieso begrenzt.
    Dann könnte man tatsächlich eine Interrupt-Leitung auf dem HBUS vorsehen, die mit dem VCC-Pegel (12-24V) arbeitet, ergo recht robust gegen Störungen ist.
    Die meinetwegen auch über Optokoppler geht.
    Die Module ziehen dann per wired-OR die Kathode der Optokoppler-LED auf Masse, woraufhin der Controller bei nächster Gelegenheit die möglichen
    Interrupt-Quellen pollt.


    Alles was noch zeitkritischer ist, muss halt dem Controller-Modul direkt zugeführt werden.
    Ich glaube, dass ist eine sehr gesunde Kombination.

  • Posting war schon wieder über 10.000 Zeichen, hier die Fortsetzung:


    Zitat

    Zu der Adressverwaltung sollten wir uns dann mal noch näher gedanken zu machen, finde es schade dass die Daisy-Chain dann nur für die erstmalige Adressierung genutzt wird und danach nicht mehr.

    Man könnte sie auch noch für andere Zwecke nutzen, aber ich sehe gegenwärtig keine sinnvolle Anwendung mehr.
    Natürlich könnte man darüber Datenströme im Stil von Glediator und Pepes Platinen führen.
    Ich sehe nur nicht, woher der Controller die Power nehmen soll, sowas zusätzlich zum 2,5MHz-HBUS zu bedienen. Würde IMHO auch die HBUS-Decoder unnötig noch weiter verkomplizieren. Die sind ja ebenfalls voll ausgelastet, auf dem HBUS zu lauschen und sich die relevanten Datenhappen herauszugreifen und damit was zu machen. Wenn die nun im Normalbetrieb auch noch auf 'ner zweiten Schnittstelle lauchen sollen - Mannomann!


    Zitat

    Das mit den zeitversetzen Bits setzen könnte schwierig werden, dafür müssten die Controller sehr synchron laufen. Vorallem wenn du von mehr als 10 Modulen ausgehst sind das schon mehrere Byte, die nach etsprechender Spezifikation (mit Start und Stop-Bit oä.) übertragen werden müssen.

    Ja, dickes Ding!
    Das war so der erste Einfall, den ich äußerte. Tatsächlich muss ich mir das nochmal ansehen, wie das physikalisch aussieht, was der UART rausgibt und wie das dann auf den RS485-Leitungen aussieht. Möglicherweise geht das gar nicht.
    Bei Wired-OR würde das ganz leicht gehen, aber bei RS232 vom UART auf RS485?


    Zitat

    HBUS-Belegung
    - VCC für Steuerung
    - 2x VCC für Lastteil
    - 3x GND
    - 4 Leitungen für den eigentlichen Bus
    - 2 reserviert für Interrupts oder Poolinganfragen (wenn die Leitung auf Masse liegt, werden alle relevanten Module gepoolt)

    Streichen wir eines der beiden letztgenannten Signale, würde ich sagen.
    Lass uns mit nur einem Interrupt-Signal arbeiten.
    Wir müssen aber auch noch eine Reset-Leitung vorsehen.


    Ich schrieb früher, ich wolle ZWEI Reset-Leitungen vorsehen:
    1) Eine globale Reset-Leitung, die das ganze System im Reset hält - sowohl den Controller, als auch alle Module.
    2) Eine zweite Reset-Leitung, die vom Controller bedient wird, damit dieser alle Module blitzschnell clearen kann.


    Habe inzwischen eine bessere Idee, die mit nur einer Reset-Leitung auskommt.
    Sieht so aus, dass wenn der Controller resettet wird (z.B. beim Flashen), seine Ausgänge also in den Tristate gehen, durch eine Beschaltung automatisch auch die Reset-Leitung zu den Modulen aktiv wird.


    So beschaltet, sind wir weiterhin bei 12 verwendeten Signalen.
    Haben wir also noch immer zwei zu vergeben! :)


    Ein Signal wüsste ich noch:
    Ein Output-Enable-Signal.
    Damit könnte der Controller entsprechend designte Module direkt (also ohne jeden Protokollkram) zb. PWMmen.
    Ist nur laut gedacht und bei geschickt konstruierten Modulen wohl auch überfüssig.
    Bin gespannt auf Deine Vorschläge, für die letzten beiden Signale!


    Zitat

    Die Adressierung würde ich so machen, dass der Hauptcontroller eine feste Adresse hat (wenn jeder Hauptcontroller die gleiche HBUS Adresse hat ist man beim Austausch der Module sehr flexibel).

    Ja, der soll immer Adresse Null haben.
    Muss man nochmal überlegen, wie man damit umgeht, wenn man zwei Subsysteme hat, also zwei getrennte Hutschienen, mit jeweils eigenem Controller und diese Controller per RS485 untereinander kommunizieren.


    Zitat

    Wenn ein Modul auf den Bus aufgesteckt wird, meldet es sich bei genau dieser Adresse (das neue Modul ist in diesem Fall der Master, der Hauptcontroller der Slave) und teilt dem Hauptcontroller mit um was für ein Modul es sich handelt und bekommt im Anschluss von dem Hauptkontroller eine Adresse übermittelt.

    Frage: Gehst Du davon aus, dass es im laufenden Betrieb hinzugesteckt wird?
    - Ich nicht. Obwohl ich es gut fände, wenn das ginge.
    Aber die Pfostenleiste zum HBUS-Verbinder hat keine voreilenden Kontakte.
    Daher ist es gefährlich, unter Spannung ein Modul zu stecken oder zu ziehen.


    Zitat

    Ob diese Adresse auch bei Spannungsausfall im Modul gespeichert werden soll oder zurückgesetzt wird wäre zu überlegen bzw kann das während der Programmierung eingestellt werden. (bietet beides vor und Nachteile, bei der Speicherung benötigt das Modul dann jedoch so ein schönen RESET-Taster um die Adresse zu löschen)

    Meinen Ansatz dafür beschrieb ich schon: Nur der Controller hat diese Initialisierungstaste.
    Die drückt man einmalig bei der ersten Inbetriebnahme. Im Zuge der Initialisierung speichert jedes Modul die ihm zugewiesenen Adressen (durchaus mehrere pro Modul).


    Dadurch kann man anschließend, zu Testzwecken, die Module auf der Schiene vertauschen - sie behalten ihre Adresse und ihre Funktion.


    Erst wenn eine neue Initialisierung ausgelöst wird, per Tastendruck am Controller-Modul, wird der Bus neu initialisiert, wobei die Module neue Adressen erhalten.
    Das ist sehr praktisch, wenn man mehrere identische Module auf der Schiene hat.
    So kann man die vertauschen, wahlweise unter Beibehaltung ihrer Funktion, oder unter Vertauschung ihrer Funktionalitäten.


    Typische Anwendung:
    Z.B. zwei identische Module, die Lampen ansteuern. Modul A steuert über SSRs Lichtleisten an, Modul B über SSRs Scheinwerfer.
    Irgendwas "zickt" und man möchte wissen, ob eines der Module defekt ist. Also testweise vertauschen.


    Will man nicht, dass Modul A nun das Scheinwerferprogramm abspult und B das Lichtleistenprogramm, löst man eine neue Initialisierung aus.
    Will man die Vertauschung aber, weil man auch die Stecker umsteckt, dann unterlässt man die Neuinitialisierung.


    Das Einzige was gewährleistet sein muss, ist das bei jeder Initialisierung eine lückelose Kette besteht, wegen der Daisy-Chains.
    Aber ist die Initialisierung erfolgt, kann man anschließend auch Module aus dem Verbund entfernen. Die fehlen dann halt, aber der Rest läuft wie
    gehabt.

  • So ich habe mir in den letzten Tagen auch noch ein paar Gedanken gemacht.


    • Alle Busse sind "gleich", also jeder Bus, egal welche Ebene, wird mit UART über RS485 realisiert. (wie du bereits angemerkt hattest)
    • Jeder Bus besteht aus einem Buscontroller (soweit waren wir ja schon). Dieser Buscontroller dient zu Adressverwaltung auf dem Bus und kann über eine weitere Schnittstelle die Verbindung zu einem übergeordneten Bus herstellen.
    • Die Struktur des Busses ist beliebig, die Busse können also, zumindest theoretisch, beliebig verschachtelt werden.


    Eine Datenübermittlung könnte so aussehen (wobei die Daten auch mehrere Byte groß sein könnten):

    • Bus belegt
    • Adresse
    • Befehl
    • Daten
    • Antwort vom anderen Modul
    • Bus ist frei

    Ablauf der Adressierung


    • Modul wird angeschlossen und der Controller startet/ das Modul bekommt über Dasy-Chain die Position (bei der Hausinstallation muss noch eine andere Lösung her)
    • Das Modul wartet bis der Bus frei ist
    • Anschließend meldet es sich beim Buscontroller mit seiner Position und dem Modultyp
    • Darauf vergibt der Buscontroller eine Adresse für das Modul


    Vorschlag Adressanfrage:


    • Bus belegt
    • Adresse des Busconnectors
    • Adressanforderung
    • Modultyp
    • Position
    • (wechsel der Kommunikationsrichtung, ab jetzt sendet der Buscontroller)
    • Adresse des Moduls
    • Bus ist frei


    Probleme und zu klärende Fragen:

    • Soll die Funktion eines Moduls von seiner Position abhängen oder immer fest sein (Hast du ja schon mit positionsabhängig beantwortet, wobei es bei mir wohl eher Typabhängig wäre, bzw fest eingestellt, aber das sind ja auch nur kleine Anpassungen im Programm)
    • wäre die Adressvergabe bei verschachtelten Bussen interessant, entweder die Adressen sind nur innerhalb des Busses gültig (würde ich bevorzugen, zugriff aus übergeordnenten Bussen dann über bestimmte Befehle an den Buscontroller) oder die Adressen sind im gesammten System gültig, jede Adresse nur einmal vorhanden. (Sehr aufwändig, unterschiedliche Adressen für die Busconnecter)
    • Wie werden kollisionen auf dem Bus erkannt/verhindert? Überlegung: Der Anfang der Übertragung wird mit "Bus belegt" gekennzeichnet und das Ende mit "Bus frei". (Verhindert schon mal einen Großteil der Kollisionen, jedoch nicht, wenn 2 Module gleichzeitig anfangen zu senden)
    • Welchen Pegel haben wir auf dem RS485 Bus
    • Bräuchten wir einen Namen für unseren Bus
  • Irrlicht
    Nun zu deinen letzten Posts

    Zitat

    Ich gehe davon aus, dass der Controller, wenn es sich um einen AVR handelt, bis zum Anschlag ausgelastet ist, wenn er Daten mit 2,5MHz über den HBUS schaufelt.
    Da sehe ich wenig Restpower, um noch einen zweiten Bus mit hoher Geschwindigkeit zu bedienen.
    Insofern dürfte es wurscht sein, ob man die Busse trennt oder alle Daten über einen einzigen Bus peitscht.

    • Ja da wäre dann wirklich wenig Restleistung, deshalb würde ich dafür auch nicht gerade einen ausgelasteten Controller wählen
    • Alternativ kann man ja auch einen Controller mit mehr Rechenleistung nehmen
    • Das mit dem trennen/zusammenfügen ist dann jedem selber überlassen (was auch die flexibilität erhöht)
    Zitat

    ... dann können diese Synchronisationsdaten doch im Datenstrom vom ersten HBUS enthalten sein!?!?

    Das ist sicherlich möglich (einfach den 2.HBUS über einen Busconnector an den ersten hängen), jedoch muss dann der Controller auf dem 2. Bus den gesammten Verkehr auf dem ersten Bus mitlauschen

    Zitat

    Wenn dessen UART, wie Pesi schon richtig feststellte, halt bei 2,5MHz seine Obergrenze hat, dann legt das halt die Obergrenze für den Datenstrom auf dem HBUS fest. Und damit ist der Controller praktisch ausgelastet, diese Datenmengen bereit zu stellen.

    • Habe gerade mal nach geschaut, die 2,5MBaud sind wirklich das absolute Maximum, das z.B. ein ATmega168 schafft (wären aber auch schon 40000 Lampen bei 25fps) Das Problem ist nur, dass die AVRs in diesem Bereich mit mindestens 4,5V versorgt werden wollen (20MHz Takt, bei 3V wären es nur 10MHz und somit maximal 1,25MBaud)
    • Zur Bereitstellung des Bytes hätte der AVR ca 80 Cyklen (8 pro Bit * 10 für 8xDaten + Start + Stop)
    • Es kommt natürlich darauf an, wie er diese Daten bereitstellen muss, einlesen über SPI von einem Speichermedium sollte sicher möglich sein. Auch einfache Bit-Schiebe-Operationen für Lauflichter sollten nicht sonderlich schwehr sein. Und über einen kurzen Zeitraum oder bei sich schnell wiederholenden Mustern kann auch der interne Speicher ausreichen
    Zitat

    Im Hutschienenmodul sitzt halt immer die Grundplatine (ich nenne sie "Motherboard"), welche immer:
    a) Die Schnittstellenverbinder zur Außenwelt bereit stellt. Also steckbare Klemmleisten und so.
    b) Den aufgesteckten HBUS-Decoder enthält.
    c) Den Verbinder zum HBUS enthält (zweireihige Pfostenleiste, von unten bestückt).

    a und c sind klar, aber das mit dem HBUS-Decoder hab ich noch nicht so ganz verstanden. Klar die daten vom RS485 müssen iergendwie zu den Kontrollern auf den Karten im Modul, aber da reicht doch auch ein einfacher MAX485 und schon hast du nen UART?!

    Zitat

    Wenn also der Begriff "Modul" fällt, sollte damit immer ein Hutschienenmodul gemeint sein, welches durchaus mehrere Platinen beinhalten kann, die dann aber halt "Erweiterungskarten" genannt werden sollten.

    Gute Idee, wende ich bereits an ( Karte und Modul)

    Zitat

    Wenn alles aus einem einzigen Netzteil gespeist wird, müsste gewährleistet sein, dass im Falle eines Kurzschlusses an externer Peripherie nur die Lastsicherung durchbrät, die Spannungsversorgung der Module aber weiterhin gewährleistet ist.

    Einfach ein Einspeisemodul bauen, in dem die Sicherungen für die Leitungen sitzen. Bei Kritischen Modulen kann intern auch noch eine seperate Sicherung vorgesehen werden.

    Zitat

    Die entscheidung zwischen Interrupt und Polling ist so eine Sache und Das ist ein wirklich schwieriges Thema, aber ich würde die ultimativ zeitkritischen Interrupt-Signale dann eher direkt dem Controller-Modul zuführen.
    Alle "normalen" Interrupts, die auch etwas Aufschub verdauen können, dann halt per Protokoll im RS485-Datenstrom untergebracht.

    Die Frage wäre sowieso wann solche Interrupts auftreten und wie zeitkritisch sie dann sind. Wenn man Sicherstell, dass der Bus alle paar 100ms mal frei ist dann sollte das auch ausreichend sein. Alternativ müssen die Karten so kombiniert werden, dass die Interrupts in dem Modul ausgewertet werden, in dem sie entstehen. (Auslösende und auswertende Karte in einem Modul unterbringen)

    Zitat

    Ja, dickes Ding!
    Das war so der erste Einfall, den ich äußerte. Tatsächlich muss ich mir das nochmal ansehen, wie das physikalisch aussieht, was der UART rausgibt und wie das dann auf den RS485-Leitungen aussieht. Möglicherweise geht das gar nicht.
    Bei Wired-OR würde das ganz leicht gehen, aber bei RS232 vom UART auf RS485?

    Entweder jedes Modul/jede Karte einzel poolen oder die Module selber senden lassen und zwar alle einzeln.

    Zitat

    Streichen wir eines der beiden letztgenannten Signale, würde ich sagen.
    Lass uns mit nur einem Interrupt-Signal arbeiten.
    Wir müssen aber auch noch eine Reset-Leitung vorsehen.

    Zitat

    Ein Signal wüsste ich noch:
    Ein Output-Enable-Signal.

    Wobei Output Enable bei bestimmten Modulen auch gewisse Ausgänge aktivieren könnte, für Beleuchtungsaktivierung im Notfall oä. (möglicherweise auch dierekt manuell bedienbar?)


    Neue Belegung (11 Pole belegt):

    • 1x Vcc für Steuerung
    • 2x Vcc für Lastteil
    • 3x Gnd
    • 2x RS485 (Multimaster)
    • 1x Interrupt (wenn benötigt)
    • 1x Modulreset
    • 1x Output enable/disable
    Zitat

    Muss man nochmal überlegen, wie man damit umgeht, wenn man zwei
    Subsysteme hat, also zwei getrennte Hutschienen, mit jeweils eigenem
    Controller und diese Controller per RS485 untereinander kommunizieren.

    Auf dem dem übergeordneten Bus sind sie einfach nur "normale" Module und haben somit auch von dem dortigen Buscontroller eigene Adressen zugewiesen bekommen.

    Zitat

    Frage: Gehst Du davon aus, dass es im laufenden Betrieb hinzugesteckt wird?


    - Ich nicht. Obwohl ich es gut fände, wenn das ginge.

    War Anfangs davon ausgegangen, dass man das ja machen könnte. Aber selbst wenn man das nicht kann, ist es für das Modul kein unterschied, denn iergnedwann bekommt es Sannung und muss sich eine Adresse besorgen.

  • 2,5MBaud sind wirklich das absolute Maximum, das z.B. ein ATmega168 schafft (wären aber auch schon 40000 Lampen bei 25fps)

    Die Rechnung verstehe ich nicht ganz:


    2,5 Mbit sind ja dann 250.000 Byte/Sek (weil ein Byte 10 Bit braucht inkl. Start- und Stopbit) - durch 25 fps macht dann 10.000 Byte/Frame...


    also bei 1 Byte pro Lampe dann 10.000 Lampen - oder wenn man die nur ein- und ausschalten können muss, hat man ja pro Byte 8 Lampen, also dann sogar 80.000... ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Zu 1.)
    Habe ich hier beschrieben:
    MoSteuS – der HBUS


    Also sowohl positionsabhängig, als auch nicht ...
    Nachdem die Initialisierung jedem Modul seine Erstadresse über die Daisy-Chain zugewiesen hat und anschließend, per RS485 alle weiteren Adressen (jedas Modul kann auf mehrere Adressen gelegt werden - sinnvoll für Gruppenfunktionen) sowie Funktionalitäten, speichert jedes Modul diese Parameter im EEPROM des eigenen HBUS-Decoders ab.
    Fortan können die Module auf dem Bus beliebig vertauscht werden, behalten aber ihre Adresse und Funktion.


    Erst wenn man per Taster am Controller eine neue Initialisierung erzwingt, werden die Module in der aktuellen Reihenfolge neu durchnummeriert (adressiert).



    Zu 2.)
    Idee: Jeder weitere Bus ist aus Sicht des Hauptcontrollers ein einziges (halt sehr komplexes) Modul.
    Nur müssen wir da die automatische Adresszuweisung per Daisy-Cahin knicken, weil zweischen den Bussen u.U. dutzende Meter Leitung liegen. Ein zweiter Bus muss also eine fixe Adresse erhalten, die im dortigen Controller in der Software abgelegt wird, um DIP-Schalter zu vermeiden.



    Zu 3.)
    Dazu schreibe ich später noch was. Bin noch am Editieren.



    Zu 4.)
    Würde sagen 5V.
    Auf dem HBUS-Decoder sitzt sowieso der 5V-Spannungsregler und der AVR, der notgedrungen mit 5V laufen muss (wegen der 2,5MHz auf dem Bus, was 20MHz Taktfrequenz erfordert).
    Auch wenn andere ICs im Modul mit 3,3V arbeiten (auch der 3,3V-Spannungsregler sitzt auf der Platine vom HBUS-Decoder), werden 3,3V-Signale gegebenenfalls per Level-Shifter an das 5V-Niveau des HBUS-Decoders angepasst.



    Zu 5.)
    Also ich nenne es die ganze Zeit einfach HBUS, was die elektrische Seite betrifft.
    Die Firmware für die HBUS-Decoder, also den ganzen Protokollkram, würde ich genauso nennen, wie das System: MoSteuS.


    Der HBUS-Decoder wird mehrere Fähigkeiten haben und im Laufe der Zeit werden immer weitere Fähigkeiten hinzukommen.
    Das wird dann so aussehen , dass ein Shop, der die HBUS-Decoder-Platinen mit geflashtem AVR anbietet, bei den Spezifikationen angibt:
    "Unterstützt MoSteuS 1.0 bis 2.3".
    In einer Tabelle wird dann nachzulesen sein, was das bedeutet.


    Hintergrund: Die HBUS-Decoder sollen stets einheitliche Hardware beinhalten, keine DIP-Schalter und stets identische Software.
    Konstruiert nun jemand ein Modul, das erweiterte Software-Fähigkeiten seitens des HBUS-Decoders benötigt, wird diese Fähigkeit in die offzizielle Firmware implementiert.
    Jede weitere Fähigkeit belegt nur ein paar Zeilen Quelltext, da ist in 'nem kelinen AVR also richtig viel Platz für "noch und nöcher" exotische Module.
    Mit etwa 10 Fähigkeiten erschlägt man nämlich schon die allermeisten Problemstellungen.


    Ich werde dazu später noch was schreiben.



    Zitat
    Im Hutschienenmodul sitzt halt immer die Grundplatine (ich nenne sie "Motherboard"), welche immer:
    a) Die Schnittstellenverbinder zur Außenwelt bereit stellt. Also steckbare Klemmleisten und so.
    b) Den aufgesteckten HBUS-Decoder enthält.
    c) Den Verbinder zum HBUS enthält (zweireihige Pfostenleiste, von unten bestückt).


    a und c sind klar, aber das mit dem HBUS-Decoder hab ich noch nicht so ganz verstanden. Klar die daten vom RS485 müssen iergendwie zu den Kontrollern auf den Karten im Modul, aber da reicht doch auch ein einfacher MAX485 und schon hast du nen UART?!

    Der HBUS-Decoder tut 'ne ganze Menge.
    Er entlastet den Anwender komplett von dem ganzen Protokollkram. Darum kümmert sich der Decoder, wie ein Standard-IC mit fixer Funktion.
    Wer ein neues Modul entwickeln will, muss daher hardwareseitig einfach die entsprechenden Leitungen des HBUS-Decoders anrouten und es passt.
    Im schlimmsten Fall muss der Entwickler softwareseitig noch eine Lib bereit stellen, die ins Programm vom Hauptcontroller includet wird, damit er dieser Fähigkeiten des neuen Moduls auch kennt.
    Aber die Hardware der Decoder ist halt immer identisch, auch deren Firmware (davon abgesehen, dass es Upgrades geben kann und wird).


    Jede neue Fähigkeit wird in der Firmware der Decoder einfach hinzugefügt.
    War die bisher aktuelle Firmware z.B. die Version "MoSteuS 1.8" und kommt eine neue Fähigkeit hinzu, wird diese die neue Firmware halt "MoSteuS 1.9" heißen, was zum Ausdruck bringt, dass genau eine neue Fähigkeit hinzugekommen ist (die Zahl hinter dem Punkt).



    Öh, letzter Stand war doch der, dass wir Vierdraht vorsehen, für RS485!?!


    Über die Sache mit Multimaster (Zweidraht) s. Vollduplex (Vierdraht) müssen wir nochmal reden, auch wenn darüber schon sehr viel diskutiert wurde.
    Späteres Posting ...



    Zitat
    Muss man nochmal überlegen, wie man damit umgeht, wenn man zwei
    Subsysteme hat, also zwei getrennte Hutschienen, mit jeweils eigenem
    Controller und diese Controller per RS485 untereinander kommunizieren.


    Auf dem dem übergeordneten Bus sind sie einfach nur "normale" Module und haben somit auch von dem dortigen Buscontroller eigene Adressen zugewiesen bekommen.

    Ja.
    Und jede weitere Hutschiene ist aus Sicht des Hauptcontrollers halt ein (komplexes) Modul, insofern, als dass die ganze Schiene eine eigene Adresse bekommt, die der Hauptcontroller anspricht.
    Innerhalb der zweiten Hutschiene läuft dann wieder ein eigener Adressbereich von 1 bis 255, sowie 0 für den dortigen Controller (auch wenn er aus der Ferne, vom Hauptcontroller, mittels einer anderen Adresse angesteuert wird. Auf dem eigenen Bus hat er immer 0.).



    Wir müssen nochwas klären, bezüglich Interrupt und Konfliktvermeidung. Dazu nachher mehr ...

  • Hallo Irrlicht

    Idee: Jeder weitere Bus ist aus Sicht des Hauptcontrollers ein einziges (halt sehr komplexes) Modul.


    Nur müssen wir da die automatische Adresszuweisung per Daisy-Cahin
    knicken, weil zweischen den Bussen u.U. dutzende Meter Leitung liegen.
    Ein zweiter Bus muss also eine fixe Adresse erhalten, die im dortigen
    Controller in der Software abgelegt wird, um DIP-Schalter zu vermeiden.

    bei der Idee stimme ich mit dir überein. Bei der Adresszuweisung entsteht dann hal das Problem, was bei allen Hausinstallationen auftreten wird, die Lokalisierung. Jedoch muss das Verbindungsmodul nicht zwangsweise eine feste Adresse haben, die Zuweisung an sich kann ja auch wie auf dem HBUS funktionieren, nur dass der Modultyp/die Position entsprechend eingestellt werden müssen (im Code). Oder aus den angeschlossenen Modulen wird ein neuer Typ-Code generiert.

    Also ich nenne es die ganze Zeit einfach HBUS, was die elektrische Seite betrifft.


    Die Firmware für die HBUS-Decoder, also den ganzen Protokollkram, würde ich genauso nennen, wie das System: MoSteuS.

    Die Bezeichnung HBUS kommt doch von deinen Verbindungsstecker. Wahrscheinlich habe ich mich unglücklich ausgedrückt, meinte eine Bezeichnung für das Bussystem über das externe Komponenten angeschlossen werden bzw das was minimal vorhanden sein muss (2x Signal, Vcc, Gnd) und das dazu gehörende Protokoll (was natürlich dann auch auf dem HBUS läuft. Des weiteren könnte es bei der Vermarktung unter dem Namen HBUS ja dann probleme geben, wenn die Bezeichnung auf dne Hersteller der Gehäuse eingetragen ist.

    Der HBUS-Decoder tut 'ne ganze Menge.


    Er entlastet den Anwender komplett von dem ganzen Protokollkram. Darum
    kümmert sich der Decoder, wie ein Standard-IC mit fixer Funktion.


    Wer ein neues Modul entwickeln will, muss daher hardwareseitig einfach
    die entsprechenden Leitungen des HBUS-Decoders anrouten und es passt.


    Aus dem Teil mit den HBUS-Decodern halte ich mich wohl erst einmal raus. Weil:

    • Ich bei der Hausautomatisierung eher dezentrale Komponenten einsetze
    • Ich die meisten Module selber entwickeln werde und nicht weis, ob ich die HBUS-Verbinder einsetze
    • Ich da erst einmal einen Prototypen abwarten werde. Verstehe zwar was du vor hast, kann mir das aber in Bezug auf den HBUS-Decoder noch nicht so ganz vorstellen.

    Öh, letzter Stand war doch der, dass wir Vierdraht vorsehen, für RS485!?!

    Bei 4-Draht RS485 ist aber kein Multimaster-Betrieb möglich. Multimaster-Betrieb bedeutet, dass jeder Teilnehmer von sich aus mit den anderen Kontakt aufnehmen kann. Es kann also jedes Modul an jedes andere Modul Daten senden.


    Beispiel:
    Modul A - Buscontroller
    Modul B - Lauflichtmodul
    Modul C - Ausgabemodul


    Ablauf der Lauflichtdatenübertragung vom Lauflichtmodul zum Ausgabemodul
    Version 1 - 1 Master (der Buscontroller ist Master)

    • Modul A fragt bei Modul B an ob Daten zu übertragen sind
    • Modul B bejat das
    • Modul A ruft die Daten ab, die für Modul C bestimmt sind
    • Modul A beendet die Verbindung
    • Modul A baut eine Verbindung mit Modul C auf
    • Modul A sendet die Daten an Modul C
    • Modul C bestätigt diese und gibt sie aus
    • Nun kann Modul A dem Modul B bestätigen, dass Modul C die Daten erhalten hat.

    Version 2 - Multimaster-Betrieb

    • Modul B hat Daten für Modul C
    • Modul B wartet bis der Bus frei ist
    • Modul B überträgt die Daten an Modul C
    • Modul C bestätigt den Empfang und gibt die Daten aus

    Ich hoffe, dass das mit dem Multimaster jetzt für dich besser verständlich ist. Natürlich ist bei 3 Modulen der Bus noch recht überschaubar, bei 3 Lauflichtmodulen, 6 Ausgabe Modulen und einem Buscontroller sieht das aber schon anders aus, wenn alle Daten doppelt versendet werden müssen (erst zum Buscontroller und dann von dort zum jeweiligen Modul)

    Zitat

    Wir müssen nochwas klären, bezüglich Interrupt und Konfliktvermeidung.

    Was mir gerade noch für das Vermeiden von Konflikten einfällt, wäre das abfragen ob der Bus in den letzen x ms (oder ns) einen Flankenwechsel hatte.

  • Jedoch muss das Verbindungsmodul nicht zwangsweise eine feste Adresse haben, die Zuweisung an sich kann ja auch wie auf dem HBUS funktionieren, nur dass der Modultyp/die Position entsprechend eingestellt werden müssen (im Code). Oder aus den angeschlossenen Modulen wird ein neuer Typ-Code generiert.

    Also wenn der zweite HBUS ohne eigenem Controller daher kommt, sondern einfach 'ne zweite Hutschiene ist, dann kann man einfach alle Signale vom Ersten HBUS an die zweite Schiene weiterreichen und dann unter Beibehaltung der Daisy-Chain jedes Modul auf der zweiten Schiene wie gehabt ansteuern.
    Das geht aber nur über relativ geringe Entfernungen, wenn man nicht auch noch die Daisy-Chains mit RS485 ausstatten will.
    Alternativ: auf jeder Schiene ein Modul, das die Daisy-Chain-Kommunikaton zu einer anderen Schiene per RS485 vornimmt. Dann kann die Strippe praktisch beliebig lang werden.


    Wenn auf der zweiten Schiene aber ein eigener Controller zum Einsatz kommt, der wiederum Herr in seinem "HBUS-Universum" ist, das wiederum bis zu 255 Module neben dem Controller erlaubt, dann muss jeder dieser Controller eine eigene Adresse haben, die im Adressraum des ersten Controllers enthalten sein muss.
    Die kann der erste aber nur dann per Daisy-Chain zuweisen, wenn man eine entsprechend vieladrige Strippe zwischen beiden Schienen vorsieht.
    Will man beide Schienen lediglich per Zweidraht- oder Vierdraht-RS485 abwickeln, dann muss der zweite, dritte, vierte ... Controller eine fixe Adresse bekommen, weil sie (mangels Daisy) anders nicht vom Hauptcontroller zugewiesen werden kann.


    Deinen letzten Satz verstehe ich nicht, kannst Du den bitte erläutern?



    Wahrscheinlich habe ich mich unglücklich ausgedrückt, meinte eine Bezeichnung für das Bussystem über das externe Komponenten angeschlossen werden bzw das was minimal vorhanden sein muss (2x Signal, Vcc, Gnd)

    Ach so.
    Öh, extern kann sonstwas angeschlossen sein.
    Das fällt irgendwie gar nicht in meinen Zuständigkeitsbereich, wenn man es so sagen will. Passendes Modul und fertig.


    Wer KNX-Nodes anschließen will, setzt halt ein KNX-Modul auf die Schiene und geht von da aus per Kabel zu den externen Nodes.



    Des weiteren könnte es bei der Vermarktung unter dem Namen HBUS ja dann probleme geben, wenn die Bezeichnung auf dne Hersteller der Gehäuse eingetragen ist.

    Na, ich glaube Phönix wäre sehr daran interessiert, dass man deren Kind auch so benennt, wie es heißt.
    Immerhin pusht dieses Projekt deren Produktbekanntheit und den Umsatz erheblich.



    Ich hoffe, dass das mit dem Multimaster jetzt für dich besser verständlich ist. Natürlich ist bei 3 Modulen der Bus noch recht überschaubar, bei 3 Lauflichtmodulen, 6 Ausgabe Modulen und einem Buscontroller sieht das aber schon anders aus, wenn alle Daten doppelt versendet werden müssen (erst zum Buscontroller und dann von dort zum jeweiligen Modul)

    Ja, ist absolut verständlich.
    Aber das doppelte Versenden sorgt ja kaum für mehr Traffic, bei Vierdraht.
    Die Daten von den Modulen zum Controller laufen über zwei Signalleitungen (nennen wir sie c & d).
    Der Controller sendet Daten, die für ein anderes Modul bestimmt sind, dann über die Signalleitungen a & b zu dem jeweiligen Zielmodul.
    Da wir bei Vierdraht Vollduplex fahren, erhöht sich nicht der Durchsatz auf einem Leitungspaar, gegenüber der multimasterfähingen Zweidraht-Version.



    Was mir gerade noch für das Vermeiden von Konflikten einfällt, wäre das abfragen ob der Bus in den letzen x ms (oder ns) einen Flankenwechsel hatte.

    Also Konflikte soll es überhaupt nicht geben können.
    Dazu knabbere ich nur noch an einem Punkt:
    Neulich schrieb ich, jedes Modul solle in einem Zeitfenster Daten senden dürfen, und zwar zunächst ein einziges Bit, das nur signalisiert, dass es was zu melden gibt.


    Das mit dem "einen Bit" wird wohl nicht hinhauen.
    Aktuell denke ich eher daran, dass es ein ganzes Byte sendet, und zwar seine eigene, bei der Initialisierung zugewiesene Adresse, WENN es etwas mitzuteilen hat.
    Wenn es nichts mitzuteilen hat, sendet es &h00.


    Damit nicht dauernd gepollt werden muss, sondern nur dann, wenn Bedarf dazu besteht, sollen alle Module jederzeit ein bestimmtes (Interrupt-)Signal senden dürfen.
    Was auf jeden Fall klappt, wäre ein Wired-OR, das von einem Modul, das etwas mitteilen möchte, zunächst auf GND gezogen wird.
    Daraufhin startet der Controller ein intelligentes Polling.


    Nur möchte ich gerne diese gesonderte Leitung mit dem Wired-OR weg haben.
    Bei Vierdraht haben wir ja zwei Leitungen, die zum RXD des Controllers führen, mit RS485.
    Es wäre schick, das auszunutzen.


    Meine noch ungare Idee:
    Der Bus von den Modulen zum Controller ist im Ruhezustand hochohmig.
    Will ein Modul was mitteilen, hebt es die Hochohmigkeit auf und sendet &h00 auf dem Bus.
    Wenn ich es richtig sehe (hier bitte ich darum, mitzudenken und mich gegebenenfalls zu korrigieren), kann dabei nichts schief gehen, wenn mehrere Module zeitgleich oder zeitlich überlappend &h00 senden.
    Im UART des Controllers kommt auf jeden Fall &h00 an.
    Daraufhin pollt er die in Frage kommenden Module nach einem intelligenten Schema.
    Ein Modul, das seine Mitteilung losgeworden ist, setzt den Bus zum Controller wieder auf hochohmig.
    Der Controller pollt also solange die in Frage kommenden Module, bis der Bus wieder hochohmig ist.
    Dann cleart er seinen Empfangsbuffer und ist wieder bereit zu lauschen.


    Das mit dem intelligenten Polling habe ich in der Theorie schon durch und es wird rasche Reaktionszeiten ermöglichen, weil gewährleistet ist, dass nur genau die Module gepollt werden, die wirklich was zu melden haben.


    Wo ich aber noch unsicher bin, ist das mit der Hochohmigkeit und ob das dem &h00 als Interrupt wirklich hinhaut, auch in den Fällen, wo mehrere Module zeitlich überlappend das &h00 senden.



    Womit ich mich ansonsten noch immer richtig schwer tue, ist die Sache mit Multimaster auf dem HBUS.
    Zu externen Komponenten, in der Hausautomation: Ja.
    Nur hat das nichts mit dem HBUS zu tun und wie da die Module mit dem Controller kommunizieren.


    Ein Modul auf dem HBUS ist ein komplexes Ding. Ist nicht einfach ein Lichtschalter.
    'Nen Lichtschalter möchte man einfach hinzufügen und unkompliziert mit 'ner bestimmten Lampe verheiraten.
    Dann muss man halt der Lampe sagen, dass sie fortan auf den neuen Schalter reagieren soll.


    Auf dem HBUS sieht es anders aus. Da klemmt man den neuen Schalter an ein Modul. In der Praxis auch mehrere Schalter über eine Zweidrahtleitung, (so KNX-mäßig). Das Modul, an dem der/die Schalter angeschlossen sind, macht aber u.U. noch 1000 weitere Sachen. Dieses sollte die Daten dann stets zum Controller senden und der "weiß", was dann passieren soll und realisiert das.
    Statt dass man die Lampe programmiert, dass sie fortan auf Schalter Nr. 23 reagieren soll, ändert man halt das Programm im Hauptcontroller.


    Sorry, wenn ich vielleicht zu dämlich bin, die Vorteile von Multimaster zu erfassen. Dann kläre man mich bitte auf.

  • Wenn auf der zweiten Schiene aber ein eigener Controller zum Einsatz kommt, der wiederum Herr in seinem "HBUS-Universum" ist, das wiederum bis zu 255 Module neben dem Controller erlaubt, dann muss jeder dieser Controller eine eigene Adresse haben, die im Adressraum des ersten Controllers enthalten sein muss.
    Die kann der erste aber nur dann per Daisy-Chain zuweisen, wenn man eine entsprechend vieladrige Strippe zwischen beiden Schienen vorsieht.
    Will man beide Schienen lediglich per Zweidraht- oder Vierdraht-RS485 abwickeln, dann muss der zweite, dritte, vierte ... Controller eine fixe Adresse bekommen, weil sie (mangels Daisy) anders nicht vom Hauptcontroller zugewiesen werden kann.

    Wie du bereits vorher erwähnt hattest, könntest du ja daort auch Daisy-Chain über RS485 realisieren. Aber an sich benötigst du die Position ja nicht, du kannst ja auch Module adressieren, ohne das sie eine Position bekommen haben. Wenn du jetzt z.B. den Bus um eine Schiene erweiterst (die ein eigenes HBUS-Universum ist) dann kann man in der Software des neuen Hauptcontrollers dierekt einspeichern um welchen Hauptcontroller es sich handelt (Hauptcontroller Schiene 2) und der übergeordnete Bus weiß dann was sich dahinter verbirgt. Fixe Adressen sollten vermieden werden, da der jeweilige Hauptcontroller diese eventuell bereits vergeben hat.

    Oder aus den angeschlossenen Modulen wird ein neuer Typ-Code generiert.

    Damit meine ich, dass der Typ des Buscontrollers (zu übergeordneten Bus) von den angeschlossenen Modulen abhängt. Beispiel: hat die Einheit ein Display und eine Tastatur dann ist es eine Bedieneinheit, der Buscontroller ist nun vom "Typ" ein Bedienmodul. Sind nur Ausgabemodule angeschlossen ist der Buscontroller ein Ausgabemodul, ... (so in etwa jedenfalls) Wenn man nun davon ausgeht, dass keine Einheit identisch ist und somit dessen Typ auch verschieden, dann kann der übergeordnete Buscontroller an hand des Typs schon die Funktion erkennen und benötigt nicht zusätzlich noch die Position.


    Aber das doppelte Versenden sorgt ja kaum für mehr Traffic, bei Vierdraht.
    Die Daten von den Modulen zum Controller laufen über zwei Signalleitungen (nennen wir sie c & d).
    Der Controller sendet Daten, die für ein anderes Modul bestimmt sind, dann über die Signalleitungen a & b zu dem jeweiligen Zielmodul.
    Da wir bei Vierdraht Vollduplex fahren, erhöht sich nicht der Durchsatz auf einem Leitungspaar, gegenüber der multimasterfähingen Zweidraht-Version.

    Wenn du davon ausgehst, dass du von Modul B daten empfangen kannst und gleichzeitig Daten an Modul C senden kannst?! In der Theorie sicher möglich, jedoch bezweifle ich, dass das im allgemeinen kollisionsfrei funktioniert, da die Module den Empfang auch teilweise bestätigen werden. Wenn die Module die Daten nicht bestätigen würden, dann wüsstest du garnicht, ob die Daten angekommen sind. Wenn aber das Modul C gerade alle Daten von A erhaltne hat und diese dann bestätigt, A aber gleichzeitig noch Daten von B abruft, dann kommt es zur Kollision!


    Also Konflikte soll es überhaupt nicht geben können.

    Das ist aber Wunschdenken oder? Na gut wenn du nur einen Master hast der immer nur mit einem Slave kommuniziert, dann klappt das.


    Wenn ich es richtig sehe (hier bitte ich darum, mitzudenken und mich gegebenenfalls zu korrigieren), kann dabei nichts schief gehen, wenn mehrere Module zeitgleich oder zeitlich überlappend &h00 senden.

    Das würde ich im allgemeinen mal als Falsch beurteilen, Wenn die Module genau gleichzeitig senden (nur wenige Takte versetzt) dann klappt das möglicherweise noch. Wenn die aber wirklich überlappend versendest, dann weiß ich nicht, wie der Controller das dan interpretiert, da das Signal ja dann auch eigentlich zu lang ist und du dir möglicherweise die Start und Stop-Bits "zerstörst". Das war jetzt aber nur für 00, was ist wenn ein Controller etwas anderes sendet? Dann überwiegt trotzdem die Null und du bekommst den Rest nicht mit. Des weitern kann das einzelne Modul nicht feststellen, ob gerade eine Datenübertragung stattfindet. Kollisionen sind da vorprogrammiert!!!
    Mein Tip: Entweder Multimaster oder einen Master und dann mit polling (evtl ausgelöst durch ein seperates Signal)

    Wer KNX-Nodes anschließen will, setzt halt ein KNX-Modul auf die Schiene und geht von da aus per Kabel zu den externen Nodes.

    Ich dachte wir wollten die kompletten Busse identisch halten, damit man den HBUS einfach zu einem externen Modul verlängern kann (und da da sogar 4 Adern ausreichen) Desweiteren kann man die Module dann an eine beliebige Busebene anschließen. Natürlich könnte man auch protokoll umsetzer auf KNX bauen aber welchen Sinn hätte das? (Außerdem würdest du die sicher nicht bauen, da nicht benötigt und wer KNX einsetzt der wird wohl KNX einsetzen)


    Ein Modul auf dem HBUS ist ein komplexes Ding. Ist nicht einfach ein Lichtschalter.
    'Nen Lichtschalter möchte man einfach hinzufügen und unkompliziert mit 'ner bestimmten Lampe verheiraten.
    Dann muss man halt der Lampe sagen, dass sie fortan auf den neuen Schalter reagieren soll.


    Auf dem HBUS sieht es anders aus. Da klemmt man den neuen Schalter an ein Modul.

    Also ich sehe da keinen Unterschied oder denkst du bei der Hausinstallation nehme ich nen Schalter aus dem Baumarkt, schließe die beiden Busleitungen da an und fertig? Ne ne, da sitzt doch auch ein Modul zwischen wo der Schalter erst mal ran muss. Und die Lampe werde ich wohl auch nicht wegen einem Schalter von der Decke schrauben, warum auch der Schalter hohlt sich vom Buscontroller seinen Befehlt (Hier "Lampe-12 Ein/Aus" und fertig ist di Sache, da brauch man nix mehr programmieren)

    Sorry, wenn ich vielleicht zu dämlich bin, die Vorteile von Multimaster zu erfassen. Dann kläre man mich bitte auf.

    Also erstmal hat natürlich alles vor und Nachteile, möglicherweise überwiegen für dich zur Zeit die Nachteile vom Multimaster. Ich werde mal versuchen die Vor und Nachteile gegenüber einem System mit nur einem Master, aber seperat ausgeführtem Hin und Rückkanal beschreiben.


    Vorteil

    • Es ist kein polling mehr nötig
    • Jeder Busteilnehmer kann selbständig Daten senden
    • Busteilnehmer können dierekt unterienander kommunizieren
    • weniger Adern erforderlich


    Nachteil

    • Es können Kollisionen entstehen, die abgefangen werden müssen
    • gleichzeitiges Senden und Empfangen ist nicht möglich
    • Durch die Kollisionsvermeidung etwas schwieriger zu programmieren

    Wenn ich noch etwas vergessen habe, bitte ich um Benachrichtigung.

  • Wenn du jetzt z.B. den Bus um eine Schiene erweiterst (die ein eigenes HBUS-Universum ist) dann kann man in der Software des neuen Hauptcontrollers dierekt einspeichern um welchen Hauptcontroller es sich handelt

    Das meine ich ja, mit der fest zugewiesenen Adresse.
    In dem Moment, wo die fix im Programm des zweiten Controllers abgespeichert ist, ist sie eben "fix".
    Das sollte - wie Du selbst schon schriebst - möglichst vermieden werden.


    Bei allen Modulen, die an der Daisy-Chain hängen, kann so eine fixe Adresse problemlos vermieden werden.
    Aber die Daisy-Chain reicht halt nicht weit, es sei denn, man setzt auch da RS485 ein. Aber das treibt den Aufwand wieder hoch.


    Wenn man nun davon ausgeht, dass keine Einheit identisch ist und somit dessen Typ auch verschieden, dann kann der übergeordnete Buscontroller an hand des Typs schon die Funktion erkennen und benötigt nicht zusätzlich noch die Position.

    Aber dazu müssen die beiden Controller bereits miteinander kommunizieren können.
    Sprich: Die müssen die jeweilige Adresse des anderen kennen.
    Woher?



    Wenn du davon ausgehst, dass du von Modul B daten empfangen kannst und gleichzeitig Daten an Modul C senden kannst?! In der Theorie sicher möglich, jedoch bezweifle ich, dass das im allgemeinen kollisionsfrei funktioniert, da die Module den Empfang auch teilweise bestätigen werden.

    Ich gehe davon aus, dass ein Modul nur auf Aufforderung durch den Controller Daten sendet.
    Ausnahme: Das erwähnte Nullbyte, das darf jedes Modul jederzeit senden - sofern der Bus gerade frei ist.



    Wenn die aber wirklich überlappend versendest, dann weiß ich nicht, wie der Controller das dan interpretiert, da das Signal ja dann auch eigentlich zu lang ist und du dir möglicherweise die Start und Stop-Bits "zerstörst". Das war jetzt aber nur für 00, was ist wenn ein Controller etwas anderes sendet?

    Wenn ich nicht sehr täusche, kann man die Start- und Stopbits auch wegkonfigurieren.
    Falls nicht: Macht auch nichts, wenn man denn eine Überprüfung einbaut, ob der Bus gerade frei oder belegt ist.


    Laut gedacht halt so: Der Bus ist im Ruhezustand hochohmig. In dem Moment, wo ein Modul sendet, ändert sich das. Das muss man detektieren können.
    Obwohl mir gerade schwant, dass das wieder eine neue Fehlerquelle ist. Hochohmige (lediglich terminierte) Signale sind prinzipiell empfindlich.
    Wegen RS485 zwar nicht so doll empfindlich, aber dennoch ...


    Ach ja (seufz) mit Polling ist man das Problem so richtig von der Backe! Multimaster ist eben doof! (Und gemein! Petz' ich alles bei Mutti!)



    Ich dachte wir wollten die kompletten Busse identisch halten, damit man den HBUS einfach zu einem externen Modul verlängern kann (und da da sogar 4 Adern ausreichen)

    Irgendwas vertüddeln wir jetzt. Du oder ich.
    Wie soll das gehen, z.B. einen KNX-Teilnehmer direkt an den HBUS anzuklemmen?
    KNX ist doch schon allein bedeutend lahmer, als der MoSteuS-Bus, mit seinen 2,5MHz Takt. Dazu können wir gar nicht direkt kompatibel sein, dafür wird immer ein spezielles Modul erforderlich sein.



    auch der Schalter hohlt sich vom Buscontroller seinen Befehlt (Hier "Lampe-12 Ein/Aus" und fertig ist di Sache, da brauch man nix mehr programmieren)

    Aha!?
    Dann ist das Verfahren ja doch nicht so ganz dezentral. Mindestens diesen ersten Befehl holt sich der Schalter vom Buscontroller. Erst ab da kann er multimastern, also jederzeit und an jeden Teilnehmer senden?


    Woher weiß die Lampe Nr. 27, dass sie auf den Schalter Nr. 18 reagieren soll, wenn man nichts zu programmieren braucht?

  • Bei allen Modulen, die an der Daisy-Chain hängen, kann so eine fixe Adresse problemlos vermieden werden.
    Aber die Daisy-Chain reicht halt nicht weit, es sei denn, man setzt auch da RS485 ein. Aber das treibt den Aufwand wieder hoch.

    Man könnte auch in den entfernten Modulen einfach die Position einspeichern, die sonst per Daisy-Chain übertragen worden wäre, dann ist wenigstens das Problem mit den festen Adressen aus der Welt.

    Aber dazu müssen die beiden Controller bereits miteinander kommunizieren können.
    Sprich: Die müssen die jeweilige Adresse des anderen kennen.
    Woher?

    Der Controller des Übergeordneten Busses hat doch bereits die Adresse 0, somit kann der von allen am Bus angeschlossenen Modulen (somit auch Buserweiterungsmodulen) angesprochen werden.

    Ich gehe davon aus, dass ein Modul nur auf Aufforderung durch den Controller Daten sendet.
    Ausnahme: Das erwähnte Nullbyte, das darf jedes Modul jederzeit senden - sofern der Bus gerade frei ist.

    Das Problem ist aber genau das, dass du nicht feststellen kannst, ob der Bus frei ist.

    Laut gedacht halt so: Der Bus ist im Ruhezustand hochohmig. In dem Moment, wo ein Modul sendet, ändert sich das. Das muss man detektieren können.
    Obwohl mir gerade schwant, dass das wieder eine neue Fehlerquelle ist. Hochohmige (lediglich terminierte) Signale sind prinzipiell empfindlich.
    Wegen RS485 zwar nicht so doll empfindlich, aber dennoch ...

    Der Zustand des Busses müsste ja in dem Datenblatt deines RS485-Wandlers definiert sein.

    Irgendwas vertüddeln wir jetzt. Du oder ich.
    Wie soll das gehen, z.B. einen KNX-Teilnehmer direkt an den HBUS anzuklemmen?
    KNX ist doch schon allein bedeutend lahmer, als der MoSteuS-Bus, mit seinen 2,5MHz Takt. Dazu können wir gar nicht direkt kompatibel sein, dafür wird immer ein spezielles Modul erforderlich sein.

    Der einzige der von KNX redet bist du, ich habe nie erwähnt, dass ich für die Haussteuerung KNX-Teilnehmer einsetzen werde/möchte. Ich würde gerne eigene Module bauen, die auf meine Bedürfnisse zugeschnitten sind und die Idee war halt, die grundlegende Kommunikation identisch ist, damit HBUS-Module quasie ohne änderung (nur einwenig in der Software) an dem Hausbus eingestezt werden können (umgekehrt natürlich auch).

    Dann ist das Verfahren ja doch nicht so ganz dezentral. Mindestens diesen ersten Befehl holt sich der Schalter vom Buscontroller. Erst ab da kann er multimastern, also jederzeit und an jeden Teilnehmer senden?

    Also ich wüsste nicht, was die Diskussion über zentral und dezentral mit Multimasterbetrieb zu tuen hat?! Das sind doch völlig verschiedene Sachen.


    Woher weiß die Lampe Nr. 27, dass sie auf den Schalter Nr. 18 reagieren soll, wenn man nichts zu programmieren braucht?

    Natürlich geht es nicht ganz ohne programmieren. Dennoch ist es der Lampe egal, von wo sie den Befehl zum einschalten bekommt.


    Hier zwei Beispiele (Annahme, die Lampe XY ist bereits am Bus angeschlossen und hat eine Adresse bekommen)


    Bespiel programmierter Taster:

    • Dem Taster wird bei der Programmierung gesagt, dass er Lampe XY schalten soll.
    • Sobald der Taster am Bus hängt, hohlt er sich von dem Buscontroller eine Adresse.
    • Anschließend hohlt er sich vom Buscontroller die Adresse der Lampe XY.
    • Wenn der Taster nun betätigt wird, sendet er an die Adresse der Lampe XY den Befehl "einschalten".


    Beispiel programmierter Buscontroller

    • Dem Buscontroller wird gesagt, welcher Taster mit welcher Lampe zusammen arbeiten soll.
    • Sobald der Taster am Bus hängt, hohlt er sich von dem Buscontroller eine Adresse.
    • Anschließend fragt er beim Buscontroller nach, an welche Adresse er seine Befehle senden soll.
    • Der Buscontroller sendet ihm die Adresse von Lampe XY.
    • Wenn der Taster nun betätigt wird, sendet er an die Adresse der Lampe XY den Befehl "einschalten".

    So wie ich das zur Zeit sehe, sollten wir jetzt erst ein paar Tests in der Realität durchführen, um zu überprüfen was machbar ist (und wie). Um anschließend genauer abschätzen zu können, welche Ideen Sinn machen und was nicht praktikabel ist.


    EDIT: Was mir gerade noch bezüglich Daisy-Chain für externe Komponenten eingefallen ist, wäre ein Dais-Chain-Emulator. Darunter versehe ich Gerät, dass man an das externe Modul anschließen kann und was dann dem Modul den Daisy-Chain emuliert, also dem Modul die im Emulator eingestellte Position mitteilt. Danach ist das Modul dann in der Lage (Wie HBUS-Module) eine Adresse beim Buscontroller anzufordern.

  • Hey kb-light,


    das macht richtig Spaß mit Dir!

    Man könnte auch in den entfernten Modulen einfach die Position einspeichern, die sonst per Daisy-Chain übertragen worden wäre, dann ist wenigstens das Problem mit den festen Adressen aus der Welt.

    Eine im Modul eingespeicherte Adresse ist für mich eine fixe Adresse.
    Man muss dabei aufpassen, dass man eine Adresse einspeichert, die definitiv noch nicht vergeben ist.
    Und um die zu ändern, muss man an dem entfernten Modul rumprogrammieren (oder DIP-Schalter befummeln).


    Das wollte ich halt durch die Daisy-Chain umgehen.
    Da verpasst stets der Controller den Modulen ihre Adressen.


    Habe aber inzwischen eine andere Idee, siehe weiter unten.


    Der Controller des Übergeordneten Busses hat doch bereits die Adresse 0, somit kann der von allen am Bus angeschlossenen Modulen (somit auch Buserweiterungsmodulen) angesprochen werden.

    Ja, aber wenn man es so macht, dass ein Controllermodul "ab Werk" Adresse Null hat, dann wird es problematisch, wenn ein zweiter Controller, auf einer zweiten Hutschiene, dazu kommt.
    Der hat auf seiner eigenen Hutschiene ja ebenfalls Adresse Null und ist der dortige Busmaster.
    Aber bei der Kommunikation mit dem ersten Controller hätten wir eine Überschneidung, die irgendwie umgangen werden muss.


    Wenn Du auf Hausautomation setzt, kommt übrigens recht schnell ein recht großer Adressraum zusammen. Anders als bei komplexen Modulen auf 'ner Hutschiene, wo man mit 8 Bit Adressraum richtig derbe viel machen kann. Aber wenn schon ein simpler Lichtschalter 'ne eigene Adresse bekommt, wird es rasch eng.
    Bin daher am überlegen, ob wir den Adressraum nicht auf 16 Bit erweitern.


    Man könnte zudem festlegen, dass der "ultimative Hauptcontroller" immer Adresse Null hat, alle anderen, per Kabel angeschlossenen Controller, die also eine eigene Hutschiene bedienen, eine der Adressen oberhalb von 8 Bit belegen und in ihrem "Universum" (ihrer Hutschiene) die unteren 8 Bit verwenden.
    Ein Modul auf Hutschiene 2 kann dennoch an jedes andere Modul Daten senden, dazu muss es lediglich die volle 16-Bit Adresse des Empfängers verwenden.


    Das Problem ist aber genau das, dass du nicht feststellen kannst, ob der Bus frei ist.

    Das sollten wir jetzt zum Prio-Thema machen, wie wir das lösen können.



    Der einzige der von KNX redet bist du, ich habe nie erwähnt, dass ich für die Haussteuerung KNX-Teilnehmer einsetzen werde/möchte. Ich würde gerne eigene Module bauen, die auf meine Bedürfnisse zugeschnitten sind und die Idee war halt, die grundlegende Kommunikation identisch ist, damit HBUS-Module quasie ohne änderung (nur einwenig in der Software) an dem Hausbus eingestezt werden können (umgekehrt natürlich auch).

    Ach so.
    OK, bin mit Dir und sehr gerne bereit, Deine Anforderungen vollumfanglich berücksichtigen.



    EDIT: Was mir gerade noch bezüglich Daisy-Chain für externe Komponenten eingefallen ist, wäre ein Dais-Chain-Emulator. Darunter versehe ich Gerät, dass man an das externe Modul anschließen kann und was dann dem Modul den Daisy-Chain emuliert, also dem Modul die im Emulator eingestellte Position mitteilt. Danach ist das Modul dann in der Lage (Wie HBUS-Module) eine Adresse beim Buscontroller anzufordern.

    Darüber zerbreche ich mir schon einige Zeit den Kopf, wie sowas gehen könnte.
    Was ich mir vorstellen kann:
    Module auf der Hutschiene werden über die Daisy-Chain automatisch adressiert. Damit sind die schon mal erschlagen.
    Entfernte Module, die nur an RS485 hängen, also nicht mit an der Daisy, haben einen Taster (nur per Kugelschreiber zugänglich oder so), dessen Betätigung vom Controller eine freie Adresse anfordert.


    Dann muss man bei der Erstinitialisierung allerdings einmal durch das Haus latschen und an jedem Teilnehmer 'ne Taste betätigen.
    Wobei das mit dem "durchs Haus latschen" entfällt, wenn der Controller schon läuft. Dann baut man einfach nacheinander die Taster ein, betätigt die Adressanforderungs-Taste und gut.


    Wobei: Man sucht sich dämlich nach dem Fehler, wenn man einen Lichtschalter einbaut, der schon eine Adresse eingespeichert hat, die sich aber mit einem anderen Teilnehmer überschneidet und man vergisst die Taste zu betätigen.
    Bei den Modulen an der Daisy ist so ein Fall ausgeschlossen. Alles, was manuell gemacht werden muss, birgt böses Fehlerpotenzial.
    Im Haus nicht schlimm, wenn mal 'ne falsche Lampe geschaltet wird. Bei einer Industriesteuerung sieht es anders aus ...



    Zu Deinen beiden Beispielen: "Programmierter Taster" vs. "Programmierter Buscontroller":
    Ich würde notmalerweise die zweite Variante bevorzugen. Unter Vorbehalt des weiter unten Geschrienbenen.
    Wenn man die Variante "Programmierter Buscontroller" einsetzt, muss es auch keine Multimaster-Lösung sein, dann kann man gleich die ganze Kommunikation auch über den Controller laufen lassen.
    Bei der Hausautomatisation fallen wohl üblicherweise ohnehin keine großen Datenmengen an, schließlich arbeitet auch KNX mit 'ner lahmen Übertragungsrate.
    Insofern kommen wir, mit unserem geilen 2,5MHz-Bus, niemals in Timing-Probleme.
    Und dann ist es wurscht, ob die Daten über den Controller laufen. Aber er hat gegebenenfalls die völlige Kontrolle, was damit passiert, was ich vorteilhaft finde.
    Der Controller darf nur nicht ausfallen oder entfernt werden, weil dann gar nichts mehr geht.


    Wenn ich das richtig sehe, wäre das bei einer dezentralen Lösung anders?
    Da kann, sobald der Schalter und die Lampe sich gegenseitig kennen, anschließend der Controller wegfallen?
    Der wird also praktisch nur einmal, für die Adresszuweisung benötigt, ab da laufen die anderen Teilnehmer autark, selbst wenn man den Controller entfernt?
    Zugegeben, das hat was! Ist das echt so?


    Wenn nicht, hätte ich persönlich Multimaster gerne vom Tisch und würde gerne alles über den Controller laufen lassen.
    Ich stecke halt sehr in meinem Hutschienen-Denken nach Art einer SPS fest. Da muss der Controller wissen, was er für Module unter sich hat und sein ganzes Programm ist darauf ausgerichtet, dass er alles mastert.
    Wenn irgendwas geändert werden soll, muss nur der Controller ein neues Programm bekommen, sonst nichts.
    Das kriege ich mit Multimaster irgendwie nicht unter einen Hut.
    Aber dass Multimaster in der Haussteuerung Sinn macht, sehe ich ein, wenn es echt so ist (wie ich inzwischen glaube verstanden zu haben), dass der Controller ausfallen kann und der Rest läuft einfach weiter.


    Was ich mich halt frage, bei Multimaster:
    Angenommen, der Controller haut gerade richtig viel Daten an Module raus, die jeweils durch Rücksendung bestätigen.
    Dann sind beide RS485-Wege permanent belegt.
    Nun will ein Lichtschalter dazwischen funken, aber die Busse sind dicht, er kommt nicht durch.
    Bei meinem Polling-Verfahren sieht der Controller zwischendurch immer mal Zeitfenster vor, wo Interrupt-Quellen sich melden können. Diese Zeitfenster öffnet der Controller, wenn er dazu bereit ist. So ist gar kein echter Interrupt nötig. Der Controller empfängt die Meldung des Schalters und sendet die Daten an den Empfänger weiter.
    Das ist aber halt der Ansatz, dass der Controller der Chef ist.
    Wenn nun ein Schalter so Multimaster-mäßig direkt an einen anderen Teilnehmer senden können soll, wird es wesentlich aufwändiger, mit der Konfliktvermeidung. Es gibt halt nicht den einen (Controller), über über das ganze Geschehen wacht und wie ein Verkehrspolitist den Verkehr regelt.
    Da muss also jeder Teilnehmer richtig viel Intelligenz mitbringen.
    Das erschwert wiederum Firmware-Updates.
    OK, auch mein Einsatz sieht "viel Intelligenz" vor, in Form des HBUS-Decoders. Aber (für mich) irgendwie überschaubarer.

  • Zitat

    Eine im Modul eingespeicherte Adresse ist für mich eine fixe Adresse.

    Für mich auch, aber ich würde ja auch nicht die Adresse speichern!!!
    Ich würde die Position speichert (oder den Modultyp anpassen). Zwar ist diese dann fix und kann nicht geändert werden, aber die Adresse wird immer noch vom Buscontroller vergeben und somit gibt es keine Adress-Kollisionen.

    Zitat

    Ja, aber wenn man es so macht, dass ein Controllermodul "ab Werk" Adresse Null hat, dann wird es problematisch, wenn ein zweiter Controller, auf einer zweiten Hutschiene, dazu kommt.

    Meine Idee war, dass der Buscontroller / Busconnector /... halt 2 Adressen hat. Einmal die interne Adresse 0 und die exteren von einem übergeordneten Buscontroller vergebene Adresse.

    Zitat

    Wenn Du auf Hausautomation setzt, kommt übrigens recht schnell ein rechtgroßer Adressraum zusammen. Anders als bei komplexen Modulen auf 'ner Hutschiene, wo man mit 8 Bit Adressraum richtig derbe viel machen kann. Aber wenn schon ein simpler Lichtschalter 'ne eigene Adresse bekommt, wird es rasch eng.
    Bin daher am überlegen, ob wir den Adressraum nicht auf 16 Bit erweitern.

    Ja das stimmt wohl, vorallem wenn man im Wohnzimmer so an die 10 Module problemlos verbauen kann ;)
    Die Überlegung wäre da entweder die 16Bit-Adressen, wobei das natürlich aufwändiger bei der Abfrage ist, es müssen ja immerhin 2Byte ausgewertet werden. Als Alternative / oder zusätzlich kann man natürlich bei der Hausautomatisierung in jedem Stockwerk einen eigenen Subbus anlegen und da sollten 256 Adressen ausreichen (oder nicht?). Bei 10 Räumen pro Etage und 10 Modulen pro Raum wären das immer noch nur 100 Module / Adressen. Da aber nicht in jedem Raum 10Module sitzen sondern im Schnitt vielleicht so 5, wären das 50 Adressen. Die 8Bit könnten also für 5 Stockwerke reichen.


    Zitat

    Wobei: Man sucht sich dämlich nach dem Fehler, wenn man einen Lichtschalter einbaut, der schon eine Adresse eingespeichert hat, die sich aber mit einem anderen Teilnehmer überschneidet und man vergisst die Taste zu betätigen.

    Dafür könnte man dem Bus ja ein paar Diagnoseverfahren spendieren. Zum Beispiel alle Adressen ansprechen die vom Buscontroller vergeben wurden oder Auflistung aller angemeldeten Module (Das fehlende Modul ist dann für die Fehler zuständig). Man könnte aber auch eine Broadcast-Adresse vergeben, worüber man dann eine neue Initialisierung starten könnte.


    Zitat

    Zu Deinen beiden Beispielen: "Programmierter Taster" vs. "Programmierter Buscontroller":
    Ich würde notmalerweise die zweite Variante bevorzugen. Unter Vorbehalt des weiter unten Geschrienbenen.

    Ja da würde ich auch den programmierten Buscontroller bevorzugen, dann kann man die Programme einfacher anpassen und muss nicht zu jedem Schalter/Schaltermodul rennen.

    Zitat

    Bei der Hausautomatisation fallen wohl üblicherweise ohnehin keine großen Datenmengen an, schließlich arbeitet auch KNX mit 'ner lahmen Übertragungsrate.
    Insofern kommen wir, mit unserem geilen 2,5MHz-Bus, niemals in Timing-Probleme.

    Da muss sich natürlich zeigen, ob die 2,5MHz auch über längere Strecken problemlos möglich sind. Bzw. würde ich da die Geschwindigkeit anpassen wollen.


    Im Grunde ist das so richtig, was natürlich dann nicht mehr funktioniert, wäre die Kommunikation über die Busgrenzen hinweg. Aber bei nur einem Bus ist der quasie wirklich überflüssig, hatte ich so noch garnicht drüber nach gedacht.


    Zitat

    Wenn nicht, hätte ich persönlich Multimaster gerne vom Tisch und würde gerne alles über den Controller laufen lassen.

    Man kann ja auch selbst beim Multimaster alles über einen Controller laufen lassen.
    Was wir auch machen könnten, wäre eventuell die Auslegung des Busses für beide Betriebsweisen. Das kann man ja z.B. in die defines des HBUS-Dekoders einbauen, da braucht man das beim programmierne nur einstellen und schon läuft das entsprechend.


    Zitat

    Was ich mich halt frage, bei Multimaster:


    Angenommen, der Controller haut gerade richtig viel Daten an Module raus, die jeweils durch Rücksendung bestätigen.


    Dann sind beide RS485-Wege permanent belegt.

    Das stimmt natürlich, aber das kann dir auf deinem System auch passieren, wenn das Datenvolumen so groß wird, dass der Bus nicht ausreicht. Da ist dann der Programmierer an der Reihe und muss entweder das Volumen reduzieren oder einen neuen Subbus anlegen, um den jeweiligen Bus zu entlasten.

    Zitat

    Wenn nun ein Schalter so Multimaster-mäßig direkt an einen anderen
    Teilnehmer senden können soll, wird es wesentlich aufwändiger, mit der
    Konfliktvermeidung. Es gibt halt nicht den einen (Controller), über über
    das ganze Geschehen wacht und wie ein Verkehrspolitist den Verkehr
    regelt.

    Das hatte ich ja bereits erwähnt, dass das mit den Konflikten Probleme machen könnte.

    Zitat

    Da muss also jeder Teilnehmer richtig viel Intelligenz mitbringen.


    Das erschwert wiederum Firmware-Updates.

    Was jetzt die Intelligenz mit Firmware-Updares zu tun hat, kann ich nicht nachvolziehen. Mir ist schon klar, dass bei mehr Intelligenz die Firmware größer wird, aber die Updates sollten doch immer gleich funktionieren, bzw deine HBUS-Decoder sind ja auch nicht gerade mit 3 Zeilen Code fertig oder?


    Ich denke jetzt müssen wirklich erst mal Prototypen und Test her, um die Machbarkeit der ganzen Ideen zu überprüfen und dann schauen wir weiter. Sonst drehen wir uns ja doch nur im Kreis und sind nächstes Jahr noch am diskutieren ob Multimaster oder nicht, ... und wenn sich rausstellt, dass iergendwas nicht praktikabel ist, dann steht die Entscheidung ja schon fest.
    EDIT: Endlich ist der Post fertig!!!

  • Hey kb-light,


    ich war leider drei Wochen teilweise weg, teilweise am Kränkeln.
    Jetzt habe ich noch zwei Kleinigkeiten in der Warteschleife, die immerhin am Rande mit dem Projekt zu tun haben und mich noch ein paar Tage auslasten, dann geht es bei mir direkt damit weiter.
    Hast Du zwischenzeitlich die erwähnten Experimente gemacht?

  • Hallo Irrlicht,


    leider habe ich zur Zeit auch sehr wenig Zeit, deshalb liegen auch erst einmal meine ganzen Projekte auf Eis.
    Bezüglich der Experimente: Da hatte ich eigentlich nicht vor, die komplett alleine zu machen und hatte gehofft, dass du auch eigene Test durchführst.


    Ich melde mich wenn es was neues gibt. (Dauert aber noch etwas)


    Gruß
    Karsten

  • Jupp, keine Angst, ich mache natürlich mit.
    Hatte in der letzten Zeit aber echt viel anderen Kram zu tun. Muss aber dringend an MoSteuS weiter machen, bin schon sowas von überfällig ...


    Off Topic totale:
    Parallel läuft auch noch diese unsägliche Beschneidungsdebatte, die meine Zeit bindet.
    Wer sich ebenfalls für ein Verbot dieser Verstümellung wehrloser Unmündiger einsetzen will, den bitte ich hier mitzuzeichnen:
    https://secure.avaaz.org/de/pe…rn_aus_religiosen_Grunden

  • PS: wie geht es eigentlich voran mit dem Projekt?

    Wenn ich jetzt im Oktober nicht mindestens die ersten beiden Platinen gefertigt bekomme, habe ich ein Problem am Hals. Muss also voran gehen.


    Derzeit halte ich mich noch mit ein paar zähen Detailproblemen auf, die insbesondere mit dem Gehäuse zu tun haben und mit meinem Anspruch, dass man praktisch ohne mechanische Arbeiten am Gehäuse auskommen können soll.
    Dieses Problem wäre schnell lösbar, allerdings zu Lasten des Preises & unnötig schlechter Wärmeabfuhr, was mir beides auch wieder nicht schmeckt ...
    Erschwert wird die Sache noch durch meinen Anspruch, dass man die Komponenten auch ohne dem Hutschienengehäuse, in ganz flachen Aufbauten, einsetzen können soll, durch bloßes Zusammenstecken.


    Rein von der elektrotechnischen Seite her, ist alles geritzt, aber die mechanischen Notwendigkeiten halten mich echt in Atem.
    Das Leben wäre wesentlich einfacher, wenn ein Designer Blut lecken würde, der mir ein Gehäuse nach meinen Vorstellungen strickt.
    Hätte ich die Zeit, würde ich mich da ja selbst einarbeiten, aber der Tag hat immer nur 24 Stunden ...