DAS-BAHN-FORUM.de

Hallo zusammen,

ich möchte mich doch endlich auch einmal in diesem Forum anmelden und einen Vorschlag zum Besten geben.

Ich weiß, dass BAHN eine Netz- und keine Stellwerkssimulation ist, und doch möchte ich das Problem "Fahrstraßen" nochmals aufgreifen, obwohl es im Forum bereits mehrfach diskutiert wurde.

Als Exil-Dresdener beschäftige ich mich nunmehr seit mehreren Jahren mit der realistischen Nachgestaltung des ÖPNV und SPNV in Ostsachsen.

Das Programm ist genial, da sind wir uns sicher alle einig... Tatsache ist aber, dass die Fahrwegsicherung in komplexen Bahnhöfen momentan äußerst schwierig ist. Daher könnte ich mir eine Art Spurplansystem vorstellen. Einige der benötigten Funktionen hat BAHN ja schon.

Vielleicht könnte eine Umsetzung folgendermaßen aussehen:

Zunächst erstellt man eine Liste der Fahrstraßen. Hier definiert man die Fahrwege mit Startpunkt (Hauptsignal) und einem Zielpunkt (nächstes Hauptsignal oder einer neu zu schaffenden Ra 10-Tafel). Eine solche FS könnte Intern dann so aussehen: FS109;H591;W134,1;W132,2;H590 (Fahrstraße109, Start Signal H591; Weiche 134 Richtung1; Weiche 132 Richtung2; Ende Signal H590). So werden zunächst alle nötigen Fahrstraßen definiert. (Richtig toll wäre es, wenn sich auch Bahnübergänge einbinden ließen, aber ich will ja nicht gleich übertreiben)

Die örtlich möglichen Fahrstraßen werden den betreffenden Hauptsignal bekanntgemacht, mit der Angabe, welche FS das Signal bei welcher Linie bei Annäherung "eingelegt" werden soll. Auch könnte man noch (ein bis zwei) Alternativfahrstraßen angeben, die ersatzweise eingelegt werden können, sollte die eigentliche Trasse belegt sein. (Wie bei Lenkziffern)

Ob jetzt aber ein Zug eine Strecke frei prüft und reserviert, oder ob das ein Signal tut, dürfte ja eigentlich egal sein. Denn Zug wie auch Signal müssten die Freiheit nicht ständig, sondern nur nach Anforderung prüfen und ggf. reservieren. Ist ein Teil des angeforderten Fahrwegs blockiert müssen Zug wie auch Signal ohnehin regelmäßig dessen Freiwerden erneut prüfen.

Die Signale mit benutzter Fahrstraßenfunktionalität sind in Grundstellung "Halt". Nähert sich jetzt ein Zug einem definierten "Anforderungspunkt" (z. Bsp. dem zugehörigen Vorsignal, kombinierten Signal oder einem Kontakt) erhält das Hauptsignal die Liniennummer und prüft den/die mit der Line verknüpte(n) Fahrstraße(n) und reserviert den Fahrweg bis zum entsprechenden Endpunkt. War dies erfolgreich, schaltet das Hauptsignal auf Fahrt frei, das Vorsignal folgerichtig auf Frei erwarten.

Die Freigabe nicht mehr benötigter Teil-Fahrstraßen (respektive reservierte Elemente) erfolgt dann ja m.W. unmittelbar nach dem Überfahren des Zuges, sodass Kreuzungswege schnell wieder frei gegeben werden können.

Beim Wenden innerhalb einer reservierten Strecke könnte der Rangierpunkt das Auflösen einer "Restfahrstraße" übernehmen.

Bei diesem Konstrukt wären Querfahrten, Flankenfahrten und auch Nachfahrten zuverlässig ausgeschlossen, eine Art Bahnhofsblock inklusive. Die Zahl der Signalanlagen und der benötigten Elemente ließe sich drastisch reduzieren und somit auch die hierfür behötigte Hardwarekapazität...

Der oben beschriebene Vorgang wäre prädestiniert für Einfahrstraßen und/ oder Verzweigungen.

Für Ausfahrstraßen und Zusammenführungen könnte dies mit der Funktionalität der "alten" Signalanlagen als Zählschleifen für den Streckenblock kombiniert werden. Soll heißen, der Fahrweg innerhalb des Bhf. ist frei UND die dahinter befindliche Strecke ist frei, geht das Signal auf Grün (und schaltet gleichzeitig den Streckenblock (Signalanlage) dahinter auf „belegt“). Hierbei wäre dann nicht unbedingt ein Signal, sondern evtl. eine neu zu schaffende RA 10-Tafel oder ein Kontakt oder sonst was der "Endpunkt" der Bahnhofsfahrstraße und Übergang auf die freie Strecke. Dies entspräche fast der Spurplantechnik bei Stellwerken.

