DAS-BAHN-FORUM.de

@ richterjue: Du hast recht. Es wäre wieder eine Erweiterung, die Bahn nicht unbedingt vereinfacht. Ich hatte mir das aber eben als eine Art Zusatzfunktion vorgestellt, die optional verwendet werden kann, aber nicht muss. Somit bleibt die bisherige Funktionalität erhalten. Ich würde für eine einfache Blockstrecke auch weiterhin das derzeitige System verwenden. Sobald ich aber eine Aufzweigung signalisieren will, muss ich mit dem derzeitigen System unwahrscheinliche Kopfstände veranstalten, um das einigermaßen hinzukriegen.

Das Problem besteht ja in erster Linie tatsächlich nur bei Verzweigungen, alles andere ließe sich mit Bordmitteln recht gut machen. Ich denke, das Problem ist zunächst, dass sich Bahn von der Strab-Simulation mit Riesenschritten auch zu einer genialen Eisenbahnetzsimulation entwickelt hat. Angesichts der Tatsache, dass die Eisenbahnen nicht auf Sicht fahren, kann das derzeitige Signalsystem den Betriebsalltag der großen Bahn nicht wirklich abbilden. Dieses ist der sonstigen Versionsgeschichte mit mittlerweile beweglichen Pantograpen und sich öffnenden Türen leider etwas auf der Strecke geblieben.

Gerade die Anhängigkeiten der gesicherten Fahrwege ist ein wesentliches Merkmal eines Bahnnetztes (Stichwort: Trassen). Die Verquickungen, die das mitsich bringt, macht die Simulation des Netztes ja erst richtig interessant. Dein Lösungsvorschlag ist sicher praktikabel, hört sich allerdings nicht sehr flexibel an. Es scheint mir etwas schwierig zu sein, mal eben einen Zug operativ eine andere Strecke bei vollständiger Zugsicherung fahren zu lassen. Vielleicht, weil ich eine Störung (fabriziert) habe, weil gebaut werden soll oder weil vielleicht einfach nur die Lokführer mal wieder streiken

Deine Bedenken mit dem Umgang der Funktion bzw. dem Antlitz einer Programmiersprache teile ich grundsätzlich auch. Allerdings wächst der Mensch ja bekanntlich mit seinen Aufgaben. Zudem halte ich eine Fahrwegbeschreibung nach dem Muster : FS109;H591;W134,1;W132,2;H590 (Fahrstraße109, Start Signal H591; Weiche 134 Richtung1; Weiche 132 Richtung2; Ende Signal H590) letzlich für deutlich übersichtlicher, als die manchmal mit Zeiten und Linien zusammengewürfelten Bedingungsketten, die man in Taktpunkten oder Weichen oder sonstetwas eintagen kann. Auch könnte mein Verfahren das Verständnis von (dann nicht mehr notwendigen) hunderten verbundenen Signalanlage untereinander in etwas umfangreicheren Gleisplänen obsolet machen oder zumindest etwas abdämpfen.

Wenn ich hier im Forum surfe, stelle ich fest, dass unwahrscheinlich viele User sich (auch) mit Eisenbahn beschäftigen. Gerade für diejenigen wäre die Fahrstraßengeschichte sicher eine tolle Sache. Und ich bin überzeugt, dass dies neue Nutzer erschließen würde und vielleicht auch Ehemalige zurück holen dürfte.

Kern meines Vorschlags ist, dass sich der Zug (bei Verwendung dieser Option) eben nicht mehr seinen Weg selbst sucht, sondern am Signal gesagt bekommt, ob und wie er gefälligst zu fahren hat.

Die in der neuen Beta-Version mögliche Verknüpfung von Haltestelle und Signal kann man dann auch geniale Weise einsetzten. Wenn der Zug seine Abfahrtszeit erreicht hat, fordert er beim Signal Fahrt frei an. Ist die (Ausfahrt)straße frei, bekommt er diese reserviert und dann sein Grün. Er fährt los und kann auf dem Weg bis zum Signal dann auch von einer Flankenfahrt, die ein paar Sekunden schneller ist, nicht mehr gestoppt werden. Gerade solche Zusammenhänge machen den Reiz einer solchen Simulation aus.

Ich träume schon davon, wie wenig Aufwand das anstelle von hunderten Signalanlagen für den Dresdener Hauptbahnhof bedeuten würde, vom Einsparen wahnsinnigen Änderungsaufwands an den Signalanlagen bei einfachen Gleisplanänderungen mal abgesehen...

Wie denkt Ihr darüber???

Vilele Grüße

Matthias

Tagchen,

M Boden hat geschrieben:[...] Dein Lösungsvorschlag ist sicher praktikabel, hört sich allerdings nicht sehr flexibel an. Es scheint mir etwas schwierig zu sein, mal eben einen Zug operativ eine andere Strecke bei vollständiger Zugsicherung fahren zu lassen. Vielleicht, weil ich eine Störung (fabriziert) habe, weil gebaut werden soll oder weil vielleicht einfach nur die Lokführer mal wieder streiken [...]

