Goetz

Hallo Michel, Das liegt eventuell daran, dass das Schlüsselwort selbst der Name der Variablen ist und "keyword" ihr Inhalt. Deshalb findest du kein generisches "keyword", welches du übergeben könntest. Für die Übergabe ist daher sinnvoller, eine generische Variable anzulegen und dort dein Keyword als Text zu speichern. Alternativ kannst du die ganze "Variables" Liste durchforsten und dann den Bezeichner der Zelle zurückgeben, die ein "keyword" enthält. Aber das scheint mir zu sehr "brute force" zu sein. @HaNNoveraNerhat inzwischen perfekt zusammen gefasst, was ich hier umständlich beschreibe. Ich schicke es mal trotzdem ab - als Ergänzung zu seinem Hinweis. Viele Grüße Götz

Du kannst nicht im selben Zyklus ein Ziel zuweisen und gleich im Anschluss auslesen, Hawkeye. Lua gibt nur den Befehl. Die Ausführung macht das Studio anschließend. Lua wartet aber mit der nächsten Zeile nicht, bis das Studio den vorherigen Befehl ausgeführt hat. Es liest einfach weiter den verfügbaren (unveränderten) Datensatz und gibt weiter Befehle aus. Ich bin mir nicht sicher, aber ich vermute den Fehler an dieser Stelle. Denn dein Fehler besagt ja, dass im Fahrzeug kein Ziel gefunden wurde. Dass du versuchst auf ein Objekt zuzugreifen, welches nicht existiert. Viele Grüße Götz

That may be your translator playing tricks on you, Doug I don't see that spelling anywhere in his example

Exakt das möchte Brummi erreichen, Timba. Weil er im Glauben ist, dass ein Vorsignal früher als das Hauptsignal auf Halt fällt. Es sieht aber so aus, als ob im Gegenteil dein Ansatz der richtige ist. Die Gleichschaltung von Vor- und Hauptsignal. Das heißt dann: Koppeln und nicht einbinden. So oder so darf man nur eins von beidem tun. Viele Grüße Götz

Und hier die Antwort eines aktiven Lokführers (mit wachsendem Interesse am Studio!)

genau so hatte ich bisher auch gedacht.

Dann wäre es in der Tat richtig, das Vorsignal wie gehabt in die Fahrstraße einzubinden und nicht mit dem Hauptsignal zu koppeln. Ich frage da mal befreundete Lokführer und Fahrdienstleiter, wie die Dinger sich tatsächlich verhalten.

Weil es am Ende der Fahrstraße sitzt. Das letzte Signal markiert immer nur das Ende und wird niemals durch die Fahrstraße gestellt. Egal, welcher Signaltyp es ist. Aber Zwischensignale müssen mit der Fahrstraße gestellt werden. Mit Ausnahme der Vorsignale. Ergänzung: Aber du hast eigentlich recht. Wahrscheinlich werden Fahrstraßen seltener über mehrere Hauptsignale gehen und häufiger Vorsignale zwischen Start und Ziel haben. Eventuell ist "nichts unternehmen" die bessere Grundstellung für alle außer dem vordersten Signal. Oder man prüft, ob ein Signal mit einem anderen verkoppelt ist. Das wäre auch ein Argument für "nichts unternehmen". Erfordert aber, dass man immer das Vorsignal ans Hauptsignal koppelt und nicht umgekehrt.

Ja, das wäre hilfreich. Aber für diesen Standard müsste das Studio ein Vorsignal von anderen unterscheiden können. Ich weiß nicht, ob die Modelle eine entsprechende Information enthalten.

Hallo Timba, Aber du kannst in der Fahrstraße für dieses Vorsignal "nichts unternehmen" einstellen. Sowohl für die Aktivierung, als auch für die Deaktivierung der Fahrstraße. Dann ist es ohne Einfluss. Viele Grüße Götz Fahrstraßentest geänderte Vorsignal Einstellungen.mbp

no need to apologise, Pete You're doing fine, keep it up

Exzellente Idee, Wolfgang. Daran hatte ich nicht gedacht.

Ohne deine Schaltung und die zugehörige Anlage zu sehen? Nein, tut mir leid. Soviel Weitblick habe ich leider nicht. Ich habe aber den Verdacht, dass es nicht die DR 130 ist, welche das Signal auf Halt schaltet. Sondern ein anderes Ereignis an anderer Stelle.