Man müsste hierzu die Signale mit der Fahrstraßenfunktionalität nachrüsten, allerdings unter Beibehaltung der bisherigen Funktionen, die dann ggf. nur nicht benutzt werden. Dies dient der Abwärtskompatibilität.

Haltestellen oder Taktpunkte könnten bei Erreichen der Abfahrtszeit zunächst beim zugehörigen Signal am Bahnsteigende das "Frei" anfordern und überprüfen und bei Erfolg den Zug abfahren lassen. (Hierbei würden die Züge bei rotem Signal auch am Taktpunkt/Haltestelle warten bis das Signal Grün ist). Diese müssten dann hierfür auch entsprechend "nachgerüstet" werden.

Straßenbahnstrecken, Blockstrecken und BÜ's können ja mit den bereits jetzt vorhandenen Bordmitteln hervorragend umgesetzt werden, weshalb das auch weiterhin so sein kann.

Hot stuff, oder?

Das ganze dürfte aber sicher ressourcenschonender sein als Konstrukte mit Hilfszügen im Untergrund o.ä. Einige Funktionalitäten sind ja in BAHN schon vorhanden. Auch viele jetzt notwendige Zwischensignale und Signalanlagen (in Funktion als reiner Zählkreis) könnten dann auch eingespart werden.

Fehler die man hierbei machen kann, wären nach dem derzeit vorhandenen System genauso möglich. Und wem das "neue" System zu kompliziert ist, kann ja aufgrund der zusätzlichen Implementierung auch weiterhin die vorhandenen Möglichkeiten nutzen.

Ich hab zwar einige Programmiererfahrung, aber ob meine Vorschläge in den BAHN-Quelltext reinpassen, kann natürlich nur Jan Bochmann entscheiden. Ich für meinen Teil wäre aber bei diesen Features mit Handkuss bereit, mindestens den doppelten Preis für eine neue Lizenz zu bezahlen.

Viele Grüße von der schwäb. Alb

Matthias Boden

Hallo Matthias (und alle anderen),

abgesehen davon, dass ich glaube, dass das alles einfacher klingt, als es programmiertechnisch umzusetzen ist, wäre auch die Akzeptanz auf Nutzerebene wohl deutlich fraglich.

Versteh mich nicht falsch - ich fände ein solches System wundervoll. Aber viele BAHN-Nutzer sind augenscheinlich schon mit aktuellen Neuerungen wie dem neuen Signalsystem überfordert bzw. sehen keinen Zusatznutzen darin - die Fahrstraßenabhängigkeit würde folglich wohl für den Großteil der aktiven Nutzer dann auch keinen Vorteil darstellen.

Ob dann dafür Leute bereit sind, mehr zu bezahlen, würde mich überraschen.

Ich wäre dankbar, wenn mich jemand bzgl. der Thesen der Komplexität und der Implementierungsschwierigkeiten widerlegen würde und mir das Gegenteil beweist - und würde mich über die Implementierung einer Fahrstraßenlogik sehr freuen!

Viele Grüße aus Heilbronn

Johannes Friedrich

Hallo Johannes,

natürlich ist ein Fortschritt mit Umfang verbunden. Wie heißt es so schön: Tradition ist weitergeben des Feuers und nicht bewahren der Asche". Bahn ist hervorragend. Aber offen gestanden, viele hier reden davon, dass es sich um eine Netzsimulation handelt und um keine virtuelle Modelleisenbahn. Dann hätte man aber auch auf den Unsinn mit Soundpunkten oder Zoom4 verzichten müssen. Bei einer Netzsimulation geht es primär um Funktionalität und weniger um Optik.
JB hat dem Druck aber offenbar trotzdem nachgeben müssen. Mir wäre aber eine rudimentäre Fahrstraßenlogik zehnmal lieber, als sich an Haltestellen öffnende Türen. Zumal Grafikoperationen die von vielen Usern beschworenen Hardwaregrenzen wohl eher herausfordern, als eine Programmlogik im Hintergrund. Und wie gesagt, für virtuelle Modellbahnanlagen gibt es andere Produkte.
Ein großer Teil meines Vorschlages basiert ohenhin auf bereits, zwar in anderer Form, aber dennoch vorhandenen Technologien. Auch ahtte ich vorgeschlagen, dies zusätzlich zu implementieren, damit diejenigen, die nicht damit arbeiten wollen, dies auch nicht müssen. WORD hat ungegheuer viele Funktionen, die kaum einer alle kennt. Trotzdem wird das Programm rege genutzt.
BAHN kommt quasi aus der Straßenbahnecke. Linen, feste Fahrwege etc. Wenn BAHN auch die Eisenbahn einschließen möchte, ist ein Tecnologievortschritt vonnöten und keine Korrekturen an der Fassade. Bahn ist ahlt eher für die "Verkehrsingenieure" gemacht, weniger für die "Landschaftgärtner"
Ich werde BAHN auf jedem Fall treu bleiben, ob mit oder ohne Fahrstraßen. Das Programm ist einfach genial. Das ich persönlich auch mehr bezahlen würde, ist meine subjektive Meinung, basierend auf JB's Aussage auf der Homepage "Wer will, der kann."

