Vorwort
Anhand von Beispielen aus dem Projekt
St. Margareten
(Stand 2011) soll Konfiguration
und Einsatz dieser TC* - Objekte, gegenüber dem in
"Philosophie" (s. linkes Register)
gegebenen Überblick detaillierter dargestellt werden.
TC* zeichnet sich u.a. dadurch aus, daß es möglich ist, mehrere Wege
zur Erreichung seines individuellen Ziels (Betriebsablauf, Betriebssituation) zu beschreiten. Von
daher ist es sehr wichtig, sich jedesmal sein Ziel genau zu
definieren.
Die hier aufgezeigten Möglichkeiten sollen nur das Prinzip
verdeutlichen und erheben keinen Anspruch auf Vollständigkeit und
/ oder Fehlerfreiheit.
Die nachfolgenden Bilder können jeweils durch
Anklicken
vergrößert werden!!
Anmerkung zum Thema Melder
Melde Objekte oder einfach Melder,
werden von TC* in drei Varianten bereitgestellt...
- als Kontaktmelder
- als Bahnwärter
- als virtueller Kontakt
Ihre spezifische Aufgabenstellung oder auch Funktion
erhalten die Objekte durch ihren konkreten Einsatz (Zuordnung)
innerhalb des TC* - Gleisplans im "Stellwerk"-Fenster.
So kann das Objekt "Kontaktmelder" als auch der "virtuelle
Kontakt" z.B. im Zusammenhang mit einem TC* - Block eine der
nachfolgenden Funktionen übertragen bekommen ....
- Bremsmelder ..................... markiert den Beginn der
Bremsstrecke
- Haltmelder ........................ markiert den Beginn
des Halteabschnitts
- Geschwindigkeitsmelder .... markiert den Punkt zur
Änderung der Geschwindigkeit
- Ereignismelder .................. markiert den Punkt an
zum Start von (z.B. Lok-) Aktionen
"Kontaktmelder" werden über den Zustandswechsel eines
Hardware - Melders bzw. dessen Sensor (Stromschiene,
IR-Lichtschranke, Reedkontakt, Relaiskontakt, Hallsensor, etc.)
aktiviert bzw. deaktiviert.
Sie geben die aktuelle Situation auf der Anlage (Hardware) wieder.
"virtueller Kontakt" und seine Einsatzbereiche
...
- Dieser ist eine "Melder-Erweiterung" für die
Fälle, in denen es nicht ausreichend
Hardware-Melder gibt oder sich einbauen lassen oder aus
Kostengründen auf diese verzichtet wird.
- Dieser ist eine "Melder-Ergänzung" um komplexe
Steuerungsaufgaben zu erledigen, die -- ausgelöst von einem
Hardware - Meldeobjekt -- von einem TC* - Kontaktmelder nicht
erledigt werden können. Der "virtuelle Kontakt" bietet hier in
diversen Registern weitere Möglichkeiten zur Differenzierung der
Aktivitäten in Abhängigkeit EINES Meldeereignisses.
Der "virtuelle Kontakt" benötigt in beiden Fällen eine Referenz, einen
sog. Referenzmelder und damit einen "Kontaktmelder".
Die Aufgabe des "virtuellen Kontakts" besteht im
Einsatzspektrum "Melder-Erweiterung" darin, in einem
bestimmten zeitlichen Abstand NACH dem Eintreten des Ereignisses
beim Referenzmelder zu reagieren.
Dieser zeitliche Abstand wird z.B. von TC*
aufgrund der angegebenen räumlichen Entfernung -
fiktiven
Einbaulage auf der Anlage - zum Referenzmelder und der
Geschwindigkeit des Fahrzeugs (Lok, Zug, ..) berechnet.
Anmerkung:
Um eine möglichst genaue / gute zeitliche Zuordnung zu erhalten
und damit letztlich eine reproduzierbare Aktion(en); z.B. HALT
ausführen zu können,
MUSS die Lok mit dem TC* Programm genau eingemessen werden.
D.h. es wird eine Kennlinie pro Lok aufgenommen, aus der dann die
Geschwindigkeits - Weg - Zeit - Relation abgeleitet wird.
Hinweis:
Im Projekt St. Margareten wurden die Brems- und Haltemelder
mittels "Kontaktmeldern" realisiert. Der Grund hierfür liegt
darin, daß ich nicht erwarte, daß die alten Märklin * - Fahrzeuge
unter allen Temperatur- und Feuchtigkeits- Randbedingungen als
auch mechanischen wie elektrischen Situationen hinreichend genaue,
reproduzierbare Fahrtwerte liefern.
Eine reale Hardware-Rückmeldung erscheint mir da sicherer.
"Gleiszustandsüberwachung im Projekt"
TC* - Blöcke und damit die entsprechenden Hardware-Bereiche werden
durch einen sog. "Besetztmelder" überwacht, und zwar der komplette
Abschnitt.
Entsprechend der Gleisnutzung (eine / zwei -- Fahrtrichtungen) ist
pro Fahrtrichtung ein Bremsmelder und ein Haltmelder installiert.
Zur Überwachung von Weichen / Kreuzungen, etc. wurden eigene
"Besetztmelder" eingebaut.
Die Aufgabe des "virtuellen Kontakts" besteht im
Einsatzspektrum "Melder-Ergänzung" darin, die
Funktionalität des "Kontaktmelders" zu ergänzen.
Der "virtueller Kontakt" besitzt einige zusätzliche
Register in den Eigenschaften, die es ermöglichen, auf ein
Meldeereignis in Abhängigkeit von dem jeweiligen Betriebsablauf,
wie Züge / Zugverbände / Zugfahrten im Block,
unterschiedlich und damit flexibel zu agieren, d.h. Aktionen zu
starten.
Damit kann ein Hardware - Ereignis sehr flexibel eine Kette
unterschiedlicher Ereignisse auslösen.
Im allgemeinen will man bei diesem Einsatzspektrum KEINE zeitliche
Verzögerung zum Referenzmelder, deshalb ist die räumliche
Entfernung mit dem minimalsten Wert (0 cm) anzugeben.
"Bahnwärter" -- eine für mich etwas
unglückliche Bezeichnung, die wohl der Historie geschuldet ist
-- sind im Prinzip "TC* interne Objekt-Sensoren",
denn sie ermöglichen die Beobachtung anderer TC* Objekte in
Hinblick auf deren Zustandswechsel.
Wird ein solcher "Auslöser" erkannt, dann wird der "Bahnwärter"
unter Berücksichtigung der eingetragenen Bedingungen aktiv, d.h.
er führt die definierten Operationen aus.
Mit diesen Merkmalen ist der "Bahnwärter" ein "Scharnier"
zwischen den TC* - Objekten und gleichzeitig ein super flexibles
Objekt zur Gestaltung von hochkomplexen Modellbahn - Steuerungen.
Anmerkung:
Durch die beiden Eigenschaften-Register "Züge" und "Zugfahrten"
ergänzt der "virtuelle Kontakt" auch die Funktionalitäten eines
"Bahnwärters" und wird damit zur "Bahnwärter-Ergänzung".
Der "virtuelle Kontakt" entpuppt sich somit zu einem
"allround" Talent.
Anmerkung zum
Thema Markierungen in einem TC* - Block
Das zuvor Gesagte muß an dieser Stelle präzisiert
werden.
Der Kontakt- oder virtuelle Melder ist das
Element / Objekt, welches einen Zustandswechsel feststellt.
Die für TC* eigentliche Funktion, die bei
dem Zustandswechsel ausgelöst wird, kommt durch die Zuordnung einer
der folgenden TC* - Markierungen zu dem einzelnen Melder
zustande ..
- Bremsmarkierung
- Haltemarkierung
- Aktionsmarkierung
Der jeweilige Markierungstyp verleiht -- im
Umgangssprachgebrauch -- dem Melder seine Melde-Aufgabenstellung.
Hinweis
Im folgenden werden die Melder dargestellt und
beschrieben, da diese auch zu allerlei sonstigen Funktionalitäten
eingesetzt werden können.
Die Darstellung der Markierungen ist in dem
Abschnitt TC-Block abgehandelt.
Editiermodus
Auswahl und Positionierung dieser
TC* - Objekte
sowie deren Konfiguration kann NUR in diesem Modus erfolgen.
Die Konfiguration dieser TC* - Objekte erfolgt in den
"Objekt - Eigenschaften".
Kontaktmelder ---- dargestellt am
Beispiel: Bremsmelder
Register "Allgemeines"
Die hier gezeigten Felder sind wohl
selbstredend und bedürfen keiner weiteren Kommentierung.
Register "Anschluß"
Hier ist die Adresse des Decoders
einzutragen, der als (Hardware-) Melder fungiert und der "Eingang"
(Decoder-Anschluß), an dem sich der (Hardware-) Sensor befindet.
Register "Operationen"
In dem Feld "Operationen" können alle
Aktivitäten eingetragen werden, die ausgeführt werden sollen, wenn
der Kontaktmelder in den Zustand ÜBERGEHT, der in dem Feld
"Auslösender Zustand" angezeigt (ausgewählt) ist (wurde).
Register "Memory"
In diesem Register läßt sich eintragen, wie
lange der Kontaktmelder in dem "aktiven" (rot) Zustand verweilen
soll.
"Selbsttätig" ist so zu verstehen, daß er dann in den "inaktiven"
Zustand wechselt, wenn das auslösende Ereignis fortfällt.
virtueller Kontakt ---- dargestellt am
Beispiel: Bremsmelder
Register "Allgemeines"
Die hier gezeigten Felder sind wohl
selbstredend und bedürfen keiner weiteren Kommentierung.
Register "Referenz"
Hier ist der Referenzmelder (Bezugsmelder,
Kontaktmelder) als TC* - Melder anzugeben und ebenso die
Fahrtrichtung, in der der virtuelle Kontakt wirksam werden soll.
Register "Bedingungen"
Im DropDown Feld "betroffener
Zustand" ist der Objekt - Zustand auszuwählen für den
die Bedingung gelten soll. Dies bedeutet, es können für
verschiedene Objektzustände auch jeweils individuelle Bedingungen
gesetzt werden.
Die Bedingungen selbst werden in
dem Feld "überprüfte Objekte"
eingetragen. D.h es werden Objektzustände anderer Objekte
festgelegt, die herrschen müssen, damit dieses Objekt aktiv
werden kann.
Das Feld "Nicht" erlaubt die Negierung
einer im Feld "überprüfte Objekte" Aussage, die per mouse
zuvor markiert wurde.
Das Feld "überprüft" erlaubt einen Wechsel der
Zustands- / Abfrage- Aussage im Feld "überprüfte Objekte"
entsprechend der Wahlmöglichkeit die das DropDown Feld anbietet.
Die zu verändernde Aussage ist zuvor mit der mouse zu markieren.
Das Feld "neue Gruppe" fügt in das Feld "überprüfte
Objekte" eine neue "Verknüpfung" ein, die als UND, ODER,
etc. mittels des Feldes "überprüft" eingestellt werden kann.
Liegen KEINE Einträge im Feld "überprüfte Objekte"
vor, das Feld ist also leer, dann wird der im Feld "betroffener
Zustand" angezeigte Zustand IMMER erreicht; oder anders
gesagt die Bedingung(en) ist / sind immer erfüllt !!!
Register "Operationen"
In dem Feld "Operationen" können alle
Aktivitäten eingetragen werden, die ausgeführt werden sollen, wenn
der Bahnwärter in den Zustand ÜBERGEHT der in den Feld
"Auslösender Zustand" angezeigt (ausgewählt) ist (wurde).
Register "Memory"
In diesem Register läßt sich eintragen, wie
lange der Kontaktmelder in dem "aktiven" (rot) Zustand verweilen
soll.
"Selbsttätig" ist so zu verstehen, daß er dann in den "inaktiven"
Zustand wechselt, wenn das auslösende Ereignis fortfällt.
Register "Züge"
In diesem Register kann die Wirkungsweise des
virtuellen Kontakts in Bezug auf Züge / Zugverbände festgelegt
werden.
KEIN Eintrag bedeutet, der virtuelle Kontakt
wird IMMER tätig, d.h. bei ALLEN Zügen / Zugverbänden.
SIND EINTRÄGE vorhanden, dann wird der
virtuelle Kontakt NUR BEI DIESEN Zügen / Zugverbänden tätig.
Register "Zugfahrten"
In diesem Register kann die Wirkungsweise des
virtuellen Kontakts in Bezug auf Zugfahrten festgelegt werden.
KEIN Eintrag bedeutet, der virtuelle Kontakt
wird IMMER tätig, d.h. bei ALLEN Zugfahrten.
SIND EINTRÄGE vorhanden, dann wird der
virtuelle Kontakt NUR BEI DIESEN Zugfahrten tätig.
Bahnwärter ---- dargestellt am Beispiel:
Weichenüberwachung
Register "Allgemeines"
Die hier gezeigten Felder sind wohl
selbstredend und bedürfen keiner weiteren Kommentierung.
Register "Auslöser"
Im DropDown Feld "betroffener
Zustand" kann der Zustand ausgewählt werden, der
eingestellt werden soll, wenn der im Feld "überprüfte Objekte"
angegebene Zustand eintritt (!!).
Achtung:
Der Auslöser löst NUR aus, wenn bei den "überprüften Objekte"
sich ein Zustand in der Form ändert !!, so daß dann die angegebene
Zustandskombination herrscht. Es ist also der Zeitpunkt des
Zustandswechsels wichtig, nicht der (spätere) permanente Zustand
selbst.
Das Feld "Nicht" erlaubt die Negierung
einer im Feld "überprüfte Objekte" Aussage, die per mouse
zuvor markiert wurde.
Das Feld "überprüft" erlaubt einen Wechsel der
Zustands- / Abfrage- Aussage im Feld "überprüfte Objekte"
entsprechend der Wahlmöglichkeit, die das DropDown Feld anbietet.
Die zu verändernde Aussage ist zuvor mit der mouse zu markieren.
Das Feld "neue Gruppe" fügt in das Feld "überprüfte
Objekte" eine neue "Verknüpfung" ein, die als UND, ODER,
etc. mittels des Feldes "überprüft" eingestellt werden kann
Register "Bedingungen"
Im DropDown Feld "betroffener
Zustand" ist der Objekt - Zustand auszuwählen für den
die Bedingung gelten soll. Dies bedeutet, es können für
verschiedene Objektzustände auch jeweils individuelle Bedingungen
gesetzt werden.
Die Bedingungen selbst werden in
dem Feld "überprüfte Objekte"
eingetragen. D.h es werden Objektzustände anderer Objekte
festgelegt, die herrschen müssen, damit dieses Objekt aktiv
werden kann.
Das Feld "Nicht" erlaubt die Negierung
einer im Feld "überprüfte Objekte" Aussage, die per mouse
zuvor markiert wurde.
Das Feld "überprüft" erlaubt einen Wechsel der
Zustands- / Abfrage- Aussage im Feld "überprüfte Objekte"
entsprechend der Wahlmöglichkeit , die das DropDown Feld anbietet.
Die zu verändernde Aussage ist zuvor mit der mouse zu markieren.
Das Feld "neue Gruppe" fügt in das Feld "überprüfte
Objekte" eine neue "Verknüpfung" ein, die als UND, ODER,
etc. mittels des Feldes "überprüft" eingestellt werden kann
Sind im Feld "überprüfte Objekte"
keine Einträge, also keine Bedingungen angegeben, dann wird der
eingestellte "betroffene Zustand" IMMER erreicht, weil dann
das TC* - Programm diesen Zustand immer als erfüllte Bedingung
interpretiert.
Register "Operationen"
In dem Feld "Operationen" können alle
Aktivitäten eingetragen werden, die ausgeführt werden sollen, wenn
der Bahnwärter in den Zustand ÜBERGEHT der in den Feld
"Auslösender Zustand" angezeigt (ausgewählt) ist (wurde).
Register "Memory"
In diesem Register läßt sich eintragen, wie
lange der Bahnwärter in dem "aktiven" (rot) Zustand verweilen
soll.
"Selbsttätig" ist so zu verstehen, daß er dann in den "inaktiven"
Zustand wechselt, wenn das auslösende Ereignis fortfällt, d.h.
sich wieder ändert.
Betriebsmodus
Simulation (offline) und realer
Betrieb (online) mit der
Modellbahnanlage können NUR in diesem Modus erfolgen.
Er wird automatisch erstellt, wenn der Editiermodus deaktiviert
wird !!
Die obigen Objekte lassen sich individuell so einstellen, daß
sie IMMER oder NUR im Editiermodus sichtbar (eingeblendet) sind.
Im Normalfall werden diese Objekte der Übersichtlichkeit wegen in
dem Betriebsmodus ausgeblendet.
Hinweis:
In der Simulation geht das TC* Programm immer davon aus, daß
die Blöcke nicht besetzt sind, es sei denn TC* hat einen
"Reservierungszustand" oder "Belegtzustand" selbst berechnet.
Will man in der Simulation eine Betriebssituation erzeugen, die
darauf beruht, daß auf der Anlage z.B. ein Besetztzustand durch
ein liegengebliebenes Fahrzeug herfeigeführt wurde, dann MUSS man
die entsprechenden Melder im Betriebsmodus "sichtbar schalten",
damit dieser Zustand durch manuelles Aktivieren des Melders
herbeigeführt werden kann.
