THEMA: Zimo MXULFA Probleme

Hallo,

ich denke Du solltest unbedingt ZUERST die Firmware des MXULFA aktualisieren.

Wurde der Stick evtl. einmal mit Android oder sonstigem Linux gelesen? Zumindest Android schmiert sofort was drauf.

Stick raus, booten lassen. Was passiert - startet es?
Neue MXULFA Firmware auf den Stick, alle anderen Firmware/Sound Files löschen, Stick einstecken. Blinkt die Taste für das Selfupdate?

Grüße, Peter W

Nachtrag - meine bisherigen Probleme:

1. Decoder gleichzeitig mit dem Gleis UND Susi verbinden -> Decoder nicht gefunden, falscher Decodertyp erkannt, Fehler MS Sound auf MX Decoder

2. Sound flashen - abbrechen. Decoder macht komische Geräusche, Wiederholen nicht mehr möglich, nach Neuflashen der  Decoder Firmware wieder OK.

Grüße, Peter W

Moin Peter,

danke für deine Antwort.

Das MXULFA kommt direkt von Zimo. Da sollte die neuste Version drauf sein. War ja länger nicht lieferbar.

Mit nem MAC OS kam der Stick in Kontakt. Aber nur einmal zu beginn. Zwischendurch nicht mehr.


Ohne USB Stick erscheint „Booting -> USB-Stick?“

Ich habe jetzt nur die MXULFA Firmware auf den USB Stick geladen und dann hat das MXULFA wieder mit mir geredet.
Ein erster Versuch ein Soundprojekt zu laden ist wieder bei „startet“ gescheitert und der 2. Versuch hängt jetzt wieder bei 0%.
3. Versuch wieder beim „startet“ gescheitert
4. Versuch hat es zumindest schon wieder bis 0% geschafft

Selbst Update konnte ich übrigens nicht ausführen. Die Led blinkt abwechselnd rot und grün


Das Scrollrad funktioniert auch nur so teilweise. Soll das so oder habe ich da einfach Pech gehabt?

Hallo,

ich hatte vor einigen Tagen ein ähnliches Problem beim SUSI Soundladen mit MXULFA. Ich hatte versucht ein coded Projekt von Alexander Mayer zu laden.
Decoder war bzw ist ein MS490 mit FW 4.225 (die aktuellste) und MXULFA auf 0.84.35 (die aktuellste).

Das Problem war das gleiche, die Statusanzeige beim SUSI Soundladen stand auf 0% und es änderte sich nichts.
(Das Laden über die Schiene lief zwar durch, aber der Decoder war hinterher leer... )
Ich habe dann den Decoder auf die FW 4.217 zurückgeflasht und kommte ein freies Soundprojekt wieder laden.
Nachdem erfolgreichen laden des freien Projekts habe ich den Ladecode erneut eingegeben und konnte auch das coded Soundprojekt erfolgreich laden.

Moritz, Nun wäre interessant zu wissen, welche FW dein Decoder hat...

Mfg
Christian W.

Ich hab jetzt auch keinen besseren Tip, als es mehrmals (mit verschiedenen) Projekten zu probieren und ggf. jeweils die Firmwares nochmal draufbügeln. Nach Möglichkeit verschiedene Ladevarianten (PC, Stick, Susi,...) ausprobieren. Ggf. einen anderen USB-Stick (in der Anleitung steht, wie der vorbereitet sein muss).

Bei meinem MXULFA funktioniert das Laden vom Stick über die Schiene zumindest RELATIV zuverlässig. Gibt aber einiges, das nicht oder nur sehr unzuverlässig funktioniert:
- Verbindung mit PC sehr unzuverlässig (CV lesen geht nicht, Projekt Laden geht nicht, Steuern geht manchmal, CV schreiben geht manchmal) Ich hab auch schon verschiedene USB-Kabel ausprobiert. Mit 2 von 3 geht es garnicht.
- Laden von USB-Stick über Susi (ESU Decoder Tester und Next18 -->MS590N18 oder MX658N18) geht nicht (Schiene ist natürlich abgesteckt und der Tester auf Susi statt Funktionsausgänge umgeschaltet).
- Ich habe kürzlich drei MS590N18 gekauft. Das Bespielen mit Projekten war bei 2 davon ein riesen Drama: das Bespielen lief laut Anzeige normal, aber im Ergebnis blieben die Decoder weitgehend stumm, es sind aber Sound-Reste vom originalen Mehrfach-Projekt drauf geblieben, wo man mit gewissen Kombinationen von CVs und Funktionstasten den Fahrsound ansteuern konnte. Letztlich habe ich jeden Decoder etwa ein dutzend Mal, auch mit dem originalen Projekt (über die Schiene: ca. 45minuten!) bespielen müssen, bis es endlich sauber funktioniert hat! Ich wollte die Decoder eigentlich schon zurückschicken. Aber ich wollte für eine genaue Fehlerbeschreibung das ursprüngliche Verhalten nochmal nachstellen (originales Projekt nochmal drauf und dann Zielprojekt). Dann ging es plötzlich bei einem. Dann habe ich beim anderen auch noch ein paar Mal probiert, bis tatsächlich ein Projekt funktioniert hat.

