Technische Probleme und Lösungen

Aufgrund einer unglücklich gewählten Norm für die Decoder-Sperre kann es beim Programmieren mit ZCS dazu kommen, dass versehentlich die Sperre aktiviert wird und der Decoder unansprechbar wirkt.
Dies ist eigentlich kein Fehler! Es passiert, der Norm entsprechend, wenn CV #15 und CV #16, in dieser Reihenfolge (!), auf verschiedene Werte eingestellt werden.
Dies wird aber auch ausgelöst, wenn das ZCS beim Programmieren des Decoders (logischerweise) eine CV nach der anderen schreibt und dabei nacheinander CV #15 und 16 auf, absichtlich oder zufällig, verschiedene Werte setzt.

LÖSUNG:

ZCS-Versionen ab 4.19.005 umgehen das Problem, indem die CVs #15 und #16 nur mehr "absichtlich" gesetzt werden können.
Auch Decoder-seitig wird es künftig eine Sicherheitsvorkehrung geben

Sollte Ihr Decoder schon gesperrt sein, so setzen Sie mittels ZCS die CV #15 auf den selben Wert wie die CV #16. Ist dieser Wert nicht bekannt, so muss man leider durchprobieren. Sehr wahrscheinlich ist der Wert "0" (ZIMO-Standard) oder "2" (in manchen Sound-Projekten gesetzt).

Das TT Modell der BR 94.5 von Kühn kann aktuell nicht mit unseren MS-Decodern betrieben werden.

Wir suchen nach einer Lösung im Bereich der Motorregelung. Es scheint, dass unsere MS-Decoder nicht mit Entstörkomponenten auf der Lokplatine klar kommen und dadurch ein Fahren fast völlig verhindert wird.

Der auf den Piko (H0) Platinen als „C4“ gekennzeichnete Entstörkondensator hatte bis ca. 2018 (Baujahr der Modelle) eine viel zu hohe Kapazität, die die Motorregelung der ZIMO Decoder störte.

Abhilfe wird durch das ersatzlose Auslöten des Bauteils erreicht. Oft ist der „C4“ auch auf der Unterseite der Lokplatine zu finden.

Im Mai fand eine Lieferung an Roco von MX645P22 mit der SW-Version 36.19 statt, obwohl das geladene Soundprojekt BR 85 für die Funktionen F9 (Bergfahrt), F10 (Talfahrt) und F11 (Talfahrt mit Gegendruckbremse) die SW-Version 36.20 (oder höher) benötigt. Leider ist davon die Hälfte der Decoder bereits im Handel gelandet bevor das Problem aufgefallen ist, und nur mehr die noch lagernden Decoder (ca. 50%) bei Roco konnte ZIMO zum kostenlosen Update zurückrufen.

Abhilfe:
SW-Update vom Decoder auf 36.20 (oder höher) behebt das Problem.

Im April sind irrtümlich MX633P22 mit noch vorhandenem Indexpin geliefert worden.

Selbstabhilfe:
Einfach den Indexpin mit einem Seitenschneider vorsichtig abzwicken, darauf achten, dass man die daneben befindlichen Pins nicht verbiegt, sonst diese bitte mit einer Zange vorsichtig wieder gerade biegen.

Vereinzelt sind an einige wenige Fachhändler statt ZIMO MX645P16 (alle 5 Doppelfunktionsendstufen bestückt) irrtümlich die Roco OEM des MX645P16 (erkennbar, dass zwei Doppelfunktionsendstufen (für FA4, FA5, FA6 und FA7) fehlen, daher jene Funktionsausgänge, welche nicht über den PluX16-Stecker zur Verfügung gestellt werden) geliefert worden. Erkennbar sind diese daran, dass sie - trotz der Roco OEM Bestückung - keinen goldenen Markierpunkt auf der Rückseite haben. Da es sich um eine sehr geringe Stückzahl handelt und in der Regel die meisten Kunden nur jene Funktionsausgänge nutzen, welche am Stecker sind, bietet ZIMO bei Bedarf hier ein HW-Upgrade an.

Abhilfe:
Betroffenen Kunden, die beim MX645P16 z.B.: FA4 nutzen wollen, können den entsprechenden Decoder mit ausgefülltem Reparaturformular an ZIMO senden. Bitte am Reparaturformular angeben, dass "Decoder in Ordnung" ist und nur eine "Nachbestückung der fehlenden Endstufen" gewünscht ist.

Unter der Artikelnummer LGB "55025" gibt es Weichendecoder unterschiedlicher Bauart (die aber gleich aussehen); einigie davon verkraften nicht die normgemäße "RailCom"-Lücke, welche das MX10 standardmäßig in den DCC Datenstrom einbaut. Dies ist der Grund, warum die gleichen Weichendecoder mit den alten ZIMO Basisgerät MX1 problemlos funktionieren (dort gab es noch kein RailCom).

Abhilfe:
Ein Update auf Software-Version 1.19.0200 behebt den Fehler: Dort wird die RailCom-Lücke auf das Minimum dessen gekürzt, was gerade noch im zulässigen Bereich liegt. Dann funktionieren die Weichendecoder (allerdings nur "gerade noch"). Eine andere Möglichkeit ist es, RailCom im MX10 überhaupt abzuschalten, wobei man dann aber natürlich auf alle damit verbundenen Features verzichtet.

Bei der MX600-Serie mit Software-Version 31.62 ist ein Fehler bei der sporadisch ein Funktionsausgang nicht mehr schaltet. Dieser Fehler kommt nicht in allen MX600 vor.