Johannes, ich danke Dir für Deine Meinung und freue mich auch weiterhin auf eine rege Diskussion.

Grüße

Matthias

Hallo Matthias,

natürlich ist ein Fortschritt mit Umfang verbunden. Wie heißt es so schön: Tradition ist weitergeben des Feuers und nicht bewahren der Asche". Bahn ist hervorragend. Aber offen gestanden, viele hier reden davon, dass es sich um eine Netzsimulation handelt und um keine virtuelle Modelleisenbahn. Dann hätte man aber auch auf den Unsinn mit Soundpunkten oder Zoom4 verzichten müssen.

Darüber gibt es verschiedene Ansichten und Meinungen. Für mich ist BAHN eine Modellbahn-Simulation mit der ich eine reale Eisenbahn-Situation wesentlich komfortabler darstellen kann, als im HO-, N- oder wasauchimmer-Maßstab darstellen kann. Mal abgesehen von den Investitionskosten.
Und unter diesen Gesichtspunkt ist z.B. ein Soundpunkt oder Zoom2 oder 4 sicher nichts schlechtes. Gut -ob es unbedingt Zoom4 sein muss, lass ich mal offen. Ich brauch's nicht und hab' es auch entsprechend ausgeschaltet.

Bei einer Netzsimulation geht es primär um Funktionalität und weniger um Optik.

Richtig. Aus meiner Sicht auch gut so.

JB hat dem Druck aber offenbar trotzdem nachgeben müssen.

Nee - also müssen glaub' ich nicht. Aber Jan ist auch jemand, der sich nicht hinstellt nach dem Motto "Hier bin ich, dann kommt lange nix, dann komm' ich nochmal", sondern der zuhört und mitliest. Und diese Wünsche wurden ja in der Vergangenheit des öfteren geäußert. Er hat es nur umgesetzt. Klar, dass das nicht jeden glücklich machen kann und dass es auch Leute gibt, die diese Funktionen unnötig finden - ich gehöre ja auch dazu. Ich brauche z.B. auch keine sich öffnende Tür an den Haltestellen, zumal es in meinem Netz auch viele Haltestellen gibt, die nicht an Bahnsteigen liegen.

Mir wäre aber eine rudimentäre Fahrstraßenlogik zehnmal lieber, als sich an Haltestellen öffnende Türen.

Zur Fahrstraßenlogik hätte ich eine Idee, die ich gleich beschreiben möchte. Zum Haltestellen hab' ich ja gerade was geschrieben.

Zumal Grafikoperationen die von vielen Usern beschworenen Hardwaregrenzen wohl eher herausfordern, als eine Programmlogik im Hintergrund. Und wie gesagt, für virtuelle Modellbahnanlagen gibt es andere Produkte.

Zum Thema "Speicher" geb' ich Dir recht.
Zum Thema "andere Programme" natürlich auch. Aber: BAHN ist in seiner jetzigen Form irgendwo einzigartig. Was würde passieren, wenn BAHN nun eine Fahrstraßenlogik bekäme? Es wäre vergleichbar mit anderen Stellwerkssimulationen, die zwar wesentlich weniger Funktionalität aufweisen würden, aber durch ihre Grafik Vorzüge hätten (siehe z.B. die Simualtion ESTW Win). Es gäb sicherlich nicht wenige User, die sich wegen der Grafik für ein anderes Produkt entscheiden würden.

Ein großer Teil meines Vorschlages basiert ohenhin auf bereits, zwar in anderer Form, aber dennoch vorhandenen Technologien. Auch ahtte ich vorgeschlagen, dies zusätzlich zu implementieren, damit diejenigen, die nicht damit arbeiten wollen, dies auch nicht müssen. WORD hat ungegheuer viele Funktionen, die kaum einer alle kennt. Trotzdem wird das Programm rege genutzt.

BAHN mit WORD zu vergleichen ist schon ein Hammer Zum Thema WORD glaube ich eher, dass es auch deshalb genutzt wird, weil es ja mit WIN auf fast jeden Rechner installiert ist und es letztlich einfacher ist, dass Programm zu behalten als es zu desinstallieren.

BAHN kommt quasi aus der Straßenbahnecke. Linen, feste Fahrwege etc.

BAHN kommt aus der Straßenbahn-Ecke. Es ist ja eine Weiterentwicklung von STRABA.

Wenn BAHN auch die Eisenbahn einschließen möchte, ist ein Tecnologievortschritt vonnöten und keine Korrekturen an der Fassade. Bahn ist ahlt eher für die "Verkehrsingenieure" gemacht, weniger für die "Landschaftgärtner"

