Rocomotion 10785 und S88 - es funktioniert
Zusammenfassung der Erkenntnisse:
Es gibt hier verschiedene Threads über das Rocomotion 10785 von Roco, das als Einsteigerset ja durchaus häufiger vertreten ist.
Interessant daran ist, dass eine ganz brauchbare Software beiliegt (bzw. herunterladbar ist), auch wenn diese inzwischen nicht mehr ganz taufrisch ist. Als gravierender Mangel wurde der Zwang zur Verwendung propietärer Rückmeldebausteine 10787 aufgeführt – eine von Roco marketingtechnisch gute aber für den Anwender schlechte, weil kostspielige, Lösung. Zusätzlich zu diesen Bausteinen wird noch ein Belegtmelder benötigt, wenn man nicht ausschließlich mit Punktmeldern, also Schaltschwellen (Reedkontakte) oder Kontaktgleisen arbeiten möchte. Das treibt die Kosten weiter in die Höhe.
Als Abhilfe taucht mehrfach der Ratschlag auf, Rocomotion ganz aufzugeben und an dessen Stelle eine Vollversion vom Traincontroller zu erwerben und ein weiteres Interface einzusetzen. Für meine Begriffe ist das zwar technisch sauber, aber eben auch für erste Versuche finanziell recht aufwendig, zumal wenn ein Rocomotion 10785 schon vorhanden ist. Außerdem gibt es noch die Gruppe der Besitzer einer Multimaus pro, deren Zentrale (Multizentrale pro) wohl auch über diese Rückmeldetechnologie verfügt.
Sinnvoll erscheint mir der Einsatz von S88-Rückmeldern – auch weil da ganz zufällig zwei Exemplare des SMS88 von Sven Brandt (
www.digital-bahn.de) herumlagen. Ob es noch von anderen Anbietern S88-Module mit integrierten Belegtmeldern und in potentialfreier Ausführung angeboten werden, habe ich nicht untersucht.
Die zweite Variante wäre die Nutzung von Baugruppen mit dem RS-Interface vom Rückmeldebus der Firma Lenz. Auf der Leiterplatte ist ein RS-Bus-Master mit vorgesehen, da ich ja einen Umsetzer von eben diesem Bus nach S88 testen möchte, um damit die Brücke zu BiDiB zu schlagen. Für den RS-Bus-Master gibt es aber noch keine Software, aber denkbar wäre auch dessen Nutzung für die Versorgung des Rocomotion mit Daten.
Nachdem mehrfach über die Technik dieses „Rückmeldebusses“ von Roco diskutiert wurde, habe ich, nachdem mich auch ein Modellbahnkollege angesprochen hatte, mir die Sache nach Erwerb einer Rocomotion 10785 näher betrachtet. Das Ergebnis ist, dass es keinen eigenen Rückmeldebus gibt. Die entsprechend beschriftete Buchse ist einfach ein durchgeleiteter Anschluss des Roconet, technisch also ein RS485-Bus mit maximal 32 Teilnehmern, basierend auf dem von Lenz gesetzten Standard des Xpressnet (Xbus) in der Version 3.0, also 62500bd, 9bit, 1 Stoppbit, keine Parität halbduplex. Als Schlussfolgerung bleibt nur, dass das Rocomotion auch nur ein normales Xbus-Gerät sein kann – die „Zentrale“, also der Busmaster, steckt ja in der Multimaus. Unklar war mir nur, wie die einzelnen Rückmelder 10787 auf dem Bus mit dem Interface kommunizieren. Da maximal 20
Module anschließbar sind, war es unwahrscheinlich, dass jedes Modul eine eigene Adresse am Xbus bekommen muss.
Dann kam die weitere Erkundung dieser Digitalbaugruppe etwas ins Stocken, da andere Themen (OpenDCC - MFT) mir wichtigen waren und mir auch keine Rückmeldemodule 10787 zur Analyse zur Verfügung standen. Leider blieben auch Anfragen nach leihweiser Überlassung in verschiedenen Foren ohne jedes Ergebnis. Da mich aber Alles was mit dem Xbus zusammenhängt interessiert, habe ich vor kurzem bei ebay zugeschlagen und 3 Module erworben, um die Analyse endlich abzuschließen – es liegen genug angefangene Projekte auf dem Tisch herum. Das ist nun auch gelungen. Das Ergebnis ist, dass den Modulen über das Rocomotion lediglich eine Nummer zugeordnet wird. Roco nennt das „Programmieren einer Adresse“, allerdings ist das keine Adresse im Sinne einer Xbus-Adresse und wird meinen Beobachtungen nach nie in einem Callbyte des Roconet direkt angesprochen, sondern eben nur eine Reihenfolge festgelegt. Die Abfrage der Rückmelder erfolgt, indem das Rocomotion einen Xbus-Frame sendet, den die Rückmeldemodule mithören und in dem die aktiven Module in der programmierten Reihenfolge jeweils ein Byte, was den Zustand ihrer 8 Eingänge (low..frei, high..belegt) repräsentiert, auf den Bus legen. Die von den Rückmeldern gesendeten Daten erfasst das Rocomotion und ermittelt daraus und aus den restlichen Daten des Frames einen CRC-Wert, der abschließend gesendet wird. Damit ist es den Modulen möglich zu erfahren, dass die Datenübertragung erfolgreich war. Sendet ein Rückmelder 10787 keine Daten, legt das Rocomotion nach einer kurzen Wartezeit selbst ein Nullbyte auf den Bus.
Die undokumentierten Xbus-Frames von Roco nutzen einen invertierten CRC. Damit wird erreicht, dass „normale“, also dem Lenz-Standard entsprechende Xbus-Geräte, solche Frames wegen der für sie falschen Checksumme grundsätzlich verwerfen. Das Senden dieses speziellen Frames wird ausschließlich von der Software auf dem PC veranlasst; das Rocomotion wird nicht von alleine tätig. Außerdem besitzt das Rocomotion eine eigene Spannungsversorgung für das Roconet und speist alle hinter ihm angeschlossenen Module.
Nun war zu untersuchen, ob die Beobachtungen richtig waren oder ob da versteckte Fallen lauern – proof of concept war angesagt, also ein Machbarkeitsnachweis.
Da ohnehin zu Testzwecken eine Baugruppe für das Umsetzen von RS-Bus zu S88 im BiDiB-Umfeld entwickelt werden sollte, habe ich schnell noch einen S88-Master und einen Xbus-Anschluss mit draufgepackt. Nachdem diese Leiterplatten vor wenigen Tagen angekommen sind, ging es nach schnellem Bestücken auch gleich an den Test der zwischenzeitlich geschriebenen (Test-)Software. Der Roconet-Teil wurde aus einer vorhandenen Lösung für den Xbus adaptiert und der S88-Teil neu geschrieben – sehr aufwändig ist das ja nicht.
Bei der Inbetriebnahme stellten sich (wie immer, wenn es schnell gehen musste) kleinere Fehler heraus. Um alles auf eine Platine zu bekommen habe ich bewusst sehr kurze RJ45- (S88) und RJ11- (Roconet) Buchsen gewählt, aber eben beim Erstellen der Footprints in der Eile nicht gepeilt, dass die Kontakte unten und nicht oben sind – also wurden die Pins seitenverkehrt bezeichnet. Das ist aber schnell durch spezielle gedrehte Kabel zu beheben – die sollte man aber nicht mit den normalen Versionen verwechseln, dann raucht es. Blöder war das Nichtbeachten der enable-Eingänge des 74HC241, da halfen nur eine Drahtbrücke und die Trennung eines Leiterzugs.
Die Stromversorgung des Moduls erfolgt über das Roconet; da ich aber die Stromaufnahme in den verschiedenen Betriebszuständen noch nicht gemessen habe, habe ich zusätzlich ein externes Steckernetzteil vorgesehen, da bei einem Vollausbau immerhin 20 S88-Module zu versorgen sind. Bei den beiden bei mir vorhandenen Modulen SMS88 reicht die Versorgung durch das Roconet vollkommen aus.
Nach dem Entwanzen des Programms wurde im Traincontroller schnell eine kleine virtuelle Anlage zusammengeklickt und yeeaah, das Ganze spielt sauber zusammen. TC erkennt die Belegtmeldungen und wertet sie richtig aus – reicht für mich als Bestätigung, dass die Untersuchungen und Erkenntnisse richtig waren.
Was kann das Modul (bzw. dessen Assembler-Software) im jetzigen Zustand?
Auf dem Modul werkelt ein AVR ATMega162 mit 16MHz, die Verbindung zum Roconet stellt ein ST485-Treiberbaustein her und der S88 ist über einen 74HC241 (nichtinvertierender Bustreiber) angebunden. Dazu kommt noch ein Spannungsregler (Schaltregler Traco), der die eingespeisten 12V des Roconet (bzw. eines externen Netzteils) auf die 5V für die eigene Schaltung und die Versorgung der S88-Bausteine passend macht. Dazu kommen noch ein paar Leds und ein serieller und potentialgetrennter (ADuM1201) Monitorausgang (deswegen auch der ATMega162 mit 2 seriellen Ports) sowie ein LCD-Port (HC44780 im 4-Bit-Betrieb). Die beiden letzten Teile existieren nur in der Hardware, die Inbetriebnahme ging auch so recht problemlos. Ein ATMega88 sollte aber eigentlich für diese Teilfunktion vollkommen ausreichen – untersucht habe ich das aber nicht. Mechanisch passt die Leiterplatte in ein Pactec-CNL-Gehäuse. S88-seitig ist eine RJ45-Buchse vorgesehen, an die die maximal möglichen 20 Module angeschlossen werden können. Möglich wäre auch die Nutzung von 2 getrennten Bussen, damit ein „in der Mitte sitzendes“ Modul zwei Stränge bedienen kann.
Die Software erkennt aus den ganzen Inquiry-Telegrammen auf dem Roconet den Frame mit der Rückmelderabfrage und merkt sich die Adresse des Rocomotion, damit danach weniger Rechenleistung zur Busbeobachtung benötigt wird. Ich bin mir nicht sicher, ob das Modul immer auf der gleichen Adresse liegt, deshalb dieser Part. Nebenher wird der S88 abgefragt. Nach meinen Versuchen kann man da relativ sportlich takten, zumindest die beiden SMS88 machen bei 60µs Periodendauer keine Probleme. Die ausgelesenen Daten werden dann bei der nächsten Abfrage an das Rocomotion geliefert. Ein kompletter S88-Abfragezyklus (160 Bits) dauert rund 9,6ms.
Die Daten werden durch das Rocomotion aller 32ms abgefragt, wenn nur das Rocomotion tätig ist. Kurbelt man tüchtig an der Multimaus herum oder sind noch weitere Roconet-Geräte aktiv, verlängert sich der Umlaufzyklus. Für den ersten Wurf habe ich auf dem S88-Bus auch auf das Reset-Signal (das brauchen eigentlich nur die klassisch aufgebauten Module mit 4044-RS-Latch) verzichtet und die Module von Sven Brandt funktionieren trotzdem einwandfrei.
Der Machbarkeitsnachweis ist aus meiner Sicht also vollauf gelungen, man müsste nicht zwingend die proprietäre Roco-Technik nutzen und kann erste Schritte relativ preiswert machen und Erfahrungen mit der Software sammeln. Weiß aber nicht, wie Roco das sieht….
Arbeit bliebe noch jede Menge übrig, die Software ist zu vervollständigen bzw. sauber neu zu schreiben und die Hardware neu zu designen, Gehäuseeinbau vorsehen, ggf. die Spannungsversorgung überarbeiten und als wesentlichster Teil Tests mit mehr Modulen (ev. auch von anderen Herstellern) und eben mit einer realen Anlage vornehmen. Außerdem wäre das Feld Multizentrale pro testweise zu beackern – ich nehme zwar ganz stark an, dass dort die gleiche Technik verwendet wird, aber man weiß ja nie, ob da ein paar zusätzliche Gemeinheiten eingebaut wurden. Und ganz wichtig ist dabei die Kostenminimierung, darf ja wie immer nix kosten, wie mir auch beim Interface per Mail mitgeteilt wurde.
Ich werde das wohl nicht weiter verfolgen; meine technische Neugier zum Roconet ist befriedigt, eine mit S88-Technik ausgerüstete Anlage habe ich nicht (und auch nicht vor zu bauen) und die für mich neue Herausforderung BiDiB von OpenDCC reizt mich momentan deutlich mehr.
Vielleicht will sich ja jemand damit weiter beschäftigen und kann die Vorarbeiten nutzen, deshalb auch die Ablage hier. Kann auch von der Moderation wieder gelöscht werden, falls Roco da Ärger machen sollte.
Gruß
Thomas
irgendwo anders angestöppselt...
