Fahrzeug-Sensoren

    Moin! Das Durchlesen des Lexikonartikels zum Thema Fahrstraßen insbesondere des Abschnitts der fahrzeugseitigen Einbindung, hat bei mir genauso viele neue Fragen aufgeworfen, wie der Artikel beantwortet hat. Speziell der Sinn der Prozedur OnEnterLeaveTrigger erschließt sich mir nicht. Aber der Reihe nach. Wenn ich das richtig verstanden haben, ist SendMessageToTrigger die Grundfunktion zum Kommunizieren des Fahrzeugs mit der Umwelt, mit folgender Auswirkung:

    Zitat von Lexikon

    Senden von Meldungen an alle in Reichweite befindliche Trigger

    Unter welchen Umständen genau befindet sich denn ein Trigger in Reichweite? Nur, wenn er sich unmittelbar am Sensor/Sender des Fahrzeugs befindet? Oder sobald er in einem 50m-Radius darum herum ist? Oder muss er sich auf dem aktuellen Fahrweg befinden, wird aber auch schon angesprochen, wenn das Fahrzeug noch 50m weit weg ist?


    Beim GT6N wird laut diesem Artikel zusätzlich noch die Prozedur OnEnterLeaveTrigger verwendet, was dafür sorgt, dass obiger Befehl nur ausgeführt wird, wenn sich das Fahrzeug genau an einem Trigger befindet. Warum man das so gelöst hat, verstehe ich allerdings nicht.

    Zitat von Lexikon

    Im GT6N werden zum Beispiel beide Funktionen zusammen verwendet: Wenn der Fahrer einen Stellbefehl aktiviert, dann wird dieser Wert (für eine bestimmte maximale Wegstrecke) "vorgemerkt". Wird dann OnEnterLeaveTrigger ausgelöst, dann benutzt das Script sofort SendMessageToTrigger und sendet damit den Stellbefehl an den Trigger.

    Beträgt der Senderadius für Fahrstraßenanforderungen 50 Meter, wird der Stellbefehl ja trotzdem an alle anderen Triggerpunkte in der Nähe geschickt, sobald das Fahrzeug den Kontakt überfährt. Ist der Senderadius dagegen nur sehr klein (<1m), würde der Stellbefehl auch von einem Fahrzeug, das ab Eingabe durch den Fahrer für 30 Meter Fahrstrecke kontinuierlich sendet, genauso nur an alle Trigger übergeben werden, die sich innerhalb der nächsten 30 Meter direkt am Fahrweg befinden. Damit wäre die Vewendung von OnEnterLeaveTrigger in diesem Falle völlig unsinnig, was zugegebenermaßen eher unwahrscheinlich ist.


    Hat dieses Vorgehen also eventuell noch andere Vorteile, die ich nicht direkt sehe, und die im Lexikonartikel nicht genannt werden, zum Beispiel einen bedeutenden Performancegewinn des nur punktuell sendenden Fahrzeugs gegenüber einem Fahrzeug, das konstant sendet, oder habe ich irgendetwas anderes falsch verstanden?

    Hi,


    zu letzterem: Es gibt kein "kontinuierliches Senden". SendMessageToTrigger sendet sofort und ein einziges Mal.

    Zwar könnte man die Prozedur für eine bestimmte Strecke in jedem SimStep aufrufen, allerdings wirkt sich das tatsächlich auf die Performance aus.

    Daher sollte das kontinuierliche Senden in Kombination mit OnEnterLeaveTrigger realisiert werden, indem sich das Fahrzeugscript nur vormerkt, dass es über eine bestimmte Wegstrecke hinweg senden soll, SendMessageToTrigger aber erst ausführt, wenn OnEnterLeaveTrigger ausgelöst wird, was genau dann passiert, wenn ein Trigger in Reichweite kommt.


    Zur Reichweite kann ich leider nichts sagen.

    Zitat von Kartoffelphantom

    Unter welchen Umständen genau befindet sich denn ein Trigger in Reichweite?

    Wenn der Abstand zwischen Triggerposition und Fahrzeugsensor kleiner als der im MapEditor eingegebene Wert ist (dieser befindet sich allerdings in den "normalen" Objekteinstellungen und nicht in den Trigger-Einstellungen). ;-) Gemessen wird ausschließlich entlang der Strecke und nicht immer über Weichen hinweg.

    Zitat von Kartoffelphantom

    Beim GT6N wird laut diesem Artikel zusätzlich noch die Prozedur OnEnterLeaveTrigger verwendet, was dafür sorgt, dass obiger Befehl nur ausgeführt wird, wenn sich das Fahrzeug genau an einem Trigger befindet. Warum man das so gelöst hat, verstehe ich allerdings nicht.

    Das hat Tene schon sehr treffend erklärt! ;-) Auch wenn eine Funktion "HandleEnteringSwitchTrigger" denkbar wäre, bei der ein bestimmter Trigger direkt angesprochen werden kann, so ist es in diesem Fall dennoch egal, weil das Fahrzeug ohnehin an alle Trigger in Reichweite sendet. Allerdings besteht der "Verständnisfehler" vermutlich einfach darin, dass die Triggerreichweite nur entlang der Strecke gemessen wird. Und der GT6N ist ja auf Trigger ausgelegt. Und 50m ist seeeeeehr lang für eine Trigger-Strecke! ;-) "Längliche" Trigger sind nur für solche Systeme geeignet, bei denen das Fahrzeug (bzw. der Stromabnehmer) in einem bestimmten Bereich stehen muss, während das Ereignis ausgelöst wird, und nicht über eine Bake fährt, so wie der GT6N.

    Das bedeutet, das Fahrzeug selbst sendet quasi mit einem Radius von 0 Metern, der Mapbauer kann aber die Trigger so konfigurieren, dass sie einen größeren Empfangsbereich haben? Tut mir Leid, dass ich noch mal nachhake, aber mit dem MapEditor bin ich überhaupt nicht vertraut, und im Lexikonartikel steht nichts dazu. Glaube ich. Falls ichs nicht übersehen habe.


    Wird die Prozedur OnEnterLeaveTrigger ausgeführt, sobald das Fahrzeug in den Wirkradius des Triggers eintritt, oder erst, wenn es die eigentiche Position des Triggers passiert? In beiden Fällen wird die Prozedur aber nur einmalig ausgeführt, und nicht mehr, wenn das Fahrzeug innerhalb der Reichweite eines Triggers zum stehen kommt, oder?


    Das frage ich deshalb, weil ich glaube, dass selbst innerhalb eines Betriebes zum Teil unterschiedliche Sende- und Empfangsvarianten genutzt werden. Wie das in Berlin ist, kann ich nicht genau sagen, aber im Zuge der Kompatibilität fände ich es schon schön, wenn man das gleiche Fahrzeug auch auf anderen Strecken einsetzen könnte. Wenn ich das in Dresden etwa richtig beobachtet habe (jetzt ärgere ich mich, dass ich in der entsprechenden Vorlesung nicht richtig aufgepasst habe-_-), dann werden die "normalen" Fahrstraßenanforderungen vor Weichen ebenfalls über irgendwie geartete, mehr oder weniger punktuelle Sensoren empfangen. In einigen Fällen, in denen anforderungsabhängige Ampelkreuzungen direkt hinter Haltestellen liegen, werden die Anforderungen aber nicht bereits bei Eintreffen der Bahn ausgelöst, sondern erst bei Beginn des Türschließvorgangs (oder bei älteren Fahrzeugen durch Drücken der Fahrstraßenanforderungstaste Geradeaus, ebenfalls bereits im Stand). Hier scheint dann ja einer dieser Fälle aufzutreten, in denen der Empfänger einen größeren Wirkradius hat.


    Das würde sich aber mit einem Skript, wie es aktuell der GT6N hat, nicht umsetzen lassen (wenn OnEnterLeaveTrigger nur bei Ein- und Ausfahrt in den/aus dem Wirkungsbereich durchgeführt wird), da die Anforderung gesendet werden müsste, während das Fahrzeug steht, und ohne, dass es in einen Triggerbereich hineinfährt. Helfen könnte es also, wenn ich zusätzlich zum einmaligen Senden der Anforderung beim Erreichen eines Triggers noch ein weiteres Mal Senden würde, und zwar direkt beim Auslösen der Anforderung, dann aber unabhängig von allen Triggern. Damit hätte ich beide Fälle (Einfahrt in einen Triggerbereich, und bereits im Triggerbereich) abgedeckt, und würde trotzdem nicht performanceunfreundlich dauerfunken. Könnte das so hinkommen, oder habe ich das Prinzip immer noch falsch verstanden?


    Aber Euch schon mal vielen Dank für die bisherigen Antworten, das macht die Sache bereits deutlich klarer für mich. Danke!



    Rein interessehalber mal, wie genau läuft das denn in Berlin beim Vorbild ab? Ich hatte jetzt erwartet, dass die Fahrzeuge prinzipiell permanent über die zehn Sekunden oder hundert Meter Fahrweg senden, das aber offenbar nicht mit allzu großer Reichweite, und dann befinden sich irgendwo entlang der Strecke Empfänger, die das Signal aufnehmen und verarbeiten. Das würde dann bedeuten, dass auch in Berlin das Senden von Anforderungen, während man gerade in einem "Empfängerbereich" steht, möglich wäre. Marcels Skriptweise, aber auch die Erklärung mit der Bake jetzt legen allerdings nahe, dass die Fahrzeuge nicht die ganze Zeit senden, sondern wirklich nur, wenn sie von einer Bake dazu aufgefordert werden. Und damit wäre es sogar realistisch, wenn die Fahrzeuge dann nicht in der Lage wären, ind größeren Empfängerbereichen stehend eine Anforderung abzugeben, weil sie eben nicht von einer Bake dazu angeregt werden.

    Zitat von Kartoffelphantom

    Das bedeutet, das Fahrzeug selbst sendet quasi mit einem Radius von 0 Metern, der Mapbauer kann aber die Trigger so konfigurieren, dass sie einen größeren Empfangsbereich haben?

    Jo

    Zitat von Kartoffelphantom

    Wird die Prozedur OnEnterLeaveTrigger ausgeführt, sobald das Fahrzeug in den Wirkradius des Triggers eintritt, oder erst, wenn es die eigentiche Position des Triggers passiert? In beiden Fällen wird die Prozedur aber nur einmalig ausgeführt, und nicht mehr, wenn das Fahrzeug innerhalb der Reichweite eines Triggers zum stehen kommt, oder?

    Sie wird einmal ausgeführt, wenn der Sensor (nicht das Fahrzeug!) in den Wirkbereich eintritt und nochmal, wenn er ihn wieder verlässt. Wenn es zum Stehen kommt, passiert nichts "extra".

    Zitat von Kartoffelphantom

    aber im Zuge der Kompatibilität fände ich es schon schön, wenn man das gleiche Fahrzeug auch auf anderen Strecken einsetzen könnte

    Das ist natürlich auch unser Ziel. :-)

    Zitat von Kartoffelphantom

    wenn ich zusätzlich zum einmaligen Senden der Anforderung beim Erreichen eines Triggers noch ein weiteres Mal Senden würde, und zwar direkt beim Auslösen der Anforderung, dann aber unabhängig von allen Triggern.

    Du kannst aus dem Script heraus jederzeit und aus jeder Prozedur heraus den "Weichenstellen"-Trigger auslösen. Das ist nicht an die "OnEnterLeaveTrigger" gebunden.

    Zitat von Kartoffelphantom

    Das würde dann bedeuten, dass auch in Berlin das Senden von Anforderungen, während man gerade in einem "Empfängerbereich" steht, möglich wäre.

    Also, erstmal ist hoffentlich klar, dass wir über's Weichenstellen sprechen, ne? ("Anforderungen" ist insofern ja eigentlich falsch...)


    Die Berliner Tram hat im Boden Baken. Ob nun der Stellbefehl die ganze Zeit blind gesendet wird oder eine bidirektionale Kommunikation stattfindet, das weiß ich nicht... ich habe es - wie gesagt - deshalb so programmiert, weil es deutlich effizienter ist und am Ende auf's selbe hinausläuft. Wie wir das lösen, wenn weitere Systeme implementiert werden, müssen wir einfach mal schauen.

    Zitat von Marcel Kuhnt

    Also, erstmal ist hoffentlich klar, dass wir über's Weichenstellen sprechen, ne? ("Anforderungen" ist insofern ja eigentlich falsch...)

    Ich hoffe mal, das kommt irgendwann noch zusammen. Richtungssensitive Anforderungen sind ja nicht völlig aus der Luft gegriffen und scheinen mir da genau das Mischwesen in der Mitte zwischen Weichenstellen und Anforderungen zu sein. Und ob ich nun übers IBIS eine Weiche stellen, oder darüber im Stand manuell eine Anforderung auslösen möchte, da sehe ich im Vorgehen auch keine so großen Unterschiede. ;-)


    Mir machen aber gerade die Fahrzeugtrigger schon wieder etwas Problem. Gibt es irgendeine Möglichkeit, die Scriptseitig zu deaktivieren?


    Bei Solofahrzeugen läuft alles mittlerweile ziemlich hervorragend, Mehrfachtraktionen sind aber ein Problem. Meistens bei Ampelanforderungen: Hat sich das erste Fahrzeug angemeldet und die Ampelanlage reagiert auf die Anforderung bevor das zweite Fahrzeug den Streckentrigger passiert, dann meldet sich das zweite Fahrzeug erneut seperat an, was teilweise gerade bei komplexeren Ampelschaltungen die ganze Anlage durcheinanderbringt oder sogar außer Gefecht setzt.

    Kann man sehr gut auch auf Diorama sehen. Die Ampelanlage an der Ausfahrt der Wendeschleife ist zwar nicht so kompliziert, aber auch die reagiert schon verwirrt darauf, wenn man die Schleife mit einer Traktion verlässt. Denn der zweite Zug meldet sich dort immer selbst noch mal neu an, was dazu führt, dass die Ampelschaltung gleich zwei mal durchläuft statt nur einmal, obwohl der Zug schon lange wieder weg ist.


    An Weichen habe ich auch manchmal Probleme damit, dass womöglich das zweite Fahrzeug Weichen, die man nur mittels G gestellt hat, irgendwie wieder resettet und unmittelbar vor oder sogar unter dem Zug wieder zurück in ihre Ausgangslage stellt, aber das habe ich noch nicht genauer untersucht, vielleicht hat dieses Phänomen auch einen ganz anderen Grund.

    Wäre es möglich, das die Weichen so gestellt werden wie im Original? Also völlig Automatisch vom IBIS bzw. OBU? Wenn ja, ich könnte die Originale Software bekommen, selbst die ganz neue, die nach und nach derzeit Aufgespielt wird. Ja, es ist derzeit eine Aufspielung von einer völligen neuen OBU im gange. Aber dazu müssten auch in Lotus die ganzen Barken usw. Funktionieren.


    Ps.: Gilt nur für Berlin, ist klar.


    Ps. II: Kartoffelphantom Ist Abgeklärt, ich dürfte das machen.

    Diebaer die Originale OBU-Software nutzt hier niemandem etwas, es denn er/sie hat einen echten Atron FRcity im Schrank liegen.

    LOTUS kann mit der OBU-Software nix anfangen und ich glaube auch nicht das Teneberus oder Marcel Kuhnt LOTUS oder die gemoddete OBU auf links drehen werden nur damit hier eine Originale Software verwendet werden kann, die meiner Meinung höchstwahrscheinlich auch nicht verwendet werden darf (Urheberrecht).

    Und nur weil du sie angeblich bekommst heißt es nicht das sie kommerziell genutzt werden darf.

    Zitat von Trammi

    Diebaer die Originale OBU-Software nutzt hier niemandem etwas, es denn er/sie hat einen echten Atron FRcity im Schrank liegen.

    LOTUS kann mit der OBU-Software nix anfangen und ich glaube auch nicht das Teneberus oder Marcel Kuhnt LOTUS oder die gemoddete OBU auf links drehen werden nur damit hier eine Originale Software verwendet werden kann, die meiner Meinung höchstwahrscheinlich auch nicht verwendet werden darf (Urheberrecht).

    Und nur weil du sie angeblich bekommst heißt es nicht das sie kommerziell genutzt werden darf.

    Ich dürfte diese wirklich weiter geben, das ist Abgeklärt. Extra gefragt und er kennt Lotus.

    Auch er findet Lotus soweit ganz gut, aber kann sich nicht vorstellen, das Lotus so umgesetzt wird, das es wie in Original Funktioniert.

    Zumindestens was die Karte Berlin betrifft, wofür nur diese OBU tauglich wäre.

    Die frage ist ja nur, ob diese nutzt. Aber wie du schon schreibst, wird diese uns nichts nutzen, weil Lotus das so nicht umsetzten kann oder wird. Oder Marcel Kuhnt ?

    Der Urheber dieser OBU-Software und der zukünftigen ist einer, der das für die BVG macht und er hat alle Rechte. Von diesen habe ich diese Genehmigung.

    Aber es muss stimmen.

    Warten wir mal ab, was das "Lotus-Team" dazu sagt.


    Ps.: Trammi Darf trotzdem keinen Namen nennen. Tut mit leid. Das ist Bedingung des Urhebers dieser Software, der Täglich damit zu tun hat.

    Ps. II: Der GT6Ner hat leider im Fahrsound einen fehler, da ist ein GT6NerU zu hören ab ca. 15km/h. Eindeutig, was mein Reden seit XXX ist.

    Wenn es möglich ist, der Originale GT6Ner Sound ist noch zu haben, haben noch genug 12xx auf Strecke. Alle 12xx sind noch Original und keine U-Boote.

    Zitat von Diebaer

    Wäre es möglich, das die Weichen so gestellt werden wie im Original? Also völlig Automatisch vom IBIS bzw. OBU?

    Das ist selbstverständlich geplant.


    Zitat von Diebaer

    [...] kann sich nicht vorstellen, das Lotus so umgesetzt wird, das es wie in Original Funktioniert.

    Wir werden sehen...


    Zitat von Diebaer

    Der Urheber dieser OBU-Software und der zukünftigen ist einer, der das für die BVG macht und er hat alle Rechte. Von diesen habe ich diese Genehmigung.


    [...]


    Ps.: Trammi Darf trotzdem keinen Namen nennen. Tut mit leid. Das ist Bedingung des Urhebers dieser Software, der Täglich damit zu tun hat.

    Meines Wissens nach stammt die Software von ATRON und wird lediglich auf die Bedürfnisse der Verkehrsbetriebe angepasst. Ich bezweifel sehr, dass dein Kontakt die Urheberrechte besitzt und diese Software einfach rausgeben darf, was durch den Wunsch, nicht genannt zu werden, nur unterstützt wird.

    Doch, er macht die Software dafür Fit und hat alle berechtigungen. Der Name deshalb nicht, weil BVG Angestellte in Foren nicht genannt werden dürfen. Wer er ist, kann auhc hier in diesen Forum jedem Egal sein. Fakt ist, stellt er diese zur verfügung, geht alles mit Recht zu.

    Und was soll das bringen? Ist das der Sourcecode in einer höheren Sprache (dann könnte man zumindest die Logik extrahieren), ist es Assembler, ist es Maschienencode (dann wirds ohne die Doku der Hardware sehr unschön)? Soweit, dass man in LOTUS einen Turing-vollständigen Rechner hat, der am besten noch die Sprache versteht, in der die Software geschrieben ist, sind die Entwickler noch lange nicht (und ich glaube, es gibt deutlich wichtigere Features).


    Klar, man könte nen Parser schreiben, der gegebenen (z.B. C) Code in LOUTS-Skripte übersetzt. Der Aufwand ist aber deutlich unverhältnismäßig zum Nachbau eines semantisch äquivalenten Skriptes.

    Zitat von Diebaer

    Doch, er macht die Software dafür Fit und hat alle berechtigungen.

    Eben, er macht sie "nur" fit, hat sie aber nicht (alleine) entwickelt, hat also nicht das alleinige Urheberrecht. Und alle Berechtigungen hat er mit Sicherheit nicht. Dieser Anwendungsfall ist derart besonders, dass er garantiert in keinem Vertrag zwischen Atron und der BVG auftaucht und damit hat's sich schon erledigt.


    Abgesehen davon gebe ich meinen Vorrednern recht: Das Einzige, was man mit dem Code machen könnte, wäre eine Analyse, um die Funktionen nachzuvollziehen, aber das ist wohl wesentlich einfacher, wenn man sich einfach genau ansieht, wie er bedient wird, zumal die genauen Grafiken und Schriftarten vermutlich dann auch noch separat in Ressourcen-Dateien verpackt sind usw. usw.

  • Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.

    Die letzte Antwort auf dieses Thema liegt mehr als 60 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.

    • :)
    • :(
    • ;)
    • :giggle:
    • :P
    • ;p
    • ^^
    • :D
    • :'D
    • 8)
    • :fantastic:
    • :omg:
    • :love:
    • 9.9
    • ?/
    • 8D
    • :sshht:
    • :rofl:
    • (:
    • :*
    • :<
    • ::
    • =O
    • X(
    • o.O
    • xD
    • ^^°
    • XP
    • <:(
    • vv°
    • :'/
    • ;(
    • :|
    • ><
    • -_-
    • :ouch:
    • oOD
    • 8o
    • <X
    • ||
    • ?(
    • :S
    • :O
    • :evil:
    • <3
    • :X
    • :o)
    • X/
    • :rolleyes:
    • :cursing:
    • :saint:
    • 9(
    • :!
    • :ghosty:
    • :alien:
    • :doesnttalk:
    • :doesntsee:
    • :doesnthear:
    Maximale Anzahl an Dateianhängen: 5
    Maximale Dateigröße: 500 kB
    Erlaubte Dateiendungen: bmp, cfg, ini, jpeg, jpg, lct, ldl, llg, lob, log, lpmtl, lptmt, ltx, pas, pdf, png, railtrack, rar, txt, veh, wav