Ein solcher Ansatz geht allerdings über den eigentlichen "Sinn" von BAHN deutlich hinaus: Derzeit wird im Wesentlichen ein Betriebsablauf unter normalen Bedingungen, also wie er im Regelfall ablaufen würde, dargestellt. Das künstliche Einbauen von großen Störungen, die während der Simulation dispositve Entscheidungen erfordern, ist da eine völlig andere Qualität. Wer schonmal mit einem professionellen Simulationstool gearbeitet hast, in dem solche Dinge explizit vorgesehen sind, der kann sich ungefähr vorstellen, wie weit BAHN davon noch entfernt ist und welchen Eingabeaufwand sowas bedeuten würde. Jede mögliche Dispositionsentscheidung muss man der Simulation nämlich vorher irgendwie beibringen, in dem man die entsprechenden Bedingungen und Restriktionen eingibt. Ganz einfaches Beispiel: Wenn ein Zug über eine andere Strecke umgeleitet werden soll, wäre es nett, wenn er irgendwann auch an sein eigentliches Ziel kommt und nicht planlos umherfährt. Für ein halbwegs komplexes Eisenbahnnetz sind das unzählige Informationen. Und dafür müssten ersteinmal Standards geschaffen werden.

Deine Bedenken mit dem Umgang der Funktion bzw. dem Antlitz einer Programmiersprache teile ich grundsätzlich auch. Allerdings wächst der Mensch ja bekanntlich mit seinen Aufgaben. Zudem halte ich eine Fahrwegbeschreibung nach dem Muster : FS109;H591;W134,1;W132,2;H590 (Fahrstraße109, Start Signal H591; Weiche 134 Richtung1; Weiche 132 Richtung2; Ende Signal H590) letzlich für deutlich übersichtlicher, als die manchmal mit Zeiten und Linien zusammengewürfelten Bedingungsketten, die man in Taktpunkten oder Weichen oder sonstetwas eintagen kann.[...]Wenn ich hier im Forum surfe, stelle ich fest, dass unwahrscheinlich viele User sich (auch) mit Eisenbahn beschäftigen. Gerade für diejenigen wäre die Fahrstraßengeschichte sicher eine tolle Sache. Und ich bin überzeugt, dass dies neue Nutzer erschließen würde und vielleicht auch Ehemalige zurück holen dürfte.

Wenn man sowas einführt, dann müsste es so einfach zu handhaben sein, dass quasi alle Eingaben automatisch erzeugt werden und man nur noch den jeweiligen Zügen/Linien/Zugtypen/... ihre Fahrwege/Fahrstraßen zuweisen braucht. Wenn man aber alles selber eingeben muss, wird das insbesondere die Nutzer, die schon vom "neuen" Signalsystem in BAHN 3.84 abgeschreckt wurden, nicht überzeugen.

Ich hatte mir das aber eben als eine Art Zusatzfunktion vorgestellt, die optional verwendet werden kann, aber nicht muss.

Das umzusetzen klingt immer so schön einfach, aber frag mal einen Programmierer...
Das alte System muss auch schon aus Gründen der Kompatibilität zunächst irgendwie erhalten bleiben.

Aus meiner Sicht wäre zum Beispiel folgender Ansatz denkbar: Hauptsignale können wahlweise mit dem jetzigen Signalsystem oder als Fahrstraßensignale funktionieren. Letztere würden so funktionieren, dass Züge sich an definierten Punkten (möglichst weit genug vor dem Vorsignal) ihre jeweilige Fahrstraße anfordern. Diese Anforderungen werden am Signal gespeichert. Wenn möglich, d.h. die Fahrstraße ist in ganzer Länge frei und nicht in Teilen bereits durch einen anderen Zug reserviert, wird diese Fahrstraße reserviert (so, wie jetzt an Kreuzungen auch Fahrwege reserviert werden können). Eine Fahrstraße reicht dabei stets von einem Hauptsignal zu einem anderen Hauptsignal oder auch zu einem anderen Zielelement (beispielsweise Gleisabschlüsse oder spezielle Elemente, die es derzeit noch nicht gibt). Für diese Fahrstraßen müsste es eine automatische Suchfunktion geben, die man bei Änderungen stets durchlaufan lassen müsste (in einem großen Netz könnte das u.U. Stunden dauern). Denkbar wäre ggf. auch ein spezieller Editor, bei dem man die Fahrstraßen z.B. mit der Maus eingibt (Startsignal, Weichen, Zielsignal, Auflösepunkte). Aber auch den müsste erstmal einer schreiben...

