[Solved]DDX mit TAMS WD-34 unzuverlässig - Lösung?

cds
Moderator
Posts: 5041
Joined: 03.02.2012, 19:24
Location: Tullnerbach, Austria

[Solved]DDX mit TAMS WD-34 unzuverlässig - Lösung?

Post by cds » 12.02.2012, 17:03

Hallo Rocrail!

Ich bin neu hier und stelle mich kurz vor:
Mein Name ist Claus und lebe in Wien. Ich besitze seit Kindestagen eine Märklin-MEB, die über die Jahre oft vernachlässigt, aber doch gewachsen ist. Vor etwa 5 Jahren habe ich die Digitalisierung begonnen und habe mittlerweile 7 digitale Loks (3 Stk. mit Decoder gekauft, 4 Stk. selbst umgebaut). Da ich keinen Platz für eine stationäre MEB habe, bin ich gezwungenermaßen leidenschaftlicher (allerdings nur in den Wintermonaten) "Teppich"bahner.

Meine Konfiguration:
Märklin M-Gleis
Control Unit 6021 (nur für Register-Programmierung)
Booster TAMS B-2
DDX (DCC, MM, MMA, MMLP)
1 Stk. S88N von Littfinski
1 Stk. S88-3 von TAMS
3 Stk. TAMS WD-34 Magnetartikeldecoder (MAD)
1 Stk. VIESSMANN 52111 MAD
Booster via RS232 an PC
S88 via Parallel-SS an PC

Das Fahren mit Control Unit hat mich nie begeistert, das manuelle, analoge Schalten dazu auch nicht. Daher habe ich immer mit der Steuerung der MEB mit dem PC geliebäugelt. Letzten Herbst habe ich Rocrail entdeckt, Homepage und Forum studiert und bis Weihnachten 2011 im Geiste geplant. Dann war es soweit: Ein Alt-PC (Celeron, 2,8 MHz, 1 GB RAM) musste her und war rasch mit Rocrail-SW installiert. Viele, viele Stunden Studium und Probieren (Testkreise, etc.) habe ich hinter mir. Kurz: Es läuft soweit alles fein!

Daher an dieser Stelle ein dickes LOB an Rocrail! Ist echt begeisternd!

Dennoch habe ich ein Problem, das ich hier gerne vorstellen und diskutieren möchte:
Ich habe TAMS WD-34 MAD im Einsatz (mit externem Schaltstrom). Diese lassen sich sauber programmieren, schalten aber unzuverlässig. Oftmals "vergessen" die MAD manchmal zu schalten, bzw. schalten nur in eine Richtung zuverlässig. Dieses Verhalten ist im Automatikbetrieb äußerst störend, weil unnötige Unfälle provoziert werden. Der MAD ist definitiv richtig konfiguriert. Es schalten alle Ports, aber eben unzuverlässig (mit und ohne MMLP). Interessant ist auch, dass nach dem Einschalten des Systems erst mal keine Weiche schaltet (egal ob via Layout oder Weichensteuerung). Erst nach einigem Schalten aller Ports werden auch Weichen geschaltet; der MAD muss sozusagen "warm" gefahren werden.
(BTW: der Viessmann-Decoder ist an dieser Stelle robuster, er schaltet zuverlässig. Noch eine Information: Einen Littfinski S-DEC-4-MM MAD habe ich nicht zum Laufen gebracht, das Lernen der Adresse hat mit keiner (!) der vielen Möglichkeiten funktioniert.)

Zuerst dachte ich, dass der Mischbetrieb DCC/MM die Ursache wäre. Ich fahre und schalte rein mit MM-Format (DCC, MM, MMA in der Server-Konfig angekreuzt), bidirektionale Kommunikation ist ausgeschaltet. Obwohl ich DCC nicht verwende, muss ich es eingeschaltet lassen, da sonst die Prozessor-Last auf nahezu 100% ansteigt und Rocrail im Automatik-Betrieb mit dem Schalten und Anzeigen der Aktionen nicht mehr rechtzeitig nachkommt. Sobald ich DCC wieder einschalte, liegt die CPU-Last bei ca. 50% und alles läuft fein. Aber auch wenn DCC ausgeschaltet ist, arbeiten die WD-34 nicht stabil und zuverlässig.

Das Wegwerfen der TAMS WD-34 ist für mich keine Option, dazu habe ich viel Zeit in den Bau investiert.

