THEMA: Zimo MX621: Erw. Function Mapping geht nicht!

Hallo,

mit CV61=97 kann man die Funktionsmapping Tabelle flach klopfen, so dass jeder Ausgang mit jeder Funktionstaste erreicht werden kann und die Richtungsabhängigkeit kann man auch über CV125 ff. einstellen.

Grüße, Peter W.

Hallo Peter,
hast Du meinen Beitrag gelesen und verstanden? Es geht mir nicht um das normale Function Mapping, weil es dort außer F0 KEINE richtungsabhängigen Funktionen gibt, sondern AUSDRÜCKLICH um das erweiterte Mapping mit CV61=98, vermittels dessen JEDE Funktion richtungsabhängig programmiert wird (und nicht etwa die Ausgänge)!

Und nun erklär mir mal, wie Du Deinen Decoder mittels CV125 ff. so programmiert hast, daß bei Rangierfahrt das Licht RICHTUNGSUNABHÄNGIG an bleibt! Mir ist das bisher nicht gelungen, weil sich ein per Effekt am Ausgang zwangsabgeschalteter Ausgang nicht mehr per Funktion einschalten läßt.

Und was ist denn nun mit Deinen Decodern - funktioniert das erweiterte Mapping nun oder nicht? Das war ja hier die Frage.

Gruß,
Torsten

Hallo Torsten,

habe gerade mal probiert, ob man CV 61 programmieren Kann. Mein MX621 lässt sich programmieren. Habe aber das erweiterte Mapping noch nicht ausprobiert.

Viele Grüße
Gebhard

Hallo,

ich habe es beim MX62 und MX620 so gemacht: Mapping auf flach gestellt und dann die F-Taste wo auch der Rangiergang mit drauf liegt (da hat man bei Zimo traditionell nicht die freie Auswahl), so eingetragen dass Lv und Lh gleichzeitig angesteuert werden.

Leider kann ich noch nichts über den MX621 berichten, ich habe keinen.

Grüße, Peter W.

Das freie Bestimmen der F-Ausgänge (CV61=98 und dann das Spiel mit Richtungswechsel) habe ich beim 621 noch nicht probiert. Da der MX621 einen speziellen Prozessor mit kleinem Gehäuse hat der weniger Speicher drin hat kann ich mir schon vorstellen daß die Funktion dem Platzproblem zum Opfer gefallen ist. MM kann das Ding ja auch nimma. In der aktuellen Anleitung sind keinerlei Hinweise zu finden

Wenn das so wäre, wäre das für mich erstmal das Aus für Zimo Decoder! Ich habe den Eindruck, daß sich Zimo ziemlich verkalkuliert hat, anfangs wurde noch kommuniziert, daß der Neue funktionsgleich zum Nachfolger wäre, dann kam peu à peu heraus, daß er nur mehr 4 statt 6 Ausgänge hat, daß SUSI fehlen wird, daß es keine Servo Ansteuerung mehr geben wird, jetzt wo er da ist, fehlt auch MM (wobei das für die N-Bahner ziemlich egal sein dürfte), und die Funktionen, die lt. Anleitung geblieben sind, funktionieren z. T.  nicht richtig (Function Mapping).

Für die Kombination aus einseitiger Beleuchtung (Licht vorne mit F0, Licht hinten mit F1, Rangiergang auf F3 (mit beidseitigem Licht)) ist das erweiterte Mapping per CV98=98 bei Zimo die einzige Möglichkeit, diese Funktionalität überhaupt zu realisieren.

Ich habe mir auf der letzten Modellbahnbörse zum Testen mal einen ESU Lokpilot V4 mitgebracht, das Ding war billig (23€) und kann ebenfalls Zimo HLU und Lenz ABC. Das Mapping über Hunderte von (zu allem Überfluß gebankten) CVs ist zwar erstmal gewöhnungsbrdürftig, faktisch aber schon wesentlich flexibler, als was Zimo anbietet.

Die Regelung ließ sich für mein Testmodell genauso gut, wenn nicht sogar besser als bei Zimo einstellen. Nur bei der Fahrdynamik (Zimo CV121..123) hat er weniger Möglichkeiten.

Nun ist der normale Lokpilot für die meisten N-Modelle zu groß, der Micro V4 ist aber in der Anleitung bereits dokumentiert, wird also auch demnächst kommen und bietet ebenfalls vier Ausgänge. Daß zwei davon Logikpegel-Ausgänge sind, ist kein Problem, die 0,04€ für zwei Logikpegel-N-Kanal-FETs kann man auch noch erübrigen.

Wenn Zimo nicht ganz schnell bei der Firmware nachbessert und wenigstens die in der Anleitung dokumentierten Features auch korrekt zum Laufen bekommt, werde ich mich umorientieren.

