Anlagen-Bausteine mit vorgefertigter Ereignissteuerung (Diskussionsforum)

[Timba]

vor 8 Stunden schrieb Goetz:

Diese Kopie wird mit dem Inhalt der temporären Liste "namen" befüllt, aber nicht das Original. Damit versickert FzListe bzw. FzTabelle im Lua Code und wird an niemanden im MBS weitergereicht. Du erkennst das daran, dass das Ereignis "Objekt Variable wird gesetzt" nicht getriggert wird.

Hallo Götz,

mal eine Frage, die nur am Rande das hier behandelte Problem berührt. Arbeiten die Tabellenbefehle "table.insert" und "table.remove" in meinen Scripts auch nur mit Kopien? Im Ereignisprotokoll werden diese Änderungen ja nicht angezeigt. Und falls ja, zu welchem Zeitpunkt findet eine Synchronisation statt, denn letztlich steht ja in der Originaltabelle am Ende alles so wie es soll.

Gruß Timba

[Goetz]

vor 51 Minuten schrieb Timba:

Arbeiten die Tabellenbefehle "table.insert" und "table.remove" in meinen Scripts auch nur mit Kopien?

Die Befehle selbst erzeugen keine neuen Kopien.

Bei Bahnland ist die Tabelle, die er als Ziel für table.insert angegeben hat, eine Kopie.
Ob das bei dir ebenso der Fall ist muss ich mir anschauen.

Und synchronisiert wird per se gar nichts. Weder in Lua, noch in anderen Sprachen.
Entweder verbirgt sich hinter zwei Namen dieselbe Adresse oder nicht.

Die Sache ist deshalb ein wenig "tricky", weil man genau hinschauen muss, wo was übergeben wird.

In Lua läuft es so ab:

Liste_1 = {"John", "Paul", "George", "Ringo"}
Liste_2 = Liste_1               -- Kopie oder Weitergabe der Adresse?

s = table.concat(Liste_2, "\n") -- alle Texte der Tabelle in einen String
print("Liste 2\n"..s.."\n")     -- sieht aus wie Liste_1

table.insert(Liste_1, 1, "Stewart")

s = table.concat(Liste_1, "\n") -- alle Texte der Tabelle in einen String
print("Liste 1:\n"..s.."\n")    -- Liste 1 hat einen neuen Namen dazu bekommen

s = table.concat(Liste_2, "\n") -- alle Texte der Tabelle in einen String
print("Liste 2:\n"..s.."\n")    -- Liste 2 ebenfalls, weil nur die Adresse übergeben wurde. Es ist dieselbe Tabelle!

-- Das heißt: umgekehrt wirkt sich eine Änderung in Liste_2 auch auf Liste_1 aus.
table.insert(Liste_2, 1, "The Beatles")

s = table.concat(Liste_1, "\n") -- alle Texte der Tabelle in einen String
print("Liste 1:\n"..s.."\n")    -- Liste 1 hat einen neuen Namen dazu bekommen

 

Selbst dann, wenn man eine globale Tabelle als Funktionsargument übergibt, bleibt es dieselbe Adresse:

Liste_1 = {"John", "Paul", "George", "Ringo"}

function Test(Liste_2)
    table.insert(Liste_2, 1, "The Beatles")
    local s = table.concat(Liste_2, "\n")
    print("Liste 2:\n"..s.."\n")
end

Test(Liste_1)
s = table.concat(Liste_1, "\n")
print("Liste 1:\n"..s.."\n")

 

In diesem Punkt ist Lua wirklich eigenartig. Eine Variable wäre als Funktionsargument lokal definiert. Sie könnte sogar den selben Namen haben, wie die globale Variable und würde dennoch nichts mit ihr zu tun haben. Eine lokale Änderung hätte keine globale Auswirkung. Aber bei der Tabelle wird nur die Adresse an den lokalen Träger übergeben. Und die weist auf dieselbe Tabelle.

 

Aber in der EV von MBS passiert mehr als nur Lua. Die Übergabe von einem Ort (Objekt, Modul etc.) zum anderen wird nicht von Lua erledigt. Sonst gäbe es keine adressierbaren Objekte. Die kennt Lua nämlich so nicht. Dahinter steckt Neos Cleverness!

Und bei der Übergabe einer Tabelle in der EV wird diese Tabelle kopiert. Deshalb ist es ratsam, nur das Objekt zu übergeben, welches die Tabelle beherbergt. Denn wenn ich das Objekt (und die darin enthaltene Tabelle) anspreche, dann ist es das Original.

Bearbeitet 1. Dezember 2019 von Goetz

[BahnLand]

Eigene Protokoll-Ausgaben im Ereignisprotokoll ganz einfach selbstgestrickt

Hallo zusammen,

wenn man in einer Ereignissteuerung einen Fehler oder ein unerwartetes Verhalten diagnostizieren möchte, sind zusätzlich bewusst eingestreute Protokollausgaben meist sehr hilfreich. Ich möchte hier zwei kleine Bespiele zeigen, wie man solche Protokollausgaben mit minimalem Aufwand selbst produzueren kann:
 

1. Beispiel
Man definiere in der Ereignisverwaltung ein Benutzerdefiniertes Ereignis und füge diesem ein paar Parameter vom Typ "Text" hinzu.

Es brauchen keine Inhalte (Bedingungen, Aktionen, ...) hinzugefügt zu werden.

In den Ereignisdefinitonen, wo Protokollzeilen ausgegeben werden sollen, fügt man nun Aufrufe dieses "leeren" Ereignisses hinzu.

Entsprechend der Anzahl eingerichteter Parameter in der Ereignisdefinition "Print" stehen nun beim Aufruf diese Parameter zum Ausfüllen zur Verfügung. Man kann auch Parameter leer lassen. Dann wird einfach der Leerstring "" hergenommen.

Man kann als Parameter aber auch Referenzen auf Objekte hinterlegen und beispielsweise deren Bezeichnungen ausgeben lassen. Dort werden dann im Ereignisprotokoll die (Bezeichungen der) tatsächlichen Objekte ausgegeben.

Leider sticht die Ausgabe im Protokoll nicht "besonders" hervor, weil es sich "nur" um die Protokollierung eines aufgetretenen Ereignisses (unter vielen) handelt. Dennoch kann man die zusätzlivchen Protkollausgaben am Namen der hierfür verwendeten Ereignisdefinitoon (hier "Print") erkennen.
 

2. Beispiel
Dieses untescheidet sich vom 1. Beipiel nur dadurch, dass man der Ereignisdefinition "Print" eine Zeile "Lua-Code" verpasst:

Das "print"-Statement bekommt genau jene Parameter verpasst, die das Print-Ereignis "nach außen" anbietet. Die Aufrufe aus den obigen Bildern bleiben unverändert. Doch die print-Anweisung in der Lua-Ereignisdefinition gibt nun zusätzlich die im Ereignis-Aufruf übergebenen Parameterwerte in grüner Schrift aus, welche hier deutlicher hervortritt. Nachteilig wirkt sich hier allerdings aus, dass das Protokoll der Ereignis-Auslösung trotzdem noch ausgegeben wird, sodass jetzt jeder "Print"-Aufruf zu einer doppelten Ausgabe führt.

Frage an @Neo:
Wäre es eventuell möglich, so etwas Ähnliches etwa in einer solchen Form ...

... direkt in der Ereignisverwaltung anzubieten, wobei dann tatsächlich nur die Ausgabe selbst (ohne Ereignisbezeichnung) im Ereignisprotikoll (in einer auffälligen Farbe) ausgegeben wird? Am einfachsten wäre es natürlich, wie beim "Kommentar" etwas in das Lua-Script einzufügen (nämlich die im vorletzten Bild gezeigte Hintereinander-Reihung der Parameter in der Lua-print-Anweisung anstelle des Kommentartextes in der Form "--text" oder "--[[ text --]] , ohne die "Trace"-Überschrift zu protokollieren).

Viele Grüße
BahnLand

 

 

Bearbeitet 4. Dezember 2019 von BahnLand

[BahnLand]

Hallo,

der hier angekündigte Anlagenbaustein "Ablaufberg" ist nun fertig und unter der Content-ID B9B9CF7A-4616-4350-B2E0-6EA3BD8A3429 im Online-Katalog zu finden. Als Anwendungsbeispiel habe die alte Anlage "Ablaufberg" aus V4 aktualisiert (Content-ID BF1E3582-32E9-4074-AE25-5F55DED16C28), die nach der automatischen Übernahme nach V5 nicht mehr funktioniert hat. In Ihr sind nun neben dem fertigen Anlagen-Baustein für den Ablaufberg auch die Bausteine "Signalhalt" und "Bahnhofshalt 2-seitig" eingefügt. Diese wurden aber für den Ablaufberg-Betrieb etwas modifiziert. Die Beschreibung des Anlagenbausteins "Ablaufberg" befindet sich hier.

Im Gegensatz zur Ablaufberg-Anlage in V4 brauchen nun die Wagen der zu zerlegenden Güterzüge nicht mehr mit Nummern bezeichnet zu sein. Sobald sich ein Güterzug der Kuppe des Ablaufbergs nähert, wird über ein Lua-Script die Liste aller im Güterzug enthaltenen Güterwagen-Objekte bestimmt, die dann an der Kuppe zur Identifizierung des abzukuppelnden Wagens herangezogen wird. Da die abzufragende Liste die Wagen-Objekte direkt enthält, können diese nun beliebige Namen besitzen, die nicht einmal eindeutig sein müssen. Dies ist übrigens das einzige im Anlagenbaustein direkt implementierte Lua-cript, alle anderen Ereignisdefinitionen sind wie in den anderen bisherigen Anlagen-Bausteinen auch über die grafische EV realisiert.

Eine einzuhaltende Namensvorgabe gibt es allerdings bei den Entkuppler-Fahrzeugen: Diese müssen alle "Entkuppler" heißen, da deren Identifizierung als Entkuppkler-Fahrzeuge über diesen Namen erfolgt (anstelle der Abfrage einer sonst notwendigen Typ-Zuweisung). Dies ist für den Anwender jedoch nur dann relevant, wenn der bereits vorhandene Pool von Entkuppler-Fahrzeugen vergrößert werden soll.
 

Noch ein Hinweis an @Neo:

Aufgrund der Aufteilung der Ereignissteuerung in 3 Funktionsgruppen (Ereignismodule) gibt es in der Hauptebene keine Ereignisdefinition. Damit gibt es hier aber auch keine Möglichkeit, eine Beschreibung hinzuzufügen.

Dies ist erst möglich, wenn mindestens eine Ereignisdefinition hinzugefügt wurde. Ich habe daher ein "leeres" Dummy-Ereignis vom Typ "benutzerdefiniert" hinzugefügt, das keinen Inhalt besitzt. Ich würde es aber für "sauberer" erachten, wenn die Übersticht im Fenster rechts mit der Möglichkeit, eine Beschreibung hinzuzufügen, auch dann angezeigt würde, wenn das oberste Ereignismodul selbst nur eingebettete Ereignismodule, aber keine direkten Ereignisdefinitionen enthält.

Viele Grüße
BahnLand

[BahnLand]

Hallo zusammen,

auch wenn @Neo aufgrund unserer gemeinsamen Bemühungen für eine komfortable Konvoi-Steuerung hier für V6 die schon lange ersehnte komfortable Unterstützung des Konvoi-Problems angekündigt hat, wollte ich doch meine schon begonnenen Lösungsansätze ohne V6 zu Ende bringen und hier vergleichend vorstellen. Es hat jetzt nun doch noch ein paar Tage gedauert, da ja bekanntlich der Teufel im Detail steckt. Doch nun hier die von mir betrachteten jeweils mit mindestens einem Makel behafteten Lösungs- oder Kompromiss-Varianten im direkten Vergleich.

Ich habe für jede Variante einen Anlagenbaustein gebaut, den man in vorhandene Anlagen einfügen (importieren) und dort mehrmals duplizieren und individuell anpassen kann, ohne jeweils die enthaltene Ereignissteuerung mit duplizieren zu müssen. Da ich mir aufgrund der Ankündigung von @Neo nicht sicher bin, ob ich die Bausteine jetzt wirklich noch im Online-Katalog (Kategorie "Module zum Einbauen") veröffentlichen soll, möchte ich sie zumindest hier als mbp-Dateien zur Verfügung stellen. Außerdem gibt es für jeden Baustein eine kleine Demo-Anlage.

1. Einfache Konvoi-Steuerung mit einer die Fahrzeuge blockierenden Fahrsperre.

Baustein Autokonvoi 1.mbp

Demo Autokonvoi 1.mbp

Der Baustein besteht aus einer (schaltbaren) Fahrsperre (dunkler Fahrbahnbelag), einem normalen Straßenstück als "Abstandhalter" (heller Fahrbahnbelag), einem Gleiskontakt zum Entsperren der Fahrsperre, einem Stopp-Taster und einem Dummy-Fahrzeug (halbtransparent grün). Befindet sich auf dem hellen Straßenstück ein Fahrzeug, wird das nächste an der Fahrsperre eintreffende Fahrzeug durch "festklemmen" zwangsgestoppt, ohne dass dabei die zugeordnete Ist-Geschwindigkeit verloren geht. Auch auf dieses Fahrzeug auffahrende weitere Fahrzeuge behalten dadurch ihre zugeordnete Ist-Geschwindigkeit bei.

Verlässt ein Fahrzeug das helle Straßenstück und damit den "Entsperr-Kontakt", wird ein an der Fahrsperre festgeklemmtes Fahrzeug "losgelassen", worauf dieses und alle nachfolgenden aufgefahrenen Fahrzeuge ihre Fahrt mit der Ist-Geschwindigkeit fortsetzen. Da diese Ist-Geschwindigkeiten der Fahrzeuge bei diesem Szenario zu keinem Zeitpunkt verändert werden, gibt es auch kein "Abbremsen" oder "Beschleunigen". Die Fahrt wird als "ruckartig" gestoppt und fortgesetzt. Der rote Taster ist Platzhalter für eine Ampel, eine Bahnschranke oder ein anderes Steuer-Objekt, mit welchem der Konvoi an der Stelle, wo dieser Baustein im Straßenverlauf platziert wird, angehalten werden soll.

Wird ein Fahrzeug an der Fahrsperre "festgeklemmt", kommt es in Abhängigkeit von seiner Länge mit einer unterschiedlichen Überlappung an der Einfahrt zur Fahrsperre zum Stehen. Bei sehr langen Fahrzeugen (z.B. einen langen Bus) kann es daher passieren, dass ein davor befindliches Fahrzeug weitergeschoben wird, und damit die Ereignissteuerung negativ beeinflusst. Außerdem wird das Fahrzeug beim "Festklemmen" etwas nach hinten versetzt, sodass sich das Fahrzeug in ein möglicherweise aufgefahrenes Fahrzeug hinein schiebt. Dies ergibt dann insbesondere bei zusammengesetzten Fahrzeugen (z.B. Gliederbus oder Sattelzug) ein sehr unschönes Erscheinungsbild. Deshalb wird bei dieser Variante jedem Fahrzeug oder Fahrzeuggespann ein "Dummy-Fahrzeug" mit einheitlich kurzer Länge vorangestellt, das anstelle der Originalfahrzeuge den "Antrieb" als "Zugmaschine" übernimmt. Das versehentliche Weiterschieben vorausfahrender Fahrzeuge wird dadurch verhindert, und das Zurückschieben in das nachfolgende Fahrzeug hinein ist nach dem Ausblenden der Dummy-Fahrzeuge nicht mehr sichtbar.

Außerdem dienen die Dummy-Fahrzeuge hierbei gleichzeitig als "Abstandhalter" zwischen den Fahrzeugen im Konvoi.

Bei aus Straßenstücken mit mehreren Fahrspuren bestehenden Straßenverläufen, kann nicht das Straßenstück mit allen Fahrspuren als schaltbare Fahrsperre ausgeführt werden. Deshalb sind hier beim originalen Straßenstück sämtliche Fahrspuren zu entfernen (oder zu deaktivieren) und bei der zu blockierenden Fahrspur durch den Anlagenbaustein zu ersetzen. Bei dessen Straßenstücken kann als Variation eine bunte Spurlinie ausgewählt werden, wobei für die Fahrsperre und das "normale" Straßenstück unterschiedliche Farben ausgewählt werden können. Für die nicht zu blockierende Fahrspur wird eine Kopie des "normalen" Straßenstücks (ebenfalls als "Spurlinie") eingesetzt und in der Länge angepasst. Darüber kann dann wieder das originale Straßenstück im normalen Straßendesign (das nun keine aktiven Fahrspuren mehr enthält) darüber gelegt werden. Die eingesetzten "Spurlinien" werden abschließend ausgeblendet (im vorletzten Bild die Ebene "Baustein-Fahrspuren").

Durch das Verschieben des Gleiskontakts nach vorne (Vergrößerung des Abstands zur Fahrsperre) kann der Abstand der Fahrzeuge auf der Straßen nach dem Verlassen der Fahrsperre reguliert werden.

2. Konvoi-Steuerung mit weichem Abbremsen auf kurzen Fahrbahn-Abschnitten.

Baustein Autokonvoi 2.mbp

Dieser Baustein besteht aus 3 Fahrbahn-Abschnitten (zur Unterscheidung mit unterschiedlichen Fahrbahnbelägen), einem Stopp-Taster, einem weiteren Taster zur Umschaltung der Ereignissteuerung zwischen Initialisierungs- und Betriebsmodus sowie einem zur Durchführung der Initialisierung benötigten Dummy-Fahrzeug. Die Konfiguration aus den 3 Straßenabschnitten repräsentiert die von der Ereignissteuerung kontrollierte "Autokonvoi-Haltestrecke", welche durch Einfügen weiterer Kopien des mittleren Straßenstücks beliebig verlängert werden kann. Ein in das vorderste Straßenstück (im Bild links) von rechts einfahrendes Fahrzeug wird dann abgebremst, wenn der Stopp-Taster "Halt" gebietet. Schaltet dieser auf Grün, wird ein auf diesem Straßenstück stehendes Fahrzeug gestartet. Bei der Einfahrt in eines der Straßenstücke dahinter wird das Fahrzeug dann abgebremst, wenn das Straßenstück davor durch ein vorausfahrendes Fahrzeug belegt ist. Dieses startet das angehaltene nachfolgende Fahrzeug wieder, sobald es das von ihm belegte Straßenstück verlassen hat. Das letzte Straßenstück (rechts) stellt als "Sonderfunktion" bei den eintreffenden Fahrzeuge noch die Geschwindigkeit und Bremsverzögerung so ein, dass das Fahrzeug beim Eintritt in alle weiteren Straßenstücke auf diesem zum Halten gebracht werden kann, ohne versehentlich in das nächste Straßenstück hinein zu gelangen.

Damit von einem Straßenstück aus auf die benachbarten Straßenstücke zugegriffen werden kann, sind diese jeweils gegenseitig miteinander verknüpft. Werden nun zwischen die "Einfahrt" (Straßenstück rechts) und die "Ausfahrt" (Straßenstück links) weitere "mittlere" Straßenstücke eingefügt, muss diese Verkettung neu konfiguriert werden. Hierzu schaltet man mit der "Auto"-Taste die Konfiguration in den Initialisierungsmodus ("Hand") um, platziert das Dummy-Fahrzeug außerhalb der Autokonvoi-Haltestrecke auf der Straße vor der "Einfahrt", und lässt es einmal durch die gesamte Haltestrecke hindurch fahren, bist es am andere Ende die "Ausfahrt" wieder verlassen hat. Danach kann man das Dummy-Fahrzeug wieder von der Straße nehmen und auf den Betriebsmodus zurückschalten. Die Autokonvoi-Haltestrecke ist nun einsatzbereit.

Dieser Baustein funktioniert so aber nur für einspurige Straßenverläufe. Für zweispurige Straßen mit Gegenverkehr hat Frank (@fzonk) in diesem Beitrag eine Lösung präsentiert, die ich entsprechend zu einem Baustein für zweispurige Straßen erweitert habe:

Baustein Autokonvoi 3.mbp

Das Schema ist im Prinzip das Gleiche wie beim Anlagenbaustein "Autokonvoi 2" mit dem Unterschied, dass nun die beiden End-Straßenstücke die Steuerung sowohl für die Einfahrt als auch für die Ausfahrt enthalten und auch das mittlere Straßenstückbeide Fahrtrichtungen unterstützt. Eine Erweiterung dieser Methode auf weitere Fahrspuren in einem Straßenstück oder eine Anwendung auf in der gleichen Fahrtrichtung zu befahrende zweispurige Straßenverläufe ist allerdings nicht möglich.

Demo Autokonvoi 2+3.mbp

Beide Varianten (ein- und zweispurig im Gegenverkehr) habe ich in der obigen Demo-Anlage vereinigt. Bei diesen Konfigurationen ist insbesondere darauf zu achten, dass die Gesamtlänge des angehaltenen Konvois innerhalb der Autokonvoi-Haltestrecke Platz findet. Sobald ein Fahrzeug noch außerhalb der der Haltestrecke auf den hinten hinausragenden stehenden Konvoi auffährt, werden die Fahrzeuge von hinten zusammengeschoben, und die Ereignissteuerung funktioniert nicht mehr, weil die einzelne Fahrzeuge des Konvois nicht mehr auf jenen Straßenabschnitten stehen, auf denen sie in der Ereignissteuerung hinterlegt sind.

3. Mittels Gleiskontakten realisierte Konvoi-Steuerung.

Baustein Autokonvoi 4.mbp

Demo Autokonvoi 4.mbp

Dieser Baustein ist analog zum Anlagenbaustein "Autokonvoi 2" aufgebaut mit dem Unterschied, dass das Erkennen einer Ein- und Ausfahrt aus einem Halteabschnitt nicht über die Straßenstücke, sondern über an den Abschnittsgrenzen angeordnete Gleiskontakte erfolgt. Die Straßenstücke selbst werden von der Ereignissteuerung nicht mehr ausgewertet und dienen hier nur noch als optische Anzeige der Halte-Abschnitte. Auf der Anlage selbst können die Gleiskontakte des Anlagenbausteins deshalb direkt auf den vorhandenen Straßenverlauf aufgelegt, sodass die Straßenstücke des Anlagenbausteins dann überflüssig sind.

Im Gegensatz zur Realisierung mit Straßenstücken werden für die Realisierung mit Gleiskontakten zwei Begrenzer des jeweiligen Halteabschnitts benötigt, wobei die "inneren" Gleiskontakte jeweils für beide angrenzenden Halteabschnitte verwendet werden. Der Ausfahr-Kontakt ganz links ist nur noch für die Freigabe des hinter ihm liegenden Halteblocks zuständig. Alle anderen Gleiskontakte sind jeweils für den in Fahrtrichtig vor ihnen liegenden Halteabschnitt zuständig, wobei der zweite Kontakt von links die Steuerung in Abhängigkeit vom Zustand des Stopp-Tasters durchführt. Bei allen anderen Kontakten bestimmt die Belegung des auf den eigenen Abschnitt folgenden Abschnitt durch ein vorausfahrendes Fahrzeug, on das den Kontakt passierende Fahrzeug abgebremst werden soll oder durchfahren kann. Der letzte Kontakt ganz rechts schließt als Einfahr-Kontakt die Autokonvoi-Haltestrecke ab und nimmt wie das letzte Straßenstück beim "Anagenbaustein Autokonvoi 2" eine eventuell erforderliche Anpassung der Geschwindigkeit und der Bremsverzögerung des einfahrenden Fahrzeugs vor.

Der verbleibende in der Reihenfolge dritte Gleiskontakt (grün) kann zur Verlängerung der Autokonvoi-Haltestrecke beliebig oft kopiert und als weiterer "innerer" Kontakt eingefügt werden. Auch hier muss anschließend im Initialisierungsmodus das Dummy-Fahrzeug durch die komplette Autokonvoi-Haltestrecke gefahren werden, um die Gleiskontakte korrekt miteinander zu verketten.

 

Im Gegensatz zur Realisierung de Konvoi-Steuerung mittels kurzer Straßenstücke ist diese Variante gleichermaßen für ein- und mehrspurige Straßen (auch mit gleicher Fahrtrichtung anwendbar, indem die Konfiguration einfach für jede zu berücksichtigende Fahrspur angelegt wird. Die Problematik der Längenbegrenzung des Konvois ist hier aber genauso vorhanden wie bei der zuvor beschriebenen Variante.

Durch das Vergrößern des Abstands zwischen den ersten beiden Gleiskontakten kann der Abstand der Fahrzeuge auf der nicht kontrollierten Straße nach dem Verlassen der Autokonvoi-Haltestrecke reguliert werden.

4. Rückwärtige Absicherung der Autokonvoi-Haltestrecke durch hinten angefügte Fahrsperren.

Baustein Autokonvoi 5.mbp

Demo Autokonvoi 5.mbp

Hierbei handelt es sich um eine Kombination aus dem Anlagenbaustein "Autokonvoi 4" und mehreren angehängten Ausprägungen des Bausteins "Autokonvoi 1", denen allerdings die Stopp-Taster fehlen. Konkret wurde der Baustein "Autokonvoi 4" um ein Mittelglied verlängert, dessen Gleiskontakt (im Bild weiß dargestellt) gleichzeitig die Funktionalität des Entsperr-Kontakts des vordersten Bausteins "Autokonvoi 1" innehat. Hierbei müssen sich der Streckenabschnitt dieses Bausteins und der letzte Abschnitt des Bausteins "Autokonvoi 4" überlappen, damit letzterer die Funktionalität des entfernten Stopp-Tasters übernehmen kann. Jeder weitere angehängte "Autokonvoi 1"-Abschnitt wird durch die Fahrsperre des Abschnitts, an den er angehängt wurde, sowohl bei der Sperrung (Stopp-Taster-Funktionalität) als auch bei der Entsperrung (Funktion des nun auch fehlenden Entsperr-Kontakts) gesteuert. Eine Verlängerung des Bausteins ist sowohl im vorderen Teil (Duplizierung des grünen Gleiskontakts) als auch im hinteren Teil (Duplizierung der mittleren Fahrsperre einschließlich des davor liegenden "Distanz"-Straßenstücks möglich.  Auch hier ist nach einer Veränderung der Baustein-Länge ein Initialisierungslauf erforderlich, wobei sowohl die Gleiskontakte als auch die Fahrsperren jeweils untereinander verkettet werden.

Im Gegensatz zum originalen Anlagenbaustein "Autokonvoi 1" bei denen die eigentlichen Fahrzeuge nicht selbst fahren, sondern jeweils durch "Längen-normierte" Dummy-Fahrzeuge gezogen werden, sind es hier wieder die originalen Fahrzeuge unterschiedlicher Länge, die von den Fahrsperren "festgeklemmt" werden. Um hierbei ein ungewolltes Anschieben des Vordermanns durch ein "zu spätes Festklemmen" zu vermeiden wurden die Distanzen im Bereich der Fahrsperren" gegenüber jenen im Bereich der Gleiskontakte vergrößert.

Ragt ein am Ende des Gleiskontaktbereich (der klassischen Autokonvoi-Haltestrecke mit "weichem" Abbremsen) angehaltenes Fahrzeug hinten über diesen Abschnitt hinaus, würde ein nachfolgendes Fahrzeug ohne zusätzliche Stopp-Stelle in das letzte Fahrzeug des haltenden Konvois hineinfahren, hierbei die haltenden Konvoi-Fahrzeuge zusammenschieben und dadurch letztendlich chaotische Zustände herstellen, welche die Ereignissteuerung nicht mehr beherrschen und auch nicht mehr reparieren kann. Um dies zu vermeiden, muss es eine Fahrsperre geben, die so weit nach hinten versetzt ist, dass auch das längste auf der Anlage im Einsatz befindliche Fahrzeuggespann (in der vorliegenden Demo ein Schwertransport mit führender und schiebender Zugmaschine) auch beim Halten ganz hinten im Gleiskontaktbereich noch davor Platz findet. Im obigen Bild erfüllt die Fahrsperre unter dem Sattelzug diese Bedingung. Damit bei kürzeren Fahrzeugen die Lücke zwischen dem letzen im Gleiskontaktbereich angehaltenen Fahrzeug und einem durch die Fahrsperre festgeklemmten Folgefahrzeug nicht zu groß wird, gibt es die im Baustein realisierte Folge von Fahrsperren mit kürzeren Abständen. Hinter der letzten Fahrsperre können dann weitere Folgefahrzeuge gefahrlos auffahren, ohne dass hierdurch die Ereignissteuerung störend beeinflusst wird.

Vergleich der Stärken und Makel der einzelnen Konvoi-Lösungen.

Der Baustein "Autokonvoi 1" erlaubt keine weichen Brems- und Anfahrvorgänge. Das Anhalten und Losfahren geschieht grundsätzlich ruckartig. Ferner werden für ein "sauberes" Anhalten an der Fahrsperre und für das Beibehalten von Mindestabständen unsichtbare Dummy-Fahrzeuge benötigt, die allen Fahrzeugen und Fahrzeuggespannen als "Zugmaschinen" vorangestellt werden (den gezogenen Fahrzeugen selbst wird dabei grundsätzlich keine Geschwindigkeit zugeordnet). Der Einbau des Bausteins in größere Straßenverkehrs-Objekte ist dagegen sehr einfach zu handhaben und benötigt mit Ausnahme des Voranstellens der Dummy-Fahrzeuge vor die eigentlichen Fahrzeuge und Fahrzeuggespanne keine besonderen Vorkehrungen. Insbesondere können auch "diffizile" Straßengeometrien mit überschaubarem Aufwand damit ausgestattet werden. Als komplexere Beispiele seien hier die Kreisverkehr-Demo-Anlagen aus diesem Beitrag genannt.

Die Bausteine "Autokonvoi 2", "Autokonvoi 3" und "Autokonvoi 4" erlauben zwar ein weiches Abbremsen und Anfahren, beschränken aber jeweils die Länge des aufgestauten Konvois auf die Länge der Realisierten "Autokonvoi-Haltestrecke". Es muss hierunbedingt vermieden werden, dass der Stau hinten über das Ende der Autokonvoi-Haltestrecke hinaus reicht und dann ein weiteres Fahrzeug hinten auffährt. Tritt dieser Fall tatsächlich auf, versinkt die Konvoi-Steuerung im Chaos. Man muss also garantieren, dass entweder der Stau niemals über das Ende der Haltestrecke hinausragt, oder die gesamte Straßenkonfiguration als Autokonvoi-Haltestrecke einrichten.

Der Baustein "Autokonvoi 5" stellt einen Kompromiss zwischen den Bausteinen "Autokonvoi 4" (stellvertretend für "Autokonvoi 2" und "Autokonvoi 3") und "Autokonvoi 1" dar, indem er diese beide kombiniert. Solange der Stau sich auf den Bereich innerhalb der Autokonvoi-Haltestrecke (den Bereich innerhalb der Gleiskontakte) beschränkt, werden die Fahrzeuge weich abgebremst und auch beim Start wieder langsam beschleunigt. Es ist jedoch möglich, den haltenden Konvoi über den Gleiskontakt-Bereich nach hinten hinaus ragen zu und auch zusätzliche Fahrzeuge von hinten auffahren zu lassen. Diese werden dann aber schlagartig angehalten und auch wieder ruckartig gestartet. Erst mit der Einfahrt i den Gleiskontaktbereich kommen dann auch diese in den Genuss der weichen Abbremsung und Beschleunigung.

Insgesamt muss ich also feststellen, dass ich keine "ultimative" Lösung gefunden habe, und man - unabhängig davon, welche Lösung man wählt - mit einem Makel leben muss. Insofern können alle hier angebotenen Lösungen nur Übergangslösungen bis zur V6 sein, in der dann diese Lösungswege vermutlich alle obsolet werden.

 

Denkansätze für eine mögliche einfache Konvoi-Steuerung mit sanftem Halt und Start.

Bei meinen Versuchen zu den obigen Lösungsansätzen habe ich festgestellt, dass ein Fahrzeug, das auf ein langsamer fahrendes Fahrzeug auffährt, auf dessen Geschwindigkeit abgebremst wird. Beschleunigt nun das vordere Fahrzeug über die ursprüngliche Geschwindigkeit des hinteren Fahrzeugs hinaus, macht das hintere Fahrzeug die Beschleunigung mit, bis seine ursprüngliche Geschwindigkeit erreicht ist, und behält diese dann bei. Die dem hinteren Fahrzeug zugeordnete Ist-Geschwindigkeit wird also beibehalten, wenn das Fahrzeug beim Auffahren auf ein langsameres Fahrzeug abgebremst wird.

Mir stellte sich daraufhin die Frage, ob es nicht möglich wäre, durch "weiches" Abbremsen des ersten Fahrzeugs auf z.B. 0,001 km/h "quasi" anzuhalten (vielleicht sogar "de facto"), ohne dass nachfolgende Fahrzeuge trotz Zwangshalt beim Auffahren ihre zugeordnete Ist-Geschwindigkeit verlieren, und dann beim Wiederanfahren des ersten Fahrzeugs alle aufgefahrenen Fahrzeuge ebenfalls anfahren - alle mit der dem ersten Fahrzeug zugeteilten Beschleunigung. Dies wäre dann tatsächlichen Konvoi-Stopp-Mechanismus ähnlich analog zu dem in Anlagenbaustein "Autokonvoi 1" beschrieben, mit dem gravierenden Unterschied, dass keinen Fahrsperren im Spiel sind, und damit auch das Anhalten und losfahren nicht abrupt, sondern "weich" erfolgt.

Leider ließ sich dann diese Idee nicht realisieren, weil sich das Verhalten des vorderen Fahrzeugs bei sehr niedrigen Geschwindigkeiten plötzlich ändert. Hierzu habe ich ein kleines Test-Oval gebaut, auf dem zwei Fahrzeuggespanne (jeweils ein angetriebenes Dummy-Fahrzeug mit 5 nicht angetriebenen Dummy-Anhängern) ihre Runden drehen.

Blockade-Test.mbp

Die vorderen Kupplungen beider Gespanne sind deaktiviert, damit die beiden Gespanne sich nicht zu einem "Zug" vereinigen. Für beide Gespanne ist ursprünglich eine Geschwindigkeit von 100 km/h eingestellt, mit der sie auf dem Oval ihre Runden drehen, ohne sich gegenseitig zu behelligen.
 

In der Mitte des der unteren Gerade ist eine Gleiskontakt platziert, an dem die Eintrittsgeschwindigkeit des jeweils Gespanns gemessen und  und zusammen mit seiner Kennzeichnung ausgegeben wird.

Reduziert man nun die Geschwindigkeit des vorderen Gespanns auf beispielsweise 50 km/h, schließt das hintere Gespann auf und wird beim Auffahren auf ebenfalls diese Geschwindigkeit zwangs-abgebremst, ...

... ohne hierbei die ursprüngliche Geschwindigkeitszuordnung zu verlieren. Auf diese Art kann das hintere Gespann durch das vordere auf bis etwa 2 km/h abgebremst werden. Ab unter 4 km/h tritt ein gelegentliches Ruckeln auf, das mit weiter sinkender Geschwindigkeit sich bist zu seinem Höhepunkt bei etwa 2 km/h steigert.

 

In einem Geschwindigkeitsbereich zwischen etwa 2,2 km/h und 2,0 km/h tritt plötzlich ein seltsames Phänomen auf: 

Beim Eintritt des vorderen Gespanns am Gleiskontakt wird zufallsgesteuert anstelle dieses Gespanns das hintere Gespann mit seiner eingestellten Ist-Geschwindigkeit von 200 km/h angezeigt, was bedeutet, dass das vordere Gespann nicht mehr als eigenständiges Gespann, sonder als geschobener Teil des hinteren Gespanns erkannt wird. Geht man mit der vorderen Geschwindigkeit noch weiterherunter werden die beiden Gespanne nur noch gemeinsam als "Hinteres Gespann" identifiziert. Außerdem steigt die Geschwindigkeit nun langsam wieder an und erreicht bei einer eingegeben Geschwindigkeit von 0,01 km/h für das vordere Gespann tatsächlich geschätzte 60 km/h (diese Geschwindigkeit kann nicht direkt gemessen werden).

Im Einzelnen habe ich folgende Geschwindigkeiten gemessen bzw. geschätzt:

eingegebene Geschwindigkeit      gemessene oder geschätzte Geschwindigkeit
100 km/h bis ca. 2,0 km/h             gemessene = eingegebene Geschwindigkeit (bis auf minimale Rundungsfehler)
1,0 km/h                                        geschätzt 30 km/h
0,1 km/h                                        geschätzt 50 km/h
0,01 km/h                                      geschätzt 60 km/h

Stellt man die Geschwindigkeit des vorderen Gespanns exakt auf 0, springt die tatsächliche Geschwindigkeit abrupt auf die 100 km/h des hinteren Gespanns. stellt man anschließend für das vordere Gespann wieder eine Geschwindigkeit >0 ein, wird wieder abrupt auf die entsprechende Geschwindigkeit - interpoliert aus obiger Tabelle - gesprungen. Bei einer Geschwindigkeitsänderung für das vordere Gespann von >0 nach >0 erfolgt die Geschwindigkeitsanpassung immer "Weiche" entsprechend der eingestellten Werte für die Bremsverzögerung und die Beschleunigung.

Fragen an @Neo:
Gibt es eine Erklärung für dieses Verhalten?
Wäre es eventuell möglich, das Verhalten so anzupassen, dass die oben beschriebene Idee einer "weichen" Konvoi-Abbremsung ermöglicht werden könnte?
Es wäre zumindest eine Überbrückungsmöglichkeit bis zur V6, mit der man weiches Anhalten und Anfahren mit dem einfachen Lösungsansatz des Anlagenbausteins "Autokonvoi 1" verbinden könnte und damit die Mängel aller oben beschriebenen Lösungsansätze beseitigen könnte.

Viele Grüße
BahnLand

[HaNNoveraNer]

Gut, daß Neo da bald was zum Abstandhalten im Basiscode entwickeln will :-)

[Neo]

Hallo BahnLand,

ich habe großen Respekt vor deiner aufwendigen Arbeit, das muss viele Stunden gekostet haben. Um so schwerer fällt es mir zu sagen, dass es für V5 keine Änderungen am Fahrzeug-Code mehr geben wird. Ich habe bereits für V6 den gesamten Code erneuert und gute Fortschritte mit der Abstandsverwaltung gemacht. Die Ergebnisse sind jetzt schon nicht mit dem zu vergleichen, was mit V5 mit viel Aufwand möglich wäre. In V6 wirst du beliebige Autos auf eine Straße setzen, dem vorderen eine Geschwindigkeit geben und alle Nachfolger orientieren sich automatisch, ohne unsichtbare Hilfsobjekte oder Ereignisse.

Es wird sich lohnen, auf V6 zu warten!

Viele Grüße,

Neo

[HaNNoveraNer]

@Neo

Kann man das vielleicht auch zum Rangieren von Loks und Waggons verwenden?
Sprich: die fahren automatisch abgebremst an stehende Waggons/Loks/Züge ran, um dann verkuppelt zu werden.

 

Gruß
Thomas

[Neo]

Hallo Thomas,

vor 1 Minute schrieb HaNNoveraNer:

Sprich: die fahren automatisch abgebremst an stehende Waggons/Loks/Züge ran, um dann verkuppelt zu werden.

ja

Viele Grüße,

Neo

[HaNNoveraNer]

[AndreasWB]

Hallo zusammen,

ich bin "erst" in der Evaluierungsphase und unternehme jetzt meine ersten Schritte in Richtung "Zugsteuerung durch Signale".

Etwas verwirrt bin ich über die Funktion der Brems-/Gleiskontakte. Beim Bremskontakt (Beschreibung wenn man das Symbol anklickt) heißt es, daß der auslösende Zug rechtzeitig vor dem Kontakt auf die dort eingestellte Geschwindigkeit gebremst wird.

• Sofern ich diese Geschwindigkeit in den direkten Eigenschaften einstelle, funktioniert dies mit gewissen Einschränkungen auch.
• Wenn ich das Abbremsen / Anhalten aber über Ereignissteuerung, z.B. abhängig von Stellung des Signals versuche, fängt der Zug erst ab dem Kontakt an, zu bremsen.

Ist dies noch ein Programmfehler, oder ist das irgendwie von den Autoren anders gedacht?

Gruß

Andreas

[Old Grey]

Hallo Andreas,

das Abbremsen funktioniert abhängig von der beim Fahrzeug eingestellten Verzögerung nur über eine bestimmte Strecke. Meine Fahrzeuge sind aktuell alle auf eine Verzögerung von 2,5 eingestellt. Ich habe mir dann eine Teststrecke gebaut, mit der ich getestet habe, wann die Fahrzeuge mit einer Geschwindigkeit vom 80 km/h zum stehen kommen. In diesem Abstand kommt dann ein Vorsignal das die Fahrzeuge an diesem Punkt auf 80 km/h abbremst. Da ich auf dieser Anlage max. 120 fahre reicht diese eine Signal. Solltest Dz jedoch noch höhere Geschwindigkeiten verwenden, mußt Du weitere Bremspunkte (Vorsignale) einbauen.

Viel Spaß beim probieren.

Neo hat es hier irgentwo schom mal erklärt, aber ich habe den Beitrag leider nicht gefunden.

Gruß Old Grey

[Goetz]

vor 10 Stunden schrieb AndreasWB:

Wenn ich das Abbremsen / Anhalten aber über Ereignissteuerung, z.B. abhängig von Stellung des Signals versuche, fängt der Zug erst ab dem Kontakt an, zu bremsen.

Mit dem Ereignis "Zug betritt Kontakt" kannst du natürlich erst in dem Augenblick etwas bewirken, wenn der Zug den Kontakt erreicht.

Der Wert für das Abbremsen auf dem Weg zum Kontakt ist eine Eigenschaft dieses Kontakts.
Diese Eigenschaft musst du in Abhängigkeit von der Signalstellung ändern.

Bearbeitet 23. November 2020 von Goetz
Bild hinzugefügt

[AndreasWB]

Hallo Goetz,

hm interessanter Ansatz. Ich habe es so nachgestellt.
Mein Signal hat den Objektnamen "S1" (wie wohl auf vielen Anlagen üblich). Wenn ich mir die Objekte der Anlage anzeigen lasse, wird es auch so aufgelistet.
Aber die Lok fährt auch bei Hp0 einfach durch.

Mir fällt auf, daß Du eine Eigenschaft beim Signal verwendest, die im Signal-Objekt doch gar nicht existiert.
Wie würde man die Eigenschaft "Stoppkontakt" mit den benötigten Eigenarten dem Signalkontakt überhaupt zuordnen?

Gruß

Andreas

P.S. Ich habe diese Aktionskette auch mit S1 statt [Signal] getestet - selbes negative Ergebnis.

Bearbeitet 23. November 2020 von AndreasWB

[streit_ross]

Hallo Andreas,

ich sehe aber bei Deiner Aktionskette, dass Du dem Signal S1 kein Schlagwort zugeteilt hast.

Gruß

streit_ross

[AndreasWB]

Ich habe noch eine andere Variante. Diese funktioniert allerdings nur eingeschränkt.

Signal S1 wurde auf Hp0 geschaltet. Beim ersten mal fährt der Zug unbeirrt durch. Jedoch bei der zweiten Runde hält er dann ordnungsgemäß an.

Umgekehrt: Signal S1 wurde auf Hp1 geschaltet. Auch hier muß der Zug erst einmal den Gleiskontakt vom Signal aktivieren, damit er beim zweiten Annähern odnungsgemäß funktioniert - den Zug jetzt durchfahren lassen.

Ich habe dann den Auslöser gewählt, daß das  Schalten des Signals der Auslöser des Ereignisses ist, das bewirkt aber aucgh nichts.
Irgendwie stehe ich gewaltig auf dem Schlauch.

Gruß

Andreas

[AndreasWB]

vor 1 Minute schrieb streit_ross:

Hallo Andreas,

ich sehe aber bei Deiner Aktionskette, dass Du dem Signal S1 kein Schlagwort zugeteilt hast.

Gruß

streit_ross

Hallo streit_ross,

was hat das mit dem "Schlagwort" auf sich?
Klar, das kann ich auch einstellen, ändert aber nichts an der Wirkung.

Wie sollte es denn geschrieben werden, wenn diese Ereignis-Kette für das Einfahrtsignal S1 gilt?

Gruß

Andreas

[HaNNoveraNer]

Hallo

Ich würde das Bremse scharf machen beim Schalten als Ereignis ausführen. 

Und dann muss es einmal schalten, damit es beim nächsten Zug wirkt. 

Beim Kontakt verlassen kannst du dann wieder auf hp0 zurück schalten. 

 

 

 

[AndreasWB]

Hallo Hannoveraner,

das Aktivieren durch Schalten des Signals hat leider auch nichts bewirkt.

Mir scheint das Setzen des Aktivitätswertes (boolsches Flag) "[Gleiskontakt].Automatische Verzögerung" nicht zu funktionieren.
Sollte man es dann nicht auch im Eigenschaftenfenster des Signals sehen?

Gruß

Andreas

[Goetz]

vor 2 Stunden schrieb AndreasWB:

Mir fällt auf, daß Du eine Eigenschaft beim Signal verwendest, die im Signal-Objekt doch gar nicht existiert.

Stoppkontakt ist keine Eigenschaft, sondern eine Variable. (Das sieht man meinem Screenshot leider nicht an.)
In dieser Variablen habe ich den Kontakt gespeichert, der bei mir zu diesem Signal gehört. Denn ich will den Zug etwas vor dem Signal an diesem Kontakt stoppen.

An anderer Stelle hier im Forum hatte ich folgende Beispielanlage mit eingefügt, in der du das Prinzip anschauen kannst:

Nah- und Fernverkehr.mbp

• Wenn das Signal umschaltet, dann ändere ich die Eigenschaft in einem Kontakt.
• Welcher Kontakt das ist, finde ich in der Variablen "Stoppkontakt" im Signal.

Bearbeitet 23. November 2020 von Goetz

[Goetz]

vor 41 Minuten schrieb AndreasWB:

was hat das mit dem "Schlagwort" auf sich?

Schlagworte kannst du benutzen, um mehrere Signale in einer "Kategorie" zusammenzufassen.
Das eröffnet dir die Möglichkeit, ein einziges Verhalten für alle Signale mit diesem Schlagwort zu erstellen. Erspart viel Arbeit, weil du nicht jedes Signal einzeln behandeln musst.

Aber für dein akutes Problem ist das ohne Belang. Das kommt später.

 

vor 27 Minuten schrieb HaNNoveraNer:

Ich würde ...

Schau dir bitte erst mein Beispiel an und bring Andreas jetzt nicht auf den falschen Pfad.
Die Eigenschaft im Kontakt stellt man mit dem Signal um und nicht beim Betreten des Kontakts!

[AndreasWB]

Hallo Goetz,

aha danke.

Das mit einem Kontakt kurz vor dem Signal als Stopp-Punkt hatte ich auch schon mal probiert. Bekommt jetzt seinen Sinn mit dem geänderten Ansprechen der Einstellungen für einen Bremskontakt.

Zu den Schlagworten:
Das hatte ich gestern abend kurz probiert. Hauptsignalen hatte ich das Schlagwort "Signal" gegeben, was dann in der EV-Beschreibung auch gut funktionierte.
Dagegen habe ich für Vorsignale das Schlagwort "Vorsignal" verwendet. Aber in den EV-Anweisungen konnte ich es z. B. bei "Signal FormVorsignal 1... schaltet" nicht aussuchen. Es wurde mir immer nur das Schlagwort "Signal" als einziges zur Auswahl angeboten.

Heute Nachmittag komme ich vielleicht dazu, das nochmals zu probieren und einige Screenshots anzufertigen.

Gruß

Andreas

[Goetz]

Du musst bitte Verursacher und Ziel auseinanderhalten:

Unter "wann wird ein Ereignis ausgelöst" kannst du per Schlagwort ein ganzes Sortiment an Objekten nennen.   (1)

Das Ziel einer Abfrage oder einer Aktion ist hingegen ein einzelnes Objekt. Und bei Verallgemeinerungen kann man festlegen, dass dieses Objekt dasjenige sein soll, das akut das Ereignis getriggert hat. Wenn es dabei um Bedingungen oder Aktionen geht, die ein Signal betreffen, heißt dieser Auslöser schlicht "Signal". Das hat nichts mit den Schlagwörtern zu tun. (2 und 3)

Selbst, wenn du für alle Signale bestimmst, dass sie bei überfahren auf "Halt" zurückfallen sollen, dann darf in dem Augenblick, in dem eins der Signale überfahren wird, auch nur dieses Signal umgestellt werden und keinesfalls alle Signale mit demselben Schlagwort. Deshalb wäre es hier unsinnig das Schlagwort als Adresse für die Aktion anzugeben. Du möchtest immer nur das eine Objekt ansprechen, welches das Ereignis in diesem Moment ausgelöst hat.

Bearbeitet 24. November 2020 von Goetz
Schreibfehler korrigiert

[Dad3353]

If I may add a little to this ..? I specify my own terms to be different to those used by The System. Any keyword, for instance, I would always write as 'Keyw_', followed by a relevant expression, so 'Keyw_Sign', or 'Keyw_Loco'. This makes differentiation much easier. I do the same for all names, in fact; for Contacts, I'd name them 'Cont_xxxx', and signals would be 'Sign_xxxx'. All my locomotives receive the name 'Engi_xxxx'. It makes reading the code much easier, with no risk of confusion with system names. Hope this helps. 

Wenn ich noch etwas hinzufügen darf ...? Ich lege meine eigenen Begriffe so fest, dass sie sich von den vom System verwendeten unterscheiden. Jedes Schlüsselwort würde ich zum Beispiel immer als 'Keyw_' schreiben, gefolgt von einem entsprechenden Ausdruck, also 'Keyw_Sign' oder 'Keyw_Loco'. Das macht die Unterscheidung viel einfacher. Ich mache eigentlich für alle Namen das Gleiche; für Kontakte würde ich sie 'Cont_xxxx' nennen, und Signale wären 'Sign_xxxx'. Alle meine Lokomotiven erhalten den Namen 'Engi_xxxx'. Das macht das Lesen des Codes viel einfacher, ohne die Gefahr einer Verwechslung mit Systemnamen. Hoffentlich hilft das 

Bearbeitet 24. November 2020 von Dad3353

[Goetz]

I love your translation, Dad.
Now that we have "everyday" and "posh", could you maybe add Cockney as well?

On a more serious note: You need to understand the difference between keywords and generic terms first, before you can develop the plan to distinguish one from the other by clever choice of keywords. 

Bearbeitet 24. November 2020 von Goetz