Für alle möglichen Sonderfälle (z.B. Vereinigen von Zugflügeln, Wenden im Gleis etc.) bräuchte man trotzdem noch spezielle Lösungen. Mit viel Programmieraufwand könnte man so ein System schaffen, welches halbwegs handhabbar ist und die wesentlichen Grundfunktionen der in Deutschland üblichen Eisenbahnsicherungstechnik darstellen kann. Das wäre sicher nicht ganz schlecht, aber eben doch nur eine Krücke, wenn man BAHN nicht zu einer wirklichen Stellwerkssimulation erweitern möchte.

Aber bevor man solche Dinge wie Fahrstraßen vorsieht, müssten aus meiner Sicht erstmal andere Defizite gelöst werden. Wir haben in BAHN beispielsweise immer noch nur eine rudimentäre, um nicht zu sagen eigentlich gar keine richtige Fahrdynamik. Solange es an solchen elementaren Dingen hapert, brauchen wir eigentlich nicht über Erweiterungen reden, die darauf aufbauen müssten.

MfG Jan

M Boden hat geschrieben:
Wie denkt Ihr darüber???

Hallo,

also ich fände es gut, wenn es diese Möglichkeiten geben würde.

Jan Eisold hat geschrieben: Ein solcher Ansatz geht allerdings über den eigentlichen "Sinn" von BAHN deutlich hinaus
...
Mit viel Programmieraufwand könnte man so ein System schaffen, welches halbwegs handhabbar ist und die wesentlichen Grundfunktionen der in Deutschland üblichen Eisenbahnsicherungstechnik darstellen kann. ...

Ich denke aber zum "Sinn" von BAHN und der Machbarkeit kann sich nur der Programmierer selbst äußern.

Grüße,


Sebastian

_________________
Potsdam und Umgebung im Jahr 1989

http://www.bahnbln89.homepage.t-online.de

Hallo Jan,

danke für Deine Meinung, auf die ich wie folgt antworten möchte:

Jan Eisold hat geschrieben:Tagchen,

M Boden hat geschrieben:[...] Dein Lösungsvorschlag ist sicher praktikabel, hört sich allerdings nicht sehr flexibel an. Es scheint mir etwas schwierig zu sein, mal eben einen Zug operativ eine andere Strecke bei vollständiger Zugsicherung fahren zu lassen. Vielleicht, weil ich eine Störung (fabriziert) habe, weil gebaut werden soll oder weil vielleicht einfach nur die Lokführer mal wieder streiken [...]

Ein solcher Ansatz geht allerdings über den eigentlichen "Sinn" von BAHN deutlich hinaus: Derzeit wird im Wesentlichen ein Betriebsablauf unter normalen Bedingungen, also wie er im Regelfall ablaufen würde, dargestellt. Das künstliche Einbauen von großen Störungen, die während der Simulation dispositve Entscheidungen erfordern, ist da eine völlig andere Qualität. Wer schonmal mit einem professionellen Simulationstool gearbeitet hast, in dem solche Dinge explizit vorgesehen sind, der kann sich ungefähr vorstellen, wie weit BAHN davon noch entfernt ist und welchen Eingabeaufwand sowas bedeuten würde. Jede mögliche Dispositionsentscheidung muss man der Simulation nämlich vorher irgendwie beibringen, in dem man die entsprechenden Bedingungen und Restriktionen eingibt. Ganz einfaches Beispiel: Wenn ein Zug über eine andere Strecke umgeleitet werden soll, wäre es nett, wenn er irgendwann auch an sein eigentliches Ziel kommt und nicht planlos umherfährt. Für ein halbwegs komplexes Eisenbahnnetz sind das unzählige Informationen. Und dafür müssten ersteinmal Standards geschaffen werden.

So komplex hatte ich mir das gar nicht vorgestellt.
Wenn ich in meinem Beispiel oben aber den Knoten Coswig bei laufenden Betrieb umbauen will und daher alle Züge von Leckwitz über die neue Spange nach Böhla umleiten möchte, kostet mich das nach meinem Vorschlag ein paar Vorbereitungen an vielleicht 5 Weichen, damit die Zuge wieder ankommen, wo sie sollen. Ich muß nicht unzähliche Signale und Signalanlagen umwidmen, damit alle auf der Strecke fahrenden Züge auch auf diese reagieren. Mit den derzeitigen Optionen reagieren auf ein Signal entweder alle Züge oder nur bestimmte Linien. Dabei sind Signale in Wirklichkeit doch strecken- und nicht liniengebunden.
Im Übrigen fährt ein Zug auch jetzt schon im Nebel rum, wenn ich meine Einstellungen an Weichen o.ä. nicht sauber gemacht habe. Insbesondere dann, wenn ein Zug zeitgebunden zum Einrücker gemacht wird, wegen einer Störung aber nicht an dem eigentlich vorgesehenen Ort ist. Da rückt bei mir eine Strab 8 schonmal über Hauptbahnhof nach Trachenberge ein

