tim-fischertechnik

Hallo @Roter Brummer, wäre es möglich, die gelbe Lampe im bestehenden Modell "H/V Hauptsperrsignal" (612B493E-D335-408D-A07D-0D13B98F20BA) mittels einer Animation ein- und auszublenden, ähnlich wie du es mit dem Sh1-Begriff und dem Zs7-Begriff bei deinen KS-Signalen gelöst hast? Im Vorbild benötigt man nicht immer den Begriff "Hp2-Langsamfahrt", sondern nur den Hp1-Fahrtbegriff, wenn die Ausfahrt ausschließlich über den geraden Abzweig einer Weiche folgt. In diesem Fall (Signal P2 im Bild) kann die gelbe Lampe am Mastschirm entfallen. Ich habe hier mal ein Foto vom "echten" Vorbild geschossen. Das linke Signal P1 kann nur den Begriff Hp2 anzeigen, während das andere Signal P2 nur den Begriff Hp1 darstellen kann, da hier mit der im Fahrplan vorgeschriebenen Höchstgeschwindigkeit über den geraden Abzweig gefahren werden kann. Folglich fehlt die gelbe Leuchte am Signal P2. Liebe Grüße Tim

Hallo @Markus4.1, du möchtest ja auf deiner Anlage Türen bei verschiedenen Fahrzeugen öffnen und schließen. Ich habe mir nochmal deine Beispielanlage angeschaut und dabei ist mir aufgefallen, dass die Animationen noch nicht richtig funktionieren, wenn ich beispielsweise die Ausfahrt für den ICE 4 auf Gleis 3 stelle. Dann erscheint folgende Fehlermeldung (dazu einfach die EV-Protokollierung öffnen): attempt to index an nil value (field '31-Türen rechts'). Die EV versucht vergeblich einen Wagen zu animieren, der die Animation "31-Türen rechts" enthält und da die EV diesen Namen nicht findet (das erkennst du an "nil value"), gibt diese eine Fehlermeldung aus. Du hast in deiner Anlage das Schlagwort "ICE mit Türen" in "Zug mit Türen" für den ICE und die EV umbenannt und allen übrigen Fahrzeugen ebenfalls dieses neue Schlagwort vergeben. Vermutlich, weil du damit alle Züge ansprechen wolltest. Das Problem dabei ist, dass die EV alle Wagons anspricht, ganz egal ob sie eine Animation mit den Namen "31-Türen rechts" enthalten oder eben nicht. Beim ICE 1 lautet die Animation für die rechte Türseite "Türen rechts", was letztlich zum Fehler in deiner Anlage führt, weil die EV keine Animation mit dem Namen "31-Türen rechts" im ICE 1 vorfindet und dann abbricht. Damit die Türen richtig funktionieren musst du also dafür sorgen, dass du: keine Schlagwörter mehr verwendest, sondern eine Liste, in der du alle Wagons eines Zugpaares als Objekt einträgst. Diese Liste habe ich "Zugverbund" genannt und jedem Auslöser, also jedem Fahrzeug mit Antrieb zugewiesen. Jeder ICE beinhaltet 2 Triebköpfe [Auslöser]. Grafik 2/4: Anleitung - Anlegen der Liste Zugverbund Am einfachsten legst du diese Liste an, indem du mit linker Maustaste einen Doppelklick auf einen Wagon des Zugpaares machst. Dann sind alle Wagons dieses Zugpaars ausgewählt und du kannst diese bequem mit "STRG + C" kopieren. Wenn du die Liste "Zugverbund" angelegt hast, kannst du die ausgewählten Wagen mit "STRG + V" in die Liste einfügen. Du hast nun eine vollständige Liste angelegt und kannst dir wieder Arbeit ersparen, indem du einfach die Liste mithilfe der Icons kopieren und einfügen in den anderen Triebkopf [Auslöser] überträgst. Die Liste bleibt ja gleich. Durch die Liste wird nun sichergestellt, dass sich nur Türen von ICE 4-Zügen öffnen, wenn die Züge auch wirklich am Bahnsteig halten und nicht etwa auf freier Strecke fahren. Da alle Wagons im vorherigen Anlagenbeispiel das Schlagwort "ICE mit Türen" besaßen, öffneten und schlossen sich diese gleichzeitig. Durch die Liste schafft man eine zugspezifische Unterscheidung, weil nur die Wagen des betroffenen Zuges angesprochen werden. Grafik 2/5: Wiederholung von Schlagwort in Liste In der EV ersetzt man nun die Wiederholung "Für Objekte mit einem Schlagwort" durch "Für Elemente in einer Liste. Grafik 2/6: Liste Zugverbund in Wiederholung einbinden Dabei wählt man als "erweiterte Variable" die Liste "Zugverbund" und als Auslöser den Typ Fahrzeug aus. Die erste Version beinhaltet diese Veränderungen. Zwar öffnen sich nun die Türen wirklich nur, wenn der Zug am Bahnhof steht aber auch nur beim ICE 4. Beim Regio Shuttle taucht wieder eine Fehlermeldung auf, weil die Namen der Türanimationen unterschiedlich sind. die unterschiedliche Bezeichnung der Türanimation berücksichtigst. Dazu habe ich jedem Wagen eine Tabelle mit den Namen „Türen“ zugewiesen. Diese beinhaltet zwei Einträge (Index). Dem ersten Eintrag „links“ wird der Name der Animation für die linke Türseite des jeweiligen Wagons als Text zugewiesen. Du musst also schauen, wie der Text der Animation genau lautet. Grafik 2/7: Anleitung - Anlegen der Tabelle Türen Beim ICE 4 lautet dieser für die linke Türseite „32-Türen links“, beim Regio Shuttle „Türen links“. Beim zweiten Eintrag „rechts“ gehst du genauso wie beim ersten Eintrag vor, nur dass es sich hierbei um die rechte Türseite dreht. In der zweiten Anlagenversion öffnen sich nun alle Türen unabhängig von der Zuggattung. Hier findet ihr beiden Lösungsvorschläge: 2. Lösungsvorschlag - Version 1.mbp (Türen von ICE 4 – Zügen öffnen nicht mehr auf freier Strecke) 2. Lösungsvorschlag - Version 2.mbp (alle Türen öffnen/schließen sich unabhängig der Zuggattung) Mit der zweiten Version hätten wir diesen Wunsch erfüllt. Viel Spaß beim Ausprobieren Liebe Grüße Tim

Hallo @EASY, ich habe eine Lösung parat. Und zwar kannst du mit der String-Bibliothek den Befehl gmatch verwenden. Mit diesem kann man in einem String nach einem bestimmten Pattern suchen. Wenn das passende Pattern gefunden wird, wir der gesuchte "Stringschnipsel" zurückgegeben, andernfalls der Wert nil. -- https://community.3d-modellbahn.de/forums/topic/7558-frage-zu-layouttime/ timeAsString = tostring(layout.time) -- lese die Zeit aus und wandle diese in einen String print("Aktuelle Uhrzeit: "..timeAsString.." Uhr") -- gebe die Aktuelle Zeit aus hours = string.match(timeAsString, "(%d+)") -- suche nach Pattern hh minutes = string.match(timeAsString, "(%d+)", -2) -- suche nach Pattern mm print(hours.."h"..":"..minutes.."min") hoursToMinutes = hours * 60; -- wandle Stunden in Minuten um print(hours.."h = "..hoursToMinutes.."min") minuten_gesamt = hoursToMinutes + minutes -- addiere restliche Minuten dazu print("Gesamtminuten: "..minuten_gesamt) timeToNumber = minuten_gesamt/1440 -- Teile Gesamtminuten durch einen Tag (24h*60min=1440min) print(timeToNumber) timeToNumber = minuten_gesamt/1440 -- Teile Stunden durch einen Tag (24h*60min=1440min) print(timeToNumber) Das habe mal auf die Schnelle zusammengebastelt. Das Ereignis wird jede Minute ausgelöst. Bestimmt lässt sich dort noch was vereinfachen. Hier noch ein die Content-ID: 1E20E137-B1EC-42C1-9643-B026E2417032 Liebe Grüße Tim

