Nun wird Gleis 1 etwas nach Norden versetzt – dort war ja das oben erwähnte Ladegleis, es ist also Platz – und der Bahnsteig wird entsprechend verbreitert und auf die normale Höhe der S-Bahnen angehoben. Während der ersten Hälfte der Bauarbeiten verkehren die Züge Wasserburg – Grafing Bf nur bis Ebersberg, die bis München durchgebundenen Züge sowie die S-Bahnen verkehren normal.

Leider wird der sogenannte “Westzugang” mit Fußgängerunterführung aus Kostengründen nicht realisiert und somit bleibt Gleis 1 wahrscheinlich weiterhin ein Stumpfgleis mit entsprechenden Einschränkungen für flexibleren Verkehr. Bleibt zu hoffen, dass der für 2013 geplante Begegnungsbahnhof in Steinhöring planmäßig angegangen wird und ab dann ein dichterer Takt möglich wird.

Heute folgte ein zweiter Anlauf, wieder mit dem LD-W-33, der diesmal gelang. Im Unterschied zum ersten Umbau habe ich heute eine Drossel zwischen der Gehäusemasse und der Motorrückleitung entfernt. Die Drossel hätte ich beinahe wieder übersehen und damit den Dekoder vermutlich wieder gegrillt, schließlich warnt die Anleitung explizit davor, die Gehäusemasse mit der Rückleitung zu verbinden. Das Modell hat folglich heute die Programmierung, die diesmal im DCC-Protokol mit derECoS 2 erfolgte, auch gut überstanden. Die Fahreigenschaften des umgebauten Modells sind auf Anhieb deutlich besser als zuletzt im Analogbetrieb.

Vor der ersten Inbetriebnahme sollte man die Anleitung gründlich durcharbeiten. Ich tat das leider nicht und war daher für zwei Tage unzufrieden mit dem Fahrverhalten, bis ich die Stelle fand, die die Einstellung der richtigen Gleisspannung nahelegte. Kaum war die Spannung von niedrigen 14 V auf die für H0-Dreileiter üblichen 19 V angehoben fuhren alle Modelle wieder mindestens so gut, wie mit der bisherigen Zentrale.

Danach standen erste Versuche mit dem DCC-Protokoll auf dem Plan: Die im November digitalisierte 212 besaß bereits einen DCC-fähigen Dekoder und war daher das geeignete “Opfer”. Man kann komfortabel die Lokparameter auslesen und verändern ohne sie von der normalen Strecke nehmen zu müssen. Im Vergleich zur DCC-Programmierung kommt mir die bisherige MM-Programmierung mit der 6021 steinzeitlich vor.

Vor zwei Wochen kamen dann die Weichen dran: Ein paar günstig ergatterte gebrauchte k83-Dekoder haben mich nun auch bei den Weichen aus der analogen Zeit geholt. Äußerst komfortabel geht darüberhinaus die Einrichtung von Fahrstraßen mit der ECoS 2 von der Hand. Weichen und Fahrstraßen kann man dann – um es perfekt zu machen – auf einem Gleisbildstellpult grafisch anordnen. Wieder kam mir die bisherige Praxis der Stellpulte sehr altmodisch vor.

In Kürze folgen nun noch die Signale. Dazu habe ich mir eine Reihe von günstigen Signaldecodern basierend auf dem WeichZwei bestellt, die die nächsten Tage eintreffen sollten.

Das Fazit: Die ECoS 2 war nicht gerade billig aber dennoch eine gute Entscheidung. Um den jetzt in kurzer Zeit erreichten Stand basierend auf der alten 6021 zu erreichen wären ähnliche hohe Investitionen in veraltete Technik nötig gewesen. Alternativ hätte ich mich auch mit SRCP und DDL/DDW befassen können und damit vermutlich etwas Geld gespart… aber viel mehr Zeit investiert. Da ich beruflich schon genug vor dem PC sitze und mich mit Sourcecode und Konfigurationsdateien beschäftige muss ich das beim Modellbahnhobby nicht auch noch haben.

Laut ersten Stellungnahme der DB Regio war der äußerst aggressive Preis, den Veolia Verkehr geboten hat, wohl ausschlaggebend für die BEG. Zusätzlich mögen die diversen Baustellen auf den KBS 950 und 951 die letzten Jahre eine Rolle gespielt haben, obwohl die Baustellen und die Gestaltung des Schienenersatzverkehrs eher auf das Konto von DB Netz geht und auch Veolia zukünftig nicht von derartigen Störungen verschont bleiben wird. Bleibt zu hoffen, dass die ca. 200 Beschäftigten von DB Regio aus Freilassing und Rosenheim beim neuen Betreiber unterkommen oder aber zum Beispiel zur SüdostBayernBahn wechseln können.

