Hallo Peter, Olli,

es sieht folgendermassen aus:

Die Zentrale hat eine UID (Seriennummer), welche sie in (un)regelmaessigen Abständen als mfx-Schienendaten auf der Anlage verbreitet. Danach fragt eine Zentrale, ob sich jemand anmelden will. Wenn sich da jetzt ein oder mehrere mfx-Decoder melden, warum, das erkläre ich weiter unten, dann fängt die Zentrale an, die UID des/der Decoder(s) auszulesen. Jeder Decoder (und die Zentralen) haben so eine weltweit nur einmalig vorkommende UID von der Herstellerfirma programmiert bekommen.
Liegt diese UID (32Bit gross) der Zentrale vor, dann geht die Zentrale her und programmiert die SID (das ist eine wesentlich kürzere Adresse als die UID des Decoders zwischen 9 und 14 Bit) in den Decoder. Zusammen mit der SID wird dem Decoder zusätzlich auch noch ein Neuanmeldezähler mitgegeben. Dieser Neuanmeldezähler wird in der Zentrale dann erhöht, wenn eine mfx-Lok in der Zentrale gelöscht wird. Der Decoder merkt sich also jetzt folgendes: Die UID der Zentrale, die SID und den Neuanmeldezähler.
Mit der wesentlich kürzeren SID (gegenüber den 32Bit UID) wird der Decoder dann mit Fahr-Infos versorgt und auch programmiert, also allgemein angesprochen. Nur bei der SID-Programmierung wird die UID des Decoders verwendet. Danach braucht man die lange Decoder-UID nicht mehr.
Wacht ein Decoder nach dem Aufgleisen in einem neuen Sonnensystem auf (also eine andere Zentrale), hat sich auf jeden Fall die UID der Zentrale geändert. Er muss sich also dann, wenn die Zentrale nach unbekannten Decodern fragt, sich melden. Die Anmeldung an der Zentrale veranlasst also der Decoder und nicht die Zentrale. Die fragt nur, ob sich eventuell jemand anmelden will, mehr nicht. In 99,99% der Fälle wird sich da niemand melden.
Sollte der mfx-Decoder gerade bei vollem Bewusstsein zuhören, wie eine andere mfx-Lok gelöscht wurde, dann versendet ja die Zentrale danach den neuen Stand des Neuanmeldezählers. Dieser neue Zählerwert wird von allen bei vollem Bewusstsein zuhörenden mfx-Decodern dann auch kommentarlos übernommen. Ist aber eine mfx-Lok bei diesem Löschvorgang gerade nicht aufgegleist gewesen oder stand in einem stromlosen Abschnitt (z. B. vor einem stromlos geschalteten Signalabschnitt oder in einem abgeschalteten Schattenbahnhofsgleis), dann bekommt er die Neuanmeldezähleränderung ja nicht mit. Jetzt muss er damit rechnen, selbst wenn die UID der Zentrale noch dieselbe ist, dass er selber eventuell in der Zentrale gelöscht worden ist. Er wird sich also nach einer gewissen Zeit dann selber wieder anmelden (müssen). Wird während dieser Zeit der Decoder nicht explizit durch einen mfx-Verify (oder eventuell auch Fahrstufenbefehle, so stand es zumindest mal in dem Entwurf für das Patent drin) direkt angesprochen, dann stellt er zuerst mal alle seine Aktivitäten ein (FS 0 alle FX aus) und meldet sich einfach wieder bei der Zentrale als neuer Decoder an. Die Zentrale liesst von Ihm die UID wieder aus (das dauert bei einer MS1 ca. 8 Sekunden). Eine MS1/CS1/ECoS macht da jetzt unvermittelt gleich weiter und lesen den ganzen Decoder aus, die CS2 schaut in ihrer Lokliste nach, ob sie diesen Decoder schon mal hatte, und wenn ja, nimmt sie einfach dessen damalige Eigenschaften wieder her und man kann danach sofort mit dem Deocder fahren. Deswegen dauert bei der CS2 so eine erneute Anmeldung auch nicht so lange.
Solange also eine Zentrale keinen geänderten Neuanmeldezähler und keine Zentralen-UID versendet, merkt der Decoder einen Sonnensystemwechsel nicht.
Die Tams hat meines Wissens früher mal die Zentralen-UID bzw. den mfx-verify nicht immer versendet. Damit wäre also ein Zentralen-Wechsel wahrscheinlicher gewesen. Heute ist das meines Wissens wegen den neuen Decodereigenschaften, nicht mehr so. Neuere Decoder wollen immer wieder so was sehen, sonst quittieren sie die Mitarbeit.

