1zu160 - Forum



Anzeige:
Arnolds Modell Web

THEMA: Zimo MS/MN Probleme - Teil 3

THEMA: Zimo MS/MN Probleme - Teil 3
Startbeitrag
B160 - 22.02.24 00:34
Hallo!

Da Teil 2 ( https://www.1zu160.net/scripte/forum/forum_show.php?id=1376208 )  schon wieder voll ist, eröffne ich mal Teil 3.

Peter W. schrieb zuletzt:
Zitat

Hallo,

bitte bei MS Decodern Next18 und MS Lokplatinen, die für Spur N Fahrzeuge konstruiert werden, ab Werk CV 12 auf 5 festlegen.

Der Werkswert 53 führt zu Fehlfunktionen bei Störungen am Gleis. AC Analog und MM Erkennung in Betrieb zu haben macht keinen Sinn in Spur N, diese Betriebsarten kommen nicht vor.

Grüße, Peter W



Dem möchte ich noch hinzufügen: wer Analogbetrieb nicht benötigt, deaktiviere in CV 12 zusätzlich Bit 0 (somit korrekter Wert 4) und in CV 29 Bit 2.

Beste Grüße

Boris

Hallo,

laut DCC Norm sollte das Deaktivieren von CV29.2 die ganze Power Conversion außer Kraft setzen und somit CV12 unwirksam werden - es sollte dann nur DCC Betrieb funktionieren. Wer weiß wie das implementiert ist?

Grüße, Peter W.
Für den Analogbetrieb müssen beide CVs entsprechend gesetzt sein, sprich CV12 und CV29.
Hallo,

zusammenfassend aus dem hier im Forum geschilderten Problem mit der FL 211 (mit MS Sound) plus MTX MDyg (mit T66857) besteht der Verdacht, dass die AC Anlogerkennung bei verminderter DCC Signalqualität zu unkontrollierbarer Schleichfahrt führt - kann es sein dass sich der Decoder die letzte Betriebsart auch eine Zeit lang merkt, so dass POR (Gleisspannung aus/ein) da nicht sofort hilft, CV8-Reset aber schon?

Grüße, Peter W.
Halt ich für eher unwahrscheinlich. Ein CV8 Reset hat auch keine Auswirkungen auf den zuletzt gespeicherten Modus.
Hallo zusammen

das hatte ich bei MS500 auch schon
daß Loks in der Abstellposition plötzlich loslaufen
nach Deaktivierung der Analog-Erkennung war das dann erledigt.

mke
Teil 2, #77:
Zitat - Antwort-Nr.: | Name: Uli_22

Die neue Doku für MS Decoder ist jetzt online.



Teil 2, #80:
Zitat - Antwort-Nr.: | Name: Vincent Hamp

Es gibt auch in der Anleitung einen CHANGELOG:
2024 02 02    MS540E24, MN140E24, LOKPL950K, Kap. 11 CV #30 Fehler Auslesen, CV #394:5 Dampfschläge überblenden; Div



Beim Update der deutschen Version scheint etwas schief gegangen zu sein.
* In der CV Übersicht ist bei allen CVs ab #186 die Beschreibung falsch, und steht jeweils eine Zeile weiter unten. Da ist wohl in der Tabelle etwas verrutscht.
* Die „Märklin-Bremsstrecke“ hat keine eigene Überschrift mehr, dadurch passen Verweise auf Kapiteln ab 3.11 nicht mehr da alle Kapitel eine andere Nummer erhalten haben.
* Auf Seite 66 überdeckt die Grafik den kompletten Text.

Die englische Version scheint allgemein in einem besseren und aktuellen Zustand zu sein und enthält diese Fehler nicht.
Danke, hab das weitergeleitet und es wurde bereits behoben. Hoffe die Version auf der Homepage wird bald geupdated.
Zitat - Antwort-Nr.: 7 | Name: Vincent Hamp

Danke, hab das weitergeleitet und es wurde bereits behoben. Hoffe die Version auf der Homepage wird bald geupdated.


Super danke, das ging ja flott. Beim kurzen drüber schauen sieht wieder alles gut aus.
Bei CV #830 bis #837 ist die Beschreibung allerdings noch teilweise fehlerhaft.
Hallo,

Bei CV #837 wurde die Beschreibung inzwischen korrigiert, allerdings ist CV #831 bis #836 in der deutschen Anleitung noch fehlerhaft.

Liebe Grüße
Stefan

Hallo

Ja Danke, wir fixen das in Kürze.
Guten Tag,
Ich habe ein MN180N18 gekauft um meine Arnold Aln668 (HN2572) zu digitalisieren.
Ich habe aber ein Problem mit die Lichte und AUX Ausgänge.
Ich kann nur die vordere und hintere Weisse (F0v und F0r) und Rote (AUX1 und AUX2) einschalten. Fehlen noch die dritte Weisse Licht (vorne und hinter, AUX 3 und AUX4) und die innenbeleuchtung.
Ich habe SUSI schon deaktiviert und ein bisschen damit bespielt, aber ohne erfolg. Kann jemand mir eine Empfehlung geben? Kann es sein, dass ein NEXT18 decoder nur insgesamt 4 Ausgänge hat?

Danke im voraus
Liebe Grüße
Roberto
Hallo Roberto,

das Problem, welches es leider beim Arnold ALN 668 gibt, wurde hier schon geklärt:
https://www.1zu160.net/scripte/forum/forum_show.php?id=1386108

Leider müssen auf der Hauptplatine drei Widerstände getauscht werden, da dort die Ansteuerung der SUSI-Pins nicht nach Norm ist.

LG
Markus
Hallo Markus,
Vielen Dank für die Antwort! Ich schaue sofort nach.
Ob das Problem nur drei Widerstände sind, ich kann die einfach tauschen.

Danke noch Mal

Liebe Grüße

Roberto
Ich habe über ein halbes Jahr mit Soundumbauten pausiert. Jetzt hab ich wieder angefangen und es geht gleich wieder mit Ärger bei die Kombination MXULF/MS-Decoder los. Eigentlich wollte ich nur einen verbauten MS491 updaten und mit Sound bespielen. Es hängen auch 880µF direkt am Decoder aber das war bisher nie ein Problem und Surprise: eine andere Lok ohne Puffer funktioniert auch nicht (siehe unten). Das MXULF ist auf dem aktuellen Stand (84 58). Über den PC geht es ja sowieso nicht, also vom USB-Stick (die Stopselei jedes mal ist fast nicht umständlich). Die Lok zappelt fröhlich hin und her, als das MXULF versucht die CVs 29 und 144 auszulesen. Nach dem Gezappel bricht es ab mit "Decoder nicht gefunden". Offensichtlich konnten die CVs nicht ausgelesen werden. Eine Glühlampe und Widerstände parallel zum Gleis (ich hab 100 bis 1000 Ohm probiert) brachten keine Besserung. Übrigens kann ich diese Lok auch nicht mit meinem D&H Programmer auslesen. POM geht einwandfrei, die Stromabnahme ist hervorragend und auch sonst funktioniert alles. Zerlegen ist übrigens keine Option. Wir sprechen von einer Spur Z Lok und es war eine *** Arbeit das Ding unterzukriegen. Ich hab dann einfach mal zwei andere Loks (2 und 3) aus meinem Fuhrpark mit MS-Decodern probiert. Alle Loks fahren einwandfrei. Hier eine Liste was geht und was nicht:

Lok1 (Z-Lok-Umbau; GAM 0615S; MS491; 880µF am Decoder) --> CV auslesen an D&H Programmer geht nicht, Update MXULF geht nicht
Lok2 (Lilliput 56; MS590N18) --> CV auslesen an D&H Programmer geht, Update MXULF geht nicht (in Lok; auch nicht mit Widerstand am Gleis). Stecke ich den Decoder in den ESU-Decodertester geht's
Lok3 (Lilliput E44; MS590N18) --> CV auslesen an D&H Programmer geht, Update MXULF geht.

Wie man an der sieht, funktioniert es prinzipell. Vermutlich ist der Strom vom Motor zu gering (die betroffenen Modelle haben beide GAMs). Mich wundert es aber, warum das mit dem Widerstand dann nicht funktioniert.

Wie bekomme ich jetzt das Update und das Soundfile auf den Decoder? Wie gesagt ist Ausbauen keine Option. Das Problem ist offensichtlich, dass die CVs nicht gelesen werden können. Es gab doch eine Möglichkeit, die ACK-Impulse vom Decoder ohne Motor erzeugen zu lassen? Ich habe dazu aber leider keine passende CV in der Dokumentation gefunden. Kann man alternativ die CV-Abfrage beim Update und Sound aufspielen umgehen?

PS: Allein am Motor kann es übrigens auch nicht liegen. Ich habe schon einige Loks mit GAM in verschiedenen Größen und D&H-Decoder ausgerüstet. Da gab's beim CV-Auslesen, Programmieren und Updates nie ein Thema.

Gruß
Andi
Zitat - Antwort-Nr.: | Name:

warum das mit dem Widerstand dann nicht funktioniert.


Weil davon der Quittungsimpuls (Stromdifferenz) auch nicht größer wird.

Abhlfe könnten die Hochstrom-Hochfrequenz Impulse bringen, ich weiß aber nicht ob MS das können.

Firmware Updaten kannst Du blind, aber nur am PC glaube ich. Beim Sound flashen gibt es doch die Option ohne CV29+144, oder irre ich jetzt gerade?

Grüße, Peter W.
Hallo Andi!

Bei mir hat bei MS-Decodern sowohl zum Updaten als auch zum Laden des Soundprojektes folgende Vorgangsweise geholfen:

1.) *.zsu und *.zpp-File auf den Stick
2.) Stick in MXULFA einstecken - MXULFA ist bereits mit Strom verbunden
3.) Taste P am MXULFA - das ist die Taste vorne links neben Scrollrad - LANGE drücken bis im Display das Menü erscheint
4.) Scrollen bis Update und Sound ohne CSV 29 und 144, mit Taste P bestätigen
5.) Datei auswählen durch scrollen
6.) Taste P bestätigen -> Warten
7.) wenn Display 100% anzeigt, nochmal Taste P drücken