Deine Bedenken mit dem Umgang der Funktion bzw. dem Antlitz einer Programmiersprache teile ich grundsätzlich auch. Allerdings wächst der Mensch ja bekanntlich mit seinen Aufgaben. Zudem halte ich eine Fahrwegbeschreibung nach dem Muster : FS109;H591;W134,1;W132,2;H590 (Fahrstraße109, Start Signal H591; Weiche 134 Richtung1; Weiche 132 Richtung2; Ende Signal H590) letzlich für deutlich übersichtlicher, als die manchmal mit Zeiten und Linien zusammengewürfelten Bedingungsketten, die man in Taktpunkten oder Weichen oder sonstetwas eintagen kann.[...]Wenn ich hier im Forum surfe, stelle ich fest, dass unwahrscheinlich viele User sich (auch) mit Eisenbahn beschäftigen. Gerade für diejenigen wäre die Fahrstraßengeschichte sicher eine tolle Sache. Und ich bin überzeugt, dass dies neue Nutzer erschließen würde und vielleicht auch Ehemalige zurück holen dürfte.

Wenn man sowas einführt, dann müsste es so einfach zu handhaben sein, dass quasi alle Eingaben automatisch erzeugt werden und man nur noch den jeweiligen Zügen/Linien/Zugtypen/... ihre Fahrwege/Fahrstraßen zuweisen braucht. Wenn man aber alles selber eingeben muss, wird das insbesondere die Nutzer, die schon vom "neuen" Signalsystem in BAHN 3.84 abgeschreckt wurden, nicht überzeugen.

Eben! Wenn ich mir überlege, wieviele Signalanlagen man manchmal in den Signaldialogfeldern eintragen muss, auf die das Signal reagieren soll oder die es ein- oder ausschalten soll, wundert es mich nicht, dass es viele abschreckt. Das ganze ist manchmal so kryptisch, dass selbst erfahrene BAHNer micht mehr genau wissen, was sie tun. Man sieht ja nicht unbedingt auf den ersten Blick, welche Signalanlage man jetzt für genau welche Funktion vorgesehen hat.

Ich hatte mir das aber eben als eine Art Zusatzfunktion vorgestellt, die optional verwendet werden kann, aber nicht muss.

Das umzusetzen klingt immer so schön einfach, aber frag mal einen Programmierer...
Das alte System muss auch schon aus Gründen der Kompatibilität zunächst irgendwie erhalten bleiben.

Na ja, ein bissel programmieren kann ich auch
Natürlich soll das alte System erhalten bleiben. Für einfache Blockstrecken oder eben den Stab-Betrieb ist es unverzichtbar.

Aus meiner Sicht wäre zum Beispiel folgender Ansatz denkbar: Hauptsignale können wahlweise mit dem jetzigen Signalsystem oder als Fahrstraßensignale funktionieren. Letztere würden so funktionieren, dass Züge sich an definierten Punkten (möglichst weit genug vor dem Vorsignal) ihre jeweilige Fahrstraße anfordern. Diese Anforderungen werden am Signal gespeichert. Wenn möglich, d.h. die Fahrstraße ist in ganzer Länge frei und nicht in Teilen bereits durch einen anderen Zug reserviert, wird diese Fahrstraße reserviert (so, wie jetzt an Kreuzungen auch Fahrwege reserviert werden können). Eine Fahrstraße reicht dabei stets von einem Hauptsignal zu einem anderen Hauptsignal oder auch zu einem anderen Zielelement (beispielsweise Gleisabschlüsse oder spezielle Elemente, die es derzeit noch nicht gibt). Für diese Fahrstraßen müsste es eine automatische Suchfunktion geben, die man bei Änderungen stets durchlaufan lassen müsste (in einem großen Netz könnte das u.U. Stunden dauern). Denkbar wäre ggf. auch ein spezieller Editor, bei dem man die Fahrstraßen z.B. mit der Maus eingibt (Startsignal, Weichen, Zielsignal, Auflösepunkte). Aber auch den müsste erstmal einer schreiben...

Das deckt sich fast vollständig mit meiner Idee.
Was die Suchfunktion betrifft, weiß ich ehrlich gesagt aber nicht, wozu die dienen soll. Einen Editor halte ich auch nicht für unbedingt nötig. Ob ich jetzt in einem Signal 20 Signalanlagen oder später in einem Fahrstraßendialog 10 Fahrwegelemente eintragen muss, macht nicht wirklich einen Unterschied.

Für alle möglichen Sonderfälle (z.B. Vereinigen von Zugflügeln, Wenden im Gleis etc.) bräuchte man trotzdem noch spezielle Lösungen. Mit viel Programmieraufwand könnte man so ein System schaffen, welches halbwegs handhabbar ist und die wesentlichen Grundfunktionen der in Deutschland üblichen Eisenbahnsicherungstechnik darstellen kann. Das wäre sicher nicht ganz schlecht, aber eben doch nur eine Krücke, wenn man BAHN nicht zu einer wirklichen Stellwerkssimulation erweitern möchte.

