Lok bekommt kein Fahrbefehl

[Arno]

Hallo Miteinander
An mehreren stellen an meiner Anlage habe ich probleme seit der Umstellung auf INZFA.
In der Demoversion erhalten die Fahrzeuge die Geschwindikeitsbefehle genau wie ich das erwarte.
Auf der Anlage jedoch nicht.
Nehmen wir mal den Startkontakt 854 und den Zielkontakt 810 unter die Lupe.
Wenn am Ziel nur 1-2 Loks stehen fährt ab 854 ein Fahrzeug einwandfrei los und Parkiert sich hinter den anderen.
Sobald aber noch mehr Züge bereits auf 810 Stehen funktioniert das einfach nicht mehr.
Die Lok bekommt zwar die Fahrstrasse, (dies auch zurecht und weil genügend Platz vorhanden ist) der Geschwindikeitsbefehl jedoch bekommt die Lok nicht und wartet friedlich bis ich eingreife. Auch beim Manuellen wählen der Fahrstrasse beobachte ich das genau gleiche.
Wo liegt mein Denkfehler. In den INZFA ist doch die Rheinenfolge richtig, und in den Fahrstrassen die Haken bei Belegt frei doch auch?

[Helmut Kreis]

Hallo Arno,

ohne Dein Projekt eingesehen zu haben, vermute ich -wie bei vielen Anfragen dieser Art-, dass der erste RMK des MiFAZ (rechnerisch oder real) besetzt ist. Es gibt kein INZFA, oder was soll das sein?

[Arno]

Mh... diese Abkürzungen.... ja ich meinte MiFAZ.
Im Anhang ist meine Datensicherung und ich wäre dir dankbar wenn du mal schaust ob sich da noch andere Fehler eingeschlichen haben.
Wenn der fehler der erste freie Kontakt sein soll? Kann man das mit einem FDL absichern?

[Dr. J. Schmidt]

Hallo,
siehe meinen Beitrag iFAZ umwandeln in MiFaZ letzter Woche und den Kommentar von Herrn Herzog.

[Arno]

Hallo Helmut
Auch das habe ich nun gelesen und gestestet.
Doch irgendwie habe ich das Problem auch wenn ich der erste Kontakt frei habe und er rechnerisch frei ist.

Ich habe schon die ganze Anlage umprogrammiert weil die ersten Tests so positiv verliefen.
Ob nun alle Probleme wirklich auf dem programm liegen? Ich weiss es nicht und würde es so auch nicht sagen.

Tatsache ist dass ich am Samstag Gäste auf bei unserer Anlage habe und hoffe das ich noch einen guten Fahrbetrieb hinbekomme.
Deshalb hoffe ich das jemand meine Daten mal anschaut e.v.t habe ich einfach ein Fehler den ich schon 100 mal übersehen habe.

Z.b am Kontakt 810 können 4 Züge stehen ohne das der erste Kontakt Rechnerisch oder real belagt ist. Trotzdem bekommen einfahrende Züge kein Geschwindikeits Signal. Oder Stoppen Züge die inder aufrückfahrstrasse unterwegs sind!

[Markus Herzog]

Hallo Arno,

vielleicht ist es nicht richtig rübergekommen. Vielleicht aber auch doch, daher zur Sicherheit nochmal.

Es muss nicht nur der 1. Kontakt im miFAZ frei sein, sondern alle auf den der Zug rechnerisch nicht steht.

Nehmen wir mal dein miFAZ 810. Nehmen wir mal dort stehen 2 Züge (leider fehlt die Fahrzeug-DB in der Datensicherung, daher was mehr Arbeit für mich und nicht so schön). Der erste am Signal und der 2. mit 15cm Abstand dahinter, einer ist 100cm lang, der nächste 120cm. Siehe Bild, dann dürfen nur die 4 rechten Kontakte 807-810 belegt sein. Die vorherigen müssen in der aktuellen Version (siehe meine Erläuterungen für Dr. Schmidt) frei sein d.h. 803-806. Hätte jetzt der Zug 13 302 so weit zu früh angehalten, dass z.B. der 806 noch belegt ist, dann erhielte der einfahrende Zug direkt nach dem Aufrufen der FS den Stopbefehl weil WDP denken würde "Hupps und schon ist der da". Wie gesagt ich arbeite daran, dass künftig in so einem Fall die FS gar nicht mehr erst gestellt wird mindestens. Work-Around habe ich auch im Beitrag für Dr. SChmidt erläutert.