Nach dem Update empfiehlt Zimo, die Lok bei eingeschalteter Zentrale auf die Anlage zu stellen, ohne Fahrbefehle etc. zu senden so für 10-30 Sekunden.

Wenn das nicht funktioniert, entnehme ich den Stick, verbinde das Gerät mit dem PC, starte ZCS.exe, aktiviere [ONLINE] (unten links) und klicke im aufpoppenden Fahrregler auf [Decoder erkennen]. Wenn das auch fehlschlägt, verschiebe ich die Lok auf dem Programmiergleis, bis die Erkennung klappt.. Danach trenne ich das MXULFA vom Notebook und beginne bei 1.)

Beste Grüße

Boris



Hallo Boris,

Das Vorgehen, nur mit Stick, hat bei den letzten Malen bei mir fast immer geklappt...
Es kommt aber vor, dass man die Lok um 180 Grad drehen muss, oder die Spannungsversorgung am Gleis.
Ich kam schon ins Schwitzen, weil sich die Firmware partout nicht aufspielen liess.

Hallo Andi,

Weder Zimo noch D&H lassen sich mit angeschlossenem Kondensator mit Firmware bzw Sound beschreiben. CV Ändern geht aber.

Das ist auf jeden Fall bei D&H so beschrieben.

Dies hat auch nichts mit dem Hersteller zu tun.

In den Piko Loks, zb. BR101 habe ich mir einen Mikroschalter vor den Kondensator gesetzt, dass ich bei einem eventuellen Update nicht jedesmal die halbe Lok zerlegen muss.

Viele Grüße, Franzi
Hallo Freunde

Wer es noch nicht weiß, es gibt eine neue Firmware v4.250 für die MS/MN Decoder, vom 21.05.2024 !