Nun, hier könnte die Abwärtskompatibilität mit dem bestehenden System durchaus gute Dienste leisten. Wenn Rangierfahrten vom Signal ausgenommen werden könnten, könnten diese so arbeiten, wie bisher. Auch die Rangierfahrt kann schon jetzt nicht in einen reservierten Abschnitt einfahren, gleichwohl kann kein Zug (respektive Fahrstraße) in einen von einer Rangierfahrt reservierten Bereich eindringen.
Es geht auch weniger um die Sicherungstechnik bei der Eisenbahn, eher um deren Logik. Daher brauchts auch keine Stellwerkssimulation, weil es ja nicht unbedingt sein muss, dass man bei jeder Zugfahrt in Echtzeit die Signale selbst stellt.

Aber bevor man solche Dinge wie Fahrstraßen vorsieht, müssten aus meiner Sicht erstmal andere Defizite gelöst werden. Wir haben in BAHN beispielsweise immer noch nur eine rudimentäre, um nicht zu sagen eigentlich gar keine richtige Fahrdynamik. Solange es an solchen elementaren Dingen hapert, brauchen wir eigentlich nicht über Erweiterungen reden, die darauf aufbauen müssten.

Das sehe ich etwas anders. BAHN hat doch eigentlich eine völlig andere Intuition. Wer sich eine virtuelle Modellbahn bauen will, ist bei der Konkurrenz sicher besser aufgehoben. Da wird man aber kaum ganz Ostsachsen reinkriegen. ohne das der PC das rauchen anfängt. Man sollte die optische Detailtreue nicht zum Maß der Dinge machen. Dafür ist BAHN, glaube ich, nicht erfunden worden. Ich bin der Meinung, es dient der Simulation der Funktion eines Netztes und nicht dessen Aussehen.
Ausserdem hat man die Fahrdynamik mit Langsamfahrstellen und Vorsignalen für den eigentlichen Zweck des Programms recht gut im Griff...

MfG Jan

Ich danke Dir für Deine Antwort und deine Gedanken.

Viele liebe Grüße aus BaWü in meine (leider viel zu weit entfernte) alte Heimat

Matthias

Hallo zusammen,

Um nicht ein neues Thema Anfangen zu müssen, hänge ich meine Frage mal hier an.

Mich interresiert auch das Thema Fahrstraßen. Ich möchte sie hauptsächlich nutzen um meine Bahnhofs Ein-/Ausfahrten zu sichern. Das System von M Boden klingt für mich auch als Anwender Plausibel und baut auf die bisherige "Programiersprache" für Signalanlagen, Takt-/Rangier-/Datenwechsaelpunkte auf.

Derzeit Arbeite ich noch mit Bahn 3.84 und suche ein kleines Tutorial, das auch bei mir läuft. Darin sollte erklärt werden, wie ihr die Fahrstraßen mit Hilfszügen sichert. Das kann ich mir bis jetzt noch nicht richtig vorstellen. Kann mir da jemand eine Datei zur Verfügung stellen, in der die Einzelnen Schritte dazu gut Erklärt sind?

Hallo Faktory,

ich freue mich, dass es noch mehr gibt, "die auf der Suche sind".

Ich meine, auf irgendeinem Board hier schon mal etwas zu Fahrstraßen mit Hilfszügen gelesen zu haben, sogar mit Beispielnetz. Vielleicht bemühst Du mal die Suche.

Ich persönlich bin allerdings der Meinung, dass eine programmseitige Lösung auf alle Fälle besser wäre, als irgendwelche Hilfskonstrukte. Denn letztere benötigen eigentlich unnötig viel Rechenleistung und verbrauchen Kapazitäten, die sich woanders sicher gewinnbringender verwenden lassen. Die Übersichtlichkeit fördert das auch nicht unbedingt.

Ich habe die Hoffnung noch nicht ganz aufgegeben, dass Jan B. dieser programmlichen Horizonterweiterung in einer der nächsten Versionen entsprechenden Raum einräumt. Technisch habe ich (und andere) schon einige Vorschläge gemacht. Klar, die Machbarkeit entgültig bewerten kann nur der Entwickler. Der aber hat mit dem Programm etwas derart geniales geschaffen, dass ich nicht den geringsten Zweifel daran habe, dass er auch das hinbekommt.

Sobald ich etwas Zeit habe, würde ich hier in Form einer Art "Textstruktogramms" detailliert beschreiben, wie ich mir meinen Vorschlag vorgestellt habe. Also was an welchen Punkt welche Wirkung unter welchen Voraussetzungen eintreten soll und wie hier bereits vorhandene Funktionen (und das sind die meisten) einbezogen bzw. beeinflusst werden können. Es dürfte in der Tat so sein, dass mit wenig zusätzlichen oder modifizierten Elementen und der grundsätzlich ja schon mal vorhandenen "Programmiersprache" (der Signalanlagen) und den eindeutigen Elementbezeichnern das Projekt "Fahrstraßen" umsetzbar wäre.

Und dann machen wir unseren Stresstest für Stuttgart21 selber

