$_Trigger2._Name im Einsatz

[Andy]

Hallo,
ich habe nochmal ein Beispiel für den EInsatz des Zaubertricks von BahnLand gemacht, dass nicht im Dschungel der problembehandelnden EV-Threads untergeht.
Es zeigt, wie der Kniff einfach für Geschwindigkeitssteuerungen eingesetzt werden kann. Sowohl direkt, als auch ein bißchen komplizierter, indirekt.
Wichtig ist es, in den Bedingungen immer zu fragen, ob die entsprechende Bezeichnung vorhanden ist. Dabei "variable hat den wert" _Trigger2.bezeichnung mit Leereintrag negiert verwenden - das funktioniert so wunderbar! Im Beispiel wird sogar unterschieden, ob es echter Wert ist, oder eine weitere Objektbezeichnung.

Das blaue Gleis hat in seinen Objektvariablen die Variable 'Tempo' mit dem Wert 40 drin. Für die beiden anderen farbigen Gleise gilt:

Ist keine Konstante drin, dann muß es eine Objektbezeichnung sein. Offensichtlich gilt eine einfache Variable nicht als Objekt, deshalb müssen wir etwas Greifbares nehmen, und das sind einfach die beiden Beschriftungen. Die Beschriftung 'Tempo30' ist mit dem Wert "Tempo" 30 gefüttert, die mit 'Tempo100' mit "Tempo" 99. Man kann sie entweder direkt in den Objektvariablen der Beschriftung ändern, oder (sogar einfacher) in der EV-Variablenliste. Die Verwendung macht Sinn, wenn man später den Wert an allen eingesetzten Stellen gleichzeitig ändern möchte.

Der Zugriff auf die Daten ist etwas kryptisch - aber wer sich den Abschnitt über indirekte Variablen in der Wiki mal anschaut, sieht, dass dies noch harmlos ist

Grüße Andy

Tempodemo.mbp

Bearbeitet 18. Oktober 2018 von Andy

[Andy]

Und hier noch der tolle zweite Vorteil des Tricks.
In der EV von eben waren genau zwei Ereignisse drin, und keines bedarf eines real existierenden Objekts.
Damit kann man sie in einen Ordner packen und als mbp-Datei speichern, die nun einfach als Komponente in eine bestehende Anlage eingefügt werden kann.
Es gibt keine Bodenplatte und nichts. Die EV-Ereignisse fügen sich als Ordner direkt ein und voila - schon sind die Dinge verwendbar.

Grüße Andy

EV_Tempokontrolle.mbp

p.s.: so habe ich mir eine EV in einer V5 gewünscht. BahnLand hat's heute schon möglich gemacht. Neo kann relaxen.

Bearbeitet 18. Oktober 2018 von Andy
p.s.

[Andy]

Aller guten Dinge sind drei.

Hier sind drei Kippschalter, die jeweils mit einer Weiche verbunden sind.
ABER: sie sind nicht über die Funktion 'verbinden mit' mit der Weiche verbunden.
Alle drei besitzen eine Objektvariable "Weiche", in der der Name der jeweiligen Weiche steht.
Warum der Umstand, wenn's doch direkt ginge?
Nun, es könnten logische Zustände eintreten, die besagen: Jetzt wird nicht geschaltet.

Jede Weiche besitzt noch eine Objektvariable "gesperrt", und die ist bei der dritten Weiche 1 im Gegensatz zu den beiden anderen, wo der Wert 0 ist.
Deshalb schaltet diese Weiche nicht!

Und JA, es ist nur ein einziges Ereignis programmiert, obwohl es drei Schalter sind - denn:  @BahnLand und @fzonk mit $_Trigger1._Name funktioniert das Wunder auch. Zumindest bei Schaltern!

So - jetzt fliegen in meiner Anlage die nächsten paar Hundert Zeilen raus.
Grüße
  Andy

schalterdemo.mbp

[Neo]

Hallo Andy,

vor 19 Stunden schrieb Andy:

so habe ich mir eine EV in einer V5 gewünscht. BahnLand hat's heute schon möglich gemacht. Neo kann relaxen.

für V5 sind solche "globalen" Ereignisse fest eingeplant, dann natürlich ohne solche Umwege, über eine explizite Konfiguration und für jeden Ereignistypen. Wie schon im anderen Thread erwähnt gibt es bei den globalen Ereignissen aber die Warnung, dass hier Performanceprobleme auftreten können, speziell bei "Ein Zug betritt ein Gleis", da so ein Ereignis dann für jeden Zug und jedes Gleis aufgerufen wird. In V5 wird es dafür Lösungen geben, z.B. durch Zuteilung von "Klassen" zu Objekten, um Ereignisse nicht an ein konkretes Objekt, sondern an alle Objekte einer bestimmten Klasse zu binden. Relaxen ist daher leider nicht angesagt, es gibt noch viel zu tun

Viele Grüße,

Neo

[Andy]

Hallo Neo,
ich bin aber schon froh, dass Du nicht sagst, dass wir von dem Dreh die Finger lassen sollen. Ist klar mit den möglichen Performanceproblemen.
Ich gehe mal volles Risiko und stelle meine ganze Anlage darauf um, da ist ja einiges drin, und wir werden sehen, wann es eng wird.
Wenn sie dann kollabiert, habe ich ja noch die Hoffnung, dass sie später mal wiederbelebt werden kann.
Wahrscheinlich ist die neue Version schon sehr weit gediehen, zumindest in der Planung. Wenn's irgendwie möglich ist, schau mal, ob Arrays mit Indizes unterzubringen sind.

Ich bin per PN mit Leuten in Kontakt, denen die jetzige EV bereits Ängste und Magenschmerzen bereitet. Es ist eine Riesenherausforderung hier den Spagat zwischen Unbedarften und Spezialisten hinzubekommen. Zumal auch die Wünsche der Unerfahrenen komplex werden. Was, das geht? Will ich auch. Und: Moment mal, das muß aber dann so.

Die Antwort darauf muß hier im Forum liegen, aber hier wird geholfen. Da bin ich total zuversichtlich. Der Schlüssel zu allem ist aber letztlich die Neugier - die Frage, wie geht das. Und Brummi's Philosophie: was nicht geht, wird passend gemacht. Ich starte inzwischen ja auch schon den Blender durch.

Grüße
  Andy

[h.w.stein-info]

Hallo Andy

Volles Risiko muss du nicht eingehen .

Speichere die Anlage doch nochmal ab unter einen anderen Namen ( zb " Anlage_1 " ) .

Dann hast Du noch die Anlage im jetzigen Zustand , zumindest mache ich das so , wenn es brenzlich werden sollte .

Andy reizt die EV aus - 

Viele Grüße

HnS

[Andy]

Hallo Hans,

oh ja, die alte Version! Klar gibt's die noch. Aber Du glaubst nicht, wie fehlerfindend das neue System ist - der nächste Vorteil! Und ich habe nicht parallel dazu die Fehler in der alten Version herausgeholt - dumdidum. Die Neue ist zum Glück stabil, aber es ist immer noch Optimierungspotential da. Dummerweise belegt die alte Version jetzt immer noch die Content-ID, sodaß ich die Neue nicht hochladen kann, ohne euch wieder mit einer neuen ID zu nerven. Und ich muß ja die jetzige Stabile auch wieder sichern. Sie wird bald als Arbeitsversion im normalen Katalog erscheinen. Dann sind wir das Theater los. Aber ich muß noch auf die Freigabe meiner beiden kleinen Elemente warten. Hoffentlich sieht sie Neo nicht als nutzlos an. Aber es wäre ja ein Wunder, wenn die ersten 'Produkte' glatt durchgehen. Also, abwarten.

Ein Zwischenfazit: normale Variablen sind nun ein ziemlich untaugliches Element geworden, da sie sich absolut nicht mit der neuen Methode behandeln lassen. Man muß sie zu einem Objekt machen. Einfache Logkvariablen, die nur 0 oder 1 tragen können, macht man dann z.B. am besten zu einem Schalter (die Rückkehr der Relais ). Der sollte aber am besten gar kein Polygon haben, damit er Performance und Speicher nicht belastet. Mal sehen, vielleicht muß ich da einen Dummyschalter basteln.

Grüße Andy

[Andy]

Hallo,

ich habe hier noch ein weiteres Beispiel. Ich wollte wissen, was passiert, wenn mehrere $_Trigger-Ereignisse gleichzeitig auftreten. Werden sie alle behandelt? Oder gibt es Ausfälle?
Das Beispiel zeigt, dass bei der Abarbeitung dieses Kommandotyps offensichtlich alle gültigen Instanzen erzeugt werden. Das bedeutet, aus dem einen $_Trigger1-Ereignis, dass bei mir in der EV steht, werden tatsächlich drei, denn alle Signale werden gleichzeitig geöffnet, wenn der Kippschalter betätigt wird. Die drei Signale haben in den Objektvariablen die Namen der drei Lampen gespeichert. Das 'SIGNAL' in den Objektvariablen ist einer Art Klassenidentifikation der Signale, die in der Bedingung abgefragt wird und hiermit hoffentlich etwas Performance sichert. Obwohl keine eine Lampe eine direkte Verbindung zu einem Signal besitzt, werden alle gleichzeitig geschaltet.

Und jetzt noch etwas sehr Wichtiges! Da, wie gezeigt, mehrere Ereignisse aus dem Einen generiert werden, dürfen die $_TriggerN._Name - Kommandos auf keinen Fall einen Countdown im Aktionsteil haben. Das würde im Chaos enden!

Gruß
  Andy

3Signale.mbp

Bearbeitet 24. Oktober 2018 von Andy

[fzonk]

Hallo @Andy und alle Anderen,

wie ich sehe beschäftigst du dich immer noch sehr intensiv mit der „TriggerX_Name“ Funktion. Auch ich habe noch ein wenig weiter experimentiert und habe dabei festgestellt dass man sehr wohl auch einen Countdown mit einarbeiten kann. Dieser hat ebenfalls keinen festen Namen und generiert sich aus der Funktion.

Ich habe ein kleines Beispiel angehangen. In diesem soll der Countdown eine Anfahrverzögerung bewirken, nach dem ein Signal auf Fahrt (Hp1 oder Hp2) geschalten wird.

In diesem Beispiel ist die Steuerung in den Signalen mit Hilfe von Objektvariablen hinterlegt. In dem entsprechenden Signal ist als Bezug das jeweilige Gleis und im jeweiligen Gleis das entsprechende Signal hinterlegt. Des Weiteren ist in den Signalen der jeweilige Signaltyp hinterlegt (HS = Hauptsignal; VS = Vorsignal) da die EV nur Stellung 0; 1; 2; 3 und so weiter auslesen kann und ein Hauptsignal in Stellung 0 (Halt) etwas anderes bewirkt als bei einem Vorsignal (Stellung 0 = Halt erwartet = langsame Fahrt).

In der EV ist die gewünschte Geschwindigkeit für die jeweilige Signalstellung hinterlegt und wird mit dem betreten des jeweiligen Gleises an die Lok weiter gegeben. Wenn die Lok an einem Signal halten muss (Hp0), gibt erst das Freischalten des Signales (Hp1 oder Hp2) mit einer Verzögerung von 3 Sekunden den Fahrbefehl an die Lok.

Ein Haken hat die ganze Sache, schaut man in die EV während ein Countdown läuft und schließt diese mit „OK“ ist der Countdown verschwunden und es passiert nichts. Geht man auf „Abbrechen“ läuft er weiter und führt die gewünschte Aktion aus. Vielleicht kann @Neo näheres zu diesem Phänomen sagen und was man gegen dieses Auftreten machen kann.

Gruß Frank

Trigger mit Countdown.mbp