Der Threads "DDX-Blacklist: Tams WD-34" und "SOLVED -- ddx, tams wd-34 problems with turnouts/switches" haben mich auch nicht weiter gebracht.

Wer weiß Rat?
Gibt es schon eine Lösung für das Problem der hohen CPU-Last, wenn DCC ausgeschaltet ist?

Beste Grüße
Claus

EDIT:
Ich habe erneut intensiv getestet und folgendes festgestellt:
Wenn DCC aus- und MM/MMA/MMLP eingeschaltet ist, arbeitet der WD-34 zuverlässig.
Wenn DCC/MMLP aus- und MM/MMA eingeschaltet ist, arbeitet der WD-34 nicht zuverlässig.
Wenn MMLP aus- und DCC/MM/MMA eingeschaltet ist, arbeitet der WD-34 nicht zuverlässig.
Wenn DCC/MM/MMA/MMLP eingeschaltet ist, arbeitet der WD-34 nicht zuverlässig.
Ich schließe daraus, dass dem WD-34 der Protokoll-Mix missfällt.

Die Lösung wäre somit (für mich und ggfs. auch für andere), wenn die CPU-Last ohne DCC normal wäre. Das Problem ist auch an anderer Stelle im Forum bereits diskutiert worden, eine Lösung gibt es aber dazu nicht.

Beste Grüße
Claus
Last edited by cds on 17.06.2012, 19:40, edited 1 time in total.

Schorse
Posts: 4972
Joined: 12.09.2008, 19:38
Location: D - Niedersachsen

Post by Schorse » 13.02.2012, 11:10

Hallo Claus,

willkommen im Forum.
Zu Deinem Problem:
Ich habe TAMS WD-34 MAD im Einsatz (mit externem Schaltstrom)
Grundsätzlich sollte geklärt werden, ob der Decoder die Ausgänge nicht schaltet oder ob nur die Weichen nicht schalten. Deiner Beschreibung nach habe ich den Eindruck, das die Schaltspannung für die Weichen zu gering ist.
Hast Du eine externe Wechselspannung angeschlossen wie in der Anleitung beschrieben?

Gruß Gerd

norbert
Posts: 121
Joined: 29.11.2008, 14:01
Location: Chemnitz
Contact:

Post by norbert » 13.02.2012, 12:19

Hallo

Hatte ebenfalls Probleme mit dem WD 34.
Es lag jedoch nicht an den Dekodern sondern an DDL/DDW. Mit DDX von Rocrail hatte ich zu diesem Zeitpunkt noch nicht experimentiert.
Ansteuern der WD 34 mit Motorola Protokoll war jedoch fehlerfrei möglich.

hier noch ein paar Details:
http://home.chemonline.de/c1022802/modellbahn4.htm

Mit der Inbetriebnahme der TAMS MasterControl war dann auch DCC für den WD 34 ok. Nutze den TAMS Booster B3, aber den auch bereits seit meiner DDW Ära.

Viel Erfolg
Gruß Norbert

HDW_64625
Posts: 1105
Joined: 14.01.2011, 09:46
Location: Bensheim

Post by HDW_64625 » 13.02.2012, 13:13

Hallo Claus,

wir (Lukas und ich) haben Weichendecoder von Railway-Lauf im Einsatz, diese zeigen ähnliche Probleme bei DDX wie Du sie beschreibst.
Schau mal in diesen Thread, hier beschreibt RainerK doch sehr detailliert warum es mit DDX zu Problemen kommen kann:

http://forum.rocrail.net/viewtopic.php? ... c&start=45
das Problem bei DDX ist durch das Prinzip der seriellen Schnittstelle beim PC begründet.
Die PC-Hardware der COM-Schnittstellen kann nur die Standard-Bitraten für Datenverkehr erzeugen.

Der Trick bei DDX und auch bei den zugrunde liegenden DDL/DDW-Treibern ist es,
mit den Standard-Bitraten 19200Bit/s bei DCC und 38400Bit/s bei MM sowie geschickten Datenbit-Kombinationen
den normgerechten DCC- u. MM-Bitraten und Daten möglichst nahe zu kommen.

Prinzipbedingt gelingt das natürlich nicht zu 100%.

Bei DCC wird "nur" ein Wert erreicht, der der unteren Toleranzgrenze der NMRA-Norm entspricht.
Bei MM weiß ich die Werte nicht genau, aber erinnere mich, dass es noch kritischer sein soll.