Grüße
Markus

Grüße
Markus

[Arno]

Hallo Markus
Sorry, im Anhang nun die Datei mit der Lokdatenbank.
Da unsere Züge recht genau fahren kann dies natürlich schon sein das es gelegentlich funktioniert und danach wieder nicht.
Wie Das Programmiertechnisch aussieht, ! Da kann ich leider nicht mitreden, hab davon keine Ahnung.
Die ansätze dieser funktion sind jedoch genial und ich bin mir sicher das du/ ihr es irgendwie hinbekommt.
Einfach die Fahrstrasse nicht ausführen wäre ja auch schaade wenn noch 3m Gleis zur verfügung steht.
Ich lade mal eine altes Gleisbild und lasse euch Werken. Sobald ihr das Update freigibt tese ich es dann wieder.

[Helmut Kreis]

Hallo Arno,

auf dem MiFAZ 810 hast Du eine Begrenzung von 2 unabhängiger Fahrzeuge.
Damit bekommst Du keinen 3. Zug mehr rein!
Zudem ist in der Automatik der Bereich Schmalspur deaktiviert.

[Arno]

Hoi Helmut
Ja das stimmt. mit der Begrenzung auf dem MiFaz 810 versuchte ich das problem zu umgehen.
In der Automatik war der Schmalspur bereich bei den Tests aktiviert.

Danke das du meine daten so genau angeschaut hast. Mir wäre lieber gewesen ich selber hätte etwas übersehen.

[Helmut Kreis]

Hallo Arno,

wer sonst hat denn etwas übersehen, wenn Du erfolglos nach dem Problem gesucht hast?

[Martin Lutz]

Guten Morgen,

Am Schluss haben wir mit der Zuganzehl herumexperimentiert. Mag sein, dass Arno dann diese letzten Daten hierhin gestellt hat. Aber dennoch: Manchmal scheint es, dass sich die Fahrstrassen gegenseitig überholen. So jedenfalls mein Eindruck. Ich glaube, hier liegt ein Problem in der Software?

[Helmut Kreis]

Hallo Lutz,

wenn sich Fahrstraßen überholen, dann ist das doch kein Softwarefehler, sondern eher eine nicht nach Wunsch erstellte Automatik!
Gib mal ein Beispiel, wo sich Fahrstraßen überholen sollen.
Und was hat jetzt das Überholen von Fahrstraßen mit der Einfahrt in das MiFAZ zu tun?

[Arno]

Hallo Helmut
Es ist schon richtig das es so gesehen kein Softwarefehler ist, das bestreitet ja auch niemand.

Was Martin beschreibt, passiert jedoch wenn man im Ak Betrieb mit F7 Fahrstrassen beendet weil die Lok keine Geschwindigkeit erhielt.
Die Folge ist natürlich das eine Lok im PC an das nächste Fenster weitergegeben wird und sich dahinter gleich die nächste Lok nachschiebt. Wenn man jetzt noch ein anderer Fahrweg an dieses Ziel führt ist das Chaos perfekt, aber sicher nicht gewollt.

Zur Erklärung, Martin bedient die Anlage, und ich habe halt über viele Jahre immer Windigipet programmiert. Gemeinsam kommen wir so recht weit und wenn man halt so ein Problem hat ist es nicht immer einfach die Ursache zu finden.
Das ich Technische Beschreibungen sehr schlecht in Worte auf das Papier bringen kann macht nicht einfacher!

Es soll jedoch gesagt sein das wir nicht ohne Grund seit 20 Jahren Windigipet benutzen und es sehr zu schätzen wissen und das man hier stets Hilfe bekommt.

[Helmut Kreis]

HAllo Arno,

ich will das Thema jetzt nicht weiter aufpröseln, aber jetzt -abschließend- noch einige Antworten geben.