Hallo zusammen, in dem vorherigen Beitrag habe ich nur kurz die Anlage beschrieben. Die Beschreibung der EV und der Änderungen möchte ich nun nachholen. Wie man EV-Ereignisse durch Schlagworte in den Auslösern klassifiziert: Im Gegensatz zum ersten Lösungsvorschlag wollen wir nicht nur an einem bestimmten Bahnsteig die Türen öffnen, sondern an x-beliebig vielen. Dazu reicht aber ein einzelner Auslöser als Objekt, wie beispielsweiße das KS-Signal allein nicht aus, weil es nur die Aktionen für den ganz spezifischen Bahnsteig auslöst. Wir versuchen die Steuerung über die EV generisch aufzubauen, d.h. zu verallgemeinern. Dazu eignen sich Schlagworte. Für jeden gleichen Aufgabenzweck, der durch denselben Auslöser wie beispielsweiße einen Gleiskontakt ausgelöst werden soll, weisen wir allen Auslösern dasselbe Schlagwort mit einem treffenden Namen wie zum Beispiel "GK-Bahnsteig" zu. Die EV bietet nämlich die hervorragende Möglichkeit, Ereignisse auf Auslöser mit bestimmtem Schlagwort zu beschränken. Es ist natürlich genauso möglich, einem Auslöser mehrere Schlagwörter zuzuweisen, wenn dieser mehrere voneinander unabhängige "Aufgaben" auslösen soll. Auf jeden Fall vermeiden wir durch die Verschlagwortung in der EV ähnelnde Einträge, die die Objekte direkt und nicht generisch ansprechen und sich quasi nur in der Namensgebung (Adressierung der Objekte) unterscheiden. In der folgenden Übersicht sind die Unterschiede von der eindeutigen Adressierung zur generischen Adressierung aufgeführt: Signal (1 Objekt) mit Namen "KS-Hauptsignal“ → Signale (x Objekte) mit Schlagwort "Ausfahrtsignal" Gleiskontakte (2 Objekte) mit Namen "Kontakt 3 - linker Bahnsteig" und "Kontakt 3 - rechter Bahnsteig“ → Gleiskontakte (x Objekte) mit Schlagwort "GK-Bahnsteig" Gleiskontakt (1 Objekt) mit Namen "KS-Hauptsignal“ → Gleiskontakte (x Objekte) mit Schlagwort "Ausfahrtsignal" Wie man die EV vereinfacht: In der Anlage habe ich das Ereignis "Zug betritt Bahnhofsgleis", welches beim Betreten des Gleises "Bahnhofsgleis" ausgelöst wurde, gelöscht und die Aktionen im Ereignis "Bahnsteigs-Gleiskontakt wird betreten bei der Einfahrt" an oberster Stelle platziert. Dabei ändert sich der Auslöser vom Gleis zum Gleiskontakt. Grafik 2/1 - geänderter Auslöser Wie Züge in Kopfbahnhöfen umkehren und in Durchgangsbahnhöfen die Fahrrichtung beibehalten: Als ich diese Änderungen vorgenommen hatte, fiel mir auf, dass der ICE an dem Durchgangsbahnhof Neumünster einfach wieder in die entgegengesetzte Richtung zurück zum Kopfbahnhof fuhr, anstatt weiter die Fahrrichtung beizubehalten. Der Grund liegt darin, dass ich noch keine Unterscheidung zwischen einem Kopfbahnhof mit verbundener Fahrrichtungsumkehr und einem Durchgangsbahnhof unter Beibehaltung der Fahrrichtung vorgenommen hatte. Dazu habe ich jedem Gleiskontakt mit dem Schlagwort "GK-Bahnsteig" die Boolesche Variable "Fahrtrichtungsumkehr" zugewiesen und diese auf den Wert "True" gesetzt, wenn die Fahrtrichtung z.B.: im Kopfbahnhof umgekehrt wird. Jedem Triebkopf habe ich die Objektvariable "andere Triebkopf" zugewiesen und als Wert genau den gegenüberliegenden Triebkopf im Zugverbund zugeordnet. In einer Bedingung prüfe ich, ob die Variable "Fahrtrichtungsumkehr" den Wert "True" aufweist. Grafik 2/2 - Bedingung Fahrtrichtungsumkehr Die Variable Fahrtrichtungsumkehr ist jedem Gleiskontakt mit dem Schlagwort "GK-Bahnsteig" zugeordnet. Wenn das Signal schaltet, muss aber auf genau diese Variable zugegriffen werden. Jetzt könnte man jedem Ausfahrtsignal den Gleiskontakt in einer Objektvariable zuweisen. Wir möchten jedoch nicht die mühselige Arbeit von Hand erledigen, sondern weisen den Bezug automatisch mittels der EV zu, wenn der Gleiskontakt betreten wurde. Wie dies funktioniert, verdeutlicht die folgende Grafik. Grafik 2/3 - automatische Variablenzuweisung Hier findet ihr noch ein Erklärvideo von Götz, worin das Konzept von erweiterten und verschachtelten Variablen nochmal erklärt wird: erweiterte Variablen - YouTube Wie Türen nicht einfach bei rotem Signal schließen oder Züge losfahren: Durch die neu eingerichteten Fahrstraßen fällt das Ausfahrtsignal selbstständig auf Hp0 zurück, ehe der Zug das Signal vollständig verlassen hat. Der Zug ist im Gegensatz zu den vorherigen Anlagen noch am Signal angemeldet, wenn das Signal schon Hp0 zeigt. Das ist problematisch, da beim Zurückfallen des Signals auf Hp0 die Türen erneut mitten auf freier Strecke geschlossen werden und der ICE plötzlich abrupt auf 10 km/h abbremst, weil dieser immer noch am Signal angemeldet ist. Was noch nicht funktioniert und demnächst behandelt werden soll: Animationen starten nicht an der aktuellen Position, sondern immer am Anfang. Bislang öffnen und schließen sich die Türen nur bei einer Zuggattung, dem ICE. Die Triebköpfe wechseln nicht automatisch das Spitzenlicht. Teilt mir gerne eure Wünsche und Anregungen mit. Liebe Grüße Tim

2. Lösungsvorschlag - Türsteuerung mithilfe einer Liste mit Objektvariablen (Schlagworte) Hallo zusammen, leider bin ich seit gestern gesundheitlich angeschlagen und mir fehlt die nötige Ruhe und Kraft gerade. Den bisherigen Stand möchte ich euch dennoch nicht vorenthalten. Die Anlage stell die Ausgangssituation für den zweiten Lösungsvorschlag dar. kurze Beschreibung: Die Anlage beinhaltet zwei Bahnhöfe mit je zwei Gleisen. Die ICEs pendeln zwischen den zwei Bahnhöfen über die automatische Fahrstraßensteuerung. Diese Anlage soll zeigen, dass Schlagworte bei mehreren ICEs nicht mehr viel Sinn ergeben, da sich plötzlich die Türen bei sämtlichen ICEs öffnen, egal ob sie mitten auf freier Strecke fahren oder gerade am Bahnhof stehen. 2. Lösungsvorschlag - Ausgangssituation.mbp Herzliche Grüße Tim