Insgesamt ist das Ding bis dato leider eine teure Enttäuschung. Die Probiererei hat mich ewig viel Zeit und Nerven gekostet und die zwei wichtigsten Dinge, weshalb ich das Teil gekauft habe (CV Listen mit ZCS/PC verwalten und schnell über SUSI laden) sind aktuell hinfällig. Das notwendige USB-Stick-Gestöpsle ist auch ultra nervig. Wenn ich etwas Zeit habe, muss ich auch mal das Zimo-Forum oder den Support bemühen.

Gruß
Andi

Hallo Andi,

ein Vereinskollege nutzt den MXULFA praktisch nur mit dem PC und das CV-Lesen funktioniert mit seinem Lenovo Laptop immer - zumindest bei MX-Decodern. Loks mit MS haben wir noch nicht.

Der ESU Decodertester belastet Susi zu stark. Leider hat Esu hier keine NMOS sondern einfache NPN verbaut um die LEDs anzusteuern, die Vorwiderstände sind unnötig niedrig und teilweise kuriose Pull-Down-Widerstände verschaltet.
Piko Decoder funktionieren auch nicht mit dem ESU Tester, weder Next18 noch Plux22 wegen der Beschaltung. Deshalb habe ich die Vorwiderstände getauscht, welche an den Susi Pins hängen. Mit einem MS450P22 funktioniert das Susi Laden.

Mit dem umgebauten Esu Tester habe ich das Susi Laden mit einem MS450P22 mit ein paar Projekten ausprobiert (ansonsten habe ich nur den MS500) und das hat bislang funktioniert.

Ad MS590N18: Da hast Du einen Lottovolltreffer gelandet, ich bin eines MS590N18 leider noch nicht habhaft geworden, nicht einmal Onkel Hübsch hat welche.

Grüße, Peter W.

Folks!

- Der Stick muss FAT32 formatiert sein mit Standardeinstellungen von Windows.

- Bei MS-Decodern funktioniert FW-Update und Sound laden nur mit USB-Stick, nicht über PC / USB-Kabel.

- CVs lesen / schreiben funktioniert bei mir ohne Probleme im Servicemode

- bei Coded-Projekten muss der Ladecode zwingend vor dem Laden des Projektes in den Decoder geschrieben werden.

- Sollte das Laden der Firmware oder eines Soundprojektes über die Tasten T1, T2 fehlschlagen, alternativen Weg über Taste R und Menu versuchen!

- Manchmal hilft auch, die Lok auf dem Programmiergleis umzudrehen, warum weiß ich nicht.

Beste Grüße

Boris

Guten Morgen,

ich habe meine MXULFA jetzt seit 3 Jahren erfolgreich in Betrieb.
Immer auf dem neuesten Hardware-Level - mit Ausnahme der 4.225, da es da, wie Zimo schreibt, Probleme beim Down-Grating geben kann.

Wenn es Probleme gab, und die gab es gelegentlich, lag es immer am USB-Stick!!
Den Zimo-USB-Stick, der mit der MXULFA ausgeliefert wird, habe ich längst an die  Hasen verfüttert.

Ansonsten kann ich nur die Ausführungen von Boris bestätigen.

Einen schönen Tag noch und viel Erfolg!

VG Dieter

PS: Ich lade meine Sound-Projekte grundsätzlich mittels USB-Stick.
Am PC bearbeite ich mit ZCS lediglich die Projekte.

Moin,


Doch, das geht schon...
Wichtig ist nur, nach dem Down-Grating ein freies Projekt zu laden. Direkt nach dem Down Grating konnte ich keine CVs ändern und somit keinen Ladecode für ein coded Projekt eingeben.

Mfg
Christian W.

Hallo Christian W,



Ah ja. Danke für den Hinweis.

VG Dieter

https://dictionary.cambridge.org/de/worterbuch/englisch/grate

Amüsierte Grüße,
Harald.

Folks!

Ein Downgrading bei Firmware für Decoder musste bzw. wollte ich noch nie machen, bei MS-Decodern schon 3x nicht. Wozu?

Noch ein Tipp für MS-Decoder, insbes. MS500, den ich vom Support von Zimo erhalten habe:



Bei MS-Decodern ist manchmal auch folgende Vorgehensweise notwendig (warum weiß ich nicht):



Nach dem Update der Firmware oder dem Laden eines Soundprojektes sollte man übrigens immer die R-Taste drücken, wenn im Display das Ende des Vorgangs angezeigt wird (CV 29 und 144 erfolgreich zurückgeschrieben).