So hängt es also von der Toleranz-"Bereitschaft" von µC-Takt und Firmware der Dekoder ab,
wie gut sie - wenn überhaubt - auf die Daten reagieren.

Bei Hardware-Zentralen gibt es das Problem selbverständlich nicht,
weil Taktraten und Firmware für DCC, MM usw. optimiert sind.
Es löst dein Problem natürlich nicht, aber vielleicht spart es Dir einige Zeit mit weiterer erfolgloser Fehlersuche. Unsere Konsequenz ist es jedenfalls in nächster Zukunft eine OpenDCC-Zentrale einzusetzen.

Gruß aus Bensheim

Holger

cds
Moderator
Posts: 5041
Joined: 03.02.2012, 19:24
Location: Tullnerbach, Austria

Post by cds » 13.02.2012, 14:05

Hallo Rocrail!

Herzlichen Dank für die zahlreichen Rückmeldungen!

@Schorse:
Ja, ich habe eine externe Wechselspannung angeschlossen (siehe mein Posting "Ich habe TAMS WD-34 MAD im Einsatz (mit externem Schaltstrom)").
Ich vergaß allerdings anzuführen, dass ich das gleiche Verhalten statt mit Weichen auch mit angeschlossenen Lämpchen habe.

@Norbert:
So ist es! Du beschreibst das analoge Verhalten für DCC wie ich es mit MM habe. Allerdings habe ich statt MM mal DCC getestet und es ging gar nichts!

@HDW_64625:
Uff, danke! Das muss ich erst mal verdauen ...
Jedenfalls kann ich die Tests einstellen.

----

Schade, denn die WD-34 funktionieren ja astrein, sobald man das DCC-Protokoll der ddx ausschaltet. Allerdings handelt man sich damit eine konstante CPU-Last von 96% und mehr ein, was eine Bedienung von Rocview sehr langsam macht und einen Automatikbetrieb verunmöglicht.

Wo ist der Unterschied des PIC auf dem WD-34 zu dem MM-Controller-Chip auf einem 5211? Dieser funktioniert klaglos. Allerdings ist dieser MAD schon einige Jahre alt und so nicht mehr erhältlich. Der PIC auf dem WD-34 kann MM, DCC und diverse andere Dinge, ist aber vmtl. bzgl. MM-Protokoll nicht so tolerant wie der 5211-Controller.

Nun, was bleibt mir für eine Wahl?
1) WD-34 wegwerfen und auf andere MAD umsteigen.
2) Danke sagen und MEB wieder in den Schrank räumen )-:
3) Geld investieren und eine HW-Zentrale einsetzen.

Schade!

Beste Grüße
Claus

rjversluis
Site Admin
Posts: 39306
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 13.02.2012, 14:14

Hallo Claus,
cds wrote: Schade, denn die WD-34 funktionieren ja astrein, sobald man das DCC-Protokoll der ddx ausschaltet. Allerdings handelt man sich damit eine konstante CPU-Last von 96% und mehr ein, was eine Bedienung von Rocview sehr langsam macht und einen Automatikbetrieb verunmöglicht.
Unter Windows ist das leider so wegen fehlende hochauflösende Timers.

HDW_64625
Posts: 1105
Joined: 14.01.2011, 09:46
Location: Bensheim

Post by HDW_64625 » 13.02.2012, 14:20

Hallo Claus,
cds wrote:Nun, was bleibt mir für eine Wahl?
1) WD-34 wegwerfen und auf andere MAD umsteigen.
2) Danke sagen und MEB wieder in den Schrank räumen )-:
3) Geld investieren und eine HW-Zentrale einsetzen.
1) Nein - warum?
2) auf keinen Fall - die Entzugserscheinungen sind schlimmer :wink:
3) Das wird wohl die Lösung sein :(

Ich habe es im Prinzip erst einmal dadurch gelöst, dass ich ESU Switch-Piloten einsetze, ist allerdings auch eine sehr teure Lösung im Vergleich zu den Railway-Lauf Modulen!

Gruß Holger

LDG
Site Admin
Posts: 2624
Joined: 18.10.2010, 00:03
Location: near Karlsruhe/Germany

Post by LDG » 13.02.2012, 14:21

Hallo Claus
cds wrote:Nun, was bleibt mir für eine Wahl?
1) WD-34 wegwerfen und auf andere MAD umsteigen.
2) Danke sagen und MEB wieder in den Schrank räumen )-:
3) Geld investieren und eine HW-Zentrale einsetzen.