Zitat - Antwort-Nr.: | Name: ZIMO

Changelog 4.241 ➔ 4.250

WICHTIG:

    Standardkonformität RCN-225
        HLU muss nun explizit via CV #27: 2 aktiviert werden
        DCC-A muss nun explizit via CV #28: 7 aktiviert werden
    Standardkonformität RCN-218
        Die Logon Adresse überschreibt die Decoder Adresse nicht mehr
    Bei MTC21 Decodern (MS440, MN340) wurde FA10 zu FA11

Neu:

    Reduzieren der Beschleunigungs- (CV #3) und Verzögerungszeiten (CV #4) durch CV #390 bei Lokfahrt (CV #348: 1)
    Lokfahrt unterdrückt E-Bremse (CV #348: 5)
    Bestätigungs-Jingle beim CV-Schreiben (CV #144: 4)
    Neue Skriptbefehle:
        Startset-Offset setzen
        Abfrage diverse Dampf-Parameter (Dampfschlag-Intervall, Schläge/Umdrehung, Geschwindigkeitsstufen, Laststufen)
        Motor invertieren
        Lichter invertieren
        Lokrichtung invertieren
        CV schreiben
        CV-Bit setzen
    Neuer Decodertyp: MS540
    Workaround: Nicht-Standard-konformes DCC1-Timing für Lenz LG100 Bremsmodule
    Neue CV #99 zum Deaktivieren von RailCom ID 7-Aussendungen
        Bit 3 deaktiviert Gleisspannung
        Bit 2 deaktiviert Temperatur
        Bit 1 deaktiviert O/W
        Bit 0 deaktiviert Kmh

Bugfixes:

    Setwechsel (CV #346: 0)
    SUSI-Ausgänge während Soundladen aus
    Thyristor-Lautstärke
    Rangier-Taste impliziert Bremsen, sofern Brems-Taste definiert und CV #124: 1 und :0 gesetzt
    Reset-Werte für Geschwindigkeitstabelle CV #67 - #94
    Skripte (Thyristor, E-Motor, Audio-Kanal wird wieder freigegeben)


Gruß Johnny
Zitat - Antwort-Nr.: | Name:

1.) *.zsu und *.zpp-File auf den Stick
2.) Stick in MXULFA einstecken - MXULFA ist bereits mit Strom verbunden
3.) Taste P am MXULFA - das ist die Taste vorne links neben Scrollrad - LANGE drücken bis im Display das Menü erscheint
4.) Scrollen bis Update und Sound ohne CSV 29 und 144, mit Taste P bestätigen
5.) Datei auswählen durch scrollen
6.) Taste P bestätigen -> Warten
7.) wenn Display 100% anzeigt, nochmal Taste P drücken

Das hört sich soweit mal nach einem gute Tip an. Die Taste "P" heißt bei mir "R". Hab wohl ein altes MXULF. Der Rest funktioniert wie beschrieben: Mit dem Update hab ich das jetzt geschafft. Decoder funktioniert einwandfrei und die Version habe ich in CV 65 = 250 auch korrekt ausgelesen. Beim Update passiert folgendes Interessantes: Vor dem eigentlichen Update blinken im Bildschirm unten links eine gute Minute lang verschiedene Decodertypen (MS990, MS950, MS500, MS590,...) gefolgt von einer kleiner werdenden Zahl (3,2,1,0) auf. Ist das nur ein "Countdown" oder gibt es hier die Möglichkeit was auszuwählen? Interessanterweise ist mein Decoder (MS491) bei der Liste nicht dabei. Ich habe einfach garnichts gedrückt und nach einer guten Minute ging das Update los.

Ich werde es jetzt mit dem Soundfile auf die gleiche Weise probieren. Drückt mir die Daumen...

Verständnisfrage: In der Anleitung des MXULF steht, dass die CVs 29 und 144 nur für MX-Decoder ausgelesen und geändert werden müssen, um die Programmiersperre und den Analogmodus zu deaktivieren. Die Programmiersperre ist bei MS-Decodern auf CVs 15 und 16 (und ist bei mir mit 0 und 0 sowieso deaktiviert). Der Analogmodus ist auch deaktiviert (CV29 Bit 2). Selbst wenn es für MS-Decoder garnicht erforderlich ist, müsste doch so alles schick sein?

Gruß
Andi
Hallo.

Zitat - Antwort-Nr.: 14 | Name: DerEine

Vermutlich ist der Strom vom Motor zu gering (die betroffenen Modelle haben beide GAMs). Mich wundert es aber, warum das mit dem Widerstand dann nicht funktioniert.


Der Strom vom Motor war sicher nicht zu gering. Updaten und Soundladen funktioniert auch mit GAMs. Das Problem war wohl, dass die Lok durch das „Zappeln“ beim Auslesen, mal den elektrischen Kontakt zur Schiene verloren hat.

Zitat - Antwort-Nr.: 17 | Name: vbh

Weder Zimo noch D&H lassen sich mit angeschlossenem Kondensator mit Firmware bzw Sound beschreiben. CV Ändern geht aber.


Wenn die Kondensatoren bei MS- und MN-Decodern am Elko Plus Lötpad angeschlossen werden, können sie auch während dem Update und Soundladen am Decoder angeschlossen bleiben.

Zitat - Antwort-Nr.: 19 | Name: DerEine

Die Taste "P" heißt bei mir "R".


Die Taste hieß schon immer R-Taste.

Zitat - Antwort-Nr.: 19 | Name: DerEine

Beim Update passiert folgendes Interessantes: Vor dem eigentlichen Update blinken im Bildschirm unten links eine gute Minute lang verschiedene Decodertypen (MS990, MS950, MS500, MS590,...) gefolgt von einer kleiner werdenden Zahl (3,2,1,0) auf. Ist das nur ein "Countdown" oder gibt es hier die Möglichkeit was auszuwählen?