Viele Grüße,
Torsten

Hallo.
hast du den ESU V4.0 im praktischen Einsatz (gehabt)? Der "alte" V3.0 war jedenfalls fürchterlich empfindlich auf Micro- Unterbrechungen in der Stromversorgung und somit de facto unbrauchbar. Wenn ESU da tatsächlich deutlich nachgebessert hat, könnte das wirklich eine Alternative sein/werden. Railcom konnte der V3.0 schon und der V4.0 soll ja jetzt endlich auch ABC beherrschen.  Vom Functionsmpping her ist ESU ohnehin unschlagbar flexibel und vielseitig.

Allerdings gehe ich davon aus, das die Zimos auch weiterhin bei der Motor- Steuerung unschlagbar sind...

Hallo Torsten,
wie sieht es denn bei Tran aus? Die sind von der Ansteuerung ja ebenfalls sehr gut und haben auch ein erweitertes Function Mapping. Ein Blick in die Anleitung verriet mir jetzt aber nicht gleich auf Anhieb ob das von dir geforderte Verhalten damit geht...

Torsten schrieb:
> Wenn das so wäre, wäre das für mich erstmal das Aus für Zimo Decoder!

Na sei doch mal so lieb und schicke ein Email an Zimo und frag nach wie es sein soll und erzähl es uns dann. Sind ja mehrere hier die es gerne wüssten (inklusive mir).

Gruß,
Harald.

Hallo zusammen,
ich habe heute mit Herrn Holub telefoniert. Zimo hat da wohl mehr Kahlschlag gemacht, als bisher dokumentiert ist:

Zusätzlich zu den dokumentierten fehlenden Features gibt es mit Ausnahme von CV61=97 das gesamte erweiterte Mapping nicht mehr!

Ebenfalls entfallen ist die km/h Steuerung, die zu einer linearen Geschwindigkeitskennlinie geführt hätte.

Weiterhin könnte es sein, daß auch das distanzgesteuerte Anhalten entfallen ist, daß konnte mir Hr. Holub aber nicht aus dem Stegreif bestätigen. Kann das jemand mal testen?

Viele Grüße,
Torsten

Kann ich nicht sagen - weil Tran bis heute kein RailCom und kein Lenz ABC kann, habe ich mit mit den Decodern nicht weiter beschäftigt.

Viele Grüße,
Torsten

Hallo zusammen,

na das ließt sich ja alles nicht so toll. Ich hatte auf den Decoder gewartet, aber ohne das erweiterte mapping ist er nun deutlich weniger interessant. Zumal der Preis dann für das Gebotene doch recht hoch erscheint. Ich werde mich dann wohl doch auch mal nach einer anderen Alternative umsehen.

Viele Grüße,

Pierre

> Zusätzlich zu den dokumentierten fehlenden Features gibt es mit Ausnahme von CV61=97
> das gesamte erweiterte Mapping nicht mehr!

Danke Torsten. Heisst dass man muss jetzt die Richtungsabhängigkeit von den AUX Ausgängen mit Bits 0,1 von CV127 usw. programmieren oder geht das auch nicht mehr?

Gruß,
Harald.

Hallo Harald,
die Programmierung der Lichteffekte der Ausgänge hat mit dem Function Mapping nichts zu tun. Ob allerdings alle dokumentierten Effekte beim MX621 noch implementiert sind, steht ja auch wieder auf einem ganz anderen Blatt.

Nur hilft Dir das alles nichts, für das von mir immer wieder zitierte Beispiel "einseitige Beleuchtung" in Kombination mit "Rangierlicht" brauchst Du zwingend die Möglichkeit, die Ausgänge wahlfrei richtungsabhängig (normale Beleuchtung) und richtungsunabhängig (Rangierlicht) zu bedienen. Die Minimalimplementation hat Lenz umgesetzt, da wurde die Zuordnung von F1 (CV35) zu F1v umgewidmet, zusätzlich gibt es dann hinter den NMRA-CVs noch CV47 für F1r.

Das wurde leider beim Streichen der Funktionen nicht bedacht, wie Herr Holub eingeräumt hat.

Viele Grüße,
Torsten

Hallo zusammen,
noch ein Nachtrag: Ich stehe auch weiterhin mit Zimo in Kontakt und erhalte hoffentlich in Kürze eine Liste, welche Features beim MX621 gestrichen wurden, damit das Rätselraten ein Ende hat. Da es noch etwas dauert, bis auch die offiziellen Anleitungen auf dem aktuellen Stand sind, werde ich mit Erlaubnis von Zimo diese Info auch hier einstellen.

Zimo ist natürlich daran interessiert, die Scharte mit dem stark eingeschränkten Mapping auszuwetzen. Offen ist z. Z. allerdings noch, wie das passieren wird.

