Seite 6 von 7

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 25.06.2020 11:16:13
von Alwin Meschede
Johannes hat geschrieben:Irgendwelche Richtungs- oder Gegengleisanzeiger in der Matrix?
Ja, Zs 2. Debug sagt "...hat Richtungs- oder Gegengleisanzeiger (Zeile noch unbekannt)".

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 25.06.2020 11:20:34
von Johannes
Der muss auch raus, wenn das Signal komplett fremdgesteuert sein soll. Momentan versucht das Programm, das Signal als alleinstehenden Richtungsanzeiger zu verknüpfen. Zusi würde das, glaube ich, auch machen.

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 25.06.2020 11:28:11
von Alwin Meschede
Danke für die Erläuterungen!

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 27.06.2020 11:48:03
von Alwin Meschede
Bei st3 welche nur im offiziellen Verzeichnis existieren scheint es ein Problem bei der Interpretation des Dateipfads zu geben:

Code: Alles auswählen

Info: Hagen Gbf Ls 112 I -> Hagen Gbf Q: unterschiedliches Ziel: 1756@Routes\Deutschland\32U_0004_0057\000392_005691_Hagen_Hbf\Hagen_Hbf_1985.st3 vs. 1756@..\Zusi3_offiziell\Routes\Deutschland\32U_0004_0057\000392_005691_Hagen_Hbf\Hagen_Hbf_1985.st3

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 27.06.2020 16:24:32
von Johannes
Neue Version 1.0.18:
* Bugfix bei der Berechnung relativer Pfade, wenn ein Pfad nur im offiziellen Datenverzeichnis existiert
* Schreibe Ausgabedateien immer ins eigene Datenverzeichnis

Danke für den Hinweis!

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 13.01.2022 19:51:00
von Johannes
Neue Version 1.0.19:
* Allein stehende Zs 3 werden unterstützt.

Die Funktion hat F.Schn. implementiert, vielen Dank. Vielleicht magst du noch mehr dazu sagen?

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 13.01.2022 20:17:35
von Alwin Meschede
Sieht aus als ob irgendein Fehler drin ist. Gegenüber der Vorgängerversion nimmt die neue Version in Hildesheim Hbf Änderungen folgender Art vor:

Code: Alles auswählen

Info: Hildesheim Hbf F -> Hildesheim Hbf S3: Hauptsignalverknuepfung (HILDESHEIM_HBF_2001.ST3,108) (Signal Hildesheim Hbf F an Element 1110g) hat unterschiedliche Zeile: (7, False) vs. (0, False)
Info: Hildesheim Hbf F -> Hildesheim Hbf S3: Vorsignalverknuepfung (HILDESHEIM_HBF_2001.ST3,107) (Signal Hildesheim Hbf WVf an Element 1087b) hat unterschiedliche Spalte: 5 vs. 0
Info: Hildesheim Hbf F -> Hildesheim Hbf S3: Vorsignalverknuepfung (HILDESHEIM_HBF_2001.ST3,235) (Signal Hildesheim Hbf f an Element 2372g) hat unterschiedliche Spalte: 5 vs. 0
Das vormals Zeile 7 (Hp 2, "60 km/h") zeigende Esig F zeigt jetzt also Zeile 0 (Hp 1, "Streckenhöchstgeschwindigkeit"). Das ist nicht richtig, weil mindestens in Streckenelement 1662 eine Signalgeschwindigkeit 65 im Fahrweg liegt.

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 13.01.2022 22:37:46
von F. Schn.
Hi,

kurze Erklärung, ich hoffe, ich habe nichts wichtiges vergessen:

Das Feature ist für Augsburg Hbf entstanden um dort eine Lösung für die allein stehenden Zs3 zu finden, die am Esig vorsignalisiert werden.

