Grüß Gott zusammen,
meine 18 321 von Märklin meldet sich an meiner ECoS nicht mehr an.
Fehlerbild:
Wenn ich die Lok auf mein Testgleis mit einer Mobilestation stelle, meldet sich die Lok einwandfrei an und funktioniert.
Wenn ich die Lok dann auf die Anlage stelle (gleiches gilt beim Programmiergleis), erscheint auf der ECoS kurz der grüne M4-Balken, verschwindet dann aber nach wenigen Sekunden und es passiert Nichts mehr.
Andere Loks melden sich ganz normal an und es funktioniert ansonsten alles.
M4 ab- und anschalten hat keine Lösung gebracht, ebenso Neustart.
Wenn ich die Lok dann auf das Testgleis mit der MS stelle, geht sie wieder.

Die Lok war früher schon mal an der ECoS angemeldet, erscheint aber in keiner Liste.

Ich habe den Decoder auch schon mit der Mobile Station zurückgesetzt. An der Mobile Station funktioniert die Lok weiterhin einwandfrei.

Im Setup-Menü der ECoS habe ich dann die auf dem Programmiergleis stehende Lok mit der Funktion „M4-Lok neu anmelden“ versucht, zum Laufen zu bekommen.

Ergebnis wie auf dem Bild zu sehen: Der Anmeldevorgang bricht ab.

ECoS II hat neuesten Softwarestand.

Hat jemand eine Idee?

Ergänzung:
Problem gelöst!

Es gibt im Setup1-Menü die Funktion „Schnellanmeldung“.

Nachdem ich diese deaktiviert hatte und dann unter Setup2 „M4-Lok neu anmelden“ gedrückt habe, hat sich die Lok ganz normal angemeldet und läuft wieder.

Hallo Michael,

wenn du die Lok von der ECoS wegnimmst und dann der MS2 wieder anbietest,
meldet sich die Lok normal an der MS2 an, oder gibt es keine Anmeldung und
man kann gleich mit ihr fahren?

Gruß est2fe

Da war doch auch mal was mit einer Funktion "verlorene mfx-Lok suchen" oder so ähnlich.
Weiss aber nicht gerade wo diese zu finden wäre.


NB: Ehrlich gesagt, diese Anmeldegeschichten haben mich dazu bewogen, wenn immer mögllich die Lok unter DCC zu fahren und natürlch auch unter DCC zu programmieren.

Moin,

wenn man mehrere Digitalprotokolle auf einer Zentrale zur Verfügung hat, sollte man auf die Verträglichkeit untereinander achten. So funktionieren mit Decodern der aktuellen Generation oftmals MM und DCC dann nicht gut zusammen, wenn im DCC-Signal die Austastlücken für RailCom sind. Die MS ist nicht in der Lage, diese Austastlücken zu erzeugen, die ECoS aber schon.

Hallo,

Zitat von Heinzi im Beitrag #3

---

Ehrlich gesagt, diese Anmeldegeschichten haben mich dazu bewogen, wenn immer mögllich die Lok unter DCC zu fahren und natürlch auch unter DCC zu programmieren.

---

Zitat von vikr im Beitrag #5

---

(und einen neuen Loklisteneintrag)

---

Moin Michael,

wenn du auf mfx / M4 verzichten kannst und der Decoder deiner BR 18 ein neuer ist, dann programmiere die Lok mit DCC. Das ist genauso gut wie mfx / M4.

Was anderes: Ist der Decoder mal aktualisiert worden? Dann kann es sein, das der Decoder zurückgesetzt wurde. Vielleicht wurde auch irttümlich was verstellt. Da gibt es dutzende Möglichkeiten.



Ich hab bei mir alle, bis auf 2, mfx Decoder rausgeschmissen und ESU LoPi 4 und 5 eingebaut. Aber das hatte den Hintergrund, das sich die Decoder in Rauch aufgelöst hatten.

Hallo Vic
Na ja, mit MFX it es schon etwas anders als du beschreibst. Jeder MFX-Decoder hat eine eindeutige ID. Dieser ID wird dann von der Zentrale ein "Name"/eine Adresse zugeordnet. Da wird nichts im Decoder programmiert, nur gelesen. Dass der Decoder richtig arbeitet, zeigt ja die Funktion mit der MS2. Das Problem liegt also entweder bei der Ecos mit ihere Software oder dem Benutzer.
Ich würde erst mal in der Ecos nach irgend welchen undefinierten bzw. nicht zuordenbaren Einträgen von Decodern suchen und die entweder testen oder löschen.