DB Regio betreibt auf der Strecke seit den 90ern einen Zwei-Stunden-Takt mit RE-Zügen von Salzburg nach München. Seit Dezember 2001 wurde dieser mit RB-Zügen auf einen Stundentakt verdichtet. Für mich, der damals in Aßling gewohnt hat, war das ein SPNV-Quantensprung. Bis dahin hatten wir an Werktagen eine Handvoll Regionalszüge die in Aßling, Ostermünchen und Großkarolinenfeld hielten und größtenteils nicht bis nach München sondern nur nach Grafing Bahnhof fuhren. Ab der Einführung des festen RB-Taktes im Dezember 2001 wurde dieser schrittweise verdichtet, so dass nun die Orte zwischen Rosenheim und Grafing Bahnhof an Werktagen fast durchgehend stündlichen Bahnanschluß haben. Mit meinem Umzug 2005 hat sich die regelmäßige Nutzung dieser Züge erledigt. Wenn dann steige ich in Grafing Bahnhof in einen dieser Züge um oder wir unternehmen gelegentlich Ausflüge ins Chiemgau oder nach Salzburg. Im Herbst 2008 gab es nochmal eine deutliche Verbesserung: Die Hälfte der Züge wurde auf Doppelstock-Wagen umgestellt. Leider spürte man das zusätzliche Platzangebot nicht lange. An Wochenenden sind Stehplätze in diesen Zügen weiterhin häufig.

Mit der Übernahme durch Veolia ab Dezember 2013 wird es einen Stundentakt zwischen Salzburg und München geben ohne Halt zwischen Rosenheim und München Ost, einen Stundentakt zwischen Kufstein und München mit Halt an allen Stationen, einen Stundentakt zwischen Rosenheim und Holzkirchen mit halbstündiger Verdichtung und Verlängerung nach München zur Hauptverkehrszeit und zusätzlich als Option “Expresszüge” zwischen Traunstein und München.

DB Regio und ihren Mitarbeitern möchte ich schonmal danken für die vielen i.d.R. relativ pünktlichen Fahrten mit und auch für viele lustige Erlebnisse in den Zügen.

Von Veolia und dem bayrischen Verkehrsministerium (als Besteller der Leistungen) wünsche ich mir ein paar Dinge:

• Ausreichend dimensionierte Garnituren: Möglicherweise wären zumindest für die Züge nach Salzburg Stadler KISS statt der angebotenen Stadler FLIRT 2 sinnvoller gewesen.
• Ein brauchbares Fahrgastinformationssystem mit Echt-Zeit-Verspätungsprognosen nicht nur in den Zügen sondern auch an den Bahnhöfen und im Internet, damit man z.B. mit seinem Smartphone auf einer einzigen Seite alle Zugfahrten an einem Bahnhof ablesen kann, egal zu welchem EVU der jeweilige Zug gehört.
• Sinnvolle Umsteigemöglichkeiten in Rosenheim von Grafing Bahnhof, Aßling, Ostermünchen und Großkarolinenfeld kommend in Richtung Salzburg und umgekehrt.

20. Dezember

Es trudeln Meldungen zweier User ein, dass sich das Webmail komisch verhalte. Der Mailabruf per POP3 oder IMAP4 ist nicht komplett ausgefallen jedoch führt ein EXPUNGE zu Ende der TCP-Connection… und das Webmail möchte beim öffnen eines Ordner erstmal ein EXPUNGE ausführen. Im Logfile äußerst sich das so:

cyrus/master[7067]: service imap pid 8873 in BUSY state: terminated abnormally

Später gesellen sich noch Meldungen folgender Art dazu:

cyrus/imaps[11644]: DBERROR db4: 24 lockers

Okay, führe ich also ein manuelles Recovery der Cyrus-Datenbanken durch und… nichts ändert sich. Eine Recherche bei Google nach der ersten Fehlermeldung führt zu der Empfehlung Cyrus upzudaten und der Einheizkater schließt sich dieser Empfehlung an. Kommt mir zwar komisch vor, wo es doch bis vor wenigen Stunden noch funktioniert hat, aber in meiner Ratlosigkeit versuche ich das und… es funktioniert wieder.

Damit war das Thema für mich erstmal erledigt, doch es sollte wieder auf meinen Tisch zurückkommen.

