Hallo zusammen,

ich habe mir eine ESU ECOS angeschafft.
Zudem habe ich jetzt 2 neue Piko Loks der Expert Reihe, mit den relativ neuen Decodern von Piko, die M4 unterstützen.
Und zwar einmal die BR143 mit Latz und eine Vossloh G6.
Leider musste ich gerade feststellen das die beiden sich beim Anmelden per M4 immer wieder gegenseititg überschreiben.
Also setze ich die BR143 aufs Gleis meldet diese sich per M4 an und teilt alle Funktionen und den Namen mit. Setze ich dann die G6 aufs Gleis und habe Schnellanmeldung aktiviert, kann ich die G6 mit dem Eintrag der BR143 steuern. Schalte ich Schnellanmeldung aus, meldet sich die G6 an und überschreibt den Eintrag der BR143.

Kennt jemand dieses Phänomen und kann mir diesbezüglich weiterhelfen?
Danke :)

Edit: Habe gerade mal M4 ausgeschaltet in der ECOS und die Loks per RailComPlus anmelden lassen, selbes Phänomen. Als ob die Zentrale denkt es wäre der selbe Decoder.

Kannst Du mal bitte genau herausbekommen, welche Decoder das sind? Lies mal bitte CV7 aus.

Leider habe ich erst jetzt zeit. Hier also das CV7:



Laut beiliegenden Anleitungen handelt es sich bei beiden Dekodern um einen:
Piko SmartDecoder 4.1 PluX22 multiprotokoll, mfx-fähig (56401)

Zitat von SSchaffrath im Beitrag #1

---

Kennt jemand dieses Phänomen und kann mir diesbezüglich weiterhelfen?

---

Das Problem ist das so lange RailComPlus und Mfx eingeschaltet ist am Decoder und diese sich automatisch darüber anmelden. Reagieren diese nicht auf DCC Befehle.
Also müsste ich dann erst die beiden Sachen ausprogrammieren um rein mit DCC zu arbeiten.
Lieber wäre mir natürlich eine Lösung mit behalten von MFX...

Zitat von SSchaffrath im Beitrag #5

---

Lieber wäre mir natürlich eine Lösung mit behalten von MFX...

---

Zitat von SSchaffrath im Beitrag #5

---

Lieber wäre mir natürlich eine Lösung mit behalten von MFX...

---

4.1 Decoder werden künftig nicht mehr unterstützt und nur noch abverkauft. Dennoch würde ich versuchen, einen der betreffenden Decoder zutauschen. Es ist möglich, dass Du dann 2 verschiedene IDs in den Decodern hast, so dass sie nicht mehr beide zeitgleich den Zuschlag erhalten.

Dann kauf ich direkt nen Esu oder ähnliches.
Sind halt die Decoder die man ja zwangsmäßig mitkaufen muss als ACler...

Hallo Sebastian,
wenn Du kannst, dann würde ich die Loks sich mal an einer anderen mfx-Zentrale anmelden lassen.
(Freund, Händler, Verein)
Ich hatte mit der mfx-Anmeldung auch so meine Späße,
die Verwendung dieses Protokolls bei diesen Decodern bringt keinen Mehrgewinn gegenüber dem DCC,
ganz im Gegenteil, unter DCC konnte ich viel mehr einstellen und auch das Lichtmapping nach meinen Vorstellungen umsetzen.
So schlecht ist ein Lokdecoder Piko Smart4.1 nicht. Die so eingestellten Decoder sind noch heute ohne Probleme im Einsatz.
LG
Bahnchef

Ein Hersteller, der mfx-taugliche Decoder anbietet und dem nicht gerecht wird, hat seine Hausaufgaben nicht gemacht. Während Märklin das mfx-Protokoll veröffentlichte. Ich selbst weiß, wie mfx funktioniert und dcc nicht. Eine neue Lok mit einem nicht optimal funktionierenden mfx-Decoder würde ich einfach zurücksenden.

Ich habe nichts mit DCC zu tun und habe auch nicht vor, es zu verwenden.

Hallo Bahnchef,

Zitat von Bahnchef im Beitrag #10

---

So schlecht ist ein Lokdecoder Piko Smart4.1 nicht. Die so eingestellten Decoder sind noch heute ohne Probleme im Einsatz.

---

Zitat von Velzen im Beitrag #11

---

Ein Hersteller, der mfx-taugliche Decoder anbietet und dem nicht gerecht wird, hat seine Hausaufgaben nicht gemacht. Während Märklin das mfx-Protokoll veröffentlichte. Ich selbst weiß, wie mfx funktioniert und dcc nicht.

---

Zitat von Dampfstoß im Beitrag #13

---

Zitat von Velzen im Beitrag #11

---

Ein Hersteller, der mfx-taugliche Decoder anbietet und dem nicht gerecht wird, hat seine Hausaufgaben nicht gemacht. Während Märklin das mfx-Protokoll veröffentlichte. Ich selbst weiß, wie mfx funktioniert und dcc nicht.

---

