MoSteuS - Brainstorming

  • Na klar!
    Die Magie ist einfach: Kommunikation über 'nen guten Bus.
    Klar können andere Boards das prinzipiell auch. Irgendwie. So mit Frickelei.
    MoSteuS ist dagegen von Anfang an dafür ausgelegt, dass alle Module über den HBUS kommunizieren.

    Auch hier drehen wir uns im Kreis, wie gesagt, das gilt für die Hutschienen-Version (die die wenigsten Bastler hier interessiert), ohne Hutschiene ist es die selbe "Frickelei" wie mit anderen Boards auch, und eben:

    Wie ich schon schrieb: Wer das Bussystem wirklich nicht braucht, der hat keinen großen Vorteil


    Optisch anspruchsvoll ist für mich z.B. sowas:

    Ja, das ist ja inzwischen reichlich bekannt... :whistling:


    Hätte der direkt Verbinder auf ein Bussystem, an das man direkt, ohne
    Löterei: Tastenfelder, Displays, Funkmodule, 'ne DCF77-Antenne, LEDs
    etc. anschließen kann, wäre das ein anderer Schnack. Dann hätte ich mit
    dem Ding schon längst was gemacht und Du wohl auch.

    Nee, bei mir liegt's eher an der SW/IDE - da zum rumspielen (oder auch später in einer konkreten Anwendung) ein paar Taster etc. "ranzufrickeln" ist nix, wo ich ein großes Problem mit hätte... ;)


    Ich brauche auch so Vieles nicht, was hier gebastelt wird.
    Soll ich jetzt in jeden Thread gehen, wo was Tolles gebastelt wird, nur um zu sagen dass ich es nicht brauche?

    Hm, naja, es ist auch nicht jeder Thread ein "Brainstorming"-Thread, wo schon mehrere User gepostet/gefragt haben, wo bei diesem und jenem herausgestellten Feature ein Vorteil sei, und dann halt jemand kommentiert, dass dies für ihn kein Vorteil ist, weil er dieses Feature schlicht nicht braucht... ;)


    ich hatte davor auch schon geschrieben, dass ich persönlich auch keinen Einsatzzweck für dieses gesmate System habe, deswegen hast Du mich ja auch nicht als Troll bezeichnet... ?(


    aber bevor das doch noch passiert :D und weil die Argumente (von uns beiden) immer wieder in die selbe Kerbe hauen, bin ich aus dieser Diskussion (wo hie rnun die großen Vorteile liegen) raus - das auch nicht falsch auffassen, wie schon gesagt:

    ich wünsche Dir natürlich trotzdem alles Gute für Dein Projekt, und dass Du möglichst viele Mitstreiter findest! :thumbup:

    lange Rede, nochmal kurzer Sinn: Bau' das Ding wie Du meinst, die User werden's dann nehmen oder nicht

    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!

  • Hallo noch einmal.


    Wenn ich mich auch noch ein letztes mal zur Thematik Sinn / Unsinn / Machbarkeit zu Wort melden darf. Danach gebe auch ich diesbezüglich Ruhe und beteilige mich nur noch an den sachlichen Fragen :P


    Du hast ja mittlerweile die ein oder andere "kritische Frage" von mir und anderen gehört wo es darum geht wo da Vorteile sind, was da bringt, ob man das braucht, usw.. Man könnte es auch vorsichtig als ein wenig "Gegenwind" bezeichnen. Nun frage ich mich warum? Das frage ich ich wirklich SLEBST!


    Ich frage mich warum ICH einen Beitrag wie eben den von oben schreibe und so kritisch bin!? Und die Antwort die mir dazu einfällt führt mich immer wieder auf deine Eingangsposts in den unterschiedlichen Threads zurück! Denn da hast Du Dinge geschrieben wie:


    Zitat

    das größte Projekt, das dieses Forum je gesehen hat


    Zitat

    Wir erschaffen hier eine neue, noch weiter gehende Legende


    Zitat

    Die Vision von MoSteuS ist eine sehr große.


    Zitat

    Ich sehe bei diesem Projekt locker das Potenzial für 20 und mehr Threads!


    Zitat

    Das MoSteuS-Projekt wird riesig und es werden immer neue Threads notwendig werden.


    Zitat

    ich glaube sogar, dass dieses Projekt langfristig dieses Forum erheblich bekannter machen wird!


    Zitat

    dieses System wird alle Anwendungsfälle abdecken!


    Ich selbst, und ich bin mir recht sicher auch viele andere, habe da gelinde gesagt deutlich mehr erwartet als (sorry) eine Art "Besser durchdachtes Arduino 3.0 mit mechanisch aufeinander abgestimmten Baugruppen".


    Ich hatte Dir ja schon gesagt, das ich das Projekt von der elektronischen Seite recht interessant und anspruchsvoll finde und mich gerne beteilige wo ich kann, aber bei allem Respekt, ich glaube nicht dass Dein Projekt je auch nur annähernd den Bekanntheitsgrad von Arduino erreichen kann / wird.


    Wie immer gilt: Bitte nicht falsch verstehen!


    LG,


    Pepe

  • Auch von mir noch ein letzter 'offtopic' Post :
    Ich habe ein wenig das du dich total verrannt hast.
    Du meinst das dein Projekt eine art 'Arduino 2.0' oder so ist das sehe ich leider ÜBERHAUPT nicht.


    Das Problem ist einfach das dein Markt viel zu klein ist damit die Intressenten aber vor allen auch die Mitentwickler fehlen werden.


    Du willst halt die EierlegendeWollMilchSau erschaffen nur sowas braucht außer dir kaum einer und in der heutigen Geiz ist Geil Gesellschaft
    ist keiner bereit der nur Wolle will für die Option auch Eier,Milch,Fleisch zu bekommen was extra zu bezahlen.


    Hast du dir eigentlich mal überlegt was so ein 'Mainmodul' incl. Gehäuse , 2-3 Platinen, Hutschienen interface usw. kostet ?


    Gerade bei den Platinen geht der Preis halt extem über die Stückzahl und wenn du nur 10 oder 20 Platinen herrstellen läßt sind die halt EXTREM teuer.


    Wir haben das hier ja mit den SEDU Board erlebt hätte da nicht Turi mit seinen Shop dick vorgestreckt wäre das Projekt vermutlich nicht
    verwirklicht worden weil der Preis pro Platine einfach zu hoch ist bei stückzahlen im unterne 2 stelligen Bereich.


    Ein fertiges µC Borard aus China kostet halt 10 Euro und das ist der Markt gegen dem du dich hier im Forum behaupten must.


    Du willst aber ein Profi System und das gibt es halt in Form von SPS bzw. wenn es eher modularer sein soll die ganzen von Pepe aufgezählen Systeme.


    Nur bei diesen System wirst du immer zugeständnisse machen müssen aber eine Eigenentwicklung eines solchen Systemes braucht halt zig
    Mannjahre + sehr viel Kohle.
    Du willst ja was auch richtig ist über das Forum diese Entwicklungslast auf mehr Leute übertragen nur das funktioniert halt nicht weil der
    Markt für das Produkt hier einfach zu klein ist.


    mfg
    Falo



  • Mal abgesehen davon, dass diese Aussagen schon ein wenig arrogant klingen, wird hier der Vergleich zu Aduino und Rhasberry pi gezogen.




    Der Erfolg beider Projekte ist in meinen Augen im wesentlichen durch 2 Punkte erreicht worden:



    - Der günstige Preis


    - Die niedrige Einstiegshürde/die einfache Benutzung bzw. Programmierung



    Wenn MoSteuS beides leisten kann, ist ein Erfolg sicher nicht ausgeschlossen. Wenn Du es schaffst, sagen wir mal ein Grundgerät mit einigen IOs für um die 40 Euro anzubieten und dazu noch eine IDE zur Verfügung zu stellen, die jedemann ohne große Vorkenntnisse bedienen kann um das System zu programmieren, kann das was werden.

  • Hi Leute,


    dass meine Aussagen überheblich geklungen haben mögen, ist und war mir klar.
    Das tut mir einerseits selbst Leid, andererseits sollte es halt aufrütteln.
    Es ist nunmal ein großes Ding und die Vision soll auch irgendwie rüberkommen.


    Ich selbst, und ich bin mir recht sicher auch viele andere, habe da gelinde gesagt deutlich mehr erwartet als (sorry) eine Art "Besser durchdachtes Arduino 3.0 mit mechanisch aufeinander abgestimmten Baugruppen".

    Oh, da kann ich aber nicht helfen.
    Wenn mehr erwartet wurde, als ein modulares Steuerungssystem, das von Niedrigpreis-Anwendungen angefangen, bis zu Großprojekten, praktisch jeden Anwendungsfall abdecken kann, dann rätsel ich wirklich, was jemand erwarten könnte, das darüber hinaus geht?
    Was könnte das sein? Vielleicht eine 3D-Videowand, so groß wie wie ein Woklenkratzer? OK, das wäre groß, aber wer wollte das bezahlen und wer braucht sowas?


    Ihr habt die Bilder und Videos der Karussells und Buden gesehen, die ich mit meinen alten Steuerungen beleuchte. Das war schon "groß", aber da waren nur maximal 48 Kanäle im Spiel. Nun geht es um ein System, das noch viel mehr kann, das praktisch beliebig skalierbar ist.
    Egal wie großkotzig meine Töne gewirkt haben mögen - ich verstehe nicht, welche bombasitsche Erwartungshaltung ich geweckt haben könnte, die "noch mehr" erwartet hat?


    Hast du dir eigentlich mal überlegt was so ein 'Mainmodul' incl. Gehäuse , 2-3 Platinen, Hutschienen interface usw. kostet ?

    Na klaro!
    Schrieb ich doch schon was, zu den Preisen.
    Die Preise der Gehäuse und Hutschienenverbinder seht Ihr bei Conrad. Man braucht diese Gehäuse und Verbinder aber nicht unbedingt. Die Platinen sind nur dafür vorgesehen, dass sie da rein passen. Wer bisher mit "nackten" Platinen gearbeitet hat, kann das auch hier tun. Aber er KANN die halt auch in die vorgesehenen Gehäuse stopfen und elegant miteinander verbinden.


    Die größte Platine in meinen bisherigen Modulen ist etwas kleiner, als 'ne halbe Eurokarte. Du kannst Dir ausmalen, was sowas kostet. Kannst ja mit anderen Projekten hier vergleichen, Sedu-Board oder RGB-Matrix und so. Vergleiche die Platinengrößen, dann weißt Du die Preisklasse.


    Ich hatte schon für mein altes System 'ne Einplatinensteuerung gemacht, die in das Gehäuse passt: Die "Doppelkrake".
    Da ist alles drauf, auf einer kleinen Karte: Gleichrichter und Stabi, ein ATmega32, ein FT232 mit USB-Buchse, 16 MOSFETs mit jeweils 4A Schaltleistung, steckbare Lastbuchsen, Fernbedienungs-Empfänger, 16 Kontroll-LEDs und eine "Spannung OK LED", sowie ein paar digitale Eingänge.
    Ach ja, und ein Erweiterungsfeld für 'ne kleine Huckepack-Platine ist auch noch vorhanden.
    Kleiner als 'ne halbe Eurokarte, erschlägt diese Einplatinensteuerung schon etliche Anwendungen, zumal man unter Verzicht auf Ausgänge auch die ADCs des AVR nutzen kann. Ein Folienkabel-Verbinder zu einer optionalen Frontplatte mit Display und Tastern ist auch vorhanden.


    Ich habe die Doppelkrake oft eingesetzt, weil billig, robust, in vielen Fällen ausreichend und (etwas) erweiterbar.
    'Ne bestückte, knappe halbe Eurokarte. Nicht teuer, aber verblüffend vielseitig.
    Wie schön doch, wenn man einfach ein paar Lasttreiber dazustricken kann, wenn man mal mehr braucht!


    Bei MoSteuS werden für noch einfachere Anwendungen noch kleinere Platinen zum Einsatz kommen, die kaum mehr als 'nen AVR enthalten und am Ende unter 15,- EUR kosten, für das Fertigteil.
    Aber halt beliebig erweiterbar, weil dafür ausgelegt.
    Und ich schrieb es schon: Man kann die Platinen (WENN man denn mehrere davon braucht) statt über die Hutschienen-Verbinder auch per Flachkabel miteinander verbinden, wenn es partout noch billiger oder ganz flach werden soll.


    Wer halt ein ganzes Riesenrad in ein Großdisplay verwandeln will, der kann das problemlos tun, wird dann aber sicher nicht mit nackten Platinen und Flachkabeln arbeiten. Klar muss man dann tiefer in die Tasche greifen, für 20,- EUR geht das nicht.
    Soviel zu den Preisen.
    Ich verstehe nicht, was daran schlecht sein soll? Ihr habt hier alles; von billig und klein bis gigantisch, beliebig ausbaubar.



    Ein fertiges µC Borard aus China kostet halt 10 Euro und das ist der Markt gegen dem du dich hier im Forum behaupten must.

    Für 10,- EUR habe ich noch nichts gesehen, aber zumindest unter 15,- EUR. Mit sehr mageren Fähigkeiten.
    Die kleinsten Platinen des neuen Systems werden sicher auch nicht teurer. Warum sollten sie auch?
    Ich verkaufe den Kram ja nicht, sondern ich breite es als Open Source aus. Wer mag, soll das produzieren und in seinem Shop anbieten.
    Warum sollten die Sachen teurer werden, als andere Mikrocontroller-Boards?


    Ich hoffe sehr, dass ich künftig die fertigen Platinen im Shop von LedStyles kaufen kann! Das befreit mich von umfangreicher Lagerhaltung der Bauteile und von der Platinenfertigung.



    eine Eigenentwicklung eines solchen Systemes braucht halt zig Mannjahre + sehr viel Kohle.

    :) Das alte System habe ich im Alleingang, in wenigen Monaten, von Null auf 100 aus dem Boden gestampft, mit immerhin 12 unterschiedlichen Platinen.
    Ich werde es wieder tun. Definitiv. Weil ich die Sachen aktuell für mehrere Projekte brauche.
    Natürlich konstruiere ich nur die Platinen, die ich selbst benötige. Aber die dürften für Viele interessant sein.
    Wer halt was mit EIB oder sonst was besonderes machen will, kann sich selbst 'ne Platine oder Software dazu stricken und profitiert dann von den fertigen, anderen Platinen.


    Ich halte nichts hinter dem Berg, sondern breite alles aus.
    Wer es gebrauchen kann, der nehme es. Wer etwas beitragen will, der ist mir herzlich willkommen.
    Und wer keinen Sinn darin sieht, der möge nun bitte Ruhe geben, denn es bringt nichts. Das System wird auf jeden Fall entstehen, weil ich es durchziehe.
    Aber ich bin offen für Vorschläge und bereit, gute Anregungen in das Projekt einfließen zu lassen, denn es soll nicht nur mir Nutzen bringen, sondern es soll für möglichst Viele interessant werden.
    Ihr habt jetzt die Möglichkeit, das System nach Euren Vorstellungen mitzugestalten, wenn Ihr es denn gebrauchen könnt. Nutzt die Chance!


    Übrigens finden sich auch im Forum vom Raspberry Pi etliche Leute, die daran zu meckern haben. "Warum habt Ihr das denn nicht soundso gemacht?" "Wozu braucht man das, ich habe doch schon 'nen PC ..."
    Fakt ist: Der Raspberry ist Hipp!
    Es gibt Leute, die darauf lauern, wie die hungrigen Wölfe. Und es gibt andere, die den nicht brauchen. Ist normal.


    Ich wünsche mir hier Leute, die den Sinn darin sehen und mit zu dem Projekt beitragen; und sei es nur durch gute Anregungen!

  • dass meine Aussagen überheblich geklungen haben mögen, ist und war mir klar.
    Das tut mir einerseits selbst Leid, andererseits sollte es halt aufrütteln.

    Das verstehe ich aber auch nicht, wenn Du hier schon so "groß die Klappe aufreisst" (Du weißt, wie's gemeint ist ;))

    Was glaubst Du, was das hier einschlagen wird, wenn erstmal die ersten Platinen verfügbar sind?!

    etc., warum es Dir dann andererseits so an Selbstvertrauen fehlt:

    Dennoch ist dieses Forum kleiner und überschaubarer als Mikrocontroller.net und Robnoternetz, wo ich untergehen würde.

    Erstens glaube ich das nicht mal (dass es dort untergeht), und *Du* solltest das erst recht nicht glauben, wenn Du von Deinem System so dermaßen überzeugt bist, dass es "größer" als Ardunio und "hipper" als Raspberry etc. wird.


    Das müsste dann dort ja eigentlich einschlagen wie eine Bombe, glattes Gegenteil von "Untergehen" - und da sind *garantiert* mehr Leute drin, die sich für das Teil interessieren, sowohl für die Anwendung wie auch Mitentwicklung...


    Weil hier im Forum hast Du vielleicht 5-10 aktive µC-Entwickler (+ ne Handvoll, die bis jetzt noch nix vorgestellt hat o.ä.), das ganze Thema ist hier im LED-Forum eher ne "Nebensache", "Mittel zum Zweck (LEDs ansteuern)", während es dort - wie der Name "mikrocontroller.net" schon sagt - das Hauptthema ist...


    da wären dann auch mehr Leute, die bei Fragen bzgl. Bus/Protokollen, alles mögliche weitere, fundiert helfen können, weil sie (ggfs. auch beruflich) dauernd damit zu tun haben...


    probier's doch einfach aus - mehr als doch untergehen kann's ja nicht, das ist dann ja auch kein Beinbruch... ideal dann aber ohne die zackigen Guru-Sprüche, schön kompakt ne Vorstellung, um was es geht, mit vielen Bildern - da bekommst Du sicher mehr positiven Response als hier im Forum


    wie man an den Posts hier ja sieht, es wird in diesem Thread weniger über Ideen zu diesem System gebrainstormt, sondern eher nur, was das Ganze *überhaupt* soll... :( - und irgendwie ein "super, das ist genau das, wonach ich immer gesucht habe" oder auch nur "kann ich bestimmt mal brauchen" war noch nicht dabei - weil die Präferenzen/Background der User hier halt einfach doch etwas anders sind...

    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!

  • Pesi, nun übertreibe mal bitte nicht.


    Dass MoSteuS "hipper" sein wird, als der Raspberry Pi, habe ich nie behauptet. Ich habe nur erwähnt, dass der hipp ist und die Gründe genannt, die ich dafür sehe. Mit dem Arduino hingegen, mag ich mich (rein technisch) durchaus messen. :D
    Aber das hängt letztendlich von der Userschar ab, ob MoSteuS auch wirklich ebenso bekannt und beliebt wird.


    Meine Töne mögen groß gewesen sein, aber mit jeder Frage, was das alles soll, steigerte sich mein Eindruck, dass die große Vison noch immer nicht angekommen war. Sowas schaukelt sich auf.
    Belassen wir es nun dabei, denn wer jetzt noch immer nicht Blut geleckt hat, für den ist es halt nichts, auch wenn ich noch mehr herumtänzel und gestikuliere. Ich schraube nun also meine Töne runter und wir werden konstruktiv, OK?



    Mikrocontroller.net war mir einfach zu riesig. Rein subjektiver Eindruck. Ich glaubte, das Projekt würde dort entweder in der Masse einfach untergehen, oder es würden dermaßen viele Köche mit am Brei rühren wollen, dass ich nicht mehr hinterher komme.
    LEDstyles schien mir die richtige Größe zu haben und genügend kompetente Leute.


    Mein (innerer) Schwerpunkt liegt halt auf Beleuchtungstechnik. Heutzutage natürlich mit LEDs.
    Habe zwar auch immer mal Projekte, wo andere Verbraucher angesteuert werden sollen, eben Ventile, Schütze etc., weswegen die Steuerung das AUCH können soll, nebst Abfrage von ein paar Eingangssignalen, aber hauptsächlich geht es mir um Lichttechnik-Anwendungen.


    Ich kann das ganze Projekt natürlich im Alleingang durchziehen. Dann erfährt es zwar nicht die Verbreitung, die es erfahren könnte, aber ich bin absolut in der Lage für meinen Eigenbedarf alles allein zu machen.
    Doch jeder engagierte Mitstreiter ist natürlich hoch willkommen!
    Schon einer, der sich richtig gut mit reinkniet, wäre Gold wert, denn das ergibt nunmal gute Synergien.
    Wenn zwei oder drei Leute mitmachen, umso besser.


    Das einzige was eher behindert, sind Kommentare im Stil von: "das brauche ich nicht!"
    Das verursacht nur traffic, frisst Zeit, bringt aber rein gar nichts.
    Davon kam hier schon überraschend viel, will ja gar nicht wissen, was in einem größeren Forum los wäre ...
    Wer es nicht braucht, der schweige einfach und werde anderweitig froh.
    Wer aber mitmachen will oder konstruktive Vorschläge hat: Herzlich Willkommen!

  • Pesi, nun übertreibe mal bitte nicht.


    Dass MoSteuS "hipper" sein wird, als der Raspberry Pi, habe ich nie behauptet.

    Naja, sorry, aber bei dieser exorbitanten Menge an Superlativen habe ich dann auch etwas den Überblick verloren, wo Du "eine neue, noch weiter gehende Legende" schaffen wolltest als wasauchimmer, und wo's nur "sowas wie" war.... :D


    Meine Töne mögen groß gewesen sein, aber mit jeder Frage, was das alles soll, steigerte sich mein Eindruck, dass die große Vison noch immer nicht angekommen war. Sowas schaukelt sich auf.

    Doch, doch, das haben alle hier kapiert, was das werden soll - wenn jemand der Meinung ist, das findet er persönlich nun nicht ganz soo toll wie Du, bedeutet das nicht automatisch, dass er's nicht verstanden hat... ;)


    Mikrocontroller.net war mir einfach zu riesig. Rein subjektiver Eindruck. Ich glaubte, das Projekt würde dort entweder in der Masse einfach untergehen, oder es würden dermaßen viele Köche mit am Brei rühren wollen, dass ich nicht mehr hinterher komme.

    Naja, aber da würden dann doch auch ein paar mehr konstruktiv mitrühren, als die 3, 4 Leute hier so ein bisschen...


    und wenn's dort in der "Masse" der auch nicht soo dermaßen tollen Projekte untergeht, dann kann's ebenfalls nicht so toll sein, oder? - oder ist das eher so gemeint, naja, für die bei µc.net ist das nix besonderes, da geht das unter zig ähnlichen/besseren Projekten unter, aber für die Tandler von Ledstyles.de reicht's schon, da ist es "das größte Projekt, das dieses Forum je gesehen hat"...? 8o (Du weißt, wie's.... ;))


    Das einzige was eher behindert, sind Kommentare im Stil von: "das brauche ich nicht!"
    Das verursacht nur traffic, frisst Zeit, bringt aber rein gar nichts.
    Davon kam hier schon überraschend viel, will ja gar nicht wissen, was in einem größeren Forum los wäre ...

    Rein statistisch gesehen würde da dann aber auch deutlich mehr Zustimmung kommen, weil mehr Leser insgesamt - und (meine "Vermutung") sogar überproportional mehr, weil sich dort bestimmt mehr User für sowas interessieren als hier... ;)

    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!

    Einmal editiert, zuletzt von Pesi ()

  • Labert nicht mehr rum, entwickelt.
    Bei der Textlänge und Rechtfertigungen und mühevollen Versuchen alles klarzustellen wieso dieses Projekt so viel besser als alles dagewesene ist, frag ich mich ob noch Zeit für die Entwicklung des Projekts ist.
    Meine Meinung ist, du bist mit deinem Bus hier falsch, im Mikrocontroller Forum wärst besser drann, aber auch da wollen alle Ihr eigenes Superding selber bauen und hoffen Freiwillige für Ihre Idee zu finden, doch die Freiwilligen wollen eh Ihr eigenes Zeug entwickelt haben und so gibts kein Fortschritt.
    Mir kommt es vor das du dich in diese Hutschienen verliebt hast und den "tollen" Bus, dass du umbedingt was mit dem Zeug machen möchtest.


    Wäre schon wenn du all das Vorgeschlagene machst, aber ich glaube du wirst das auch nicht bringen, es sind Themen dabei die ein Haufen Zeit benötigen und ob du die hast?
    Wünsch dir viel Erfolg.

  • Labert nicht mehr rum, entwickelt.

    Machen wir doch schon... ;)


    Meine Meinung ist, du bist mit deinem Bus hier falsch, im Mikrocontroller Forum wärst besser drann, aber auch da wollen alle Ihr eigenes Superding selber bauen und hoffen Freiwillige für Ihre Idee zu finden, doch die Freiwilligen wollen eh Ihr eigenes Zeug entwickelt haben und so gibts kein Fortschritt.

    Das sehe ich ähnlich, wie schon gesagt, und der zweite Teil trifft irgendwie auf jedes Forum zu... ;)


    Bei mir z.B. ist's zwar nicht so, dass ich mein Zeug entwickelt haben will, aber ich stelle gerade schon wieder mal fest, dass ich zu viel Zeit und Gedanken in ein "fremdes" Projekt stecke, das mich eher nur aus reiner Neugier interessiert, statt mal wieder an irgendwas eigenem weiter zu machen, das kann nicht so bleiben - aber naja, Domi ist dort ja auch noch fleißig... ;)


    Wäre schon wenn du all das Vorgeschlagene machst, aber ich glaube du wirst das auch nicht bringen, es sind Themen dabei die ein Haufen Zeit benötigen und ob du die hast?

    also da hätte ich jetzt weniger Bedenken, wenn ich mir anschaue, was der Irrlicht schon so alles gemacht hat, auf seiner HP, und da ist auch jede Menge Text dabei... ;)

    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!

  • Irrlicht


    Vielleicht könntest Du ja mal so ne Schema zeichnen auf dem Du klar darlegst wie das Modul-Konzept funktionieren soll. Dieses Diagramm sollte folgende Sachen aufzeigen:


    - was macht der Main-Controller und wie sieht er aus (µC? 8,16bit? FPGA? ARM?)
    - was soll dieser für Schnittstellen haben?
    - Die einzelnen Module, sollen die alle 'nen µC haben und dann Aufsteckkarten? So habe ich es bisher verstanden?
    - Welche Boards willst DU für DICH definitiv machen / haben und was sollen die können?
    - Welche Sachen sind für Dich nun schon fest und nicht mehr verhandelbar und bei welchen Sachen hoffst Du auf User-Input.


    Ich denke wenn Du einige Sachen einfach festlegst auf deutsch gesagt, dann ist das zwar nich sehr demokratisch aber es sogt definitiv dafür, dass mal ein Stein in Richtung "sachliche Diskussion" ins Rollen kommt! Denn solange die Leute keine konkreten Rahmenbedingungen kennen keimt halt eher Off-Topic auf als Kreativität.


    Ist kurioserweise so, wenn man Leuten etwas diktiert fangen sie eher an darüber nachzudenken als wenn man ihnen einfach frei Wahl lässt :huh:


    Und jetzt gibt's Bier, ist schließlich Freitag! :thumbup:


    Prost!

  • Ja, mache ich, Stück für Stück.
    Manche Sachen sind abhängig von anderen, die noch in der Entwicklung sind. Da will ich noch nicht zuviel sagen.
    Meine eigene Stichwortliste, ohne meinem gewohnt langem Gelaber, ist schon meterlang, da muss ich mich mal durchwühlen und die Essenz herauspulen.


    Will aber erstmal darauf hinweisen, dass ich im Inhaltsverzeichnis-Thread das zweite Posting erweitert habe, Abschnitt:
    Tischgehäuse, Wandgehäuse


    Ich glaube das erhöht die allgemeine Akzeptanz noch weiter, dass sich selbst ein handwerklich eher unbegabter Bastler ruckzuck ein Tischgehäuse zusammenstecken KANN und damit die ungeliebte Hutschiene, nebst jedem Kabelkram, komplett aus den Augen hat (und jetzt bitte kein Gnöle wegen Preis und so! Es ist ein KANN; kein Muss, an dem man nicht vorbei käme!).

  • Du hattest ja in deinem Abschnitt über Gehäuse gefragt ob jemand so ein Antennen-Gehäuse hat und ich hab zufällig so eins bei mir rumfliegen und hab das gleich mal fotografiert ;)


    [Blockierte Grafik: http://img29.imageshack.us/img29/9258/20120506011230.th.jpg]
    [Blockierte Grafik: http://img838.imageshack.us/img838/6443/20120506011044.th.jpg]
    [Blockierte Grafik: http://img36.imageshack.us/img36/6605/20120506010648.th.jpg]


    ich hoffe das hilft euch etwas ;)

  • Sehr schön, vielen Dank!


    Da werde ich mich wohl etwas anstrengen müssen, aber neben der DCF77 dürfte zumindest noch ein RFM70BP und ein AVR mit reinpassen; mit Chance auch noch ein WLAN-Modul.
    Ob die sich in der Enge dann noch alle miteinander vertragen, ist die nächste Frage ... :D


    Das Gehäuse ist schon recht elegant (wenn auch nicht billig).
    Wäre es etwas größer, würde ich noch andere Funkstandards mit reinquetschen, insbesondere Enocean.
    Aber man braucht ja wohl kaum alle zusammen; muss mal sehen, ob ich eine wahlweise Bestückung hinbekomme, so dass man genau die Module reinstopfen kann, die man braucht.

  • Hallo


    nach überfliegen der MoStreuS-Threads, habe ich die angesprochenen Sachen auch einmal überdacht und Folgendes zusammengesponen. Ich hoffe, dass ich damit den Forderungen von allen gerecht werde. (Sowohl für die Beleuchtung von Karusells, als auch für die Hausautomatisierung)
    Das Ganze ist natürlich noch nicht zu Ende gedacht.


    Vorab:
    - Es gibt zwei Bussysteme/-ebenen, den Hauptbus und den Subbus.
    - Mehrere örtlich bei einander sitzende Module ergeben eine Moduleinheit.


    Hauptbus:
    - Multimasterfähig
    -Verbindet die Moduleinheiten miteinander
    - Kann als Hausbus verwendet werden
    - Wird wahrscheinlich langsamer sein als der Subbus, dafür aber eine lange Reichweite haben
    - Er ist für die Übermittlung weniger Daten ausgelegt (Steuerbefehle und ähnliches)
    - Hier würde sich RS485 anbieten aber auch Ethernet und Funk wären zusätzlich denkbar


    Subbus:
    - Vernetzt die Module einer Moduleinheit untereinander
    - Hat keine Verbindung zu anderen Moduleinheiten
    - Hier würden sich SPI und/oder I2C anbieten
    - Ist für ein hohes Datenvolumen ausgelegt
    - Unabhängig vom Hauptbus
    - Wird nur Räumlich begrenzt eingesetzt
    - Hier würde der von Irrlich vorgeschlagene HBUS Anwendung finden


    Modul
    - Kann von jedem Nutzer nach seinen Bedürfnissen entwickelt werden
    - Es sind beliebige Module möglich und auch die "Größe"/ der Funktionsumfang eines Moduls ist nicht begrenzt (Es kann sich dabei z.B. nur um eine Platine mit einem Controller handeln oder aber auch um ein mit Technik volgestopftes Gehäuse an dem mehrere Sensoren und Aktoren angeschlossen sind)
    - Ist ein Teilsystem, dass über den Subbus mit den anderen Komponenten kommuniziert
    Anmerkung: Die hier vorgestellten Module verstehen sich als Beispiele, des weiteren ist eine Zusammenfassung mehrerer der weiter untern vorgestellten Module denkbar.


    Moduleinheit:
    - Besteht aus mehreren Modulen die örtlich dicht bei einander sitzen und zusammenarbeiten (müssen)
    - Eins der Module ist immer ein Bus-Connector-Modul


    Bus-Connector-Modul
    - Stellt die Verbindung zwischen Hauptbus und Subbus her
    - Muss natürlich nicht als seperates Modul ausgeführt sein, sondern kann auch weitere Aufgaben übernehmen

  • Hallo kb-light,


    soweit korrekt zusammengefasst.
    Nur würde ich empfehlen, in Deinem Posting die Bezeichnungen "Hauptbus" und "Subbus" jeweils zu vertauschen.
    Nach meiner Philosophie ist der HBUS der Hauptbus (passt zufällig sogar mnemonisch).
    Alles, was weiter entfernt angeschlossen wird, würde ich als Subbus bezeichnen.
    Das heißt, alles in Richtung Hausautomation (Lichtschalter, Rolladenantriebe ...), wo es um längere Strecken geht, hängt am Subbus.


    Derzeit bin ich noch mit meiner Displayansteuerung beschäftigt, aber demnächst geht es weiter mit der langsam überfälligen Spezifizierung des HBUSes.
    Du hast erwähnt, dass sich beim HBUS SPI und I2C anbieten. Das war auch meine ursprüngliche Idee.
    Wegen verschiedener Einwände ging die Überlegung inzwischen dahin, für die Übertragung der Datenmasse auf dem schnellen HBUS statt dessen RS485 einzusetzen.


    Zugegeben bin ich selbst damit noch nicht ganz durch. I2C möchte ich "eigentlich" zusätzlich weiterhin über den HBUS führen, aber dann gibt es wieder das Problem mit der maximalen Buslänge, von dem RS485 uns ja komplett befreien würde.
    I2C hat halt Vorteile, wenn man ein Modul ansteuern möchte, das quasi nichts als I2C-Bausteine enthält, was durchaus häufig vorkommen dürfte.
    Andererseits ist I2C ein kleines Sensibelchen und nicht für hohe Datenraten ausgelegt.
    Letzte Überlegung war ja die, die RS485-Daten mit 2,5MHz über den Bus zu peitschen. Das würde, trotz Protokoll-Overhead, I2C ziemlich obsolet werden lassen.
    Man bedenke, das in jedem Modul auch ein HBUS-Decoder sitzt, der einen AVR enthält, der also selbst in der Lage ist, I2C-Bausteine oder SPI-Bausteine im jeweiligen Modul anzusteuern.



    Ich schrieb schon, woran ich gegenwärtig noch kaue:
    Es wäre schick, wenn das Controller-Modul bei der Initialisierung den Bus "scannen" würde. Und dazu würde ich gerne die Notwendigkeit von DIP-Schaltern für die Adresszuweisung in jedem Modul wegrationalisieren, weil fehlerträchtig durch Fehleinstellung. Zudem layouttechnisch aufwändig.
    Dazu würde es sich anbieten, die beiden Daisy-Chains zu verwenden.
    Dann könnte der Controller bei der Initialisierung die Module zunächst ohne Adresse(!) einzeln ansprechen, nach dem Prinzip einer LED-Pixelkette.
    Einmal angesprochen, könnte der Controller auf diese Weise jedem Modul eine Adresse zuweisen (sogar mehrere Adressen), auf die dieses Modul anschließend lauschen soll, und zwar auf dem RS485-Signal (also nicht mehr auf den Daisy-Chains).


    Dieses Verfahren halte ich für ausgesprochen klug, es ist aber zu bedenken, dass das nur innerhalb des HBUSes so richtig Sinn macht.
    Bei weiter entfernten Komponenten, also bei der Hausautomatisierung, müssten sonst alle Teilnehmer so konstruiert sein, dass sie ebenfalls Daisy-Chains realisieren. Aber da wäre das nachteilig, bezüglich der Verdrahtung.


    Der Nachteil einer Daisy-Chain ist zudem der, dass alle nachfolgenden Teilnehmer sozusagen abgeklemmt sind, wenn man einen Teilnehmer aus der Kette entfernt. Das ist bei Hausautomatisierung nun echt schlecht, weil man sich nach dem Fehler blöd sucht, wenn ein Teilnehmer schlechten Kontakt hat, folglich mehrere Teilnehmer nicht mehr funktionieren und man nicht mehr weiß, wie die Verkabelung geführt wurde.
    Damit ist Daisy-Chain beim Subbus (nach meiner Definition also der weiträumige Bus) indiskutabel.


    Bleibt die Überlegung, ob Daisy-Chain auf dem HBUS wirklich sinnvoll ist.
    Nachteilig ist in jedem Fall auch dort, dass nachfolgende Module nicht mehr adressiert werden können, wenn man eines der mittigen Module entfernt.
    Für dieses Problem hatte ich bereits die Lösung vorgeschlagen, dass die eigentliche Initialisierung im Normalfall nur einmalig vorgenommen wird, typischerweise bei der ersten Inbetriebnahme.
    Sie kann aber per Knopfdruck jederzeit erneut ausgeführt werden.
    Bei jeder Initialisierung weist der Controller den Modulen halt ihre jeweiligen Adressen zu, die diese dann im EEPROM des HBUS-Decoders abspeichern.
    Diese Adresszuweisung behält also ihre Gültigkeit, auch wenn man anschließend (zu Testzwecken, bei der Fehlersuche) mittige Module entfernt, die Chain also unterbrochen ist.
    Denn die eigentliche Datenverbindung erfolgt ab einmal getätigter Adresszuweisung halt über das stets durchgeschliffene RS485-Signal.



    Bei solchen Installationen, wo der weiträumige Subbus recht überschaubar ist (Normalfall), kann man direkt das RS485-Signal vom HBUS dazu verwenden, gleichzeitig den weiträumigen Subbus zu realisieren, ohne das ein von Dir beschriebenes Bus-Connector-Modul erforderlich wäre.
    Nur müssen die entfernten Teilnehmer, die also nicht an der Daisy-Chain des HBUSes hängen, sondern ausschließlich an RS485, notgedrungen DIP-Schalter mitbringen, damit man denen fest eine Adresse verpassen kann.
    Es gibt denkbare Alternativen zu DIP-Schaltern, aber in jedem Fall mus jeder entfernte Teilnehmer manuell eine Adresse zugewiesen bekommen.
    Und diese Adressen dürfen sich nicht mit denen überschneiden, die der Controller per Daisy-Chain bei der Initialisierung den Modulen auf dem HBUS zuweist.



    Wenn man das so abbildet, braucht man auf dem HBUS:
    - Beide Daisy-Chains, also zwei Signale.
    - Vier Signale für RS485.
    - Spannungsversorgung (ich liebäugle gegenwärtig mit 12 bis 24V, auf jedem HBUS-Decoder sitzen Spannungsregler für 5V und 3,3V).
    - Masse (gern doppelt ausgeführt).


    Da wären also noch einige Leitungen frei.
    Ich liebäugle daher damit, die Spannungsversorgung ebenfalls mindestens doppelt, besser dreifach auszuführen.
    Aus folgendem Grund: Wenn jedes Modul mehrere Leuchtidioden enthält, wie bei einer SPS, dann kommen selbst bei Low-Current-LEDs schnell nennenswerte Ströme zusammen. Und die Kontakte der HBUS-Verbinder sind (frei aus dem Gedächtnis) nur für 2A spezifiziert.
    Beispiel: 20 Module, von denen jedes Modul 32 LEDs enthält.
    20x32x2mA=1,28A. Nur für die Low-Current-LEDs. Die zwar nur dann fließen, wenn alle LEDs gleichzeitig an sind, aber man dimensioniert ja für den Worst Case.
    Noch schlimmer wird es, wenn jedes Modul SSRs ansteuert, wo gleich 20mA pro SSR erforderlich sind. Dann wären wir schon bei 12,8A ...
    Man kann die Belastung der Kontakte der HBUS-Verbinder halbieren, indem man den Saft von beiden Seiten einspeist. Wären aber immer noch 6,4A.
    Bei Belegung von jeweils drei Kontakten parallel wären das dann noch etwas mehr als 2A pro Kontakt.


    Belegt man also insgesamt 6 Kontakte für die Spannungsversorgung (drei für 12-24V, drei für GND) wären mit 4-pol RS485 folglich 10 der 14 durchgeschliffenen Kontakte belegt.
    Vier stehen also noch zur Verfügung, für Interrupts etc.


    Wobei mich etwas stört, dass es widersinnig ist, die Datenmasse störsicher per RS485 auszuführen (was richtig lange Leitungen ermöglicht), jedoch die Interrupt-Signale einfach auf dem HBUS durchzuschleifen, was die Leitungslänge wieder sehr einschränkt.
    Darum bin ich am Überlegen, ob man nicht auf durchgeschliffene Interrupts verzichtet und statt dessen solche Signale ebenfalls im RS485-Datenstrom unterbringt.
    Dann muss das Protokoll halt so gestrickt sein, dass es potenzielle Interrupt-Quellen zügig "pollt".
    Wobei ich da an kein reguläres Polling denke, sondern an eine Sendeberechtigung nach einem Schema, das wirklich schnelle Reaktionen des Controllers ermöglicht.
    Dazu habe ich auch schon einen guten Ansatz. Datails später (Posting schon wieder so lang).

  • Hallo Irrlicht,


    ja so hat jeder seine eigenen Definitionen, ich hatte mir das genau anders herum gedacht, dass der Hauptbus alle Einheiten verbindet und jede Einheit ihren eigenen Subbus hat. Bei deiner Anwendung mit nur einer "großen" Einheit ist dein System aber auch verständlich. Mein Vorschlag wäre daher den über den HBUS geführten Bus als Lokalbus und den für die Vernetzung der Moduleinheiten verwendeten Bus als Globalbus (Bezeichnung gefällt mir noch nicht) zu bezeichnen, so dass das für beide Anwendungen passt.


    Natürlich ist auch RS485 möglich, wo bei das ja nix mit SPI / I2C zu tun hat, man könnte ja quasi einen SPI über RS485 realisieren. Alternativ gäbe es ja auch für I2C noch ICs um die Reichweite zu erhöhen. Außerdem ist der Bus ja nicht so extrem lang, da du ja keine 1m langen Hutschienen in deinen Schaltschrank setzen wirst (oder doch?). Zur Not müsste man die Einheiten dann kleiner wählen / trennen und über den Globalbus verbinden. Dann würde eine Einheit nur noch so aus 3-5 Modulen bestehen.


    Zum scannen des Busses würde ich vorschlagen, dass das jedes Modul für sich macht. dann würde es auch möglich sein das System im laufenden Betrieb zu erweitern. Das würde in etwa so ablaufen, dass das Modul, wenn es auf den Bus gesteckt wird alle möglichen Adressen anpingt und wenn keine Antwort kommt diese Adresse dann übernimmt. (Gut bei über 100 möglichen Adressen dauert das ein wenig, aber das System kann man bestimmt noch optimieren) Oder das Modul fragt bei dem Hauptmodul/Adressverwaltungsmodul an, welche Adresse/Adressen noch frei sind. (beides erfordert jedoch den Multimaster-Betrieb, wäre jedoch auch für die Haussteuerung/den Globalbus geignet. Erinnert mich iergendwie an DHCP)
    Die Daisy Chains würde ich für die Kommunikation zwischen nebeneinadner liegenden Modulen vorsehen, wenn diese nur zusammen funktionieren und z.B. eine schnelle Anbindung untereinander benötigen oder sich gegenseitig IO-Signale senden, z.B. für Interrupts. (Oder um einfach nur abzufragen, ob ein Nachbar vorhanden ist)


    Der Hausbus sollte meiner Meinung nach mit maximal 4 Leitungen auskommen: GND, 5-24V (nur zur Versorgung der Steuerungen, nicht jedoch für die "Last"), Signal+ und Signal-


    Der HBUS würde dann so aussehen (Teilweise von dir übernommen)
    - 4 Signale für RS485/Bus
    - Spannungsversorgung 5-24V (Spannungsregler auf jedem Modul, wobei bei 5V für Peripherie eher 8-24V nötig wären. Möglich wäre ja auch 2 Leitungen zu nehmen und einmal 5V und einmal 24V oder so (welchen Sinn das auch immer machen würde)
    - Masse Leitung soviele wie Versorgungsleitungen, macht anders auch keinen Sinn. (bei 2x 12V also auch 2xGND)
    - Die Daisy-Chains also für die Kommunikation zwischen benachbarten Modulen


    Die Spannungsversorgung für externe Komponenten, z.B. SSRs würde ich an jedem Modul (das diese Versorgung benötigt) seperat anschließen.
    Auch wäre bei mir nach maximal 10 Modulen sowieso Schluss, würde ja immerhin von der Länge einer Reihe von 40 Sicherungsautomaten entsprechen!
    Mit den Interrupt-Signalen würde ich das so handhaben, dass wenn eine wichtige Übertragung nötig wird, das jeweilige Modul eine Gemeinsame Interrupt-Leitung auf Masse zieht, dann wissen alle Module bescheid, dass die aktuelle Kommunikation zu beenden ist. Anschließend muss das anfordernde Modul noch eine Bestätigung bekommen, dass es jetzt senden darf (es sei den man bekommt das über iergendwelche Pakete auf dem Bus gemanaged). Die Interrupt anforderung könnte man ja mit 12V/der Versorgungsspannung realisieren, damit geringe Störungen keine Auswirkungen daruf haben.


    Somit wären jetzt 4+4+2=10 bzw. 4+6+2=12 (je nach Spannungsversorgung) durchkontaktierte Leitungen belegt

  • Hallo nb-light,


    zunächst mal: Freut mich, dass Du Dich mit Deinen Ideen an diesem Thema beteiligst!

    Machen wir es doch so: Nennen wir den HBUS einfach HBUS. :)
    Alles was "extern" angeschlossen ist, ist halt extern. Das kann (und wird, bei Hausautomation) RS485 sein, aber auch ein beliebiges anderes Bussystem. Hängt dann ja nur vom jeweiligen Bus-Connctor-Modul ab.


    Natürlich kann es Installationen mit zwei und mehr HBUS-Systemen geben, was Du als "Moduleinheit" bezeichnet hast.
    Also: Jede Moduleinheit kommuniziert intern über den HBUS. Liegen solche Moduleinheiten räumlich weit auseinander, also z.B. in einem Haus, im Schaltkasten jedes Stockwerks je eine Moduleinheit, dann läuft die Kommunikation zwischen den Stockwerken über einen geeigneten Bus, der wohl in aller Regel RS485 sein wird, wobei auch andere Bussysteme denkbar sind.
    Aber RS485 bietet sich in einem solchen Fall aus zwei Gründen an:
    1) Wegen der Störsicherheit, nebst der Möglichkeit, sehr lange Leitungslängen einzusetzen.
    2) Weil schon der HBUS im Wesentlichen auf RS485 basiert, folglich in den meisten Fällen kein Bus-Connector-Modul erforderlich ist.


    Zitat

    man könnte ja quasi einen SPI über RS485 realisieren.

    Ja, aber das hatten wir früher schon: Dazu wären bei vier SPI-Signalen satte 8 Leitungen erforderlich. Biserl viel.


    Zitat

    Alternativ
    gäbe es ja auch für I2C noch ICs um die Reichweite zu erhöhen.

    Ja, aber da muss man schauen, was der Regelfall ist.
    Im Regelfall kommt der HBUS zum Einsatz. Da sind die Strecken kurz genug um direkt I2C zu verwenden.
    Bei längeren Strecken könnte man zwar solche ICs einsetzen, aber die Frage ist: Warum?
    Wenn man die große Datenmasse sowieso mit 2,5MHz über RS485 schaufelt, kann man sich das doch schenken, oder?


    Ich bin inzwischen echt auf dem Tripp, I2C nicht gesondert über den HBUS zu führen, sondern sämtliche Kommunikation (außer der Sache mit den Daisy-Chains, zur Initialisierung) über RS485 auf dem HBUS zu jagen.
    Den kann man dann eben auch direkt verlängern und externe Moduleinheiten oder sonstige Teilnehmer direkt dranhängen.
    Wie erwähnt: In jedem Modul steckt sowieso ein HBUS-Decoder, mit AVR, an den man I2C-Komponenten anschließen kann.


    Zitat

    Außerdem
    ist der Bus ja nicht so extrem lang, da du ja keine 1m langen
    Hutschienen in deinen Schaltschrank setzen wirst (oder doch?).

    Doch, davon gehe ich aus.
    Wobei 1m für I2C noch lange kein Problem darstellt. Aber I2C will ich (inzwischen) dennoch nicht mehr direkt führen.
    Ich denke an Anwendungen, wie bei dem Karussell: Bedientableau in der Kasse, kommuniziert über ein einziges MoSteuS-Modul, über eine 15m lange Leitung mit der eigentlichen MoSteuS-Steuerung (bestehend aus mehreren Modulen auf dem HBUS) im Schaltschrank des Karussells.
    So eine Installation sollte mit geringsmöglichem Aufwand möglich sein, also ohne explizitem Bus-Connector-Modul.
    Einfach den RS485-Teil vom HBUS im Schaltschrank verlängert und zur Kasse geführt, wo ein einzelnes Modul sitzt, an das die ganzen Taster angeschlossen sind.


    Bei solcher Leitungslänge ist kein direkter Einsatz von I2C mehr realistisch. Aber wenn auf beiden Enden I2C zum Einsatz kommen soll, ist das dennoch möglich, weil jeder HBUS-Cecoder einen "frischen" AVR beinhaltet, an dessen I2C-Port dann die nötigen Komponenten vor Ort angeschlossen werden können.
    Die Kommunikation zwischen Schaltschrank und Kasse aber rein über RS485.


    Zitat

    Zur Not
    müsste man die Einheiten dann kleiner wählen / trennen und über den
    Globalbus verbinden. Dann würde eine Einheit nur noch so aus 3-5 Modulen
    bestehen.

    Ja, das ist die natürliche Option, die immer zur Verfügung steht, wenn es "zuviel" wird.
    Aber dieses "Zuviel" sollte IMHO erst in wirklich seltenen Fällen auftreten. Nicht schon nach 3-5 Modulen. Ansonsten quält man sich in der Praxis dauernd mit Einspeisemodulen und Bus-Connector-Modulen rum, was Aufwand und Kosten echt in die Höhe treibt.
    Die sollten meiner Meinung nach nur in seltenen Fällen notwendig werden.


    Puh, der Controller muss ja auch wissen, WAS er da am Bus hat.
    Es reicht ja nicht, dass jedes Modul "irgendeine Adresse" hat, sondern der Controller, als "Hauptmaster", in dem das eigentliche Programm läuft, muss wissen, welche Datenpakete er an welches Modul senden soll.
    Ich wüsste bei Deinem Ansatz nicht, wie das gehen soll. Vielleicht habe ich ja auch nur diese Multimasterei noch nicht richtig begriffen.
    Woher weiß der Hauptcontroller, das am 5. Modul die Lampen hängen und am 8. Modul die Rolladenmotoren?


    Bei meinem Ansatz sieht es halt so aus, dass der Controller, von seinem Programm her, durchaus schon weiß, was auf dem Bus sitzt und was daran angeschlossen ist.
    Aber weil alle HBUS-Decoder in den Modulen von der Hardware und Firmware her identisch sind, und keine DIP-Schalter zum Einsatz kommen sollen, für die Adresseinstellung, weist der Controller den Modulen über die beiden Daisy-Chains zunächst ihre jeweiligen Adressen zu.
    Ist das einmal geschehen, spricht er sie immer über die zugewiesenen Adressen an. Ab da ist es auch wurscht, ob man zwischendurch ausschaltet, Module umsteckt, also gegeneinander vertauscht und wieder einschaltet. Jedes Modul behält die einmal zugewiesene(n) Adresse(n), bis gegebenenfalls eine neue Initialisierung durchläuft.


    Zitat

    Der Hausbus sollte meiner Meinung nach mit maximal 4 Leitungen
    auskommen: GND, 5-24V (nur zur Versorgung der Steuerungen, nicht jedoch
    für die "Last"), Signal+ und Signal-

    Vier Leitungen sind gut. In manchen Fällen auch nur zwei. So denke ich mir das ebenfalls.
    Da müsste man aber nochmal schauen, was in der Hausautomatisierung so Standard ist, damit wir das ohne Verrenkungen und ohne Bus-Connector-Module direkt mit unterstützen können.


    Zitat

    - Spannungsversorgung 5-24V (Spannungsregler auf jedem Modul, wobei bei
    5V für Peripherie eher 8-24V nötig wären. Möglich wäre ja auch 2
    Leitungen zu nehmen und einmal 5V und einmal 24V oder so (welchen Sinn
    das auch immer machen würde)

    Die Spannungsversorgung sollte mit gleichgerichten 8V vom Klingeltrafo (also etwa 11V) funktionieren und bis 24V betragen dürfen, für den Einsatz in Schaltschränken, wo schon SPS zum Einsatz kommt und 24V ohnehin vorhanden sind.


    Warum bin ich inzwischen auf eine Versorgungsspannung von mehr als stabilisierten 5V eingeschossen?
    - Nun, abgesehen davon, dass eine Stabilisierung vor Ort sowieso günstiger ist, braucht man erstens kein Mords-Netzteil mit stabilen 5V, sondern kann so ziemlich jede schon vorhandene Spannungsquelle nehmen, die einfach nur genug Strom liefert.
    Zweitens ermöglicht das ohne Zusatzaufwand das Ansteuern von Highside-MOSFETS. Die nötige, hohe Gate-Spannung ist schon vorhanden, muss also nicht erst per Ladungspumpe oder sonstwie erzeugt werden.


    Zitat

    Die Spannungsversorgung für externe Komponenten, z.B. SSRs würde ich an
    jedem Modul (das diese Versorgung benötigt) seperat anschließen.

    Ja, Module mit hohem Stromverbrauch soll man direkt einspeisen können.
    Was aber häufig vorkommen wird (bei mir zumindest) ist der Fall, dass ein Modul viele SSRs treibt. Da muss ich 20mA pro Kanal vorsehen.
    Die typische Modulgröße könnte 4x8 oder maximal 4x10 Kanäle treiben, wobei dann jedoch kein Platz mehr zur Verfügung steht, für einen Einspeisestecker.
    Deshalb möchte ich mehrere solcher Module auch ohne Direkteinspeisung, einfach über den HBUS versorgen. Zumindest da, wo es geht.
    Wenn es gar zu viele Module werden, oder gar zu hohe Treiberlasten, muss natürlich unumgänglich zwischendurch erneut eingespeist werden. Aber das sollte der selten nötige Ausnahmefall bleiben.


    (Grmbl, Posting schon wieder über 10.000 Zeichen, Forsetzung gleich ...)

  • Fortsetzung:

    Zitat

    Auch wäre bei mir nach maximal 10 Modulen sowieso Schluss, würde ja
    immerhin von der Länge einer Reihe von 40 Sicherungsautomaten
    entsprechen!

    Da möchte ich lediglich etwas größer werden können.
    Denke halt an einen Schaltschrank mit mehreren, langen Hutschienen, der richtig was tut.
    Man kann dann jede Hutschiene gesondert einspeisen, sogar von beiden Seiten. Aber nur maximal 10 Module, bis wieder eine Einspeisung erforderlich wird, wäre mir zu wenig. Das erreicht man doch zu häufig.


    Zitat

    Mit den Interrupt-Signalen würde ich das so handhaben, dass wenn eine
    wichtige Übertragung nötig wird, das jeweilige Modul eine Gemeinsame
    Interrupt-Leitung auf Masse zieht, dann wissen alle Module bescheid,
    dass die aktuelle Kommunikation zu beenden ist.

    Das war mein ursprünglicher Ansatz.
    Auf einer einzelnen Hutschiene, von überschaubarer Länge wäre das auch praktikabel. Aber wenn man nur so kleine Systeme im Blick hat, dann braucht man auch gar nicht über RS485 zu gehen, dann könnte man auf dem HBUS auch bei SPI (bzw. SPIn) und I2C bleiben.
    Nun haben wir hier aber früher schon so viel diskutiert und uns auf RS485 eingeschossen, was ja wesentlich längere Verbindungen ermöglicht, dass ich nicht wieder einen neuen Flaschenhals einbauen möchte, mit einem empfindlichen Signal, das nur geringe Länge ermöglicht.


    Ich sage es mal ehrlich: Ich bin generell kein Freund von Interrupts.
    Wo immer es geht, würde ich Polling bevorzugen. Man bedenke, dass Module oft einen AVR beinhalten und lokale Interrupts selbst abhandeln können.
    Es geht also nur noch um solche Interrupts, die von einem beliebigen Modul unbedingt an den Hauptcontroller gesendet werden müssen.
    Da schwebt mir eine Art des Pollings vor, die sehr schnelle Reaktionszeiten ermöglicht und innerhalb des RS485-Datenstroms abgehandelt wird.


    Prinzip: Der Hauptcontroller sendet ab und an einen Sendeberechtigungs-Befehl an alle Module.
    Jedes Modul setzt dann in einem bestimmten Zeitfenster ein einziges Bit. Alle Module jedoch leicht zeitversetzt.
    Das mit dem Zeitversatz ist leicht möglich, weil jedes Modul eine eigene Adresse hat. Diese Adresse beinhaltet zugleich die Information, an welcher Stelle das Modul im Zeitfenster sein Interrupt-Bit im RS485-Datenstrom setzen darf.


    Beispiel: Sitzen zusätzlich zum Controller noch 8 Module auf dem Bus und sendet jedes Modul sein jeweiliges Bit um ein Bit zeitversetzt, dann kommt beim Controller ein serielles Byte an, anhand dessen der Controller genau weiß, welches Modul "was zu sagen hat".
    Dieses pollt er dann gezielt an, worauf es seine eigentliche Botschaft sendet.
    Haben mehrere Module ihr jeweiliges Bit gesetzt, ist das kein Problem, kommt ja konfliktlos beim Controller an. Er entscheidet dann, in welcher Reihenfolge er die Module anpollt.
    Aber er pollt wirklich nur dann, wenn es auch Grund dafür gibt! Das hält den Traffic gering.
    Ansonsten stellt er nur ab und an, wenn er dazu bereit ist, sein Zeitfenster zur Verfügung.


    Das Prinzip ist also ein Mittelding, zwischen echtem Interrupt, welcher jederzeit gnadenlos dazwischen funkt, und langwierigem Polloing aller Module, obwohl gar keine Notwendigkeit besteht, Daten zu "scannen".
    Vielmehr sagt der Controller: "Liebe Module, jetzt bin ich bereit zuzuhören, wer hat was zu melden?" - worauf die Module dann antworten (oder auch nicht).


    In jedem Fall kann man sowas softwaremäßig leicht kapseln. Der Anwender soll sich damit gar nicht rumschlagen müssen (ist ja das Prinzip von MoSteuS, es dem Anwender leicht zu machen). Den Protokollkram erledigen die HBUS-Controller und includete Subroutinen.
    Bis hierhin ohne echte Interrupts, was stabile, unkritische Programme ermöglicht.
    Wie oft der Controller das Zeitfenster für die Quasi-Interrupts zur Verfügung stellt, entscheidet dann allein der Anwender, der das programmiert, anhand seiner individuellen Anfroderungen.
    Was dann so alles abläuft, muss den Anwender aber nicht mehr kümmern, das kann er hinzu includen und muss dann nur noch darauf reagieren, mit seiner Software.
    Ist halt wie bei einem gebufferten UART, mit mehreren Bytes Tiefe, wo man die Bytes bei Bedarf abholt, wenn man Zeit dafür hat.
    Nur quasi auf den Kopf gestellt - die Bytes trudeln erst dann ein, wenn der Controller über sein Zeitfenster (einen gesendeten Befehl) Bereitschaft an alle Module signalisiert, jetzt die Bytes abzuholen.

  • Ok dann haben wir jetzt den HBUS und den externen Bus, beide Busse nutzen RS485.


    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)
    Interessant ist, dass mein Bus-Connector-Modul dir zu teuer und zu aufwendig ist, du jedoch in jedes Modul einen HBUS-Dekoder einbauen willst. Des weiteren würde ich wenn dierekt den Bus-Connector in den jeweiligen Hauptcontroller des HBUSes integrieren.
    Das mit der Spannungsversorgung über den HBUS wird schon Klappen, die Frage wäre halt ob 2 oder 3 Leitungen (jeweils für GND und VCC). Bei Größerer Last müsste man dann zwischeneinspeisungen einbauen. (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.
    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)
    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.
    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.


    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)


    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).
    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. Der Hauptkontroller kennt somit alle Module mit deren FUnktion und der jeweiligen Adresse. 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)


    So das war es erst einmal von meiner Seite


    Gruß
    Karsten