Das Tool ist in Verbindung mit der Echtzeitprogrammierung so was von geil und beim abstimmen der Lok der ESU-Software alleine schon beim Zeitaufwand deutlich überlegen und auch einfach praktischer.
Gruß Thorsten
Kann ich wiederum überhaupt nicht unterschreiben. Ich arbeite mit dem Lokprogrammer von ESU bei den ESU Decodern und dort ist das Verschieben der einzelnen Funktionen und Soundslots deutlich einfach als bei Zimo und das sogar bei "codierten" Henning und Piko Sounds. Manfred hat sich fast die Zähne an meinen Zimo MX645 ausgebissen um die Funktionen nach Wunsch so um zu verlegen wie ich es der Einheitlichkeit halber benötige. Ohne das passende "Zpp" geht hier gar nix, das mußte sogar Herr Henning in Leipzig zugeben, welcher sich gestreubt hatte das Selbige für meine Lok mit seinem Sound heraus zu geben. Das auf der Zimo Webseite war nicht kompatibel. Ich hatte mühsam CV für CV ausgelesen, dokumentiert und daraus versucht mit der zcs Software eine zpp Datei zu erstellen. Selbst das hatte nicht funktioniert, da sich die CV's nicht abspeichern ließen.
Viele Grüße Steffen
DR Ep.III und IV, Pilz Standard und Tillig Elite, Digikeijs DR5000, DR4088/LN CS, DR4033, DR4018, WDec04b, Zimo, ESU, Kres FlexDec, I-Train Plus; TCB , Programmer: ESU, MXULFA, Lenz, D&H Schaut mal hier rein: Modellbau Club Jahnsbach Offizieller Sponsor der Modellbahnproduzierenden Industrie
Hallo Oliver, ich bin zwar in diesen Thread nur am Rande involviert, aber: Ich hätte dem Kollegen schon gar keine Antwort gegeben ob seiner unverschämten Aussagen. Ich für meinen Teil setze das ZCS ein, um meine Zimo Decoder zu konfigurieren und ich bin sehr zufrieden damit und dankbar, dass ich es kostenlos nutzen darf. Es ist sicher in Ordnung, jemanden ein höfliches Feedback zu geben, wenn einem ein Fehler auffällt oder man ein Frage hat, aber der Ton macht die Musik. Ich kann jeden verstehen, der keine Veröffentlichungen mehr macht um sich nicht solch unqualifizierten Aussagen ausszusetzen. Daher einfach ignorieren, die große Mehrheit steht deinem Produkt sicher sehr positiv gegenüber, Gruß Thomas
Du hast Recht. Ohne die zpp-Datei geht's nicht. Die zu haben, ist für mich so selbstverständlich, dass ich gar nicht auf die Idee kam, das zu erwähnen. Deshalb kaufe ich auch keine fertig bespielten Decoder mehr. Aber das Problem hast Du bei JEDEM Hersteller. Also Grundlage für weitergehende Anpassungen ist immer die Projektdatei. Weil Herr Henning bei seinen ESU-Projekten zumindest damals nie die Datei herausgeben wollte, obwohl er sie ja auch verschlüsseln kann, habe ich nur noch ZIMO-Projekte von ihm gekauft.
Vergleicht man eine "gecodete" zpp-Datei mit der verschlüsselten Projektdatei von ESU (z. B. von LeoSoundLab), so hat man mit letzterer eklatant weniger Möglichkeiten, den Sound für sich selbst hinzubiegen. Ich meine nicht das Mapping. Mapping mag für die meisten DAS Problem sein, die kein Programmierbaustein haben. Wenn vorhanden, ist das eine Farce und sozusagen Standardprozedur nach Kauf oder Soundisierung einer Lok. Und das geht bei ESU natürlich auch sehr gut. Ich meine aber tiefere Eingriffe in den Soundablauf und die einzelnen Funktionssounds. Bei ESU ist der "Soundteil" einer verschlüsselten Projektdatei gesperrt aber aufgrund der besonderen Architektur muss ja in den Ablauf rein. Da geht ja fast nichts mit CV's. Bei ZIMO kann man dagegen noch richtig viel machen.
Und gerade bei der Anpassung des Sounds ist die Echtzeitprorammierung so vorteilhaft: Man verschieb einen Lautstärkeregler und kann sich sofort das Ergebnis anhören. Oder man setzt beim Mapping irgendwo einen Haken und sofort ist die Funktion da. Bei ESU muss man immer erst flashen.
Übrigens ist es bei D&H recht ähnlich wie bei ZIMO. Deshalb bin ich auch froh, dass man z. B. LeoSoundLab-Sounds ohne Aufpreis beim eh schon günstigen D&H mitbekommt. Auch da kann ich mehr abstimmen.
Um was für ein Projekt handelte es sich bei dem von Henning eigentlich? Ich weiß, dass er mehr hat, als auf der ZIMO Sounddatabase vorhanden. Aber ohne die Datei wird er sie mir nicht mehr verkaufen können. Dafür ist ja die Geschichte mit dem Ladecode da. Die übrigens ganz hervorragend funktioniert. Ich kaufe sie meistens bei einem bestimmten Online-Händler (der hier auch schon geschrieben hat) per PayPal. Meistens habe ich dann noch am selben Tag den Code in meinem Postfach. Bisher hatte jeder meiner Roco Werkssounddampfer spätestens am zweiten Tag nach dem Kauf ein besseres Projekt als das originale drauf ;-)
Nun gut. In die Soundabläufe selbst will ich (vorerst) nicht eingreifen. Für mich ich ein einfaches Handling bei Mappen maßgebend. Als DR-Bahner bin ich jetzt (bis auf wenige Ausnahmen) voll auf Henningsound. Das Problem ist dort, das die von ihm selbst (wie in meinem Falle) aufgespielten Projekte schon weiter Entwickelte sind gegenüber Denen, welche auf der Zimo Homepage zu finden sind. So auch bei meiner 35.10, aber auch der "132"er. Gerade Dieser ist speziell auf seine "eigene" Platine abgestimmt, welche ich auch in meiner Lok verbaut habe. Was ESU betrifft hast Du natürlich recht, aber dafür bekomme ich, wenn der Sound von ihm einmal drauf ist, ein kostenloses Update, wenn Dieser, wie im Falle der 58.30, verbessert wurde. Bei dieser Loktype kannst Du den Originalen (nicht von Henning), speziell für Gützold entwickelten und von ESU übernommen Sound nicht anhören. Zu diesem Sound hatte ich vor langem hier mal einen Thread geschrieben. Leider wird dieser Sound in der aktuellen Ausführung mit ESU Decoder (es wird alternativ auch eine Ausführung mit Zimo Decoder und Henningsound angeboten) wieder so angeboten. Genau diese Ausführung hatten wir erst kürzlich zu unserer Ausstellung zur Verfügung. Soll aber nicht weiter das Thema sein. Zum D&H möchte ich mal sagen, wenn der die Vorzüge von Zimo (10 FA) und ESU (einfaches Mapping mit entspr. Programmer) vereint wäre er eine Alternative. Leider kann man hier nicht mal die Programmer Software, wie von ESU oder Zimo, testen, da schon die entsprechende Software kostenpflichtig ist.
Viele Grüße Steffen
DR Ep.III und IV, Pilz Standard und Tillig Elite, Digikeijs DR5000, DR4088/LN CS, DR4033, DR4018, WDec04b, Zimo, ESU, Kres FlexDec, I-Train Plus; TCB , Programmer: ESU, MXULFA, Lenz, D&H Schaut mal hier rein: Modellbau Club Jahnsbach Offizieller Sponsor der Modellbahnproduzierenden Industrie
Lieber Thomas, vielen Dank für Deine aufmunternden Worte! Was ZIMO/ESU etc.ist besser betrifft: Der Vergleich zwischen dem Handling von ZIMO oder zb. ESU Decoder ist imho nicht wirklich zulässig. Beide verfolgen in der Programmierung und im Handling doch eine andere Philosophie. Was nun besser ist, ist imho eher Geschmacksache. Daher sollte man sich davon verabschieden einen Vergleich zu ziehen "bei ESU macht man das so, warum nicht auch bei ZIMO?" Weil es eben anders funktioniert! Genausogut könnte ich fragen, weshalb ESU Decoder kein NMRA Mapping kennen ... weil ESU eben eine andere Philosophie hat und das Mapping anders funktioniert - ist so. Daher gibt es nur zwei Möglichkeiten: 1.) sich damit abfinden 2.) rigoros nur noch Decoder eines Decoderherstellers verwenden
natürlich "schießt" man sich irgendwann auf einen bestimmten Decoderhersteller, bzw. seiner Philosphie ein. Nur leider ist das bei Sound-Decodern ja kaum möglich, weil man sich nun einmal nach den vorhandenen Sounds richten muss. Unterm Strich kann und muss man natürlich vergleichen, welche Herstellerphilosophie, bzw. Produktmerkmale den eigenen Vorstellungen am nächsten kommt. Das ganze Leben besteht ja eigentlich aus "Vergleichen". Durchaus darf man sich bei einigen Features durchaus fragen, warum es der andere Herstereller nicht auch anbietet, sofern es nicht eine Frage der "Programmierung" und des "Handlings" ist. Z. B. empfinde ich die Funktion "Bremstaste" und die Umschaltung auf ein anderes ABV-Profil mittlerweile als für mich und einer vorbildlichen Fahrweise als essentiell und neben der Philsophie der Aufnahme der Vorbildgeräusche als Grund, Loksound ganz hintenanzustellen in meiner Auswahl.
Servus Thorsten, man "muss" sich nicht wirklich nach Vorhandenem richten ... man kann durchaus Sounds von vorhandenen, aber unerwünschten Decodern auslesen ... Ich habe diese Art der Sounderstellung u.a. hier beschrieben: http://mobazi.huebsch.at/tipps/sounderst...derstellung.htm Das mach ich zb. bei US-Loks mit deren verbauten Decoder, die einen durchaus guten Sound haben, deren Ansteuerung aber teilweise mehr als "gewöhnungsbedürftig" ist .... Es macht auch keinen Sinn sich zu fragen, weshalb die Amis kein ABC oder RailCom kennen - ist so. Ich habe nur die Möglichkeit das zu akzeptieren und den Decoder so wie er ist zu nutzen und mich ständig zu ärgern, dass das Ding nicht das macht, was ich möchte und alle anderen Fahrzeuge mit "meinen Wunschdecodern" machen, oder ich entferne des Decoder und baue die Elektronik komplett selber auf (was ich auch mache - siehe zb. http://mobazi.huebsch.at/umbauten/CabForward_AC5/AC5.htm ). Das ich dann bei der Gelegenheit mehr einbaue, als vom Hersteller ursprünglich vorgesehen, ist für mich irgendwie "eh klar".
Fragen darf man sich aber, weshalb manche Hersteller auf Kritik und Kundenwünsche reagieren (wenn auch manchmal langsam), andere dies aber nicht einmal ignorieren... oder weshalb es noch immer Decoder gibt, die nicht updatefähig sind ...
Deine verlinkten Artikel kenne ich. Sind toll. Aber das ist dann natürlich schon "richtig Arbeit". Solange ich immer noch etliche "leichter machbare" Projekte auf dem Tisch stehen habe, kann ich so etwas zum Glück auf die lange Bank schieben, bis es vielleicht doch einmal ein gutes Projekt gibt. So ist es z. B. mit Deinem Köf II - Projekt, bei dem die Lok schon länger umgebaut ist. Du hast Dich ja scheinbar ziemlich auf US-Bahnen verlegt und machst auch nicht mehr viel für die "Öffentlichkeit" scheint mir. Wenn Du gecodete Projekte nach aktuellem Standard machen würdest, hätte ich so gar nichts dagegen. Leider kann ich mit US-Sounds aber so gar nichts anfangen.
den blanken Frust kann man sich selbst dann abholen wenn man diese Ausrüstung besitzt: Eigentlich sollte das hier völlig ungefährlich sein. Ich habe weder einen Abschluss im Studiengang Informatik, noch einen Studiengang angefangen, geschweige denn fortgeschrittene Kenntnis der Informatik; in dieser Hinsicht bin ich einfach der schlichte Laie mit rudimentären Wissen. Auch hier ist der MX645 auf einmal verstummt als ich ihn mit dem ZCS einstellen wollte. Ganz einfache Decoder Grundeinstellungen wie Höchstgeschwindigkeit, anpassen der Dampfstösse an die Radumdrehungen oder Function Mapping. Die entsprechenden CVs bearbeitet und schon war der Decoder stumm. Erst nach einem Hard Reset war der Sound dann wieder da, aber nicht der vorher aufgespielte, sondern der welcher ab Werk auf dem Decoder vorhanden war. Später nach ettlichen Versuchen und Fehlersuchen bin ich dann dahinter gekommen, wenn ich einen der virtuellen Lautstärkeregler im ZCS ein kleines bischen bewege, ist ein Teil vom Sound wieder da. Dann gab es noch andere Spukereien mit dem ZCS, deren Ursachen ich mich ausserstande sehe zu klären. Das Aufspielen von Sounds aus der Zimo Soundbasis klappte auch nur sporadisch, in letzter Zeit ging da gar nichts mehr zu machen. Ich habe daher den MXULFA erst einmal beiseite gelegt bis das geklärt ist und bei mir so funktioniert wie es sollte, aber dafür brauche ich Hilfe, wie schon erwähnt ich bin kein Informatiker.
In der Zwischenzeit bearbeite ich meine Decoder mit Decoder Pro über einen SPROG3 was wunderbar unkompliziert funktioniert, auch bei Zimo Sounddecodern. Der Mitbewerb bietet auch Soundecoder an welche für den Laien nicht so sperrig zu handhaben sind.
Ich bin auch kein Informatiker aber Deine Probleme kann ich ganz und gar nicht bestätigen und ich habe den MXULFA mit ZSP und ZCS wahrlich oft in Benutzung. Womit versorgst Du ihn denn mit Strom? Bist Du grundsätzlich auf aktuellem Stand mit Firm- u. Software?
Hallo Thorsten, ZCS, ZSP, das Updaten von MXULFA sind nicht selbsterklärend und setzen Grundkenntnisse der Informatik voraus über die ich im Moment nicht verfüge. Das wird mir jemand ausführlich erklären müssen, irgendwie will ich es es ja mal lernen. Netzteil z.Zt. HP 16V=, 825mA und hier hängt nur das Programmiergleis daran, sonst nichts. Hier auf diesem Gebiet Zimo Sounddecoder bin ich eindeutig nicht der Crack, sondern der Anfänger.
Man muss weder Informatiker sein, noch studiert haben - CV Konfiguration hat damit überhaupt nichts zu tun (ein klein Wenig Verständnis der Materie schadet jedoch nicht ... aber alles, was über die Zahlensysteme Dezimal, Hexadezimal und Binär und deren Umrechnung hinausgeht, ist nicht erforderlich - das sind dann aber eher Themen der Mathematik, als der Informatik)! Um CVs zu ändern braucht man auch kein MXULF - das ist nur *erforderlich* wenn man selbst Sounds erstellt/ändert und in den Decoder laden will, bzw. zum Firmwareupdate.
Alle anderen (NMRA kompatiblen) Dedcoder haben großteils die gleichen CVs und die gleichen Werte - und die können ja auch ohne "Informatikkentnisse porgrammiert" werden?!
Das das MXULF aufgrund von Firmwarefehler manchmal mit Decoder - speziell mit in Modellen verbauten (wegen zb. Elkos oder sonstige Verbraucher) mehr oder weniger Probleme hat, ist eine andere Geschichte ... Auch, dass die Strom/Spannungsversorgung des MXULF, bzw. das MXULF selbst da empfindlich reagieren kann, leider auch. Manchmal hat auch eine Decoderfirmwareversion einen Bug ... Ich selbst nutze das MXDECUP, MX31ZL und MXULF und habe bisher noch so sich hartnäckig weigernde Decoder "klein" bekommen ;) Natürlich ist mir klar, dass nicht jeder diesen Gerätepark und/oder Geduld hat. Da hilft aber kein Schimpfen, sondern nur Kontakt zum ZIMO Support und im schlimmsten Fall das Einsenden des Decoders.
Ein Informatiker, Elektroniker, Programmierer etc. hat aber dem "Normalo" einen entscheidenden Vorteil: Er *kennt* alle möglichen und unmöglichen Fehler, die auftreten können, obwohl sie eigentlich nicht auftreten dürften... ist daher oft gelassener und versucht es halt auf eine andere Art - vielleicht sogar mit Werten/Methoden die absolut unlogisch erscheinen und wundert sich nicht, wenn heute etwas funktioniert, das gestern unter gleichen Bedingungen nicht funktioniert hat oder umgekehrt ;)
Was das Netzteil betrifft: 825mA sind zu wenig - das Netzteil muss ja nicht nur den Decoder versorgen, sondern auch das MXULF selbst ... Ich schließe mein MXULF am Schienenausgang meiner Zentrale an - 15Volt X Ampere ...
glaube mir, mit "Informatiker" hat das alles nicht viel zu tun. Man muss sich nur einfach darüber im Klaren sein, dass Software nun einmal einer stetigen Weiterentwicklung unterliegt. Wie ja eigentlich alles in unserer hochtechnischen Welt. Das bedeutet, wenn ich sie nutze außerhalb abgeschotteter Systeme, MUSS ich regelmäßig nach Updates suchen und mich mit deren Durchführung vertraut machen. Da kommt man nicht drum herum! Es gibt zwar den Stammtischspruch "Never change a running system", aber der trifft eigentlich nur bei den vorher genannten Systemen zu, die mit der "Außenwelt" nichts zu tun haben. Und das ist hier nicht so. Alleine durch den Kauf eines neuen Decoders oder eines neuen Soundprojektes werden Updates notwendig. Das dadurch mal Fehler auftreten können, liegt auch in der Natur der Sache. Ich kann Dir aber versichern, als "Administrator" eines Heimnetzwerkes mit 6 Rechnern sowie einer nicht kleinen WLAN-Peripherie, dass die "Wartung" zwar eine Sauarbeit ist aber es dadurch erst gar nicht zu Problemen (auch mit der Sicherheit) kommt, mit denen andere sich dann doch über kurz oder lang rumschlagen müssen. Ich bin z. B. erstaunt, dass Oliver von etlichen Problemen mit dem MXULF berichtet. Allerdings dürfte da auch einen ganz anderen Horizont haben. Bei mir kommen im Schnitt 6, 7 neue MX64x pro Jahr neu dazu und nebst dem "Unterhalt" der alten (es gibt ja auch immer mal wieder aktualisierte Soundprojekte, so dass man da auch immerm al wieder "ran" muss). Ich kann von ü b e r h a u p t k e i n e n Problemen, wie Du sie schilderst, berichten. Das flutscht einfach. Ok, das setzt alles kein Informatikstudium voraus aber lesen, lesen, lesen und verstehen. Nachdem ich ESU gewohnt war, musste ich mich hier auch umgewöhnen, was mir durchaus auch etwas Stress bereitete. Bei Problemen und Fehlern versuchen, sie logisch einzugrenzen, zu recherchieren, sich einzulese. Zugegeben sind Dokumentation und Präsentation bei ZIMO etwas unübersichtlich und durchaus gewöhnungsbedürftig (für mich als Norddeutscher auch manchmal auch das Wienerisch ;-)) aber dafür sind die technischen Möglichkeiten enorm und die Produkte sehr innovativ. Außerdem sind sie sehr nah am Kunden, wie ich immer mal wieder feststellen konnte. Da bekommt man auch schon mal nachts, nach kurzer Zeit schon, eine Mailantwort. Der ganze Digitalkrempel ist nun einmal ein Hobby im Hobby und wer die Möglichkeiten ausschöpfen will und auch eigene Ansprüche daraus entwickelt, muss sich offensiv und geduldig damit auseinandersetzen. Eine neue Soundversion aufzuspielen und mittels des ZCS schnell und direkt abzustimmen, macht wirklich unheimlich Spaß. Weil es auch viel besser geht als beim Mitbewerber mit den 3 Buchstaben. Seitdem Brawa auf D&H setzt und sie sich einige gute Sounddesigner geangelt haben, habe ich meinen Horizont auch auf deren Produkte erweitert und mir auch deren Programmer geholt. Von der Archiitektur her sehr ähnlich und deren eigene Software läuft ganz ordentlich und man findet schnell rein. Von der Funktionsweise und vom Umfang her ist das ZCS ja wirklich klasse, wenn auch in der Bedienung der GUI etwas zickig. Auf jeden Fall müsste ZIMO eigentlich selbst ein derartiges Programm entwickelt haben wollen. Wahrscheinlich haben sie es mit dem ZIRC gemacht, das aber ja nun schon etliche Jahre stillzuliegen scheint.
Nun auch noch was zur Stromversorgung. Mangels Alternativen hatte ich gleich, wie Oliver, meine Schienenspannung genommen. Erst vom ESU Navigator, jetzt von PIKO (ESU) Smart Control. Nie Proble damit gehabt. Wie wichtig aber eine STABILE Spannung ist, habe ich jetzt beim D&H Programmer gemerkt. Sie geben die Anforderungen an und empfehlen ein Schaltnetzteil. Ich hatte einige Steckernetzteile mit den passenden Daten probiert. Bei jedem brach beim flashen die Spannung ein. Auslesen ging noch. Dann habe ich mir ein Schaltnetzteil besorgt und seitdem gibt es keinerlei Probleme mehr. Ach ja, und natürlich die Firmware von Progammer und Decoder auch gleich aktualisiert ;-)
Hallo! Nun, dass ich von möglichen "Problemen berichte" liegt daran, dass ich nicht nur *ein* (mein) MXULF, sondern auch andere Geräte teste.... und manchmal kann es schon sein, dass ein Gerät unter bestimmten Bedingungen so überhaupt nicht will. Oft sind das aber Bedingungen, die sehr schwer bis gar nicht nachstellbar sind und dann auch oft nur zufällig auftreten ... Leider kann man einen Fehler nur beseitigen, wenn man ihn nachstellen, somit finden kann und dann auch noch die Ursache erkennt.
Ich will jetzt sicher nichts beschönigen, nur etwas mehr Verständnis schaffen, dass ein Problem manchmal ein "Einzel-Schicksal" ist, bedingt durch Bedingungen, die genau nur bei dem vorkommen, der das Problem hat - hier eine Hilfe zb. über ein Forum zu geben ist unmöglich! Es können nur vage Vermutungen angestellt und Tipps gegeben werden die möglicherweise die Lösung sein könnten - Betonung liegt auf "möglicherweise" und "könnte" ...
Am Rande: Ich habe einen alten MX82, mit dem ich 4 Servos als Weichenangtrieb ansteuere. Jetzt wollte ich die Werte für die linke und rechte Endstellung auslesen und dann neu schreiben. Hat nicht funktioniert (ich habe den Decoder aber schon erfolgreich konfiguriert!)... Weder mit dem MXULF noch MX10 oder MX31ZL - auch nach einem Firmwareupdate ging nichts. Weder am Programmiergleis, noch am Hauptgleis, obwohl die Firmware angeblich RailCom können sollte, war ein Auslesen/Schreiben nicht möglich - egal was ich versuchte, es gab immer eine Fehlermeldung.... Bis ich dann einfach in der Zentrale RailCom abgeschaltet habe - und siehe da, auf einmal war am Programmiergleis lesen/schreiben und am Hauptgleis schreiben ohne Fehler möglich! Hat mich rund 45 Minuten gekostet, bis ich die Ursache und somit den Fehler gefunden habe - normalerweise denkt an so etwas kein Mensch! Da hilft nur analytisches Denken: ich habe "damals" den Decoder mit dem MX1 konfiguriert - was hat sich vom MX1 zum MX10, MX31ZL, MXULF geändert?! Richtig - RailCom! Natürlich hätte ich den Decoder auch dem Entwickler zur Überprüfung geben können (wär sicher ein Spaß geworden zu sehen, wie lange er braucht ;) ... vor allem, da es MX82 gibt, die keine Probleme mit RailCom haben - liegt an der HW-Revision, wie ich inzwischen erfahren habe ...
Ihr seit also nicht alleine mit dem einen oder anderen Problem - und selbst als "Informatiker" kämpft man mit solchen (nur gehe ich zb. anders an die Sache ran, WEIL ich eben schon viel unmögliche Dinge erlebt habe ... wenn ich meine Schlüssel verlegt habe, suche ich auch im Kühlschrank ... nix ist unmöglich ;)
schön, daß es bei Dir flutscht. Ich wünschte das wäre bei mir auch so. Als Hinweis an die Experten in Sachen Zimo; bei mir hängt der MXULFA über USB-Kabel direkt am Rechner. Das Netzteil, übrigens ein Spannungstabilisiertes, ist ebenfalls mit angeschlossen. Kommt es da zu irgendwelche Interferenzen?
@Oliver Auch wenn ich kein studierter Informatiker bin, so habe ich doch viel damit zu tun. Von daher kann ich jeden Deiner Sätze voll bestätigen. Ich hätte vorher auch nicht geglaubt, dass auch die Digitaltechnik sein kann wie eine Mechanik: Zwischen richtig funktionieren oder gar nicht gibt es tatsächlich noch was dazwischen. Ist was für Menschen mit großem analytischen und logischen Verstand.
@Ludwig Natürlich schließt man ihn an den Rechner an. Dann wird's ja überhaupt erst interessant. Das dient aber nicht wirklich zur Spannungsversorgung. Oliver hat ja schon gesagt, dass Deines zu schwachbrüstig ist. Dann nimm doch die Schienenspannung Deiner Digitalzentrale. Das funktioniert! Hast du Dich nun mit der Firmwareaktualisierung beschäftigt? Was zuerst recht kompliziert aussieht, ist nachher ganz einfach. Aber ACHTUNG: Ab einer bestimmten Firmware ist ein neuer Treiber erforderlich. Schau hier: http://www.zimo.at/web2010/support/UpdateMXULF.htm Du musst alles genau durchlesen, dann kommst Du zum Ziel.
Ich bin mir sicher, dass diese beiden Punkte die Ursache Deines Problems sind.
Ach sieh an. Gerade ist wieder ein Firmware-Update herausgekommen. Und siehste: "POM CV lesen und schreiben verbessert". Das ist z. B. beim letzten Update dazugekommen, lief aber noch nicht sauber. Da bin ich ja mal gespannt. Das ist übrigens typisch (aber nicht nur) ZIMO. Es kommt regelmäßig neues, aber oftmals noch nicht gleich fehlerfrei. Aber ich kann den Jungs das verzeihen. Dafür kommt eben immer wieder was neues. Was hat mal jemand geschrieben: Von Nerds für Nerds. Von mir aus...
@Ludwig: Du musst nicht von Österreichisch übersetzen, sonder von "Zieglerisch" ... dessen BAs muss auch ich mehrmals lesen, um zu durchschauen, was nun wirklich gemeint ist ;) @Thosten: Im Grund wäre es so einfach: wenn eine bestimmte Bedingung zutrifft, gibt es ein bestimmtes Ergebnis.... ABER: Meist trifft nicht nur eine Bedingung zu, oft ergänzen oder widersprechen sich Bedingungen, manchmal wird auch im Programmcode ein Fehler "eingebaut" ... und manchmal passiert was, was nicht passieren dürfte - keiner weis warum, nirgends gibt es einen plausiblen Grund, alle Bedingungen schauen korrekt aus, selbst alle Parameter im Programm sind richtig gesetzt und die nötigen Routinen werken korrekt nur am Ende kommt was falsches raus ... und 2 Stunden später, unter den gleichen Bedingungen funktioniert die Sache ... und wieder sind alle ratlos ... und der Fehler ist nie mehr nachstellbar, tritt auch nie mehr auf (zumindest nicht in dieser SW-Version). DAS sind dann die "spannenden" Momente ...
Passt vielleicht nicht ganz hier rein, ich frage trotzdem. Wie kann ich den Z1 Zufallsgenerator überreden seine Funktion aufzunehemen? Hab schon alles was in meinen Fähigkeiten liegt versucht, aber der Zufallsound schweigt. Auf Z1 liegt die Luftpumpe, per F-Taste kann ich den Sound auch auslösen, aber von selbst kommt er nicht. Was müßte ich euch dazu noch mitteilen? Ich kann CV`s lesen und schreiben, hab aber keinen ZIMO-Programmer.
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Digitaltechnik
»
Zimo MX645 Sound gelöscht
Thema drucken
24.11.2016 21:22 (zuletzt bearbeitet: 24.11.2016 21:25)
Antworten