Abhilfe:
Ein Update auf Software-Version 31.63 behebt den Fehler.

Bei einer Teilcharge produzierter Funkfahrpulte MX32FU funktioniert der Laderegler des Akkus nicht korrekt. Daher das Funkfahrpult ladet den Akku trotz längeren Anschluß an den CAN-Bus nicht auf.

Abhilfe:
Bitte betroffene MX32FU an ZIMO Reparaturservice einsenden, ZIMO führt eine entsprechende Modifikation am Laderegler kostenlos durch.

Bei einer Produktionscharge MX648-Serie (geliefert November und Dezember 2015) ist ein Fehler bei der automatischen Seriennnummernvergabe (CV#250 bis CV#253) passiert, die im ZSP angezeigte Seriennummer ist nicht korrekt.

Workaround/Abhilfe:
Einmalig muss über ein Fahrpult bzw. DCC-Zentrale die CV#250 manuell ausgelesen werden, dann korrigiert der Decoder den Fehler automatisch und CV#251 bis CV#253 enthalten dann eine korrekte (andere) Seriennummer. Falls Sie bereits einen Ladecode (für das Laden eines coded Soundprojekts) für die vorher "ungültig" Seriennummer angefordert haben, teilen Sie dies ZIMO bitte mit. Sie erhalten dann nach Prüfung den zu der neuen Seriennummer passenden Ladecode kostenlos.

ZIMO Sound Programmer (ZSP) in der aktuellen Version 1.12.19 und ZIMO Decoderupdate (aktuelle Version 5.6.0) können derzeit nicht in Kombination mit dem MXULFA (aktuelle Version 0.61.55) zum Soundladen und Softwareladen unter Windows 10 benutzt werden.

Abhilfe:
Es gibt jetzt eine neue ZSP-Version (1.13.00), in welcher der Treiber für das MXULFA und das MX31ZL auch Windows 10 unterstützt.

Kunden die damals noch einen nicht zertifizierten Treiber für MX31ZL und MXULFA genutzt haben, bitte diesen neu installieren. Der Treiber kann hier herunter geladen werden. Bitte das ZIP/RAR-File entpacken und die Datei "ZIMO Installer.exe" im Ordner Installer starten und "Treiber installieren" wählen.

Das Laden eines Sounprojektes ist nicht möglich.

Abhilfe: Um ein Soundprojekt in den MX658N18 laden zu können, muss zuerst ein Software-Update auf die Version 33.33 gemacht werden. Nach dem Update kann problemlos der Sound eingespielt werden.

Einige PIKO -oks haben im Rahmen der Motorentstörung derartig große Kondensatoren parallel zum Motorausgang geschaltet, daß der Betrieb stark behindert wird, oder es sogar zur Überstrom-Abschaltung führt.

      

Abhilfe: Der "schädliche" Kondensator, auf der Lokplatine üblicher Weise mit "C4" gekennzeichnet, muss entfernt werden! Dazu muss häufig die Lokplatine entnommen werden, weil der Kondensator auf der Unterseite platziert ist.

Bei der allererste Hardwarerevision 5 vom MX32 (erkennbar an den Resetpads auf der Rückseite, siehe MX32 Anleitung), wo es nur Kabelfahrpulte (keine Funkfahrpulte) gab, kann es bei sehr langer Nichtnutzung (ca. über 6 Monate) aufgrund eines Designfehlers bei der internen Ladeschaltung zu einer Tiefentladung vom Akku kommen. Die Tiefentladung bewirkt, dass die eingestellten GUIs der Lok nicht mehr vorhanden sind bzw. die Funktionssymbole nicht mehr angezeigt werden bzw. auch die gespeicherten Fonts weg sind (erkennbar an der sehr kleinen Schriftgröße). Den Effekt der Tiefentladung des Akkus kann man verhindern indem man das Gerät eine alle paar Monate am CAN-Bus anschließt und etwas wartet bis sich der Akku wieder etwas aufgeladen hat, bevor man es wieder absteckt.

Eine echte Behebung ist nur durch ein kostenpflichtiges Hardwareupgrade auf die Revision 7 (zweite verkaufte Hardwarerevision) möglich.

Abhilfe: Bitte das MX32 Revision 5 mit beigelegten ausgefülltem Reparaturformular (Download hier) und der Angabe, ob das MX32 Rev. 5 auf MX32 Kabelversion Rev. 7 ODER auf MX32FU Funkversion Rev. 7 upgeraded werden soll, an ZIMO schicken. Das Upgrade auf die Funkversion Rev. 7 ist etwas teurer als das Upgrade auf die Kabelversion Rev. 7. Die Revision 7 (zweite verkaufte Hardwarerevision vom MX32) hat einen schnelleren Prozessor und 4GB Speicher (statt nur 1 GB als in Revision 5). Den Preis für das Upgrade können Sie per Email an office@zimo.at bzw. per Telefon direkt im ZIMO Verkauf erfragen.

Die Versorgung von Servos wird an ADAPLU50 (= Ausführung der Adapterplatine mit 5V - Funktions-Niederspannung) angeschlossen an der Niederspannung „NSpg“ (= 5V) und „GND“ (Masse), gesteuert durch die Servo-Steuerleitung, auf einem der Anschlüsse „SUSI Clock“ oder „SUSI Data“ (der aufgesteckte Decoder muss dazu passend programmiert sein, siehe Betriebsanleitung).

Problembeschreibung: Die handelsüblichen Servoantriebe verhalten sich sehr unterschiedlich; während viele Typen problemlos betrieben werden können, gibt es bei anderen diverse Probleme, in vielen Fällen auch davon abhängig ob bzw. nur dann wenn die Digitalzentrale eine „RailCom-Lücke“ macht. Dies führt zu Ruckeln im Stillstand, oder mehrfachem Hin- und Herlaufen nach Power-an und beim Schalten der betreffenden Funktion.

Abhilfe: In solchen Fällen ist das meistens durch Kondensatoren möglich — 1) Elko mit 2200 µF, 16 V oder mehr an die übliche Energiespeicher-Anschaltung, also zwischen „ELKO Plus“ und „GND“, und 2) Elko mit 220 µF, 6 V (auch mehr oder weniger als 2200 µF, probieren!) in die Versorgungsleitungen der Servos (also zwischen „NSpg“ und „GND“).