.

Genau!
Ich würde aber nicht alles als Fassaden-Korrektur bezeichnen, sondern es sind auch viele Dinge im Laufe der Zeit neu entstanden, die es uns als User einfacher gemacht haben wie z.B. das Signal-System.

Ich werde BAHN auf jedem Fall treu bleiben, ob mit oder ohne Fahrstraßen. Das Programm ist einfach genial. Das ich persönlich auch mehr bezahlen würde, ist meine subjektive Meinung, basierend auf JB's Aussage auf der Homepage "Wer will, der kann."

Das ist natürlich sehr löblich, aber hier widersprichst (das Wort ist zu hart, ich finde nur gerade kein passendes) Du Dich: Du forderst zwar einen Technologie-Fortschritt mit der Fahrstraßen-Technik, kannst aber auch drauf verzichten. Außerdem hat das Programm ja Deiner Meinung nach auch ohne Fahrstraßen eine gewisse Genialität.

Gruß
Rolf
in Teil 2 mein Vorschlag für die Fahrstraßentechnik mit BAHN

Mein Vorschlag schließt sich an Matthias' Vorschlag an:

Für die Fahrstraße ("FS") könnte man wie folgt vorgehen:

Festlegung der FS:
Ähnlich einer Signalanlage ("SA"). Im Gegensatz zur jetzigen Möglichkeit müssten dafür vor allem noch Weichen eingefügt werden können.
Hierzu müssten diese aber ein komplett anderes Stellsystem erhalten: derzeit funktionieren sie ja Situations- und Zug- abhängig, d.h. der Zug kommt zur Weiche, dort prüft der Zug, ob er abbiegen muss oder nicht.
Das müsste sich ändern: Ähnlich wie ich einem Signal in der SA sage, dass es auf "Grün" schalten soll, müsste ich der beteiligten Weiche mitteilen können, dass sie auf "gerade" oder "Abzweig" gehen soll.
BAHN müsste dann die Weichenstellung rückmelden mit entsprechendem Symbol.
Im Prinzip wäre die Weiche ein weiteres Signal.
Jetzt muss sie nur noch verriegelt werden. Dies könnte mittels einem Zähler geschehen, der im Zustand "frei" einen anderen Wert hat als im Zustand "verriegelt".
Man könnte diesen Zähler aber dann dafür nutzen, eine FS zu sichern. Ist z.B. Wert für die Verriegelung als 1 programmiert, könnte man beim Festlegen der FS einfach sagen: ich hab 10 Objekte (Signale, Sperrsignale, Weichen etc.), also muss der Wert 10 betragen - nur dann kann die FS frei sein und in ihr eingefahren werden.
Der Wert darf aber nur dann für ein Objekt erteilt werden, wenn es nicht durch eine andere FS verriegelt wurde.
Was wir jetzt noch brauchen, ist die Entriegelung der FS-Objekte. Das könnte dann mittels Schaltkontakte erfolgen oder über eine Möglichkeit, ähnlich der jetzigen Signalfunktion, mit der man z.B. das Hauptsignal wieder auf "rot" stellt, wenn der vorbeifahrende Zug die SA wieder auf gesperrt schaltet.
Allerdings darf das Entriegeln erst erfolgen, wenn der Zug zumindest das Objekt passiert hat. Sonst könnte ja eine Weiche schon gestellt werden, wenn die noch durch einen längeren Zug belegt ist.

Außerdem hab ich noch 2 Dinge, wo ich noch keine richtige Lösung drauf weiß:
a) Flanken-Schutzweichen
Die Weiche muss verriegelt sein, muss es aber erlauben, eine FS zu schalten, wenn diese nicht mit der zuvor einstellten FS kollidiert.
Beispiel: Überleitungen, Parallelausfahrten, -einfahrten ...

b) Gleisbesetztanzeige
Weichenstellungen, Signalstellungen ist noch klar und könnte auch aus den oben genannten Werten erzeugt werden. Was ist aber mit den normalen Gleisen, die keine Funktion haben?

Soweit meine Theorie. Allerdings stelle ich fest, dass es fast ein anderes Programm ist, was ich aus BAHN-Mitteln erzeugen wollte.


NA denn - ich bin gespannt, was Ihr davon haltet...

Bis dann...

Rolf

Guten Tag,

Ähnlich einer Signalanlage ("SA"). Im Gegensatz zur jetzigen Möglichkeit müssten dafür vor allem noch Weichen eingefügt werden können.
Hierzu müssten diese aber ein komplett anderes Stellsystem erhalten: derzeit funktionieren sie ja Situations- und Zug- abhängig, d.h. der Zug kommt zur Weiche, dort prüft der Zug, ob er abbiegen muss oder nicht.
Das müsste sich ändern: Ähnlich wie ich einem Signal in der SA sage, dass es auf "Grün" schalten soll, müsste ich der beteiligten Weiche mitteilen können, dass sie auf "gerade" oder "Abzweig" gehen soll.
BAHN müsste dann die Weichenstellung rückmelden mit entsprechendem Symbol.
Im Prinzip wäre die Weiche ein weiteres Signal.