Hallo Joachim,

Zitat von JoWild im Beitrag #8

---

Das Problem liegt also entweder bei der Ecos mit ihere Software oder dem Benutzer.
Ich würde erst mal in der Ecos nach irgend welchen undefinierten bzw. nicht zuordenbaren Einträgen von Decodern suchen und die entweder testen oder löschen.

---

Zitat von est2fe im Beitrag #2

---

Hallo Michael,

wenn du die Lok von der ECoS wegnimmst und dann der MS2 wieder anbietest,
meldet sich die Lok normal an der MS2 an, oder gibt es keine Anmeldung und
man kann gleich mit ihr fahren?

Gruß est2fe

---

Zitat von E 44 im Beitrag #7

---

Moin Michael,

wenn du auf mfx / M4 verzichten kannst und der Decoder deiner BR 18 ein neuer ist, dann programmiere die Lok mit DCC. Das ist genauso gut wie mfx / M4.

Was anderes: Ist der Decoder mal aktualisiert worden? Dann kann es sein, das der Decoder zurückgesetzt wurde. Vielleicht wurde auch irttümlich was verstellt. Da gibt es dutzende Möglichkeiten.



Ich hab bei mir alle, bis auf 2, mfx Decoder rausgeschmissen und ESU LoPi 4 und 5 eingebaut. Aber das hatte den Hintergrund, das sich die Decoder in Rauch aufgelöst hatten.

---

Das Thema ist als gelöst markiert. Verrätst Du uns auch was nun die Lösung war?

Wie oben geschrieben:

Es gibt im Setup1-Menü die Funktion „Schnellanmeldung“.

Nachdem ich diese deaktiviert hatte und dann unter Setup2 „M4-Lok neu anmelden“ gedrückt habe, hat sich die Lok ganz normal angemeldet und läuft wieder.

Moin Michael,

das leben kann manchmal echt einfach sein, wenn man weiß wie es geht. Glückwunsch zur Fehlerbehebung

Hallo Michael,

Zitat von S3/6 im Beitrag #13

---

Wie oben geschrieben:

Es gibt im Setup1-Menü die Funktion „Schnellanmeldung“.

Nachdem ich diese deaktiviert hatte und dann unter Setup2 „M4-Lok neu anmelden“ gedrückt habe, hat sich die Lok ganz normal angemeldet und läuft wieder.

---

Hallo Joachim,

Zitat von JoWild im Beitrag #8

---

Na ja, mit MFX it es schon etwas anders als du beschreibst.

---

Zitat von JoWild im Beitrag #8

---

Jeder MFX-Decoder hat eine eindeutige ID. Dieser ID wird dann von der Zentrale ein "Name"/eine Adresse zugeordnet. Da wird nichts im Decoder programmiert, nur gelesen.

---

Zitat von JoWild im Beitrag #8

---

Dass der Decoder richtig arbeitet, zeigt ja die Funktion mit der MS2. Das Problem liegt also entweder bei der Ecos mit ihere Software oder dem Benutzer.

---

Zitat von JoWild im Beitrag #8

---

Ich würde erst mal in der Ecos nach irgend welchen undefinierten bzw. nicht zuordenbaren Einträgen von Decodern suchen und die entweder testen oder löschen.

---

Hallo, zusammen,

ob die gleiche SID an zwei Zentralen vergeben wird oder nicht, spielt keine Rolle. Der Dekoder merkt sich auch nicht nur die SID.

Nach der Anmeldung merkt sich der Dekoder auch die UID der Zentrale und den sogenannten Neuanmeldezähler. Lassen wir den letzteren der Einfachheit halber mal beiseite. Sobald der Dekoder Strom bekommt, schaut er, ob die aktuelle Zentrale die ist, bei der er zuletzt angemeldet war. Wenn ja, weiß er, dass die Zentrale ihn korrekt kennt und hört auf die Befehle, die diese Zentrale an seine SID, die er sich dazu natürlich auch gemerkt hat, sendet. Wenn er die UID der Zentrale nicht kennt, dann meldet er sich erneut an. Die SID spielt keine Rolle mehr, sie wird bei der Anmeldung neu vergeben. Eine Zentrale kann die SID eines Dekoders übrigens auch während des Betriebs problemlos wechseln.