Somit hast du also kaum eine Chance, einen Sonnensystemwechsel ohne Neuanmledung zu überstehen.

Das ist ja auch der Grund, warum die neue CS2 als Zweitgerät umgeschaltet werden kann. Damit wird der interne GFP im Zweitgerät abgeschaltet, und der interne CS2-Booster wird quasi wie ein externer Booster verwendet. Das dafür zusätzlich benötigte Gleissignal dafür wird sowieso über das CAN-Kabel mitgeliefert. Nur jetzt wird es auch sachgerecht weiterverwendet.

Wenn ihr also eure "Groß-Anlage" ohne Neuanmeldungen zwischen den Zentralen betreiben wollt, dann nimmt mehrere CS2. Die sind für sowas ganz gut eingerichtet.

Gruß

est2fe

Hallo Leute,

vielen Dank für die Infos.

Wichtig ist zu wissen, das wenn man mit 2 Zentralen
(also nicht Master/Slave wo die eine nur noch Booster und Regler ist)
fährt, das man es mit 2 völlig unterschiedlichen Spannungsquellen zu tun hat auch beim Überfahren niemals gebrückt werden sollten. Spätestens bei beidseitiger Brückung drohen Defekte. Das ist NICHT vergleichbar mit Starthilfe beim Auto, sondern ungefähr so, wie wenn man eine Verlängerungskabel mit 2 Steckern baut, und so eine seiner Netz-Steckdose mit einer Netz-Steckdose des Nachbarhauses verbindet .

Trotzdem, wie warten sehnsüchtigst auf Erfahrungsberichte von Peter, wie lang es dauert bis welche Lok wo wieder steuerbar ist .

Viele Grüße
Frank

Und der XPressFahrer hat auch mal wieder was zu besser-meckern: Warum sind bloss ECos-Link und Märklin-Bus unterschiedlich

Tja, dann werden die Mfx-Lokomotiven immer im Übergabegleis warten müssen, bis alle "Grenz-Formalitäten" erledigt sind.

Zitat von est2fe

---

Wenn ihr also eure "Groß-Anlage" ohne Neuanmeldungen zwischen den Zentralen betreiben wollt, dann nimmt mehrere CS2.

---

Es geht ja darum, vorhandenes Material mit möglichst wenig Aufwand gemeinsam nutzen zu können. Eine Empfehlung für eine bestimmte Zentrale wäre da die falsche Maßnahme.

Zitat von Gast_001

---

Trotzdem, wie warten sehnsüchtigst auf Erfahrungsberichte von Peter, wie lang es dauert bis welche Lok wo wieder steuerbar ist .

---

Ist ja nur ein Nebenkriegsschauplatz, aber einen Bericht wird es geben. Die eigentlichen Herausforderungen sind ganz anderer Natur.



Und vielen Dank für den theoretischen Hintergrund, ein paar Dinge kann ich mir so etwas besser erklären. Meine MasterControl hat Software-Stand 1.4.5c, die regelmäßig gesendete Bake gibt es wohl ab Version 1.4.5f. Vor unserem Treffen wollte ich keine neue Software mehr aufspielen, dass mache ich danach. Mfx-mäßig gibt es also noch viel auszuprobieren. Unsere Mobile Station ließ sich aber von der im Stromkreis der MasterControl fremd gegangenen Lokomotive täuschen, für sie kam die Lok nur aus einem stromlosen Abschnitt zurück. Na ja, ich bin jetzt vorgewarnt und kann mögliche Reaktionen deuten.