Das ist ja im Prinzip auch schon möglich, wenn man jeder Weiche eine Signalanlage zuordnet.
Im Zweifelsfall sieht das dann wie unten aus.

Man könnte diesen Zähler aber dann dafür nutzen, eine FS zu sichern. Ist z.B. Wert für die Verriegelung als 1 programmiert, könnte man beim Festlegen der FS einfach sagen: ich hab 10 Objekte (Signale, Sperrsignale, Weichen etc.), also muss der Wert 10 betragen - nur dann kann die FS frei sein und in ihr eingefahren werden.

Es muss allerdings auch geprüft werden, ob sich auf dem zu sichernden Abschnitt auch kein anderer Zug befindet, selbst wenn von Weichen oder Signalen her keine Konflikte mehr bestehen (Zug biegt auf die selbe Strecke ein, hat aber die "einbiegende" Weiche schon wieder entriegelt. Ich hoffe man versteht, was gemeint ist).
Das Problem lässt sich im Moment nur damit lösen, auch die restliche Strecke in "Unterblöcke" zu zerteilen und diese einzeln zu belegen bzw. wieder freizuschalten. Diese müssen allerdings erst logisch erstellt / aus dem Gleisbild hergeleitet werden, so dass sie auch wirklich alle Möglichkeiten für konfliktfreie Zugfahrten offen halten. Wenn keiner der Blöcke mehr belegt ist, muss es im Umkehrschluss auch möglich sein, alle Weichen konfliktlos zu stellen.
Prüfen muss das allerdings nach wie vor ein unterirdischer "Stellzug". Was anderes ist mir noch nicht eingefallen. Immerhin sind so auch Alternativfahrstraßen machbar, indem das Wägelchen mehrere Wege zur Verfügung hat und je nach Belegung entscheidet.

Jetzt muss sie nur noch verriegelt werden.

Das ist tatsächlich das Einzige, was in BAHN noch fehlt und wofür es auch keine alternativen Möglichkeiten gibt.
Flankenschutz muss bisher wohl oder übel unverriegelt erfolgen.

b) Gleisbesetztanzeige
Weichenstellungen, Signalstellungen ist noch klar und könnte auch aus den oben genannten Werten erzeugt werden. Was ist aber mit den normalen Gleisen, die keine Funktion haben?

Das lässt sich mit vielen Signalen und Geduld auch jetzt schon erreichen. Siehe unten.

Auch wenn all das bisher doch recht kompliziert zu bewerkstelligen ist, möglich ist es allemal.
Man könnte es höchstens (erheblich) vereinfachen.

MfG Leander

Hallo,

ich finde die Überlegungen hier ja durchaus interessant, aber ich glaube nicht, dass das Ganze etwas bringt. Den Beiträgen entnehme ich, dass man entweder ein System schaffen würde, welches mit viel Aufwand nur ansatzweise Fahrstraßen sichert, oder man müsste BAHN zu einer richtigen Stellwerkssimulation ausbauen, um wenigstens alle wesentlichen Funktionalitäten eines richtigen Stellwerks nachzubilden. Ich glaube, dass die erste Variante nicht erstrebenswert ist, während die zweite an der begrenzten Programmierkapazität scheitert und für die meisten Nutzer ohnehin zu kompliziert wäre. Überhaupt wäre die Frage, welche Funktionen mal realisiert, denn es gibt außerhalb Deutschlands teilweise völlig andere Technologien zur Fahrwegsicherung.

Ich weiß auch nicht, ob das überhaupt nötig ist, wenn man bedenkt, wieviele Beschwerden es schon über das ach so komplizierte Signalsystem in BAHN 3.84 gab. Wieviele Nutzer würden denn sowas wirklich nutzen ? Wäre es nicht vielleicht ein besserer Weg, diesen wenigen Nutzern vielleicht durch die Implementierung einzelner zusätzlicher Funktionen die Erstellung von Fahrstraßen zu erleichtern, ohne diese komplett ins Programm einzubauen ? Ich meine damit beispielsweise eine Funktionalität, die es erlaubt, Signalanlagen bedingt zu schalten und diese Bedingung bzw. Schaltschritte zu speichern. Dann könnte man mit den jetzigen Mitteln Fahrstraßen auf Basis von Signalanlagen bauen und diese gewissermaßen festlegen, während die Anfoderung einer zweiten Fahrstraße noch bis zur Auflösung der ersten zurückgehalten würde. Die wenigen Nutzer hätten dann zwar einen gewissen Aufwand beim Bau von Fahrstraßen (der aber wohl auch nicht so extrem viel höher als eine elementweise Definition wäre), aber man müsste nur wenig am Programm ändern und würde die bestehenden Signal-Funktionen mit nutzen.

