Standardisierte Automatiksteuerung - Fragen an die Experten

[ostenfstr]

Hallo liebe Fan-Gemeinde,

 

nach geraumer Zeit habe ich wieder vor, eine neue Anlage mit dem MBS zu bauen.

Beim Einlesen und Ausprobieren der neuen Funktionalitäten kam mir spontan der Gedanke, ob es jetzt wohl möglich sei, eine Automatiksteuerung (hauptsächlich Streckenblock- und Bahnhofsfunktionalitäten) so zu modularisieren, dass man z.B. einen kompletten Streckenblock so erstellen kann, dass die zugehörige EV mit der Änderung eines einzigen Ereignisses (welches dann Blockdefinitions-Variablen setzt) in beliebiger Anzahl auf die eigene Anlage gezogen werden kann.

Ich habe die grundlegenden Mechanismen dafür weitestgehend ausprobiert, hätte aber dazu einige Fragen, die das Forum vielleicht beantworten könnte:

1. In den Versions-updates steht "Die Animations/Countdownbedingungen und -Aktionen unterstützen nun ebenfalls Variablen (beginnend mit $)". In meinem Fall stolperte ich darüber, dass wohl das Starten eines Countdowns über einen variablen Counter ausgelöst werden kann, nicht jedoch die Abfrage auf einen abgelaufenen Counter. Hat das einen tieferen Sinn?

2. Um so eine EV aufzubauen, die diese Struktur aufweist (Ereignis: Variablen Block A setzen / standardisierte Ereignisgruppe Streckenblock / Ereignis: Variablen Block B setzen / standardisierte Ereignisgruppe Streckenblock / Ereignis: Variablen Bahnhof C setzen / standardisierte Ereignisgruppe Durchgangsbahnhof / usw.) müsste man bei jedem Durchlauf der EV die zugehörigen Variablen setzen. In der EV muss ich aber immer ein auslösendes Ereignis haben.

Die bisherige Lösung ist die Erhöhung einer Variablen, wenn diese Variable geändert wurde. Gibt es eine Möglichkeit, auf elegante Weise die ERSTE Änderung auszulösen?

3. Bahnland beschreibt in dem Automatisierungs-Wiki (großes Lob für den Artikel) im Abschnitt über Lock-Variablen:

"Leider ist der hier beschriebene Mechanismus "Lockvariable auf 0 prüfen und dann auf eigenen Wert setzen" nicht "atomar". D.h. die Aktionsfolge "Lesen + Bewerten + Schreiben" kann nicht als "eine Operation" realisiert werden, während deren Bearbeitung konkurrierende Lese- und Schreib-Operationen unterbunden werden. "

Wird die EV nicht sequentiell abgearbeitet, so dass jeder Schritt davon ausgehen kann, dass der vorhergehende Schritt abgeschlossen ist und er sofort auf die Ergebnisse der vorhergehenden Aktionen zugreifen kann? Dann wäre doch eine Lock-Variable in dem Moment geändert, in dem sie gesetzt würde. Könnte tatsächlich eine nachfolgende Instanz einen alten Wert sehen, obwohl dieser schon geändert ist?

 

Es scheint vielleicht für das Gesamtergebnis ein zu hoher Aufwand zu sein, den ich hier betreibe. Aber für mich hat so eine Standardisierung einige gravierende Vorteile. So ließe sich z.B. bei einer Gleisverzweigung oder -zusammenführung eine Round-Robin-Funktion entwickeln, die dann durch einfachen Austausch der Steuerblöcke auf eine Anlage auch im Nachhinein innerhalb von Minuten implementiert werden kann. Weiterhin verliere ich keine Automatisierungsereignisse, wenn ich beim Umbau mal ein Gleis ändere oder eine andere Weiche benutze, weil die EV nicht mehr direkt auf die Objekte zugreift, sondern eine Referenz über Namen herstellt.

 

Es wäre nett, wenn jemand zu den Fragen einige Antworten hätte.

Gruß

Ostenfstr

[BahnLand]

Hallo Ostenfstr,

Zitat