Viele Grüße,
Torsten

... am besten indem erst mal der Preis entsprechend angepasst wird, sonst warten wir ja nochmal ewig (oder wechseln gleich den Lieferanten).
meint
Roger

Zum MX621: Ich denke der Decoder hat so durchaus seine Berechtigung. Sowas Robustes bzgl Spannungen gibts sonst nirgends. Andere Decoder sind wesentlich größer oder haben Spannungsprobleme. Leider liefern viele Zentralen immer noch weit mehr als die genormten 12V für N.

Zur Aufgabe rotes schaltbares Rücklicht richtungsabhängig: das geht auch ohne dem CV61=98 Lernmodus. Belegung F0v uind F0r weiß klassisch an FA1 und FA2 werden die roten Rücklicher angeschlossen. Dann CV35=12 um via F1 beide rot einzuschalten. Man kann auch via Functionmapping andere Tasten nehmen - eeh der Klassiker...
Schließlich über CV127=1 und CV128=2 die rot Ausgänge Richtungsabhängig machen und man ist fertig.

Abschließend: klar die Doku - was der Decoder kann oder nicht kann -  gehört ASAP veröffentlicht. Die Unsitte Dinge zu beschreiben die man gar nicht vor hat zu produzieren dafür aber verfügbare HW überhaupt nciht zu dokumentieren greift leider um sich, ZIMO ist da keine Ausnahme, scheinen es eher erfunden zu haben SCNR

Hallo Arnold,
was Du beschreibst (dieser "Klassiker") ist halt die typische Spielzeug-Variante, die sich nicht am Vorbild orientiert und munter den Wagenpark anleuchtet, bzw. wenn man damit einen vorbildgetreuen Lichtwechsel realisieren will für manuellen Betrieb nicht praxistauglich ist, weil man so für eine automatische Kombination von Fahrtrichtung, einseitiger Abschaltung der Beleuchtung und der richtungsunabhängigen Beleuchtung zwingend eine PC-Steuerung braucht. Dann kann ich ich auch gleich jedes Licht richtungsunabhängig auf eine eigene Taste legen und mich komplett von der PC-Steuerung abhängig machen oder mir an der Zentrale die Finger wunddrücken...

Bei der von Dir beschriebenen Programmierung muß ich für einen einfachen Fahrtrichtungswechsel Richtung Steuerwagen einer Lok im Wendezug
1. Die Fahrtrichtung umkehren
2. Das weiße Licht ausschalten (F0)
3. Das rote Licht einschalten (F1)
Das kann's doch nicht sein, oder?

Das ist jedenfalls nicht das, was ich und wie ich denke auch die Allgemeinheit unter "einseitiger Beleuchtung" verstehe.

Also, ich wiederhole mich jetzt mal zum 'zigten Mal:

Eine richtig brauchbare Lösung wäre:
F0: Licht vorne (weiß/rot abhängig von der Fahrtrichtung)
F1: Licht hinten (weiß/rot abhängig von der Fahrtrichtung)
F3: Rangierlicht weiß beiderseits, wenn Rangiergang aktiv und F0 oder F1 aktiv

Nicht umsonst hat Lenz ja bei der aktuellen Firmware auch F1 richtungsabhängig gemacht (auch wenn das Mapping dadurch nicht mehr ganz NMRA-konform ist) und F1v auf CV35 und CV47 für F1r neu eingeführt. Gut, die kleinen Lenze haben ohnehin nur zwei Ausgänge, aber bei einer Lok mit weiß/weißer Beleuchtung läßt sich so schon Folgendes realisieren:
CV33=1
CV34=0
CV35=0
CV36=0
CV37=3 (F3, Rangiergang)
CV38..CV46=0
CV47=2
Damit geht dann wenigstens schon mal einseitige Beleuchtung und beim Einschalten des Rangiergangs geht auch die Rangierbeleuchtung an. Vorbildgetreuer geht's bei einer Lok ohne rotes Licht ohnehin kaum noch (schön wäre halt nur noch die zusätzliche Bedingung: Rangierlicht nur, wenn F3 UND (F0 ODER F1).

Diese Variante mit F0/F1 und zwangsweisem Rangierlicht bei F3 ließ sich bei Zimo bisher mit dem erweiterten Mapping (CV61=98) problemlos erstellen. Mit der Firmware des MX621 geht das nicht mehr - ein dickes Minus.

