Digital neuer Programmer "Zimo-KLUG"

[tokaalex]

Gut dann eben nicht mit Susi sondern auf der Platine mit der Gleisfunktion

Ein Firmware-Update wird ausschließlich über Schiene gemacht, völlig egal ob MX oder MS!

Aber plötzlich gibt es einen knall und eine Stichflamme

Da war mit ziemlicher Sicherheit SUSI- UND Gleisanschluss gleichzeitig am MXULF angeschlossen, was einen Kurzschluss erzeugt und zumindest den Decoder (wenn man schnell genug ist) oder eben auch den Tester dazu hochjubelt... hab ich auch schon mal vergessen zu kontrollieren. Passiert. 🤷‍♂️

ist das so ähnlich mit einem MS auch nochmal passiert,

... was zwei völlig verschiedene Dinge sind, weil bei den MS581ern ein falsches Bauteil montiert wurde und es dadurch unter gewissen Konstellationen (Aktivierung der Zugnummernimpulse) zu starker Wärmeentwicklung kam/kommt.
... hat aus meiner Sicht überhaupt nüscht mit "menschlichem Versagen" des Anwenders beim versuchten Firmware-Update eines Decoders via SUSI oder aber dem parallelen/gleichzeitigen Anschluss von SUSI und Gleis am MXULF zu tun.

Zimo offerierte mir, das sowas schon mal passieren kann.

Na das Geschriebene würde mich ja brennend interessieren... 👀

ob der neue Programmer die ganzen hier angesprochen Problem in Zukunft nicht hat.

Was soll da anders werden? Die Hardware und deren Asnchlussmöglichkeit wurde für bestimmte Voraussetzungen geändert und angepasst/erneuert, deswegen bleibt das Arbeitsprinzip beim Aufspielen von Firmware oder Soundprojekten identisch zum MXULF... 🤷‍♂️


Übrigens ist es durchaus möglich, dass es neben einem fehlerhaften/deffekten Bauteil auf einem Deoder auch Softwarefehler gibt, was wiederum die verschiedensten Auswirkungen haben kann:
- beim Aufspielen des Firmware-Updates kommt es zu Übertragungsfehlern durch Bauteildefekt-> nächstes Firmware-Update funktioniert nicht mehr (kann nur ZIMO selbst beheben)
- Decoder bleibt nach dem Soundaufspielen im Update-Modus hängen und nix geht mehr -> kann der User selbst beheben und klappt fast immer, sofern kein Bauteil beschädigt ist
- Soundendstufe defekt -> Decoder "fährt" und Sound wurde normal auf den Decoder aufgespielt, aber aus dem LS kommt nur ein leises Blubbern -> kann nur ZIMO beheben
- Motorendstufe defekt -> kann nur ZIMO beheben
- Sound lässt sich bei MS-Decodern nicht via SUSI und nur über Gleis aufspielen -> fehlerhaftes Bauteil und kann nur durch ZIMO behoben werden, falls SUSI unbedingt gewünscht ist

 

[Zilli]

Ob es, wie dargelegt wurde am USB Kabel nur alleine hängt, kann ich nicht beurteilen,

Die Spezifikation des USB-Kabel hat mit MXUlfA überhaupt nichts zu tun, da geht es rein um den Programmer "KLUG".

Ansonsten fände ich es ja ganz nett, wenn die Diskussion über MXUlfA dort geführt wird wo diese hingehört - hier geht um den Programmer "KLUG", vielen Dank.

Ich hatte nun gestern ein Kabel besorgt mit Vollbelegung, USB-C 4.
Erster Versuch Sound auf zu spielen ging dann trotzdem wieder schief, Fehler "keine Antwort - Abbruch".

Betriebsblind wie man manchmal ist habe ich erst beim Betrachten des Screenshot bemerkt, Firmware 5.5 - mal schauen was mit neuerer Firmware passiert.
Also Dekoder-Update auf 5.15 und schon funktionierte alles wie es sein soll, mit Programm ZPP.

In ZCS lässt sich der "KLUG" zwar verbinden, zeigt im Log-Fenster die Hardware auch richtig an, aber eine auslesen/schreiben von CV endet immer mit Fehler, Programmer hängt sich auf (violette LED-Anzeige, dauerhaft blinkend).

Die Voraussetzungen für den neuen Programmer sind also schon mal recht hoch gesteckt:
- Rechner mit aktuellem BS und USB-C Anschluss mit mind. Spezifikation USB 3.1 (keine Ahnung ob ältere BS USB C 3.x und/oder höher unterstützen)
- USB-C-Kabel mit ebenfalls mind. Spezifikation USB 3.1
- Vor dem einspielen von Sound (habe nur per Susi getestet, per Gleis weiß ich nicht) muss der MS-Dekoder Firmware-Version mind. 5.15 aufgespielt bekommen

 

[Warcry2000]

@Zilli - das Firmware Update von 5.5 auf 5.15 ging mit dem KLUG ?

 

[Zilli]

Ja, funktionierte mit ZPP

 

[Warcry2000]

OK, danke.