Wird die EV nicht sequentiell abgearbeitet, so dass jeder Schritt davon ausgehen kann, dass der vorhergehende Schritt abgeschlossen ist und er sofort auf die Ergebnisse der vorhergehenden Aktionen zugreifen kann? Dann wäre doch eine Lock-Variable in dem Moment geändert, in dem sie gesetzt würde. Könnte tatsächlich eine nachfolgende Instanz einen alten Wert sehen, obwohl dieser schon geändert ist?

So viel ich weiß, ist das Modellbahn-Studio Multiprozessor-fähig. Dies würde aber bedeuten, dass - wenn nicht explizit auf denselben Prozessor "gezwungen" - zwei Abläufe "bedingtes Setzen einer Ereignis-Variable" parallel abgearbeitet werden können. Würden sich hierbei die beiden gleichzeitigen Abläufe auf dieselbe Variable beziehen, wäre es mit der "sequentiellen Abarbeitung" (und damit der Wirksamkeit des Locks) vorbei. 

Viele Grüße
BahnLand

[Neo]

Hallo Ostenfstr,

zu 1: Einen tieferen Sinn gibt es nicht, bisher ist das noch nicht vorgesehen, dass man Countdowns per Variable ansprechen kann. Für welchen Fall genau benötigst du das?

zu 2: Hier verstehe ich die Frage/das Problem nicht.

zu 3: Alle Aktionen werden in der Ereignisverwaltung garantiert hintereinander und in der angegebenen Reihenfolge abgearbeitet. Das Studio nutzt zwar mehrere Prozessoren, aber nicht für die Ereignisverwaltung.

Viele Grüße,

Neo

[EASY]

Hallo Ostenfstr, Hallo Neo

... wenn ich es richtig interpretiere (kann mich allerdings auch irren) soll hier das aufgebaut werden, was man in der Steuerungstechnik als so etwas wie eine "offene Prozesskette" bezeichnen würde.

"Offen" deshalb, da es nicht direkt an bestimmte Objekte (z.B. Gleise, Rollmaterial) "gebunden" sein soll, sondern indirekt durch gewisse Objekteigenschaften (z.B. zugewiesene Variablen).

Zitat

Gibt es eine Möglichkeit, auf elegante Weise die ERSTE Änderung auszulösen?

... ist (wie in jedem Prozess) immer eine schwierige Frage... da letztendlich die Frage der definierten Anfangsbedingung, um den Prozess anzustoßen (wenn es mal läuft, dann läuft es...)

Auf den ersten Blick, wäre die eleganteste Lösung also so etwas wie ein "Autostart" beim Laden (oder besser gesagt, wenn das Projekt vollständig geladen ist...)

Da es auf der einen Seite den "Autostart" über die EV nicht gibt und Du Dir auf der anderen Seite ein offenes System vorstellst (bei dem es natürlich eine große Anzahl an möglichen Anfangsbedingungen gibt), läßt sich Deine Frage so nicht pauschal beantworten. Eine Möglichkeit besteht darin z.B. daß am Anfang schon etwas läuft (z.B. ein Zug), der dieses Anfangsereignis auslöst... wäre aber eine projektbezogene Lösung.

... so wird Dich meine Antwort wahrscheinlich nicht ganz glücklich machen...

... mit Neo über einen Autostart verhandeln...

... und sich in der Zwischenzeit mit einem Schalter "Start" o.ä. zu behelfen (kann man ja auch noch versuchen "nett" zu verstecken)... funktioniert immer.... unabhängig davon, wie es weitergeht...

Gruß

EASY

 

 

[BahnLand]

Hallo Neo und Ostenfstr,

dass die komplette Ereignisverwaltung immer auf demselben Prozessor abläuft und damit eine Aktion nicht während der Bearbeitung von einer anderen Aktion überholt werden kann, vereinfacht die Lock-Bearbeitung erheblich und macht sie auch sicher. Die Lock-Anforderung und Freigabe reduziert sich somit die Abfolge

1. Lockvariable auf den "eigenen Wert" setzen, wenn die Zusatzbedingung "Lockvariable hat den Wert 0" erfüllt ist
2. Nachträglicher Test:
   Lockvariable besitzt nun den "eigenen" Wert: Lock wurde erfolgreich zugeteilt - weiter mit Punkt 5