Grüße

Matthias

Danke für die Antwort,

ich habe zwar eine Art Beispielnetz gefunden, jedoch konnte ich damit nicht viel Anfangen. Ich habe zum einen manche Logiken nicht ganz verstanden, zum anderen waren meiner Meinung nach einige Sachen veraltet. Zum Beispiel gab es vor jedem Anmeldekontakt extra Weichen, damit er für einige Züge nicht gilt. Aber die grundlegende Logik, die Hinter dieser Arbeit stand war leider für mich als Neueinsteiger in dieses Thema noch nicht ganz nachvollziehbar.

Ansonsten werde ich mich erstmal mit meinem "einfachen" System weiter behelfen. Nur habe ich in meinem Aktuellen Netz eine Stelle an der sich das mal gut austesten ließe.
2 sich kreuzende Fahrstraßen bei der Einfahrt, Kopf machen, Parallelausfahrt

mal sehen, ob ich doch noch was finden kann. Ich habe mir jetzt 3.86 als Shareware geladen. Baue jedoch erstmal weiter mit 3.84, da ich noch nicht weiß, wann ich das Geld habe, die Vollversion freischalten zu können.

Faktory

Faktory hat geschrieben: ...

Ich habe mir jetzt 3.86 als Shareware geladen. Baue jedoch erstmal weiter mit 3.84, da ich noch nicht weiß, wann ich das Geld habe, die Vollversion freischalten zu können.

Faktory

Das is als bestehender nutzer doch kostenlos?!

Hallo Daniel,

Kronprinz_Daniel hat geschrieben:
[...]
Das is als bestehender nutzer doch kostenlos?!

dass ist nur für einen sehr engen Kreis an Nutzern so! Und zwar für diejenigen, welche die BAHN-Version 3.85 nach dem 31.09.2010 bei JBSS registrieren lassen haben. Für alle anderen kostet die neue Lizenz wieder etwas. Siehe dazu auch auf die Seite von Jan Bochmann.

Grüße,
Matches

Matches hat geschrieben:Für alle anderen kostet die neue Lizenz wieder etwas.

Für die Besitzer von 3.84/3.85 kostet das Update 17,- €. Gut investiertes Geld. Vor allem weil Du was dafür bekommst (im Gegensatz zu den Ausgaben unseres Staates wg. Griechenland u.a.).
Das schreibt ein neuer registrierter 3.86-User (Update).

Gruß
Rolf

Moin,

die Paar Kröten die ein Upgrad auf eine neue Version kostet sind nicht die Welt,
für Bahn ist es völlig egal, ob es 17 oder 30 Tacken sind, denn Bahn ist das Geilste was es auf dem Markt gibt.
Es kann kein Programm mit Bahn mithalten!!!

Gruß

Mark

Hi,

und wo kann JanBo die Tacken zu welchem Kurs in Euronen tauschen
Im Übrigen haste vollkommen recht: BAHN forever

Gruß
Gerd

Hallo zusammen,

ich Frage mich, ob es möglich wäre die Ein- und Ausfahrsignale mit den "Fahrwegsanforderungen" der Züge zu Verknüpfen? Das wäre doch dann fast schon eine "Fahrstraßen Schaltung".
Ein Zug fährt auf ein Einfahrsignal zu, Reserviert seinen Fahrweg und wenn der mit einer Zuglänge nach dem Ausschaltkontakt frei ist wechselt das Signal von rot auf grün.

Gruß vom Pfälzer Charly

Nachdem hier jetzt schon einige in verschiedenen Beiträgen so etwas wie eine rudimentäre Fahrstraßenlogik wollen, möchte ich meine Idee etwas plastischer darstellen.
Klar ist, das BAHN trotz erweiterter Signalanlagensteuerung für die EisenBAHNer bei komplizierten Gleislagen ohne aufwändige Umbauten wie Hilfssignalen für den Kreuzungsverkehr oder Hilfskonstruktionen kaum eine Möglichkeit zur Simulation von tatsächlichen Abhängigkeiten bietet. Aber grade bei einer Netzsimulation sind es solche Faktoren, die im realen Leben „Probleme“ verursachen. Insbesondere bei Fahrten über das Gegengleis benötigt man jetzt ein zusätzliches Signal nach dem Abzweig oder blockiert bei Geradeausfahrten unnötig die Gegenrichtung. Im Prinzip muss man die Signale nach den Abzweig setzten, was im wahren Leben wohl kaum vorkommt. Die Steuerung nur über Linien halte ich für unflexibel.

Ich möchte daher am Beispiel Leckwitz (siehe unten) meine Idee nochmals erläutern.

