Beiträge von Torsten Lang

    Zitat von driethenauer

    die neue PC-Diskusion entstand wegen de einen Satzes von Herrn Kosa.
    Eine weitere Erklärung gabe es ja bisher nicht.


    Leider gibt es auch einige (schlecht informierte) Modellbahn "Fachzeitschriften", die das Gerücht verbreitet hatten, der Commander hätte eine PC-Anbindung z. B. zur Darstellung/Bedienung des Stellpultes (MIBA).


    Gruß,
    Torsten

    Hallo zusammen,
    obwohl Spur N Fahrer fehlt auch mir die volle DCC Funktionsunterstützung! Bei den aktuellen Spur N Soundloks geht die Funktionsliste nämlich auch bis weit über F12 hinaus!


    Viele Grüße,
    Torsten

    Hallo Raimund,
    heißt das, Du hast zusätzlich zum Decoder den Sender in der Lok? Überleg mal: Beim Auslesen hast Du dann zwei Decoder, die auf die Abfrage antworten. Das kann so nicht funktionieren! Bei Tams (FD-R Basic) ist es m. W. so, daß er als RailCom Sender Schattenregister führt, d. h. wenn Du Werte programmierst speichert er diese ab, statt seine eigenen Funktionen umzuprogrammieren. Wenn Du natürlich Werte programmierst, die der Original-Decoder nicht "verdaut", wie z. B. "RailCom an", dann wird beim Auslesen der Lokdecoder mit "RailCom aus" antworten (er unterstützt es ja nicht) und der RailCom-Sender mit "RailCom an", d. h. Du bekommst beim Auslesen "Datensalat".


    Also:


    Im Service-Mode (Programmiergleis) wird das Rücklesen nur dann plausible Werte liefern, wenn beider Decoder "einer Meinung sind", sprich dieselben Daten liefern. Wenn Du auf dem Programmiergleis gezielt CVs auslesen willst, mußt Du den nicht benötigten Decoder abklemmen! Das ist halt der Nachteil der Nachrüst-Lösung.


    Im POM-Modus (via RailCom) kann der Lokdecoder überhaupt nicht antworten, hier müßtest Du ausschließlich das rücklesen, was der RailCom-Sender gespeichert hat. Das muß logischerweise aber nicht konsistent mit der Programmierung des Lokdecoders sein.


    Viele Grüße,
    Torsten


    P. S. Grundsätzlich hast Du solche Probleme auch, wenn Du mehrere Decoder (z. B. Lokdecoder und Funktionsdecoder) in ein Fahrzeug einbaust, da es dann Überlappungen bei den CVs gibt (bei z. T. unterschiedlicher Funktion).

    Hallo,
    z. Z. ist die Wunschliste leider nicht auffindbar - insofern weiß ich nicht, ob das hier schon mal geäußert wurde:


    Meines Erachtens fehlt im Commander eine Funktion, um Lokdatensätze zu duplizieren. Es kommt bei mir mittlerweile recht oft vor, daß ich für eine neue Lok die Grundparameter aus einem anderen Datensatz übernehme. Beim Commander ist das mehr als hölzern:


    • Alte Lok aufs Fahrpult
    • Von da aus in den Lokeditor
    • Neue Lok aufs Programmiergleis
    • Nun Registerkarte für Registerkarte durcharbeiten und bis auf die Adresse alles über die neue Lok überprogrammieren (1.)
    • Neue Lok vom Programmiergleis nehmen und Lokeditor verlassen
    • Neue Lok wieder auf Programmiergleis und warten, bis der Aufruf des Lokeditors angeboten wird
    • Lokeditor aufrufen und Registerkarte für Registerkarte alle Werte wieder zurücklesen (2.)
    • Lok in die Lokliste eintragen
    • Alles speichern und Lokeditor verlassen
    • Commander erstmal neustarten, weil die Software jetzt bestimmt nicht mehr korrekt läuft 3.)


    • Bei der Registerkarte mit den CVs ist hier viel Handarbeit angesagt!
    • In der Registerkarte für die Geschwindigkeitstabelle funktioniert das Rücklesen nicht (muß man über die CV-Karte machen)!
    • Nach längerer Arbeit mit dem Lokeditor stirbt die Firmware in Raten, nach dem Neustart gibt's erstmal Meldung bzgl. korrupter Daten - das muß doch endlich mal zu beheben sein! Weiterhin werden CVs >= 128 nicht korrekt gespeichert!


    Mal ehrlich, diese zeitraubende Holzhammermethode, gepaart mit den immer noch vorhandenen Speicherfehlern im Commander nervt einfach nur und kann's doch nicht sein, oder?


    Viele Grüße,
    Torsten

    Zitat von driethenauer

    Hallo,


    doch nochmal eine Idee.
    Für die Waggons gibt es bspw. bei Flesichmann extra Lämpchen
    für Betrieb mit DC und digital, die haben glaube ich 21 V.


    Hallo,
    ich kaufe mir die Lämpchen allerdings nicht beim MoBa-Hersteller, weil meist viel zu teuer, sondern beim Elektronik-Versender (immer noch teuer). Die Miniaturlämchen gibt es ganz selten mal mit 19V, meist nur mit 24V. Da ich nicht glaube, daß sich Fleischmann und Trix ihre Lampen speziell fertigen lassen, gehe ich mal davon aus, daß die Austauschlampen für Digitalbetrieb ebenfalls 24V-Typen sind (ich habe bisher jedenfalls nie eine Spezifikation gesehen). An sich ist das kein Drama, bei analog werden meist 14V-Lampen verwendet und die Züge fahren meist nicht mit voller Spannung (12V), sondern bei deutlich niedrigeren Spannungen.


    Was mich übrigens sehr wundert ist, daß noch kein einziger Anbieter von Leuchtmitteln auf die Idee gekommen ist, die gängigen Bauformen von Miniaturlampen für Spur N als LED-Lampen mit integriertem Gleichrichter und Vorwiderstand (oder besser noch Konstantstromquelle) anzubieten. Für den Hobbyisten ist das nicht realisierbar, in Stückzahlen sollte das aber eigentlich kein Thema sein, wenn ich sehe, daß z. B. Trix die LED-Chips ungehäust auf die Platinen bondet oder mir die Sonderbauformen bei den Formsignalen bei Viessmann anschaue. Und für H0 (E10 Lämpchen) gibt's das auch...


    Bei Fleischmann gibt es Austauschlampen auch offiziell, Trix sieht seine Leuchtstäbe wohl eher als Wegwerfware - die Lampen sind eingelötet und nur mit viel Fummelei tauschbar, der Lampentausch wird nicht beschrieben. Trotzdem habe ich den Austausch durchgeführt.


    Was LED-Beleuchtung für Spur N angeht, da werde ich wohl demnächst was Eigenes designen. Mich stört einfach nur noch, daß der Markt uns Spur N Fahrer völlig ignoriert. Natürlich kann ich Spur H0 Beleuchtungen absägen, aber das ist einfach unwirtschaftlich.


    Ich weiß nicht, wie es bei den LED-Beleuchtungen von Viessmann aussieht, da das Seitenlayout momentan so kaputt ist, daß ich die Produkte nicht angezeigt bekomme (s. Threads zum Thema (sinngemäß) "Forum weg").


    Mit freundlichen Grüßen,
    Torsten Lang

    Zitat von pierre.bln

    Hallo Otto,


    Stimmt danke!
    Aber wie gesagt, ich finde es persönlich sehr versteckt (ein Forum ist für mich keinen "Service", aber vieilleicht ist es auch anders gesehen in Deutschland :D ). ...


    Hallo,
    da kann ich nur zustimmen. In der Navigationsleiste links wurde das Forum einfach vergessen, es taucht nur rechts auf, wo die Punkte auf der Service-Startseite nochmals aufgelistet werden.


    Der Bereich "Service" sollte m. E. nochmal etwas überarbeitet werden. Kundendienst listet die Kontaktinfo per Telefon & EMail, Kontakt nur die per Formular auf, das gehört m. E. zusammengeführt. Und daß AGB und Impressum ganz klein rechts oben in der Ecke versteckt sind, ist ebenfalls nicht sonderlich übersichtlich.


    Folgende Vorschläge meinerseits (wenn das CMS mitspielt):

    • Die "Fähnchen" zur Sprachumschaltung aus der Kopfzeile rausziehen und an erster Stelle bei der Navigation einblenden (wenn auch Grafik geht).
    • "Sitemap" sollte ebenfalls in die Navigationsleiste verfrachtet werden.
    • Die AGB interessieren nur Kunden beim Direktverkauf, gehören also am ehesten in den Shop.
    • Das Impressum würde ich ans Ende der Navigation legen.
    • Die Seite skaliert leider in der Breite nicht, was nicht schön ist (einfach nicht mehr zeitgemäß).


    Zur Erklärung: Der Platz in der Kopfzeile wird ständig mitgeschleppt, wird im Grunde aber nur ganz selten gebraucht (Sprachauswahl beim Start). Immer mehr Anwender verwenden 16:10 oder gar 16:9 Bildschirme (ich ebenfalls), daher finde ich es schon störend, wenn nicht gerade unerheblich Platz mit (Quasi-)Zierelementen verschwendet wird. Und daß die Darstellung beim Aufziehen rechts und links nur weißen Rand liefert wirkt einfach wenig professionell.


    Bei aller Kritik: Das neue Design ist schon schick und gefällt mir.


    Unter MacOS/Safari ist die neue Seite aber leider unbrauchbar (sorry, es ist so!):

    • Ganz schlimm: in den einzelnen Rubriken bei den Produkten wird immer nur das erste Produkt, und auch das immer nur zur Hälfte, angezeigt. Leute, da ist irgendwo ein kapitaler Fehler im Layout oder den Styles! Das muß jedenfalls unbedingt abgestellt werden.
    • Es hagelt immer wieder Dialogboxen mit "Datenübertragungsfehler".


    Gruß,
    Torsten

    Zitat von MuggelClan

    Hallo Thomas,


    21V kann ich gar nicht glauben. :o
    Kann es sein, das es sich um ein Schreibfehler handelt?
    Ich glaube eher das ist ein Zahlendreher - 12V statt 21V


    Also, bei den Beleuchtungen schreibt Trix sogar digital 22V (!) auf die Schachtel - allerdings ist das insofern totaler Quatsch, da die Innenbeleuchtungen keinerlei Elektronik haben und die 12V-Glühbirnen dann fast die vierfache Leistung verbraten. Die Waggons sind dann gleißend hell beleuchtet und werden so heiß, daß akute Gefahr für das Modell besteht.


    Ansonsten bin ich mir auch nicht ganz im klaren, was ich nun glauben soll. Fakt ist: Bei der NEM651-Schnittstelle wurde ein dedizierter Decoder VCC (+) Anschluß schlicht vergessen. Das DCC-Signal ist aber nun mal eine Rechteck-Spannung mit einem mittleren Pegel von 0V (für den Betrieb eines einzelnen analogen Fahrzeugs zusammen mit digitalen Fahrzeugen kann dieser Pegel geshiftet werden, was wohl nicht ganz unproblematisch ist). Sind nun Birnchen einfach gegen eines der Schienenpotentiale geschaltet, dann liegt der Duty-Cycle maximal bei 50% (da der Decoder gegen seine Masse schaltet, die letztlich je nach aktueller Polarität der Gleisspannung mal links, mal rechts liegt). Mit der Erhöhung der Spannung von 12V auf 18V verdoppelt sich aber wiederum ungefähr die Leistung, d. h. im Mittel bekommen die Birnen dann die volle Leistung ab. Das gilt natürlich nicht für direkt angeschlossene Dauerbeleuchtung, z. B. in Waggons. Hier müssen die Birnchen gegen entsprechend spannungsfeste ausgetauscht werden.


    Kurz und gut: Da ich keine Lust habe, die Spitzen-/Schlußbeleuchtung überall umzubauen (ich habe bisher nur wenige Fahrzeuge, bei denen das Beleuchtungs-Plus über eine Diodenschaltung auf beide Schienen geführt wird), habe ich mich entschieden, mit 18V zu fahren und bei Loks die Beleuchtung bei 12V Verbrauchern zu belassen und bei Waggons entsprechend umzurüsten.


    Die Alternative wäre gewesen, die Gleisspannung auf 13,5V zu senken und in den Loks die Birnchen gegen 6V-Typen zu tauschen (so man sie bekommt!).


    Übrigens habe ich bei einigen älteren Fleischmann Decodern bei geringerer Gleisspannung tatsächlich Probleme gehabt (unzuverlässige Decodierung), aber das bleibt sicherlich die Ausnahme...


    Viele Grüße,
    Torsten

    Hallo zusammen,
    ich habe mittlerweile unter "Dieselloks+Triebwagen" 25 Einträge stehen. Versuche ich nun, einen 26. am Ende einzutragen, klappt das nicht. Stattdessen erscheinen am Ende der Liste (nach einer Lücke von mehreren Einträgen) plötzlich willkürlich Lokbilder und wirre Texte. Gehe ich danach im Fahrpult in die betreffende Liste, wird wild der Bildschirm "übermalt". Insgesamt finde ich dieses Verhalten etwas beängstigend. Kann das jemand bestätigen?


    Viele Grüße,
    Torsten


    Moin moin,
    - "Daten korrupt" hatte ich bisher nicht mehr. Bei der alten Version war das allerdings durchaus nicht ohne Relevanz, sondern es waren dann immer die Einstellungen der Funktionen weg (d. h. nach Wiederherstellen alle Lichter aus etc.).
    - Ja, kann ich bestätigen. Tritt bei mir bei der Arbeit im Lokeditor auf. Wobei dann auch gelegentlich Loks verschwinden oder falsch einsortiert werden (in der Datenbank selbst sind sie aber OK, es geht nur um die Zuweisung zu den verschiedenen Rubriken Dampfloks/E-Loks/... für den Fahrtregler). Einmal aus- und wieder einschalten hilft dann.


    Gruß,
    Torsten


    Hallo Rick,
    also, passive Verteiler gibt es bei USB schlicht und einfach nicht. Das Teil ist ein "bus-powered Hub", bezieht seine Energie also aus der Schnittstelle. Was aber kein Problem ist, da der Commander nur geringen Strombedarf anmeldet. Und wie gesagt, es funktioniert ja überhaupt erst halbwegs, wenn dieser Hub angeschlossen ist.


    Neee - aufgrund der Probleme bei vielen Benutzern tippe ich da eher auf ein systematisches Problem (vielleicht ja nur bei älteren Geräten).


    Gruß,
    Torsten

    Hallo Herr Meier,
    erstmal vielen Dank für das sehr ausführliche und informative Gespräch an der Hotline - vor allem beruhigen mich die Informationen deutlich, wenn es doch mal wieder hakeln sollte.


    Für mich war das Update eine ziemliche Zitterpartie, weil es auf der einen Seite (Update-Software) eben nicht weiterging und die Update-Meldung ("Unterbrechen Sie ... in keinem Fall die Stromversorgung") in diesem Fall doch etwas Angst macht.


    Übrigens hat alles Spielen an den Einstellungen des Treibers letztlich das Problem nur geringfügig entschärft. Zumindest bei meinem Notebook habe ich das Problem deutlich entschärfen können, indem ich noch einen USB-Hub zwischengeschaltet habe.


    Ganz weg ist es leider immer noch nicht. Ich war mal so mutig und habe das Update nochmal gestartet. Immerhin hat es jetzt nur relativ wenige Verbindungabbrüche gegeben.


    Insofern werde ich den Commander demnächst mal zum durchchecken reinreichen...


    Viele Grüße,
    Torsten Lang

    Zitat von Rick

    @Torsten:
    Kannst Du probeweise einen anderen Rechner verwenden?


    Hatte ich auch schon - da wurde der Commander aber überhaupt nicht erkannt.


    Was den Verdacht von Achim angeht:

    Zitat

    Wird jedoch die Schnittstellennummer jenseits der tatsächlich möglichen Schnittstellen definiert, wird nach emulieren die Schnittstelle diese als virtuelle Schnittstelle vom BS erkannt und die Erkennung nicht mehr durchgeführt.


    Die serielle Emulation läßt sich zumindest beim aktuellen Treiber 2.4.16 ganz abschalten - dazu die Eigenschaften des Gerätes "USB Serial Converter" unter "USB-Controller" aufrufen, Reiter "Erweitert", Kasten "VCP laden" ("VCP" = "virtual COM port", denke ich).


    Nur: Nutzen tut das bei meinem Commander alles nichts. Sobald die ersten Daten übertragen wurden, wird der Commander bzw. der Schnittstellenbaustein nicht mehr korrekt erkannt.


    Wie schon mal angesprochen - mich würde mal interessieren, was bei anderen, die diese Probleme mit Verbindungsabbrüchen beim Flashen oder beim Backup haben, so passiert (speziell das Protokoll der Backup-Software, da es ein wenig mehr enthält als die magere Info des Flashprotokolls (im Fehlerfalle Startzeit/Endezeit).


    So sieht das übrigens aus, wenn er wenigstens mal mit dem Backup anfängt:


    Gibt es denn niemanden außer mir, der solche Probleme hat?


    Gruß,
    Torsten

    Hallo Achim,
    klingt interessant. Ich bin mir aber nicht sicher, ob das das eigentliche Problem ist: Oft genug wird der FT232R im Commander erkannt, allerdings offenbar die EEPROM-Daten nicht korrekt gelesen. Beim Backup zeigt sich das dann an der fehlenden Seriennummer und der Kennung FT_DEVICE_UNKNOWN (statt FT_DEVICE_232R oder so ähnlich). Auch das FTDI EEPROM-Tool FT_Prog erkennt den Baustein dann nicht.


    Mich würde mal interessieren, ob diese Effekte bei anderen Benutzern, die Probleme mit Abbrüchen haben, gleich ist. Falls nicht und falls ich der Einzige hier im Forum bin mit diesem speziellen Problem, hat der Commander möglicherweise ein Hardware-Problem.


    Gruß,
    Torsten

    Zitat

    Hallo Torsten,
    bei mir funktionierte das Update und auch das Backup immer. Beim Backup gibt es ja 2 Möglichkeiten, einmal hat der Button der Zusatz "DLL" und einmal nicht. Beim Anklicken des Buttons ohne DLL kommt folgendes kurzes Protokoll zustande:


    Moin moin,
    ich bin etwas verwirrt - bei mir gibt es nur genau einen Button "Datensicherung starten". Was für eine Version verwendest Du denn? Ich dachte, ich hätte die neueste (V1.010)...


    Gruß,
    Torsten

    Zitat

    tt-driver:
    das Problem trat bei mir auch beim letzen Update auf, Abhilfe schafft ein Neustart nur des PC mit anschließender Kontrolle der Schnittstellenparameter. Der PC muss aber richtig ausgeschaltet sein und ca. 2 min warten vor Neustart, ein Warmstart hilft hier nicht.
    Die Parametereinstellung im Pc habe ich im Forum im Beitrag vom 05.04.2009 erläutert, damit hat es dann problemlos funktioniert.


    Viel Erfolg beim Testen


    Ich habe mir Deinen Beitrag mal rausgesucht, damit man nicht lange suchen muß hier nochmal die Kopie:

    Zitat

    Die Übertragung brach jedoch auch hier mehrmals zusammen, die Fehlerursache dafür sind die Datentransfer-Einstellungen der Schnittstelle. Dazu bei angeschlossenem Commander über die Systemsteuerung, System, Hardware, Geräte Manager, Anschlüsse Com/LPT, den gefundenen Com Port auswählen, dann über Eigenschaften die Anschlusseinstellungen öffnen, dort in der Com-Nr. auf 15 setzen, die Time Out Zeit auf 1 ms einstellen und die Paketgröße beim Senden und Empfangen auf 2048 reduzieren, die Anzahl der Max. Time Out im Senden und Empfangen auf 100, anschließend alles speichern und neu starten, mit diesen Daten ist das Update problemlos durchgelaufen und war bei mir innerhalb von 25 min erfolgreich beendet. Eine Fehlermeldung über Time Out im Protokoll ist unbedeutend, das Zurückspielen der gemachten Backup-Datei funktionierte ebenfalls problemlos. Auf dem Notebook ist Win XP Prof., auf dem Desktop-Rechner XP-Home, beide SP2.


    Damit läßt sich das Update starten, allerdings ist es auch alles andere als stabil! mitten im größten Block (Programmiere Controller 3/3) ging der Zinnober wieder los. Ich hoffe, daß ich das Update innerhalb der nächsten Stunden stückchenweise fertigbekomme, ansonsten ist der Commander wirklich reif für den Service!

    Da weiß ich selber auch drum, da ich z. Z. beruflich viel mit Emulatoren und CAN-Hardware am USB arbeite. Nicht nur zu lange, sondern auch schlechte Kabel, USB-Hubs und I/O-Boxen machen da oft genug Ärger.


    Ich habe aber das orginale Kabel (1,8m) im Einsatz - wie gesagt, bei den voherigen Updates gab es keinerlei Probleme! Und der USB-Port ist direkt am Mainboard. Mit dem anderen Port ging es übrigens genausowenig.


    Für das nächste Update muß hier jedenfalls dringend die Ursache für die eklatanten Probleme gefunden werden und vor allem eine Lösung her! Und sei es als temporäre Lösung nur, daß Viessmann klare Aussagen macht, welche Treiberversionen und Einstellungen unterstützt werden. Mittelfritig muß aber die Ursache behoben werden - es gibt genügend Anwendungen, die die FTDI-Chips verwenden und solche Probleme nicht haben!


    Nachtrag: Das Update ist endlich drauf - ich habe hier gut zwei Stunden Blut und Wasser geschwitzt (und nebenbei angefangen, diesen Beitrag zu schreiben)!


    Lokbildeditor und Backup funktionieren allerdings nach wie vor nicht - der Commander wird einfach nicht erkannt. Das Backup-Tool gibt immerhin ein paar Log-Informationen aus, mich würde mal interessieren, wie das bei jemandem aussieht, wo das Backup funktioniert:


    Viele Grüße,
    Torsten

    Moin moin,
    Function Mapping ist ja schön und gut, wenn insgesamt maximal 12 Funktionen zu bedienen sind. Ich habe kürzlich noch ein Exemplar des Athearn Big Boy in 1:160 ergattert, da sind es glaube ich so an die 30 Funktionen. Mit dem Commander keine Chance.


    Wäre damit auch was für die Wunschliste...


    MfG
    Torsten

    Hallo,
    erstmal vorweg - dieses hier war nicht das erste Update. Ich habe den Commander mit einer steinalten SW erhalten und dann mit der Reorganisation des Flashes (Version 1.018) angefangen jedes Update mitgemacht. Bisher immer ohne Probleme.


    Das System ist ein Windows XP Pro / SP3 mit .net 2.0 und FTDI 2.4.6 und läuft auf einem Core 2 Duo Macbook Pro (keine VM, sondern nativ). Klar ist natürlich, daß die Energiesparoptionen ausgeschaltet sind.


    Da der Rechner normalerweise nicht im Internet unterwegs ist (ist mir mit Windows viel zu gefährlich) ist das System nicht auf dem neuesten Stand, sondern tatsächlich genau das, mit dem ich schon die vorherigen Updates gemacht habe. Wie in meinem Hilferuf (s. Link) schon drinsteht, ist auch der FTDI-Treiber der aktuelle von der Viessmann-Seite.


    Damit ist auch klar, daß bisher die Version 1.042 drauf ist.


    Viessmann selbst schreibt ja, daß beim Fehlschlagen von Updates das Gerät keinesfalls ausgeschaltet, sondern das Update nochmal durchgeführt werden soll. Aber wie denn bitte, wenn sich die Software einfach weigert???


    Meine einzige Hoffnung wäre ein zweiter funktionsfähiger Commander, mit dem man die Update-SW dazu bringen könnte, erstmal die Programmierung überhaupt anzubieten, und dann umzustecken und es nochmal zu versuchen.


    Gruß,
    Torsten