Schön für Dich. Dann weißt Du auch, dass mfx ein Krückenprotokoll ist, welches nie ausentwickelt wurde und nicht mal Zubehör ansteuert, ob wohl es das könnte, wenn man bei Märklin das gewollt oder gekonnt hätte. Noch heute braucht man für Weichen oder Signale DCC oder Motorola als Hilfsmittel. Aber im Grunde hat Märklin das mfx auch nur von ESU geerbt und dann nicht konsequent weiter entwickelt, weil man verkaufte ja auch so genug. Anbetracht der Tatsache, das mfx Spezialchips aus der Dampfradiozeit verwendet, wird das Protokoll früher oder später ohnehin verdrängt werden. Deshalb versucht man es jetzt krampfhaft zu erhalten und nur darum gab es die (teilweise) Öffnung des Protokolls. DCC hingegen wird immer noch gepflegt und erweitert und könnte in Zukunft sogar noch mal grundlegend verbessert werden - da alle Quellen frei verfügbar und für jedermann einsehbar sind. Und jeder mit ein bisschen Programmier- und Lötkenntnis kann sich ohne Probleme eigene Decoder oder Steuergeräte bauen.

Wenn ich Dich also zitieren darf: Ich habe nichts mit mfx zu tun und habe auch nicht vor, es zu verwenden.

---

Hallo,

mal zur eigentlichen Sache. Wenn man die Loks an einer CS2 anmelden würde, dann könnte man im CS2 Backup die mfxUID sehen. Alternativ an einer Tams MC über m3-Programmierung. Wenn bei beiden Loks die mfxUID identisch ist, dann hat Piko etwas falsch gemacht, denn die mfxUID müssen eindeutig sein.

Viele Grüße Dirk

Das Problem besteht ja ebenfalls bei RailComPlus. Daher ist es ja kein eigenständiges MFX Thema.
Wenn RailComPlus auch anhand einer ID arbeitet, dann sind wohl beide Identisch.

Ich habe so dass Gefühl, dass man schlicht vergessen hat, die IDs zu setzen und somit irgendwelche Standardwerte da drin stehen. Schon aus Prinzip sollten IDs für RailCom+ und mfx NICHT identisch sein.

Zitat von Dampfstoß im Beitrag #13

---

Zitat von Velzen im Beitrag #11

---

Ein Hersteller, der mfx-taugliche Decoder anbietet und dem nicht gerecht wird, hat seine Hausaufgaben nicht gemacht. Während Märklin das mfx-Protokoll veröffentlichte. Ich selbst weiß, wie mfx funktioniert und dcc nicht.

---

Schön für Dich. Dann weißt Du auch, dass mfx ein Krückenprotokoll ist, welches nie ausentwickelt wurde und nicht mal Zubehör ansteuert, ob wohl es das könnte, wenn man bei Märklin das gewollt oder gekonnt hätte. Noch heute braucht man für Weichen oder Signale DCC oder Motorola als Hilfsmittel. Aber im Grunde hat Märklin das mfx auch nur von ESU geerbt und dann nicht konsequent weiter entwickelt, weil man verkaufte ja auch so genug. Anbetracht der Tatsache, das mfx Spezialchips aus der Dampfradiozeit verwendet, wird das Protokoll früher oder später ohnehin verdrängt werden. Deshalb versucht man es jetzt krampfhaft zu erhalten und nur darum gab es die (teilweise) Öffnung des Protokolls. DCC hingegen wird immer noch gepflegt und erweitert und könnte in Zukunft sogar noch mal grundlegend verbessert werden - da alle Quellen frei verfügbar und für jedermann einsehbar sind. Und jeder mit ein bisschen Programmier- und Lötkenntnis kann sich ohne Probleme eigene Decoder oder Steuergeräte bauen.

Wenn ich Dich also zitieren darf: Ich habe nichts mit mfx zu tun und habe auch nicht vor, es zu verwenden.

---

Zitat von Velzen im Beitrag #18

---

Märklin hat das mfx-Protokoll freigegeben und es steht allen zur Verfügung, nur der Name ist geschützt.

---

Hallo,

Zitat von Velzen im Beitrag #18

---

Märklin hat das mfx-Protokoll freigegeben und es steht allen zur Verfügung, nur der Name ist geschützt. Du liegst also falsch und weißt nichts. Außerdem ist DCC nicht benutzerfreundlich genug und mfx ist das viel mehr und auch einfacher.

---

Zitat von nakott im Beitrag #15

---

Hallo,

mal zur eigentlichen Sache. Wenn man die Loks an einer CS2 anmelden würde, dann könnte man im CS2 Backup die mfxUID sehen. Alternativ an einer Tams MC über m3-Programmierung. Wenn bei beiden Loks die mfxUID identisch ist, dann hat Piko etwas falsch gemacht, denn die mfxUID müssen eindeutig sein.

Viele Grüße Dirk

---

Also mein Vater besitzt eine CS2.
Wie ich das ganze an der cs2 mache, weiß ich allerdings nicht.

Zitat von SSchaffrath im Beitrag #22

---

Also mein Vater besitzt eine CS2.
Wie ich das ganze an der cs2 mache, weiß ich allerdings nicht.

---

Wenn beide Loks die gleiche mfx-ID haben, wird nur eine an der Zentrale angemeldet, nämlich die zuerst antwortende, im Fall, dass man sie nacheinander aufstellt. Meine ich. Das ist ja der Sinn von eindeutigen Seriennummern. Ich würde einen Decoder tauschen lassen.

Also konnte nun bei meinem Vater einmal über dar CS2 Backup die Daten anschauen.

BR143 Artikelnummer: 51711


Vossloh G6 Artikelnummer: 52663


Also haben beide den selben Softwarestand in der CS2 und im Backup auch die selbe UID...

Kann ich das ausversehen mit der Ecos irgendwie überschrieben haben?
Oder kann das nur von Piko schon so sein?