Verzögerung bei Schaltfunktion / Zeitgesteuerte Schaltfunkt.

[HSE]

Moin,

ich habe in meinem (etwas größeren) Netz mittlerweile schon öfter das Problem gehabt, dass ich eine Signalanlage direkt vor einer Haltestelle platziert habe, die ich gerne 10-15 Sekunden vor Abfahrt des Zuges auf Frei schalten möchte. Das ganze soll dann z.B. die Frei-Anforderung an einer Straßenbahnhaltestelle simulieren, bei der die Signalanlage erst nach der Ein/Aussteigezeit der Bahn auf grün schaltet um den Straßenverkehr nicht zu blockieren.
Das gleiche wäre auch für eine Rückschaltung nicht schlecht, so dass man der Strab Zeit geben würde die Kreuzung zu räumen.

Technisch könnte man das z.B. so organisieren:

Neue Schaltfunktion:
15s:K1+, 40s:K1

für den Schaltvorgang K1+ nach 15 Sekunden und K1 (-) nach 40 Sekunden.

Alternativ ginge natürlich auch der ursprüngliche Weg mit der separaten Angabe der Schalt- bzw. Rückschaltzeit, das wäre allerdings nicht ganz so flexibel.

Technisch dürfte das auch nicht so aufwendig sein, die Rückschaltfunktionen werden im Moment ja ebenfalls in die Zeitliste eingefügt und dann später ausgeführt.
Ob man eine solche Schaltfunktion noch auf Plausibilität prüfen könnte bzw. ob es damit Probleme geben könnte müsste man noch gucken bzw. es wirklich dem Benutzer überlassen - das wäre ja ohnehin eine Funktion für die Experten.

Ich bin auf Eure Meinungen gespannt

Gruß,
- Tobi

P.S: Im Moment benutze ich zwei Schaltkontakte: der erste Schaltet S+ mit Rückschaltzeit x Sekunden, der zweite S ohne Rückschaltzeit. Damit wird der gewünschte Effekt zwar erreicht, ich brauche aber eine Unmenge von Kontakten, was vom Platz her recht unübersichtlich wird. Außerdem können die Signalanlagen nicht mit den Standardparametern "bedient" werden, sondern ich muss alle auf "max 2" setzen um einen Überlauf zu verhindern..

[Rolf R]

Was wäre mit folgendem Ansatz:

Einschaltkontakt wie gehabt mit der entsprechenden Anforderungszeit, aber: statt Züge zu zählen die Fahrzeuge zu zählen. Dann könnte der Ausschaltkontakt sogar ohne Verzögerungszeit auskommen, wenn dort ebenfalls die Fahrzeuge gezählt würden.
Natürlich müssten die Maximalwerte der Signalanlagenzähler entsprechend der Fahrzeuganzahl angepasst werden (mindestens die maximale Fahrzeug-Anzahl auf der entsprechenden Strecke).
Vorteil: Du kannst die Züge in variablen Längen einsetzen, wenn Du innerhalb der Maximalwerte bleibst, die Du Dir vorgegeben hast. Außerdem könnten die Züge sogar unterschiedliche Wartezeiten und Geschwindigkeiten haben.

Funktionsprinzip ähnlich wie bei einem Bahnübergang...

Und bitte den übrigen Verkehr nicht zu lange warten lassen - sonst geht das Gehupe los!

Grüße aus dem Münsterland
Rolf

[HSE]

Hi Rolf!

Ja, für das Räumen der Kreuzung wäre die Lösung so schon nicht verkehrt (wobei es dann an kleinen Details scheitert, z.B. daran das ich den MIV genauso simuliere wie den Linienverkehr und dann die Autos die Schaltkontakte eben auch überfahren - auf eine Linie festlegen will ich mich da aber nicht, sondern mit dem Merkmal "hat die Haltestelle bedient" eigentlich auskommen).
Das eigentliche Problem ist aber wirklich das "Schalten nachdem der Bus/Tram/Zug schon x Sekunden gewartet hat". Zu dem Zeitpunkt passiert ja nichts, es gibt keine Zugbewegung etc sondern es ist wirklich _nur_ die Zeit die eine Rolle spielen soll. Einen Kontakt hinter die Haltestelle legen will ich nicht. Bei Bussen und Straßenbahnen ist das vielleicht nicht soo unrealistisch aber bei der "großen" Bahn fährt der Zug ja erst wieder an wenn das Signal wirklich auf Fahrt steht. In größeren Bahnhöfen (Taktpunkt) kann man das vielleicht noch mit einem zweiten Taktpunkt realisieren über den die Fahrstraße angefordert wird, aber bei kleineren Bahnhöfen wo das Ausfahrsignal erst nach Eintreffen des Zuges gestellt wird brauche ich dann gleich wieder Hilfszüge die ich eigentlich vermeiden wollte (davon hab ich schon genug, da ich mit Fahrstraßen arbeite).
Was mir auch noch einfällt (und was natürlich schön wäre, aber an anderer Stelle auch schon diskutiert wurde) sind die "Schalten wenn möglich"-Listen mit denen man einen Schaltkontakt von Bedingungen abhängig machen könnte. Der Zug würde dann nicht vor dem Signal (was ja sonst nötig wäre) stehen bleiben sondern den Kontakt überfahren und die Schaltfunktion würde in eine Liste eingebunden die regelmäßig (alle 5 Sekunden etc) durchgeprüft wird ob die Schaltfunktion mittlerweile ausgeführt werden kann.
So könnte man auch Fahrstraßen sehr elegant realisieren (okay, immer noch zwei Signalanlagen pro Weiche aber machbar).

Vielleicht erfüllen sich diese Träume ja in einer zukünftigen BAHN-Version

Gruß,

Tobi

P.S: Ich hab natürlich keine Ahnung von der internen Struktur von BAHN aber im Gegensatz zu vielen anderen Wünschen (echte Fahrstraßen, mehrere Richtungen pro Symbol, ..) erscheint mir das noch halbwegs realsierbar.
P.P.S: Mein Netz bildet die Stadt Essen im heutigen Zustand ab, ist allerdings noch nicht fertig. Falls jemand Interesse an den Fahrstraßenschaltungen oder dem Tool dafür hat: einfach kurz bescheid sagen..

[Jan Bochmann]

Guten Abend,

Moin,

ich habe in meinem (etwas größeren) Netz mittlerweile schon öfter das Problem gehabt, dass ich eine Signalanlage direkt vor einer Haltestelle platziert habe, die ich gerne 10-15 Sekunden vor Abfahrt des Zuges auf Frei schalten möchte. Das ganze soll dann z.B. die Frei-Anforderung an einer Straßenbahnhaltestelle simulieren, bei der die Signalanlage erst nach der Ein/Aussteigezeit der Bahn auf grün schaltet um den Straßenverkehr nicht zu blockieren.
Das gleiche wäre auch für eine Rückschaltung nicht schlecht, so dass man der Strab Zeit geben würde die Kreuzung zu räumen.

Technisch könnte man das z.B. so organisieren:

Neue Schaltfunktion:
15s:K1+, 40s:K1

für den Schaltvorgang K1+ nach 15 Sekunden und K1 (-) nach 40 Sekunden.

Alternativ ginge natürlich auch der ursprüngliche Weg mit der separaten Angabe der Schalt- bzw. Rückschaltzeit, das wäre allerdings nicht ganz so flexibel.

Technisch dürfte das auch nicht so aufwendig sein, die Rückschaltfunktionen werden im Moment ja ebenfalls in die Zeitliste eingefügt und dann später ausgeführt.

Das ist nicht so. Die Zeitliste ist statisch und enthält nur die Schaltzeiten. Die Rückschaltzeiten werden daraus ermittelt. Also z.B. Es ist jetzt 20:04, als Rückschaltzeit sind 60s eingetragen, also schaue ich in der Liste, ob da ein Eintrag um 20:03 ist, und wenn ja, dann schalte ich zurück (*).