MfG Jan

Hallo!

Auch ich würde mich natürlich über die Möglichkeiten von Fahrstraßen in BAHN freuen. Mir ist aber auch klar, dass sich damit nur wenige Nutzer befassen. Jans Anreegungen würden schon weiterhelfen. Auch über Schaltzüge habe ich schon nachgedacht, der Nachteil ist hier neben dem hohen Aufwand, dass es bei einem großen Netz wie Wn-Regio die Geschwindigkeit erheblich verringern würde.
Eine Stellwerkssimulation wäre BAHN wenn es Fahrstraßen gäbe immer noch nicht ganz, da es bei Programmen wie ESTW Sim auch darum geht bei Störungen und Verspätungen in den Betrieb einzugreifen, dies wäre bei BAHN immer noch nicht möglich.
@Rednael: Ist dein Netz irgendwo zu downloaden oder könntest du es mir per E-Mail senden?

Viele Grüße
Timm

@Timm & Jan

Ja, die Befürchtungen, die ja hier auch nicht zum ersten Mal geäußert wurden, habe ich auch. Ich würde es prinzipiell auch erstmal für besser halten, einen Zug fahren zu sehen, als ihn als wandelnden Farbfleck zum Objekt der Begierde zu machen.
Es wird auch nicht möglich sein beides gleichzeitig zu tun.
Und dann stellt sich doch die Frage, was man will. Entweder eine Modellbahn-Simulation oder eine Stellwerks-Simulation.

Ich wäre für die Modellbahn, also BAHN so wie es jetzt ist.

Gruß
Rolf

Hallo zusammen,

wow, jetzt ist ja richtig Speed in die Diskussion gekommen. Wirklich starke Beiträge, für die ich mich bedanken möchte.

Trotzdem glaube ich, meine Idee noch etwas präziser zu beschreiben zu müssen. Also vorneweg: BAHN soll so bleiben, wie es ist, also eine Netzsimulation. Keine Stellwerkssimulation und auch keine Modellbahnsimulation.

Mit meinem Vergleich mit Word wollte ich eigentlich nur eine Metapher schaffen und ausdrücken, dass es viele Software gibt, bei der die User nie das gesamte Funktionsspektrum ausnutzen, sondern nur dass was sie individuell benötigen. Ich denke, mit einer behutsamen Erweiterung des Einsatzspektrums könnten auch die rückläufigen Nutzerzahlen etwas gedämpft werden.

Fakt ist, für Straba-Netze ist BAHN unschlagbar. Für kleinere Eisenbahnprojekte auch. Aber wenn man hier etwas größeres plant, kommt man mit dem Signalanlagenkonzept schnell an seine Grenzen. Fahrwege für Parallelfahrten und/ oder Kreuzungsfahrten sind derzeit nur mit massiven Einsatz von Signalanlagen und Signalanlagenelementen mit vielen Zwischensignalen umzusetzen. Und für alles wird Rechenleistung und Speicher benötigt.

Ich würde es daher gar nicht so komliziert machen. Bereits jetzt prüft der Zug (mit gesetzter Option "Kreuzungen freihalten") seinen Fahrweg für mindestens seine Zuglänge selbst im Voraus. Nach meinem Konzept würde das eben das Signal gemäß den für die Linie dises Zuges voreingestellten Fahrweg tun. Und nicht nur für die Zuglänge, sondern bis zu einem definierten Endpunkt. Ist der Fahrweg frei, reserviert das Signal diesen, geht auf Grün und der Zug fährt genau diesen Weg.

Flankenfahrten sind unmöglich, weil ja andere Signale diese Prüfung ggf. auch machen und bei reservierten Teilfahrstraßen nicht auf grün gehen. Insoweit wären Schutzweichen höchstens aus optischen Gründen notwendig.

Nachfahrten sind auch unmöglich, weil der vordefinierte Fahrweg nicht bis zum Endpunkt frei ist, weil da ja eben noch ein anderer Zug steht. Eine Gleisbesetztanzeige brauchts daher nicht.

Das ganze wäre bei weitem noch keine Stellwerkssimulation. Zum einen, weil ja kein Stellwerkstableau in die Oberfläche eingebaut werden soll. Zum anderen, weil ich ja keine "Stellwerksbedienung" in Echtzeit vorgeschlagen habe. Die Züge fahren ja auch weiterhin nach einer Voreinstellung und automatisch. Nur das die Fahrwegsuche und die Signalisierung an diesen Signalen etwas anders liefe.

Oder wie denkt Ihr?

Matthias

Hallo Matthias,

