Hallo, nach Firmwareupdate vom msD3 Nachrüstdecoder auf 3.3.1.0 war der Decoder unter DCC nicht mehr ansprechbar. Habe 4 Decoder geliefert. Dann zu Märklin eingeschickt. 4 Ersatzdecoder bekomnen, aber die hatten 3.2.2.1!
Also Märklin gefragt, was das soll. Denn, um die Decoder zu programmieren, ist ja wieder das Update auf 3.3.1.0 fällig und dann ist der Fehler ja wieder drin. Märklin antwortete, das Problem sei beseitigt. Dann aber müsste FW Versionsnummer ja hochgezählt sein.
Ist aber immer noch 3.3.1.0 !

Dann habe ich alle 4 Decoder dem Firmwareupdate auf 3.3.1.0 unterzogen und - oh Wunder - 3 Decoder funktionierten dann auch unter DCC, aber - oh Schreck, wie befürchtet - der 4. Decoder ist nach dem Firmwareupdate unter DCC nicht anzusprechen. Bei diesem Decoder passierte dann sogar noch Folgendes, als ich nach dem Firmwareupdate den Decoder beschreiben wollte, kam eine Fehlermeldung, dass die Firmware 3.3.1.0 veraltet ist und ich ein Firmwareupdate machen solle. Die 3.3.1.0 ist aber die neueste Version! Ein weiterer Versuch, das Firmwareupdate auf 3.3.1.0 zu wiederholen, resultierte in der Meldung "Decoder auf neuestem Stand" bzw "kein Update vorhanden".

Dann habe ich Folgendes herausgefunden: dieses Problem tritt dann auf, wenn man die Projektdatei mit Doppelklick öffnet und über die Dateierweiterung dann das MDT Märklin Decoder Tool gestartet wird. Macht man es anders herun, also erst das MDT öffnet und von dort das Projekt, dann konnte ich den Decoder beschreiben. Aber dennoch funktioniert er unter DCC nicht. Also: FW Update auf 3.3.1.0 auf die msD3 Nachrüstdecoder verhagelt Euch ggfls. den Betrieb unter DCC. Alle 4 Decoder gehen wieder an Märklin mit einer Mängelrüge zurück.

Es gibt noch einen weiteren Fehler, den ich Märklin vor 1,5 Jahren gemeldet habe, der heute 1 x wieder auftrat. Wenn man einen msD/3 Nachrüstdecoder beschreibt, ist immer mfx voreingestellt. Mit CV50 kann man dann das abändern auf nur DCC. Danach aber kommt es immer mal wieder vor, dass die CVs 260-261-262 zurückgesetzt werden, das ist meistens die Lokfunktion F0 Fahrlicht vorwärts. Man wundert sich, dass das Lokfahrlicht nach vorne nicht mehr geht. Abhilfe: nicht mit dem Märklin Decoder Tool diese CVs wieder richtigstellen (sonst wird wieder mfx eingeschaltet) sondern mit der Digitalzentrale diese CVs wieder richtigstellen.

Wenn man diese Erfahrung wie ich durchlebt und gleichzeitig in der Moba Community hört, welche Updateprobleme mit der CS3 die Leute zur Verzweiflung treiben, dann ist meine Erkenntnis: Märklin hat ein massives Softwareproblem.

Gruss
Frank

Hi Frank,

Bei deiner Problembeschreibung „Datei mittels Doppelklick öffnen“ würde ich annehmen, dass dabei nicht das mDT3 in Version 3.6 gestartet wird, sondern eine ältere Version.

Ich persönlich habe keine Probleme mehr, seit 3.3.x als dekoderfirmware, und mDT3 in 3.6.


Wenn es so ein allgemeines Problem wäre, wie du es denkst, dann würden sich hier und bei Märklin die Beschwerden „stapeln“


Viele Grüße, Michael

Hallo Michael,

vielen Dank für diesen sehr wertvollen Hinweis. Ich habe das kontrolliert und in der Tat öffnet sich
auf dem Weg über die Projektdatei das MDT in 3.5 und nicht in 3.6. Ich muss meinen PC also noch
nach der verwaisten exe Datei der Version 3.5 durchsuchen. Ich hatte dann ja andersherum mein
MDT in Version 3.6 geöffnet und von dort das Projekt geladen. Aber leider tut der Decoder
trotzdem nicht unter DCC.