Also: Die Zusi-Logik ist, dass allein stehende Zs3 den Fahrweg in einen Abschnitt davor und einen Abschnitt dahinter teilen. Ein Geschwindigkeitssignal ist in der Doku 5.3.1.11.6.12 beschrieben. Es ist ein Signal, mit Geschwindigkeitszeilen größer 0 aber ohne eine Zeile mit vMax 0. Außerdem darf das Signal keine Vorsignalfunktion haben.

Die Geschwindigkeiten beider Segmente werden vom 3D-Editor soweit ich das augenscheinlich beurteilen kann separat bestimmt. Ein Geschwindigkeitsereignis im hinteren Weichenbereich hat daher auf den vorderen Abschnitt keine Auswirkung. Der 3D-Editor unterbindet aber eine Geschwindigkeitserhöhung am allein stehenden Zs3, das heißt die Vmax des Zs3 ist immer geringer als die des Esig.

Für Stumpfgleise und Zugdeckungssignale kann man weiter ganz normal in die 0-km/h-Zeile bzw. die -999-Zeile ein Geschwindigkeitsereignis legen. (Momentan werden an Hauptsignalen wie im 3D-Editor auch alle anderen Zeilen unterstützt.) Dieses wird dann am allein stehenden Zs3 zwangsweise angezeigt. Am Esig wird dann das Signalbild angezeigt, was sich aus den Weichen bis zum Zugdeckungssignal ergibt.

Möchte man am Esig zwangsweise eine bestimmte Geschwindigkeit anzeigen, kann man bei fahrstr_gen bei allein stehenden Zs3 in die Signalmatrix in die entsprechende Zeile ein Ereignis "Signalgeschwindigkeit" setzen. Man kann also in der 20-km/h-Zeile eines allein stehenden Zs3 eine Geschwindigkeit 62 eintragen und die Geschwindigkeit 62 dann auf Zs3 "6" + Zs3v "2" verkabeln. Man kann auch mehrere Signale hintereinander schachteln: Man kann z.B. in einer 40-km/h-Weiche ein unsichtbares Signal setzen, dass eine Geschwindigkeit von 62 km/h auf 42 km/h transformiert (Zs3 "4" anstatt Zs3 "6" bei weiterhin leuchtendem Zs3v), und eine Geschwindigkeit von 65 km/h auf 40 km/h (Zs3 "4" anstatt Zs3 "6" bei ausgeschaltetem Zs3v).

Möchte man verhindern, dass der 3D-Editor den Fahrweg in zwei Abschnitte teilt, kann man dem Signal eine Vorsignalgeschwindigkeit geben. Die allein stehenden Zs3 werden dann mit der selben Geschwindigkeit angesteuert, wie das Esig. Diesen Exploit hat TheShow herausgefunden. :) Dieser Trick könnte zwar dafür sorgen, dass man die Konstruktion nicht mehr so einfach durchschaut, ist aber sehr mächtig. Er ermöglicht es, ein Signal auch von Weichen abhängig zu machen, die vor dem Signal stehen. (Lohnt sich, bei komplizierten Sonderkonstruktionen darüber nachzudenken.)

Es gibt zwei Module, die bisher mit fahrstr_gen gebaut wurden, und die mit dem neuen Feature nicht mehr funktionieren werden:
Hildesheim Hbf die allein stehenden Zs3 (Element 1662 zählt hier nicht, weil es hinter dem Zs3 liegt) und
Mönchehof das allein stehende Lf2/3.
Beide funktionieren mit dem 3D-Editor derzeit ebenfalls nicht.

Beide Module lassen sich korrigieren, indem man entweder Geschwindigkeitsereignisse in die Signalmatrix der Zs3/Lf2/3 einbaut, oder indem man die Abschnittsteilung der Zs3 aufhebt, indem man die Vorsignalgeschwindigkeit auf 0 setzt.

Ich habe mit Johannes Hilfe den ganzen Bestand gefilzt, mehr ist mir nicht aufgefallen. Ich hoffe, ich habe auch genügend Autopilot-Tests gemacht, das sah aber vielversprechend aus.