Beste Grüße

Boris

Nachtrag: das Problem mit dem Scrollrad, das weiter oben beschrieben wurde, hatte ich auch schon, wurde von Zimo sehr kulant repariert. In diesem Zusammenhang bekam ich einen Tipp zum Selbsttest des MXULFA:
:

Das klingt plausibel und interessant. Muss ich mir mal ansehen. Hast du da genau Werte/Infos, welche Widerstände das sind?

Auch mit MX-Decoder funktioniert Sound Laden vom PC nicht. Beim CV lesen zuckt der Motor noch. Es kommt aber keine Info beim PC an und die Kommunikation danach ist tot. Man muss den MXULFA neu starten (vom Strom trennen)

Bei Fischer-Modell waren vor ein paar Wochen mehr als ein Dutzend lieferbar. Sind einfach so im Shop aufgetaucht... Vor dem Chipmangel dieses Jahr konnte ich auch bereits einen ergattern. Heißt ich habe jetzt vier. Sind in Liliput-Loks gelandet. Aber wie gesagt: zwei davon haben ziemlich gezickt... Ich hab dafür noch keinen STACO in der Hand gehabt. Soll jetzt Mitte/Ende November die neuen geben...

Gruß
Andi

Reden wir vom Service-Mode oder On-the-Main?

USB-Kabel hast Du schon mal getauscht?

Welche FW-Version wird nach dem Anstecken an Strom am Display angezeigt?

Gelegentlich hatte ich auch Probleme mit MX-Decodern, wenn am MXULFA die aktuellste Firmware geladen war. Wenn dieses Problem auftritt, mache ich am MXULFA ausnahmsweise ein Downgrade auf FW 0.72.6, mit der flutscht dann alles mit MX-Decodern.

Sound laden vom PC dauert sowieso länger als vom Stick, funktioniert aber bei MX-Decodern zumindest mit 0.72.6

Beste Grüße

Boris

Hallo.



Hast du das auch mit einer aktuellen MXULFA- und ZCS-Software probiert? Die Verbindung zum PC wurde vor wenigen Monaten verbessert (vor allem was ZCS betrifft).



Über den PC und das USB-Kabel funktioniert mit dem MXULFA das SUSI-Soundladen auch mit MS-Decodern. Nur Soundladen über Schiene funktioniert noch nicht bei den MS-Decodern.



Vorsicht! Unter die SW-Version 0.84.30 darf man nur MXULFA mit der Hardwarerevision E oder älter downdaten. Bei der neuen Hardwarerevision F vom MXULFA, die seit ein paar Monaten verfügbar ist, darf man nicht drunter gehen, da diese erst ab SW-Version 0.84.xx unterstützt werden.

LG
Markus

Hallo,

.
Wie lädt man dann den Sound in den MS500?

Grüße, Peter W

Hallo Peter.


Das bezog sich auf das Soundladen über den PC mit USB-Kabel. Über USB-Stick funktioniert es natürlich.

LG
Markus

Hallo,

Danke und aber so ganz verstehe ich es nicht warum A+A geht und A+B nicht - wenn man eine Implementierung macht für die Laderoutine, sollte es dann nicht egal sein von welchem Interface die Binärdaten kommen?

Grüße, Peter W

Nein, weil die PC-Schnittstelle anders ist als die USB-Stick-Schnittstelle. Fürs Soundladen über die Schiene für die MS-Decoder wurde damals ein neues schnelleres Protokoll entwickelt, welches bis jetzt nur für die USB-Stick-Schnittstelle implementiert wurde.

LG
Markus

Hallo Peter!

USB-Stick und USB-Verbindung zwischen Notebook und Zentrale ist leider nicht dasselbe. Das erkennst Du schon daran, dass ein Stick als Laufwerk wie eine CD oder HDD unter Windows / LINUX / ... angesprochen wird, für die über USB verbundene Zentrale aber mindestens ein COM-Port (=serieller Port) verwendet wird. Schon deswegen erfolgt die Übertragung Stick <-> Gerät anders als PC <-> Gerät. Den Rest hat Markus bereits erklärt.

Beste Grüße

Boris

Hallo,

ob die Binärdaten vom File Reader oder vom seriellen USB Datenstrom stammen, kann den Routinen, die das blockweise aufs Gleis oder Susi hinaus serialisieren völlig egal sein. Und wenn man das historisch so nicht vorliegen hat, muss man es tunlichst refaktorieren, sonst wird das ganz schnell unwartbar.

Grüße, Peter W

Soft- und Firmwares sind alle aktuell bzw. von letzter Woche.


