Profile, Nichtabgearbeitete Kontaktereignisse, Automatische Verwerfung?

[Walter Lauth]

Hallo WDP-Nutzer!

Ich verwende fast nur Profile, kaum „reine“ Fahrstraßen, da die IDO-Profile viel mehr Möglichkeiten bieten.
Bei längerem Betrieb stoppten manche Züge  nicht bei Erreichen des Ziel-Zugnummernfeldes, sondern fuhren einfach weiter, bis es zu einem Crash kam, bzw. ich musste sie manuell stoppen. Da es hauptsächlich die Einfahrtfahrstraßen meines 10-gleisigen Schattenbahnhofes betraf, da vor allem das Gleis vier (die anderen neun funktionierten), ging ich zuerst von einem Fehler in den Fahrstraßen bzw. Profilen von WDP aus. Diese waren jedoch alle auf einen Schlag mit dem Fahrstraßenassistenten erstellt worden bzw. die Profile hatten in allen Einfahrten die gleichen Daten. Über das Logbuch bzw. die Zugüberwachung stellte ich fest, dass ein Kontaktereignis nicht richtig abgearbeitet wurde. Somit wurden auch die nachfolgenden Kontaktereignisse ignoriert und also auch der entscheidende Stopp-Befehl am Ende. Als Ursache vermute ich, dass manchmal irgendwie die Belegungsmeldung nicht ankommt (Ursachen gibt es ja viele, vom Gleisbesetztmelder über Bus, Zentrale, Inferface bis WDP (schließe ich zu 99,9 % aus) bei gleichzeitigem Betrieb von bis zu 10 Zügen. Allerdings ist diese Konzentration seltsam,  da es ein Rückmelder ist, der Teil aller 10 Einfahrtstraßen ist und dies fast nur bei der Einfahrt in Gleis 4 passiert. Es ist der Rückmelder  vor den Einfahrtsweichen, der  die Funktion der Geschwindigkeitsreduzierung und der Lok-Funktionsabschaltung (Licht, Sound aus usw., derzeit bis zu 6) erledigen soll. Er ist auf jeden Fall auf Grund seiner Länge(über 50 cm) mehrere Sekunden lang belegt. Ich habe ihn dann ganz aus den Profilen herausgenommen, und diese Funktionen dem vorherigen Kontakt überlassen (zwei zeitversetzte Kontaktereignisse, da der vorherige Kontakt ebenfalls schon Geschwindigkeitsreduktion veranlasste) und es kam nur noch selten vor. Inzwischen habe ich den Stopp- Kontakt als Sicherheitskontakt bestimmt und die Ein- und Ausschaltverzögerung auf je 350 ms heraufgesetzt. Dies sind jedoch nur ein Hilfsmittel.
Kann es sein, dass aufgrund des vielen Datenverkehrs nicht genügend Funktionen pro Kontaktereignis gleichzeitig abgearbeitet werden können?
Helfen würde meines Erachtens  folgendes: Nachfolgende Kontaktereignisse müssten, obwohl ein früheres Kontaktereignis noch nicht abgearbeitet wurde, trotzdem abgearbeitet werden. Somit wäre auch das Problem gelöst, dass man ein Kontaktereignis  vom Zeitablauf zu spät erfasst (ich bemerkte auch, dass bei anderen Profilen mit mehreren zeitversetzten Kontaktereignissen pro Gleisbesetztmelder  bei schnellen Zügen das gleiche Problem auftrat, bei langsameren Zügen aber nicht, da dann natürlich die Gleisbesetztmelder länger besetzt sind. Ich denke, dass das gerade die Zweileiter-Fahrer besonders betrifft, da viele Wagen, insbesondere bei unbeleuchteten Güterzügen, nicht rückmeldefähig sind.  Dies kann man auch in der Simulation, die ja viel schneller abläuft, nicht erkennen.  Dies gilt vor allem für den Stopp/Fahrstufe-000-Befehl  am Ende. Gibt es das schon bzw. wäre das als Optionseinstellung möglich?  Ich meine letzter Zeit im Forum etwas vom automatischen Verwerfen von Kontaktereignissen gelesen zu haben, konnte leider den  Beitrag nicht (mehr) finden.
Gibt es schon so eine Möglichkeit schon, ist so etwas angedacht, ober gibt es jetzt schon eine andere Lösung, die ich nicht kenne?
Vielen Dank im Voraus.

Mit freundlichen Grüßen
Walter

[Markus Herzog]

Hallo Walter,

Helfen würde meines Erachtens  folgendes: Nachfolgende Kontaktereignisse müssten, obwohl ein früheres Kontaktereignis noch nicht abgearbeitet wurde, trotzdem abgearbeitet werden. Somit wäre auch das Problem gelöst, dass man ein Kontaktereignis  vom Zeitablauf zu spät erfasst (ich bemerkte auch, dass bei anderen Profilen mit mehreren zeitversetzten Kontaktereignissen pro Gleisbesetztmelder  bei schnellen Zügen das gleiche Problem auftrat, bei langsameren Zügen aber nicht, da dann natürlich die Gleisbesetztmelder länger besetzt sind. Ich denke, dass das gerade die Zweileiter-Fahrer besonders betrifft, da viele Wagen, insbesondere bei unbeleuchteten Güterzügen, nicht rückmeldefähig sind.  Dies kann man auch in der Simulation, die ja viel schneller abläuft, nicht erkennen.  Dies gilt vor allem für den Stopp/Fahrstufe-000-Befehl  am Ende. Gibt es das schon bzw. wäre das als Optionseinstellung möglich?  Ich meine letzter Zeit im Forum etwas vom automatischen Verwerfen von Kontaktereignissen gelesen zu haben, konnte leider den  Beitrag nicht (mehr) finden.

Das geht leider nicht so einfach Profilereignisse auszulassen/zu überspringen. Grund ist, dass man sonst keine Rangierprofile mehr machen könnte.
Stell dir folgendes Profil vor zum Rangieren einer Lok an einen Zug ran:
Lok kommt von Kontakt 1, Zug steht an Kontakt 3, hinter dem Zug Kontakt 4. Vor dem Zug Kontakt 2. Nun fährt die Lok über Kontakt 2 zu Kontakt 3 und drückt den Zug solange nach hinten bis Kontakt 4 erreicht wird. Dann wendet der Zug und zieht vor bis zum Signal an Kontakt 2.
Profilerereignisse dazu:
-K1 V=30
-K4 Stop
-K4 Wenden
-K4 V=30
-K2 Stop

würde man nun deinen Vorschlag umsetzen, dann würde K4 niemals ausgelöst und damit das ganze Profil hinfällig, da die Lok sofort an K2 stehenbleiben würde.

Aber nun zu deinem Problem. Eigentlich kann die Lenzzentrale sehr viele Ereignisse schnell verarbeiten, da sehe ich ehrlich gesagt kein Problem. Du solltest aber mal beobachten im Taskmanager wie hoch die CPu-Last in solchen Situationen ist. wäre die sehr hoch wäre das ein sicheres Zeichen, dass die Kommunikation zwischen Zentrale und CPU "zu" läuft.

Schaltest du denn eigentlich die bis zu 6 Sonderfunktionen mit einer oder mehreren Kontaktzeilen aus, eine wäre günstiger.

Wobei ich mich auch nicht des Eindrucks eines Hardwareproblems erwähren kann, da es sich nur um 1 oder 2 Problemkontakte zu handeln scheint.

Das von dir automatische Verwerfen von Ereignissen macht WDP nur bei Standardfahrten, da diese ja auch nicht zum Rangieren taugen und somit die strikte Einhaltung der Kontaktfolge irrelevant ist.

grüße
Markus

grüße
Markus

[Walter Lauth]

Hallo Markus!

Vielen Dank für Deine schnelle Antwort.
Ich vermute auch ein Hardware-Problem, allerdings nicht am GBM, sondern letztendlich im  Lenz-Rückmeldesystem.  Der verwendete Blücher-GBM ist nämlich sehr zuverlässig und hat den Vorteil, dass man über eine Diode das Auslösen visuell nachvollziehen kann; das hat bei sonstigen Kontrollen immer funktioniert. Aufgrund des relativ seltenen (so habe ich  10-mal hintereinander die Fahrstraße/Profil befahren, wobei alles bestens funktionierte) Fehlers, ist das tatsächliche Beobachten des GBM beim Fehlerauftreten kaum möglich.
Danke für die Info, dass es besser ist, die vielen Funktionen bei einem Kontaktereignis zu schalten, und nicht nach und nach. Gilt dies auch, wenn gleichzeitig die Geschwindigkeit reduziert wird, also zusätzlich Fahrstufenbefehle gleichzeitig erfolgen?
Das Rangierproblem war mir klar, deswegen habe ich das als eventuelle Option vorgeschlagen, was natürlich wieder das Programm für Anwender verkompliziert. Falls ich Dich richtig verstanden habe, macht dies WDP schon, d.h. ich müsste die Einfahrt als „reine“ Fahrstraße ohne Profil betreiben, wobei ich wieder die Lokfunktionen nicht schalten könnte oder ginge das folgendermaßen:  Über einen virtuellen Magnetartikel, den ich am darauffolgen Rückmelder über die Folgeschaltung der Fahrstraße (nicht im Profil) auslöse, wird der entsprechen GBM auf Belegt geschaltet, und am Ende der Fahrstr. wieder auf Grün=Frei. Somit würde das Kontaktereignis im Profil und alle folgende Ereignisse abgearbeitet werden, oder habe ich da einen Denkfehler?

Die CPU-Last werde ich mehr beobachten.

Mit freundlichen Grüßen
Walter

[Dirk Streuber]

Hallo Walter,

... Inzwischen habe ich den Stopp- Kontakt als Sicherheitskontakt bestimmt und die Ein- und Ausschaltverzögerung auf je 350 ms heraufgesetzt. Dies sind jedoch nur ein Hilfsmittel.
 

verstehe ich das jetzt richtig: Du hast bei der Einschaltverzögerung und bei der Ausschaltverzögerung jeweils 350msec eingetragen? Wenn ja, dann setze die Einschaltverzögerung wieder auf 0msec! Wenn die Meldung des RMK, wegen zu geringen Widerstandes der Lok, kleiner als die 350msec ist, dann wird der RMK in WDP nicht abgearbeitet, da er die Mindesteinschaltzeit nicht erreicht.

[Markus Herzog]

Hallo Walter,

So etwas ginge ist aber extra Aufwand. Ich würde erstmal wirklich bei Ereignissen am selben Kontakt Fahr- und Funktionsbefehle möglichst in eine Kontaktzeile zusammen fassen. Das minimiert den Traffic.

Hintergrund: Stell dir vor du willst F1-F4 ausschalten. Dafür gibt es nur einen gemeinsamen Befehl. Machst du das in 4 Zeilen wird daraus folgende Befehlsfolge:
F1 aus, F2 - F4 an
F1 - F2 aus, F3-F4 an
F1-F3 aus, F 4 an
F1 - F 4 aus

Das heißt 4 Befehle gehen an die Zentralen und das Gleis. Machst du es in einer Zeile geht direkt F1 - F 4 aus raus. Hast du dann auch noch den Fahrbehl in der Zeile ersparst dann zusätzlich noch WDP einige Rechenzeit.

Grüße
Markus

[Walter Lauth]

Hallo Dirk!

Ich habe aufgrund Deiner Empfehlung  die Einschaltverzögerung wieder auf 0 ms gestellt (war beim Fehlerauftreten bei 0 ms). Da die Rückmeldestrecke  über 1,50 m lang ist (habe sie nun nachgemessen), jweils mindestens zwei polarisierte Weichen enthält, wodurch die Räder immer wieder  an den Gleisprofilen anstoßen, dürfte das eigentlich nicht entscheidend sein. Meine Überlegung war, dass Loks mit haftreifenbestückter erster Achse  die Rückmeldung anfangs nur ganz kurz auslösen. Ich wollte damit erreichen, dass erst bei totaler Besetzung der Rückmelder klar und konstant die Gleisbesetzung meldet und diese dann erst an das Rückmeldesystem weiter gibt. Ähnliches Flackern soll auch bei Verlassen der Rückmeldestrecke vermieden  und so das System insgesamt entlastet werden.

Hallo Markus!

Vielen Dank für Deine Erklärung über den Ablauf der Steuerungsbefehle im Digitalsystem (Zitat Loddar:“ Again what learned“).
Ich werde erstmal weiter beobachten und auch die Hardware unter die Lupe nehmen.

Mit freundlichen Grüßen

Walter

[Helmut Kreis]

Hallo Walter,

die GBM von Blücher haben doch eine Ausschaltverzögerung. Das bedeutet dass der Kontakt, wenn er denn mal ausgelöst wurde, auch noch eine gewisse Zeit erhalten wird. Daher brauchst Du die Zeit in WDP nicht auch noch hoch zu stellen und kannst sicher sein, kein "gewackel" in der Rückmeldung zu haben.

Vielleicht kannst Du auch durch den GBM einen visuellen Kontakt schalten lassen, mit dem Du dann im Gleisbild siehst, ob der Kontakt geschaltet hat oder nicht. Wenn Du diesen Kontakt dann vielleicht erst wieder löschst, wenn Die entsprechende FS erneut geschaltet wird, sollte auch nachträglich ersichtlich sein, oder bei einem Crash dieser Kontakt Schuld hatte.

Gruß

Helmut