Ich würde mich freuen, wenn es euch hilft, und wir damit (vermutlich hoffentlich?) die letzte Lücke zum 3D-Editor geschlossen haben.

Mit freundlichen Grüßen

F. Schn.

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 23.01.2022 18:13:56
von Juergen_Verheien
Hallo,

beim Ausbau von Streckenmodulen traten bei den abschließenden Arbeiten ( 3.Register mit Fahrstraßen, Register etc.) im Meldefenster Fehler auf, die alle bearbeitet und damit entfernt wurden.

Auf Grund von Hinweisen hier im Forum habe ich dann testweise den Fahrstr_Gen.exe in der aktuellen Version mal eingesetzt, erstaunlicherweise nun mit Infos, aber auch Warnungen, die im Zuis3-Edi nicht auftraten. Hier habe ich nun einige Verständnisprobleme und bitte um Unterstützung.

Bild

Die Signale an den Elementen 20 und 410 sind absolut identisch.

Rufe ich nun die Streckendatei des Moduls im Fahrstr_gen auf, wird folgendes angezeigt:

Bild

Für das Signal an Element 20 wird keine Warnung ausgegeben !
Für das Signal an Element 410 ist die Warnung markiert. Wie ist diese Warnung zu verstehen, was muss ich wie und wo verändern, damit die Warnung unterdrückt wird.

Die anderen drei Warnungen beziehen sich auf Bksigs in einem anderen Modul, siehe Fotos....

Bild
Bild

Auch hier mein Unverständnis, was in der Signalmatrix wie korrigiert werden soll. Haben die Warnungen irgendeinen negativen Einfluss auf das Simu-Geschehen ?

Für verständliche Korrekturhinweise bin ich dankbar....

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 23.01.2022 18:42:41
von F. Schn.
Die Meldung besagt, dass es eine Fahrstraße gibt, die laut "Signalgeschwindigkeit"-Ereignissen mit 40 km/h befahren werden soll. Das Signal hat hierfür jedoch keine Zeile. Für das Signal an Element 20 gibt es vermutlich keine Fahrstraße, die nur mit 40 km/h befahren werden kann. Daher wird die Warnmeldung auch nicht angezeigt.

Generell bin ich aber sehr verwirrt, was du hier vor hast. C432 gehört nicht zum Bahnhof Bövinghausen, sondern müsste ein kombiniertes Esig für Dorstfeld und Dortmunderfeld sein und Selbstblocksignale gibt es dort keine und auch keine Halbregelabstands-Ankündigungssignale, mit denen du diese verwechselt haben könntest. Ich habe bei allen vier Signalen starke Zweifel, ob sie im Aufbau grunsätzlich richtig sind. Eine Korrektur in der Matrix macht vermutlich keinen Sinn, dort gehört vermutlich eher das korrekte Einfahrsignal hin.

Nachtrag: Die markierte Zeile spricht eigentlich auch von Signal C432.

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 24.01.2022 15:17:04
von dk48
Ich habe den Fahrstrassengenerator ausprobiert und hoffte das folgenden Problem damit auf elegante Weise lösen zu können:

Bild Bild Bild
Bild1 zeigt die Situation, Ausfahrt von d2 bis d5 nach Rheinberg über das markierte Gruppenausfahrsignal D2-5 funktioniert korrekt wie im Handbuch beschrieben.
Bei Ausfahrt (Rangierfahrt) nach Solvay wird D2-5 ebenfalls auf Hp2 gestellt.
Das ist Zusiseitig korrekt, weil Zusi noch keine Rangierstrassen kann. Trotzdem sollte das Signal hier auf Hp0 bleiben weil der Zug dieses Signal nicht passiert.