Wenn die Zentrale gewechselt wird, muss sich der Dekoder neu anmelden. Das ist auch sinnvoll, denn der Dekoder kann nicht wissen, was in der Zwischenzeit passiert ist und was in der Zentrale schon gespeichert ist. Die Zentrale kann sich aber natürlich den Dekoder merken. Sie erkennt ihn während der Neuanmeldung an seiner UID (nicht der SID) wieder. Sie braucht dann die Eigenschaften des Dekoders nicht weiter auszulesen, sondern gibt ihm einfach wieder eine neue SID und kann ihn direkt bedienen. Das geht schneller, als alle Daten erneut auszulesen. Hat aber den Nachteil, dass in der Zwischenzeit geänderte Daten so an der Zentrale vorbei gehen - ESU beschreibt das ja im verlinkten FAQ. Deshalb war das ursprünglich nicht vorgesehen. Andererseits ändern sich gerade diese Dinge auch nicht so oft.

Diese Art der Schnellanmeldung hat mitnichten ESU erfunden. Die CS2 und CS3 machten das schon lange so.

Die CS2/3 ist auch bei der Erstanmeldung viel schneller als früher die CS1 oder die ECoS. Das liegt daran, dass die CS1/ECoS bei der Anmeldung immer den gesamten Config Space auslesen (also auch z.B. die Motorparameter), die CS2/3 aber nur das, was sie zum Fahren und Anzeigen braucht (also eben Name, Symbol, Funktionstasten und ihre Symbole, Tacho-Anzeige etc.). Dafür muss sie den Config Space auslesen, wenn man ins Config-Menü geht. Die CS1/ECoS ist wiederum hier schneller, denn sie hat ja schon alle Informationen. Das kann man so oder so machen. Allerdings ist es im Zusammenhang mit der später eingeführten Schnellanmeldung etwas ungünstig, denn so bekommt die ECoS auch beim Öffnen des Config-Menüs in der Zwischenzeit angefallene Änderungen nicht mit - daher der FAQ-Eintrag und die vorgeschlagene Prozedur. Aber wie gesagt, das ist nur notwendig, wenn man am Dekoder in der Zwischenzeit auf einer anderen Zentrale etwas geändert hat. Also eher selten.

Zurück zur Schnellanmeldung und dem beschriebenen Problem. Die ECoS hat hier vermutlich die mfx-Lok auch nach dem Zentralenwechsel zur MS2 in seinen internen Listen wiedergefunden und sie "schnellangemeldet". Damit war mfx-technisch für den Dekoder und die Zentrale alles in Ordnung. Allerdings hat die ECoS die Lok eben nicht wieder sichtbar gemacht - und damit konnte sie Michael nicht mehr finden und auf der ECoS auch nicht mehr fahren. Michael schrieb ja, dass er sie in allen Listen nicht mehr finden konnte, er hat sie also nicht übersehen (ist mir schon passiert) oder lediglich auf dem Regler erwartet. Auch das Neuanmelden geht so natürlich nicht, denn der Dekoder ist ja schon angemeldet. Durch das Abschalten der Schnellanmeldung hat die ECoS die Lok bei der Anmeldung komplett ausgelesen, den alten Eintrag in der internen Liste dabei gelöscht und neu angelegt. Und die Lok wieder am GUI angezeigt. Kann passieren

Grüße
Stefan

Hallo Stefan,

Zitat von Stefan Krauss im Beitrag #17

---

Die ECoS hat hier vermutlich die mfx-Lok auch nach dem Zentralenwechsel zur MS2 in seinen internen Listen wiedergefunden und sie "schnellangemeldet". Damit war mfx-technisch für den Dekoder und die Zentrale alles in Ordnung. Allerdings hat die ECoS die Lok eben nicht wieder sichtbar gemacht - und damit konnte sie Michael nicht mehr finden und auf der ECoS auch nicht mehr fahren. Michael schrieb ja, dass er sie in allen Listen nicht mehr finden konnte, er hat sie also nicht übersehen (ist mir schon passiert) oder lediglich auf dem Regler erwartet.