Hallo Jürgen, die einfachste Lösung ist, du startest die Animation 3 Mal hintereinander. Dazwischen musst du jeweils eine Verzögerung setzen, die so lang ist, wie ein Durchlauf dauert. So erreichst du, dass die zweite Animation erst dann startet, wenn die erste zu Ende ist. Diese Verzögerung findest du unter Aktion -> Zeitsteuerung -> Verzögerung Die Verzögerung im Bild ist mit 60 Sekunden etwas zu lang. Ich hatte grob geschätzt, wie lange ein Umlauf dauert und dann als erstes diesen Wert ausprobiert, der ganz sicher genug Zeit lässt. Von da aus kann man sich jetzt rantasten und die Dauer finden, welche sich gut eignet. Viele Grüße Götz

Brilliant, Pete! That's the way to do it. And I'm happy to help you with this every step of the way.

Hallo Matt, für die Wahl des Maßstabs macht es keinen Unterschied, ob du V5 oder die aktuelle V7 nutzt. Da sind keine Bugs drin. Wenn du mit V7 eine neue Anlage beginnst, dann wirst du deutlicher als zuvor gebeten, dich für einen Maßstab zu entscheiden. Und der Grund dafür ist das, was dir jetzt passiert ist: Dass User gelegentlich unbeabsichtigt verschiedene Maßstäbe vermischt haben. Aber ansonsten arbeiten alle Versionen nach demselben Prinzip und du kannst in jeder Version auch nachträglich den Maßstab ändern, wenn du zu Beginn den falschen gewählt hattest. Viele Grüße Götz

That's indeed a much better principle, Herman

Hello Doug, Then allow me, please ... In the following example, the steam train has a marginally longer round and runs at a speed 1 km/h slower than the railcar. This causes the time gap between the two to increase slightly each round. For two rounds, the barriers stay closed between the railcar leaving and steam train entering. On the third round, the barriers open after the railcar. And this time they stay open long enough for a few cars to pass through. They close again just in time before the steam train crosses. level crossing example.mbp The actual closing happens very late in this example. The barriers reach the down position at the very moment when the train arrives. This is deliberate to help you understand what's happening when and why. I find this a very useful principle. That's why I'm so eager to demonstrate it. Greets Goetz

Hello Herman, When the bus enters the depot, it's the front of the bus that counts. But when it leaves, the rear of that bus is placed at the depot's door. So ... in and out ain't the same. This makes a bus journey from end to end shorter than a car journey. Also: When the bus exits, while two cars enter on the other side in quick succession, one of the two triggers may get lost. I can't tell you for sure the precise sequence of events that leads to a lost command. I didn't take the time to observe with the required scrutiny. But you can. Start a screen recorder. Make sure the event protocol is recorded with the action. And go through the film frame by frame afterwards to find the exact condition where the number of cars on the road changes. Kind regards Goetz

Not, if you separate the counter contact from the close contact (with a good stretch of track between the two). Trust me, Doug. I've done this before. With the studio. With EEP. But you're correct in saying that skipping back to the starting position looks worse than a reversal of direction midway. I simply prefer a mechanism where neither ever happens. And if it can't happen, you may as well start from the top.

The "send from depot" command is only executed when there is sufficient room on front of the depot. The bus, which is longer than other cars, upsets your pattern. Occasionally it causes "send from depot" commands to be skipped.

it's a gem, innit? So very clever

Yes, Doug. But that is a different matter altogether. And a barrier that half opens and immediately closes again looks only marginally better. To avoid this and have a proper, clean operation where the barriers only open between trains when at least a few cars can slip through, you need to separate the counter contact from the closing contact. A train must announce it's approach a fair time earlier before it triggers the lowering of the barriers. By doing so, it ensures closed barriers staying down while risen barriers stay open a little longer.

for @Dad3353, @220hotwheels, @simonjackson1964 and anyone who loves the British outlook on life: One of my all time favourite British TV films is the chain from Granada TV. Beginning at 28:50, it has a short section concerning computers that I find hilarious. Make sure you watch the next 7 minutes until 35:30 to get the full story. I hope you enjoy this as much as I do Goetz

Hi Pete, that's not what you should be striving for. Instead, you should work on gaining a better understanding. Here's an example from your current attempt: The outer condition checks if the variable has a value greater than 1. And when that is not the case, the inner loop checks if it is greater than 0. When both conditions (not > 1, but > 0) are met, the barriers are closed. If the value of Test Barrier 1.trains crossing is not greater than 1, but greater than 0, what is it's value, considering it's always a whole number? And when you close the barriers, it's also time to set the deceleration value to 0. Only then! The afore mentioned aspects are only cosmetic. The behaviour is correct. When it comes to opening the barriers however, matters are a little more serious. You once had a smart system, where you first raised the barriers and then, after a short time delay, set the cars in motion. Now you shuffled that order of events to where it no longer makes any sense. Yyou are making progress. But it's very difficult for me to decide if your understanding improves or if you're just following orders ... Greets Goetz No, Doug, they don't! Because his code only lowers the barriers for the first train.