um nochmal den Vergleich mit MS Word aufzugreifen: Er hinkt ein wenig. Wenn es in MS Word eine Funktion gibt, die nur sagen wir 0,1% aller Kunden nutzen, dann handelt es sich vermutlich immernoch um zig tausend Personen. BAHN hat aber viel geringere Nutzerzahlen, da wären 0,1% vielleicht eine Hand voll Menschen. Selbst wenn die nun alle 100€ pro Lizenz bezahlen, wäre es wohl gemessen am Aufwand eher ein schlechtes Geschäft für den Entwickler. Es stellt sich generell die Frage, ob man da nicht lieber erstmal Dinge angehen sollte, die einem größeren Nutzerkreis wichtig wären - Beispiele dazu wurden bereits in anderen Diskussionsketten genannt.

Aus deinen Ausführungen entnehme ich, dass du nun doch keine Stellwerkssimulation willst, aber BAHN soll so wie ein Stellwerk funktionieren. Das ist irgendwie wiedersprüchlich. Und wahrscheinlich nicht möglich. Was ist denn zum Beispiel mit Rangierfahrten - wie sollen die denn in dein System eingebunden werden (Stichwort: Flankenfahrt) ? Auch darf bezweifelt werden, ob BAHN dann wirklich ressourcenschonender laufen könnte.

Übrigens brauche ich für meine Eisenbahn-Signalanlagen weder Schaltzüge noch irgendwelche Zwischensignale, von denen hier immer die Rede ist. Trotzdem lassen sich damit neben einer vorbildgetreuen Optik auch tatsächlich Zugzusammenstöße vermeiden. Und das mit den jetzigen Mitteln. Wie gesagt, ein paar kleine zusätzliche Funktionen wären sicher noch nötig, um das System zu verbessern (ein paar Einschränkungen gibt es freilich), aber das ist m.E. gar nicht so viel.

MfG Jan

Hallo Jan,

ich denke, das mit Word lassen wir wohl besser mal beiseite.

Wenn ich die ersten Resonanzen auf meinen Vorschlag hier so ansehe, glaube ich nicht, dass es wirklich so wenige sind, die sich über rudimentäre Fahrstraßen freuen würden.

Im Übrigen wollte ich NIE eine Stellwerkssimulation. Schau Dir doch bitte mal die hiefür einschlägigen Programme an und vergleiche das mit meinem Vorschlag oben. Das hat wirklich überhaupt nix miteinander zu tun. BAHN soll auch nicht wie ein Stellwerk funktionieren, das wäre viel zu kompliziert.

Mein Vorschlag war nur, dass BAHN auch die Eisenbahnrealität simulieren kann. Während die Strab auf SICHTAbstand fährt (so wie meist die Züge in BAHN), fährt die Eisenbahn bekanntich mit RAUMabstand. Das heißt, sie prüft erst den Fahrweg, bevor sie zufährt. Und nur dass würde ich mir auch in BAHN wünschen.

Zur Rangierfahrt: Nach meinem Vorschlag würden ja den Signalen ihre bisherigen Optionen bleiben. Da gibt es die Eingabe "Signal gilt nur/nicht für folgende Linien". Hir könnte man die Rangierfahrten (bzw. deren Liniennummer) eintragen. Alles liefe wie bisher...

Ein weiterer Flankenschutz erübrigt sich auch, bereits heute fahren sich die Züge nicht in die Flanken, der (Strecken-)Reservierung sei Dank. Jeder Zug reserviert sich ja bereits heute seine Strecke, zumindest für seine eigene Zuglänge. Und wenn ein anderer Zug auf diese Reservierung auffahren will, geht das doch heute auch schon nicht (außer Frontal natürlich). Wo liegt eigentlich das Problem?

Wie gesagt, ich glaube nicht, dass dies ein so übermäßiger Aufwand wäre, da BAHN ja so etwas im Prinzip ja schon macht. Nur sollte das eben nicht der Zug selbst machen, sondern ein Signal für den Zug. Bevor mir uns über den Aufwand die Köpfe zermartern, sollte der Entwickler selbst einschätzen, wie groß der Aufwand hierfür wäre. Ein Lizenzpreis von 100€ wird aber sicher kaum dabei herauskommen, denke ich. Das ich den Fehler gemacht habe, zu erklären, mir persönlich wäre BAHN auch mehr Geld wert, scheint mir ja nun irgendwie anzuhängen...

Viele liebe Grüße nach Klotzsche

Matthias

Hallo,

ich wollte die Frage mit den Fahrstraßen noch mal zur Diskussion stellen.

Wie gesagt, es geht nicht um eine Stellwerkssimulation, sondern dass sich ein Zug vor dem Signal seinen Fahrweg sucht und dann am Signal Frei oder halt bekommt...