Das MXULF versucht bei diesen Vorgang den exakten Decodertype zu erkennen. Auswählen kannst du hier nichts. Sobald er diesen Decoder erkannt hat, startet er das Update oder Soundladen. Die 3, 2, 1 oder 0 am Ende sind nur die Subtypen des Decoders, die sich durch andere Bauteile die bestückt wurden unterscheiden, wie z.B. Flash-Speicher von einem anderen Hersteller.

LG
Markus
Danke Markus für die Antwort und Infos!
Zitat - Antwort-Nr.: | Name:

Das Problem war wohl, dass die Lok durch das „Zappeln“ beim Auslesen, mal den elektrischen Kontakt zur Schiene verloren hat.

Sehr unwahrscheinlich. Ich habe es wirklich MEHRMALS probiert und dabei auch die Lok bzw. Tender (mit Stromabnahme) aufs Gleis gedrückt. Ohne Änderung.

Zitat - Antwort-Nr.: | Name:

Wenn die Kondensatoren bei MS- und MN-Decodern am Elko Plus Lötpad angeschlossen werden, können sie auch während dem Update und Soundladen am Decoder angeschlossen bleiben.

Das ist hier der Fall.

Das Soundladen hat übrigens nicht funktioniert und ich habe den gleichen Fehler, den ich schon öfter hatte: Die Lok fährt aber der Sound funktioniert nicht wie er soll. Auf den Funktionstasten sind an verschiedensten Stellen irgendwelche Soundschnipsel verteilt. Teilweise kommt der Sound nur beim Fahren und/oder es gibt irgendwelche andere Effekte (F1-> fährt mit aktiven F1 nicht los und es kommt auch kein Sound. Aktiviert man F1 beim Fahren ertönt ein wiederkehrendes Pumpen (?) Geräusch, das dann auch beim Stehen bleiben. F7-> Genau ein Auspuffschlag; F16-> genau ein anderer Auspuffschlag; usw.....). Bemerkenswert ist, dass wieder CV 265 nicht stimmt. Im Projekt steht da "1" (=Projekt-ID Dampflok?). Im Decoder steht beim Auslesen mit Railcom/POM "0" (=?). Ich kann den Wert auch nicht ändern. Weder mit POM, noch mit direkter CV-Programmierung. Es bleibt einfach 0 drin stehen. Programmiersperre ist natürlich nicht drin. Bei Multi-Projekten kann mit CV265 das Projekt auswählen. Welche Funtkion das bei normalen Einfachprojekten hat, weiß ich nicht. Alle anderen CVs scheinen mit dem Projekt übereinzustimmen. Wie gesagt habe und hatte ich diesen Fehler schon öfter. Auch mit Next18-Decodern direkt am Decodertester (also ohne jegliche Kontaktprobleme!). Es hat dann leider nur mehrmaliges Aufspielen bzw. Zurückspielen des Standard-Projekts geholfen. Bis es irgendwann mal funktioniert hat.

Gruß
Andi
Hallo!

Ich entschuldige mich für die fälschliche Bezeichnung der R-Taste als Taste P. Warum ich mir das nicht merken kann, weiß ich nicht, vermutlich hat mir noch niemand erklären können, wofür das R steht, ich denke bei der Taste an Programmierung / Programmwahl und daher das P. Sorry!

Zitat - Antwort-Nr.: 21 | Name: DerEine

Das Soundladen hat übrigens nicht funktioniert und ich habe den gleichen Fehler, den ich schon öfter hatte: Die Lok fährt aber der Sound funktioniert nicht wie er soll. Auf den Funktionstasten sind an verschiedensten Stellen irgendwelche Soundschnipsel verteilt. Teilweise kommt der Sound nur beim Fahren und/oder es gibt irgendwelche andere Effekte (F1-> fährt mit aktiven F1 nicht los und es kommt auch kein Sound. Aktiviert man F1 beim Fahren ertönt ein wiederkehrendes Pumpen (?) Geräusch, das dann auch beim Stehen bleiben. F7-> Genau ein Auspuffschlag; F16-> genau ein anderer Auspuffschlag; usw.....). Bemerkenswert ist, dass wieder CV 265 nicht stimmt. Im Projekt steht da "1" (=Projekt-ID Dampflok?). Im Decoder steht beim Auslesen mit Railcom/POM "0" (=?). Ich kann den Wert auch nicht ändern. Weder mit POM, noch mit direkter CV-Programmierung. Es bleibt einfach 0 drin stehen. Programmiersperre ist natürlich nicht drin. Bei Multi-Projekten kann mit CV265 das Projekt auswählen. Welche Funtkion das bei normalen Einfachprojekten hat, weiß ich nicht. Alle anderen CVs scheinen mit dem Projekt übereinzustimmen. Wie gesagt habe und hatte ich diesen Fehler schon öfter. Auch mit Next18-Decodern direkt am Decodertester (also ohne jegliche Kontaktprobleme!). Es hat dann leider nur mehrmaliges Aufspielen bzw. Zurückspielen des Standard-Projekts geholfen. Bis es irgendwann mal funktioniert hat.



Das ist mir auch schon passiert, das Soundladen hat ja funktioniert, aber das Soundfile ist wohl korrupt. Vom Support von Zimo habe ich gelernt, dass dies passiert, wenn man ein Projekt mit ZCS bearbeitet und speichert, das mehrere CV-Sets wählbar durch CV 265 enthält. Die Entwickler von ZCS arbeiten an einem Bugfix. Bis auf weiteres sollte man *.zpp-Dateien mit mehreren CV-Sets nur mit dem in ZSP enthaltenen Programm Decoder-Config / Zimo Config bearbeiten und speichern. Seit ich diesen Rat befolge, gab es das Problem bei mir nicht wieder.

Edit: ein weiterer Tipp von Zimo war: CV 265 soll man nur mit der Zentrale auf dem Programmgleis der Anlage und nicht mit Programmern wie MXULF ändern. Warum das so ist, habe ich nicht ganz verstanden, aber auch das hilft.

Schönen Sonntag und beste Grüße

Boris




Zitat - Antwort-Nr.: | Name:

Ich entschuldige mich für die fälschliche Bezeichnung der R-Taste als Taste P

Kein Problem! Hat ja funktioniert...

Zitat - Antwort-Nr.: | Name:

Das ist mir auch schon passiert, das Soundladen hat ja funktioniert, aber das Soundfile ist wohl korrupt. Vom Support von Zimo habe ich gelernt, dass dies passiert, wenn man ein Projekt mit ZCS bearbeitet und speichert, das mehrere CV-Sets wählbar durch CV 265 enthält. Die Entwickler von ZCS arbeiten an einem Bugfix. Bis auf weiteres sollte man *.zpp-Dateien mit mehreren CV-Sets nur mit dem in ZSP enthaltenen Programm Decoder-Config / Zimo Config bearbeiten und speichern. Seit ich diesen Rat befolge, gab es das Problem bei mir nicht wieder.

Edit: ein weiterer Tipp von Zimo war: CV 265 soll man nur mit der Zentrale auf dem Programmgleis der Anlage und nicht mit Programmern wie MXULF ändern. Warum das so ist, habe ich nicht ganz verstanden, aber auch das hilft.

Genau. Im Prinzip hat das Soundladen funktioniert. Aber nur im Prinzip. Die .zpp habe ich tatsächlich bearbeitet. Aber nicht mit ZCS (dem Drittanbieter-Programm) sondern mit "ZPP Config". Dabei habe ich aber nur ein paar Funktionstasten und die Motorregelspannung geändert. Sonst nichts. Das Projekt ist übrigens die S 3/6 und ein "Einzelprojekt". CV265 sollte man also garnicht umschalten müssen/dürfen/brauchen, weil ja nur ein Projekt auf dem Decoder ist.

CV265 schreiben habe ich mit dem D&H Programmer versucht (POM und Direkt CV). Ich habe es jetzt auch nochmal über den Programmierausgang meiner (schwarzen) Z21 versucht. Auch da kann ich weder mit POM noch direkt CV den Wert 1 in CV 265 schreiben. Ein interessantes Detail: Die CV265 mit dem Wert "0" kann von der Z21 meist direkt als CV mit "ACK" ausgelesen werden. Die Adresse (CV1=3) jedoch nicht. Muss ich mal beim D&H Programmer probieren ob es da auch so ist.

Ich werde jetzt dann wieder mehrmals Soundprojekte auf den Decoder schubsen. Ich fang mal mit dem Standardprojekt an. Dauert ja nur eine Stunde - vielleicht funktioniert es dann irgendwann mal.

Gruß
Andi
Hallo Andi!

OK, wenn es kein Projekt mit mehreren CV-Sets ist, kann man das Problem mit ZCS ausschließen, da Du nur mit ZPP-Config / Zimo-Config / Decoder-Config gearbeitet hast, sowieso.

Eine Idee wäre noch: Stick formatieren, ZPP-File neu raufkopieren und Sound neu laden.

Was das Schreiben von CV 265 betrifft, noch eine Info von Zimo: das sit so ähnlich wie mit CV 8=8 (reset), es werden alle CVs neu geschrieben, halt nicht mit Standard-Werten (des Projektes) sondern mit den Werten des gewünschten CV-Sets. CV 265 auslesen bringt aber immer den Wert 0, so wie CV 8 auslesen immer 145 anzeigt. Hier wird mit beiden CVs ein Prozess ausgelöst und das führt auch bei CV 8 mit manchen Zentralen zu Fehlermeldungen, obwohl man in der Folge durch auslesen anderer CVs erkennen kann, dass der Reset sehr wohl funktioniert hat.

Beste Grüße

Boris
In den sehr selten Fällen in denen das Soundprojekt nach dem Laden bei mir nicht richtig funktionierte, hat meistens ein CV8=8 Reset geholfen. Auf diese Weise kann man sich meist sparen das Soundprojekt nochmal in den Sounddecoder zu laden.

Wenn das Soundprojekt nur einen Loktyp hat, ist es normal das in der CV265 der Wert 0 drinnen steht.

LG
Markus
Zitat - Antwort-Nr.: 25 | Name: Hardwaredesigner

Wenn das Soundprojekt nur einen Loktyp hat, ist es normal das in der CV265 der Wert 0 drinnen steht.



Hallo Markus!

Das ist ja klar!

Aber ich denke jetzt z.B. an die 2043 von JC, bei der über CV 265=101 oder 103 der Loktyp (Luftdruck- oder E-Starter) ausgewählt werden kann. Auch hier wird nach der Auswahl des gewünschten Wertes 0 angezeigt, wenn man den Wert nach der Programmierung wieder ausliest.

Beste Grüße

Boris
Also im Projekt steht für die CV265 der Wert 1. Was auch immer das bedeuten mag. Beim Auslesen kommt tatsächlich stets "0" zurück. Das habe ich ausprobiert, als ich kurz mal das Standard-Projekt drauf hatte (siehe unten). Mir ist halt aufgefallen, dass im Projekt was anders steht, als ich ausgelesen habe. Aber wenn man stets "0" ausliest, dann würde auch das den Unterschied erklären.

Folgendes habe ich jetzt probiert (hatte grad nicht viel Zeit und anderes zu tun...):
- Zurücksetzen mit CV8=8 --> keine Änderung
- Aufpielen des Standard-Projektes (ohne CVs 29 und 144)--> Das Standard-Projekt funktioniert einwandfrei.
- Aufspielen des gewünschten Projekts (ohne CVs 29 und 144) --> exakt das gleiche Fehlerbild wie oben.
- Jetzt ist was interessantes passiert: ich bin zu kurz auf der R-Taste geblieben und dann wird der Fahr-Modus gestartet. Dafür werden Fahr-CVs ausgelesen. Diese wurden alle EINWANDFREI ausgelesen, die Lok fuhr aber nicht, weil das MXULF den Fahrsound anmacht (F1) die Lok aber mit aktivierten F1 mit dem Fehler nicht losfährt (siehe oben). Nach dem Zurücksetzen des MXULF ging am Decoder plötzlich garnichts mehr. Kein Fahren, kein Sound, kein Programmieren. Beim Versuch des CV-Auslesen haben nur die Frontlichter geleuchtet. Egal ob MXULF oder D&H Programmer.
- Decoderupdate auf den aktuellen Softwarestand 4.250 (ohne CVs 29 und 144) --> hat funktioniert. Decoder läuft wieder so wie davor (mit Fehler)
- Dann habe ich gleich probiert, nochmal das Projekt aufzuspielen, diesmal MIT CVs 29 und 144 auslesen. Und es hat auf Anhieb gestartet! Das Ergebnis ist aber leider das gleiche: Sound-Mischmasch (Fahrmodus mit CVs Auslesen hat wieder einwandfrei funktioniert!)