Aber dass sich die Reklamationen "stapeln" würden, sehe ich nicht so. Erst einmal ist das ein
Nachrüstdecoder für alle diejenigen MoBa Anwender die Loks, die nicht von Märklin sind, mit
einem mfx fähigen Decoder ausrüsten. Oder für diejenigen MoBa Anwender, die die Märklin
Decoder, die ab Werk eingebaut sind und nur eingeschränkte CV Zugriffe erlauben, durch
einen frei programmierbaren Decoder ersetzen wollen. Die Mehrheit beider Anwendergruppen
aber werden als "eingefleischte Märklinisten" das mfx Protokoll benutzen und da funktioniert der
Decoder bestens. Die wenigsten User sind wie ich, die mfx aus ihrer MoBa verbannt haben und
reinrassig nur DCC fahren. Also, das von mir festgestellte Problem kommt nicht so oft vor.

Die Servicestelle von Märklin hat mir übrigens eine ChangeLog Information zugeschickt und
in der Version 3.3.1.0 wurde am 12. Juli 2023 ein Handlingsfehler im DCC Timeoutproblem behoben.
Offensichtlich aber nicht vollständig.

Viele Grüße
Frank

Hi Frank,

Ein Vorschlag/Versuch, den „faulen“ Dekoder doch wieder ans arbeiten zu bekommen (der bei mir funktioniert hat, als die Probleme akut waren):

Mittels CS2 die Firmware 3.2.2.x auf den Dekoder spielen (die CS2 hat mit stand letzte Woche noch nicht die aktuellen Firmwaredaten 3.3.x), und anschließend mittels Programmierstick oder cs3 sowohl die Firmware neu einspielen, als auch (mit mdt3 3.6) das Projekt neu in den Dekoder schreiben.


Viele Grüße, Michael

PS: schön, das mein Tipp zielführend war - wobei ich ehrlich gesagt nicht verstehe, dass du nicht selbst bemerkt hast, dass du (teilweise) auf der alten mdt3 Version unterwegs warst.
Denn die Version des mdt3 wird doch oben im Programm ständig angezeigt, oder täusche ich mich?

Hallo Michael, ja die MDT Version wird oben angezeigt, aber ich hab da halt nicht drauf geachtet.

Und Dein Tip, die alte FW auf den Decoder zu spielen, funktioniert bei mir nicht. Ich habe glücklicherweise keine CS3 (die beim letzten Update ja massive Probleme hatte), sondern die neueste ESU ECoS, mit der ich bisher problemlos alle msD3 Nachrüstdecoder (mit CV50 auf nur DCC) bei abgeschaltetem mfx Gleisprotokoll einlesen konnte. Die Probleme gingen mit 3.3.1.0 los, auch dann noch, wenn ich zuerst das MDT 3.6 öffne und dann das Projekt in den Decoder schreibe.

Was jetzt frustrierend ist, dass sich 3 der 4 Decoder unter 3.3.1.0 unter DCC betreiben lassen aber einer eben nicht. Wo liegt der Unterschied? Kann es sein, dass in der Projektdatei noch ein Fehler ist?? Ich habe jetzt nicht nur die 4 Decoder an Märklin erneut zurückgeschickt plus dem Herrn Pütz die 4 Projektdateien, die geladen wurden. Und auf dem Versandtaschenetikett jedes Decoders ist der Loktyp angegeben.

Eine Sache fiel mir noch auf: bisher war der reine DCC Betrieb der msD3 Decoder im CV50 immer mit einer 0 einzustellen. Jetzt habe ich die neue USA Diesellok ES44AC und dort den Decoder erstzt durch einen msD3 Nachrüstdecoder (noch in FW Version vor der 3.3.1.0) und da ist CV 50 für reinen DCC Betrieb mit 4 zu programmieren. Irgendwie inkonsistent. Bei selber Firmware muss der Decoder ja den CV50 im Verbund mit dem Loktyp analysieren, um zu wissen, dass jetzt nicht 0, sondern 4 der reine DCC Betrieb ist.