Hallo Neulich, ja du hast Recht. Das war Murks von mir. Vermutlich ist es diesem Grund geschuldet: Ich wollte ein Augenmerk darauf legen, dass die Gleiskontakte auch farblich zu den Bahnsteigbezeichnungen passen, damit man versteht, welchen Wert die Variable "linke Bahnsteigseite" bei der jeweiligen Seite aufweist und ich habe es als Herausforderung für mich gesehen, das Positionieren von Objekten mithilfe von Lua zu verstehen. Ich habe dein Anliegen berücksichtig und stelle hier nochmal eine modifizierte Anlage ein. Start und Stopp im Bahnhof Testanlage - Version 5.mbp Da ich selbst Modellbauer bin, kann ich dir beruhigt sagen, dass so ein Gleiskontakt gerade mal 32 Polygone (Dreiecke) beinhaltet. Wenn man an irgendeiner Stelle im Programm Polygone einsparen kann, ist das mehr als gut, da die Framerate darunter nicht so sehr leidet aber verglichen mit anderen Modellen ist der Einfluss nur marginal auf die Performance. Ich verstehe deinen Einwand, dass man solche Betriebsabläufe nur über einen Gleiskontakt dem KS-Signal steuern kann, wie du eindrücklich in deinem Testlayout gezeigt hast. Damit benötigt man nur ein Ereignis. Leider wird dann die EV recht groß und unübersichtlich. Es ist besser, wenn man solche Betriebsabläufe auf viele kleine verschiedene Ereignisse aufteilt, weil man es besser terminieren und strukturieren kann. Das würde ich dir als Tipp raten. Grundsätzlich gibt es ganz verschiedene Lösungsansätze für ein und dasselbe Problem. Daher kann ich nicht ganz diesen Einwand nachvollziehen, weil ich mich bemühe, die EV so minimalistisch wie möglich aufzubauen. In der Tutorialreihe wird es fortlaufend Verbesserungsvorschläge geben. Am Ende habe ich dann quasi eine fast "perfekte" Lösung parat. Diese Punkte werde ich an gegebener Stelle auch noch in mein Anlagenlayout einfügen, wenn es thematisch passt. Liebe Grüße, Tim

Inspiriert von Götz möchte ich die Türsteuerung für beide Bahnsteigseiten nach dem Schema umzusetzen, da der Code wesentlich schlanker und übersichtlicher wird. Wir benötigen im Gegensatz zur vorherigen Anlage zusätzlich die Information über die Bahnsteigseite. Wir entscheiden uns einfach für die linke Bahnsteigseite, da wir sie zuvor immer angefahren haben, und weisen dem Gleiskontakt die boolesche Variable „linke Bahnsteigsseite“ mit dem Wert „true“ zu. Konkret steht der Wert der booleschen Variablen für Folgendes: linke Bahnsteigsseite = true --> linke Bahnsteigseite linke Bahnsteigsseite = false --> rechte Bahnsteigseite Boolesche Variablen können im Gegensatz zu Zahlen nur zwei Werte (true und false) darstellen, eignen sich aber prima für Bedingungen, weil diese ebenfalls nur „wahr“ oder „falsch“ zurückgeben. Grafik 1/8: Wertetabelle - Türen öffnen schließen auf beiden Bahnsteigseiten Wenn wir diese Wertetabelle anschauen, sehen wir, dass sich die ersten vier Fälle in ihren Ergebnissen genau spiegelverkehrt zu den übrigen Fällen verhalten. Die Fälle 5 bis 8 sind uns schon bekannt, da wir hier die linke Bahnsteigseite wie im vorherigen Lösungsvorschlag anfahren. Da liegt es doch nahe, wenn wir mit einer zusätzlichen Bedingung überprüfen, ob die Variable „linke Bahnsteigseite“ im Gleiskontakt den Wert „true“ enthält und wir die Animationen für die rechte Bahnsteigseite vertauschen. Grafik 1/9: ausführliche EV - Türen auf beiden Bahnsteigseiten öffnen Das funktioniert recht gut, doch wir haben im Beitrag von Götz gelernt, dass wir Aussagen so zusammenfassen können, dass diese nur mit einer einzigen Bedingung überprüft werden können. Beim ersten und achten Fall in der Wertetabelle sind alle drei Aussagen entweder falsch oder wahr. Dabei spielt es keine Rolle ob, wir nur zwei Faktoren, Faktor A == Faktor B drei Faktoren, (Faktor A == Faktor B) == Faktor C vier Faktoren, ((Faktor A == Faktor B) == Faktor C) == Faktor D oder gar fünf Faktoren (((Faktor A == Faktor B) == Faktor C) == Faktor D) == Faktor E verwenden. Wir müssen natürlich auf die Klammern achten. Wenn ein weiterer Faktor hinzukommt, nennt man das auch Kaskadierung, weil ein weiterer Fall (Kaskade) das Ergebnis in die eine oder andere Richtung kippt. Für unsere drei Aussagen gilt nach dem Schema Folgendes: (linke Bahnsteigsseite == Schlagwort „andere Türseite“ im Auslöser) == Schlagwort „andere Türseite“ im Wagon Wir haben nun das Problem, dass wir mit der grafischen EV maximal 2 Variablen gleichzeitig vergleichen können. Wir haben zwei Möglichkeiten das Problem zu umgehen: Wir vergleichen immer zwei Variablen der Reihe nach und speichern das Zwischenergebnis. Mit steigender Zahl an Faktoren wird dieses Prinzip jedoch unhandlich. Wir nutzen in der grafischen EV die Skript-Bedingung. Dort schreiben wir einen Einzeiler in der Programmiersprache Lua. Ihr braucht keine Sorge haben, Lua zu lernen, da man die grafische EV einfach in Lua umwandeln kann. Wir entscheiden uns hierfür. Skript Bedingung Nr. 1: Grafik 1/10: kompakte EV - Türen auf beiden Bahnsteigseiten öffnen Das Ereignis: „Kontakt 3 wird betreten bei der Einfahrt (kompakt)“ kann jetzt durch zwei Gleiskontakte ausgelöst werden. Vor der Wiederholung weisen wir dem Fahrzeug den Wert der Bahnsteigseite mittels der Variablen „linke Bahnsteigsseite“ aus dem Gleiskontakt zu. Das dient später im Ereignis „Wenn das KS Hauptsignal schaltet (kompakt)“ dazu, die Bahnsteigseite zu identifizieren, da auf das Fahrzeug nicht direkt als Auslöser zurückgegriffen werden kann. Der Auslöser bei diesem Ereignis ist ein Signal, das jedoch den Zug in seiner Objektvariablen „zug“ abgespeichert hat. Die fertige Lua-Zeile für die Skript Bedingung Nr. 1 lautet: return (vehicle.variables["andere Türseite"] == Wagon.variables["andere Türseite"]) == contact.variables["linke Bahnsteigsseite"] Wie kommen wir jetzt aber darauf? Wir wandeln die einzelnen Bedingungen in ein Skript um und fügen die einzelnen Codestücke über Copy & Paste in die Skript-Bedingung ein. Wir löschen doppelte Animationen heraus. Wir legen an oberster Stelle die Skript-Bedingung an. Wir verschieben die Animationen in die Skript-Bedingung, sodass die Animation mit der rechten Seite im oberen Block der Bedingung angeordnet wird und die linke Seite im unteren Block. In der Wiederholung haben wir 3 Bedingungen (Skript-Bedingung ausgenommen). Zwei davon sind unterschiedlich. Jede unterschiedliche Bedingung wandeln wir in ein Skript um. Die Bedingung, bei der if vehicle.variables["andere Türseite"] == Wagon.variables["andere Türseite"] then end steht fügen wir als erstes in die Skript-Bedingung ein. Dabei lassen wir das "if", "then" und "end" weg und setzen es vor "return". Um diesen Code bilden wir noch eine öffnende und schließende runde Klammer. Ans Ende fügen wir zwei Gleichheitszeichen. Die andere umgewandelte Bedingung fügen wir ebenfalls in die Skript-Bedingung ein. Der Wert "True" wird nicht kopiert. Dabei müssen wir nicht einmal wissen, wofür jede Bezeichnung genau steht. Return steht für den Rückgabewert. Bei jeder Skript-Bedingung wird ein boolescher Wert zurückgegeben, der entweder wahr oder unwahr ist. engl. vehicle = Fahrzeug | Wagon = Name, den wir uns in unserer Wiederholung ausgedacht haben | engl. contact = Gleiskontakt .variables[" "] steht dafür, dass ein Objekt einen Bezug (Referenz) zu einer Variablen besitzt. Die Klammern mit den doppelten Anführungszeichen umschließen den Variablennamen "Eingedeutscht" sähe der Code so aus: gebe_ zurück (Fahrzeug.Variable["andere Türseite"] == Wagon.Variable["andere Türseite"]) == Gleiskontakt.Variable["linke Bahnsteigsseite"] Grafik 1/11: kompakte EV - Türen auf beiden Bahnsteigseiten schließen Im Ereignis „Wenn das KS Hauptsignal schaltet (kompakt)“ löschen wir die Variable „linke Bahnsteigsseite“ im Triebkopf. Skript Bedingung Nr. 2: return (signal.variables["zug"].variables["andere Türseite"] == Wagon.variables["andere Türseite"]) == signal.variables["zug"].variables["linke Bahnsteigsseite"] engl. signal = Signal Bei diesem Konstrukt: signal.variables["zug"].variables["linke Bahnsteigsseite"] haben wir zwei Variablen. Anlagenlayout – Version 5 Start und Stopp im Bahnhof Testanlage - Version 5.mbp Liebe Grüße, Tim