Meine Lösung: ich habe aus den Rangiersignalen die Referenz auf das Koppelsignal D2-5 entfernt und in den Ausfahrzugstrassen den in Bild 2 markierten Eintrag zugefügt,
damit zeigt das Signal nur noch bei Ausfahrt Richtung Rheinberg Hp2,
bei Ausfahrt (Rangierfahrt) nach Solvay bleibt das Signal auf Hp0.

Bild3 ist zeigt eines der Sperrsignale, diese fungieren als Startsignale für die Fahrstrassen.

Wie gesagt das ist nur eine vorläufige Lösung bis Rangieren möglich ist. Gibt es eine einfachere Lösung?
Nachtrag, das Problem gäbe es auch wenn in Richtung Solvay ein 2. Gruppenausfahrsignal stehen würde...

Gruß Dieter

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 24.01.2022 20:39:11
von Michael Springer
Was wäre, wenn man Richtung Solvay in den Fahrweg ein 25iger Ereignis bauen würde und dann bei den Sperrsignalen noch eine weitere 25iger Zugfahrstraßen-Zeile hinzufügen würde. Dann könnte man ja in der neuen Zeile das Gruppen-Asig auf Hp0 konfigurieren. Oder?

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 25.01.2022 13:03:43
von dk48
Hallo Michael,
danke für diese Anregung - was meinst Du mit 25iger Ereignis im Fahrweg? (Ein weiterer 4. Eintrag im Sperrsignal ändert nichts)

Folgendes funktioniert so halbwegs:
Bild Bild Bild

Bild1: In den Sperrsignalen keine Verknüpfung mit dem Gruppenausfahrsignal unter Reiter 1, nur in der Kombinationsmatrix ein zusätzliches Ereignis mit Verknüpfung zum Gruppensignal auf Zeile 1 (Hp0)

Bild2: Die zugehörigen Fahrstrassen oben in Richtung Rheinberg wird da Gruppenausfahrsignal jetzt auf Zeile 0 (Hp1) verküpft, in der Zeile 0 kann man aber das Signalbild Hp2 einstellen - dann past es.
Fahrstr. in Richtung Solvay enthält nur das Sperrsignal - dadurch bleibt das Gruppenausfahrsignal in Grundstellung Zeile 1 (Hp0) (wenn man hier ein ncoh eine Verknüpfung Gr.Sig auf Zeile 1 einträgt ändert sich nichts)

Bild3: Bei der Fahrstrassenrzeugung werden die beiden Meldungen angezeigt, die gleichen Meldungen für dei beiden anderen Sperssignale fehlen... Diese Meldungen kan man wohl ignorieren?!

Gruß Dieter

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 25.01.2022 18:09:48
von Michael Springer
Nach der letzten Weiche Richtung Solvay einfach ein 25km/h Ereignis setzen. Dann das Gruppen-Asig so bauen wie in der Doku. Und einfach eine neue 25iger Zeile hinzufügen. Durch die 2. Geschwindigkeit hast eine Unterscheidung geschaffen. Das HSig musst halt so zusammenklickern, dass in der 40iger Zeile Hp2 und in der 25iger Zeile Hp0 zeigt.

Bild

Bild

Und im Fahrweg halt irgendwo im Fahrweg nach Solway nach der letzten Weiche ein Signalgeschwindigkeit 25.

Bild

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 26.01.2022 09:09:03
von dk48
Michael,

danke, jetzt funktioniert es - das Zauberwort war "Signalgeschwindigkeit".

Die Abhängigkeit dieses Ereignis zur Fahrstrassengenerierung war mit bisher nicht bekannt, das eröffnet viele Möglichkeiten.

