Jump to content

Empfohlene Beiträge

Geschrieben
vor 24 Minuten schrieb Roter Brummer:

was passiert ..., wenn ... zwei Züge exakt gleichzeitig den Haltekontakt berühren?

Dann treffen trotzdem beide Ereignisse nacheinander ein. Also werden auch beide Ereignisse nacheinander ausgewertet.
Sonst könnte das 3D-Modellbahn Studio nicht funktionieren, denn wie du im Protokoll gut beobachten kannst, besteht der ganze Betrieb auf einer Anlage aus einer Unzahl von Ereignissen. Ganz unabhängig davon, ob du dich mit Hilfe der Ereignisverwaltung an ausgewählte Ereignisse dran hängst oder nicht. Das Studio muss also alle Ereignisse auswerten. Auch dann, wenn sie exakt zur selben Zeit eintreffen. 

Geschrieben

Hallo zusammen,

es geht in diesem Beispiel nicht um den kleinen Schmalspurbahnhof in Modulbauweise, sondern um die Verladung von Holz auf die Güterwagen.

1132842982_Experimente14.thumb.jpg.9f412ac48e3c10d74d3b0912c1c28302.jpg

Meine eigene Vorgabe war, dass mit nur einem Schalter als Auslöser (roter Taster) sowohl der komplette Durchlauf für das Beladen und auch das Entladen angestoßen werden kann. Dabei stören mich in der EV zwei Dinge:

  1. Ich brauche zwei Ereignisse, um die komplette Kette durch zu spielen. Einmal muss der Durchlauf gestartet und im zweiten Ereignis zum Ende geführt werden.
  2. Mir erscheint die EV als viel zu komplex. Ich habe aber keine andere Möglichkeit gefunden, alle nötigen Bedingungen einfließen zu lassen.

Sieht jemand eine Möglichkeit, die EV auf der grafischen Ebene radikal zu verschlanken? Vielleicht bin ich da ja auch inzwischen Betriebsblind.

HG
Brummi

Holzverladung.mbp

Geschrieben

Hi Brummi

Mit einem Kran brauchst Du immer 2 Ereignisse.
Eins zum Starten und eins für den Kran.

Komplexität kann man nur mit Variablen in den Objekten verringern (Ladung, Abstellfläche u.s.w.).

Gruß
Thomas

Geschrieben

Hallo Brummi,

hier ist mein Beispiel für den Einsatz von Listen zur Vereinfachung der EV.

B4D3D746-B3DD-4F2B-BA39-13440912B88E

Ich habe die Variation als Versuch hochgeladen, damit ich die Anlage verbessern kann, wenn mir neue Ideen kommen.
Diese Version benötigt sogar drei Ereignisse. Aber zwei der drei Ereignisse ändern nur eine Variable. Das dritte Ereignis erledigt die ganze Arbeit.

Man möchte auf zwei Dinge reagieren können:

  1. auf die Betätigung des Schalters
  2. auf die Beendigung eines Beladungsschrittes

Dafür sind alleine schon zwei Ereignisse unabdingbar notwendig. (Eigentlich muss man richtig sagen: Ich will auf zwei unterschiedliche Ereignisse reagieren und deshalb muss ich für beide Ereignisse Aktionslisten schreiben.) Und weil beide Ereignisse dieselbe Aktion anstoßen sollen ist es sinnvoll, diese eigentliche Aktionsliste einem dritten Ereignis zuzuweisen, welches von den beiden anderen Ereignissen getriggert werden kann. Ein Benutzerdefiniertes Ereignis wäre eine Möglichkeit. Aber da ein Zähler beteiligt ist, scheint mir die Änderung einer Variablen das bessere Ereignis für den Zweck.

Geschrieben
vor 2 Minuten schrieb Roter Brummer:

Mir ist noch nicht ganz klar, wie die Listen abgearbeitet werden

Die Listen enthalten die Zieladressen für die Kranaktion. Also Holzstapel 1, Ladefläche 2, Abstellplatz 3 etc.
Diese Elemente sind mit 1 beginnend fortlaufend durchnummeriert.

Wenn der Zähler auf 3 steht, dann kann ich dem Kran sagen:
Bewege dich zur Adresse 3 in Liste "Aufladen". Das wäre dann der Holzstapel 2

Listen.thumb.jpg.d6f98158bc253b2ea82fd1d16f58a11e.jpg

Geschrieben (bearbeitet)

Moin

Sehr schön, genau so hab ich es mit meinem Containerkran auch gemacht, nur daß die Liste immer wieder neu geschrieben wird, wenn ein neuer/anderer Zug einfährt.
Und wenn die Ladung neben dem Gleis übereinander gestapelt wird, dann muß man sich die besetzten Plätze noch in Variablen merken.
Die Ladung auf dem Zug kann man sich in Variablen der Waggons merken, um sie später wieder in die Liste einzutragen.
Den ganzen Zug geht man dann mit der Wiederholenfunktion durch, um die Liste zu erzeugen.