Wenn ich jetzt noch rote Beleuchtung an der Lok habe, dann braucht es zumindest etwas Hardware: Ich habe testweise bei einem Modell mal gemeinsame Anodenwiderstände für weiße und rote LEDs verwendet, jetzt muß aber die Vorwärtsspannung im "roten" Zweig noch mit einer Zenerdiode in Serie zur roten LED noch etwa über die Vorwärtsspannung im "weißen" Zweig angehoben werden. Werden dann rot und weiß gleichzeitig geschaltet, geht rot automatisch aus, weil die Spannung nicht mehr reicht. Eine einfache und elegante Lösung - nur läßt sich das nicht einfach bei jedem Modell problemlos so umrüsten.

Kurz und schmerzlos: Mit dem MX621 mit der aktuellen Firmware ist einseitige Beleuchtung NICHT in Kombination mit Rangierlicht realisierbar!

Einseitige Beleuchtung alleine geht (über die Krücke mit den Lichteffekten am Ausgang CV125ff.). Rangierlicht ohne einseitigen Lichtwechsel geht auch (macht aber eigentlich nur Sinn, wenn ein PC die fehlende Lichtsteuerung in der Software anbietet).

Es gibt aber noch einen anderen, juristischen Punkt: Der nennt sich "zugesicherte Eigenschaft". Die fehlenden Funktionen sind in der Anleitung klar dokumentiert, insofern ist das aktuelle Produkt rein aus juristischer Sicht mangelhaft. Auch insofern sollte Zimo schleunigst nachbessern. Entweder die Anleitung (dann werde ich aber künftig kein Kunde mehr sein) oder die Firmware.

Viele Grüße,
Torsten

@18 Nope einfach ausprobieren und Freude haben

F0 macht Lv und Lh Richtungsabhängig - OK das ist eeh der Standard
F1 schaltet rot UNABHÄNGIG von F0 win und das richtungsabhängig

Damit kann ich sowohl eine Zuglok (weiß vorne ein, rot hinten aus), eine Schiebelok (weiß aus nur rot an) als auch eine alleine fahrende Lok korrekt beleuchten. Von Spielzeugbetrieb sehe ich da nix.

Wenn man den andernen Mode haben will daß man nicht weiß/rot steuert sondern Licht an der 1'er oder Licht an der 2'er Seite so ist das auch damit ohne Nachdenken ohne irgendwelcher Probleme machbar:
CV33, CV34=5
CV35=10
damit schaltet man rot/weiß auf den jeweiligen seiten ein das ist natürlich noch Unfig daher dann mit
CV125=1
CV126=2
CV127=1
CV128=2
die Ausgänge richtungsabhängig machen (falls man falsch anschließt einfach  die Richtungsabhängigkeit entsprechend anpassen oder ummöten)
schließlich CV36=3 und CV61=97 und das war's

Ob man jetzt die erste Variante oder die 2. Variante als unbrauchbare Kindergartenversion bezeichnet spaltet die Modellbahner in 2 Hälften. Ist aber egal mit'm MX621 werden beide Kindergartenfraktionen glücklich Vor allem nur mit Programmierung ohne zusätzlcher HW wie Dioden udglm!

Es gäbe ja auch nich die Geschichte mit CV61=2,3,4,5,6 da sollte das auch gehen! Das hab' ich zuletzt vor 12 Jahren benutzt ist also etwas in Vergessenheit geraten.

Über die kreaktive Marketingidee nichtgelieferte Produkte zu beschreiben aber gelieferte nicht zu beschreiben darüber brauch' ma hoffentlich nicht diskutieren - das ist Unfug! Zugesicherte Eigenschaft - hmm ja wirklich interessant ob das Futter für Streithanseln bietet. Mir wär's lieber diese sinnlose klein ist geil Sach' sein zu lassen der 9x13 Einbauraum wird überall geboten daher halte ich die MX621 Verkleinberung für massiv unnötig. Mir wär's lieber wenn bald wieder ein ordentlicher MX620 Nachfolger käme.

@19:
Nee - stimmt einfach nicht. Bitte selbst mal ausprobieren, die Beleuchtungssteuerung bei meinem Umbaubericht für die Arnold 211/V100 nachzuprogrammieren und feststellen - ES GEHT NICHT!

Mit der Nutzung von CV125ff. verbaust Du Dir die Möglichkeit, Ausgänge auch dauerhaft einschalten zu können, wie es eben beim Rangieren gefordert ist.

Wie ich schon geschrieben habe: Im Moment geht mit dem MX621 ENTWEDER Rangierlicht ODER einseitige Beleuchtung. Und wie gesagt, unter einseitiger Beleuchtung verstehe zumindest ich nicht, daß die Beleuchtung beim Wechseln der Fahrrichtung von einer Seite des Fahrzeugs auf die andere springt.

Bitte zeig' mir mal ein Foto, auf dem Du mit Deiner Programmierung beiderseits weiß angeschaltet hast (Rangiergang).

Zur Lektüre mag ich nochmal auf einen alten Beitrag verweisen: http://www.1zu160.net/scripte/forum/forum_show...zernrichtlinien#aw10