---

Zitat von Stefan Krauss im Beitrag #17

---

Auch das Neuanmelden geht so natürlich nicht, denn der Dekoder ist ja schon angemeldet.

---

Zitat von Stefan Krauss im Beitrag #17

---

Durch das Abschalten der Schnellanmeldung hat die ECoS die Lok bei der Anmeldung komplett ausgelesen, den alten Eintrag in der internen Liste dabei gelöscht und neu angelegt. Und die Lok wieder am GUI angezeigt. Kann passieren

---

Hallo Viktor,

das wird mal wieder ein Roman!

Die Sache mit der Zusammenarbeit zwischen Zentrale und den Steuerungsprogrammen ist etwas komplexer und so wie es bisher gelöst ist vermutlich der beste und einfachste Weg, um Komplikationen aus dem Weg zu gehen.
Die Zentrale ist der Master, fertig.
Deine im obigen Beitrag angesprochenen Probleme der Zusammenarbeit zwischen Zentrale und Steuerungsprogramm rühren immer daher, dass der Benutzer auf eine Art und Weise eingegriffen hat, die er nicht überblickt und sich daher selber in diese Situation hineinmanöviert hat. Sehr oft fehlt auch das technische Verständnis, was sich da im Hintergrund abspielt. Das ist aber kein Vorwurf an den Benutzer. Dieses Wissen wird leider nicht so im Detail der Öffentlichkeit in epischer Breite erklärt. Es gibt dazu leider keine Anleitungen in "einfacher Sprache". Das oben verlinkte Dokument ist für Programmierer geschrieben, und daher bewusst nicht für die Allgemeinheit geeignet. Ich habe bisher keine Beschreibung in "einfacher Sprache" gefunden/geschrieben. Das fehlt wirklich, wenn man sich die regelmässig immer wiederkehrenden gleichen Fragen hier im Forum zu Gemüte führt.

In der Regel vergeben die mfx-Zentralen CS2/CS3 von den Göppingern bei einer mfx-Anmeldung, jetzt egal ob schnell oder langsam, einem ihr schon/noch bekanntem Decoder dieselbe SID wieder, sofern der Lokeintrag mit der UID/SID in der Lokliste der Zentrale auffindbar ist. Dabei wird davon ausgegangen, dass die Lokliste in der Zentrale eineindeutig ist, und keine Doppelbelegungen aufweist und die Lokliste der Zentrale auch die aktuellsten Informationen über diesen Decoder hat. Wurde ein Decoder inzwischen von einer anderen Zentrale verändert (z. B. in den CVs oder Funktionen usw.), wird das bei einer Schnellanmeldung, wie Stefan schon geschrieben hat, zuerst mal nicht erkannt. Der Decoder bekommt trotzdem seine alte SID wieder.

Wenn ich aber hergehe und eine mfx-Lok komplett aus der Lokliste der Zentrale lösche, ist die UID/SID Zuordnung von früher nicht mehr vorhanden, und die Zentrale vergibt zurecht eine neue SID, weil es für sie nun eine komplett neue mfx-Lok ist. Dann darf ich mich aber nicht beklagen, wenn sich die SID geändert hat und ich das im Steuerungsprogramm dann auch nachziehen muss. Dieses Ei habe ich mir dann selber gelegt und muss daher auch mit den Folgen leben.

Eine mfx-Zentrale kann (derzeit) nicht erkennen, ob das Steuerungsprogramm eine UID/SID-Kombi aus einer früheren Beziehung schon/noch kennt. Dazu gibt es bisher leider keine Steuerbefehle, auch in der Richtung von CS zum Steuerungsprogramm nicht. Schön wäre es, wenn man da eine logische Kopplung machen könnte, und die mfx-Zentrale quasi die Lokliste des Steuerungsprogramms übernimmt oder umgekehrt. Ja, es gibt Steuerungsprogramme, die in der Lage sind, die Lokliste der CS auszulesen und zu verwenden. Aber Loks, die das Steuerungsprogramm hat, die aber in der CS-Lokliste nicht zu finden sind, können damit nicht ohne weiteres in die CS transferiert werden. Dazu gibt es keine offiziellen Steuerbefehle.

