Der
MohBus ist das zentrale Datenaustausch-Medium von MoSteuS.
Hardwareseitig kommen Komponenten der Firma Phoenix Contact zum Einsatz, die dort als "HBUS" bezeichnet werden.
Zu Anfang übernahm ich diese Bezeichnung, hielt später aber eine Abgrenzung für notwendig, durch einen eigenen Namen für das Bussystem von MoSteuS.
Auf dem Bild sieht man mehrere Hutschienenmodule, die einfach auf die Busverbinder von Phoenix Contact aufgeschnappt werden, die wiederum direkt in die Hutschiene eingeschnappt sind.
Der besondere Vorteil ist der, dass aus einer solchen Anordnung Module einfach direkt entnommen werden können, durch simple Entriegelung der Hutschienenklammer mit einem Schraubendreher und anschließendem Herausziehen der Module, gerade nach oben!
Man muss also nicht erst Teile seitlich wegschieben, wie z.B. von Hilfskontakten an Schützen gewohnt.
Die Busverbinder, die übrigens genauso breit sind, wie die aufgesteckten Modulgehäuse, werden durch seitliches Zusammenschieben elektrisch miteinander verbunden.
Dieses Konzept fand ich so überzeugend, dass ich bei MoSteuS darauf aufbaue! - Hatte ich doch schon vor bald 20 Jahren ein ähnliches System ersonnen, das es damals aber (soweit ich weiß) noch nicht gab und das ich mangels Kapital und Fertigungsmöglichkeiten nie umsetzen konnte.
Die Philosophie von MoSteuS ist halt die, dass JEDWEDER Defekt mit wenigen Handgriffen zu beheben sein soll.
Es soll möglich sein, zwischen zwei Fahrten eines Karussells schnell zum Schaltschrank im Mittelbau zu laufen, ein schadhaftes Modul zu identifizieren und auszutauschen!
Ganz ohne Lötarbeiten, ohne lange Schrauberei. ALLES gesteckt!
Damit das zuverlässig funktioniert, muss also eine robuste Datenkommunikation zwischen den Modulen her.
Bei Karussells ist es in aller Regel auch notwendig, dass Daten zwischen dem Bedienpult in der Kasse und einem Schaltschrank am Mittelbau des Karussells ausgetauscht werden. Da kommen schnell 20 Meter Leitungslänge in störverseuchter Umgebung zusammen.
Den Modulen stehen mit den Busverbindern 14 parallele Leitungen zur Verfügung, sowie zwei Daisy-Chains.
Doch entgegen dem
Vorgänger von MoSteuS setze ich beim aktuellen Konzept komplett auf serielle Datenübertragung per RS-485, statt auf TTL-Pegel und parallele Daten.
Das folgende Bild zeigt die Belegung zweier Busverbinder, die also in die Hutschiene eingeschnappt und dann seitlich zusammengeschoben werden:
Für die Kommunikation kommt bei MoSteuS - wie schon erwähnt - also RS-485 zum Einsatz, und zwar als Vierdraht-Bus.
Also Vollduplex, Master/Slave.
Im LedStyles-Forum ließ ich mich belehren, dass selbst 8-Bit AVRs bis zu 2 MBit/s über COM und RS-485 schaufeln können! Ein Systemtakt von 20 MHz und Assemblercode vorausgesetzt.
OK, mit reinem BASCOM wird man in der Realität oft weniger schaffen, aber dennoch lassen sich selbst große Lichtsteueranlagen damit realisieren.
Zumal man bei Bedarf ja auch mehrere "MoSteuS-Universen" einsetzen kann, etc. etc. Aber das ist ein anderes Thema.
Damit der Projektierer einer MoSteuS-Anlage es möglichst einfach hat, wird es ein paar "Normen" geben.
So ist vorgesehen, dass in jedem Modul eine Funktionseinheit sitzt (meistens in Form einer stets identischen, gesteckten Mini-Platine), die sich um die Anbindung des Moduls an den MohBus kümmert.
Diese Funktionseinheit nenne ich das "
MohBus-Gateway".
Das Gateway enthält im Wesentlichen nur einen RS-485-Transceiver und einen eigenen AVR (nebst Quarz) plus etwas Kleinkram.
Die geflashte Software im Controller eines jeden Gateways ist auch stets identisch und braucht normalerweise nie geändert zu werden.
Die Gateways kommunizieren relativ eigenständig mit dem Master-Modul und werden von diesem lediglich
parametriert, was sich auf den Inhalt des EEPROMs im AVR-Controller auswirkt.
Das macht es möglich, selbst komplexe Funktionen durch reines Zusammenstecken von Modulen zu realisieren, wobei im Normalfall nur das Mastermodul programmiert werden muss (es sei denn, ein Slave enthält noch einen zusätzlichen, eigenen Controller, der dann natürlich individuell geflasht werden muss).
Die MohBus-Gateways bilden also eine Funktionalität ab, die den Projektierer eines MoSteuS-Systems sehr weitgehend davon entlastet, sich um die Details der Datenübertragung kümmern zu müssen; sowohl was die Hardware, als auch die Software betrifft.
Wer eigene Module entwickeln will, die zu MoSteuS kompatibel sind, der sieht einfach einen Steckplatz für ein MohBus-Gateway vor und routet lediglich die entsprechenden, stets gleichen Kontakte an!
Die Software im Master-Modul parametriert bei der Inbetriebnahme einmalig die Gateways aller Slaves. Ansonsten kümmert sich der Programmierer nur um die Datenausgabe/-Abfrage und überlässt nervige Details den Gateways, denn diese übernehmen den Datentransport - nebst einigen Konvertierungsaufgaben - sozusagen selbst in sie Hand.
Die Gateway-Card in einem Slave kommuniziert auf MohBus-Seite also per RS-485 mit der Gateway-Card im Master-Modul.
Modul-intern wiederum stellt die Gateway-Card SPI, I2C und COM zur Verfügung, sowie ein paar weitere Portpins.
Die Parametrierung, die bei Inbetriebnahme vom Master zu jedem einzelnen Gateway in den Slaves gesendet wird, legt fest, welches Übertragungsprotokoll verwendet werden soll, ob das Modul Interrupts senden darf (oder lediglich gepollt wird) und was das Gateway im Slave-Modul so treibt.
Beispiel: Ein simples Protokoll weist ein Gateway an, per HBUS empfangene Daten Modul-intern per SPI auszugeben, um damit z.B. eine Kette von Schieberegistern auf der Grundplatine zu füttern, bzw. auszulesen.
Auch wenn ich mich wiederhole:
Der Programmierer muss so ein (mitunter aufwändiges) Protokoll nicht selbst stricken! Es steckt bereits im Flash des Gateways!
Der Programmierer muss lediglich auswählen, welches Protokoll verwendet werden soll; den Rest erledigen die Gateways eigenständig.
Module sind dadurch in aller Regel ohne Programmieraufwand direkt auswechselbar, z.B. im Falle eines Defekts!
Die Software in den Gateways ist ja stets identisch und ihre Parametrierung erhalten sie bei der Inbetriebnahme vom Master.
Im LedStyles-Forum gelang es mir nicht, den anderen Usern zu vermitteln, wie mit einer stets gleichen Programmierung der Gateways unterschiedliche Kommunikationsprotokolle gefahren werden können und was für immense Vorteile diese Technik bringt.
Selbst meinen Freund Hubert (HK-Datentechnik) konnte ich kürzlich am Telefon nicht davon überzeugen, ein 25 Meter entferntes SPI-Display, statt per einer dicken, mehradrigen Steuerleitung und
mehreren(!) RS-485 Kanälen, besser über eine einzige RS-485-Verbindung und meiner Gatewaytechnik anzusteuern.
Dabei ist so ein fertig programmiertes MohBus-Gateway einfach eine fertige Funktionseinheit; grob vergleichbar mit einem I2C-Baustein, auf einem steckbaren Platinchen.
Nun muss Hubert also erstens eine unnötig dicke Strippe zum Display ziehen und weiterhin für beide Seiten eine eigene Platine mit mehreren ICs entwerfen. Statt einfach auf beiden Seiten meine Gateways einzusetzen, mit wenigen Codezeilen so parametriert, dass sie SPI entgegen nehmen, diese Daten per Vierdraht RS-485 übertragen und am anderen Leitungsende wieder SPI ausgeben.
Die verschiedenen MoSteuS-Komponenten - so auch die Gateway-Card - werden später preiswerte Massenware werden, wie Arduino.
Dadurch leicht austauschbar, jederzeit nachkaufbar.
Die Gateways sollen sogar fertig geflasht angeboten werden. Einstecken und fertig!
Bei Huberts Ansatz sieht das anders aus. Er entwickelt für eine an sich simple Aufgabe nun zwei hoch spezielle Platinen, die er wahrscheinlich nie wieder benötigen wird. Geht sie beim Kunden kaputt und ist Hubert mal krank oder fällt anderweitig aus, steht sein Kunde im Regen.
Aus diesem Grund veröffentliche ich alles, rund um MoSteuS!
Alles ist Open Source / freie Hardware - alle Schaltpläne, Konstruktionspläne, alle Platinenlayouts, alle Quelltexte!
Voll piratig ey!
Jeder Anwender, der ein System projektiert, steckt also im Regelfall einfach fertige Komponenten zusammen. Etwa wie Lego-Bausteine, oder Fischertechnik.
Alle Komponenten anderweitig wiederverwendbar, also auch verkaufbar.
Die gesamte Konzeption macht es einfach, z.B. per Internet eine neue "Firmware" in ein System zu flashen. Der Master würde in diesem Fall einen Bootloader enthalten und wäre über ein gestecktes LAN/WLAN-Modul mit dem Router verbunden. Oder über eine GSM-Einheit sogar mobil.
Bei meinem
Vorgänger von MoSteuS steckte noch in jedem Modul ein individuell programmierter Chip, was einfache Updates einer Anlage, oder den einfachen Austausch eines schadhaften Moduls, unmöglich machte.
In den folgenden Postings gehe ich näher auf die Details der Hardware und Software der Gateways ein.