Die Miniaturlautsprecher LS10X12, LS10X15, LS10X15H11 und LS15X25 dürfen ausschließlich nur mit einem geschlossenen Resonanzkörper und nicht mit voller Lautstärke betrieben werden.

In beiden Fällen kommt es zu Übersteuern! Als maximal mögliche Lautstärke wird CV#266=64 empfohlen (hängt auch vom Soundprojekt ab).

Maxxon hat neue Motore produziert, die in einigen neuen Großbahnmodellen verbaut sind, welche sich nicht einwandfrei ansteuern lassen.

Die Loks fahren bei aktiver Märklinbremsstrecke weiter.

Alle MX633 / MX634 seit Erstauslieferung reagieren auf HLU nicht. Fehlerbehebung derzeit mit Einzel-Decoder-SW - V31.3 . Download HIER!

Einige Decoder aus den Lieferungen der vergangen 2-3 Monate machen bei der ersten Inbetriebnahme den Eindruck defekt zu sein, obwohl sie es nicht wirklich sind. Grund dafür ist eine starke Verschmutzung durch Flussmittel der Stifte des NEM652 - Steckers, die bei dem von uns beauftragten Kabelbaum - Fertigungsbetrieb passiert sein dürfte und beim testen der Decoder in unserem Haus nicht aufgefallen ist. (andere Kontaktierungsvorrichtung als in den meisten Loks vorhanden ist)

Abhilfe: Stecker putzen ...

Hinweis: Diese Verschmutzung dürfte die eigentliche Ursache für den im April 2013 gemeldeten Fehler, siehe unten, betreffend Decoder MX623 gewesen sein. In diesen Fällen handelte es sich offensichtlich doch nicht um einen Fehler im Microcontroller-Chip wie dort vermutet wurde.  

Einige der im April 2013 gelieferten Decoder der Familie MX623 (besonders häufig der Typ MX623R) sind funktionslos ("tot"), obwohl sie vor Auslieferung getestet wurden und einwandfrei funktioniert haben. Als Ursache wird ein Defekt im Microcontroller-Chip (Flash-Speicher ) vermutet, sodass dieser den Programmcode nicht vollständig und dauerhaft speichert.

Mit diesem Fehler zu ZIMO eingesandte Decoder werden ersetzt. 

Nach dem Einspielen von SW 0.36 kann kein weiteres Selbstupdate des MXULF/A über die übliche Prozedur (Taster 3) durchgeführt werden.

Das Selbstupdate von SW Version 0.36 auf SW Version 0.37 ist über folgende Prozedur durch zu führen:

- USB-Stick mit einer Softwareversion (bzw. Bootloader) für MXULF/A anstecken

- Taste 2 und Richtungstaste gleichzeitig drücken und dann MXULF/A einschalten (Stromversorgung) - ACHTUNG: Das Selbstupdate wird dann automatisch ausgeführt.  

Störungen wie
- Wiederanfahren bei noch rotem Signal oder
- nicht komplettes Anhalten

 können verursacht sein durch die Tatsache, dass die üblicher Weise verwendete Diodenschaltung den gewünschten Spannungsabfall nur bei Vorhandensein eines gewissen Stromflusses erzeugen kann. Wenn zu wenig Strom durch die Schaltung in die Lok fließt, ist der Spannungsabfall für die ABC-Erkennung zu klein. Durch den Einsatz von LEDs anstelle von Glühbirnchen und durch Einsatz von Energiespeichern in den Loks wird oft zeitweise kaum Strom verbraucht, insbesondere wenn die Geschwindigkeit zurückgeht; Dadurch ergibt sich das Phänomen, dass die Lok  in der ABC-Strecke zum Bremsen anfängt oder sogar zum Stehen kommt, dadurch besonders wenig Strom verbraucht, die jetzt zu geringe Asymmetrie nicht mehr erkennt, und daher wieder beschleunigt und das rote Signal überfährt.

Abhilfe:  ein fester Verbraucher (erfahrungsgemäß ein Widerstand von ca. 1 K, ½ W) sollte die Diodenstrecke belasten, am besten angeordnet zwischen den Schienenanschlüssen in der Lok.
An sich könnte ein solcher Widerstand auch außerhalb der Lok direkt auf der ABC-Strecke, also auf der Schiene angebracht werden, allerdings würde dann eine eventuell vorhandene Besetztmeldung dauer-ausgelöst werden.

Wegen eines SW-Fehlers in der Schienenspannungsmessung können die oben angeführten Fehlfunktionen auftreten.