Aber:
Was das dann für Auswirkungen auf diejenigen Loks hat, welche die Zentrale zwischenzeitlich ohne das Steuerungsprogramm in ihre Lokliste aufgenommen hat und diese Daten dann eventuell mit den UID/SID-Kombinationen des Steuerungsprogramms kollidieren, kann sich jeder selber ausmalen. Solle es in Zukunft mal Befehle geben, einer Zentrale UID/SID-Kombinationen zu übergeben, muss die Zentrale all denjenigen Loks, welche nun mit ihren eigenen Zentralen-Steuerungsdaten kollidieren, eine neue UID/SID-Kombi zuweisen, die es bisher nicht gab und diese Kombis auch dem Steuerungprogramm zurück geben. Dafür gibt es aber bisher keine Austauschbefehle.

Wenn man sich aber Gedanken darüber macht, der Zentrale bekannte Loks zu übergeben, muss man vorher Fragen beantworten, wie z. B. diese:
Ich habe auf der Anlage mfx-Loks, die ganz offiziell an der Zentrale angemeldet sind. Aufgrund eines Austausches mit einem Steuerungsprogramm kommt es nun dazu, dass die eine oder andere mfx-Lok auf der Anlage eine neue UID/SID-Kombination zugewiesen werden müsste. Was passiert nun, wenn diese mfx-Loks auf Schienenabschnitten stehen, welche zur Zeit nicht bestromt sind, und daher von der Zentrale das "Binden" nicht möglich ist. Es wird Komplikationen geben, wenn das Signal grün schaltet, und die Lok mit ihrer alten SID auf einmal losfährt, weil diejenige (neue) mfx-Lok mit der neu zugewisenen alten SID einer Lok auf der Anlage einen Fahrbefehl bekommt, und nun sich beide mfx-Loks angesprochen fühlen. Das gibt ein richtiges Chaos. Da ist die Situation, dass die _alte_ Lok die Situation erkennt, und sich mal schnell neu anmeldet, wenn sie wieder Strom bekommt, noch das harmloseste aller Szenarien.

Daher: Es darf im System nur einen Master geben, der Herr über UID/SID-Kombinationen ist.

Daher ist die bisherige Lösung mit "Die Zentrale ist Master" die derzeit beste Lösung. Aber ein gewisser (Daten-)Austausch zwischen Steuerungsprogramm und Zentrale wäre trotzdem wünschenswert. Hier müsste dann aber das Steuerungsprogramm Slave sein, und seine Daten mit den Daten der Zentrale abgleichen incl. der Übernahme/Vergabe der UID/SID-Kombinationen von der Zentrale zum Steuerungsprogramm. Ich würde für den Abgleich von Loks, welche im Steuerungsprogramm enthalten sind und in der Zentrale fehlen, eine Möglichkeit vorsehen, diese "virtuell" an der Zentrale anmelden zu können. In diesem Fall tut dann das Steuerungsprogramm so, wie wenn es eine Lok wäre und diese der Zentrale bekannt macht incl. dem virtuellen "Binden", also dem Zuweisen von UID/SID und Neuanmeldezähler. Damit kann dann das Steuerungsprogramm seine Lok der Zentrale bekanntmachen, die Zentrale aber der (neuen) Lok vom Steuerungsprogramm auch eine (neue) SID zuweisen. Damit dürfte dann eine Situation wie oben beschrieben entschärft werden.

Eigentlich dürfte so eine Situation, dass es eine Lok auf einer mfx-Anlage gibt, deren UID/SID-Kombination ungültig ist (für die Zentrale), gar nicht geben. Wenn eine mfx-Lok auf der Anlage wieder aufgegleist wird, und die mfx-Lok erkennt, dass sie in einem anderen Sonnensystem aufwacht, wird sie sich neu anmelden, und daher wird dann diese "alte" UID der Zentrale wieder bekannt gemacht und sie erhält ihre alte SID wieder, die auch dem Steuerungsprogramm bekannt sein müsste. Wurde sie aber zwischenzeitlich in der Zentrale gelöscht, bekommt sie eine neue SID, welche dann aber nicht mehr mit der SID im Steuerungsprogramm überein stimmt. Jetzt ist ein Abgleich nötig, den es so bisher noch nicht gibt.