Schade!
1) bitte in meine Richtung werfen :mrgreen: :mrgreen: :mrgreen:
2) Auf gar keinen Fall :shock:
3) Wenn Du MM und/oder mfx brauchst dann empfehle ich eine TamsMC (ab ca. 180€) sonst (DCC only) CanGC.

Gruß,
Lothar

Schorse
Posts: 4972
Joined: 12.09.2008, 19:38
Location: D - Niedersachsen

Post by Schorse » 13.02.2012, 23:03

Hallo Claus,
3) Geld investieren und eine HW-Zentrale einsetzen.
wer einen kleinen Geldbeutel hat und mit einigen Einschränkungen leben kann, sollte sich mal diese Zentrale ansehen:http://wiki.rocrail.net/doku.php?id=mdr ... 4992466a7c
oder in Englisch:http://wiki.rocrail.net/doku.php?id=mdrrc-en

Gruß Gerd

cds
Moderator
Posts: 5041
Joined: 03.02.2012, 19:24
Location: Tullnerbach, Austria

Post by cds » 14.02.2012, 08:03

Hallo Rocrail!

Danke für die Anteilnahme :) und die zahlreichen Tipps!

Ich habe gestern einen anderen PC zum Einsatz gebracht; ein altes Core 2 Duo, 1,66 MHz, 1 GB RAM Notebook mit WinXP SP3.
Was ich dann erlebt habe, hat mich beinahe aus den Schuhen kippen lassen ...
Ich werde hier berichten. (Bitte noch um etwas Geduld, ich muss noch Tests machen, bin aber dzt. beruflich stark in Anspruch genommen.)

Beste Grüße
Claus

RainerK
Moderator
Posts: 3825
Joined: 29.04.2009, 09:31
Location: Sprockhövel (zwischen BO u. W)
Contact:

Post by RainerK » 15.02.2012, 10:23

Hallo zusammen,

ich habe 'mal den WD-34 mit "PARTIAL | only MM works" in die black/white-List aufgenommen.

Es grüßt RainerK

cds
Moderator
Posts: 5041
Joined: 03.02.2012, 19:24
Location: Tullnerbach, Austria

Post by cds » 17.02.2012, 18:58

Hallo Rocrail!

Danke an alle Interessierten für die aufgebrachte Geduld.
Es gibt Neuigkeiten!

Wie angekündigt, habe ich ein ein altes Intel Core 2 Duo, 1,66 MHz, 1 GB RAM Notebook mit WinXP SP3 angeschlossen (zuvor war ein Desktop-PC Intel Celeron, 2,6 MHz, 1 GB RAM, WinXP SP3 im Einsatz) und die Version 3259 vom 13.02. aufgespielt. DDX war DCC/MM/MMA ein, MMLP aus.
*) Nach dem "Strom ein" war S88 sofort grün -> gut!
*) Die Weichen am WD-34 schalteten sauber, satt und knackig -> das hat mich aus den Schuhen gekippt!
*) Die Weichen am 5211 schalteten, aber nicht mehr satt und zuverlässig -> ich verstehe die Welt nicht mehr
*) Bei Fahrstraßen haben einige Weichen geschaltet, andere nicht -> *grübel*
*) Bei den Loks konnte ich Licht an/aus schalten, aber gefahren sind sie nicht! -> Hilfe!

Na ja, meine Verzweiflung war groß, die Hilflosigkeit schlug schnell in Tatendrang um; Fehlersuche war angesagt.

Als erstes erkannte ich, dass Rocrail zwar Befehle an die Loks sendete, diese aber im Feld Fahrstrom immer eine "0" hatten. Das konnte nur ein Fehler in der 3259 sein. Ich habe eine alte Version eingespielt und sofort fuhren die Loks wieder.

Mittlerweile habe ich die 3268 eingespielt, die Loks fahren. Die Weichen am WD-34 schalten sauber, die Weichen am 5211 schalten so la la. S88 läuft klaglos. Das Fahrstraßenproblem habe ich durch Erhöhung der Zeit auf 750 (ms) in den Automatik-Einstellungen gelöst.
Die Loks fahren allerdings qualitativ schlechter als beim anderen PC: Verzögerungen, obwohl kein Grund dafür vorliegt, späteres Anhalten in Blöcken, einige Male sogar erst nach den Ausfahrweichen.