Hallo liebe Community, heute stelle ich euch vor, wie wir die Türsteuerung für beide Bahnsteigseiten umsetzen werden. Die Bahn hat dafür ein milliardenschweres Investitionspaket für einen neuartiges Bahnsteigkonzept ausgeben. Es handelt sich hierbei um ein Pilotprojekt, einen verschwenkbaren Bahnsteig, der sich mittels eines Schalters verschwenken lässt. Einige Anwohner munkeln, dass das übrige Geld für den geplanten Streckenausbau nicht mehr ausgereicht hatte und eine Kehrschleife die momentan praktikabelste Lösung darstellt. Grafik 1/7: Konfigurierung der GK für Bahnsteigseiten Sobald der Schalter betätigt wird, wird der aktuell sichtbare Bahnsteig ausgeblendet und der gegenüberliegende Bahnsteig eingeblendet. Zudem wird für jede Bahnsteigseite ein gleichfarbiger Gleiskontakt auf dem Stumpfgleis positioniert. Beide Gleiskontakte beinhalten das Schlagwort „GK-Bahnsteig“ das momentan noch irrelevant für den Ablauf ist und die boolesche Variable „linke Bahnsteigsseite“. Nur auf der linken Bahnsteigseite ist der Wert dieser Variablen wahr, also true. Später möchten wir sicherlich keinen verschwenkbaren Bahnsteig mehr haben und entscheiden uns dann für einen der beiden Gleiskontakte entsprechend der Bahnsteigseite. Für unser Tutorial wird in Zukunft nur noch das Ereignismodul „Tutorial-Modul“ relevant sein. Alle übrigen Module sind für die eigentliche Türsteuerung irrelevant und müssen weder berücksichtigt noch verändert werden. Wenn der ICE zweimal in den Bahnhof gefahren ist, verschwenkt er beim Betreten eines Gleiskontaktes in der Kehrschleife automatisch den Bahnsteig um. (Fortsetzung folgt in Kürze)

Vorkehrungen: Wir überlegen uns, nach welchen Kriterien wir die Fahrtrichtung unterscheiden können. Die Türen öffnen sich immer, wenn der Kontakt 3 von einem Triebkopf betreten wird. In der Grafik „1/1 – Türen öffnen abhängig von Fahrtrichtung“ sehen wir, dass abhängig von der Fahrrichtung immer ein anderer Triebkopf diesen Kontakt betritt (linker Bildteil). Glücklicherweise haben wir nur dem Triebkopf A das Schlagwort „andere Türseite“ zugewiesen und können so eine Unterscheidung zwischen den beiden Triebköpfen fällen. Voraussetzung dafür ist natürlich, dass der Antrieb des vorderen Triebkopfs immer eingeschaltet ist, da sonst der GK kein Ereignis auslöst und dass die Geschwindigkeit größer Null ist, da sonst fälschlicherweise der andere Triebkopf das Ereignis auslöst, was wir unbedingt vermeiden wollen. Wir nutzen nämlich das Vorhandensein des Schlagwortes im auslösenden Triebkopf dazu, um indirekt die Fahrrichtung zu bestimmen. Aus diesen Vorüberlegungen können wir unseren neuen Kriterienkatalog bilden. Neuer Kriterienkatalog: Unter folgenden Rahmenbedingungen: Züge können beide Fahrtrichtungen annehmen (Kehrschleife). Die Mittelwagen im ICE haben dieselbe z-Ausrichtung wie Triebkopf B. Beide Antriebe des Zugpaares sind aktiviert. Der vordere Triebkopf in Fahrrichtung muss zuvor über mindestens einen Brems- oder Beschleunigungskontakt (auch Signal) gefahren sein, damit die Geschwindigkeit nicht Null ist. Triebkopf A enthält das Schlagwort: „andere Türseite“. sollen folgende Aufgaben/ Kriterien erfüllt sein: Alle Türen des gesamten Zuges (ICEs) sollen sich schließen und öffnen lassen. Die Türen müssen auf der richtigen Bahnsteigseite öffnen und schließen. Wagons ohne Türanimation sollten keine Fehler in der EV verursachen. Beschreibung der EV: Grafik 1/2: EV für fahrrichtungsabhängiges Türöffnen Im Ereignis „Kontakt 3 wird betreten bei der Einfahrt“ prüfen wir, ob der Auslöser [Fahrzeug] über das Schlagwort „andere Türseite“ verfügt. Wenn das Schlagwort existiert, dann ist der ICE mit umgekehrter Fahrtrichtung in den Bahnhof eingefahren und alle linken Türen (Ausnahme Triebkopf A: rechte Tür) öffnen sich. Wenn der ICE mit dem Triebkopf B in Fahrtrichtung in den Bahnhof fährt, ist im Auslöser (Triebkopf B) kein Schlagwort „andere Türseite“ vorhanden, weshalb sich alle rechten Türen (Ausnahme Triebkopf A: linke Tür) öffnen. Auffällig ist, dass die unteren beiden Aktionen im Gegensatz zu den oberen beiden Aktionen genau spiegelverkehrt angeordnet sind, weil sich die Ausrichtung des gesamten Zuges um 180° umkehrt. Ich persönlich finde solche Fallbeschreibungen in Textform nicht sonderlich verständlich. Dafür eigenen sich sogenannte Wahrheitstabellen viel besser. Grafik 1/3: Wahrheitstabelle Tür öffnen In ihnen fassen wir die Zustände in Form von Zahlen (0 = falsch | 1 = wahr) tabellarisch zusammen, sodass wir am Ende eine Ergebniszeile für die linke und rechte Tür erhalten, wo jeder Zustand eindeutig ist. Solche Wahrheitstabellen sind viel übersichtlicher. Für das andere Ereignis „Wenn das KS Hauptsignal schaltet“ sieht die Wahrheitstabelle wie folgt aus: Grafik 1/4: Wahrheitstabelle Tür schließen Im Gegensatz zur vorherigen Wertetabelle ist die zweite Bedingung nicht mehr negiert. Wir können jedoch bei diesem Ereignis nicht direkt auf das Fahrzeug als Auslöser zugreifen aber wir haben ja den Auslöser im Signal abgespeichert. Grafik 1/5: Aufbau von erweiterten Variablen Deswegen greifen wir auf das Schlagwort „andere Türseite“ im Triebkopf zu, der wiederum in der Objektvariable „zug“ im Signal abgespeichert ist. Die grafische EV setzt jetzt genau das um, was in der Wahrheitstabelle steht. Grafik 1/6: EV für fahrrichtungsabhängiges Türschließen Hier findet ihr wieder die zugehörige Anlage. Start und Stopp im Bahnhof Testanlage - Version 4.mbp Viel Spaß beim Ausprobieren! Herzliche Grüße Tim