Dieter

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 03.05.2022 19:53:49
von Alwin Meschede
viewtopic.php?p=333920#p333920
F. Schn. hat geschrieben: 13.01.2022 22:37:46 Das Feature ist für Augsburg Hbf entstanden um dort eine Lösung für die allein stehenden Zs3 zu finden, die am Esig vorsignalisiert werden.
Kann bei Gelegenheit eine Musterlösung für den gängigen Fall "Stumpfgleis, alleinstehndes Zs 3, Vorsignalisierung des alleinstehenden Zs 3 am Einfahrsignal" in https://zusiwiki.echoray.de/wiki/Intere ... truktionen dokumentiert werden? Habe ich es richtig verstanden, dass eine Vorsignalisierung am Einfahrsignal sich nicht von selbst ergibt, sondern immer durch Eingriff in die Signalmatrix des Einfahrsignals von Hand hergestellt werden muss?

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 03.05.2022 20:46:26
von F. Schn.
Erledigt. (Zumindest halbwegs.)
Ja (es ist im normal konfigurierten Einfahrsignal ja auch gar keine Zelle mit Vr0 + Zs3v vorhanden), theoretisch müsste es aber möglich sein, die Zeile "62" bei den Hauptsignalen flächendeckend anzulegen. (Praktisch gelangen wir da aber vermutlich an die Grenzen des Assistenten...)

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 03.05.2022 21:25:28
von Alwin Meschede
Danke.
F. Schn. hat geschrieben: 03.05.2022 20:46:26 theoretisch müsste es aber möglich sein, die Zeile "62" bei den Hauptsignalen flächendeckend anzulegen. (Praktisch gelangen wir da aber vermutlich an die Grenzen des Assistenten...)
Signalgeschwindigkeiten mit so einer Spezialbedeutung vorzubelegen ist wohl nicht sinnvoll, weil zum Beispiel die 62 von anderen Leuten auch für sonstige fahrwegabhängige Schaltungen verwendet wird. Und dann würden dort erstmal seltsame Dinge passieren.

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 07.07.2022 21:14:19
von F. Schn.
Neue Version 1.0.20:

Hintergrund ist, dass es bei der bisherigen Lösung für Halbregelabstand ein Problem gibt, wenn an Signal 9 ( https://zusiwiki.echoray.de/wiki/Intere ... n#Beispiel ) der Begriff Hp2 angezeigt werden kann. Dies ist in Augsburg der Fall. Bei der Untersuchung kam heraus, dass bei Ersatzsignal an Signal 3 Zusi Probleme hat, die Geschwindigkeitsbeschränkung auf 40 km/h korrekt an Signal AN aufzuheben. Daraufhin habe ich eine Lösung entwickelt, mit der man die Vorsignalgeschwindigkeit überschreiben kann, indem man in einer Matrix-Zelle ein Ereignis "Signalgeschwindigkeit" mit dem Text "vsig" platziert. Das Beispiel ist im Wiki dokumentiert. Hierbei sind nebenbei folgende Änderungen entstanden:

* Neu: Mit Ereignis "Signalgeschwindigkeit" und Text "vsig" kann die Geschwindigkeit kann die wirkame Vorsignalgeschwindigkeit - insbesondere bei Hochsignalisieren - überschrieben werden
* Fehlerbehebung: FahrstrGen konnte Geschwindigkeiten kleiner 0 km/h nicht voneinander unterscheiden. (Warburg, Hagen Hbf)
* Neu: In der Konsolenversion kann man in der Bedingungsdatei angeben, ob fahrstrGen automatisch alternative_fahrwege oder flankenschutz anlegen soll. (In der Graphischen Version habe ich den Implementierungsversuch wegen Problemen mit dem Testen abgebrochen.)

Re: Fahrstrassen-Generierung (fahrstr_gen)

Verfasst: 03.11.2022 17:09:48
von F. Schn.
Mal eine Frage: fahrstr_gen hat ja inzwischen den Funktionsumfang der Editor-Internen Fahrstraßenerstellung erreicht. Ich würde einfach mal in den Raum werfen, ob man nicht fahrstr_gen einfach in _Tools mitliefert und der Knopf im 3D-Editor nur noch fahrstr_gen aufruft. Da wäre meine Frage, ob da inzwischen noch etwas dagegen spricht?