Gruß
Thomas

Bearbeitet von HaNNoveraNer
Geschrieben (bearbeitet)

Hallo hier ist der kutscher, ich finde das nicht be miri fehlen aus historischen, koreander + Mini experimente.

Was nun fragt kutscher

Bearbeitet von kutscher
Geschrieben

Blocksignal universal

Hallo zusammen,

es sind wohl ein paar Haare noch grauer geworden, aber jetzt habe ich endlich das universell einsetzbare Signal zusammen geschustert.

Es ist egal, ob das Triebfahrzeug vorwärts oder rückwärts fährt und ebenso ist es egal, an welcher Stelle das angetriebene Fahrzeug im Zugverband eingereiht ist. Der Zug hält immer korrekt mit der Zugspitze am geschlossenen Signal, fährt bei offenem Signal mit der eingetragenen Streckengeschwindigkeit durch und beschleunigt bei sich öffnendem Signal auf die eingetragene Streckengeschwindigkeit.

Das Signal kann auch als normales Ein- oder Ausfahrtsignal benutzt werden.

In den Variablen des Signals kann die Streckengeschwindigkeit geändert werden. Bei der Verwendung als Blocksignal muss das Objekt des zurückliegenden Blocksignals ausgewählt werden, weil die Blockfreigabe sonst nicht funktioniert.

1268362756_Experimente15.thumb.JPG.f56dfeffd2e99c991c79284fb6279104.JPG

Die Ereignisverwaltung hat vier Einträge.

im ersten Ereignis wird der Objektname des angetriebenen Fahrzeugs abgefragt. Alle Geschwindigkeitsänderungen beziehen sich dann auf diese Lokadresse. Sollte der Zug vor dem geschlossenen Signal bereits den Bremsvorgang eingeleitet und sich das Signal inzwischen wieder geöffnet haben, nähert er sich vorbildgerecht mit reduzierter Geschwindigkeit dem Signal und beschleunigt ab diesem wieder auf die in den Variablen eingestellte Streckengeschwindigkeit.

905284216_Experimente16.thumb.JPG.4d6731340b56b4c2d9e50b886fd976aa.JPG

Das zweite Ereignis regelt die Zustände der Bremsverzögerung und startet einen am geschlossenen Signal stehenden Zug am sich öffnenden Signal. Auch hier beschleunigt der Zug dann auf die vorher eingestellte Streckengeschwindigkeit.

2024961095_Experimente17.thumb.JPG.6e270ee143452e26bc6b7f44f88fc82d.JPG

Im dritten Ereignis wird lediglich das Signal nach passieren der halben Zuglänge auf Hp0 gestellt.

2067085584_Experimente18.thumb.JPG.1bddcfa27176a1d6902c7b3aff0b5e98.JPG

Im letzten Ereignis wird der zurückliegende Block dann für den nächsten Zug freigegeben.

2113412159_Experimente19.thumb.JPG.ab29d4a0e6f77049fbb8ffd9c21fe166.JPG

Das ist das entsprechende Signal:

Blocksignal universal.mbp

Der Einbau ist sehr einfach durch "Importieren aus Anlage" möglich. Damit man die Signale nachher unterscheiden kann, empfiehlt es sich, ihnen eindeutige Namen zu geben. Ebenso empfehle ich, die Ereignismodule entsprechend um zu benennen. In den Ereignissen selber muss nichts geändert werden.

Die einzige Schwierigkeit besteht eventuell darin, in den Variablen jedes einzelnen Signals das richtige Objekt als zurückliegendes Blocksignal auszuwählen. :D

Viel Spaß beim experimentieren und fahrt auch mal rückwärts oder mit schiebender Lok. :D

HG
Brummi

Geschrieben (bearbeitet)

Hi Brummi

Irgendwas stimmt mit der Geschwindigkeitssteuerung nicht:

test.mbp

Sieht so aus, als wenn er zuerst die Geschwindigkeit der Vorgängerlok setzt und dann erst den neuen Loknamen übernimmt, wenn eine Lok zum
Bremsen ansetzt.

 

Gruß
Thomas

Bearbeitet von HaNNoveraNer
Geschrieben

Hallo Brummi,

gibt es einen Grund, warum du nicht mit Schlagwörtern für das Signal arbeitest? Durch die direkte Angabe des Signals im Ereignis müssen für jedes Signal die Ereignisse neu importiert werden, obwohl der Ablauf dann immer gleich ist.

Viele Grüße,

Neo

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen.

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...