Hallo zusammen, nachdem wir im letzten Beitrag den falsch "herum gedrehten" Triebkopf in der EV mit berücksichtig haben, damit die Tür auch wirklich auf der richtigen Seite öffnet, können wir behaupten, dass wir alle 3 Aufgaben erfüllt haben. Durch die Schlagworte "ICE mit Türen" in allen Wagen stellen wir sicher, dass alle Türen des gesamten Zuges animiert sind. Durch Berücksichtigung des "falsch herum" gedrehten Triebkopfs korrigieren wir die Ausrichtung, sodass am Ende die Tür dennoch auf der richtigen Seite öffnet. Der "falsch herum" gedrehte Triebkopf erhielt dazu das Schlagwort "andere Türseite". Wir verschlagworten erstmal nur Wagen, die überhaupt eine Türanimation besitzen und identische Bezeichnungen für die beiden Türanimationen "31-Türen rechts" bzw. "32-Türen links" enthalten. Dankenswerterweise ist das beim ICE 4 von unserem Modellbauer Reinhard kein Problem. ... oder vielleicht doch nicht? Wenn wir die Datei "Start und Stopp im Bahnhof Testanlage - Version 3.mbp" von mir öffnen, dann funktioniert alles reibungslos. Öffnen wir dagegen die modifizierte Version „Start und Stopp im Bahnhof Testanlage - Version 3 (mod).mbp“ von Bahnland mit der Kehrschleife, Grafik 1/1: Türen öffnen abhängig von Fahrtrichtung Die obige Grafik spiegelt die Ausgangsituation von Bahnlands modifizierter Anlage wider. Anhand dieser können wir erkennen, dass bei normaler Fahrtrichtung die Türen alle auf der Bahnsteigseite öffnen, während bei umgekehrter Fahrtrichtung sie auf der „falschen" Seite öffnen. Das liegt hier auch wieder an der geänderten Ausrichtung des gesamten Zuges in z-Richtung um genau 180°. Wir sehen also, dass Aufgaben nur innerhalb bestimmter Rahmenbedingungen gültig sind. Sobald wir die Fahrrichtung umkehren, können wir nicht mehr der zweiten Aufgabe in unserem Kriterienkatalog gerecht werden und enden dann meist in einem ziemlichen Chaos (undefinierter/unbekannter Zustand). Am besten schreiben wir in Zukunft die Rahmenbedingungen gleich in den Kriterienkatalog mit. Ich habe die Herausforderung von Bahnland angenommen und werde euch jetzt im Folgenden die Funktionsweise meines Lösungsvorschlages erläutern. An dieser Stelle nochmal mein Dank an Bahnland für das nützliche Testlayout. (Fortsetzung folgt in Kürze)

Hallo zusammen, in meinem vorherigen Beitrag habe ich ja davon gesprochen, dass die Anlage nicht ganz perfekt ist, sondern ein Fehler aufweist. Dieser liegt darin, dass immer beim vorderen Triebkopf (der in Richtung Signal zeigt) die Türen auf der falschen Seite öffnen, also genau gegenteilig zum restlichen Zugteil. Das sieht natürlich unschön aus. Die Ursache hierfür liegt in der unterschiedlichen Ausrichtung der jeweiligen Wagen. Bis auf den vorderen Triebkopf (z=0°) sind alle Wagen verkehrt herum (z = 180°) gedreht. Folglich sind die Seiten rechts und links miteinander vertauscht. Wenn ich im Folgenden von der rechten Türseite spreche, meine ich damit die Seite zur längeren Bahnsteigkante. Um diese Unschönheit zu beheben, kann man dem "verkehrt herum gedrehten" Wagen ein Schlagwort wie z.B.: "andere Türseite" zuweisen. Das habe ich beim Triebkopf, der in Richtung Signal zeigt, wie folgt vorgenommen. Nun müssen wir noch in unserem Ereignis "Wenn das KS Hauptsignal schaltet" entscheiden, ob der einzelne Wagon innerhalb der Wiederholung eine andere Türseite aufweist und damit "gedreht" ist. Dazu bedienen wir uns wieder einer Bedingung (gelber Kasten). Wir prüfen an dieser Stelle, ob das Schlagwort "andere Türseite" in irgendeinem Wagon existiert. Wenn es existiert, dann ist der Wagon "falsch herumgedreht". Das heißt, dass wir die linke Seite anstatt der rechten Seite animieren. Wenn die Bedingung nicht erfüllt ist, dann ist der Wagon "normal ausgerichtet", weshalb wir die übliche rechte Türseite animieren. Dasselbe Prinzip müssen wir noch in dem Ereignis "Kontakt 3 wird betreten bei der Einfahrt" anwenden. Ich fragt euch zurecht, warum die Animationen vertauscht wurden. Bedingungen können auch wahr sein, wenn ein bestimmter Fall nicht erfüllt ist, beispielsweiße eine Variable NICHT existiert. Hierbei haben wir die Bedingung negiert/ invertiert. Eine wahre Aussage wird bei einer Negierung unwahr und eine falsche Aussage wahr. Wenn das Schlagwort "andere Türseite" nicht existiert, ist der Wagen "normal" positioniert und die rechte Tür wird geöffnet. Der untere Block wird immer nur ausgeführt, wenn die Bedingung nicht erfüllt wurde. In diesem Fall wird dieser Block nur ausgeführt, wenn das Schlagwort nicht nicht existiert, also letztendlich dann doch. Hierbei haben wir eine doppelte Verneinung, die am Ende wieder wahr ergibt. Also ziemlich verwirrend. Wie immer gibt es von mir ein passendes Anlagenbeispiel dazu. Ich rate jedoch immer dazu, erstmal selbst Lösungsansätze zu finden. Ja das klingt gut. Ich habe die Animation rausgelöscht. Start und Stopp im Bahnhof Testanlage - Version 3.mbp Viel Spaß beim Ausprobieren Liebe Grüße Tim

