Ja, Zs 2. Debug sagt "...hat Richtungs- oder Gegengleisanzeiger (Zeile noch unbekannt)".Johannes hat geschrieben:Irgendwelche Richtungs- oder Gegengleisanzeiger in der Matrix?
Fahrstrassen-Generierung (fahrstr_gen)
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Fahrstrassen-Generierung (fahrstr_gen)
Zuletzt geändert von Alwin Meschede am 25.06.2020 11:20:08, insgesamt 1-mal geändert.
Mein Youtube-Kanal: youtube.com/echoray1
- Johannes
- Beiträge: 3216
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Fahrstrassen-Generierung (fahrstr_gen)
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.
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Fahrstrassen-Generierung (fahrstr_gen)
Danke für die Erläuterungen!
Mein Youtube-Kanal: youtube.com/echoray1
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Fahrstrassen-Generierung (fahrstr_gen)
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
Mein Youtube-Kanal: youtube.com/echoray1
- Johannes
- Beiträge: 3216
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Fahrstrassen-Generierung (fahrstr_gen)
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!
* 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!
- Johannes
- Beiträge: 3216
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Fahrstrassen-Generierung (fahrstr_gen)
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?
* Allein stehende Zs 3 werden unterstützt.
Die Funktion hat F.Schn. implementiert, vielen Dank. Vielleicht magst du noch mehr dazu sagen?
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Fahrstrassen-Generierung (fahrstr_gen)
Sieht aus als ob irgendein Fehler drin ist. Gegenüber der Vorgängerversion nimmt die neue Version in Hildesheim Hbf Änderungen folgender Art vor:
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.
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
Mein Youtube-Kanal: youtube.com/echoray1
Re: Fahrstrassen-Generierung (fahrstr_gen)
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.
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.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
-
- Beiträge: 3197
- Registriert: 07.03.2002 10:09:59
- Aktuelle Projekte: Objektbau und Modulgestaltung
- Wohnort: Dortmund
Re: Fahrstrassen-Generierung (fahrstr_gen)
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.
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:
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....
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....
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.
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:
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....
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....
tschüs....
Jürgen
Jürgen
Re: Fahrstrassen-Generierung (fahrstr_gen)
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.
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.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
Re: Fahrstrassen-Generierung (fahrstr_gen)
Ich habe den Fahrstrassengenerator ausprobiert und hoffte das folgenden Problem damit auf elegante Weise lösen zu können:
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
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
https://dk-nbahn.de ---> Projekt RB31 https://dk-nbahn.de/ba/rb31.php
- Michael Springer
- Beiträge: 2933
- Registriert: 24.06.2002 16:22:44
- Wohnort: Schwäbisch Gmünd
Re: Fahrstrassen-Generierung (fahrstr_gen)
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)
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:
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
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:
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
https://dk-nbahn.de ---> Projekt RB31 https://dk-nbahn.de/ba/rb31.php
- Michael Springer
- Beiträge: 2933
- Registriert: 24.06.2002 16:22:44
- Wohnort: Schwäbisch Gmünd
Re: Fahrstrassen-Generierung (fahrstr_gen)
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.
Und im Fahrweg halt irgendwo im Fahrweg nach Solway nach der letzten Weiche ein Signalgeschwindigkeit 25.
Und im Fahrweg halt irgendwo im Fahrweg nach Solway nach der letzten Weiche ein Signalgeschwindigkeit 25.
Re: Fahrstrassen-Generierung (fahrstr_gen)
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
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
https://dk-nbahn.de ---> Projekt RB31 https://dk-nbahn.de/ba/rb31.php
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Fahrstrassen-Generierung (fahrstr_gen)
viewtopic.php?p=333920#p333920
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?
Mein Youtube-Kanal: youtube.com/echoray1
Re: Fahrstrassen-Generierung (fahrstr_gen)
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...)
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...)
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: Fahrstrassen-Generierung (fahrstr_gen)
Danke.
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.
Mein Youtube-Kanal: youtube.com/echoray1
Re: Fahrstrassen-Generierung (fahrstr_gen)
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.)
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.)
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
Re: Fahrstrassen-Generierung (fahrstr_gen)
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?
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat