Hallo Jan,
Jan Eisold hat geschrieben:
Klar, Leckwitz sollte ja auch nicht als Beispiel für die Übersichtlichkeit dienen. Eher für die Probleme, die die derzeitigen Möglichkeiten von BAHN bereits an so einer kleinen Betriebsstelle verursachen. Hätte ich die Übersichtlichkeit meines Vorschlages in den Vordergrund gestellt, hatte ich Dresden Hbf. genommen.
Nehmen wir doch aber das Beispiel Leckwitz nochmal ran: Nochmal der Zug von Riesa nach Böhla. Um die Strecke von Leckwitz nach Böhla blocktechnisch zu sichern, müsste ich jetzt ein Signal NACH der Weiche aufstellen. (Nach Coswig dito) Das ist alles andere als realistisch (auch wenn ich das Signal ausblenden würde).
Ich muss das bei meinem System nicht.
Dann würde mich das System interessieren.
Oder ich stelle zwei Signale vor der Weiche auf, eins nach Böhla, eins nach Coswig. Auch nicht realistisch. ... Und mit welchem der beiden Signale verknüpfe ich eigentlich das Vorsignal?
Aus Richtung Glaubitz würde ich genau ein Signal aufstellen, das für beide Richtungen gilt. Theoretisch sogar für Fahrten ins Gegengleis, aber das wollen wir hier erstmal nicht betrachten. Sofern das vorherige Hauptsignal kein Mehrabschnittssignal ist, geht das sogar ohne Tricksereien.
Auch das würde mich näher interessieren. Vor allem, wie Du dem Signal klar machst, in welche Richtung (und damit in welchen Blockabschnitt) der Zug an der Ausfahrweiche fahren will? Welchen Begriff zeigt Dein Ausfahrtsignal, wenn nur einer der anschließenden Blockabschnitte (Böhla oder Coswig) belegt ist?
Hier muss ich zudem die Linienselektivität benutzen, damit überhaupt noch was geht. Kommt da mal ein Umleiter, der nicht in einer der Linienlisten hinterlegt ist, bleiben beide Signale wirkunkslos.
Bei mir gibt es immer einen "Standardfahrweg", das ist meistens die Einfahrt bzw. Durchfahrt im durchgehenden Hauptgleis. Soll eine Linie anders fahren, muss das eingetragen werden, sonst nicht.
Be Weichen ist mir der Standardfahrweg schon geläufig, nur wie machst Du das dem Signal vor der Weiche klar? Insbesondere in Bezug auf vorherige Frage?
Linienselektivität: Wie soll denn bei dir am Signal entschieden werden, welche Fahrstraße ein Zug anfordert ? Etwa auch über die Linie ? Dann wäre der "Vorteil" eigentlich nur der, dass bei dir ggf. diese Linien nur je einmal eingegeben werden müssen (bei mir u.U. gar nicht, s.o.), aber ohne die Angabe der Linie oder einer anderen Entscheidungsinformation an irgendeiner Stelle (wo eigentlich ?) wird es wohl nicht gehen.
Natürlich auch über die Line. Am Signal sind die möglichen Fahrwege hinterlegt. Einer davon ist der Standardfahrweg. Gleichwohl wird im Signal hinterlegt, welche Linie welchen Fahrweg und ggf. welchen Alternativfahrweg nehmen soll. Kommt ein Zug, dessen Linie nicht am Signal hinterlegt ist, wird dieser auf den Standardfahrweg geleitet.
Ich muss aber nicht sagen: "Signal gilt nur für ... Linien" oder "Signal gilt nicht für ... Linien". Das meinte ich mit Linienselektivität. Soetwas gibt es (mit Ausnahme der Rautentafel für Rangierfahrten beim Hl-Signalsystem) beim Vorbild nicht.
Nochwas, um Flankenfahrten aus Coswig in Zuge nach Böhla zu verhindern, müsste ich eine extra Signalanlage verwenden...
Das ist wohl wahr. Dies könnte ich bei mir allerdings einsparen, wenn man Signalanlagen in BAHN in einer Art Liste speichern und nacheinander ablegen könnte. Dann könnte ich eine Fahrstraße festlegen, und wenn diese wieder aufgelöst (freigefahren) ist die nächste aus der Liste festlegen usw. Das ist eigentlich die wesentliche Funktion, die ich bräuchte, um mit meinem System ziemlich gute Ergebnisse zu erzielen. Ohne diese Festlegung einer Fahrstraße kann es derzeit passieren, dass ein zweiter Zug einem anderen das bereits Fahrt zeigende Signal wieder sperrt. Ich könnte das durch Schaltzüge lösen, aber das mag ich nicht.
Jetzt sind wir aber schon irgendwie bei "meinem System" angekommen, nur dass Du das nicht über vorab reservierte Fahrwegselemente machen würdest, sondern über die Verkettung (nicht Verknüpfung) von mehereren Signalanlagen. Das wäre wie ein Bahnhofsblock. Jawoll, auch eine Lösung... Man müsste aber auch hier, wie Du schon schreibst, die verketteten Signalanlagen aber auch schon vorab belegen, damit ein anderer Zug das nicht mehr tun kann. Auch insoweit deckt sich Deine Lösung mit meiner. Und Richtig! Schaltzüge, genau das gilt es zu verhindern.
..., die die Einfahrt aus Coswig sperrt, sobald ein Zug aus Leckwitz entweder Richtung Böhla oder Coswig abfährt. Fährt er nach Böhla, ist das in Ordnung. Fährt er nach Coswig, habe ich das Gegengleis unnötig blockiert. Für eine Netzsimulation eigentlich untragbar.
Genau. Ein Glück, dass das bei mir gar kein Problem darstellt.
Womit ich wieder zu meiner ersten Frage käme: Wie funktioniert Dein System?
Übersichtlicher auch deshalb, weil ich vom Signal als Beginn des Fahrweges diesen anhand der eindeutigen Bezeichnungen der tangierenden Elemente ohne weiteres nachvollziehen kann. Ich habe keine endlose Auflistung von Signalanlagennummern mehr, bei der ich auf den ersten Blick nicht nachvollziehen kann, wofür die Anlagen zuständig sind und mit welchen Elementen und Abhängigkeiten sie noch verknüpft sind.
Wenn ich meine Signalanlagen schon anlegen muss, kann ich sie auch sinnvoll bezeichnen. Mit einem einheitlichen Schema kann man das sehr übersichtlich machen.
Richtig. Nur ist der Platz im Eingabefeld der Signale irgendwie auch begrenzt, um hier eine Menge Signalanlagen mit aussagekräftigen (und damit wahrscheinlich auch längeren) Namen einzutragen. Auch ändert das nix daran, dass hier eigentlich nur Verweise aufgeführt sind und mir über die Abhängigkeiten dieser Verweise keine Auskunft geben. Nur mit vielen Klicks komme ich an die Informationen. Hinzu kommt noch, dass diese Verweisliste noch mit einigen logischen Operatoren verknüpft sein dürften, was die Lesbarkeit nicht unbedingt verbessert.
Bedenke, dass sich dein Beispiel nur auf eine Abzweigstelle mit vier Weichen bezieht - wie soll das denn bei einem mittelgroßen Bahnhof aussehen !?
Genau, hierum geht es, um mittelgroße und große Betriebsstellen. Siehe oben! Mein Vorschlag wäre viel kleinteiliger als die derzeit notwendigen 100 oder mehr Signalanlagen, die in und um den Bahnhof sowie mit den benachbarten Blöcken irgendwie verknüpft sind.
Bahnhöfe mit 100 Signalanlagen habe ich bisher eigentlich nicht gebraucht. Okay, dazu muss man sagen, dass ich nur Fahrstraßen anlege, die auch benutzt werden, das reduziert den Aufwand erheblich. Brauche ich später doch mal mehr, kann ich es ja einfach nachträglich einbauen.
Klar, so mache ich das zwangsläufig momentan auch. Gerade aber der nachträgliche "Einbau" erfordert ja, dass ich die bestehenden Abhängigkeiten erstmal aufdrieseln, dann erweitern muss. Das Konstukt wird damit immer komplizierter, weil verschachtelter.
Ich frage mich aber, was man wirklich spart. Die Signalanlagen der Blockstrecken würdest du ja weiterhin verwenden wollen. Aus "meinen" Signalanlagen für die Fahrstraßen würden "deine" Fahrstraßen werden, also bleibt auch hier die Anzahl gleich.Was wegfiele, wären Signalanlagen zur Absicherung von kreuzenden Fahrten, die ich aber derzeit nur benötige, weil es keine Fahrstraßenfestlegung gibt (s.o.). Was bei mir die Verknüpfung der Signalanlagen ist, wäre bei dir die Zusammensetzung der einzelnen Fahrstraßen (sowohl vom Speicher-, als auch vom Rechenaufwand). Damit würde man in deinem System gegenüber meinem insgesamt durchaus etwas sparen, allerdings schätze ich den Vorteil bei weitem nicht so dramatisch ein wie es in deinen Ausführungen zunächst erscheint.
Nicht ganz. Ja, für Steckenblock öder BÜ-Sicherung sind die Signalanlagen ausgezeichnet, insbesonder im Modus "Fahrzeuge zählen". Das ist wie ein Achszählkreis beim Vorbild.
Für den Bahnhofsblock ist das aber zu kompliziert. Zumal man hier auch schon einmal Schaltkontakte bei einer Weichenverbindung zwischen zwei unmittelbar benachbarten Gleisen bräuchte, was aus Platzgründen nur mit recht hässlichen Lösungen machbar ist.
Ich gehe davon aus, dass die Signalanlagen jetzt irgendwie in Form eines Arrays oder eines Records mit ihrern jeweiligen verknüpten Elementen und ihren Parametern und Schaltzuständen organisiert sind. Bei jeder Inanspruchname einer Signalanlage muss auf diese Daten zugegriffen und müssen diese verändert werden. Daher dürften diese Gitter permanent im Speicher sein.
Bei meinem Vorschlag würde nur bei der Fahrwegsanforderung einmal auf die Definitionen zugegriffen werden. Ansonsten nutz BAHN die Reservierung (und auch die Dereservierung) der Fahrwegselemente, die die Züge ja bereits heute schon verwenden, in etwas modifizierter Form. Flnken- und Querfahrten sind damit genauso automatisch ausgeschlossen, wie das von Dir oben geschilderte Problem des nachträgliche Belegen eines Abschnittes durch einen anderen Zug. Die Fahrwegsreservierung ist ja zudem bei Deiner Lösung trotzdem noch notwendig, weil vorhanden, zusätzlich zur Bedienung der Signalanlagen.
Bei meiner Lösung würde man viele Signalanlagen einsparen, inklusive deren Speicherplatz und der Zugriffe auf sie. Man würde viele Schaltkontakte sparen, die zum "Freifahren" einzelner Abschnitte (Signalanlagen) benötigt werden. Und man nutzt bereits vorhandene Funktionen effektiver und reduziert damit den Resourcenverbrauch.
Es geht mir nicht um die Logik, sondern um die Übersichtlichkeit. Und was passiert, wenn ich eine Weiche zusätzlich einbaue oder eine Weiche wegnehme ? Dann müsste ich ja genau so alle Fahrstraßen ändern.
Genau! Dann muss ich die betreffenden (und eben nur die betreffenden) Fahrstraßen auch korrigieren, wie beim Vorbild. Wenn Du jetzt eine Weiche ein- oder ausbaust, musst Du die Signalanlagen im derzeitigen System doch auch anpassen, zumindest dann, wenn die Weiche eine betriebliche Funktion haben soll. Hier musst Du dann nur noch ein oder zwei, vielleicht auch 5 Fahrwegdefinitionen überarbeiten und nicht mehr 25 Signalanlagen des Mit-, Gegen- oder Querverkehrs.
Ich kann soviele Weichen ein- oder ausbauen wie ich will, solange das keine neuen oder den Wegfall von alten Fahrstraßen bedeutet und es keine Änderungen bei den Fahrstraßenausschlüssen gibt, muss ich an meinen Signalen gar nichts machen.
Richtig, was den Sinn dieser Weichen dann aber irgendwie infrage stellt. Die Zahl von Weichen, die ich dann noch aus rein optischen Gründen ein- oder ausbaue, dürfte sich in engen Grenzen halten.
Und selbst dann wären pro Signal (und hier ja auch nur ein Teil der insgesamt vorhandenen) vielleicht 2 oder 3 Fahrwegdefinitionen betroffen, deren Edit recht schnell vonstatten gehen dürfte. Bei der Verwendung von Zwischensignalen, was mit meiner Lösung richtig Gaudi machen würde, wird die Zahl der zu ändernden Fahrwegsdefinitionen noch geringer ausfallen.
Ich bin weiterhin der Meinung, wenn man Fahrstraßen in BAHN einführt, muss es zugleich eine automatische Möglichkeit geben, diese zu erzeugen. Sonst ist das nicht praktikabel. Die Fahrstraßen könnten zum Beispiel in einer separaten Datei hinterlegt werden.
Warum? Wenn ein Bahnhof beim Vorbild gebaut wird, macht auch jemand erstmal einen Verschlussplan. Das ist zunächst erst einam etwas Arbeit, gilt aber solange, wie sich im Gefüge nichts ändert. Bei BAHN ist das dann auch nicht mehr Arbeit, als die Signalanlagen anzulegen. Und wenn die Fahrwege fertig definiert sind, kann man diese genau so wie jetzt schon die (kryptischen) Schaltkriterien an das betreffende Signal(anlagen)element anhängen, weil sie ja auch nur für dieses Element sinnhaft sind. Da brauchts keine extra Datei und eigentlich auch keine automatische Möglichkeit. Einzig ein Button, der die eingegebene Fahrstraße zu Testzwecken visualisiert (oder einen Fehler anzeigt), wäre eine tolle Sache.
Wie lange dauert es denn, bis ich alle Fahrstraßen für Dresden Hbf (nur die aus den bzw. in die Regelgleisen) angelegt habe ? Und wie lange dauert es, wenn ich danach im Bahnhofsvorfeld eine Weiche umbaue, bis ich alle betreffenden Fahrstraßen angepasst habe ? Und nun rechne diesen Aufwand mal auf halbwegs anständige Netze mit vielleicht so ca. 500 km Streckennetz und 100 Betriebsstellen hoch. Es wird schon einen Grund haben, warum wir für unsere "echte" Simulation so ein Tool haben...
Ja, alles nach und nach. Die Frage kann ich eigentlich gleich so zurück geben. Wie lange dauert das denn bei der Lösung über Signalanlagen? Hier gab und gibt es doch auch keine Möglichkeit, deren Estellung zu automatisieren. Ich könnte mir beim besten Willen auch keinen Algorythmus vorstellen, der im Fall des Signalanlagenkonstruktes dazu in der Lage wäre.
Von mir aus, so ein Toll wäre lustig und sehr hilfreich. Aber ob's das unbedingt braucht, wage ich zu bezweifeln.
Ansonsten verweise ich insbesondere in bezug auf den Einsatz von Zwischensignalen auf meine obige Antwort.
(Mir fällt aber gerade noch ein, dass man bei meiner Lösung die Verknüpfung der "Vorsignalfunktion" bei kombin. Signalen insoweit dynamisieren müsste, dass der Vorsignalbegriff mit der Haupsignalstellung des Signals am Ende der eingelegten Fahrstraße entspricht, wenn deren Ende ein Hauptsignal ist. Ist dazwischen noch eine Haltestelle o.ä. könnte geprüft werden, ob der Zug da zu halten hätte, ansonsten könnte die Haltestelle ja an dem mit ihr verknüpten Signal die "Durchfahrt" anfordern. Mann wär' das cool!
)
Ja, man sollte aber nicht mit Kanonen auf Spatzen schießen. Ich glaube Zielbremsungen, Fahrdynamik und Durchrutschwege sind nicht wirklich das, was BAHN ernsthaft fehlen würde.
Genau das macht aber den Eisenbahnbetrieb aus, neben der Art der Fahrwegsicherung und der Abstandshaltung. Was nützen mir vorbildgerechte Fahrstraßen, wenn ich jedem Zug per Hand seinen Bremseinsatzpunkt festlegen muss ? Was man allein bei der Aufstellung von Bremstafeln für Zeit und Speicherplatz sparen könnte...
Ja klar, aber hier stellt sich die Frage: Was wollen wir eigentlich mit BANH machen? Wollen wir a'la SMA Gutachten zu Stuttgart 21 machen oder wollen wir einfach nur Spaß haben? Im Prinzip hast Du recht, aber mit diesem "Schönheitsfehler" kann ich leben. Zumal ich mir vorstellen könnte, dass mit der "vorauseilenden Fahrwegprüfung" nach meiner Lösung das ermitteln von Bremspunkten tatsächlich irgendwann mal technologisch umsetzbar wäre.
Genauso wenig eine automatische Fahrwegssuche, die jedesmal gestartet wird, wenn ein Zug an ein Signal fährt (Und dabei Rechenleistung verbraucht.)
Davon habe ich nichts geschrieben. Die Fahrwegsuche soll ein Mal stattfinden und dann würde mit den hinterlegten Fahrstraßen immer weiter gearbeitet (außer, ich führe die Suche wegen Umbauten etc. später nochmal aus).
Siehe oben.
Wenn der Zug in Richtung des Signales fährt, muss natürlich dann irgendwann die Fahrstraße angestoßen werden. Das erfordert dann bei jedem Zug Rechenleistung, wie du schon richtig schreibst.
Ja, aber nur einmal pro Zuganfahrt auf das Signal und nicht bei mehreren Siganlanlagen
Ich möchte eigentlich nur mit kleineren Modifikationen dass, was BAHN ohnehin schon kann, effektiver nutzen.
Ich auch ! Ich möchte dir mit meinem Beitrag verständlich machen, dass es dafür jedoch auch andere Lösungsmöglichkeiten gibt.
Zweifelsohne. Daher möchte ich Dir für den betrag danken. Mit dieser Form des Dialogs kann an das Für und Wider abwägen und so die beste Lösung ermitteln.
Wie gesagt, ich habe ein eigenes System, dass mit wenigen Ergänzungen eine absolut realistische Fahrstraßenabbildung ermöglichen würde.
Rudimentär würde mir reichen...
Es wäre 100% abwärtskompatibel, benötigt keine neuen Elemente (Weichentypen, Signaltypen).
Abwärtskompatibel wäre meins auch. Okay, man müsste einige Elemante erweitern, wie das aber bei den letzten Versionsänderungen aber auch problemlos der Fall war.
Okay, es wäre vielleicht nicht ganz so elegant wie dein System, wenn es bei dir einen automatischen Fahrstraßengenerator gäbe. Das sehe ich nämlich als Vorteil deines Ansatzes: Man könnte die Fahrstraßen komplett neu in das Programm einbringen und dann deren Erstellung automatisieren. Letzteres kann ich mir für mein System nur schwer vorstellen.
Über Eleganz lässt sich bekanntlich streiten. Mir macht es jedoch den Eindruck, als ob Dein System einen sehr hohen Entwicklungsstand hat. Nur würde ich den Aufwand bei der Lösung mit vielen Siganlanlagen für unangemessen halten. Ist halt immer eine frage des Blickwinkels...
Ohne diese Automatisierung halte ich aber den Aufwand bei deiner Lösung für unangemessen (gegenüber dem Nutzen, der von der Anzahl der potentiellen Benutzer abhängt).
Das ist Ansichtssache...
Viele Grüße in meine Heimat
Matthias