1. Lösungsvorschlag - Türsteuerung mithilfe von Schlagwörtern Zuerst legt man ein treffendes Schlagwort in einen Wagon des Zugverbunds an. Mithilfe der Icons kopieren und einfügen kann man das Schlagwort bequem in die restlichen Wagons des Zugverbunds einfügen. Wir wollen nun im nächsten Schritt alle Objekte mit dem Schlagwort "ICE mit Türen" ansprechen. Dazu verwendet man die Wiederholung "Für alle Objekte mit einem Schlagwort". Wiederholungen bieten sich immer dann an, wenn eine Aktion auf dieselbe Art und Weise mehr als einmal ausgeführt werden soll, wie in diesem Beispiel. In die grafische EV trägt man in der Wiederholung das Schlagwort und den Namen aller Elemente ein, die später in der Wiederholung angesprochen werden. Aktionen (grüner Kasten) innerhalb von Wiederholungen brauchen immer eine Information über den Auslöser, von wem sie eigentlich angesprochen werden. Bei der Variablen wählt man dann nicht mehr den Auslöser aus, sondern die Wiederholung aus. Das sieht dann wie folgt aus. Bei Objekt steht dann nicht mehr Auslöser, sondern Wiederholung in Klammern dahinter. Der Name der Wiederholung muss mit dem Namen aus dem braunen Kasten übereinstimmen. Sonst gibt es hier Fehler. Dieses Grundprinzip bleibt immer gleich. Anstatt einer Aktion innerhalb einer Wiederholung lassen sich weitere Aktionen und auch Bedingungen einfügen. Das Einzige was innerhalb von Wiederholungen direkt nicht möglich ist, sind zeitliche Verzögerungen. Auf diesen Abbildungen habe ich nur das Abfahren des Zuges mit Türschließen gezeigt. Genauso müsste eine Wiederholung auch beim Schließen der Türen in die grafische EV eingebaut werden. Die Animation mit dem Pantografen verändere ich erstmal nicht, da das jetzt den Rahmen sprengen würde. Anbei füge ich noch eine mbp-Datei dieses Lösungsvorschlages an. Wer genau hinschaut wird einen kleinen Fehler finden, den ich im nächsten Lösungsvorschlag näher beleuchte. Vielleicht hat jemand schon eine Lösung gefunden. Start und Stopp im Bahnhof Testanlage - Version 2.mbp Herzliche Grüße Tim

Hallo liebe Community, oft möchte man Animationen im Zugbetrieb einsetzen, weil es realistischer aussieht. Besonders beindruckend ist sicherlich das gemeinsame Schließen von Türen eines ganzen Zugpaares. Wie man solche teils komplexen Steuerung über die grafische EV löst, möchte ich anhand einer Anlage von @Markus40 zeigen. Viele Wege führen nach Rom. Deswegen werde ich verschiedene Lösungsansätze für ein und dasselbe Problem zeigen, da man so die Abläufe in der EV am besten begreift. In der Anlage befindet sich ein ICE an einem Bahnsteig mit Ausfahrtsignal. Sobald das Signal schaltet, wird die Tür geschlossen und der Pantograf hebt sich. Der ICE setzt sich in Bewegung. Wenn dieser wieder in den Bahnhof einfährt, stoppt dieser und die Tür öffnet sich und der Pantograf senkt sich. Allerdings werden immer nur die Animationen des angetriebenen Triebkopfes gesteuert. Beim anderen Zugteil funktionieren die Animationen noch nicht. Das soll sich jetzt ändern. Im Folgenden werde ich verschiedene Lösungsansätze zeigen, die folgende Aufgabe/ Kriterien erfüllen müssen: Alle Türen des gesamten Zuges (ICEs) sollen sich schließen und öffnen lassen. Die Türen müssen auf der richtigen Bahnsteigseite öffnen und schließen. Wagons ohne Türanimation sollten keine Fehler in der EV verursachen. Viele Grüße Tim

Durchaus gelungen und realistisch bis auf eine Kleinigkeit. Du verwendest die Gleiskontakte schon als Bremskontakte und weist per EV trotzdem beim Betreten dieselbe Bremsgeschwindigkeit zu, die schon in den Bremskontakten eingetragen ist. Du weißt diesen Bremskontakten zweimal dieselbe Geschwindigkeit zu, was unnötig ist. Jeder ICE und überhaupt jedes elektrisch angetriebene Fahrzeug der DB sollte über mindestens einen Pantografen verfügen, da dieser die einzige Verbindung zwischen dem Fahrzeug und der elektrischen Stromversorgung über die Fahrleitung ermöglicht. Früher wurde der Strom über die linke und die rechte Schiene gespeist. Das ist aber brandgefährlich (lebensgefährlich), da Passanten beide Schienenstränge eines Gleises berühren könnten. Deswegen wird der Strom über den Fahrdraht und dem Pantografen zum Triebfahrzeug geleitet und über die Achsen und Schienen fließt er wieder ab. Man sagt auch, dass Fahrzeuge geerdet sein müssen. Durch die Höhe des Fahrdrahts wird sichergestellt, dass niemand in Berührung mit stromführenden Teilen kommen sollte. Die Hamburger Stadtbahnen haben beispielsweiße auch keinen klassischen Fahrdraht. Hierbei wird jedoch eine zusätzliche Stromschiene (3. Schiene) an dem Gleis befestig, die von oben isoliert ist, damit niemand drankommt. Diese Fahrzeuge haben dann statt eines Pantografen einen Schleifer, der an der 3. Scheine anliegt. Ich füge dir noch eine korrigierte Fassung von deiner Anlage ein. Dort funktioniert auch der Pantograf und der ICE fährt auch ab. Start und Stopp im Bahnhof Testanlage - Version 1.mbp Viele Grüße Tim

Hallo @Markus40, ich möchte dir deine 2. Fehler in der EV zeigen, damit du ein Beispiel hast, wie man es richtig umsetzen könnte. 1. Fehler: Du speicherst das Triebfahrzeug (erster Triebkopf an Zugspitze Richtung Signal) im Signal ab, willst aber die Animation mit dem Pantografen abspielen, der aber gar nicht von der EV angesprochen werden kann, weil er zu einem anderen Wagen und nicht um Triebkopf zugehört. Wie du richtig erkannt hast, liegt es an den Animationen, weshalb der Zug nicht losfährt. Du fragst dich, wie man auf den Fehler kommt? Dazu schaltet man die Ereignis-Protokollierung an. Dort siehst du bei [16:43:24], dass das Programm vergeblich nach einer Animation mit dem Namen "50-Pantograf DC" sucht, sie aber nicht im Triebkopf finden kann. Bei der Animation mit den Türen hast du das ja schon richtig hinbekommen. Versuche mal im Signal im Triebfahrzeug eine zusätzliche Variable wie beispielsweise "Trafowagen" anzulegen und über diese die Animation anzusprechen. Ich würde dir aber lieber raten, die besagten Videos von Goetz anzuschauen, oder auf die Animation mit dem Pantografen erst mal zu verzichten. 2. Fehler: Nachdem der Zug das Signal verlassen hat, löscht du den Zug (Triebkopf/ Auslöser) aus dem Signal und schaltest das Signal wieder auf Hp0. Wenn das Signal schaltet, dann verhält es sich so, als ob der ICE wieder vom Bahnsteig abfahren würde, was ja nicht stimmt. Du musst also sicherstellen, dass der ICE nicht angesprochen wird, wenn die Variable "Zug" gelöscht wurde. Darin liegt nämlich der eigentliche Fehler, was du auch an der markierten Fehlermeldung in der EV-Protokollierung erkennen kannst. Die sagt nämlich aus, dass die EV nicht auf den Auslöser/ Triebkopf (local 'v') zurückgreifen kann, weil dieser in der Variablen fehlt. Du kannst das Problem umgehen, indem du überprüfst, ob die Variable leer ist oder nicht. Die gelben Kästchen sind sogenannte Bedingungen. Dabei wird unterschieden, ob ein bestimmtes Merkmal erfüllt ist oder nicht. Dabei gibt es nur zwei Fälle. Entweder ist die Variable vorhanden und existiert oder sie ist leer. Das ist in etwa so wie mit einem Lichtschalter. Dort hast du auch zwei Zustände, nämlich Licht aus und Licht ein. Der obere Bereich vor der grauen Klammer wird immer ausgeführt, wenn die Bedingung erfüllt, also wahr ist. Der untere Bereich unterhalb des grauen Strichs wird nur dann ausgefüllt, wenn die Bedingung nicht erfüllt, also falsch ist. In diesem Fall ist der untere Bereich leer, weil hier nichts ausgeführt werden muss. Ein kleiner Tipp am Rande: Ich finde es gut, dass du dir die Mühe gemacht hast, für die Zugabfahrt eine kleine Demoanlage einzufügen und uns bereitzustellen, denn nur so können wir dir helfen. Versuche immer so wenige Aktionen wie möglich in die EV zu schreiben, weil man dann schnell den Überblick verliert. Du hast jetzt zwar nur zwei Fehler in der Anlage. Bei größeren Anlagen könnte man jedoch schnell den Überblick verlieren und die Fehler nicht mehr klar auseinanderhalten. Fährt der Zug nicht los, weil die Animation mit dem Pantographen nicht gefunden werden kann oder liegt es daran, dass der Zug nicht in der Variable steht und trotzdem angesprochen wird... ? Bei Fragen kannst du die anderen um mich anschreiben (gerne auch per PN). Herzliche Grüße Tim

