Hallo,
im 2. Teil von 2015 geht es darum alles zu Testen bevor ich alles mit Bauten und Landschaft zubaue, spätere Änderungen sind dann nur schwer zu machen.
Als ich den Lückenschluss gemacht hatte, konnte ich jede Menge Züge gleichzeitig fahren lassen. Dabei ist mir mit iTrain dann aufgefallen, dass mein alter betagter Rechner (PC, ehemals Server) das nicht mehr gepackt hat. Vor allem wenn im Hintergrund noch von Windows Updates gekommen sind und installiert wurden. Die Auslastung nur durch iTrain betrug knapp 75%, wenn dann noch was im Hintergrund gelaufen ist, machte sich das dann durch Fehler auf der Anlage bemerkbar, weil Rückmeldungen verspätet bei iTrain angekommen sind.
Aufgrund der Erfahrung und Hilfestellung bzw. Erfahrungsaustausch im iTrain-Forum habe ich den PC etwas „Aufgepimpt“. Alter Stand: AMD Athlon 2,4 GHz Single-Core. Das Motherboard mit Prozessor habe ich gegen ein Quad-Core 4x1,5 GHz ausgetauscht, weil ich vernommen habe, die Geschwindigkeit ist nicht so entscheidend aber die Mehrprozessor-Technologie bringt da mehr, statt 3 GB Ram hat er dann 12 GB bekommen und statt einer S-ATA Festplatte habe ich eine SSD eingebaut. Die ersten Eindrücke waren auch nicht so schlecht, nur die Reaktionszeit bei der Bedienung in iTrain war dann doch eher etwas träge bzw. verzögert. Vermutete erst das, dass an der Grafikkarte auf dem Motherboard liegt und habe eine extra Grafikkarte mit 2 GB RAM nachgerüstet, leider brachte das nichts an dem verzögerten Reaktionsverhalten.
Es gab aber einen deutlichen Unterschied bei der Prozessorauslastung, mit iTrain war der Prozessor kaum oder selten mehr als 50% ausgelastet, auch Updates im Hintergrund machten sich fast nicht mehr bemerkbar außer das die Reaktion bei der Bedienung noch schlechter geworden ist.
Aber das Problem, dass der Rechner mit iTrain und Hintergrundprozesse überfordert war, war dann behoben.
Nun habe ich auch reichlich Züge auf die Anlage gestellt und fahren lassen und musste dann allerdings wieder feststellen, nachdem ich „Start All“ gedrückt habe und 30 Züge gleichzeitig sich in Bewegung setzten, dass ich wieder jede Menge Fehlermeldungen erhalten habe, weil Rückmeldungen einfach nicht rechtzeitig bei iTrain angekommen sind.
Ich steigerte die Anzahl gleichzeitig fahrender Züge dann langsam und allmählich, bis 17 ging alles noch ohne Probleme, ab dann ging es mit sporadischen Fehlern los, ab 24 gab es dann so viele Fehler bei der Positionierung aufgrund der verspäteten Rückmeldungen, dass es einfach keinen Spaß mehr machte. An dem PC lag es also nicht, er war ja nur mit max. 50% ausgelastet als die Fehler aufgetreten sind, es muss also an was nach dem PC liegen. Habe dann den Netzwerkanschluss zur Zentrale auf Gigabit-LAN umgestellt um eine Verzögerung an der Schnittstelle mal auszuschließen, war leider erfolglos, die Ecos kann, wenn überhaupt, nur 100Mbit aber der Versuch war recht schnell und günstig zu machen.
Habe mich dann mit der Eigenschaft der Netzwerk-Schnittstelle beschäftigt, eine andere Schnittstelle hat ja die Ecos nicht sonst hätte ich alternativ eine andere testen können.
Die Erkenntnis daraus war, dass eine Netzwerkschnittstelle sehr schnell ist große Datenmengen zu transportieren aber doch recht langsam ist wenn es viele kleine Daten sind. Wer schon mal innerhalb eines Netzwerks Daten kopiert oder verschoben hat, hat das mit Sicherheit schon mal selbst feststellen können, dass Große Dateien aber wenige schneller übertragen werden wie viele kleine Dateien. Zudem kommt dann auch noch der Effekt, dass in einem Haus-Netz mit Internetanschluss per Router auch jede Menge anderer Traffic unterwegs ist der die Ecos und iTrain gar nicht interessiert aber ausbremst.
Also habe ich versuchsweise den PC und Ecos isoliert miteinander verbunden also direkt nur PC und Ecos, das war zwar etwas besser geworden aber dennoch inakzeptabel, max. 21 Züge.
OK, das ist halt dann so dachte ich mir und bremste die max. gleichzeitig fahrenden Züge per Wartezeiten in iTrain aus und begnügte mich damit oder habe mich damit abgefunden.
Auch die Übertragung am Gleisanschluss bzw. Bus habe ich mir angeschaut, weil ich immer wieder feststellen musste, dass Weichen und Signale verspätet oder gar nicht geschalten haben. Eine Fehlstellung der Weichen konnte ich relativ schnell lokalisieren, weil die ESU Switchpilot Decoder per RailCom eine Weichenrückmeldung meiner Fleischmann Magnetantriebe lieferten und die zu iTrain auch übertragen wurden.
Dahinter gekommen bin ich nicht so wirklich aber es liegt in der Sache wie alles übertagen wird.
Als ich mir dann RaiCom Rückmelder von ESU anschaffte bemerkte ich dann was sich schädlich auf das Gleissignal bzw. RailCom Rückmeldung auswirkte.
Die Ecos hat einen globalen RC-Empfänger für den Switchpilot, erst mit den RC-Rückmeldern kann die Adresse von Loks in einem Block identifiziert werden und da merkte ich dann was die RC-Rückmeldung störte, es waren die ganz banalen Glühlampen die in so manchen beleuchteten Wagen noch vorhanden waren. Nachdem ich alle Glühlampen aus den Wagen entferne und zum größten Teil durch LED-Streifen ersetzte war das auch schon besser. Die RC-Adressmeldung bei den Rückmeldern wurde nicht mehr gestört und die Weichenrückmeldung vom Switchpilot war auch zuverlässiger geworden.
Zwischen den S88 Belegtmeldern und den nicht überwachten Streckenabschnitten bemerkte ich einen Spannungsunterschied von knapp 1,4V der sich je nach Lok und Decoder in der Geschwindigkeit bemerkbar machte. Als ich dann nachgeforscht habe wie man das beheben kann stieß ich dann auf folgende Schaltungen um das auszugleichen.
Spannungsgleichheit-2.PNG
IMG_4390.JPG
Der Wiederstand dazwischen ist wichtig, damit die RaiCom Rückmeldungen zur Zentrale übertragen werden können. Das hat auch erst mal prima funktioniert, sollte sich aber später als erneutes Problem herausstellen, weil die Bauteile in der DCC-Versorgung der nicht überwachten Gleisabschnitte das Signal verfälscht und beeinträchtigt haben. Aus heutiger Sicht ist es besser einen Belegtmelderausgang für die nicht überwachten Gleisabschnitte zu verwenden, da wird das Gleissignal nicht so stark beeinflusst und es entsteht nahezu kein Spannungsunterschied mehr zwischen den Gleisabschnitten.
Das Größte Problem bei zu großen Spannungsunterschieden zwischen den Gleisabschnitten ist allerdings, dass der Strom lieber über den Teil abfließt der das höhere Spannungspotential hat. Das wirkte sich dann so aus, dass erst wenn die Lok komplett in den Abschnitt mit niedrigeren Spannungspotential eingefahren war, erst dann eine Rückmeldung in dem Abschnitt erfolgte, was wiederum zu Problemen bei der Positioniergenauigkeit führte weil die Offsetwerte der Lok für die Rückmeldung nie wirklich stimmten.
Ende 2015 kam dann von ESU ein Firmware Update was jede Menge Software-Hersteller Probleme bereitet hat da die Befehls- und Melde-Syntax der Ecos doch zum Teil erheblich abgeändert worden war. Das hat mich mit iTrain auch getroffen und konnte den Betrieb der Anlage nur eingeschränkt nutzen bzw. musste ich den Leagasy-Modus bei der Ecos aktivieren damit ich einen Betrieb überhaupt machen konnte.
Zwischen den beiden Modis stellte ich dann per Netzwerk-Schnüffel-Software folgende Unterschiede fest.
Ecos Leagacymode.PNG
W7_leagacy_normal.PNG
Links die alte und rechts die neue Syntax beim Schalten einer Weiche was zur Folge hatte, dass ein Auswerten der Weichenstellung per Software nicht mehr so ohne weiteres möglich war bzw. Fehler behaftet ist weil die Stellung der Weiche nicht mehr als OK gemeldet wurde, sondern nur noch ein Fehler. Die Software musste also dann davon ausgehen, dass wenn keine Meldung gekommen ist alles OK war, das ist sehr unsicher und macht die Weichenrückmeldung unbrauchbar, weil sie nicht wirklich zuverlässig funktionierte.
Des Weiteren tauchten Geister-Rückmeldungen vom SwitchPilot per RailCom auf, einige Weichen sendeten ständig Meldungen obwohl die Weiche gar nicht betätigt wurde. Auf Nachfrage bei ESU direkt oder im ESU-Forum bzw. beim Support habe ich bis heute noch keine Antwort darauf erhalten.
Also musste ich mich selber auf die Suche machen, habe dann feststellen müssen, dass nur der SwitchPilot V1.0 davon betroffen war, allerdings ein Firmware-Update ist bei dem, um den Fehler zu beheben, nicht möglich da es bei dem keine Möglichkeit für ein Update gibt. Da ich einige davon gehabt habe blieb mir nur eines übrig, die Weichenrückmeldung zu deaktivieren, weil sonst ständig sporadische Fehler aufgetreten sind.
Zu den Fehlern bei den RailCom Rückmeldern gab es auch noch weitere Fehler die mich sehr viel Zeit gekostet haben, weil ESU die Fehler auf die Software-Hersteller abgewälzt hat und die Software-Hersteller schoben die Schuld auf ESU, was für den Verbraucher oder Anwender eine recht ärgerliche Situation darstellt und habe dann versucht beide zu vermitteln damit sie miteinander das Problem lösen. Ein Stück weit ist mir das gelungen doch die Weichenrückmeldung wurde bisher nicht wieder optimiert, dass sie wie vor dem Update zuverlässig funktionierte.
Auch bei anderen Dingen musste ich immer wieder feststellen, dass manches einfach nicht mit der Ecos zu machen war und ich mich ernsthaft nach alternativen umschaute.
Folgendes ist mit der Ecos schlichtweg nicht möglich:
- Eine vernünftige Drehscheibensteuerung damit anzusteuern oder zu betreiben, es geht nur die Märklin Schnittstelle und das auch nur im Motorola Format, ein TT-DEC von LDT muss auch im MM Format betrieben werden damit der mit der Ecos funktioniert. Ich muss also für die Handbedienung per Ecos das MM-Format einschalten was ein hässliches Lichtflackern bei den Loks zur Folge hat, weil die Glühlämpchen für die Spitzenbeleuchtung zumeist auf Masse sprich einer Schienenseite den + beziehen, eine Isolierung der Glühlampen und Versorgung per + vom Decoder ist in Spur-N fast nicht möglich, höchstens eine Umrüstung auf eine LED-Beleuchtung was ein immenser Aufwand wäre.
Auch die Möglichkeit per Ecos und Lokdecoder die Drehscheibe zu betreiben geht gar nicht per Software wie iTrain, weil die Ecos schlichtweg die Ansteuerung der Drehscheibe nicht auf der Netzwerk-Schnittstelle zur Verfügung stellt, es ist höchstens ein Handbetrieb per Ecos möglich. Beide Punkte habe ich schon kurz nach Kauf an ESU herangetragen und sogar mehrmals per Mali sogar direkt bei den Geschäftsführern angebracht, auch in einem persönlichen Gespräch auf Messen, leider bis heute Erfolglos, schade.
- Die Ecos unterstützt keine Möglichkeit der Lokprogrammierung per POM und Software, sie hat nur die Möglichkeit, dass die zu programmierende Lok auf das Programmiergleis geholt werden muss und nur dort kann sie per CV und externer Software programmiert werden.
Eine Möglichkeit eine Lok direkt aus iTrain und das im Betrieb per POM auf der Anlage zu machen geht also nicht mit der Ecos, nur an der Ecos aber nicht von extern. Auf Nachfrage bei ESU bekam ich zur Antwort, dass die Ecos dann intern ein Konkurrenz-Produkt zum Lokprogrammer ist und das nicht vorgesehen ist. Also laut ESU ist der Lokprogrammer zu verwenden damit es einfach und schnell geht (den muss man sich allerdings dann erst kaufen 
).
- Der Strom- Spannungs und Temperatur-Monitor wird auch nicht an der Schnittstelle ausgegeben, was inzwischen sehr viele Zentralen ermöglichen.
- Mit RailCom Rückmelder kann nur eine Lok im Rückmelderbereich identifiziert werden, andere können bis zu vier in einem Rügmelder.
- QOS hat ESU noch nicht wirklich verstanden was damit alles angezeigt werden kann und findet es auch für nicht notwendig so etwas zu haben, wird also nicht kommen, auch nicht in absehbarer Zeit.
- Das schon längst bemängelte Fehlen einer Möglichkeit einen RailCom Decoder per Software anzulegen wird immer wieder vergessen und verschoben.
Da kam jetzt in mir der Gedanke auf ob ESU die Ecos sterben lässt oder gar eine neue Zentrale in nächster Zeit kommt oder sie die Zentrale schlichtweg nur vernachlässigen, weil sie zu sehr damit beschäftigt sind andere Produkte zu entwickeln. Außerdem musste ich immer wieder feststellen, dass auf N-Bahner nicht wirklich Rücksicht oder war genommen wird. Auch schade.
Über Weihnachten hatte ich mir dann zwei mögliche Kandidaten ausgesucht.
Weiter geht es dann in 2016.
Gruß
Gerd
Sie haben keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