Zitat von Peter Müller

---

Wissen tue ich es erst in zehn Tagen.

---

Eigentlich weiß ich nach unserem Teppichbahn-Treffen nur, dass es nicht so einfach geht

Die Mfx-Lokomotiven konnten nicht von der der ECoS zur CS1reloaded bzw. anders herum geschleust werden. Sie meldeten sich bei der neuen Zentrale nicht an, standen teilweise 15 Minuten unsteuerbar auf dem Gleis. Wir haben die Versuche dann zugunsten des rundlaufenden Betriebes abgebrochen und bei beiden Zentralen Mfx ausgeschaltet. Mit dem MM-Protokoll funktionierte es dann weitestgehends. Es gab noch eine Lokomotive, die von der ECoS nicht steuerbar war, aber ich bin mir nicht sicher, ob es sich um einen DCC-Decoder gehandelt hat.

Am allerliebsten waren einem natürlich Multiprotokoll-Decoder mit Selbsterkennung DCC/MM: Adresse eintippen und weiterfahren, auch fliegende Wechsel kein Problem.

Fliegende Wechsel Tams-Mfx zu Mobile-Station-Mfx, welche hier bei mir zuhause anstandslos funktioniert hatten, waren beim Teppichbahning nicht möglich . Hier wurde ebenfalls zugunsten des Betriebes auf eine Untersuchung verzichtet.

Die Tams nahm jede Mfx-Lok anstandslos an. Ich konnte die Schleusengleise wahlweise auf den Programmiergleis-Anschluss legen und die Lokomotiven bekamen einfach bei der Übernahme die Adresse des Gleises, auf welches sie geleitet wurden, zugewiesen.

Hallo Peter,

einfach nur vielen Dank, fürs probieren und berichten.

Ich hätte erwartet, das paarweises jeder mit jedem geht. Nur die Verweildauer in der Schleuse hätte je nach Paarung unterschiedlich lange ausfallen dürfen. Es bleibt der Eindruck, das mnache Übergaben hätten stattfinden können, aber sie hätten dann unerträglich lange gebraucht.

Klar ist, das die Zentralen wegen Ihrer properitären Systembusse praktisch nicht dafür geeignet und vorgesehen sind, und die Tams - wegen Ihrer persistenten UID-M3 Zuordnung : - die besten Karten hatte.

Vielleicht kann est2fe das "Ergebnis" nochmal erklären : .

Danke und Grüße
Frank

Es waren keine "Laborbedingungen", teilweise 20 Meter lange Zuleitungen. Die Gründe, warum es nicht klappte, können vielfältig sein. Wir hätten erst noch übrige Fehlerquellen ausschließen müssen, dafür war keine Zeit. Deshalb wurden alle Tests abgebrochen.

Hallo zusammen,

> Vielleicht kann est2fe das "Ergebnis" nochmal erklären

ich komme gerade von einer Augen-OP aus Berlin zurück und sehe die Zeichen hier auf dem Bildschirm noch etwas verschwommen, weil das operierte Auge noch tränt. Aber ich konnte es dennoch entziffern, was ihr da geschrieben habt.

Nun, das mit der Tamse kann ich noch verstehen. Auf dem Programmiergleis wird einfach den angekommenen mfx-Loks eine neue SID zugewiesen, fertig! Das geht ja auch solange gut, bis diese mfx-Loks den Tamssschen Bereich wieder verlassen. Dann müssen sie sich an der "neuen" Zentrale wieder erneut neu anmelden, denn bei dieser Zuweisung durch die Tamse haben sie eine andere Zentralen-UID, SID und einen anderen Neuanmeldezähler gemerkt. Dass dies aber nicht immer klappt, dafür gibt es, wie schon geschrieben, viele Gründe.

