Hawkeye

Hallo Andreas, genau das doch der Grundgedanke des Fahrstraßensystems! Ist eine Fahrstraße frei, kann sie aktiviert werden. Ist sie nicht frei, wird sie blockiert. Oder erst gar nicht aktiviert. Dein Gedankenfehler ist, das du diese Prüfung nur einmal zu einem bestimmten Zeitpunkt „Zug betritt Fahrstraße“ durchführen möchtest. Wenn die Fahrstraße zu genau diesem Ereignis blockiert ist, mußt du die Prüfung also zu einem anderen Zeitpunkt auch wiederholen. Siehe oben. Ich denke, das Rechenaufgaben keinen Einfluss auf die Performance haben, auch nicht bei größeren Anlagen. Da macht die Grafikberechnung der vielen Polygone eher Probleme. VG, Hawkeye

Hallo Andreas, genau, das geht doch auch. Bei dir nicht? Wenn eine der obigen Fahrstraßen auch sofort aktiviert wurde, kann das nicht passieren. Beispiel: Alle Fahrstraßen vom selben Signal aus in den Bahnhof erhalten das gleiche Schlagwort. Eine kleine Abfrage in der Schleife reicht. Es kann nur eine Fahrstraße geben, die aktiviert wird. Alle anderen sind dann automatisch "blockiert". Sind diese Fahrstraßen durch andere Fahrstraßen blockiert, dann wird eben auch keine aktiviert. Diese Abfrage wird ständig wiederholt, bis eine Fahrstraße mit dem entsprechenden Schlagwort frei ist. Einfacher geht es nicht. VG, Hawkeye

Hallo Andreas, Versuch das mal. VG, Hawkeye

Hatte ich so nicht verstanden, das dich die Signale stören. Das brauchst du nicht. Ordne die Signale einer anderen Ebene zu und blende diese Ebene aus. Dann sieht man die Signale auch nicht mehr. Die Steuerung funktioniert dann trotzdem noch. VG, Hakweye

Hallo, für Interessenten die vor Lua nicht zurückschrecken, hier mal eine Demo eines Kopfbahnhofes mit Lokwechsel auf 6 Gleisen. Es fahren auf der Anlage 4 Wechselzüge und 4 Triebzüge, die sich jeweils die freien Gleise im Kopfbahnhof suchen. Jeweils 2 Gleise teilen sich ein Abstellgleis mit bereitstehenden Loks zum Wechseln. Die Anlage ist auf die Neuerungen der Version V8 optimiert und läuft Fahrstraßen gesteuert vollautomatisch. Kopfbahnhof mit Lokwechsel auf allen Gleisen.mbp (Wem der Ablauf zu langsam erscheint, der kann ja die Zeitrafferfunktion einstellen. ) Viel Spaß beim Zuschauen. VG, Hawkeye

Hallo @Leihe, aufgrund deiner Information vermute ich, das du eine Blocksteuerung ohne Fahrstraßen erstellen möchtest. Leider hast du nicht verraten, welche MBS-Version du benutzt. Ab V7 gibt es aber schon Signale mit Grundfunktionen, die dir eine einfache Blocksteuerung erleichtern. Dazu reicht ein Ereignis in der EV aus. Hier ein kleines Beispiel. einfache Blocksteuerung.mbp VG, Hawkeye

Hallo Siggi, Brummi hatte damals, als er die KS-Signale erstellt hat klargestellt, das er nicht jede denkbar mögliche Kombination der KS-Signale berücksichtigen kann. In den Typen, die er erstellt hat, sind viele Variationsmöglichkeiten und Einstellungsmöglichkeiten durch Animationen enthalten. Schau sie dir doch erstmal genauer an. VG, Hawkeye

Doch, der Text „ falsche Schlußfolgerung“ bezieht sich nicht auf vorherige Beiträge. Ich hatte noch einen Beitrag erstellt. Da hatte ich aber einen Denkfehler und habe in wieder entfernt. Löschen geht nicht, also musste etwas stehenbleiben. VG, Hawkeye

Sorry, falsche Schlußfolgerung. 🙄 VG, Hawkeye

Moin, um die Beobachtung von Bahnkater weiter einzugrenzen, habe ich die Testanlage erweitert. Die Gerade sind auf exakt +/-50mm verlegt und die Gesamtlänge ist auf ca. 90.000mm vergrößert. Kameratest_V2.mbp 1. Umlauf: Die Kamera ist am letzten Wagen verknüpft und folgt der Lok nicht. Hier bleibt der Y-Wert nach einem Umlauf erhalten. 2. Umlauf: Die Kamera ist am letzten Wagen verknüpft und folgt der Lok in den Kurven. Hier stellt sich nach einem Umlauf schon eine Verschiebung von 0,2mm ein. Es muss also einen Zusammenhang mit der Koordinatentransformation durch die Relativbewegung der Kamera geben. VG, Hawkeye PS: @Bahnkater: Die schnellste Lösung für dein Problem ist, das Verfolgen der Lok abzuschalten und ggf. den Blickwinkel zu erhöhen.

Hallo Eggu, das sehe ich auch so. Ich hab mal zum Testen eine ähnliche Anlage, in einer "normalen" Größe erstellt. (X-Werte ca. +/- 10.000mm). Die Geraden liegen auf +/- 50mm. Hier bleibt die Kameraposition am letzten Wagen mit dem y-Wert auf der Geraden immer gleich bei 50 mit einer max. Abweichung +/- 0,01 Die Anlage von Bahnkater ist aber gigantisch! x-Werte bim Bereich von +/-83.000mm! Ich vermute, je größer die Zahlen mit denen die Position errechnet wird, umso weniger Nachkommastellen werden berücksichtigt. Dadurch können solche Rundungsfehler entstehen. Die sich nach einer Weile auch aufsummieren und zu solchen Effekten führen. Kameratest.mbp VG, Hawkeye

Hallo Bahnkater, der erste Schritt war doch, erstmal aus deinen dünnen Informationen die Beobachtung zu bestätigen und zu reproduzieren. Das haben Götz und ich ja auch endlich geschafft. Sicherlich wird sich @Neo das auch ansehen. VG, Hawkeye

Das stimmt. Es lässt sich auch leicht nachweisen. An einer beliebigen, möglichst geraden Strecke die Kameraposition mit der Position des verknüpften Wagens abgleichen. Hier die Y-Position der Kamera auf die 57,67 des Wagens setzen. Nach ein paar Umläufen die Position der Kamera zum Wagen an etwa derselben Stelle wieder vergleichen. Ich denke, das wegen der Größe der Anlage Rundungsfehler bei der Positionsberechnung der Grund sind, die sich nach einer gewissen Zeit dann auch in der Verschiebung bemerkbar machen. VG, Hawkeye

Hallo @Bahnkater deine Kamera ist auf einem Wagen mitfahrend verknüpft, und folgt fixiert gleichzeitig der Position dem VT11 (Triebkopf). Deshalb erfolgt bei Kurven natürlich eine relative Bewegung des VT11(Triebkopf) zum Standort der Kamera in x,y-Richtung und somit bewegt bzw. dreht sich die Kamera, um weiterhin den Triebkopf VT11 im Visier zu haben. Ist das die Bewegung der Kamera die du meinst? Das hast du doch selbst so eingestellt. Da aber der Drehpunkt der Kamera nicht das Zentrum der Kamera ist, nimmt man eine seitliche Verschiebung war. Auf gerader Strecke dürfte aber alles wieder in der "normalen" Position sein. Ist bei mir zumindest so. VG, Hawkeye

Hallo Helmut, wieso ist der Radius mit R323 vorgegeben? Die normale Weichen haben einen Radius von 490. Und die Kreuzungsweiche von Henry aus dem Katalog hat den Radius 495,02 (siehe Beitrag von Little). Bei diesem Radius hat das gebogene Gleisstück bei einem Winkel von 13° in etwa die Bogenlänge von 112,8 und entspricht somit der Länge der geraden Gleisstücke. Deine DKW sieht so aus. Betritt eine Lok die Kreuzung schaltet die DKW auf Gerade , weil die Bogengleise nicht erkannt werden. Viele Grüße, Hawkeye

Hallo @helmutwes, bei der Kreuzung fehlen die Verlängerungen vom Radius zu den Enden der Kreuzung. Du kannst das prüfen, indem du auf „technische Zeichnung“ gehst. Rote Striche zeigen eine fehlende Verbindung an. VG Hawkeye PS: Die Geraden sind zu lang. Die Enden der gebogenen Gleisstücke müssen an den gleichen Stellen der Geraden enden.

Hallo @RoniHB, ob das Nichtandocken von Straßen an Kreuzungen ein Fehler ist, kann ich nicht beantworten. Aber den Grund, warum die Straßen nicht an Kreuzungen andocken, den habe ich gefunden. Straßen haben eine Spur 0 als Spline der Kategorie "Nur 3D-Modell" definiert. Kreuzungen haben diese Spur nicht! Alle Spuren sind vom Typ "virtuell" in der Kategorie "Straße". Deshalb vermute ich, das man mit dem Gizmo (gelbes Quadrat) am Anfang oder Ende einer Straße auch nur an ein Modell der gleichen Kategorie und dem gleichen Typ andocken kann. Ändert man in der Straße die Kategorie von Typ "Nur 3D-Modell" auf "Straße" dann erfolgt zwar ein Andocken, aber an der falschen Stelle. Vielleicht hilft das erstmal als Begründung und Erläuterung. Viele Grüße, Hawkeye

Hallo Easy, eine schöne Erläuterung. Wenn ich z.B. das folgende Ereignis ausführe, ist klar, das der ICE auch sofort losfährt. Jetzt baue ich eine Verzögerung von 10 s ein, damit genau dieser Zug, den ich ja genau hier definiert habe, verzögert abfährt. Und jetzt erwartest du, das ich mir darüber absolut im Klaren sein muss, das vielleicht doch ein anderer Zug zu dem Zeitpunkt losfährt, weil die Variable ja in der Zwischenzeit während der Verzögerung überschrieben werden könnte. Echt jetzt? Viele Grüße, Hawkeye

Hallo Easy, das ist doch mal eine interessante Information, die man erst mal realisieren muß! Nur dumm, wenn einem der Wert, den man benötigt, nicht als Auslöser zu Auswahl angeboten wird und man deshalb auf eine Variable in Verbindung mit einer Verzögerung zurückgreifen muß. Dann darf man sich über ungewollte Effekte auch nicht wundern. Ich denke, die meisten Nutzer hier haben sich darüber bisher kaum Gedanken gemacht. Gruß, Hawkeye

Hallo Neo, da hast du wohl recht, am Auslöser scheint es nicht zu liegen. Das stimmt aber nur bedingt, es hängt damit zusammen welchen Variablen-Typ man in Verbindung mit einer Verzögerung verwendet. Bezieht man sich auf eine "Objektvariable", bei der das Objekt auch der Auslöser im Ereignis ist, dann geht es. Wird jedoch eine Verzögerung in Verbindung mit einer Modulvariablen verwendet, dann können diese Variablen während der "Verzögerungszeit" überschrieben werden. Zur Verdeutlichung hier ein Beispiel mit 4 Variationen und 2 gleich erscheinenden Ereignissen. 5 Signale werden um 2s zeitversetzt auf "Fahrt geschaltet. Die Loks fahren nach der eingestellten Verzögerungszeit (Voreinstellung = 4s) los, um eine Überlappung der Verzögerungen zu erreichen. (Diese Einstellung der Verzögerungszeit kann mit (+)/(-) variiert werden.) Zum Schalten der Signale kann aus 4 verschiedenen Steuerungsvarianten ausgewählt werden, die eigentlich alle das gleiche Schalt-Ergebnis liefern sollten. Dazu gibt es 2 Ereignisse, um den Unterschied zu verdeutlichen. "Beispiel 1" mit Verwendung einer Objektvariablen und "Beispiel 2" mit Verwendung einer Modulvariablen. (Welches Ereignis benutzt wird, kann mit dem "schwarzen Taster" umgeschaltet werden.) Erwarten würde ich, das alle 8 programmierten Varianten das gleiche Ergebnis liefern. Das tun sie aber nicht. Hier das Beispiel. Test Verzögerungen.mbp Nur wenn keine Verzögerung (Verzögerungszeit = 0s ) existiert, dann verhält sich das Ereignis mit der Modulvariablen genauso wie das mit der Objektvariablen. => Modulvariablen in Verbindung mit Verzögerungen sind mit Vorsicht zu verwenden. Viele Grüße, Hawkeye

Hallo Sintbert + Neo, ja, um so einen Effekt geht es. Es scheinen dabei Variabeln irgendwie überschrieben zu werden. Ich versuche mal etwas einfaches reproduzierbares zu erstellen, ist aber nicht so leicht. Viele Grüße, Hawkeye

Hallo @Neo, In der EV werden Verzögerungen, die im gleichen Ereignis stehen, zur Unterscheidung mit einer (Zahl) ergänzt. Auch wenn man das nicht in der grafische EV sehen kann, so wird es bei der Umwandlung in Lua deutlich : Bei der Automatisierung von Abläufen mit Verzögerungen in der EV kommt es aber immer wieder vor, das "längere" Verzögerungen mit gleichem Namen wieder aufgerufen werden, bevor die zuerst aufgerufene Verzögerung mit dem selben Namen abgelaufen ist. Dadurch wird die erste Verzögerung überschrieben und es fährt z.B. ein ganz anderes, als das gewollte Fahrzeug los. Das zu verstehen, bis man diesen Fehler gefunden hat, dauert lange! Hier würde ich mir wünschen, das Verzögerungen intern zusätzlich automatische eine längere Zufallszahl verpasst bekommen, so das auch bei Aufruf des gleichen Ereignisses für andere Fahrzeuge innerhalb der Verzögerungszeit eine Unterscheidung bestehen bleibt. Oder alternativ, das man in der grafischen EV selber einen eigenen Verzögerungsnamen mit einer selbst gewählten Variablen (z.B. dem Fahrzeugnamen) setzten oder ergänzen kann, ohne auf Lua zurückgreifen zu müssen. Damit wäre eine Unterscheidung auch sichergestellt. Viele Grüße, Hawkeye

Hallo @BahnUropa, deine Texturdatei hat wohl eine falsches Dateiformat. Im deinem Verzeichnis liegt sie als .jpg vor. Viele Grüße, Hawkeye

Hallo Bahnland, das ist im Moment ja auch möglich. Interessant was dieser Einwand wieder für Wellen schlägt. Ich wollte mich mit meiner Anmerkung auch nur auf ein schon mal geführtes Thema beziehen. Ob diese Zukunftsvision von Neo möglich ist, wenn in Fahrzeugen bei der Definition der Seiten unterschiedliche Logiken angewandt werden, wage ich aber dann doch zu bezweifeln. Viele Grüße, Hawkeye

Hallo Bahnland, diese Logik ist aus deiner Sichtweise auch verständlich. Ich wollte nur darauf hinweisen, das bei den bisherigen Triebwagen anderer Modellbauer die Seite "links" immer aus der Cockpit-Ansicht definiert wurde und danach auch die EV-Steuerungen zum Öffnen von Türen programmiert sind. Bei diesem Modell und deiner Logik muss man jetzt die Seiten in der Fahrzeug -Variablen vertauschen. 1 = "Türen rechts" und 2 = "Türen links" , sonst geht die falsche Seite auf. Es liegt dann also nicht an einem Fehler in der Programmierung, sondern an der Reihenfolge der in diesem Steuerwagen definierten Variablen. Das sollte man dann auch wissen, damit man es (an der richtigen Stelle) auch berücksichtigen kann. VG, Hawkeye