Betroffen sind wahrscheinlich alle bisher ausgelieferten Decoder der Familie MX621, obwohl in den  meisten Anwendungen das Fehlverhalten kaum zu merken ist.

Abhilfe: Software auf Version 31.0 oder höher.

Wegen einer unbemerkten Änderung von Bauteil-Parametern werden ein Teil dieser Decoder im normalen Betrieb ungewöhnlich heiß (abhängig von Verbrauch), außerdem funktioniert die ZIMO Zugnummern-Erkennung nicht oder unzuverlässig, und ebenso funktioniert das Software-Update und das Sound-Laden nicht. Gemeinsame Ursache für diese Probleme ist die zu geringe Amplitude der Quittungspulse - auch ZIMO Zugnummernimpulse genannt - die durch die Motorendstufe erzeugt werden.

Erkennung der fehlerhaften Decoder: Unterseite, äußeres Bauteil auf Gegenseite von angelöteten Drähte oder PluX-Stecker (Motorendstufe), Beschriftung 3. Zeile letzter Buchstabe "B" (schlecht), "C" (gut).

Abhilfe: in der Regel muss ein solcher Decoder bei ZIMO repariert werden (Garantiefall); was das Software-Update und Sound-Laden betrifft, ist unter Umständen (derzeit mit MXDECUP und ZSP, in Zukunft eventuell auch mit MXULF) ein Update-Vorgang ohne Rückmeldung möglich.  

Wegen einer unbemerkten Änderung von Bauteil-Parametern funktioniert bei einem Teil dieser Decoder das Software-Update und das Nachladen von Sound-Projekten nicht.

Abhilfe: Entfernung des Bauteiles (rot gezeichnet, "C6", ein Kondensator) laut untenstehendem Auszug des Bestückungsplanes oder Reparatur bei ZIMO (Garantiefall).

Die seit Mitte April gelieferten Magnetartikel-Decoder MX82E, MX82D, MX82V  haben zum Teil keine Funktion auf den Anschlüssen für Servos bzw. Schalteingänge. Dies ist auf einen Bestückungsfehler zurückzuführen.

Abhilfe: Reparatur bei ZIMO (Garantiefall).

Die Großbahn-Decoder MX695 in der aktuellen Bauart (ab 2012 soll dies geändert werden) haben im Vergleich zu anderen ZIMO Decodern nur eine relativ kurze Zeit des Speicher-Erhalts (Zehntel sec - Bereich) für die aktuellen Fahrdaten. Wenn also eine Kontaktunterbrechung zur Schiene länger dauert als diese Zeitspanne, kommt es zum Power-on-Reset des Decoders und zum Weideranlauf von Motor und Sound wie aus dem Stand.

Abhilfe: Anschließen eines Energiespeichers (meistens Elektrolyt-Kondensators) an den dafür vorgesehenen Schraubklemmen oder Stiften (obere Leiste, links). Um eine entsprechende Wirkung zu entfalten, sollte die Kapazität des Kondensators zumindest einige 1000 uF betragen, da ja aus diesem Kondensator auch Motor, Sound-Erzeugung, und andere Verbraucher gespeist werden. Demgemäß besteht eine starke Abhängigkeit der resultierenden Speuicherzeit vom allgemeinen Stromverbrauch.

Diese Erscheinung ist bekannt zusammen mit Zentralen von Lenz und Uhlenbrock: Durch den Ladestrom, mit dem der MX695 seine internen Kapazitäten auflädt, kann es zur Abschaltung des Programmiergleis-Ausganges kommen. OB das tatsächlich passiert, hängt von verschiedenen Umständen ab, beispielsweise von der Versorgungsspannung.

Provisorische Abhilfe: Einige Anwender berichten, dass durch Vorschalten eines 12 Ohm - Widerstandes in die Schienen-Leitung der Stromverbrauch genügend abgesenkt wird, um das unbeabsichtigte Abschalten der Zentrale zu vermeiden. Dies ist eine unter Großbahnern bewährte Methode, weil eine ähnliches Problem auch mit Decodern anderer Hersteller auftritt.

Abhilfe: Die nächste Auflage der Großbahn-Decoder ab Juli/August 2011 wird einen kleineren Strom ziehen; dies sollte das Problem beseitigen oder zumindest unwahrscheinlicher machen.

Aufgrund von zu großer Stromaufnahme beim Hochfahren (sämtliche interne Kondensatoren werden geladen) der MX695- und MX696-Serie muss beim MXDECUP/U eine kleine Modifikation (ergänzen von Widerständen, welchen den anfänglichen Strom limitieren) durchgeführt werden.

Betroffene Kunden können bei ZIMO die zwei zu ergänzenden Widerstände kostenlos anfordern.

Abhilfe: Modifikation MXDECUP/U gemäß Anleitung

Die folgenden Probleme sind in letzter Zeit bekannt geworden:

- Auslesen von CV's im Operational Mode (PoM): Bei manchen Systemen kommt die Meldung des Wertes erst bei der zweiten Abfrage oder gar nicht. Hintergrund: Bei einer Zentrale die den DCC-Auslese-Befehl (ebenso wie Schreib-Befehle) mehrmals hintereinander sendet, z.B. bei ZIMO, ist dieser Fehler nicht feststellbar; bei einigen anderen Systemen (die einmal senden) gibt es dieses Problem.