Es ist schon richtig das es so gesehen kein Softwarefehler ist, das bestreitet ja auch niemand.

Was Martin beschreibt, passiert jedoch wenn man im Ak Betrieb mit F7 Fahrstrassen beendet weil die Lok keine Geschwindigkeit erhielt.

Wenn Du das mit dem Softwarefehler nicht so meinst, dann solltest Du das auch nicht so schreiben!
Wir als Betatester bemühen uns in Tests schon weit vor der Veröffentlichung einer Version oder Updates mit den neuen Dingen. Trotzdem gibt es aber immer die Möglichkeit, dass ein oder auch mehrere Anwender intuitiv etwas anders machen, oder ihre Anlage und Anwendung nicht von uns zu testen ist.

Wenn Ihr mit F7 Fahrstraßen löscht, dann hat das u. U. weitreichende Folgen, die ihr in einer Automaik nur schwer ganz nachverfolgen könnt.
Daher sollte das Löschen mit F7 eigentlich eine Ausnahme sein, der man aber nachfolgend mit einer Fehlersuche auf den Grund gehen sollte!

[Markus Herzog]

Hallo zusammen,

Ich mag mich dazu nochmal äußern, insbesondere weil sich über das gleiche Thema jetzt in zwei Beiträgen unterhalten wird:

Die Ursache ist somit bei ungenauen Zugfahrten. Bei dieser Funktion kann es halt sein das sich Züge so einreihen das der letzte Wagen genau auf einen Rückmeldung trifft. Wenn der betreffende Zug in diesem Fall einen milimeter zu wenig weit fährt, hat man das beschriebene Problem.

Wie schon einmal erläutert tritt das Problem auf, wenn der Zug zu früh hält. Da hat Arno schon richtig erkannt, aber man hat das Problem jetzt nicht jedes Mal wenn ein Zug mal um einen Millimeter zu früh hält, sondern nur wenn das dann genau mit einer RMK-Grenze aufeinander trifft.

Nehmen wir mal ein Gleis mit 3 RMK 001, 002 und 003 (links nach rechts). Je 100cm lang. Wir fahren mit einem 90cm Zug und der einfachheit halber mal angenommen ist der Abstand zwischen erster/letzter meldender Achse und Zugende 0.0 cm.
Schutzabstand im miFAZ auf 10 cm eingestellt.

Fall a: Signalabstand zum Gleisende 5cm rechts. Ist jetzt der Zug genau eingefahren steht er so auf den RMKs:
001 frei, 002 frei, 003 5cm Luft - 90 cm Zug - 5 cm Luft
Jetzt dürfte der 90cm Zug bis zu 5cm zu früh gehalten habenund RMK 002 wäre noch nicht belegt und mit dem Schutzabstand von 10cm sollte auch alles sicher sein wenn jetzt der nächste einfahrende Zug nicht noch viel zu weit fährt.

Fall B: Signalabstand zum Gleisende 10cm rechts. Ist jetzt der Zug genau eingefahren steht er so auf den RMKs:
001 frei, 002 frei, 003 0cm Luft - 90 cm Zug - 10 cm Luft
Würde jetzt der Zug zu früh halten, dann wäre es bei dem Grenzfall natürlich so, dass schon 1 Millimeter zu früh nicht folgenlos wäre.

Bleiben wir bei Fall B und der Zug ist sagen wir mal 3 cm zu früh gestoppt.
Für die WDP-FS-Start-Logik ist es Stand 2021.1 noch so, dass die FS gestellt würde, da laut miFAZ ja auf RMK 001 und 002 kein Zug steht. Leider merkt dann aber die Stop-Logik nach dem Stellen der FS "Uuups der Zug ist zum Ziel gesprungen und ich muss sofort wieder anhalten" weil RMK 002 ja unerwartet besetzt ist.
Das ist natürlich nicht schön und ich habe ja schon gesagt, dass wir dazu an einer Lösung via nächsten Update arbeiten. Allerdings ist schon erstaunlich, dass dies jetzt erst auftaucht fast 2 Jahre nach Einführung des miFAZ (klar hat sicher auch nicht jeder das sofort genutzt). Von daher war unsere Grundannahme "Züge fahren eher zu weit als zu wenig weit" nicht ganz falsch war, aber klar es gibt diese Fälle.
Aber trotzdem ist die Lösung erstmal eher zu sicher als unsicher, weil der Zug halt eher einmal zu viel nicht fährt.