D.h. es gibt derzeit keine Datenstruktur, in der Schaltvorgänge zwischen Hin- und Rückschalten zwischengespeichert werden. Deshalb funktioniert das Rückschalten auch nur für Werte aus der Liste und nicht für Vorgänge, die manuell oder via Schaltkontakt/Signal ausgeführt werden.

Für eine flexiblere Lösung wie Deinen Vorschlag müßte man aber alle eingehenden Schaltvorgänge speichern und jeweils nach ihrer Rückschaltzeit zurücknehmen und wieder löschen. Solche Vorgänge können sich aber nahezu beliebig überlappen, d.h. vor Ablauf der einen Rückschaltzeit können bereits weitere Vorgänge ablaufen, vor allem wenn man Fahrzeuge zählt statt ganzer Züge, und wenn die Rückschaltzeiten recht lang und obendrein unterschiedlich sind. Es ist also schwierig, einen entsprechenden Pufferspeicher zu dimensionieren.

Am Kontakt ist es ähnlich: Jeder neu ausgelöste Vorgang überschreibt den vorherigen und aktualisiert die Rückschaltzeit auf die aktuelle Zeit plus eingetragene Zeitdifferenz. Das ist also eine einfache Variable pro Kontakt, keine Liste von Ereignissen mit variabler Länge. Gemerkt werden dazu lediglich die Summen für Hin- und Rückschalten, d.h. auflaufende Schaltvorgänge addieren sich und werden immer weiter zeitlich nach hinten verzögert, bis es wirklich mal zum Rückschalten kommt.

(*) In Wahrheit ist es etwas optimiert und komplizierter, sodaß nicht jede Sekunde die ganze Liste durchgeprüft werden muß. Es ändert aber nichts an der Wirkung.

Gruß,
Jan B.

[HSE]

Hallo Jan!

zuerst mal Danke für die schnelle Antwort..
Tja, man steckt eben doch nicht im Quelltext, ganz ehrlich: Obwohl ich seit 15 Jahren in diversen Sprachen programmiere dürfte es mir sehr schwer fallen, ein Projekt wie BAHN so flüssig laufend auf die Beine zu stellen - dafür erstmal ein riesen Kompliment.
Trotzdem bin ich der Meinung, eine solche Liste mit Aufgaben die dann abgearbeitet werden könnte sinnvoll sein (evtl. auch für andere Aufgaben wie die angesprochene Schalt-Warteliste oder Dinge die mir im Moment nicht einfallen). Mir schwebt dazu schon ein Konzept im Kopf herum, falls ich dir damit etwas Arbeit abnehmen kann würde ich das einfach mal zusammen schreiben bzw das ganze auch gleich in C pseudofertig programmieren. Ich habe durchaus auch noch andere Anschläge auf dich vor, wie z.B. eine externe API so das man Erweiterungen für Bahn bauen könnte (z.B. ein Gleisbildstellwerk oder einen damit verbundenen Fahrstraßeneditor der die Daten direkt in BAHN einfügt etc.).

Aber jetzte erstmal der Reihe nach - falls grundsätzlich das Interesse bei dir da wäre so eine Sache zu implementieren gibt es bestimmt eine Möglichkeit das resourcenschonend umzusetzen - und wenn es dann hinterher doch nur ein Tool ist welches eine API anspricht oder eins der Editorfenster "klaut" und versucht, daraus schlau zu werden

Schönen Gruß aus Essen,

Tobi

[HSE]

Noch eine Idee dazu: Eigentlich ist für diese Funktion nur die Erweiterung des Kontaktes um folgende Elemente nötig:

- Rückschaltzeit wird nicht nur "negativ" (Rückschalten) verwendet sondern auch positiv. Der Kontakt müsste dafür nur im eine Einschaltunterdrückung erweitert werden, der interne Zähler gibt ja sowieso schon Auskunft darüber in welche Richtung (Schaltfunktion ausführen oder zurücknehmen) beim Ablauf der Zeit geschaltet wird.
- Der Kontakt (und das ist die einzige Neuerung die sich nicht mit den vorhandenen Variablen des Kontakts realisieren ließe) bekommt eine Schaltbedingung ähnlich wie an einem Signal. Wenn die Bedingung beim Befahren durch einen Zug erfüllt ist wird die Schaltaktion sofort ausgeführt, andernfalls der "wie oft versucht"-Zähler erhöht und die "Rückschaltzeit" auf einen definierbaren Wert gesetzt (Eingabefeld dafür ist ja auch schon vorhanden). Wenn die Zeit abgelaufen ist, wird die Bedingung erneut geprüft und falls sie mittlerweile Wahr ist die Schaltaktion ausgeführt. Andernfalls wird die Zeit wieder neu gesetzt und eben in t+x wieder versucht.

In der Summe müsste die Programmfunktion die das Befahren eines Kontakts behandelt und diejenige die die Rückschaltung beim Kontakt verarbeitet verändert werden, außerdem müssten die Kontakt bei denen das neue Feature genutzt werden soll mit einer entsprechenden Variable/Liste für die Bedingung ausgestattet werden.

Damit braucht man dann auch keine umständliche Zeitliste mehr sondern könnte Fahrstraßen relativ einfach implementieren (mit dem nötigen "Nachdenk-Aufwand" vorrausgesetzt..).

Gruß,

Tobi

[Jan Bochmann]

Guten Tag,

Hallo Jan!

zuerst mal Danke für die schnelle Antwort..
Tja, man steckt eben doch nicht im Quelltext, ganz ehrlich: Obwohl ich seit 15 Jahren in diversen Sprachen programmiere dürfte es mir sehr schwer fallen, ein Projekt wie BAHN so flüssig laufend auf die Beine zu stellen - dafür erstmal ein riesen Kompliment.
Trotzdem bin ich der Meinung, eine solche Liste mit Aufgaben die dann abgearbeitet werden könnte sinnvoll sein (evtl. auch für andere Aufgaben wie die angesprochene Schalt-Warteliste oder Dinge die mir im Moment nicht einfallen)...

Es kann sich in einem großen Netz um tausende Kontakte/Signale/Anlagen handeln. Bei variabler Länge quält man die Speicherverwaltung dann etwas. Das macht BAHN allerdings sowieso schon, und Windows ist in dieser Hinsicht besser als sein Ruf.

Mir schwebt dazu schon ein Konzept im Kopf herum, falls ich dir damit etwas Arbeit abnehmen kann würde ich das einfach mal zusammen schreiben bzw das ganze auch gleich in C pseudofertig programmieren. Ich habe durchaus auch noch andere Anschläge auf dich vor, wie z.B. eine externe API so das man Erweiterungen für Bahn bauen könnte (z.B. ein Gleisbildstellwerk oder einen damit verbundenen Fahrstraßeneditor der die Daten direkt in BAHN einfügt etc.).

Eine externe API als Schnittstelle via DLL-Funktionen gab es schon mal als Variation von BAHN 3.83 (nicht veröffentlicht, war für einen speziellen Kunden). Viel hat sie zwar nicht gemacht, aber zumindest gezeigt, daß so etwas im Prinzip möglich ist. U.a. konnte man damit die Daten einzelner Züge auslesen und Texte ins Streckennetz schreiben. Es ging allerdings dabei wohl nur um recht kleine Stadtbahnnetze. Ob und wie das mit wirklich großen Netzen funktioniert, müßte man probieren.

Aber jetzte erstmal der Reihe nach - falls grundsätzlich das Interesse bei dir da wäre so eine Sache zu implementieren gibt es bestimmt eine Möglichkeit das resourcenschonend umzusetzen - und wenn es dann hinterher doch nur ein Tool ist welches eine API anspricht oder eins der Editorfenster "klaut" und versucht, daraus schlau zu werden

Dann lieber eine ordentliche Schnittstelle als "klauen" aus dem Fenster. Im Fenster hast Du doch nur grafische Infos, die sich kaum sinnvoll auswerten lassen.

Schönen Gruß nach Essen,
Jan B.