- Jetzt probiere ich gerade, das Projekt im nicht-modifizierten, originalen Zustand aufzuspielen. Diesmal hat das mit den CVs 29 und 144 wieder nicht geklappt. Also hab ich ohne gestartet. Das Aufspielen läuft gerade...

Gruß
Andi
Hallo,

Den Effekt hatte ich auch schon bei einem Plux22 Decoder. Das ganze MS System scheint mir etwas mit der heißen Nadel gestrickt zu sein. Seit Monaten habe ich mich nicht mehr mit Zimo Sound beschäftigt. Ununterbrochen gibt es Updates, das schaffe ich zeitlich nicht. Aktuell kaufe ich die Loks auch wieder analog wenn geht.

Grüße, Peter W.


Hallo Andi!

Welche Version hat Dein ZPP-Config (steht in der Titelleiste nach dem Start)? Aktuell ist 1.22.00.

Beste Grüße

Boris


Grüß euch

Wir werden die Anleitung rund um CV265 mal überarbeiten, mir scheint da besteht aktuell großer Aufholbedarf unsererseits. Prinzipiell wurde die CV265 wie oben bereits erwähnt von der Logik her an die CV8 angepasst. Wir werden das intern noch diskutieren wie wir das künftig genau beschreiben, grundsätzlich wäre ich aber dafür dass wir von der Beschreibung "Auswahl des Loktyps" wegkommen.

Die CV265 wird nämlich mittlerweile sowohl bei MS- als auch bei MN-Decodern dazu genutzt ein "CV-Set" zu aktivieren und das muss nicht zwangsweise etwas mit einem Loktyp oder Sound zu tun haben. Ein CV-Set aktivieren heißt lediglich dass ein paar CVs die im Projekt unter einer "Setnummer" hinterlegt wurden auf die entsprechenden Werte gesetzt werden. Das könnte dann zum Beispiel auch ein Function Mapping sein, oder Motor-Einstellungen, usw. usf.

Der Unterschied zur CV8 besteht darin, dass die restlichen CVs des Decoders nicht geändert werden, sondern wirklich nur jene die im Set definiert wurden!

Das zuletzt aktivierte CV-Set (CV265=X) kann via CV259 wieder gelesen werden.


Bezüglich konstant eingeschaltetem Vorder- und Rücklicht nach dem Versuch ein .zpp zu laden:
Wenn der Decoder nach einem .zpp Ladevorgang beim Booten Vorder- und Rücklicht einschaltet, dann ist beim Ladevorgang etwas schief gegangen und das Soundflash des Decoders muss wieder gelöscht werden. Das kann bis zu ~50s Dauern. Danach sollte der Decoder (ohne Sound) wieder ganz normal reagieren.
Hallo Vincent!

Danke für Deine Ausführungen, die meine obigen bestätigen. Dass man den Loktyp mit CV 259 auslesen kann, ist mir neu, danke für diese wertvolle Info!

Zitat - Antwort-Nr.: 30 | Name: Vincent_Hamp

Bezüglich konstant eingeschaltetem Vorder- und Rücklicht nach dem Versuch ein .zpp zu laden:
Wenn der Decoder nach einem .zpp Ladevorgang beim Booten Vorder- und Rücklicht einschaltet, dann ist beim Ladevorgang etwas schief gegangen und das Soundflash des Decoders muss wieder gelöscht werden. Das kann bis zu ~50s Dauern. Danach sollte der Decoder (ohne Sound) wieder ganz normal reagieren.



Kannst Du das bitte näher erläutern, wie da vorgegangen werden muss? Soundflash löschen ~50 s?

Beste Grüße

Boris
Grüß dich Boris

Da muss man eigentlich aktiv nichts dazu beitragen. Sollte nach einem Ladevorgang Vorder- und Rücklicht leuchten, dann beginnt der Decoder sein Soundflash zu löschen. Das dauert leider je nach verbautem Flashtyp bis zu 50s. Danach startet der Decoder ganz normal, nur eben leider ohne erfolgreich geladenem .zpp.

Wir sind uns der Problematik diesbezüglich bewusst, leider ist uns da aktuell noch keine Lösung eingefallen ohne die Rückwärtskompatibilität mit alten Soundprojekten zu brechen. An so Dinge wie eine Versionsnummer oder eine Prüfsumme wurde zu Anfangszeiten der ".zpp"s noch nicht gedacht.
Also. Erstmal Sorry, ich hatte die letzten beiden Tage nicht so viel Zeit für die Moba.

Tatsächlich lies sich das unbearbeitete Projekt einwandfrei aufspielen. Auch war meine Zimo Sound Programmer-Version veraltet (V1.21.38). Nach dem Update der Software und einer erneuten Änderung und Aufspielen des Projektes scheint jetzt (fast) alles seine Richtigkeit zu haben. Aufspielen ging jetzt wieder nur ohne CVs 29 und 144. Testfahrt mit dem MXULF (inkl. CV-Auslesen) funktioniert aber einwandfrei.