Wie bereits erwähnt, müsste man Fahrwege vordefinieren. Im Beispiel wären für H101 folgende Fahrwege möglich:
- nach Böhla und
- nach Coswig
Für dieses Signal könnte die Fahrwegbeschreibung nach Böhla so aussehen: „Leck101B;1340,1;388,1;1339,1;SigAnl10;K702:SigAnl10,Z;SigAnl20,F“
(Fahrstraße Leck101B, Weiche 1340 Richtung1; Weiche 388 Richtung1; Weiche 1339 Richtung1; Signalanlage SigAnl10=0? (also Strecke frei?) ,Ende Kontakt K702 [und nach dem Doppelpunkt] erhöhe SigAnl10 um 1 beim Überfahren von mir zähle Züge; erhöhe SigAnl20 um 1 beim Überfahren von mir zähle Fahrzeuge)
Nach Coswig dann so:
„Leck101C;1340,1;388,2;SigAnl11;K707:SigAnl11,Z“
(Fahrstraße Leck101C, Weiche 1340 Richtung1; Weiche 388 Richtung2; Signalanlage SigAnl11=0?,Ende Kontakt K707 [und nach dem Doppelpunkt] erhöhe SigAnl11 um 1 beim Überfahren von mir zähle Züge)
Zunächst kompliziert, aber mit etwas Übung einfacher als die Konstruktion mit einem Haufen Signalanlagen pro Signal. Weichen, die im Fahrweg vorhanden sind, aber nicht in der Liste genannt werden, sind entweder stumpf oder werden in der Hauptrichtung befahren.

Jetzt muss man die Fahrstraßen mit den Linien (und ggf. Kursen nach bereits vorhandener Definition) verknüpfen:
- Die Linie ICE1 kommt von Riesa, hält nicht an Hst1 und fährt nach Böhla: wir tragen an V698 ein ICE1:Leck101B
- Die Linie RE1 kommt von Riesa, hält an Hst1 und fährt nach Coswig: wir tragen an H101 ein RE1:Leck101C
- Kommt ein Zug, dessen Liniennummer nicht hinterlegt ist, wird am Hauptsignal (und auch erst dort) die erste, in der Liste genannte Fahrstraße verwendet, dieser Zug wird ab dem Vorsignal erstmal runterbremsen müssen.

Lassen wir mal einen ICE1 fahren:
- er kommt von Riesa und fährt an V698, hier sendet er seine Linien-/Kursnummer an das hier verknüpfte Hauptsignal (H101)
- H101 schaut nach: ah ja, ICE1 fährt über Leck101B
- H101 legt Weiche 1340 in Stellung 1, W338 auch, ignoriert W1338 und legt W1339 in Stellung 1. Jetzt guckt es, ob SigAnl10 „frei ist“ und der restliche Fahrweg bis K702 auch. (Ein Zug in BAHN reserviert ja bereits heute seinen Fahrweg mindestens um Zuglänge. Jetzt müsste das das Signal übernehmen, nur eben bis zum definierten Endpunkt)
- Ist dies alles korrekt, erhöht es die SigAnl 10 und 20 um 1 und geht selbst auf Fahrt frei. Mit SigAnl10 wird diese Strecke reserviert, mit SigAnl20 der Bahnübergang geschlossen. Gleichzeitig geht V698 auf „frei“ und ICE1 fährt ohne zu bremsen durch Leckwitz
- beim Überfahren von H101 fällt das Signal auf Halt, die Signalanlage 10 wurde ja schon um eins erhöht (vorgeblockt), deshalb passiert bei Ihr nix mehr. SigAnl20 ist zum Fahrzeuge zählen konfiguriert, also werden diese beim Überfahren von H101 gezählt.
- Alle reservierten Fahrwegelemente werden wieder frei, wenn das letzte Fahrzeug sie verlassen hat (macht BAHN ja jetzt schon)
- Am K702 werden die Fahrzeuge wieder runtergezählt, wenn nicht zufällig ein Gegenzug kommt, gehen die Schranken wieder auf
- ICE 1 wird dann in Böhla SigAnl10 auf 0 setzen (rückblocken) mit den schon vorhandenen Mechanismen.
- alles kann von vorn beginnen

und jetzt ein RE1:
- er kommt von Riesa und fährt an V698, hier ist die Linie nicht hinterlegt, es passiert also nix, außer dass er gemäß Vorgaben bei „Halt erwarten“ abbremst.
- an Hst1 steht er und die Wartezeit läuft ab.
- jetzt schickt er vom Haltepunkt seine Linien-/Kursnummer zum verknüpften Signal H101. Dieses schaut nach: der RE1 fährt über Leck101C
- H101 legt Weiche 1340 in Stellung 1, W338 in Stellung 2. Jetzt guckt es, ob SigAnl11 „frei ist“ und prüft den restlichen Fahrweg bis K707.
- Ist dies alles korrekt, erhöht es die SigAnl 11 um 1 und geht selbst auf Fahrt frei. Mit SigAnl11 wird diese Strecke reserviert.
- Jetzt meldet H101 an Hst1 die Abfahrbereitschaft zurück und RE1 fahrt an.
- beim Überfahren von H101 fällt das Signal auf Halt, die Signalanlage 11 wurde ja schon um eins erhöht (vorgeblockt), deshalb passiert bei Ihr nix mehr.
- Alle reservierten Fahrwegelemente werden auch hier wieder frei, wenn das letzte Fahrzeug sie verlassen hat .
- RE 1 wird dann in Coswig SigAnl11 auf 0 setzen (rückblocken).