Nehmen wir nur mal das Beispiel "Leckwitz" an der LDE (Dateianhang unten). Um hier Flankenfahrten und Nachfahrten zu sichern, ist mit dem jetzigen System ein höherer Aufwand mit Signalanlagen nötig.

Für Fahrten aus Richtung Riesa müssten für die Blocksicherung der folgenden Strecken zusätzliche (vorbildwidrige) Signale nach dem Abzweig eingefügt werden. Von der Kopplung mit einem Vorsignal ganz zu schweigen...

Eine Fahrstraße nach meinem Vorschlag von Leckwitz nach z. Bsp. Böhla könnte dann so aussehen: W1340(Richtung1); W388(Richtung1); W1339(Richtung1); Signalanl. (zur Blocksicherung Richtung Böhla)=0 --> alles frei, dann Fahrweg reservieren und Signal H101 auf Fahrt. (Natürlich ist meine Fahrstraßenbeschreibung hier nur beispielhaft.

So wäre aber der Fahrweg geprüft und reserviert. Eine Zugfahrt von Coswig nach Riesa würde ebenso verfahren, erhält aber kein Fahrt frei, weil der kreuzende Fahrweg schon reserviert ist.

Wenig Aufwand, große Sache. Weniger Rechenleistung und mehr Übericht, weil weniger Signalanlagen.

Ich weiß, dass ich mit Liniengebundenen Signalanlagen schon viel erreichen kann. Wenn ich aber mal eine Störung auf dem Linienweg habe (was in einer Netzsimulation ja auch mal vorkommen darf), wäre es mit den liniengebundenen Signalen kaum möglich, einen Zug mal eben umzuleiten, ohne das die Signalisierung den Bach runter geht.

Gerade in einem Netz kommt es vor, dass sich ausschließende Fahrwege auf das ganze Netz auswirken, das wäre es schön, soetwas in der Simulation auch darstellen zu können.

Ich würde mich freuen, wenn Ihr mal grundsätzlich eine Aussage trefft, ob die "Fahrstraßen" für Euch interessant wären...

Hallo

Dank dessen, das sich Signalanlagen mit den Logikfuktionen UND/ODER/NICHT auch verknüpfen lassen, ist es möglich Fahrstraßen festllegen zu können die teilweise nicht Linienabhängig sind. Als Vorbild ist die Funktion eher dem Modellbahneralltag entnommen als sie dem realen Eisenbahnalltag entspricht. Ich verwende in Bahn die Lösung der Gleisbesetztmeldung. Der Ausfahrende Zug gibt seinen Fahrweg dem nachfolgenden wieder frei. Sind Gleisabschnitte besetzt kann der nachfolgende in die freien Gleise einfahren, wenn diese der Linienführung entsprechen. Damit sind dann Überholungen möglich, es können verschiedenen Linien auch an demselben Bahnsteig halten und auch wenden.
Das einizige Manko ist, das die Signalabhängigen Weichen für diese Schaltungen nicht hilfreich sind. Bisher ist es so, das diese immer eine Grundstellung haben. Ist im Prüfbereich des einfahrenden Zuges kein Wagen mehr, kommt es zu recht zufälligen Zugfahrten. Hier müßten die signalabhägingen Weichen wie ein Signal behandelt werden. Durch das vorhandensein der Dreiwegeweichen sind daher die Zustände 0,1,2 definiert festzulegen, d.h. es werden für das umstellen der Weiche 3-Signalanlagen benötigt. Davon darf nur eine den Zustand 1 haben. Ist das nicht so, gilt für diese Weiche der Zustand Signal Rot und der Zug bleibt wie vor jedem haltzeigenden Signal stehen. Damit bleibt das bisher in Bahn verwendete Prüfverfahren erhalten.
Damit müßten sich dann Signalabhängige Fahrstraßen festlegen lassen.
Fraglich bleibt aber auch hier, ob der Anwender auch mit dieser Funktion dann umzugehen weis. Es ist schon jetzt schwer, das Zusammenspiel der Signalanlagen untereinander zu erklären. Mit dieser Erweiterung wird es nicht einfacher, sondern das Signalsystem geht dann den Weg hin zu einer "Programmiersprache" in der Simulation, die vorwiegend mathematische Züge haben wird.

Ob das der Intension der Grundidee von Bahn noch entspricht, kann nur der Programmierer Jan selbst beurteilen.

Ich möchte das oben geschriebene als Denkanstoß verstanden wissen. Man wird eben nicht alles haben können

Herzliche Grüße
richterjue

Wobei ich hinzufügen muss, dass mir- ich baue Wien mit Umgebung nach eine fahrstrassensteuerung sehr abgeht. Es wäre wirklich toll, das hinzuzufügen. Ic hätte hierzu noch eine Idee, über die ich mir aber noch mal Gedanken mach, bevor ich sie heir veröffentliche.
Wünsche allen gute Nacht!!!