3. Lockvariable besitzt nicht den eigenen Wert: Lock ist anderweitig belegt - warten, bis Lock durch aktuellen Besitzer des Locks wieder freigegeben wird
   Hierzu kann man das Ereignis "Lockvariable wird auf "0" gesetzt definieren, wodurch die Freigabe des Locks durch den haltenden Konkurrenten signalisiert wird.
4. "Lockvariable auf 0 gesetzt" erkannt: Erneuten Versuch, beginnend mit Punkt 1, starten.
5. Lock erfolgreich gesetzt. Durch den Lock geschützte Aktionen können nun ausgeführt werden, ohne dass ein möglicher Konkurrent "dazwischen funkt".
6. Freigabe des Locks nach Abschluss der geschützten Aktionen durch Setzen der Lockvariable auf "0".

Bei dieser Abfolge der Lock-Anforderung fehlt gegenüber der Beschreibung im Wiki die Wartezeit vor dem Test nach dem "bedingten" Setzen des Locks, um mögliche "Überholer" bei der Lock-Anforderung zu erkennen. Diese Wartezeit ist nun nicht mehr notwendig, aber auch nicht schädlich (verlängert nur die gehaltene Lockstrecke den Sekundenbruchteil der Wartezeit). Durch die Garantie, dass sämtliche Lockbearbeitungs-Mechanismen der Ereignisverwaltung auf demselben Prozessor abgewickelt werden, ist dieser Lock-Mechanismus auch "sicher". D.h. es kann nicht durch ein spezielles Zeitverhalten dazu kommen, dass der Lock versehentlich gleichzeitig durch mehrere Instanzen gehalten wird.

Viele Grüße
BahnLand

[ostenfstr]

Hallo Bahnland, Neo, EASY,

Ich muss schon sagen ... Ich bin schwer beeindruckt ...

Kaum stellt man hier im Forum eine Frage, schon wird man innerhalb kürzester Zeit mit technisch präzisen Kommentaren geradezu bombardiert

Vielen Dank euch allen!

 

Ich versuche mal strukturiert zu antworten:

Zu 1 "Abfrage Countdown über Variable":

@Neo: Mein Problem ist, dass ein abzufragender Countdown während der Programmierung praktisch noch gar nicht real exisiert, da nirgendwo ein Startereignis existiert. Da ihn das MBS nicht kennt, taucht er auch nicht in der Auswahlliste auf. Ich werde mal alle Countdowns als Dummy definieren und sehen, ob ich die dann auswählen kann. Ich würde mich wieder melden, wenn ich hier überhaupt nicht weiterkomme.

Zu 2 "ständiges Ereignis":

@Neo: eine (oder mehrere) Aktion(en), die bei JEDEM Durchlauf durch die EV IMMER ausgeführt werden.

@EASY: Vielen Dank. Dann benutze ich zunächst mal meine Zählvariable und starte die mit einem Schalter. Mal sehn, ob sich das bei Fortschritt des Projektes überhaupt als störend herausstellt.

Zu 3 "Mehrere Instanzen können gleichzeitig eine Variable abfragen"

@Neo: Das ist klar und deutlich. Danke.

@Bahnland: Danke, das werde ich so mal umsetzen.

 

Ich werde jetzt mal mit diesen Informationen in Ruhe eine Teststrecke aufbauen und sie dann mal zur Kommentierung einstellen.

 

Nochmals vielen Dank für eure Mühe

ostenfstr

 

[ostenfstr]

Hallo liebe Fan-Gemeinde,

 

Wie angekündigt, habe ich mal einen Entwurf kreiert, der mir schon ewig im Kopf rumgeistert, der aber bei der Umsetzung auf Variablen einige Probleme bereitet...

Zur Erklärung: Ich habe die Block-Steuerung von BAHNLAND aus dem WIKI mal testweise für zwei zweigleisige Kopfbahnhöfe modifiziert (siehe Datei 1: Langanlage Check 1). Bitte ignoriert für die Erklärung meines Problems alle ausgeblendeten Gruppen. Betätigt man den Hauptschalter am GBS, so fahren die beiden Züge in munterem Wechselspiel hin und her. So weit so gut ...