Hallo nochmal, ich füge hier zwei Konzepte für eine fahrtrichtungsabhängige Spitzen- und Zugschlussbeleuchtung für alle Interessierten ein, die das Auslesen der Kupplungsbelegungen nutzen. Im Grunde genommen führen beide Konzepte zum selben Ergebnis. Es leuchten immer die weißen Spitzenlichter an der vorderen Stirnseite in Fahrrichtung. Am Zugschluss leuchten dann die roten Zugschlusslichter auf. Zwischen den einzelnen Wagons erlischt die Beleuchtung. (genauere Beschreibung als Link: TF-Ausbildung.de - Zg-Signale) Im Konzept A wende ich eine Methode an, bei der alle Wagen der Fahrrichtung nach aufgeschlüsselt werden. Das heißt, dass der erste Wagon in Fahrrichtung auch wirklich an erster Stelle einer Liste und der letzte Wagon in Fahrtrichtung an letzter Stelle in der Liste steht. Dazu musste ich in manchen Sonderfällen die ursprüngliche Wagenreihung umkehren. Anschließend kann ich auf die Reihenfolge der Wagenreihung in dieser Liste zurückgreifen und im Auslöser den ersten und letzten Wagen schreiben und somit dann die Animationen schalten. Das Konzept B nutzt dieselbe Methode wie in der fahrtrichtungsabhängigen Türsteuerung. Beide Konzepte haben ihre Vor- und Nachteile, wobei mir persönlich das Konzept B ein wenig besser gefällt, da der Programmieraufwand geringer ist. Dies kann man beispielsweise daran erkennen, dass in Konzept A erst mühselig unterschieden werden muss, ob der Zugverband aus nur einem oder mehreren Wagen besteht. Konzept A: Spitzen - und Zugschlussbeleuchtung Konzept A.mbp Konzept B: Spitzen - und Zugschlussbeleuchtung Konzept B.mbp Viel Spaß beim Ausprobieren Liebe Grüße Tim

Hallo @prinz, da mich auch das Thema interessiert, habe ich dein Skript etwas modifiziert, um damit eine fahrtrichtungsabhängige Türsteuerung umzusetzen. Auch von meiner Seiten aus. Vielen Dank für das Skript! Das konnte ich echt gut gebrauchen. Diese Variable "zur Lok" erfüllt bei mir einen etwas anderen Zweck, und zwar gibt die Variable die relative Position der Wagen ohne Antrieb zum Auslöser (Lok) wieder. Wenn die vordere Kupplung in dieselbe Richtung wie die vordere Kupplung des Auslösers zeigt, dann besitzt sie denn Wert 0. Andernfalls besitzt sie den Wert 1. Dann zeigen Kupplungen gleichen Typs genau in die entgegengesetzte Richtung. Mithilfe dieses Positionswertes ermittle ich dann im zweiten Schritt eine fiktive Fahrtrichtung. Wenn "zur Lok = 0" gilt, dann entspricht die fiktive Fahrrichtung genau der Fahrrichtung des Auslösers (vorwärts ==> vorwärts). Andernfalls genau umgekehrt (vorwärts ==> rückwärts). Das Skript selbst habe ich mit Funktionen ausgelagert, damit es übersichtlicher ist. Die Funktionen finden sich in der Skript-Datei (<> Skript). Mit dem modifizierten Skript kann man nun dies ermitteln. Oder hat sich das erübrigt? Ich habe die Demoanlage "Kupplungsbelegungen auslesen" mit dem modifizierten Skript unter folgender ID als Entwurf veröffentlicht: 83C32D12-056A-49B1-B20E-D9AE1E6D56DE In meiner Anlage Türsteuerung verwende ich nun die relative Fahrrichtung, um die Türen abhängig von der Ausrichtung und Fahrtrichtung immer an der richtigen Stelle öffnen zu lassen. fahrtrichtungsabhängige Türsteuerung: fahrtrichtungsabhängige Türsteuerung.mbp Viele Grüße Tim

Hallo @EASY, hallo @Neo, was mir natürlich noch gerade aufgefallen ist, dass man die Position einer Animation unter den bisherigen Möglichkeiten nur dann abfragen kann, wenn die Animation stoppt oder startet, also wenn die Endlage eh schon erreicht ist. Die Bü-Steuerung mit Abfrage der Schrankenposition wäre realisierbar, da hierbei nur die Position in den Endlagen überprüft werden soll. Eine Aufzugssteuerung mit Abfrage der Position wäre sinnlos, da es hier Zwischenschritte gibt, es sei denn man fragt bei jedem Animationsschritt die Position ab. Es wäre bestimmt nicht einfach und sinnvoll, ein Ereignis zu definieren, das bei jedem Schritt einer Animation auslöst, weil hier ziemlich viele Meldungen kämen. 1000 Ereignisse (Schrittweite 0,001 bei einer Animation) wären schon ziemlich viel. Von daher müsste man weiterhin das Ereignis Animation gestartet/gestoppt verwenden und einfach die Animation in kleinere Zwischenanimationen aufteilen. Das geht ja schon, da man Animationen teilweise abspielen kann, wie hier verlinkt: Animation teilweise abspielen - Fragen zur Steuerung - 3D-Modellbahn Studio. Was denkt ihr z.B.: @EASY, Bahnland ... über die Art des Ereignisses? (Ereignis "Animation gestartet/gestoppt" weiterbeibehalten oder neues Ereignis "Animationsschritt erfolgt" einführen) Neo hat ja auch schonmal in einem anderen Zusammenhang davon gesprochen, dass man Animationen auch nach ihrem Einsatzweck verwenden kann. Ich kann mich auch total irren. LG Tim