Sollte hier jemand von den Göppingern mitlesen, dann würde ich es begrüssen, wenn man sich in dieser Hinsicht mal ein paar warme Gedanken machen würde.

Es fehlen Befehle wie:

Hallo Zentrale, hast du eine Lok mit der UID 0x12345678?

Wenn nein, dann:
Zentrale: Schnell- oder Virtuelle Anmeldung einer Lok mit der UID 0x12345678 mit allen dazu nötigen Folgebefehlen. Das käme dem Anmelden/Laden einer Lok über die Chipkarte gleich.
Problem: Diese Lok steht derzeit nicht auf der Anlage oder kann physikalisch nicht gebunden werden, weil stromlos. Was dann?

Wenn ja (UID ist der Zentrale bekannt): Durchführen eines virtuellen Bindens mit dem Steuerungsprogramm. Das Steuerungsprogramm bekommt dann für diese Lok eine neue SID.

Damit kann ein Steuerungsprogramm vor der Benutzung einer mfx-Lok sicherstellen, dass die ihr bekannte Lok auch die richtige SID hat und ggf. die derzeit aktuelle SID übernehmen.
Das bedingt aber, dass das Steuerungsprogramm auch eine Liste mit UID/SID führt, also nicht nur, wie bisher, die SID der Lok kennt sondern auch deren UID, um bei der Zentrale nach deren SID nachfragen zu können.

Gruß est2fe

P.S.: Ich gehe mal davon aus, dass du (Viktor) das Dokument, das du oben verlinkt hast, auch durchgelesen und verstanden hast. Somit sind dir die hier im Beitrag verwendeten Begrifflichkeiten bekannt. Wenn nicht, bitte melden.

Hallo,

es ist doch eigentlich recht einfach: Die Zentrale verwaltet die SID. Davon muss der Anwender nichts wissen, auch nicht der Anwender eines Steuerprogramms. Zentralen und auch die Steuerprogramme müssten sich Loks über die UID merken - das ist ja gerade der Vorteil einer eindeutigen UID. Die SID ist nur eine temporäre Adresse, die die Zentrale ganz nach belieben und wie die Unterwäsche wechseln kann. Davon darf der Anwender nichts mitbekommen. Programme, die über eine Zentrale die Loks fahren, dürfen sich natürlich nicht die SID merken, sondern müssen diese nach jedem Einschalten von der Zentrale erfragen. Zwischen Märklin-Geräten funktioniert das doch auch. Eine MS2 oder eine weitere CS2 oder CS3 als weiteres Steuergerät an einer CS2/3 stören sich ja auch nicht daran, wenn bei einer Lok die SID gewechselt wird.

Leider machen das viele Programme nicht. Und sicher ist auch die Schnittstelle der CS2/3 diesbezüglich nicht besonders geschickt aufgebaut und dokumentiert. Die ECoS arbeitet anders - aber auch da scheinen sich die Programme nicht sonderlich leicht zu tun. Das steht alles aber auf einem anderen Blatt und hat mit mfx nicht viel zu tun. Da könnte man noch viel besser machen.

Zu Michaels Problem: Ein Eintrag in der Lokliste der Zentrale dürfte sich in der Handhabung nicht zwischen einer DCC-, MM- oder mfx-Lok unterscheiden. Wenn eine bekannte mfx-Lok im Hintergrund neu angemeldet wird, müsste das den Eintrag nicht tangieren. Und den Benutzer auch nicht. Wenn der Eintrag deshalb verschwindet, ist das ein Fehler der Zentrale. Wenn man ihn nicht wiederfindet, ist es ein Problem des Benutzers, das genauso mit einem DCC-Lok-Eintrag hätte passieren können.

Der Wechsel auf eine andere Anlage ist ja gerade eine Stärke des Systems. Die Zentrale sorgt immer im Hintergrund dafür, dass sich die Loks nicht in die Quere kommen. Hier braucht es keinen Eingriff des Benutzers. Besser geht nicht.

Der Fehler ist, dass sich Programme zu sehr an der SID orientieren und daher mit solchen Situationen schlecht zurecht kommen. Dass Märklin hier nicht die Doku und die Schnittstelle der CS2/3 verbessert hat, sondern eher noch darauf eingeht und versucht, die SID möglichst unverändert zu belassen, halte ich für kontraproduktiv.

Grüße
Stefan