Da sind auch die Konzernrichtlinien der DB AG verlinkt, unter KoRil 301, Signalbuch B2, 1 (2) Signal Fz 1 - Rangierlokomotivsignal (Nachtsignal) steht's. Und genau das bekommst Du nicht hin, wenn Du an den Ausgangs-CVs rumfummelst.

Gruß,
Torsten

Torsten,

ist schon richtig, BEIDES geht nicht. Ich verstehe aber auch nicht wozu man das braucht.
Ich habe es seinerzeit so gemacht als es den interaktiven Modus noch gar nicht gab, sondern nur die "flache" Tabelle (mit Standard NMRA Mapping gehts auch nicht wegen F3):

F0 schaltet weiß Lv, Lh - Lichtwechsel Standardbelegung (CV33=1, CV34=2, CV125=0, CV126=0)
F1 schaltet rot an FA1, FA2 - inverser Lichtwechsel (CV35=12, CV127=2, CV128=1)
F3 schaltet Rangiergang und Rangierlicht (2x weiß - CV37=3)

Damit kann ich die Beleuchtung wie folgt schalten:

- Zuglok: F0 (vorne weiß im Wechsel)
- Lokzug: F0+F1 (vorne weiß, hinten rot im Wechsel)
- Schiebelok: F1 (hinten rot im Wechsel)
- Rangierlok: F3 (beidseitig weiß, übersteuert auch F0)

Der einzige Nachteil dieser Variante ist also, dass der Rangierbetrieb immer durch bedseitige Beleuchtung angezeigt wird (es gibt keine Verkopplung mit F0), was ich aber so haben möchte und durchaus vorbildgerecht ist - zumindest bei den ÖBB darf meines Wissens ohne Licht nichtmal mehr rangiert werden, ob das stimmt kann ich heute Abend nochmal einen Lokführer fragen.

Grüße, Peter W.

Hallo Peter
Bei Verschub müssen immer alle drei Lampen in beiden Richtungen eingeschaltet sein.Sonst Verschubuntauglich.Bei Zugfahrten  Spitzenbeleuchtung in Fahrtrichtung drei Lampen. Die Einstellung die Torsten fordert gibt es bei der ÖBB nicht.Oder les ich da was falsch.
Gruß Josef

Hallo Peter,
hallo Josef,
genau diese "klassische" Variante, auf die ja auch Arnold pocht, und zu der man durch das vermurkste NMRA-Mapping quasi gezwungen wird, fordert aber reichlich umständliche Bedienabläufe:

Wendezug:
- Zug fährt, Lok zieht, Beleuchtung mit F0
- Zug hält an
- Richtungswechsel:
  - erstmal F0 aus
  - Dann Fahrtrichtungsumkehr
  - Dann F1 an
- Jetzt kann wieder angefahren werden

Das ist doch einfach nur Murks!

Und bei Rangierbetrieb muß man auch noch händisch F1 abschalten - auch wieder Murks.

Das ist jedenfalls keine einseitige Beleuchtung. Dann kann ich auch gleich die Ausgänge ohne jede Richtungsabhängigkeit zuordnen und alles manuell schalten.

Klar, man kann sich natürlich die Hose mit der Beißzange anziehen. Aber das mache ich nicht und will es auch nicht.

Ansonsten habe nochmal ein Beschaltung angehängt, mit der sich eine Zwangsabschaltung des roten Lichts bei aktivem weißen Licht bewerkstelligen läßt. Einfach und elegant. Zumindest, wenn der Decoder in den Grundfunktionen mal mitspielt...

Viele Grüße,
Torsten



Die von Torsten Lang zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo Torsten,

eine Wendezuglok würde ich sowieso anders programmieren, wozu gibts den PoM.

Was wir eigentlich brauchen, ist die Dunkeltastung aller Lampen auf der Waggonseite, am besten gleich über einen Kontakt an der Kupplung...

Grüße, Peter W.

Hallo Peter,
mit POM würde ich die Lok nicht ständig umprogrammieren, entweder hat der uC echtes EEPROM, dann werden einzelne Zellen über Gebühr verschlissen, oder er hat 'ne EEPROM Emulation im Flash, dann werden ganze Pages immer wieder gefüllt, gelöscht etc.

Wie langlebig die Geschichte dann effektiv ist, steht und fällt natürlich zusätzlich mit der Intelligenz der implementierten Algorithmen.