Gruss
Frank

Hallo,

Ich hatte das Problem auch. Hatte die Lösung auch mal beschrieben. Erst den Decoder mit Firmware update versehen. DANN NUR MIT DEM Decodertool 3.6 ansprechen.

Nun Wichtig! Es werden nicht alle alten Projekte richtig übersetzt.

DAS HÄNGT MIT DER Version zusammen mit welcher diese ursprünglich erstellt wurden.

DAHER SELBER ggf. NEUES Projekt in 3.6 erstellen. DANN LIEFEN BEI MIR BISHER ALLE unter DCC

MfG

Heiko

Hallo Heiko, danke für Deine Antwort. Wie legst Du dann das Projekt neu an? Klappt es, wenn man aus dem MDT 3.6 das "alte" Projekt aufruft / öffnet und dann neu abspeichert unter neuem Namen. Oder muss man aus der Bibliothek sich das Märklin Projekt neu laden und individuell anpassen?

Kann Deinen Tipp leider nicht austesten, weil alle 4 Decoder auf dem Weg zurück zu Märklin sind. Da ich denen ja auch meine zugehörigen Projekte gemailt habe, müssten die ja bei Märklin auch feststellen können, ob hier noch irgendeine Inkompatibilität vorliegt.

Viele Grüsse
Frank

Hi Frank,

Zur cv 50:

Vorwort:
Nachfolgendes ist Theoretisch abgeleitet aus der Anleitung, weil ich bei keiner meiner mSD3/mLD3 auch nur ein Format je abgeschaltet habe - wir/ich fahren mit IB2 oder gelegentlich mit der ms2 (da reicht die normale Priorität der Protokolle im Dekoder, um problemlos mit zu spielen):

Mit Wert 0 (in cv50) schaltest du alle Protokolle ab, außer dem, mit dem du gerade programmierst. Wenn du also mit DCC programmierst, und in cv 50 den Wert 0 schreibst, ist alles bis auf DCC aus.
Machst du das mit mm, ist Bus auf mm alles aus.

Bei der Programmierung des Wert 4 in der cv 50 werden wider alle Möglichkeiten abgeschaltet, bis auf dem „Programmier-Protokoll“ (DCC/MM) und zusätzlich wird das „Partner“ Protokoll, also bei DCC Motorola und bei Motorola DCC aktiv gelesen.


Es mach also keinen Sinn, wenn du nur DCC fahren willst, mittels DCC Programmierung in der cv 50 den Wert 4 zu schreiben, weil damit zusätzlich das Motorola Protokoll aktiv bleibt.
Richtiger wäre den Wert 0 zu schreiben, um eben alle anderen Protokolle abzuschalten.


Ich werde aber jetzt weder mit den GE ES 44ac, noch mit anderen Loks oder nachrüstdekodern irgendwelche versuche in der angegebenen Form durchzuführen.



Viele Grüße, Michael

Ich probiere es so, wenn das alte Projekt nicht unter DCC geht, dann wird ein neues angelegt erst mal nur Fahren ohne Sounds. Wenn das geht, muss man die Sounds neu dazu geben, aber ohne die alte Projektdatei. Also alles von Hand neu machen

Da ich woanders auch gefragt wurde, was die Ursache ist:

Das ist Pfusch von Märklin.

Man im Decodertool 3.6 nicht die Vorrausetzung gschaffen, dass Projekte von älteren Versionen immer richtig umgestellt werden. Wahrscheinlich hat man den Test von der Softwareversion 3.5 auf 3.6 mit Projekten auch geprüft. Aber nicht damit gerechnet das Kunden auch von 3.x z.B. 3.3 oder 3.4 Projekte benutzen. Die Struktur auf dem Decoder mit der neuen Firmeware 3.3.x setzt aber eine Struktur des Projektes aus 3.6 voraus.

Man hätte das ganze auch mit einem richtigen Updateverlauf der Softwareversionen lösen können, jedoch hat man auch hier den schnellen Low Cost ansatz gewählt.

Der Vorteil aus diesem Ansatz, wird aber nun durch Kundenreklamationen wohl aufgefressen.

Dürfte aber bei Märklin eine andere Kostenstelle sein.

MfG

Heiko