Ich hätte eigentlich jetzt erwartet, dass das Anmelden bei den verschiedenen ESU-Geräten, eigentlich in endlicher Zeit klappen sollte. Ich dachte bisher immer, dass ESU die größere Erfahrung bzgl. mfx haben sollte, weil sie das ja als Auftragsentwicklung für M* gemacht haben. Deswegen verwundert es mich jetzt doch etwas.

Aber, und da gebe ich euch recht, es kann natürlich auch an den suboptimalen Zuleitungen/Bedingungen gelegen haben. Diese mfx-Rückmeldepiepse zu detektieren, ist rein technisch nicht ganz trivial.

In diesem Zusammenhang hätte mich jetzt auch mal interessiert, wie gut in diesem Umfeld wohl RailCom funktioniert hätte? Das wäre jetzt eigentlich wirklich mal ein fairer Vergleich unter praktischen Bedingungen gewesen!
Ich denke, das hätte vermutlich in so einem Umfeld ähnlich schlechte Ergebnisse geliefert, zumal da die Rückmeldung ja mit noch kleineren Strömen erfolgt (50mA zu 150mA)!

Gut, wie dem auch sei, um das mit den von den Benutzern mitgebrachten unterschiedlichen Zentralen in so einer bunt zusammengesteckten Umgebung per mfx umfassend zu lösen, braucht es wohl doch etwas mehr Verwaltung und Intelligenz im Hintergrund, als es bisher mit rein menschlichem Sachverstand möglich ist.

Das bisherige Fazit dazu ist also:

Mit den bisherigen Zentralen und ihrem eingebauten Handling ist das derzeit wohl nicht mit vertretbarem Aufwand lösbar. Bei den ESU-Zentralen ECoS, MS und CS1 kommt man nicht ohne großen Aufwand an die vergebenen SID ran. Bei der CS2 muss man den CAN mithören, kann dann aber vermutlich regulativ eingreifen. Bei der Tamse kennt man die SIDs und kann die zuweisen, was einem aber im Zusammenspiel mit den anderen Zentralen auch nicht viel hilft.
In Summe betrachtet, braucht man eigentlich eine im Hintergrund laufende sehr intelligente Verwaltung, welche das, natürlich mit zusätzlichem Aufwand für ein paar dafür in den bisher bestehenden Zentralen benötigten neuen Steuerbefehlen, alles managed.
So etwas wird es aber auch in mittlerer Zukunft nicht geben, weil sich ESU bezüglich ihrers Busses ECoS-Link nicht in die Karten schauen lässt. Auch wenn man das Protokoll kennen würde, klappt das nicht, weil auf dem Bus nur logische Objekte ausgetauscht werden, und die physikalischen Größen wie SID, UIDs, MM und DCC-Adresse usw. da nicht bekannt sind.

Also da muss ich jetzt schon mal das CS2-CAN-Protokoll lobenswert hervorheben. Da ist irgendwie alles über Winkel und Ecken zugänglich, auch wenn es nicht immer ganz so einfach zu verstehen ist.

Ich würde es begrüßen, wenn sich da im Laufe der Zeit ein allgemeines Protokoll durchsetzen würde und die bisherigen Zentralen dieses Protokoll noch implementiert bekommen würden. Das ist aber auf allen Seiten mit Aufwand verbunden, und die Programmierer bekommen in diesem Fall nichts für ihren Arbeitsaufwand, weil dann jeder seine bisherige Zentrale weiterverwenden kann, ohne eine Neue kaufen zu müssen.

Gruss

est2fe

Zitat von est2fe

---

Ich würde es begrüßen, wenn sich da im Laufe der Zeit ein allgemeines Protokoll durchsetzen würde und die bisherigen Zentralen dieses Protokoll noch implementiert bekommen würden.