Jedenfalls keine Frage, diese Form der Vollautomatik würde ich mir ebenfalls wünschen. Nur mit einem Kontakt an der Kupplung halte ich das für suboptimal, schließlich bin ich froh, daß dank Kurzkupplungen wie Fleischmann "Erbse" oder Hammerschmid KK ein sanftes Kuppeln überhaupt möglich ist. Und da habe ich eben Bedenken, daß egal wie so ein Kontakt ausgeführt wird, er entweder mechanisch sehr empfindlich ist oder das Kuppel-Erlebnis wieder in die Steinzeit zurückwirft...

Wohin ich jedenfalls auch nicht möchte, ist die Decoder je nach Betriebssituation immer wieder umprogrammieren zu müssen. Eigentlich sollten wir aus der Digital-Steinzeit so langsam mal raus sein.

Und nach dem, was ich mit Herstellern schon an Gesprächen geführt habe, bin ich nicht der Einzige, der sich da Gedanken macht...

Viele Grüße,
Torsten

Hallo,

der uC ist ein PIC und hat ein echtes EEPROM, laut Microchip 1.000.000 Zyklen.

Ich werde das mal bei der Railcommunity einkippen. Bislang hatte ich eher das Gefühl, dass viele Decoderhersteller an Vorbild- und Modell-Betriebssituationen vorbei entwickeln.

Grüße, Peter W.

Hallo Torsten!
Wir sind doch beide einer Meinung daß es ein großer Mangel ist daß es die CV61=98 Prozedur dzt im MX621 nimma gibt - korrekt?

OK also es gibt 2 Varianten dem zu begegnen, mit tatsächlich veringertem Komfort. Man hat daher nur die Möglichkeit das zu benutzen oder es eben sein zu lassen. Ich bin selbst auch nicht glücklich damit aber derzeit ist es halt so - ich kann auch nix dafür sondern wollte nur Alternativen aufzeigen die man noch hat.

Auf der Zimo Homepage ist ein MX622 angekündigt, der 2 Servoausgänge sowie Susi können soll

Da war auch ein zum MX620 softwarekompatibler MX621 angekündigt...
Ergebnis siehe diesen Thread

@29 Die Ursache für dei MX621 Funktionalitätsreduzierung ist nicht durch ZIMO entstanden sondern durch Microchip, dem Prozessorlieferanten. Die haben erstens nicht wie angekündigt im Februar 2010 den Chip in Volumen geliefert sondern erst Ende 2010 und dann mit gewaltigen Fehlern. Inzwischen gibts auch den MX620 Prozessor nicht mehr, ZIMO hätte nicht sehr lange den MX620 weiter machen können was aber aus Produktionsgründen schon früher eingestellt wurde. Man kann nur hoffen die neuen Prozessoren sind besser sowohl in Qualität als auch Verfügbarkeit.

Hallo Arnold,

die Ursache ist für mich eigentlich beliebig austauschbar, ich sehe hier das Ergebnis nach einem geschlagenen Jahr Wartezeit...
Und ich bin froh für den Preis nicht blind geordert zu haben (die gäbe es jetzt allesamt wieder zurück!), nur sollte Zimo jetzt mal schnell in die Gänge kommen und den angekündigten, bis auf SUSI gleichwertigen, Decoder zu einem entsprechendem Preis endlich bringen, sonst sehe ich da für in Zukunft schwarz!

meint
Roger

Arnold in @17:
> Abschließend: klar die Doku - was der Decoder kann oder nicht kann -  gehört ASAP veröffentlicht.

Wenn ein Produkt das Software enthällt eine Doku hat die so viel vom Produkt abweicht werde ich ganz schnell sehr misstrauisch was Test und Qualitätskontrolle in der Softwareentwicklungsabteilung anbelangt. Irgendwie muss man doch die Checkliste im Test und die Doku miteinander abgleichen?

> Sowas Robustes bzgl Spannungen gibts sonst nirgends.

In der Größe mit 4 Funktionsausgängen, stimmt.  Der DZ143 ist schon ein Stück größer. Wenn der MX622 der eigentliche Nachfolger des MX620 ist und der MX621 die "light" Variante, dann das doch bitte kommunizieren, auch in der Doku, ihr lieben Leut bei Zimo.

Gruß,
Harald.

@32

Was glaubst red' ich mir den Mund fusselig wenn ich bei ZIMO wider einmal vorbei komme. Übrigens keine Sorge sowas wie Dokukontrolle gibts da nicht - falls Dich das nicht noch mehr beunruhigt Der MX621 hat aber keine spezielle Doku, so wie auch die anderen Decoder sondern ist in Varianten darin vermerkt und da sind viele Dinge eben nicht angegeben daß es im MX621 fehlt.

Hallo Lehmden,
meinen Beitrag zur Gänze gelesen? Ich zitiere mich hier nochmal selbst:

Wie sonst, wenn nicht im praktischen Einsatz, habe ich das wohl rausbekommen?