22. Dezember

Wir fahren über die Weihnachtsfeiertage zur schwäbischen Verwandschaft. Dort angekommen fehlt mir die Motivation nochmal den Rechner anzuwerfen, daher merke ich erstmal nicht, dass bei Cyrus schon wieder etwas im Argen ist. Im Logfile finde ich später Meldungen folgender Art:

couldn't connect to lmtpd: Connection timed out_ 421 4.3.0 deliver: couldn't connect to lmtpd_

23. Dezember

Nagios begrüßt mich mit zwei Mails, der POP3- und IMAP4-Dienst seien gegen 5:23 ausgefallen. Zu der Zeit findet ein täglicher Restart der Cyrus-Dienste statt um liegengebliebene Prozesse – die leider bei TLS/SSL-verschlüsselten Sessions häufig auftreten – abzuräumen. Ich schaue dem System in die Eingeweide und stelle fest, dass ein cyr_expire-Prozess beinahe alle CPU-Leistung auffrisst aber nichts tut. Nach einem Versuch Cyrus per Restart zu motivieren finde ich das hier im Log:

cyrus/cyr_expire[19078]: DBERROR db4: PANIC: fatal region error detected; run recovery
cyrus/cyr_expire[19078]: DBERROR: critical database situation

Aha, das erinnert mich wieder an die Meldungen vom 20. Dezember. Also nochmal ein manuelles Recovery versucht, leider wieder ohne Verbesserung. Nach etwas Recherche wird mir klar dass cyr_expire sich um deliver.db bearbeitet, das normale Recovery jedoch mailboxes.db und annotations.db repariert. Da ich nichts finde, dass mir für eine Reparatur der deliver.db gedacht erscheint, benenne ich die Datei um und starte Cyrus ein weiteres Mal neu und… siehe da: Es läuft wieder.

26. Dezember

Wieder beglückt mich Nagios mit zwei Mails am Morgen. Der Server war von ca. 23:20 bis 01:10 nicht erreichbar. Nach einem Blick im Logfile ist er in der Zeit tatsächlich tot gewesen, wurde um 01:10 wieder gestartet und um 03:20 nochmals. Ich vermute einen kleinen Stromausfall in einem Teil des beheimatenden RZ. Mal sehen was der Betreiber dazu sagt. Nach obigen Cyrus-Incidents und einem unpuscheligen Bootsektor Anfang des Monats wünsche ich mir etwas Ruhe an dieser Baustelle.

Als Ersatz gibt es bei Hetzner schon längere auf Anfrage stundenweise die sogenannte LARA, die ich bisher zum Glück nicht gebraucht habe. Die LARA wird an die Keyboard-, Video- und Mouse-Anschlüsse angeschlossen und bietet dem Kunden dann über ein Java-Applet Zugriff auf seinen Server. Damit hat man sogar etwas mehr Möglichkeiten als mit einer seriellen Konsole, da man mit der LARA auch den Bootvorgang boch vor dem Bootloader beobachten kann. Im Notfall muss man aber erst eine Supportanfrage absetzen und drauf hoffen, dass zeitnah eine LARA verfügbar ist.

Als Zwischenlösung gibt es seit etwas über einem Jahr auch VKVM bei Hetzner. Dabei wird der Server über das Netzwerk in ein Rescue-System geboot und darin eine VM gestartet, auf die man per VNC zugreifen kann. Diese VM kann dann das System von der Platte des Servers starten, so dass man den kompletten Bootvorgang miterleben kann.

Nachdem ich nun auch einen noch nicht produktiven Server zur Hand hatte, um das mal auszuprobieren, habe ich die Gelegenheit genutzt. Besser man macht sich vorab mit dem Feature vertraut anstatt erst im Notfall wenn man dann eh schon aufgeregt ist und die Zeit knapp ist.

Als erstes wählt man im Hetzner Robot bei seinem Server unter Rescue VKVM in der zur Installation passenden Variante aus. Man erfährt sofort URL und Zugangsdaten der VKVM-Konsole. Nicht wundern braucht man sich darüber, dass die URL auf die Haupt-IP-Adresse des eigenen Servers verweist. Nun löst man den Restart des Servers aus; entweder per Reboot auf dem Server selbst oder – wenn dieser nicht mehr erreichbar ist – über den Hetzner Robot. Es dauert nun einige Zeit bis das Rescue-Virtualisierungs-System hochgefahren ist. Nach einiger Zeit kann man dann per Java-fähigemBrowser auf die genannte URL zugreifen und sich mit den genannten Zugangsdaten anmelden. Es startet ein Java-Applet über dass man Zugriff auf die Konsole des virtualisierten Systems erhält. In dieser Konsole sieht man nun eine etwas verwirrende Boot-Schleife, bei der scheinbar versucht wird, das lokale System zu starten, was jedoch nicht klappen mag. Des rätsels Lösung ist, auf folgende Frage mit Q zu antworten:

Boot from (N)etwork or (Q)uit?

Erst dadurch wird der Bootloader auf der Festplatte des eigenen Systems gestartet, der Default N bietet hingegen weitere Diagnose- und Rescue-Möglichkeiten an aber nichtden Zugriff auf das installierte System. Einen weiteren Fallstrick gibt es nun beim Start des installierten Systems: Benutzt man einen Kernel, der auf Hardware-Virtualisierungstechniken angewiesen ist, z.B. mit Xen-Support, so scheitert der Start, denn man ist ja bereits in einer virtuellen Umgebung in der keine Hardware-Virtualisierungstechniken mehr verfügbar sein können.

Hat man auch diese Hürde geschafft startet endlich das installierte System und ist dann auch aus dem Internet z.B. per SSH erreichbar, was für Arbeiten an den Konfigurationsdateien sicherlich etwas angenehmer ist als der Zugriff über die Konsole im Java-Applet.

Verzwickt ist zum Schluss nochmal der Wechsel zurück zum “echten” System. Die Menüpunkte des Java-Applets, die einen Strg+Alt+Entf senden lassen bzw. einen Hardware-Reset durchführen lassen wirken sich nur auf die virtuelle Umgebung aus, d.h. man verläßt damit das Rescue-VKVM-System nicht. Erst durch einen richtigen Reboot aus dem Hetzner-Robot kommt man hier wieder raus.

Fazit: Von der Handhabung her etwas komplizierter als eine serielle Konsole her, von den Diagnose- und Reparaturmöglichkeiten möglicherweise sogar etwas besser.

…bis es dann zwischen Grafing Bahnhof und Grafing Stadt zu einer Schnellbremsung mit gut durchgeschüttelten Fahrgästen kam. Kurz nach dem Stillstand des Zuges meldete sich der Tf: “Unsere Weiterfahrt verzögert sich um unbestimmte Zeit, vor uns steht ein Auto.” Entweder wollte da noch jemand schnell die Halbschranken des BÜ umrunden oder das Auto verstarb direkt auf dem Bahnübergang.

Passiert ist zum Glück nichts weiter, nach wenigen Minuten war das Hinderniss aus dem Weg und unsere Regionalbahn konnte weiterfahren. Ob aber ein der sonst dort noch fahrenden 423er rechtzeitig zum Stillstand gekommen wäre bezweifle ich.

Wenn man SchlundTech als Registrar benutzt ist die Vorgehensweise allerdings etwas trickreich: Ich musste den IPv6-Glue-Record per Leerzeichen getrennt im Feld des IPv4-Glue-Record eingeben, alle anderen Varianten – ein explizites Feld für IPv6-Glue-Records existiert nicht – warfen mir Fehlermeldungen um die Schlappohren.

Gespannt bin ich nun, ob die nächste Änderung des IPv4-Glue-Records für meine .net-Domain direkt klappen wird. Bisher war ich entweder auf manuelle Eingriffe des Support angewiesen oder aber musste den IPv4-Glue-Records durch ein Leerzeichen getrennt direkt im Feld des DNS-Server-Namens eingeben.

Nach meinen bisher durchweg positiven Erfahrungen mit dem Tams-Dekodern (gut, zwei Dekoder habe ich beim Einbau “gegrillt”) sollte es auch nun wieder ein Dekoder von Tams sein. Diesmal fiel die Wahl auf den LD-W-32, bisher hatte ich fast nur die älteren LD-W-3 und LD-G-3 verbaut.

Die Vorgehensweise dürfte in MoBa-Kreisen bekannt sein: Alten Umschalter ausbauen (wenn der neue Dekoder bereits mit Kabeln bestückt ist, kann man i.d.R. fast alle alten Kabel herauslöten), neuen Dekoder isoliert befestigen, damit es keinen Kurzschluß gibt, die Kabel auf eine sinnvolle Länge kürzen und neu verlöten.

