Fahrtrichtungswechsel kommt verzögert

[breditarms]

Moin zusammen.

Beim Testen meiner Loks auf der Anlage viel mir auf, das der Fahrtrichtungswechsel verzögert kommt, es dauert teilweise bis zu 6 Sekunden.
Ablauf:
Fahrzeug steht auf dem Gleis, Fahrtrichtung vorwärts-rückwärts wird in WDP geändert, funktioniert.
Stelle ich die Fahrtrichtung noch zwei mal um, funktionierts, beim 3 mal dauert es dann.
Gleiches Problem habe ich auch an anderen Loks festgestellt.
Parallel läuft kein anderes Fahrzeug, es stehen 16 andere Loks im gleichen Boosterabschnitt auf der Anlage, deren Licht ist an. Kein Sound, keine Schaltbefehle.
Im Fahrzeuganzeiger springt die Richtung sofort um, nur nicht der Lichtwechsel an der Lok.
Lt. Boostermanagement liegt eine Auslastung von 25 % an.

Alle Loks haben ESU-V4 bzw. V5-Decoder mit 28 Fahrstufen, Protokoll nur DCC.
Gefahren wird mit einer CS3+, geschaltet über die CC-Schnitte.
WDP hat den aktuell letzten Update erhalten.

Woran kann das liegen?

Gruß Gerhard

[Helmut Kreis]

Hallo Gerhard,

sind das Soundloks?
Ist die Erscheinung neu, oder schon immer so?

[breditarms]

Moin Helmut.

Es sind 14 Loks ohne und zwei Loks mit Sound. Die Sounds waren aber nicht eingeschaltet.
Ob das jetzt erst aufgetreten ist, kann ich gar nicht beantworten. Es ist mir zumindest erst gestern aufgefallen.

Wenn das Problem auftritt, hat man das Gefühl als ob da jemand auf der Leitung steht oder zu viele Telegramme zur Abarbeitung anstehen.
WDP und die CS3+ sind über einen Switch und Patchkabel verbunden. Daran sollte es eigentlich nicht liegen.

Gibt es eine Möglichkeit, den kompletten Nachrichtenverkehr zwischen WDP und der CS3 aufzuzeichnen?

Gruß Gerhard

[Helmut Kreis]

Hallo Gerhard,

ist die Erscheinung immer noch, oder könnte es sein, dass zur Zeit ein fremdes Update im Hintergrund lief?

[breditarms]

Moin Helmut.

Es lief kein Update im Hintergrund.
Im Anhang der Auszug vom Log heute morgen.
Um 08:58:33 begann der erste Umschaltbefehl, 08:58:34 der zweite, 08:58:36 der dritte und um 08:58:43 dann der vierte. Man kann den Zeitversatz deutlich sehen.

Bin immer noch am Rätseln, woher das kommt.

Mein Notebook hat 8 GB Ram, Intel I5, 3,4 bis 3,8 Ghz, 64 Bit und eine 250 SSD. An der Hardware sollte es also nicht liegen.

Gruß Gerhard

[Helmut Kreis]

Hallo Gerhard,

das sind aber doch die Meldungen, dass die Richtung geändert wird. Eine Verzögerung lässt sich hier nicht rauslesen.
Stellst Du mal das Projekt zur Verfügung?

[breditarms]

Moin Helmut.
Im Log ist zwischen den Umschaltungen fast immer ein Zeitversatz von 1 Sekunde zu sehen, das finde ich auch o.k. Bei der vierten Umschaltung tritt ein Versatz von 7 Sekunden auf. Das ist die gemeinte Verzögerung.

Anbei noch die Datensicherung. Ich hoffe, Du kannst da noch etwas finden.

Gruß Gerhard

[Markus Herzog]

Hallo Gerhard,

Hmm wie ist die Umscahltung denn ausgelöst worden. Per Klick im Control oder wie?

Irgendwie ist der Log für mich nicht wirklich aussagekräftig, denn ich kann da ja nicht erkennen wann was wie per Klick oder so ausgelöst wurde.

Grüße
Markus

[breditarms]