---

Das wäre auch mein Traum!

Bis RailCom sind wir noch lange nicht, wir schleppen ja sogar noch Gleichstrom und Wechselstrom mit durch und speisen mit den günstigen Delta-Boostern den Strom ein. Getrennte Masse ist auch ein ewiger Zankpunkt. Ich hoffe, dass wir demnächst wenigstens eine einzige RailCom-Strecke unter Teppichbahn-Treffen-Bedingungen aufbauen können. Der Hinweis auf das schwächere Signal betrübt mich natürlich.

Das Zentralen-mäßig bestausgerüstete Team hatte übrigens eine CS1reloaded mit Funkreglern und zusätzlichen iPods. Andere Teams sind froh, wenn sie für die Dauer der Veranstaltung eine IB ausgeliehen bekommen. Das streckenmäßig längste Land war mit über 20 Meter Loconet-Kabeln verbunden und dort gab es auch Probleme, die erst nach zigmaligem Kabel-Tausch gelöst werden konnten. Für ein alles überspannendes Netz kann man sich noch fürchterlich viele Gedanken machen, es bleibt spannend.

Hallo est2fe,

Erstmal Danke für die Info und gute Besserung.

Zitat von est2fe

---

In diesem Zusammenhang hätte mich jetzt auch mal interessiert, wie gut in diesem Umfeld wohl RailCom funktioniert hätte? Das wäre jetzt eigentlich wirklich mal ein fairer Vergleich unter praktischen Bedingungen gewesen!
Ich denke, das hätte vermutlich in so einem Umfeld ähnlich schlechte Ergebnisse geliefert, zumal da die Rückmeldung ja mit noch kleineren Strömen erfolgt (50mA zu 150mA)!

---

Ein RailCom Lok sendet Ihre Adresse alle wohl bis zu mehr als 100 mal je Sekunde (jeweils zwischen 2 DCC-Befehlen). Bei lokalem RailCom wird das RailCom Paket bereits am nächsten Rückmelder mit integriertem Detector gelesen. Es wäre also denkbar , das die Stromschleife bei lokalem RailCom einfach auch kleiner ist. Thomas, (Münchner Kindl) könnte hier wohl genaueres zu sagen. Während der Übetragunszeit legt der Booster (im gegensatz zu mfx) )zusätzlich die Leitung ruhig "Austastlücke".

Dennoch würde das allein für das Verhalten der Lok keine Rolle spielen, die würde entweder die Fahrstufe des neuen System in der Schleuse (Umschaltung könnte während der Fahrt erfolgen) übernehmen, oder, wenn sie dort gerade nicht geführt oder von aufgerufen wird, unbeirrt weiterfahren bis es crashed, oder bis sie wieder das erste System (via Schleuse) erreicht. Also erstmal genau wie wenn es eine MM Lok wäre.

RailCom ist einfach nur eine Information, de von der Lok gesendet wird und dann von einem PC o.ä. optional augewertet werden kann/könnte. Bei lokalem RailCom würde der Abschnittsdetector das vorhandensein der neuen Lok melden, bei globalem der Booster. Wie das funktioniert, wenn kein lokales RailCom installiert wäre, weiss ich auch nicht. Von einem Anti-Kollisionsprotokoll bzgl der Adresse bei gleichzeitigen Sendens mehrerer Lokos ist mir nichts bekannt. Das gibt es bei anderen Werten, wie Geschwindigkeit, wo jeweils immer nur die dcc-adressierte Lok "meldet".

Zitat

---

Ich würde es begrüßen, wenn sich da im Laufe der Zeit ein allgemeines Protokoll durchsetzen würde und die bisherigen Zentralen dieses Protokoll noch implementiert bekommen würden. Das ist aber auf allen Seiten mit Aufwand verbunden, und die Programmierer bekommen in diesem Fall nichts für ihren Arbeitsaufwand, weil dann jeder seine bisherige Zentrale weiterverwenden kann, ohne eine Neue kaufen zu müssen.