Kann tatsächlich die veraltete Software-Version verantwortlich sein? Wenn ja, dann habe ich eine andere Frage dazu: wie bekomme ich eine .zpp auf einen Decoder, welche in einer älteren Software-Version erstellt wurde (z.B. aus meiner eigenen Sounddatenbank)? Eben war von Rückwärtskompatiblität mit alten Soundprojekten die Rede. Das geht so aber dann nicht. Oder genügt es, die alte Datei im aktuelle zpp config zu öffnen und erneut zu speichern?

Kritk an der Stelle: es gibt keinen Updateservice in der Software und auch keinen Mechanismus, der das Aufspielen eines zpp aus einer alten Programmversion auf einen Decoder mit aktueller Firmware verhindert. Mir ist auch nicht bekannt, dass es irgendwo dazu einen Hinweis gäbe.

Gruß
Andi
Hallo,

das sollte auch nicht so sein. Wozu habe ich ein Fileformat, eine Software und einen Programmer rundherum, wenn eine Abweichung beim Dateninhalt dazu führen kann. dass der Ladevorgang abbricht und der Speicher im Decoder durcheinander kommt.

Das System, dass der Decoder den Speicher unter bestimmten Umständen autonom löscht und dazu an Schienenspannung gehalten werden muss, ohne dass das Programmiergerät und/oder die Programmiersoftware das berücksichtigen oder anzeigen, gefällt mir überhaupt nicht. Das ganze wird immer verworrener.

Wenn der Decoder weiß, dass etwas mit dem Speicher nicht stimmt, dann soll er das bitte signalisieren (Blinken fände ich besser als alle Lampen an) und zumindest in CV30 oder dergl. den Status anzeigen.

Dann muss man in der Doku auch davor warnen, Lv und Lh für zeitrelevante Verbraucher zu benutzen, Man stelle sich vor, da hängt eine Digitalkupplung dran oder ein Raucherzeuger und der Decoder schaltet einfach weil er lustig ist diese Verbraucher ein. Brennt dann die Magnetspule oder der trocken heizende Seuthe durch, weil der Decoder den Speicher löschen muss?

Grüße, Peter W.
Hallo Andi (#33)!

Ich vermute, dass Du da vollkommen unbesorgt sein kannst. Projekte, die Du bereits erfolgreich auf Decoder geladen hast, kannst du sicher wieder ohne Bedenken auch mit der neuen Version aufspielen so wie Du sie bereits einmal erfolgreich geladen hast. Ich denke, dass genauso wie aktuellere Projekte aktuellere Firmware im Decoder benötigen, benötigen diese auch aktuellere Versionen des Programmes.

Update der Firmware und Laden des Soundprojektes funktioniert bei MS- und MN-Decodern auch bei mir nur ohne CV 29 und CV 144, das Auslesen dieser CVs ist bei MS- / MN-Decodern angeblich auch vollkommen unnötig.

Gruß

Boris


Hallo.

@Andi
In Decoder mit der neusten Software-Version kann man .zpp-Dateien die mit aktueller und auch mit älteren zpp Konfig Versionen erstellt wurden laden.

Es kann jedoch immer passieren, dass bei zpp Konfig (und auch ZCS) ein kleiner Bug, der nur manche Spundprojekte betrifft, erst nach der Veröffentlichung auffällt und deshalb das bearbeitete Soundprojekt mit einer anderen Version (die nicht diesen Bug enthält) abgespeichert werden muss.


Zitat - Antwort-Nr.: 34 | Name: Peter W.

Wenn der Decoder weiß, dass etwas mit dem Speicher nicht stimmt, dann soll er das bitte signalisieren (Blinken fände ich besser als alle Lampen an) und zumindest in CV30 oder dergl. den Status anzeigen.


Wenn beim Soundladen was schief ging sind nicht alle FAs an. Es sind nur LV und LH an.


Zitat - Antwort-Nr.: 34 | Name: Peter W.

Dann muss man in der Doku auch davor warnen, Lv und Lh für zeitrelevante Verbraucher zu benutzen, Man stelle sich vor, da hängt eine Digitalkupplung dran oder ein Raucherzeuger und der Decoder schaltet einfach weil er lustig ist diese Verbraucher ein. Brennt dann die Magnetspule oder der trocken heizende Seuthe durch, weil der Decoder den Speicher löschen muss?


In der MS-/MN-Betriebsanleitung wird bereits auf Seite 45 bzw. Seite 46 erklärt, dass Raucherzeuger und Digitalkupplungen an FA1 bis FA8 angeschlossen werden.

LG
Markus
Hallo

Der Decoder sollte seinen Speicher ausschließlich im Fehlerfall löschen. Natürlich sollte das im Normalfall nicht vorkommen sondern nur wenn man z.b. während dem Ladevorgang die Versorgung kappt.

Diverse Blinkmuster sind bereits für andere Fehlermeldungen vergeben und eine Anzeige in CV30 sieht man nicht sofort. Wenn der Decoder für 50s nichts tut glauben die Kunden er ist defekt.

Ich habe den selben Mechanismus erst kürzlich auch fürs SUSI Soundladen übernommen.

lg
Vincent
Hallo,

Danke für die Erkläungen! Gibt es dazu eine extra Dokumentation? In der Betriebsanleitung steht:
Zitat - Antwort-Nr.: | Name:

signalisieren geschulten Fachleuten Fehler in EEPROM, Flash-Speicher, geg. Sound-Speicher und daraus folgende, fehlgeschlagene Initialisierungen durch entsprechende Blinkmuster


Grüße, Peter W.
Eine extra Dokumentation gibt es so viel ich weiß nicht. Das könnte man in der Betriebsanleitung natürlich noch etwas ausführlicher beschreiben ….

LG
Markus
Grüß dich Peter

Das Blinken ist folgendermaßen definiert:
- 250ms -> Audio geht nicht
- 500ms -> EEPROM geht nicht
- 750ms -> Flash geht nicht

Der Text in der Anleitung ist zum Schmunzeln. "Geschulte" Fachleute.
Ja, unsere Reparaturabteilung hat Leute mit tollen Fähigkeiten, aber diese Blinkmuster "lesen" gehört da glaub ich nicht dazu.  :)