- Adress-Erkennung und -Anzeige durch einen "lokalen RailCom-Detektor" funktioniert bisweilen unzuverlässig oder verzögert (möglicherweise besonders, wenn nur diese eine Adresse im System), festgestellt in einer Anwendung zusammen mit Tams-Produkten. Hintergrund: Ein ZIMO Decoder mit bisheriger Software hat seine eigene Adresse im sogenannten "Broadcast-Channel" nicht ausgesendet, wenn die eigene Adresse angesprochen wurde,  weil diese in Daten-Kanal sowieso quittiert wird. Wenn allerdings ein "lokaler Detektor" nur den Broadcast-Channel liest und gleichzeitig nur oder fast nur diese eine Adresse ausgesendet wird, funktioniert die Meldung nicht.

Abhilfe: SW-Update auf 30.10 oder höher.

Dies ist kein eigentlicher Entwicklungs- oder Produktionsfehler, sondern eher eine Fehleinschätzung der Anwenderwünsche: aus Speicherplatzgründen (wegen Miniaturisierung kleinerer Prozessor als andere ZIMO Decoder) sind einige der sonst üblichen Software-Features im MX621 nicht implementiert. Dies betrifft u.a. das MM-Format (nicht vorhanden), die Servo-Ansteuerung (nicht vorhanden), Lichteffekte, und eben auch einen großen Teil des über das NMRA-konforme hinausgehende Function mapping (CV 61 = ... Fälle, darunter auch die Prozedur CV # 61 = 98).

Während der größte Teil der dadurch verursachten Einschränkungen für die Anwendungen eines Miniatur-Decoders belanglos sind, gibt es eine Betriebsvariante, die jetzt fehlt und doch vielfach genwünscht wird: der "einseitige Lichtwechsel", bisher entweder über die CV # 61 = 98 Prozedur oder über die Effekte programmierbar.

Wegen des großen Bedarfs werden wahrscheinlich in der nächsten SW-Version die bisher unbenützten CV's 47, 48 dafür herangezogen, um zumindest den "einseitigen Lichtwechsel" möglich zu machen.

Abhilfe: SW-Update auf zukünftige Version, wo der beschriebene Mangel behoben ist (also die CV's # 47, 48 eingebaut sind.

Wegen eines Bestückungsfehlers arbeitet die Rückmeldung (CV-Auslesen, Geschwindigkeits-Meldung, Adress-Rückmeldung) über RailCom nicht.

Fehler verifizieren: CV # 29, Bit 3 einschalten (also z.B. CV # 29 = 14) und CV # 28 = 3. Fahrbetrieb mit RailCom-fähigem Digitalsystem, z.B. ZIMO MX31ZL. Wenn dann keine Geschwindigkeitsmeldung (kmh ...) im Display aufscheint, ist der betreffende Decoder bezüglich RailComdefekt.

Abhilfe: In diesem Fall ist zu Behebung nur eine Hardware-Reparatur bei ZIMO möglich.

Die beiden genannten Betriebsarten (siehe CV's # 135, 136 bzw. # 140 .. 143) sind anscheinend durch Software-Modifikationen in der Vergangenheit beschädigt worden. Die gewünschte Funktion ist daher mit der aktuellen Software nicht oder nicht vollständig gegeben.

Abhilfe: SW-Update auf zukünftige Version, wo dieser Fehler behoben ist.

Bei Verwendung der sogenannte "Märklin-Bremsstrecke" und gleichzeitiger Verwendung des MM-Formates (Motorola, meistens Märklin-Zentrale) Fährt der Zug nach Aufhebung der Bremsstrecke nicht selbsttätig wieder an.

Hingegen: bei DCC Format und "Märklin-Bremsstrecke" (ist praktisch gleich der Gleichstrom-Bremsstrecke) tritt dieser Fehler nicht auf.

Abhilfe: SW-Update auf 28.25 oder höher

Durch einen Bauteil-Bruch am Decoder, der beim routinemäßigen Produktionstest nicht erkennbar ist, kommt es zu einem Fehlstrom in der Motor-Endstufe des Decoders, der den Stromverbrauch, und damit die Erwärmung des Decoders erhöht. Im Allgemeinen tritt dieser Effekt jedoch nur auf, wenn die Fahrspannung höher als ca. 20 V ist. Dies ist vor allem bei Digitalzentralen ohne Spannungsregelung der Fall, daher (auf den ersten Blick paradoxer Weise) bei besonders kleinen, preisgünstigen Produkten und geringer Belastung.

Es ist derzeit nicht wirklich bekannt, wie viele der gelieferten Decoder diesen Fahler aufweisen; es könnten bis 20 % sein.

Erkennung des Problems: Fahrverhalten beim Rückwärtsfahren ist schlechter als im Vorwärtsbetrieb, Geräusche beim Rückwärtsfahren, manchmal schaltet die Digitalzentrale ab (was natürlich nur bei relativ "schwachen" Zentralen passiert), ev. kann der Decoder beschädigt werden, d.h. die Endstufe zerstört (eine Fahrtrichtung fällt aus oder beide).

Abhilfe: Reparatur bei ZIMO

Der Typ MX645 wird seit Dezember 2010 ausgeliefert.

Es kommt (je nach SW-Version leicht unterschiedlich) zu verzögertem Einschalten der FA5 bis FA8, Nicht-Funktion der FA7 - FA8, und Nicht-Wirkung der Dimm-Maske 2 für die FA's ab FA7.

Abhilfe: SW-Update auf 28.15 oder höher

Durch einen Software-Fehler bezüglich der Überstrom-Abschaltung für Funktions-Ausgänge kommt es ohne Anlass zum Abschalten der Lichter (besonders wenn es sich um Glühbirnchen handelt und nicht nur um LEDs); nach einigen sec schaltet sich das Licht wieder automatisch ein.

Abhilfe: SW-Update auf 28.10 oder höher

Bei Durchführung des SW-Updates mit dem Update-Gerät MXDECUP kommt die Fehler-Meldung "Framing error" - Das Update wird aber trotzdem durchgeführt !!!     Ursache ist ein Fehler im Boot-Loader der Decoder; dieser wird nicht durch ein Software-Update beseitigt (obwohl dieses - siehe oben - an sich funktioniert) !

Abhilfe: Fehler-Meldung ignorieren ... besser: sobald erhältlich auf das neue Update-Gerät MXULF wechseln !

Dies betrifft (wahrscheinlich) Decoder mit Software-Versionen 27.7 bis 28.9.

Der Decoder spricht nicht an auf die MAN-Taste des ZIMO Fahrpultes (MN beim MX32), sowohl was das Aufheben der ZIMO Zugbeeinflussung (HLU) betrifft) als auch, wenn MAN in Verwendung als Rangiertaste.

Abhilfe: SW-Update auf aktuelle Version durchführen.

Das Zeitverhalten im Programmiermodus (am Programmiergleis, "service mode") eines Fertigungsloses der ZIMO (Nicht-Sound-) Decoder MX630, MX631 weicht leicht von der Norm ab, was bei Digitalsystemen, die diesbezüglich  wenig Toleranz aufweisen, dazu führt, dass das Programmieren/Auslesen der CV's sowie das Adressieren (Zuteilung einer neuen Fahrzeugadresse) am Programmiergleis (im SERVICE MODE) nicht funktioniert.

Bekannt ist derzeit, dass das Programmieren/Auslesen mit Lenz Digitalsystemen sowie Uhlenbrock Digitalsystemen (Intellibox I, wahrscheinlich auch II) davon betroffen ist.  Über Probleme mit anderen Systemen ist (derzeit) nichts bekannt.

Abhilfe im Falle eines Lenz-Systems: es kann das "Quittungsverfahren durch Hochfrequenz-Hochstromimpulse" verwendet werden, welches an sich für andere Aufgaben geschaffen wurde, aber "zufällig" hier auch hilft. Dafür ist folgende CV-Programmierung notwendig:

  CV # 112, Bit 1 = 1,    also z.B.  CV # 112 = 5

Besser ist natürlich ein SW-Update auf die aktuelle Version.

Abhilfe im Falle eines Uhlenbrock-Systems: das obige Verfahren (wie für Lenz) hilft nicht; CV-Programmieren kann also nur unbestätigt durchgeführt werden; CV-Auslesen ist nicht möglich.

Im Falle des Adressieren ist auch keine unbestätigte Durchführung möglich, weil bei Adressieren das Auslesen der CV # 29 unumgänglich ist. Ersatzweise kann das eigentliche Adressieren durch direktes (unbestätigtes) CV-Programmieren ersetzt werden:

Im Falle einer "kurzen" Adresse (1 bis 127): die gewünschte Adresse einschreiben in CV # 1,
im Falle einer "langen" Adresse (ab 128): gewünschte Adresse in CV # 17 und 18
(die Art der Codierung der langen Adresse kann man erfahren, indem man versuchsweise einen
Decoder mit funktionierendem Auslesen regulär adressiert und dort das Ergebnis aus CV # 17 und 18 ausliest)

Bei Wechsel zwischen kurzer und langer Adresse: CV # 29 neu programmieren
(mit Bit 5 = 0 für kurze Adresse, Bit 5 = 1 für lange Adresse)

Besser ist natürlich ein SW-Update auf die aktuelle Version.

ZIMO Decoder, die werksseitig in Fahrzeuge der Fa. Roco, Fleischmann, HAG, und anderer Hersteller eingesetzt werden, sind häufig gegen ein SW-Update gesperrt; dies geschieht aus Sicherheitsgründen, damit der Decoder (insbesondere im Analogbetrieb) nicht versehentlich in den Update-Modus geraten kann (wo er dann nicht mehr fahrbar wäre).

Wenn ein solcher Decoder bzw. eine Lok, die einen solchen ZIMO Decoder enthält, mit einer neuen SW-Version versehen werden soll, wird der Decoder von der Update-Software (ZSP, ZIRC, ..) als "nicht gefunden" gemeldet !

Abhilfe: vor dem SW-Update: 

  CV # 144 = 0

setzen ! Damit wird in der CV # 144 auch das Bit 7 gelöscht, welches für die Update-Sperr zuständig ist. Danach kann die neue Software geladen werden (wie üblich mit MXDECUP oder MX31ZL und Software ZSP, ZIRC, ..)

Zusatzhinweis: In manchen Fällen wird das SW-Update auch behindert, wenn Analogbetrieb eingeschaltet ist, was bei werksseitig eingebauten Decodern meistens der Fall ist. Wenn dies der Fall ist - oder gleich vorbeugend - kann der Analogbetrieb dieser ausgeschaltet werden durch

CV # 29, Bit 2 = 0,    also z.B.  CV # 29 = 10 (anstelle 14, was oft vorgegeben ist)

Nach erfolgtem Update können natürlich Analogbetrieb und/oder Update-Sperre bei Bedarf wieder aktiviert werden: CV # 29 = 14, CV # 144 = 128.

HiHinweis: ein neues - besonders komfortables Decoder-Update-Gerät - MXULF - ist in Entwicklung und wird das vorhandene MXDECUP ablösen ! Dieses kann auch offline arbeiten ("Decoder-SW-Update" aus dem USB-Stick), wird Testfahrten möglich machen, und wird natürlich auch das Sperr-Bit in CV # 144 selbsttätig löschen ...

Diese Problem kann auftreten, wenn in CV # 155 und/oder CV1 # 156 eine Funktion als Rangiertaste zugeordnet ist, und die Digitalzentrale den aktuellen Zustand der betreffenden Funktion (z.B. F6) -dass sie nämlich ausgeschaltet ist - nicht aussendet, weil das Digitalsystem die betreffende Funktion (z.B. F6) gar nicht kennt, weil z.B. nur die Funktionen F0 bis F4 bedient werden.

Dies ist vor allem bei älteren Digitalsystemen der Fall (altes Märklin System, altes Roco Lokmaus System, ... deswegen wurde das Problem auch nicht vor Auslieferung erkannt.

Der Decoder nimmt dann zufällig einen Zustand (ein/aus) für diese Funktion (z.B. F6) an, und schaltet damit den Rangiergang manchmal ein. Dies macht sich vor allem dadurch bemerkbar, das die Lok nicht mit normaler Geschwindigkeit fährt, sondern schleicht. Die Lok verhält sich aber meistens nicht dauerhaft so, sondern das Problem kann nach Power-on verschwinden oder wieder-auftreten, bzw. auch nach verschiedenen Bedienungsschritten.

Eventuell betroffene Fahrzeuge mit einem ZIMO Decoder als Erstausstattung sind:

ROCO, FLEISCHMANN:
E10/BR110  (F9 als Rangiertaste)
DA-SJ (F6 als Rangiertaste)
BRBR44 (F6 als Rangiertaste)
Railjet (F6 als Rangiertaste)
BR43 (F6 als Rangiertaste)

HAG:
MX631, 631C (F4 als Rangiertaste)

NICHT betroffen: ICN, S231, S60, BR18.201, 1245

Abhilfe: N Null-Setzen der Rangiertasten-CV's, also 

 CV # 155 = 0   und CV # 156 = 0

Damit ist die Rangierfunktions beseitigt, was keinen Verlust darstellt, weil sie vom betreffenden Digitalsystem ohnedies nicht bedient werden könnte.

Da hauptsächlich Motorola-Fahrer betroffen sind (altes Märklin System ...), hier eine kurze Beschreibung, wie diese Programmierung von einem Märklin 6021 aus durchzuführen ist:

Um in den Programmiermodus einsteigen:
- die Adresse der zu programmierenden Lok anwählen
- "STOP"-Taste auf der Zentrale drücken und einige Sekunden warten
- Geschwindigkeitsregler über den linken Anschlag hinaus drehen, halten (Richtungsumkehr)
- "START"-Taste auf der Zentrale drücken
- Geschwindigkeitsregler loslassen

Der Decoder sollte nun im Programmiermodus sein und das Frontlicht im Abstand von einer Sekunde blinken. Nun folgende Adressen eingeben und danach. Richtungsumkehr betätigen (RU=Richtungsumkehr):
- Adr. 80, RU, RU  (wechselt in den Modus zum programmieren von CV's > 79)
- Adr. 15, RUr
- Adr. 5, RU
- Adr. 80, RU, RU
- Adr. 15, RU
- Adr. 6, RU
- Adr. 80, RU, RU

DaDas Anhalten in einer Gleichstrom-Bremsstrecke (auch "Märklin" - Bremsabschnitt) funktioniert zwar planmäßig, jedoch fährt die Lok  nach dem Aufheben einer Gleichstrom-Bremsstrecke (wenn also wieder ein DCC-Signal angelegt wird) nicht selbsttätig wieder an.

Das Problem tritt nicht bei Betrieb mit einem ZIMO Digitalsystem auf !

Abhilfe: F Folgende CV-Programmierungen machen den Fehler unwirksam (obwohl diese CV's eigentlich nichts mit DC-Abschnitten zu tun haben, sondern mit ABC):

 CV # 27 = 3   und CV # 134 = 150

Allerdings funktioniert dann ABC nicht mehr (aber dieses wird selten zusammenmit DC-Bremsabschnitten verwendet). Besser ist natürlich ein SW-Update auf die aktuelle Version.

Hinweis: ein neues - besonders komfortables Decoder-Update-Gerät - MXULF - ist in Entwicklung und wird das vorhandene MXDECUP ablösen !

Versehentlich wurden in den letzten Monaten ein Teil der Sound-Decoder ohne bzw. mit unvollständiger ID in den CV's # 250 - 253 ausgeliefert; hauptsächlich solche, die werksseitig in Fahrzeuge der Fa. Roco eingebaut wurden.

Im Normalfall macht das kein Problem, da bereits das passende Sound-Projekt geladen ist. Falls aber in einen solchen Sound-Decoder ein anderes Sound-Projekt geladen werden soll, und dieses andere Sound Projekt ein kostenpflichtiges ist, müsste dafür ein Lade-Code angefordert werden, was aber ohne Decoder-ID nicht möglich ist.

Abhilfe: Auslesen der CV # 250 von einem Fahrgerät aus (nicht vom Computer); das Ergebnis des Auslesens ist in diesem Zusammenhang belanglos (es handelt sich um einen Code für den Decoder-Typ), aber es führt dazu, dass eine automatische ID (Zufallszahl) gebildet wird. Diese kann dann auch vom Computer ausgelesen werden, und für die Anforderung eines Lade-Codes verwendet werden.

Beim Laden eines Sound-Projektes über das Decoder-Update-Gerät MXDECUP kommt es zum Abbruch, obwohl der Decoder zunächst erfolgreich gefunden wird, und auch ein eventuelles Software-Update durchgeführt werden kann. Ursache für das Problem dürfte ein elektrisches Übersprechen zwischen nahe-liegenden Leiterbahnen auf der Decoder-Platine sein.

Bei den selben Decodern kann es übrigens auch zu Sound-Verzerrungen kommen, wenn die Schienenspannung größer als ca. 20 V ist.

Abhilfe: Decoder in umgekehrter Polarität am MXDECUP anschließen; Software-Update auf Version 27.6 oder höher.

Bei einem Teil der etwa im Juli, August 2010 produzierten Sound-Decoder MX642 funktioniert bei angeschlossenem Energiespeicher-Kondensator das CV-Auslesen am Programmiergleis nicht.

Abhilfe: abgesehen von der provisorischen Lösung des Abtrennen des Kondensators kann das Problem nur durch eine Reparatur in der ZIMO Werkstätte behoben werden.

Durch einen Fehler innerhalb der verwendeten Microcontroller funktionieren viele der Sound-Decoder, welche im Jahr 2010 ausgeliefert worden sind, nicht stabil bei höheren Temperaturen. D.h. ab eíner Decoder-Temperatur von ca. 80 C kann es zum "Absturz" der Software kommen, wodurch der Decoder nicht mehr ansprechbar ist.

Abhilfe: Der defekte Microcontroller muss ausgetauscht werden; diese Reparatur ist nur in der ZIMO Werkstätte möglich; sie erfolgt natürlich auf Garantie.

In den letzten SW-Versionen (etwa ab 25.0) und mit einigen Antriebsarten tritt ruckeliges Fahrverhalten (eher bei MX640 gesehen) auf bzw.  "Bocksprünge" (gelegentliches Hochlaufen des Motors, gesehen beim MX630).

Abhilfe: Update des Decoders auf die Version 26.4 oder höher..

Bei Verwendung der Decoder zusammen mit Lenz-Systemen wird bisweilen der "Signalhalt durch asymmetrisches DCC-Signal" (Lenz ABC) eingesetzt. Kundenberichte sprechen davon, dass diese Funktion mit den aktuellen SW-Versionen der ZIMO Decoder nicht sicher funktioniert.

 Abhilfe: Neue SW-Version ab Juli 2010

Durch Pseudo-Programmieren der CV # 7 können höher CV's und höhere CV-Werte (jeweils > 99) mit Geräten erreicht werden, welche nur einen Wertebereich 0 - 99 beherrschen, wie Lokmau-2. Durch Software-Modifikationen im Decoder (wahrscheinlich mit Version 25.0) ist dies Funktion versehentlich gestört worden.

Abhilfe: Update des Decoders auf die Version 25.4 oder höher. 

Diese Prozedur dient zur richtungsabhängigen Zuordnung von Funktionsausgängen zu Funktionen, was mit dem "normalen" Function mapping" nach NMRA nicht möglich ist. Durch Software-Modifikationen im Decoder (wahrscheinlich mit Version 25.0) ist dies Funktion versehentlich gestört worden.

Abhilfe: Update des Decoders auf die Version 25.4 oder höher. 

Januar 2009Die SW-Version 20.19 bewirkt beim Sound-Projekt für den "roten Brummer" VT98 nach einiger Zeit (jeweils nach Power-on) normaler Funktionsweise, einen immer rascheres Abspielen einer Funktions-Sounds. Diese SW-Version ist an sich eine Spezial-Ausgabe für ein anderes Hersteller-Projekt und wurde versehentlich in eine größere Serie Decoder geladen.

Abhilfe: Update des Decoders auf die "ältere" Version 20.18 bzw.

Endgültige Abhilfe: neue SW-Version 25.0 ab Juli 2009.

Das MX31ZL kann bekanntlich sowohl als Zentrale als auch als "normales" Fahrpult angeschlossen an einem Basisgerät MX1, ... oder auch an einem anderen MX31ZL, verwendet wird. Wenn ein MX31ZL als Fahrpult an eine bereits laufende Konfiguration angeschlossen wird, kommt es zum Zwangs-Resewt aller Geräte am CAN-Bus, d.h. die Züge bleien stehen, usw. Dieser Effekt hat sich als SW-Fehler vor einigen Moanten "eingeschlichen".

Abhilfe: Entweder: MX31ZL anschließen vor dem Einschalten des Basisgerätes, oder (besser) Update auf die korrigierte Software-Version ab 3.08 (Februar 2009).

Mit bestimmten Motoren (typ. Fleischmann) treten mit neueren SW-Versionen (z.B. beim MX640 höher als 4.0) Regelungsfehler auf, meistens bemerkbar durch plötzliches unerwünschtes Beschleunigen ("Bocksprünge").

Betroffen sind nur bestimmte Motortypen, besonders häufig dürften dies Fleischmann-Motor sein. Auch Faulhaber-Motore könnten gelegentlich betroffen sein.

Abhilfe: Update auf die korrigierte Software-Version (ab ca. 28. Jan. 2009)

MX620, MX64D:  9.10
MX69, MX690: 20.16
MX640:   4.16