---

Korrekt. Nur das kann meineserachtens genügend Investitionssicherheit für Entwickler , wie auch Vertrauen beim Kunden gewährleisten , in welche Form auch immer sich an solchen Techniken konstrutiv weiterführend zu beteiligen. Wer entwickelt schon Lösungen für Produkte ohne oder mit einem winzigem Markt. Egal ob gratis oder bezahlt.

Gruss

Frank

Zitat von est2fe

---

Mit den bisherigen Zentralen und ihrem eingebauten Handling ist das derzeit wohl nicht mit vertretbarem Aufwand lösbar. Bei den ESU-Zentralen ECoS, MS und CS1 kommt man nicht ohne großen Aufwand an die vergebenen SID ran. Bei der CS2 muss man den CAN mithören, kann dann aber vermutlich regulativ eingreifen. Bei der Tamse kennt man die SIDs und kann die zuweisen, was einem aber im Zusammenspiel mit den anderen Zentralen auch nicht viel hilft.
In Summe betrachtet, braucht man eigentlich eine im Hintergrund laufende sehr intelligente Verwaltung, welche das, natürlich mit zusätzlichem Aufwand für ein paar dafür in den bisher bestehenden Zentralen benötigten neuen Steuerbefehlen, alles managed.

---

Demnächst geht es wohl wieder an einen Test, deshalb beschäftige ich mich weiter mit dem Thema. Aber vorher wollte ich noch klarstellen, dass ein Pendeln zwischen Tams und MS1 problemlos möglich war. Demzufolge könnte ich mir vorstellen, dass auch zwischen Tams und Tams oder MS1 und MS1 pendeln möglich ist (bei der MS1 muss eine vorherige Anmeldeprozedur beachtet werden, was aber bei maximal 10 möglichen beteiligten Lokomotiven zu schaffen wäre). Erst wenn eine der großen Mfx-Zentralen ins Spiel kommt und ihre eigene Adresse vergeben will, wird es kompliziert. Die Lösung wäre, wenn bei einem der nächsten Updates man den großen Zentralen beibrächte, auf die Selbstvergabe der Adresse zu verzichten und eine vom Benutzer gewählte Adresse zu verwenden. Ob ich wohl erhört würde?

Hallo Peter,

auch zwischen MS1 und MS1 geht das nicht ohne Probleme. Es ist bei der MS1, zumindest bei den älteren Firmwareversionen), unweigerlich eine komplette Anmeldung nötig -> 22s!

Zwischen Tams und jeweils einer anderen Zentrale geht es fast immer, wenn man rausbekommen kann, unter welcher SID die mfx-Lok bei dieser anderen Zentrale fährt, und in der Tams dann diese SID auch verwendet. Dann merkt der Decoder von einem Systemwechsel nichts.

> Die Lösung wäre, wenn bei einem der nächsten Updates man den
> großen Zentralen beibrächte, auf die Selbstvergabe der Adresse zu
> verzichten und eine vom Benutzer gewählte Adresse zu verwenden.
> Ob ich wohl erhört würde?

Nein, das ist auch nicht die ultimative Lösung. Man muss da bei diesen anderen Zentrale dann auch noch die Möglichkeit haben, das Senden der Zentralen-UID abzuschalten, so wie in der Tams, die diese UID ja überhaupt nicht sendet. Aber, damit ist dann auch ein automatisches Anmelden nicht mehr möglich, sondern nur noch auf Anforderung. mfx wird dadurch eine seiner Merkmale beraubt.

Gruß

est2fe

Zitat von est2fe

---

Nein, das ist auch nicht die ultimative Lösung. Man muss da bei diesen anderen Zentrale dann auch noch die Möglichkeit haben, das Senden der Zentralen-UID abzuschalten, so wie in der Tams, die diese UID ja überhaupt nicht sendet. Aber, damit ist dann auch ein automatisches Anmelden nicht mehr möglich, sondern nur noch auf Anforderung. mfx wird dadurch eine seiner Merkmale beraubt.