Hallo Markus.
Ausgelöst per Click über das Control. Da ist es auch aufgefallen.

Gruß Gerhard

[Markus Herzog]

Hallo Gerhard,

habe ich gerade mit deinem Projekt und einer CS3+ probiert. Bei mir nicht nachvollziehbar. Und bei mir läuft das sogar über ein ziemlich komplexes Netzwerk.

Nur zum Verständnis:
Du hast immer wieder neu geklickt nachdem du gesehen hast, dass es am Fahrzeug umgeschaltet hat. Die Zeit dokumentiert also wie lange du gewartet hast bis du die Anlagenreaktion gesehen hast?
Oder hast du ständig geklickt und es erschien dann erst verzögert im Logbuch?

Grüße
Markus

[breditarms]

Hallo Markus.

Habe immer wieder mit der Hand geklickt und konnte dann beim vierten Klick den Zeitversatz sehen. Die Loks wechseln dann das Licht, ganz deutlich zu sehen.
Ich könnte das auch noch in einem Video festhalten, muss mal schauen wie ich das mit zwei Händen hinbekomme.
Wird aber nicht vor Montag passieren.

Euch einen schönen Sonntag.
Gruß Gerhard

[breditarms]

Moin zusammen.

Der Fehler ist gefunden und beseitigt. Nur warum er aufgetreten ist, ist mir schleierhaft.
Im Moba-Raum habe ich einen alten Fritz-Router zum Repeater umkonfiguriert.
Er hängt nun per Wlan an der großen Fritzbox und dient als Switch für mein Laptop und die CS3.

Der Repeater kann auf beiden GHZ-Frequenzen arbeiten, war aber nur auf 2,4 eingestellt. Die große Fritzbox auf 2,4 und 5 Ghz. Den Repeater habe ich auch auf 2,4 und 5 Ghz gesetzt, nun funktioniert der Fahrtrichtungswechsel.

Bin nur durch Zufall darauf gekommen, weil ich in der Fritz-Box etwas umstellen musste. Dabei viel der Unterschied zum Repeater auf.  Repeater angepasst und alles läuft.

Für mich unerklärlich, aber Tatsache, Hauptsache der Wurm ist da raus.

Gruß Gerhard

[breditarms]

Moin zusammen.

Nun bin ich etwas verwirrt und verstehe WDP nicht so recht.

Vor längerer Zeit, Januar 2024, hatte ich das Problem, das der Fahrtrichtungswechsel, wenn er mehrfach nacheinander vorgenommen wurde, erst mit großer Verzögerung ausgeführt wurde.
Damals wurde mein Router als Verursacher ertappt und ausgetauscht. Hing mit den möglichen Wlan-Frequenzen zusammen. Dann war erst einmal Ruhe.

Mittlerweile bin ich auf WDP 2025 mit den aktuellen Updates und teste gerade intensiv mit digitalen Kupplungen, alte Telex von Märklin, Klotzkupplung von Märklin und die ESU-Kupplung.
Die ESU-Decoder der drei Loks wurden entsprechend eingestellt und funktionieren für alle drei Kupplungen fast sauber.

Problem wieder der Fahrtrichtungswechsel:
Wird er mehrmals hintereinander ausgelöst und dann der Kuppler betätigt, schaltet WDP zu spät um, dafür wird der Kuppler vorgezogen. Es ist dabei egal, welche Kupplung bzw. Lok angesprochen wird.
Angeforderte Befehlsfolge: FRW FRW Kuppler
Ergebnis Ausführung:       FRW Kuppler FRW

Das sieht total wirr und irre aus und bringt den Ablauf durcheinander. Woran mag das liegen?

Bei anderer Gelegenheit ein ähnliches Phänomen:
Auf FRW reagiert weder die Lok, noch WDP bzw. CS3. Erst wenn ein weiterer Fahrbefehl rausgeht, erfolgt der FRW. Da ist doch etwas faul.
 
Eigentlich müsste man die erzeugten Befehle im Rahmen eines Logging's festhalten, parallel dazu die ausgeführten Befehle aufschreiben und dann überprüfen.
Geht das mit dem Logging irgendwie?

Gruß Gerhard