Kreuzungs-, Nach- oder Flankenfahrten werden ohne viel Tam-Tam verhindert, weil irgendein Fahrwegelement bei der Prüfung eben nicht frei ist. Im Beispiel des ICE oben wäre es so, wenn eine Kreuzungsfahrt von Coswig stattfindet, dass er am V698 „Halt erwarten“ kriegen würde. Er müsste bremsen und am H101 erneut prüfen, ob sein Fahrweg frei ist. Oder wenn eine folgende Streckenblocksignalanlage nicht frei ist, ebenso.

Für die anderen beiden Hauptsignale sind die gleichen Einstellungen notwendig. Das macht man aber auch nur einmal und es ist auch nicht aufwändiger, als dies mit zig verketteten Signalanlagen zu realisieren. Vor allem ist es übersichtlicher.

Ende der Prüfstrecke ist die Haltestelle, der Taktpunkt, ein Signal oder ein anderes nummeriertes Element. Trotzdem sollte aus Sicherheitsgründen die Fahrwegprüfung auf maximal 150 bis 200 Elemente begrenzt werden. Zur Streckenblocksicherung sind ja auch die bereits vorhandenen Signalanlagen perfekt und mehr als ausreichend.

Folgende Elemente müssten aus meiner Sicht angepasst werden:
- Taktpunkte/ Haltestellen, Vorsignale, kombinierte Signale, evtl. Rangierpunkte; sie müssten insofern erweitert werden, dass sie eine Fahrweganforderung an das mit ihnen verknüpfte Hauptsignal zur Prüfung weiterleiten, alle anderen Funktionalitäten bieten die Elemente ja schon.
- Hauptsignale, kombinierte Signale; sie müssten um die beschriebene Fahrwegprüfung erweitert werden.
- Weichen; hier bräuchte es einen Typ, der in einer durch die Fahrwegprüfung festgelegten Lage reservierbar ist, bis sie überfahren ist
- Signalanlagen: Wenn diese als Schutzanlagen (BÜ/ Schranke) eingesetzt werden, wäre es cool, wenn man diese bei erfolgreicher Fahrwegprüfung schließen könne. Das Signal wäre hier dann gleichzeitig Deckungssignal. Eine Auslösung mittels Schaltfunktion (wie bereits möglich) wäre nicht so gut, könnte ja sein, dass der Zug vor dem BÜ „abbiegt“. Die „Fahrstraße“ sollte eine Signalanlage „anstupsen“ können (Schranke schließt) und das (Start-)Signal dann ggf. die Zählung der Fahrzeuge übernimmt (sofern dies eingestellt ist). Die Funktion könnte man dann auch für das Vorblocken verwenden.
- Rangierpunkte und Haltestellen müssten optional nummerierbar sein, damit man sie als eindeutige Fahrwegelemente (als Endpunkt z. Bsp. bei Wendefahrten) verwenden kann

Ich bin der Meinung, dass so etwas mehr Struktur in die Netze bringen kann. Bei der großen Eisenbahn wird eben nicht auf Sicht gefahren, sondern im Raumabstand. Das konnte BAHN bislang nur unzureichend berücksichtigen.
Ich möchte betonen, dass dies aus meiner Sicht immer noch keine Stellwerkssimulation ist, auch wenn gewisse Algorithmen tatsächlich von hier entstammen, sondern lediglich grundlegende Abhängigkeiten in die Simulation implementiert. Diese Abhängigkeiten sind für ein Netz elementar, weshalb sie nicht fehlen sollten. Letztlich besteht ja aber immer noch keine Möglichkeit, Fahrten manuell zu steuern, wie das auf einem Stellwerk gemacht wird.

Die bisherigen Hilfskonstrukte mit vielen offenen oder verborgenen Signalanlagen bindet haufenweise Ressourcen und macht große Projekte absolut unübersichtlich. Vieles kann BAHN schon, den Rest müsste man weiterentwickeln.

Was denkt Ihr darüber? Würde mich über eine gute Diskussion, auch über Details, die mir „durchgegangen“ sind, sehr freuen.

Euch allen einen Guten Start ins neue Jahr…

Hallo
Kannst Du M Boden Deinen Beitrag bitte so ändern das er nicht dem Rahmen (Breite)des Forums sprengt ?
Sonst wäre es schön wenn dies ein hier zuständiger Admin übernehmen könnte. Die Darstellung ist so zu unübersichtlich wenn man erst hin und her schieben muß !!
MfG Daniel

Edit: Denke das liegt an dem Bild weil unangemeldet sieht man dieses nicht und da paßt der Beitrag in den Rahmen.