Zusätzlich lohnt es sich, bei der Gelegenheit gleich noch nötige Wartungsarbeiten zu erledigen, sonst hat man danach ein digitalisiertes Fahrzeug, dessen Fahreigenschaften aber enttäuschen. Also zerlegt man noch den typischen Märklin-Motor (vorher die Federn der Bürsten/Schleifkohlen beiseite nehmen). Auf der Innenseite des Ankerschilds hat sich Abrieb der Bürsten bzw. Schleifkohlen angesammelt; dieser sollte entfernt werden. Ebenso hat sich solcher Abrieb am Kollektor in den Ritzen gesammelt, wo er die Stromaufnahme des Modells unnötig erhöht und im schlechtesten Fall Kurzschlüsse produziert.

Nach der Entfernung des Abriebs sollte man bei gebraucht erworbenen Modellen gleich noch überschüssiges Öl und/oder Fett entfernen. Viele Modellbahner scheinen ihre Modelle nach dem Motto “viel hilft viel” zu ölen bzw. zu fetten. Danach stellt man noch sicher, dass an den relevanten Stellen der Ankerwelle und des Getriebes etwas (wenig!) Fett vorhanden ist, und setzt den Motor wieder zusammen. Bei meinem heutigen Umbau sah ich leider Getriebezahnräder, deren Seitenflächen gut gefettet waren, wohingegen die Laufflächen  staubtrocken waren…

Nachdem man nun das Modell gesäubert, gereinigt, ggf. dezent gefettet und mit dem Digitaldekoder bestückt hat, steht noch eine verzwickte Kleinigkeit an: Der Dekoder will programmiert werden. Der grundsätzliche Vorgang ist in der Anleitung gut beschrieben; jedoch hapert es bei zwei kleinen Details: Diverse Register können mit Werten zwischen 0 und 255 belegt werden, meine alte Central Unit (Artikelnummer 6021) kann jedoch nur Werte zwischen 1 und 80 senden. Hierfür hat Tams ein “Hintertürchen” (das leider in der Druckfassung der Anleitung noch fehlte) vorgesehen. Man kann das Register 62 zu Hilfe nehmen. Dort hinterlegte Werte werden beim Speichern der anderen Register vervierfacht, zum eingegebenen Wert addiert und dann ins eigentliche Register gespeichert. Möchte man also den Wert 255 in das Register X speichern, dann speichert man zuerst den Wert 63 ins Register 62 und danach den Rest 3 ins Register X. Tatsächlich wird dann 63*4+3=255 ins Register X gespeichert. Einen Weg, um den Wert 0 mit der 6021 speichern zu können, habe ich leider noch nicht gefunden.

Hat man die Klippen der Registerprogrammierung mit diesen Dekodern umschifft, muss man noch ein wenig mit den Werten für die Anfahr- und Maximalspannung und ggf. Anfahr-Kick, Beschleunigungs- und Bremsrate sowie der Motorfrequenz herumprobieren.

Die Anfahrspannung war ab Werk auf 40/255 eingestellt, was ich schrittweise auf 75/255 anheben musste. Bei niedrigeren Werten hört man die Motorsteuerung zwar vorher schon arbeiten, was der Lok jedoch nur “Jaulen”, aber keine Bewegung entlockt. Mit einer alternativen Motorfrequenz von 60 Hz war das “Jaulen” zwar weg, dafür ruckelte die Lok im niedrigen Geschwindigkeitsbereich deutlich. Die Maximalspannung habe ich auf 143/255 festgelegt, damit die 212 nicht zu schnell unterwegs ist.

Der Anfahr-Kick sorgt dafür, das Losbrechmoment zu überwinden, indem mit der Fahrstufe 4 (Werkseinstellung) angefahren wird, danach jedoch sofort abgebremst wird. Die Einstellung ab Werk hat sich bei mir als für die 212 geeignet herausgestellt. An den Werten für die Beschleunigungs- und Bremsraten habe ich keine Veränderungen vorgenommen.

Die konkreten Werte dürften für jeden Motor- und Getriebetyp abweichen; daher empfiehlt es sich, für Versuche genug Zeit mitzubringen. Die Unterschiede im Fahrverhalten sind doch deutlich spürbar. Für mich hat sich dabei als sinnvolle Vorgehensweise herausgestellt, zuerst die Maximalspannung und damit den Geschwindigkeitsbereich zu begrenzen. Damit kann man das Modell im verbleibenden Geschwindigkeitsbereich sofort feiner steuern. Danach habe ich den Anfahr-Kick deaktiviert, um davon ungestört die niedrigste Anfahrspannung “suchen” zu können. Zu guter Letzt habe ich den Anfahr-Kick wieder aktiviert, damit die Lok auch in Kurven und an Steigungen anfahren kann.