- Service Mode
- Ich hab bis jetzt drei unterschiedliche Kabel ausprobiert. 2 gingen garnicht obwohl es echte Daten-und keine "Lade"-Kabel sind. Ich hab gerade noch zwei weitere gefunden. Wenn ich wieder etwas Zeit habe, werde ich weiter Testen. Ich hab auch das Gefühl, dass die Verbindung besonders zickt, wenn gleichzeitig andere Peripherie angeschlossen ist.
- 0.84.35

Gruß
Andi

Hallo Peter!

Ich denke, es geht nicht um die Routine des Schreibens der Daten auf den Decoder, sondern um die Routine des Empfangens der Daten von Notebook / PC und sendens von Empfangsbestätigungen, damit Software am PC / Notebook weiß, das Daten vom MXULFA verstanden wurden. Dieser Vorgang unterscheidet sich vom Lesezugriff auf den USB-Stick. Es sind ja beim MXULFA auch 2 verschiedene Steckplätze für Kabel und Stick.

Anders formuliert: am USB-Stick liegen die Daten z.B. blockweise vor und die FW des MXULFA kann sie blockweise lesen. Die Daten über Kabel kommen seriell über Kabel, die FW muss sie erst wieder korrekt zu Blöcken zusammensetzen, allfällige Übertragungsfehler erkennen und neue Übermittlung anfordern, .. und genau dieser Vorgang scheint noch nicht vollständig implementiert.

Beste Grüße

Boris

Ich würde Zimo mal nahelegen sich entweder jemand zu beschaffen der das mit der Software kann oder die Protokolle so offenzulegen dass jemand anderes, der das mit der Software kann sich der Sache annehmen kann. Nach dem was ich hier lese ist das MXULFA als Produkt eigentlich so wie es ist unhaltbar und beschmutzt den Ruf anderer gut gemachter Produkte die ja funtktionieren. (Ich gehöre ja auch zu denen die seit Jahren am liebsten die MX Decider verwenden und beim Kundenservice hatte ich ja auch noch nix zum Meckern).


Wenn der Bufferspace groß genug ist oder das Timing passt, hast du recht.

Grüße,
Harald.

Hallo Harald!

Einspruch Euer Ehren! Ich besitze das MXULFA seit vielen Jahren. Solange Zimo nur MX-Decoder produzierte, war alles paletti und das MXULFA hat super funktioniert.

Jetzt kamen zu den MX-Decodern die neue Generation MS-Decoder dazu mit neuer Architektur der Decoder, ... Soundfiles sind jetzt bis zu 4x größer als für MX-Decoder, ... und das MXULFA bedient beide Decoder-Familien weiter. Dass es da mal hin und wieder zu Problemchen kommen kann ist verständlich und Zimo ist sehr dahinter alle auftretenden Bugs zeitnah zu beheben und die Performance zu verbessern.

Fakt ist: bei vielen Kollegen und bei mir funktionieren
- Aktualisierung der Firmware von MX- und MS-Decodern über USB-Stick und Schiene oder SUSI und
- Soundladen auf MX- und MS-Decoder über USB-Stick und Schiene oder SUSI
tadellos.

Dass Update der Firmware und Soundladen vom PC über Kabel auf MS-Decoder problematisch ist, ist zu verschmerzen, zumal der Umweg über den Stick kürzere Ladezeiten mit sich bringt.

Die geschilderten Probleme von Andi sind entweder auf einen Hardwaredefekt des Gerätes von Andi zurückzuführen (sowas soll bei elektronischen Geräten schon mal vorkommen) oder die Schnittstelle (COM) ist in Windows nicht korrekt konfiguriert. Da kann dann Zimo nichts dafür.

Übrigens: der Support von Zimo ist der allerbeste, den ich je kennengelernt habe. Wenn alle Tipps hier nicht helfen, kann man sich jederzeit direkt an den Support wenden, da werden Sie geholfen!

Beste Grüße

Boris

Kannst du ja meinen, aber wenn der Support folgende Tips gibt:



dann zeigt das deutlich dass die Software Fehler hat (die könnte das ja auch tun wenn es der MS500 braucht) und als Kompensation muss der Anwerder dann rumrödeln weil es die Software nicht macht. Auch Verhalten wie "Gerät hängt bis hartem Reset" sind Softwarefehler. Hab selber auch schon solche gebaut.



Am anderen Ende hängt der Device Driver (COM/Serial) da drann dann ZSP (auch von Zimo), oder? Device driver Fehler im COM Driver von Windows würde ich als "selten" einstufen.

Grüße,
Harald.

Hallo,

genauso wie Boris das beschreibt ....... so isses! (bei mir)



  .... da von mir eh nicht durchgeführt  und der Umweg über den Stick eh die kürzere Ladezeiten mit sich bringt.

VG Dieter

Folks!

Zimo hat ein Update der Firmware für MXULFA veröffentlicht: http://www.zimo.at/web2010/support/UpdateMXULF.htm

Beste Grüße

Boris