Ja dem kann ich wirklich nur zustimmen. Es wäre wirklich praktisch, wenn man beispielsweise die Position einer Animation als Eigenschaft als Zahl auslesen kann. Denn in meiner Demoanlage zu Bü-Überwachungssignalen, habe ich Schranken verbaut, die animiert sind. Hierbei prüfe ich aus Sicherheitsgründen, ob die Schranken wirklich geschlossen sind, bevor der Zug den Bahnübergang passiert und das Bü-Überwachungssignal dann auf Fahrt geht. Momentan löse ich das über einen Schalter mit 4 Positionen: Schranke geöffnet, Schranke schließen, Schranke geschlossen und Schranke öffnen. Immer wenn die Animation der Schranke startet oder stoppt, schaltet der Schalter um eine weitere Position nach vorne. Dabei gibt es aber ein kleines Problem. Wenn man händisch in die Animation eingreift, das heißt, dass man die Schranke stoppt ehe sie die Endlage erreicht hat, wird der Schalter fälschlicherweise umgeschaltet und der Zustand wird durcheinandergewürfelt. So kann es sein, dass die Schranke noch geöffnet ist, aber schon fälschlicherweise der Zustand "Schranke geschlossen" gemeldet wird, was sicherheitstechnisch nicht so gut wäre. Man könnte dies natürlich auch mit Timern lösen und prüfen, ob die Animation eine genau definierte Zeit für den Ablauf nicht über oder unterschritten hat. Doch das ist meines Erachtens ziemlich kompliziert und hätte andere negative Sideeffects wie der hohe Gebrauch von Timern. Da grundsätzlich nicht zwischen dem Ereignis Animation wird gestartet und dem Ereignis Animation wird gestoppt unterschieden wird hätte solch ein Feature einige Vorteile. a) Steuerungsprozesse werden nicht mehr so fehleranfällig, da Verwechslungen ausgeschlossen sind. b) Timer können entfallen, was möglicherweise die FPS-Rate/Performance nicht so belastet (Bitte korrigieren falls das so nicht stimmt und ich mich irre). c) Präzisere Angaben können gemacht werden auch darüber, ob bestimmte Zwischenschritte einer Animation erreicht sind. Das wäre wirklich eine Bereicherung, aber ich verstehe natürlich auch, dass man Steuerungsprozesse auch so auslegen kann, ohne auf die Position einer Animation zurückgreifen zu müssen. Es ist halt nur nicht so fehlerfrei und etwas komplizierter. LG Tim

Hallo liebe Community, hallo @Achimdampf. Ja, ich habe die EV noch einmal grundlegend überarbeitet, sodass jetzt bei dem anderen mechanischen Bahnübergang nahe dem Bahnhof Eningen immer das Schrankengeläute ertönt, wenn sich die Schranke gerade schließt. Ich hoffe, dass das so passt. Außerdem stoppen jetzt die Autos vorbildgerecht am Bahnübergang und die Signale kommen erst auf Fahrt, wenn der Bü vollständig geräumt ist. Die Fahrstraße von Gleis 2 wird nicht automatisch aktiviert. Das ist extra so gewollt, da man den Bü auch manuell über zwei Taster öffnen und schließen kann. Die sonstigen Fahrstraßen über die jeweiligen Bahnübergänge werden jedoch automatisch aktiviert. LG Tim

Hallo zusammen, ich möchte euch mit einer kleinen Demoanlage die Funktionsweise von Bü-Überwachungssignalen zeigen, nachdem ich das Modell als Entwurf veröffentlich habe und in diesem Post: Tims Modellbau 2022 - Modelle vorgestellt habe. Diese dienen nämlich zur Absicherung von Bahnübergängen und hoffentlich kommt es dann nicht mehr zu so vielen Crashs an Bahnübergängen im 3D-Modellbaustudio. Das Überwachungssignal zeigt den Signalbegriff Bü0 (Lampe aus), wenn der Bü nicht gesichert ist und Bü1 (Lampe blinkt), wenn er erfolgreich gesichert wurde, das heißt, dass alle Schranken unten sind. Die Demoanlage ist zweigleisig ausgeführt und besitzt 4 Überwachungssignale für jede Richtung. Wenn die Züge ihre Runde drehen könnt ihr mal beobachten, was genau passiert. Wenn einer der Bü-Ankündigungstafeln betreten wird, schließt sich der Bü. Nach einer gewissen Zeit sind die Schranken geschlossen und es wird eine Freimeldung abgegeben. (Dazu kann das Dialogfenster zu Ereignisprotokollierung geöffnet werden) Auf den Strecken, wo sich ein Zug befindet, blinkt das Überwachungssignal nach der Freimeldung, weil zuvor die Züge ihre Fahrstraßen anagefordert haben. Wenn einer der Bü-Ausschaltkontakte verlassen wurde, werden die Schranken wieder geöffnet aber auch nur dann, wenn die Anzahl der Züge im Streckenabschnitt gleich Null ist. ID der Demoanlage (als Entwurf veröffentlicht): 292268BD-61A8-47C4-95F3-6BE4E13B1773 Die Anlage dient als Anstoß für weitere Umsetzungen. So könnte man beispielsweise die Freimeldeprüfung auf den Straßenverkehr erweitern. Das heißt, dass der Bü erst als gesichert gilt, wenn sich kein Auto mehr auf dem Bahnübergang befindet. Die Prüfung könnte man über 2 Fahrstraßen lösen und prüfen, ob die Fahrstraßen frei sind und aktiviert werden können. Vielleicht ist das etwas für unsere EV/Lua-Experten. LG Tim

Hallo liebe Modellbahncommunity, in der Zwischenzeit habe ich ein neues Modell fertiggestellt. Es handelt sich hierbei um ein sogenanntes Bü-Überwachungssignal, das ich schon immer bauen wollte. Bü Überwachungssignale dienen dazu, einen Bahnübergang signaltechnisch abzusichern. Das Modell besitzt zwei Signalstellungen Bü0 (Lampe aus) --> Bü ist nicht gesichert Bü1 (Lampe blinkt) --> Bü ist gesichert einen Gleiskontakt und eine Animation zum Öffnen/Schließen des Schaltschrankes auf der Rückseite. Ich habe das Modell als Entwurf unter folgender ID veröffentlicht: 52DF19AE-027E-4243-ACF4-84B125CE90F5 und würde mich über Kritik und Verbesserungswünsche freuen. Um euch einen Eindruck zu geben, was ein Bü-Überwachungssignal überhaupt ist und wofür es verwendet wird, habe ich eine kleine Demo-Anlage entworfen. (Hier findet ihr den Link zu dem Beitrag: Anlagen Demoanlage - Bahnübergang mit Überwachungssignalen) LG Tim

Hallo liebe 3D-Community, das Modell "Bü-Ankündigungstafel" steht jetzt offiziell im Onlinekatalog unter Infrastruktur > Bahnverkehr > Signale > Schilder zur Verfügung. An der Content-ID ändert sich nichts: B2AAC5BD-4338-45BC-99D9-11DCF2E88092. Ich stelle hier eine Tauschtextursammlung aus mehreren einzelnen Tauschtexturen für dieses Modell zusammen, bei denen der Kilometerstand unterschiedlich ist. So kann jeder auf eine kleine Auswahl zurückgreifen. Tauschtextursammlung: Tauschtextursammlung_Bü-Ankündigungstafel_Version_1.zip Vielen Dank Neo für die Freigabe des Modells! Viel Spaß beim Ausprobieren wünscht Tim LG

Hallo Roter Brummer, Tolles Modell! Vor allem finde ich klasse, dass man das Dach abnehmen kann, um einfacher Personen in den Zug zu setzen. Wenn man von Unterseite aus schaut (Ameisenperspektive ) erkennt man an einer Kante des Wagenkastens einen gelb flackernden Streifen. Möglicherweise sind da 2 Flächen direkt übereinander. Herzliche Grüße Tim

Hallo Max, auch von mir ein dickes Lob! Das Modell ist so detailreich, sogar mit animierter Antriebswelle, Schläuchen, etc.! Mir sind nur 2 klitzekleine Fehler aufgefallen, die den Führerstand betreffen. 1. Ein möglicher Texturierungsfehler an den Sitzstützen an einem Sitz in Richtung hinterer Lokteil. 2. Auf einer Seite der Lok zeigen die Flächen der weißen Verkleidung noch in die falsche Richtung. Liebe Grüße Tim