Wir brauchen da aber ein bisschen was da jetzt was zu schaffen auch den Fall abzudecken und trotzdem die Betriebssicherheit zu maximieren.

Möglichkeit 1:
Sollte im Fall B wo nach miFAZ-Belegung RMK 002 nicht besetzt sein dürfte, doch RMK 002 besetzt sein, könnte WDP sagen "RMK 002 unerwartet belegt, ich starte die FS nicht". Bedeutet aber auch dass dieses miFAZ erst wieder befahren werden kann, wenn vorherfahrende Züge im miFAZ aufgerückt/ausgefahren sind. Das wäre aber auch die absolut sichere Lösung, denn es wäre dann egal ob der schon im miFAZ stehende Zug nur 1mm zu früh oder bis zu 100cm zu früh gehalten hätte.

Möglichkeit 2:
Sollte im Fall B wo nach miFAZ-Belegung RMK 002 nicht besetzt sein dürfte, doch RMK 002 besetzt sein, könnte WDP sagen "RMK 002 unerwartet belegt, aber vielleicht/hoffentlich nur im Rahmen des eingestellten Schutzabstands, starte die FS daher trotzdem auf diese Annahme bauend und rechne den Weg nur annehmend auf der zu erwartenden Belegung von RMK 001". Das wäre eine Lösung die zu weniger Stillstand führt aber natürlich viel unsicherer ist falls der nun einfahrende Zug diesmal halt deutlich zu weit fährt oder der zu früh gestoppte Zug z.B 20cm zu früh gestoppt hat. Eine Lösung bei der ich bis jetzt echt Bauchschmerzen habe.

Möglichkeit 3:
Sollte im Fall B wo nach miFAZ-Belegung RMK 002 nicht besetzt sein dürfte, doch RMK 002 besetzt sein, könnte WDP sagen "RMK 002 unerwartet belegt, ich starte die FS zwar, aber nur wenn Züge reinfahren wollen die nur ein 100cm lang sind (Länge RMK 001) und halte die auch so früh, dass die komplett auf RMK  001 stehen". Vorteil: wieder viel sicherer als Möglichkeit 2. Nachteil: sperrt halt Züge einer Länge größer 100cm aus, selbst wenn der Zug den RMK 002 nur 1mm fehlbelegt hat und ein 180cm Zug z.B. ohne Probleme reinpassen könnte.

Ich habe da auch noch Möglichkeiten 4..x im Kopf (1-3 sind die extremsten Lösungen), die ich aber hier nicht diskutieren werde/möchte/kann, wir lassen uns dazu was einfallen.

Wie schonmal erwähnt, wer jetzt Züge hat die sehr oft zu früh halten, sollte entweder seine Bremskorrektur was zurücknehmen (dann fahren sie leiber eher was zu weit) oder könnte WDP auch "temporär" austricksen indem ihr an den Zug temporär einen virtuellen Waggon der Länge x anhängt oder den letzten Waggon x cm länger macht, dann vergrößert sich der schutz für den Zug nach hinten um diese Länge x. Nur so mal als Idee. Wobei Helmut auch schon was recht.
(Wenn ich die Fahrparameter der Lok sehe, würde ich bei mir selber darüber nachdenken insb. Thema Langsamfahrstufe, da einen anderen Dekoder einzubauen, den man so programmieren kann, dass man das im Dekoder einstellt und WDP alle Fahrstufen zur Verfügung hat.) Ich setze das bewusst in Klammern, da ich das nicht fordere/verlange, aber ich wäre mit solche Messkurven/Lokparametern für micht selber absolut nicht glücklich.

Vorschlag: wir beenden das Thema hier erstmal. Resultat: Problem ist angekommen. Wir befassen uns damit.

Grüße
Markus