---

Genau!

Das war ja dann die Lösung des Problems, man kann bei CS1 und ECoS1 wohl das Mfx-Protokoll abschalten (wusste ich bis dahin gar nicht). Damit war es wieder möglich, zwischen den Zentralen zu pendeln. Es waren aber auch die vielen Funktionen von Mfx abgeschaltet, weil alle Lokomotiven nur noch auf MM hörten.

Schön wäre es, die vielen Funktionen von Mfx nutzen zu können, aber auf die Anmeldeprozedur zu verzichten, also selber Adressen zu vergeben.

Moin,

da ich kein besonderer Freund von mfx bin habe ich mir auch damals die ECoS statt der CS1 gekauft.

Nach dem Softwareupdate auf 3.0.1 bei der ECoS kann ich nun auch mfx b.z.w. M4 nutzen.

Mein Vater hat sich nun die CS2 gekauft und hatte nun plötzlich Probleme seine Loks einzulesen die Werksseitig von Märklin mit mfx Decodern ausgestattet waren. Allerdings muß man dazu sagen das die Loks vorher nur unter Motorola mit der 6021 gefahren wurden.

Erst nachdem ich die Loks mit meiner ECoS eingelesen hatte meldeten sich die Lok nun auch von allein bei der CS2 an.

Kennt jemand von Euch dieses Phänomen bei mfx ??

Zitat von Peter Müller

---

...Schön wäre es, die vielen Funktionen von Mfx nutzen zu können, aber auf die Anmeldeprozedur zu verzichten, also selber Adressen zu vergeben.

---

Moin Peter,

du sprichst mir aus dem Herzen.

Zitat von Dirk Ackermann

---

Moin,

da ich kein besonderer Freund von mfx bin habe ich mir auch damals die ECoS statt der CS1 gekauft.

Nach dem Softwareupdate auf 3.0.1 bei der ECoS kann ich nun auch mfx b.z.w. M4 nutzen.

Mein Vater hat sich nun die CS2 gekauft und hatte nun plötzlich Probleme seine Loks einzulesen die Werksseitig von Märklin mit mfx Decodern ausgestattet waren. Allerdings muß man dazu sagen das die Loks vorher nur unter Motorola mit der 6021 gefahren wurden.

Erst nachdem ich die Loks mit meiner ECoS eingelesen hatte meldeten sich die Lok nun auch von allein bei der CS2 an.

Kennt jemand von Euch dieses Phänomen bei mfx ??

---

Die Büchse der Pandora

Okay, ich kaufe dann mal meine soeben vertickten 6021 alle zurück.

Guten Morgen,

Zitat

---

Aber vorher wollte ich noch klarstellen, dass ein Pendeln zwischen Tams und MS1 problemlos möglich war. Demzufolge könnte ich mir vorstellen, dass auch zwischen Tams und Tams oder MS1 und MS1 pendeln möglich ist (bei der MS1 muss eine vorherige Anmeldeprozedur beachtet werden, was aber bei maximal 10 möglichen beteiligten Lokomotiven zu schaffen wäre).

---

Eine Frage dazu: Welche Version befindet sich auf der MC? Es ist nicht auszuschliessen, dass dieses Pendeln zwischen Systemen mit der aktuellsten Version nicht mehr funktionieren wird, weil die MC ab dann den Loks ihre ID mitteilt, was fuer den Betrieb der neuen mfx-Decoder notwendig war.

Zitat von Muenchner Kindl

---

Welche Version befindet sich auf der MC?

---

1.4.5m

Ich bin mir aber nicht mehr ganz sicher, ob ich vor oder nach den Versuchen ein Update gemacht habe. Ich meine, es war vor den Versuchen. Demnächst wiederhole ich das alles noch einmal.