EDIT: BITTE AB HIER NUR DEN TEXT LESEN UND NICHT MIT DEM BEISPIEL BESCHÄFTIGEN ... EINE DETAILIERTERE PROBLEMBESCHREIBUNG HABE ICH IM NÄCHSTEN BEITRAG EINGESTELLT.

Im Beispiel 2 (Langanlage Check 2) habe ich versucht, im Bahnhof A (Gleise A1 und A2) die Signale (#SigA1B und #SigA2B) durch Variablen zu ersetzen. Die Idee ist folgende: Vor der Abarbeitung einer EV-Gruppe werden die zu dieser Gruppe gehörenden Variablen gesetzt (in diesem Fall: %Signal = #SigA1B oder %Signal = #SigA2B). Anschließend kann dann ein identisch definiertes Ereignis das jeweilige Ausfahrtsignal mit "$%Signal" abfragen.

Der folgende Effekt tritt aber leider bei dieser Form der Abfrage ein (dargestellt rechts oberhalb vom GBS) ein:

Die Variable "%Signal" wird offensichtlich korrekt gesetzt (erkennbar an der Beschriftung im angegebenen Bereich). Die nachfolgende Aktion, welche den Zustand von "$%Signal" als Bedingung abfragt, scheint aber den Variablenwert aus dem VORHERGEHENDEN Zyklus abzufragen, d.h. die Bedingung "wenn '$%Signal' = 0 dann Setze Beschriftung=Zu" in der Abarbeitung von Gleis A1 den Signalzustand von Signal #SigA2B darstellt.

Ich gebe zu, das klingt ein wenig kompliziert, aber ich hoffe, dass die versierten Mitglieder verstehen, was ich meine.

Ich habe ein ähnliches Problem bei der Lok-Geschwindigkeits-Ereignisgruppe beobachtet. Auch dort hat die EV bei Bedingungs-Definitionen den letzten Wert aus dem VORHERGEHENDEN Zyklus eingesetzt.

Außerdem habe ich festgestellt (darum die aufwändige Darstellung links über dem GBS), dass BERECHNUNGEN mit Variablen eben NICHT (wie NEO angegeben hat) ihr Ergebnis den folgenden Ereignissen im gleichen Zyklus zur Verfügung stellen (testweise den Counter Sekunde+0,2 mal mit 0 starten). Bei der Routine, die die Lokgeschwindigkeit setzt ist der Wert "GeschwNeu+15"  NICHT direkt in einer Bedingung zu verwenden.

Bin ich hier auf einen Bug gestoßen, oder habe ich in der Programmierung der EV etwas grundsätzlich verkehrt gemacht?

@Bahnland: Ich denke, dass dieser Effekt dazu geführt hat, dass Du die "Zwischencounter" benutzt, weil die Aktionen nicht "atomar" sind. Meiner Meinung nach sollte man sich jedoch auf die korrekte Abarbeitung absolut verlassen können. Sonst arten größere Automatisierungs-Projekte in unendlicher Versuchsarbeit aus, oder?

Ich hoffe, jemand durchblickt meine Erläuterungen  und bin schon jetzt gespannt auf eure Kommentare.

Es grüßt

Ostenfstr

Langanlage_check_1.zip

Langanlage_check_2.zip

[ostenfstr]

Hallo liebe Fan-Gemeinde,

das Problem mit den variablen Objekten ließ mir keine Ruhe und ich habe mal eine kleine Testdemo erstellt, die das Problem weiter einkreist.

Ist wahrscheinlich etwas übersichtlicher als eine ganze Anlage zu durchforsten

Der Effekt ist reproduzierbar ... sobald einer Variablen, die zur Objekt-Referenzierung dient, innerhalb der EV neu gesetzt wird, benutzt der GESAMTE EV-Zyklus den ZULETZT zugewiesenen Wert. Dieses gilt sowohl für EREIGNISSE, wie auch für BEDINGUNGEN, nicht jedoch für AKTIONEN. Aktionen werden immer mit dem korrekten Objekt durchgeführt. Auch hat die Variable zu jedem Zeitpunkt den korrekten Wert.

Dieses Verhalten ist doch nicht gewollt, oder?

Es grüßt der Tüftler

Ostenfstr

Test_mit_variablen.zip