Also: Mir ist nichts Negatives aufgefallen, keine (wie bei Lenz üblich) unerwarteten Notstops und Neustarts bei kleinsten Unterbrechungen o. ä.


Hallo Arnold,
in beiden Fällen full Ack.

Nur: Nicht OK ist eben, daß es nicht dokumentiert wird, ich habe jetzt zu Hause eine Handvoll Decoder liegen, die ich aufgrund der zugesagten Eigenschaften gekauft habe und nun entweder zurückgeben kann oder für die ich Anwendungen suchen muß, wo die Einschränkungen nicht stören. Und geschenkt bekommen habe ich die Teile auch nicht gerade.

Für mich ist die aktuelle Situation jedenfalls ärgerlich (und ich schließe mich hier meinen Vorrednern an: Es zählt halt primär das Ergebnis), da ich faktisch z. Z. keine kleinen und leistungsfähigen (im Sinne von Funktionsumfang) Spur N Decoder mit modernen DCC-Features bekomme:
Kühn N45: Probleme mit dem Controller
Lenz Silver Mini+: Z. Z. schwere Firmware-Fehler und fehlender Fahrstufen-Speicher
Zimo: Stark kastrierte Firmware
Tran: Kein RailCom, kein ABC (aber wenigstens HLU)

Viele Grüße,
Torsten

P. S. Die versprochene Liste mit fehlenden Features habe ich leider bis heute nicht erhalten!
P. P. S. Der LokPilot Micro V4 soll ja in den nächsten Wochen erscheinen, mal schauen, was der bringt.

Hallo
Antwort auf Anfrage an Zimo (Herrn Hubinger)


Ob der MX622 auch mit N-Schnittstelle erscheinen wird ist derzeit noch nicht klar!

Bitte um Geduld, der Decoder ist noch im Designstatus.

Gruß Josef

So, jetzt habe ich einen Fall wo ich das Function Mapping nach CV61=94 sehr gut gebrauchen könnte.

Ich habe hier eine Atlas H16-44 die Analog mit "Christbaumlicht" ausgelefert wird, d.h. bei der Fahrt in die eine Richtung sind vorn Stirnlampe und grüne "class lights" an, hinten "class lights" in rot, in die andere Richtung umgekehrt. Vom Vorbild her ist das Unsinn, da eine einzeln fahrende Lok selten grüne class lights an hätte. Ich habe mit die Platine angesehen, und die Schaltung sollte ungefähr so sein:

http://www.stacken.kth.se/~haba/1zu160/H16-44-led1.1.png

Vorbildlich wären folgende Lichterkombinationen (wenn ich die USA Regeln richtig gelesen habe):

* Vorne Weiss + Zug
* Vorne Weiss + Grün + Zug
* Vorne Weiss, hinten Rot (alleinfahrende Lok)
* Hinten Rot (letztes Fahrzeug, Schiebebetrieb oder Lokzug)

(Die Lok gab es auch in Digital ab Fabrik, die Kommentare zum orginal Lenz Dekoder sind aber nicht so jubelnd).

Entweder könnte ich jetzt versuchen einen Digitrax DN163A0 zu bekommen und alle 4 class lights mit neuen Dioden (gemeinsames + anstelle von gemeinsamen -) neu aufzubauen, oder so könnte man auf der modifizierten Platine einen MX620 unterbringen und mit CV61=94 die Lichteffekte hinbekommen. Da die LED schon an der richtigen Stelle sitzen, hätte ich eigentlch die Platine gern behalten. Die Schaltung auf der modifizierten Platine würde dann so aussehen, man bräuchte noch ein paar kleine SMD Dioden.

http://www.stacken.kth.se/~haba/1zu160/H16-44-led2.1.png

Der Trick um hier um mit 4 Funktionsausgängen auszukommen ist dass man die Ausgänge anwendet um die LEDs abzuschalten. Einen MX620 könnte man so mappen (fahtrichtungssymetrisch):

* Vorne Weiss + Zug  = F0v + F1 + F2 bzw F0r + F1 +F2
* Vorne Weiss + vorne Grün + Zug = F0v + F2 bzw F0r + F1 +F2
* Vorne Weiss, hinten Rot (alleinfahrende Lok) = F0v + F1 bzw F0r + F1
* Hinten Rot (letztes Fahrzeug, Schiebebetrieb oder Lokzug)  = geht nicht

Dass die letzte Variante nicht geht kann ich verschmerzen, kann die vorletzte Variante nehmen. Ich hab in den USA gesehen wie der Scheinwerfer der letzten Lok im Lokzug schön die vorletzte Lok anscheint.

Doch: Ich habe keinen MX620 mer herumliegen, und jetzt eine andere Lok schlachten (*) um an einen MX620 von einer Lok zu kommen wo die Spezialfunktionen "übrig" sind, das will ich auch nicht.