Bemerkenswert ist, dass die WD-34 bei ausgeschaltetem DCC gar nicht mehr schalten, beim anderen PC haben sie erst da sauber geschaltet!

Mein Problem habe ich auch mit TAMS erörtert. Hr. Tams persönlich (vermute ich) hat mir folgende Erklärung gegeben, Zitat:
---
Zum Timing: Die serielle Schnittstelle des PC erlaubt nicht die Einhaltung der Timings für das MM oder DCC-Signal. Beide Formate liegen außerhalb der Spec. Das ist der Grund, warum solche Phänomene auftreten können. Es hängt jetzt von den internen Toleranzen der Software ab, ob das Signal noch erkannt wird, oder nicht. Das ist ein schwieriges Thema, da eine zu große Toleranz dazu führen kann, dass fälschlicherweise andere Signale als normale Befehle erkannt werden.
---

Rob hat eine ähnliche Erklärung gepostet.

Offenbar hängt viel vom verwendeten PC ab. In diesem Zusammenhang möchte ich die Frage stellen, inwieweit die Einstellung der seriellen Schnittstelle einen Einfluss auf das Verhalten hat? Ich arbeite mit COM1, 9600,8,N,1, FIFO des UART 16550 auf max.
Was ist empfohlen? Finde ich das im Rocrail Wiki? Gefunden habe ich dazu nichts.

Zusammenfassend kann ich sagen, dass eine HW-Zentrale für einen zuverlässigen Betrieb offenbar die bessere Wahl ist.

Ich freue mich auf Rückmeldungen.

@RainerK: Ist die black/white list hinsichtlich WD-34 zu überdenken?

Beste Grüße
Claus

ron&bram
Posts: 2460
Joined: 11.06.2008, 19:34
Location: Heemskerk, Netherlands

Post by ron&bram » 17.02.2012, 19:14

Hallo Claus

Zum -nicht- fahren den Loks:

http://forum.rocrail.net/viewtopic.php?t=3849

RainerK
Moderator
Posts: 3825
Joined: 29.04.2009, 09:31
Location: Sprockhövel (zwischen BO u. W)
Contact:

Post by RainerK » 18.02.2012, 18:36

Hallo Claus,
cds wrote:...Ist die black/white list hinsichtlich WD-34 zu überdenken?...
in der black/white list habe ich in den Kommentar zum WD-34 die PC-Hardware-Abhängigkeit und einen Link zu diesem Faden eingefügt.

Es grüßt RainerK

cds
Moderator
Posts: 5041
Joined: 03.02.2012, 19:24
Location: Tullnerbach, Austria

Post by cds » 27.02.2012, 18:10

Hallo Rocrail!

Mittlerweile habe ich folgenden konstanten Zustand mit dem Notebook als Zentrale:
Konfiguration ddx: DCC/MM/MMA/Check Tx/Fast CV Get ein, MMLP aus
Konfiguration Automatik: Weichenschaltzeit 100, Schaltzeit für Fahrstraße 500
Die Weichen schalten alle, hin und wieder "vergisst" eine zu schalten, was in 80% der Fälle zu einem Unfall führt.
Insbesondere heißt es aufpassen, wenn nach einem Ghost-Zug der Strom weg ist und nach der Fehlerbehebung der Strom wieder eingeschaltet wird, dass auch wirklich alle Weichen richtig liegen. Offenbar treffen manchmal das "Strom weg" und der Weichenschaltbefehl zeitgleich aufeinander und der Schaltbefehl wird verschluckt.

Loks, die mit dem Desktop-PC klaglos und zuverlässig funktioniert haben, "vergessen" auf den korrekten Halt im Bf. (auf der Strecke ist es nicht so schlimm). Es kommt häufig vor, dass die Lok über das Bfs.ende hinaus fährt, obwohl der Stopbefehl vom PC exakt in der Sekunde des Überfahrens des enter2in-Rückmelders gegeben wird. Dies betrifft nahezu alle Loks, manche mehr, manche weniger. Es sínd darunter von mir umgebaute Loks mit TAMS LD-G-32, TAMS LD-W-32, aber auch eine Märklin 36845 mit Original-Decoder. Wie gesagt: Dieses Phänomen hatte ich mit dem Desktop-PC nie.

Trotz aller Unzulänglichkeiten, die - wie oben ausgeführt - auf Timing-Probleme zurückzuführen sind, macht Rocrail Riesenspaß!

Beste Grüße

Post Reply

Return to “Tams (DE)”