lg
Vincent
Darf ich diesbezüglich nochmal nachhaken:
Zitat - Antwort-Nr.: | Name:

Kann tatsächlich die veraltete Software-Version verantwortlich sein? Wenn ja, dann habe ich eine andere Frage dazu: wie bekomme ich eine .zpp auf einen Decoder, welche in einer älteren Software-Version erstellt wurde (z.B. aus meiner eigenen Sounddatenbank)? Eben war von Rückwärtskompatiblität mit alten Soundprojekten die Rede. Das geht so aber dann nicht. Oder genügt es, die alte Datei im aktuelle zpp config zu öffnen und erneut zu speichern?

Wenn ich das so richtig verstehe, dann sollte eine zpp aus einem älteren zpp config auch auf einen Decoder mit aktueller Firmware drauf gehen? Dann war das bei mir ein einmaliger Softwarefehler?

Für mein Projekt habe ich übrigens noch ein paar CVs angepasst (Dampfschläge,...). Das habe ich auch im ZPP Config getan und nochmal draufgebügelt, damit die Werte bei einem Reset (CV8=8) nicht verloren gehen. Das hat ohne CVs 29 und 144 einwandfrei funktioniert. Der MXULF/A hatte dabei NICHT die aktuelle Firmware, die gerade erst rausgekommen ist und wo sich offenbar einigiges bei den Ladeprozeduren geändert hat (0.84.92).

Gruß
Andi
Hallo Andi!

Ich würde so sagen: Zimo ist ja immer bedacht darauf, dass Projekte, die mit einer bestimmten Version ihrer Programme und für eine bestimmte Firmware der Decoder erstellt wurden, auch mit neueren Versionen der Programme bearbeitet werden können und auch mit Decodern mit neuerer Firmware funktionieren. Das nennt man "Abwärtskompatibilität".

Umgekehrt könnte es durchaus Probleme geben, wenn ein Projekt, das mit einer neueren Version einer Software erstellt wurde, mit einer veralteten Version bearbeitet wird oder in einen Decoder mit älterer Version der Firmware zu laden versucht wird.

Daher wird allgemein empfohlen, nach Möglichkeit immer die neueste Version der Firmware auf den Decoder zu laden und die neueste Version der Software auf PC und Notebook zu nutzen. Da bist Du immer auf der sicheren Seite, egal wie alt die *.zpp-Files sind.

Davon abgesehen kann sich natürlich auch mal ein Bug in Firmware oder Programm einschleichen, der später behoben wird. Oder es gibt technische Probleme, dass eine Datei beim Speichern oder Kopieren auf den Stick korrumpiert wird, da kann dann weder Zimo noch das Programm was dafür, das liegt dann schlicht am Notebook / PC, Aber das wird jetzt nicht mehr eruierbar sein, was seinerzeit bei Dir passiert ist.

Beste Grüße

Boris
Zitat - Antwort-Nr.: | Name:

Wenn die Kondensatoren bei MS- und MN-Decodern am Elko Plus Lötpad angeschlossen werden, können sie auch während dem Update und Soundladen am Decoder angeschlossen bleiben.

nochmal eine doofe Frage hierzu: Kondensatoren mit klassischer Ladeschaltung an GND und V+ werden wohl nicht gehen. Wie sieht es mit STACO aus (hängt auch an V+ und GND)? Hintergrund: Hab hier zwei Kandidaten, da ist das fest verdrahtet und sehr verzwickt eingebaut. Mal "schnell" Ausbauen ist ECHT nicht lustig! Deswegen frag ich so doof, bevor ich es ausprobiere und die Decoder bricke. Im Prinzip sind die korrekten Soundprojekte bereits drauf. Ich möchte aber Decoder-Update machen und ggf. neue "Standard-CVs" haben. Sprich: die CVs sollen sich nach einem Update und einem Decoderreset (CV8=8) auf diese neu eingestellten CVs ändern und nicht auf die Werks-Werte des Projekts.

Geht mit verbundenen Staco wenigstens das Decoderupdate bzw. was kann ich alles machen, ohne die Dinger wieder komplett zu zerlegen? Decoderupdate? CV-Listen aufspielen (in ZPP-Config CVs in Decoder Laden)? Soundprojekt aufspielen? Und noch eine Frage: Werden die CVs beim Aufspielen eines CV-Sets zu den Standard-CVs oder werden einfach nur CVs geschrieben, so als würde ich das händisch programmieren? Wenn es nicht geht, gibt es eine andere Möglichkeit, CVs im Decoder als Projektstandard festzulegen außer das Projekt komplett neu aufzuspielen?

Gruß
Andi
Hallo Andi,

deswegen brauchst du dir keine Sorgen machen. Die Hardware vom STACO ist so intelligent, dass auch mit einen am ZIMO Decoder angeschlossen STACO das Softwareupdate, Soundladen und CV-Set-Laden durchgeführt werden kann. Mit einer klassischen einfachen Ladeschaltung ist das alles nicht möglich.

Ein CV-Set ist einfach gesagt wie ein Soundprojekt ohne Sound. Wenn ein CV-Set in den Decoder geladen wurde, werden bei einen CV8 = 8 Reset die Werte vom CV-Set wieder hergestellt. Nur über einen CV8 = 0 Reset erhält man die Standard CV-Werte des Decoders.

LG
Markus
Hallo Andi!

Wenn Du eine ZPP-Datei in den Decoder ladest, sind die in dieser Datei gespeicherten CVs die neuen Standard-CVs und wird der Decoder mit CV 8 = 8 auf diese Werte zurückgesetzt.

Laut Aussage von Markus (Hardwaredesigner) in einem schon älteren Thread behindert ein korrekt verbauter Staco nicht das Laden von Sound-Projekten in den Decoder, ebenso nicht Updates von Firmware und Lesen und Schreiben von CVs.

Beste Grüße

Boris

Edit: Markus war schneller


Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->

Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account





Zum Seitenanfang

© by 1zu160.net;