Hab auch schon mit dem DN143 probiert, doch der ist zu dick wenn man die class lights behalten will.

So was mach ich jetzt? Leg das Projekt erst mal wieder auf die Seite glaube ich.

Gruß,
Harald.

(*) Das wäre in dem Fall ein Taurus meiner besseren Hälfte, das wär wohl "out"

Hallo,

in der neuesten Betriebsanleitung werden die fehlenden Funktionen aufgelistet:
http://www.zimo.at/web2010/documents/MX-KleineDecoder.pdf

Grüße

Stephan

Harald,
wenns passt nimm einen anderen (kleinen) Decoder, z.B. von Tran. Evtl. Könnte man sogar noch einen Funktionsdecoder einbauen um fehlende Möglichkeiten abzudecken.

Hallo zusammen,
um nochmal ein paar Punkte aufzugreifen:


Leider muß ich Dir in der Beziehung teilweise recht geben. Mein Testexemplar (ein nachträglich motorisierter Arnold Turmtriebwagen, dazu habe ich zwei Radsatzschleifer von Fleischmann verbaut (die für die 9447)) ist erfreulich kontaktsicher. Ich habe jetzt auch den ersten LoPi Micro V4 verbaut (in einer Fleischmann 145). Der ESU merkt sich zwar korrekt die Fahrstufe, braucht nach einer Mikro-Unterbrechung aber zu lange zum Booten und scheint auch den Regelkreis neu zu initialisieren. Das führt dann leider zum Ruckeln. Weiterhin läßt die die Motorregelung nicht 100%ig auf den Fleischmann Motor einstellen, entweder gibt's einen Ruck beim Anfahren oder beim Anhalten. Und das "Grade Crossing", das perfekt wäre, Rangierlicht mit der Licht-Grundfunktion zu kombinieren (also Rangierlicht nur dann, wenn F0 oder F1 an), geht leider auch nicht (mal schauen, wann der Support dazu antwortet). Das ist leider ziemlich ernüchternd.


So ist das bei der Deutschen Bahn ja auch. Sofern die Lok ohnehin nur weißes Licht hat, kann man wenigstens dahingehend tricksen, daß man jeweils zwei Ausgänge zusammenschaltet und den einen richtungsabhängig, den anderen richtungsunabhängig programmiert, d. h. der Decoder hat dann faktisch nur noch zwei Ausgänge.

Damit gibt es momentan IMHO einfach keinen brauchbaren Spur N Decoder, der mindestens vier Funktionsausgänge (besser 4+2), ein freizügig programmierbares Function Mapping, RailCom und ABC (und HLU) hat. Brauchbar heißt für mich, daß es keine schweren Fehler in der Firmware (z. B. Lenz: Notstop beim Richtungswechsel) oder eine mangelhafte Motorregelung (Lenz, Kühn: zu hohe Kriechgeschwindigkeit, ESU: Stottern oder Neustart bei kurzen Spannungsabfällen o. ä).

Viele Grüße,
Torsten

Moin zusammen,
beim MX621 ist nun immerhin etwas Besserung in Sicht. In Kürze dürfte es ein neues Update geben, mit dem sich dann relativ leicht (zumindest bei LED-Licht) einseitiges Licht mit Rangierlicht und rot/weißer Beleuchtung kombinieren läßt. Ein bißchen technische Nachhilfe braucht es dann immer noch, aber der Aufwand ist zumindest bei LED-Licht minimal, sofern die Schaltung paßt (Widerstände anodenseitig).

Ich habe hier gerade eine Roco 290 mit nachgerüsteter Beleuchtung am Probelaufen und es schaut sehr gut aus!

Tante edit hat noch einen Nachtrag: Vielen Dank an dieser Stelle mal an Herrn Holub, der sich für die Beseitigung eines Problems mit Lenz ABC die Nacht um die Ohren geschlagen hat!

Viele Grüße,
Torsten

Hallo Torsten,

ist sicher toll - mach mal ein paar Fotos!

Grüße, Peter W.

Hallo Peter,
mach' ich bei nächster Gelegenheit. Ich muß noch die Griffstangen lackieren, da fehlt mir noch "das richtige" Grau. Dbei werde ich das Gehäuse ohnehin abnehmen und dann auch vom Innenleben noch ein paar Bilder machen.

Wahrscheinlich gibt das dann wieder mal einen Umbaubericht

Viele Grüße,
Torsten

Hallo Peter,
das das Thema mit dem MX621 nur am Rande zu tun hat, habe ich mal einen eigenen Thread aufgemacht: Unter http://www.1zu160.net/scripte/forum/forum_show.php?id=563962 gibt's schon mal ein paar Fotos.

Viele Grüße,
Torsten